偏差
在項目的開發(fā)過程中，經(jīng)常會出現(xiàn)這個問題。
但這不能怪程序猿——畢竟寫的再詳細的文檔，不同的人看也可能會產(chǎn)生不同的理解，還有可能是我們的文檔寫的不夠詳細。
針對這個問題，我們應(yīng)該把主要精力要放在預(yù)防上面：
在程序猿開發(fā)某一個小模塊前，尤其是新出現(xiàn)的或者是重點模塊，主動去找程序猿進行需求再確認，再和程序猿講明需求，也可以讓程序猿口述一下需求，我們來聽；最終目的就是要確認程序猿已經(jīng)完全理解了需求，避免后續(xù)的更改與返工。
如果在開發(fā)過程中仍然出現(xiàn)了對需求的理解問題，比如前端和后端對接口的理解不一，如果你此時不去協(xié)調(diào)，那么這個問題可能會被擱置，后期還是會爆發(fā)出來。
還有可能是理解錯誤的一方將另一方說服，從而造成后期的返工和改動，這是很傷的。
當發(fā)現(xiàn)雙方有理解上的偏差時，一定要把雙方叫在一起討論，確保前端和后端都能正確的理解需求，再進行開發(fā)。
在項目開始前一定和程序猿講明，對需求有任何分歧一定要找你，大家商議解決，而不要私下討論。
2）出現(xiàn)需求變更
需求變更，無論是產(chǎn)品經(jīng)理還是程序猿，看到這個詞都會覺得頭疼。
出現(xiàn)需求變更的原因主要有三個：
產(chǎn)品經(jīng)理自己沒有思考全面，比如對異常情況的處理不夠細膩等等。我們應(yīng)該盡量避免這種情況的發(fā)生，如果總出現(xiàn)這個問題，說明我們的工作是有疏忽的，程序猿也會對你產(chǎn)生不信任感。如果因為這個原因出現(xiàn)了需求變更，去找程序猿大爺說明吧，回來后對自己進行充分反思，并爭取在下一次做得更好。
老板要求改需求，這種情況我們看似無能為力，但實際上也是有操作空間的。對于老板的要求，我們首先要仔細的思考利弊，如果仍然覺得之前的方案好，拿出證據(jù)向老板說明。如果老板的方案更好，那么我們就要有技巧的向程序猿說明。同樣可以利用講故事的方式，向程序猿說明更改需求的原因與必要性。這時就是考驗?zāi)愫统绦蛟酬P(guān)系的時候了，沒事的時候記得和程序猿們打好關(guān)系哦。
自己腦袋中突然靈光一閃，覺得某個功能點有更好的方案。如果是這種情況，哪怕這個方案真的好，哪怕它能提升50%的轉(zhuǎn)化率，我還是建議放在下個版本進行優(yōu)化，如果我們站在程序猿的角度上想：“需求是你定的，我代碼都寫一半了，你突然有了更好的點子，然后就讓我刪除自己辛辛苦苦敲出來的代碼，憑什么？”
人非圣賢，誰也不能保證自己第一個方案就是完美的。
當有了更好的點子時，我們不妨再增加一個優(yōu)化版本，反正版本上線后我們也要收集用戶反饋，把這個點子放在優(yōu)化版本里不是更好么？
3）項目進度延期
當發(fā)現(xiàn)項目進度已經(jīng)落后的時候，我們首先要分析原因，根據(jù)原因來尋找解決辦法。
可能的原因有以下幾個：
①團隊溝通不暢
如果前期做好了預(yù)防，一般是不會出現(xiàn)這個問題的。
但真出現(xiàn)了這個問題，怎么辦呢？
此時我們就需要找到溝通不暢的當事人，詢問原因，是成員之間不能正確理解對方的意思呢，還是互相不認可對方的觀點。
如果是溝通不暢的雙方?jīng)]有辦法正確理解對方的意思，那此時我們要做雙方的“翻譯機”，確保成員之間理解統(tǒng)一；如果是互相不認可對方的觀點，那么此時，抓上項目經(jīng)理或開發(fā)主管，一起來商量誰的解決辦法更好。
總而言之，一定要確保團隊成員對項目理解的統(tǒng)一，大家?guī)е粋€目標前進。
②程序猿能力不夠
之前也遇到過這種問題，程序猿小A難以完成分配給他任務(wù)，這時我們就要叫上技術(shù)的大佬，然后讓程序猿小A去敘述他遇到了什么難題，讓大家一起解決，解決問題的方法我們就不摻和了，做好團隊之間的橋梁就好。
③程序猿因為生活上的事導(dǎo)致情緒低落，開發(fā)積極性低
我們都是人，是有情感的動物，難免會因為生活上的的事情影響到工作，這時候，我們要從同事的身份中脫離出來，作為朋友，帶著程序猿去吃點小菜，喝掉小酒，聊聊人生，看看美女，沒事再給程序猿買點零食，送點溫暖。
此時對待程序猿要向?qū)Υ约号笥岩粯訙厝?，幫他從情緒低谷中走出來，重新振作開始工作，這樣無論是對于團隊，還是對于他自己，都是有好處的。
④對工期預(yù)估過于樂觀，項目排期出現(xiàn)了問題
項目排期，其實也是一個預(yù)估的時間，誰也不能保證一定可以準時完成，如果是項目排期出現(xiàn)了問題，一
