越來越能體會這句話「管理大部分時間都在溝通和協調」，一個專案涉及很多人，包括業務、產品、設計、後端開發、前端開發、測試等，他們對同一件事情的理解可能不同，過程中也會有各種問題，需要不斷協調和溝通才能達成一致，如果還劃分為不同的組，溝通和協調會更困難。
最近負責了2個大的需求開發，過程中遇到了很多問題，導致了專案延期，給別人和其他小組帶來了不好的印象，有些是自己的問題，有些是他人的問題，為了能在以後專案中進行改善和避免，一併總結下。
信任與責任
我們組有一個同事，大家都覺得他技術很強，自己負責的任務也能不錯的完成，但只關注別人提到的點，過程中遇到問題也不能很好的溝通，有很大的風險。
技術好不代表能力強，剛開始會把一些重要的事情交給你，但如果缺乏責任感，會辜負大家的信任，慢慢地脫離團隊。
領導會把重要的事情交給他最信賴的人去做，他會很放心，也不會過問很多，時間到了，便會得到一份滿意的答卷，這就是信任。
專案開發是一個團體行為，應站在團隊整體利益的角度去考慮，對自己的任務負責任，對整個專案負責任，重視與他人的溝通和配合。
多做一點，多想一點，對專案負責任，會贏得大家的信任。
整體和細節都很關鍵
先說下我們現在的開發流程：
- 業務會和產品溝通需求，形成產品需求文件、原型圖、互動稿；
- 開發、測試對需求進行理解，梳理自己的疑問；
- 產品和開發、測試一起，進行需求宣講，解答開發測試人員的疑問；
- 開發、測試對功能進行拆分，評估出開發時間；
- PMO組織召開專案立項會；
- 實施過程中，對進度進行把控；
看似完整的流程，還是遇到了一些問題，好多人缺乏對整體功能的瞭解，一些細節做得也不到位。
產品需求文件太散，沒有把功能串起來，大家理解起來有一定困難，如果一個文件需要大家反覆揣摩才能理解，那是不合格的，會大大增加溝通成本。如果有一個檢視，把功能按場景串起來，理解起來會容易很多，一些細節也能給產品正反饋。
原型、互動也不夠細緻，這樣會導致每個人的理解不統一，甚至會缺少一些功能，影響的不光是後端開發，還有前端開發、測試，業務驗收時也會反饋相關問題，大大增加了返工率和人力成本。
開發和測試也有問題，沒有詳細分析產品需求文件，慌慌忙忙去參加需求宣講會，等於浪費大家時間，沒有對功能點及實現進行詳細分析，大致評估開發時間，會讓進度一再延期，處處有風險。
關於需求文件、原型、互動，以後會時刻促進產品做的細緻點、易理解一點。
關於需求宣講，要提前通知到位，讓每個人有足夠時間去分析、梳理，更好地參與需求宣講會，這點我做的不好。
關於功能分析和時間評估，我就不要自以為是了，交給開發負責人去評估，需要做的就是輔助他們分析，從整體上進行把控。
前期的重視和投入，會產生1+1>2的效果，減少溝通成本。
任務的並行和突發性
僅線上客服這一塊，就有8-9個工程，還有很多其他依賴的服務，一個新需求可能涉及很多工程，而且部署了4套環境，要不斷的處理線上反饋的問題。
目前僅有3個人來處理這些，最近這段時間，我開發的也少了，可想而知，任務的並行和突發會經常發生，要協調好。
真是辛苦他們了。
在評估工時時，需要考慮這些，可以按照比例大致評估下，預留一些buffer，免得專案不斷延期。
任務的依賴性
這段時間，前端同事老是抱怨提供的介面無法走通整個流程，因為後端呼叫鏈條比較長，需要完成很多工作才能真正調通，這是我的失誤，沒有考慮到前、後端任務的依賴性。
一方面，可以讓前端晚點介入，減少不必要的投入。
另一方面，可以給後端評估多點時間，先做一些偽介面，先讓整個流程能夠跑通，前後端各自開發，互不影響，這樣後端開發也會更清晰。
無論哪種，要提前協調好。
題外話：介面一定要自己驗證，特別是關聯度大的介面，不要讓前端幫你找問題。
進度把控
專案管理中，進度把控也是比較難的，每個人的水平、想法、性格不同，過程中會穿插其他一些事情，有些實現效果也是未知的，所有這些因素，都會影響專案的整體進度。
針對重要專案或一些人，需要每天對下進度，把問題和風險儘早發現，如果進度特別緊，可以臨時協調其他人加入開發。
對於我，要重視別人反饋的問題，不拖延，加強溝通和協調。
不要因為我的忽視影響整體進度。
預留聯調的時間
如果涉及的工程比較多，評估工時時，要預留足夠的聯調時間，每個人開發各自的模組，有些問題可能在聯調時才發現，需要時間去修改。
這點，我忽略了。
歡迎掃描下方二維碼，關注我的個人微信公眾號，檢視更多文章 ~
