從程序媛角度去看項目管理

做者：暖暖

項目管理通常是從技術負責人、項目產品負責人的角度去看的，程序員雖然碼代碼很重要，但對項目的領悟能力也一樣重要。咱們常常會遇到各類困惑：手上的項目需求愈來愈多，BUG列表只增不減，該採起怎樣的措施，保證本身的生產力？但願如下的講述帶給你莫名的認同感，或多或少讓你磨刀霍霍一試。

需求管理

下圖描述的是程序員從接到需求到開發環節的過程：

通常咱們首先會收到產品的PRD或交互稿，被詢問今天什麼時間點是否有空，進行需求評審。時光匆匆，回想起剛畢業那時，我望着冗長的PRD，直接跳過背景、目的等看似與開發無關的內容描述。時光冉冉，我明白了一個道理：知道了爲何而作，才能砍需求啊！！

咱們要作一個有思考的程序員，不是別人說什麼咱們就作什麼，咱們能夠引導產品經理，給出提醒並提供建設性的意見，讓他們向着咱們但願的那個點去思考去改進。 嗯，牛逼~

固然，祈求PRD完美，是不可能的，可是它又是咱們排期、開發的依據，這二者存在這不可避免的矛盾。所以，力求在分析評審階段，把不清晰不完整的部分暴露出來，是咱們的目標之一。

特別警戒一句話需求，好比在頁面添加一個連接，包含的功能可能有：

• 確認添加a元素跳轉爲target="_blank"，仍是在當前頁面跳轉；
• 連接的文字和地址是否可配置，是否經過接口拉取；
• 連接地址是否可爲空，此時要警戒target="_blank"的狀況；
• 連接文字是否可多行，是否限制字數；
• 是否須要埋點，以及確認埋點方案。

第二個目標，就是砍需求了。「沒時間了，這個需求放在二期吧」 這個金句，不知道你們感悟深不深，哈哈。首先要清楚本身在某個時間段的工做重點，而後根據需求與工做重點的相關係數去評估，有意識地拒絕一些無心義的工做。固然，工做重點應該是與業務息息相關的，最好是和上級商量後的結果。

因而，給本身定個todo list，在需求評審前本身過一遍相關文件內容，列出有疑問的地方，作好砍需求的準備...

需求排期

確認需求後，首先確認需求的優先級，而後進行排期。 若是咱們手上有許多需求，確認需求的優先級是十分有必要的。

• 來自同一個產品的需求，可以讓對方給出優先級便可。
• 不一樣產品的需求，可徵求需求方的意見，避免出現嚴重影響到對方的主流程的狀況。
• 雖然說需求的優先級主要掌握在產品經理的手上，可是咱們本身也要有個認識。 瞭解 主線需求 > 主線的分支需求 > 錦上添花的需求 的原則，根據 用戶覆蓋面、用戶使用頻次、對用戶的重要程度，以四象限法則「重要且緊急 > 重要不緊急 > 緊急不重要 > 不重要也不緊急」做爲輔助等等，應付什麼需求都重要、什麼需求都緊急的狀況。
• 針對老闆提的需求，下週要演示給老闆看的需求，咱們就乖乖地排期在前面吧，排除萬難，沒啥好說的~

排期一直是歷史難題，有如下「名言名句」供參考：

• 瞭解需求進入開發階段的依賴條件，好比是否依賴設計稿仍是接口，而後再進行排期。
• 不要把一天當8個或者更多的工做小時用，臨時的會議或者被打斷的現象太常見了。
• 排期留有餘地，尤爲是本身不熟悉的領域，風險較高。排期的計算方式有挺多，能夠根據本身的豐富經驗來，或者計算公式好比（通常能完成的天數 + 確定能完成的天數）/2，或者（通常能完成的天數）x 係數，係數根據難度來區分。
• 把握好需求的節奏，如遇開發週期較長的需求，將需求拆分紅N個子需求。
• 要明白，即便排期很輕鬆，你可能依然是最後一刻才完成，太扎心。

需求跟蹤

需求進入開發後，特別是大項目，得利用需求管理平臺，這有利於需求的進度追蹤，且方便咱們彙報工做。不要把彙報工做當作負擔，應化被動爲主動。不然，週五下午某個時刻，你會收到產品經理的盤問：「作得怎麼樣了？進度如何？」；彙報工做，也有利於讓你們看到本身的努力成果，成就感增倍，造成良好的工做循環；或者是瞭解身邊的小夥伴在作什麼，有利於交流。

咱們如今每週五會開項目例會，彙報內容以下：

1. 結果：進度如何，完成了哪些內容？
2. 計劃：下週計劃完成哪些內容？
3. 問題：討論問題，找出問題的失誤點、關鍵點、反思點，如何解決。

需求變動

需求變動有時不可避免，咱們還得拿出快速響應需求變動的本事，記錄反饋全部的變動，拒毫不合理的需求。最好和產品經理達成一個共識，若因PRD的需求變更，則會根據實際狀況從新排期。有代價，有反思，有利於督促雙方在編寫PRD、評審的階段就開始認真對待，且定義好完成需求的標準。

研發管理

打開昨天沒關機的電腦屏幕，找到本身喜歡的姿式，或穿着格子襯衫、棉拖鞋，或套着護頸枕，或帶着耳機聽音樂，而後就開始搬磚了~~

倉庫管理

爲了規範代碼倉庫，使得版本的演進保持簡潔，主幹清晰，所以得遵循一些規則，避免因爲維護困難形成的錯誤版本發佈等問題。

分支要求：

• 每一個需求必須新開一個本地分支，並備註好需求描述。
• 每一個分支只作一個需求，切勿需求交叉修改。
• 合併後或無用的分支需當即刪除，若是有修改，再從新拉一個新分支。
• 約束命名規則，如採起master、dev、feat、release、hotfix命名方式。

提交commit要求：

• 保證commit歷史記錄的整潔，要求提交的代碼粒度要小， 儘可能保證這個 commit只作一件事情，不然很難描述清楚。
• 約定commit提交規範，如 Angular 團隊的規範<type>(<scope>): <subject>，且利用commitlint工具約束一些格式，同時避免使用-n強制提交。

有分支就有合併，合理選擇適當的時機、適當的方式進行合併，好比merge --no-ff、merge --squash、rebase仍是cherry-pick。你們都知道，變基有風險，且要遵循變基原則：只對還沒有推送或分享給別人的本地修改執行變基操做清理歷史，從不對已推送至別處的提交執行變基操做。

有合併就可能有衝突。若是一直存在大量的衝突，說明是分工、組織架構不對，須要減小多人同時改動同一份代碼的概率。如遇到衝突，可採起如下措施：

• 下降合併分支衝突的數量，好比先合併少衝突的分支，再合併衝突多的分支。
• 熟悉Git操做，適當藉助可視化合並工做。
• 合併後的代碼檢查，讓代碼實際運行一遍。
• 若是衝突的不是本身負責的代碼，讓具體負責人來參與代碼合併。

代碼管理

• 邏輯必定要清晰，考慮周全。不要只考慮普通狀況，還要考慮什麼狀況會出錯，失敗瞭如何處理，總之，多維度去思考。
• 當第二次編寫相同的代碼時，是提取成組件的正確時機。對於大項目，第三次才提取，將會加強執行的阻力。
• 必定要多寫註釋，解釋代碼的意圖和及其緣由，再次回頭看的時候，你也會十分感激本身，效率往上蹭。
• 若是函數或方法超過 30 行代碼，考慮優化它，可用工具好比vscode的插件CodeMetrics輔助提示解決，心中要有一把尺子時刻鞭策本身，凡事得過本身那一關。
• 看到問題，即便暫時不能解決，必定要以某種方式把問題拋出來，否則容易遺忘在某個角落。固然，能解決就當場解決，再次拾起的時間、人力代價也是很高的。

風險管理

即便當心再當心，意外老是會在某一刻發生。因此咱們要時刻控制，下降需求變動、項目延期的風險，應用積累的經驗和專業知識來預測什麼時候會出現風險，以及如何採起有效的應對措施。

風險管理就是如何預防風險：

下面挑幾個重點講講：

• 需求理解偏差、難度誤判、排期緊張，在分析評審階段，能夠必定程度地避免這些問題，固然也和咱們自身的能力有關。本身越沒有把握的事，爭取留些時間以備不測，避免延期的狀況出現。
• 確認有效的溝通方式，及時拋出異常。可在研發郵件中暴露進度是否異常、同步需求變動，是否存在待確認的問題，或者標紅其餘重要信息。
• 認真驗收全部需求，是否遺漏功能。 除了覆蓋功能基本流程邏輯的形式，也能夠從用戶的使用習慣角度去進行場景測試。提及來容易，有時候作起來難，特別是對項目不是特別熟悉，項目又特別複雜的狀況，此時要作的就是，根據代碼影響的範圍來肯定自測的範圍。項目成員可共同維護一份功能列表，以此爲依據進行測試。
• 保證測試分支與將上線的內容一致，也就是說，保證測試分支的乾淨程度。若是測試完畢後才合併分支，可能帶來合併衝突的相似問題。
• 針對大版本，分析上線前的依賴，通知到全部相關人員，最好開一個上線總動員的會議，共同探討上線注意事項、遺留的問題。
• 針對小版本，約定上線的頻次。可每週固定週二或週四發版，且發送上線申請郵件，不可隨意發版。
• 上線先後，指定每人負責某些模塊的測試以及風險管理，有利於心裏產生更大的責任去作好，甚至能夠影響督促別人。
• 報錯異常、性能、服務異常要監控，保證第一時間收到異常並處理。
• 上線後，及時回顧總結項目的成功和失敗之處，剖析各個環節存在的問題，爲之後的項目提供參考。

一個優秀的程序員和一個普通程序員的差異，可能在於理解問題的深度。 「試試重啓一下電腦」，當電腦出現問題的時候，咱們常常會想到這句話。可是有沒有想過，可能失去了一個挖掘問題本質的機會，致使之後問題該出現的時候仍是會出現。 再者，咱們碼程序，修BUG，有時候忽略了質量，而去趕進度，這是得不償失的，最後坑的仍是本身啊。

總結

以上從需求管理、研發管理、風險管理三個大方向，又細分了小方向去講述如何管理好手上的項目。人自己就是一個產品，多個項目的集合。項目就要好心經營，精心管理，由於正是這一件一件的執行的過程，構成了咱們豐富多彩的程序員生活。

經驗有限，或許以上內容有瑕疵，歡迎交流與更正。謝謝你們~

歡迎關注凹凸實驗室公衆號（AOTULabs），不定時推送文章：