或許你聽過這樣一個段子：一如程式碼深似海，後面從此有無數的跟句：從此妹子是路人，從此程式碼是節操……或許，許多寫程式碼的程式設計師每天應對的就是寫不完的程式碼和改不完的bug。只想說，如果你只需要解決這兩件事情算是幸福的了，因為多數程式設計師同志遭遇的不僅是以上的挑戰。　　以下為正文：　　我曾擔任過開發人員和專案經理，現在是一家開發諮詢公司的CEO。在擔任這些角色期間我學到了一個經驗教訓：過多地屈從於客戶的需求、希望和一時的心血來潮，將會限制你實際的工作能力以及正確解決問題的能力。　　為什麼說你需要學會說不，才能讓客戶和開發專案可以得到最好的結果呢？其中有三個原因：　　1. 並非所有客戶都適合你的團隊　　最近，一位客戶告訴我他們不願意支付預付款。我告訴他們可以選擇即刻退出而不用付任何費用，我解釋說：“我們提供定製軟體，而非定製流程。”　　最後，他們沒有簽約。雖然這在財務上並不是最好的結果，但對我的團隊和業務來說這是最好的結果。　　我沒有在這個問題上變通並不是我想為難他們，而是因為我們已經開發出了久經考驗的流程，而且如果我們希望持續擴大規模和盈利，就不能為了每個客戶而調整我們的流程。　　雖然這個問題關係到付款，但是也適用於我們業務的所有方面。如果客戶希望由最合適的團隊來負責他們的專案，那麼他們也必須是我們最合適的客戶。　　Forrester的一份報告預測，2018年僱主可能需要為高階開發者和其他急需的人才支付高於市場20%的薪水。在技術人才短缺的情況下，相對較易找到新客戶，但是卻很難找到最好的開發人員。　　要求客戶同意我們的條款可以幫助我們管理專案，但同時也表明，與有困難的客戶的付款相比，我們更加重視我們的開發人員的工作。即便沒有新客戶我的業務可以照常運轉幾個月，但是如果所有經驗豐富的高階開發人員都離職的話，我們就完蛋了。　　2. 客戶付錢聘請的是專家，而不是聽話的人　　由於害怕失去客戶或收到差評，很多領導被迫應允所有事情。然而，如果答應的事情會讓團隊陷入極大困境的話，那麼你面臨的風險更高。　　沒有人會跑到一家米其林的星級義大利餐廳，然後抱怨廚師不會做印度咖哩。因為你很明白，如果讓別人做他們不擅長的事情，那一定無法滿足你的期望。　　因此，我和我的團隊非常清楚我們提供的服務和不提供的服務。我們只做：PHP、Laravel、Java、Vue.js、Node、Ionic和Electron。這些都是現代的成熟的技術，我們可以快速地構建和擴充套件產品。　　客戶之所以付錢給你，是因為在某些事情上你做得比他們更好、更快。我們經常遇到的一個問題是，客戶會拿出很多他們認為對達成目標所必需的功能或整合方案。我們所要做的是拒絕，並向他們展示我們可以用最簡單和對使用者更友好的方式來實現。　　另一個常見的問題是，客戶希望等到產品盡善盡美再開始讓使用者使用。但這不利於我們的工作。我們利用久經考驗的敏捷方式來構建軟體，並鼓勵客戶儘可能在早期讓更多真正的使用者來使用軟體，以便我們做測試，發現故障，並改進功能。　　3. 客戶參與得太多或太少　　在精益軟體開發方法流行之前，公司的一個專案開發三年之久，到頭來卻發現產品並不符合實際目標的現象非常普遍。我相信如果使用迭代週期，你沒有理由無法在三個月內做好軟體的某個功能。但是有效地運轉迭代週期需要客戶從頭到尾參與整個過程。　　既然我和我的團隊負責解決問題，那麼遇到客戶只給出簡單需求就消失得無影無蹤，最後還希望我們可以交付完整產品的時候，我們會選擇拒絕。相反，我們希望與客戶密切合作，推進快速迭代的開發過程。　　我認為溝通和合作是開發專案的命脈，而且我們應該將成對的高階開發人員指派給客戶，這些客戶則需要在每個迭代週期結束時負責檢查。　　研究表明，與單個的程式設計師相比，成對的開發人員可以更好地考慮更多設計選擇，並且可以開發出更簡單、更加易於維護的最終產品，且設計問題和bug更少。　　同時，也有客戶參與過多的現象。關注管理細節的客戶往往會分散開發團隊的注意力，並可能極大地降低專案速度。因此，在每個迭代週期結束的時候，我們會提供兩週（敏捷開發中每個迭代週期一般為兩週）的進度彙報，而在迭代的關鍵時期，只有財務經理或專案經理作為聯絡人員負責維繫客戶，同時他們可以新增重要的任務到後備需求列表中。　　客戶最終選擇你的原因是因為他們不想聘用並管理每個開發人員。如果你放任他們隨意地推進你的開發專案，那麼合同就沒有意義了。所以在客戶聽到太多NO之前，如果你希望提供最好的服務，那麼你需要掌控大局並知道何時必須堅定立場。
​     如果有任何疑問，歡迎新增qq群測試入門到大神 755431660 共同學習~
​​