我的經理希望我根據客戶的請求進行更改。

問題

我應該如何進行？

您應根據客戶端的請求進行更改。

顯然，客戶端需要此修改。顯然，您的經理同意。看來他願意吸收技術上的影響以便使客戶滿意。

再也沒有必要再作解釋，除非即使您清楚地解釋了，經理也不認為您理解您（它似乎他確實理解，但不同意。）

很顯然，您的經理是可以決定這裡不需要什麼的人，而不是您。

一旦滿足了客戶的請求，就可以決定。 ，您可能想找一個安靜的時間與您的經理進行討論。您進行此類討論的目的不應是使您的經理相信您是對的。相反，您的目標應該是向您的經理詢問該決定，以便您更好地了解公司的客戶請求流程。顯然，有一些您不了解的客戶問題。

或者可能正在尋找其他工作？

如果您需要一份可以得到的工作即使客戶和經理已經決定要決定客戶得到什麼或沒有得到什麼，也應該尋找新工作。

也許您應該尋找一個管理職位，在哪裡對於交付哪些功能和不交付哪些功能具有更大的影響。或者，也許您應該尋找一個客戶服務或產品管理角色，以便您與客戶進行更緊密的互動，影響產品功能時間表，並有助於確定滿足或拒絕哪些客戶請求。

正如@IsmaelMiguel正確指出的那樣，在一家產品公司工作，在該公司很少徵求或滿足個別客戶的要求。 （當然，您仍然會遇到經理的指示。）

還是應該告訴我的經理，如果這麼簡單，他應該幫忙嗎？

只有當你不真正重視自己的工作時，才應該對老闆生氣。

您的問題基於對用戶請求的有效性和正確性的質疑，以及經理選擇接受並採取行動的基礎。用戶的請求有效，而您的經理的決定也有效。

這是您要做的工作。

您需要的是非功能需求的實現。

系統要求您提高可用性，而不是功能擴展。

系統的非功能性需求是 still 需求

在這種情況下，這些可用性修補程序旨在提高用戶的工作效率並降低其錯誤率。

可用性修補程序實施起來並不容易。這並不意味著應該將它們視為第二類關注點。作為開發人員，您可以在其中創建重要而不是 easy 。

一本出色的書，有助於理解可用性作為關鍵，核心，工程方面的關注點是
Donald Norman的“日常事物的設計”（鏈接）。

T型福特是一個功能完善的系統，需要進一步開髮用戶控件的一個很好的例子。就像汽車一樣。它引導。停了它載有乘客。

現在看看用戶控件（鏈接）。沒有人再這樣喜歡它們了-有充分的理由。

它們很難啟動（並且容易出錯，即容易受傷）。

節氣門是一對操縱桿在轉向柱的相對兩側上，它們必須獨立且有時同時操作。

嘗試考慮一種在兩種情況下都可行的解決方案。

如果已經存在此功能，那麼就用戶界面而言，顯然是不合適的。也許重新設計控件或導航？嘗試通過巧妙的方法來減少點擊次數，以達到所需的目的。

此外，當經理告訴您做您完全不同意的事情時，辭職？！ / strong>您一定很喜歡找工作，因為這很常見。

您的問題很混亂；這是一個很大的矛盾。要么它已經存在於產品中，那麼就無事可做。或不是，您必須克服一些技術問題。但不是兩個。

如果產品中還沒有該功能，請按照以下步驟操作：

如果您還沒有，請重新發明輪子。尚未完成，請書面通知您的經理。一封電子郵件就足夠了。其中應包含您所要解決的問題和技術難題，並在可能的情況下估算出時間。清楚地標記那些您真的不知道如何解決它們的地方，並尋求他的幫助。

還要詢問他該功能是否值得，並向他展示更重要的功能等待積壓。現在，您已經為他提供了一個時間範圍（“解決所有問題要花5週，完全解決4個問題”）和可能的人力使用方式，他應該能夠做出明智的決定。

如果他回答“是的，繼續前進”，則盡一切可能，並傳達所有您無法解決的問題。他要求提供該功能，並為您提供了解決問題的時間表。其他一切都高於您的薪水等級。

首先，應將功能的存在告知客戶（如果尚未存在）。僅僅因為實現了它並不意味著他們知道它或知道如何使用該功能。這應該由與客戶的主要聯繫人（可能是您的經理）完成。他們可能只需要了解此功能。但是，如果他們發現實現沒有用，那麼仍然需要更改功能的實現方式。

如果聯繫點是您的經理，而您的經理已經提出來了並且客戶仍然希望進行更改，或者您的經理認為沒有必要提出更改，那麼您已盡力了。您提出了論據，並且由負責該決定的人做出了決定。現在是執行決定的時候了。

但是，聽起來您的組織內部確實存在問題。代碼隨著時間降級的情況並不少見。 技術債的積累和對系統的更改只會導致設計完整性下降（軟件熵）。最終，必須解決這些問題，否則軟件維護的成本可能會增加到對系統進行更改的極高成本。缺乏時間進行測試並將質量建立到流程中也是一個問題。

這些組織問題是長期問題。 “更改您的組織”就是這種情況。您可以解決這些問題，也可以開始尋找更合適的新組織。

驗證需要對客戶執行的操作。繪製圖片，提供分步說明等，以確保您了解請求。這並不是在向客戶說明現在如何完成工作，而是要確保您正確地完成工作。您甚至可以將其與該功能現在的工作方式進行比較，以驗證其更改是否像您看起來的那麼簡單。

編輯：

您可以擁有客戶或經理批准此更改。您可以向您的經理提及，如果將其提交給客戶以“簽收”，以防萬一交付時他們意識到更改有多小可能會有所幫助。但是，這裡的重點是交流，如果您的經理同意了，那麼至少您可以清楚地完成工作，並且您有文檔證明您提供了要求的內容，並且沒有欺騙或操縱解決方案。

結束編輯

您的客戶可能要求“現有”功能，而他們沒有意識到。您的客戶也可能需要更少的步驟/更少的點擊次數來完成此操作。我熟悉許多由於“點擊次數增加”而對用戶“不可接受”的系統。

嘗試保護自己免受不必要的更改或向客戶收取已存在的功能的費用對您很有幫助。您可能無法根據客戶的要求來判斷客戶，或者像父母那樣過度保護自己，並試圖幫助客戶省錢或以其他方式“按自己的方式做事”。

如果您不願意或無法執行該工作，那麼您的經理應該知道這一點。但是然後您可能應該尋找另一份工作。

我為你感到。我得到的詳細設計始終沒有功能要求。他們不了解當前的數據設計和服務器調用。兩次單擊可以是乾淨且可擴展的，而一次單擊會導致數據模型發生更改。他們說他們不在乎，但是當數據損壞或數據損壞時，這是您的問題。即使您確實做到了，您的代碼庫也很脆弱，下一個更改更加困難。當程序員只被認為是編碼者而不是設計師時，這真令人沮喪。

關於您可以做什麼。 1）說明問題。 2）然後以書面和口頭形式反對並陳述反對意見。概述進行​​此更改的時間和長期影響。 3）然後就做。如果要花3個星期來編程，而要花2個星期來測試，那就這樣吧。代碼將變得更加脆弱，老闆也不會理解。被當作代碼猴子被貶低。也就是說，盡力而為，建立自己的技能。如果您對下一次性能評估仍然感到沮喪，請進行規劃。如果您提出與特定變更無關的流程，那麼希望老闆會更認真地考慮您的職位。如果老闆說流程不會改變，那麼您知道自己的立場。不要只是戒菸。決定是否可以忍受。如果您不能忍受它，那麼請為下一份工作制定計劃。一旦您不再關心當前的工作，那就可以容忍了。

這裡的答案是“得到澄清！”

客戶是否意識到該功能已經以更簡化的方式存在？

如果不是... ，然後他們很可能是相當心煩不被告知這件事，並隨後支付更多的時間惡化已經存在的功能的功能。我知道我會被打勾……當我向項目經理說“我想要功能X”時，他們的工作就是弄清楚它是否已經存在，並讓我知道，以便我可以確保對項目的決定我委託的是一位有見識的人。

如果是這樣的話 ，那麼客戶想要該項目的就是他們想要的。需求就是需求，它們是有原因的，因此不必向您解釋。例如，他們可能有硬數據，這些額外的點擊會對他們的業務產生一些奇怪的積極影響，而他們希望這樣做。甚至僅僅是因為他們愚蠢...如果他們選擇愚蠢，他們有權向您支付額外費用。只要他們能充分告知該決定並支付從您那一刻起花費的時間就可以了。

結論：如果這只是您的項目經理沒有適當地告知客戶，那麼那是個問題。如果客戶即使確實已經知道一個更好的功能版本，仍然真的想要一個啞巴要求，那麼...那麼即使是一個啞巴，它仍然是一個客戶要求。

您不能採取適當的措施直到您弄清楚情況是什麼...或者至少花點力氣弄清楚情況是什麼，以便萬一發現經理沒有做好他的工作，您的屁股就被掩蓋了。

我喜歡它，在工作場所中的每個人都談論道德和專業精神，而我們所做的很多事情都是出於利益和政治遊戲的結果。這裡的情況很明顯，答案很短：
客戶想要捐款（我的意思是，他們的無知使他們在已經得到的東西上浪費了錢），經理沒有問題。那筆錢用來支付你的薪水。為自己拿走這筆錢而高興，並為自己比客戶更聰明而高興。利潤。