編者有言：帶人做專案是個容易出力不討好的活，面臨不少風險，卻很難在朝夕間培養得力助手。那麼怎樣從一開始就明確規避專案風向，帶著新人養成最佳習慣？也許本文會給你一些靈感。
專案：在既定的資源和要求的約束條件下，為實現某種目的而相互聯絡的一次性工作。
專案成功的三個要素：
1、必勝的信念
2、正確的資訊同步
3、可靠的人力
本文將會針對專案風險出現的幾方面來逐一進行討論。
一、資訊同步
尤其是跟外部團隊合作時，資訊同步是重中之重。
明確整體專案的目標，清楚自己所在的細分專案在整體專案中所處的環節和作用，以及同其他團隊的協同依賴關係。在這裡需要向對外的介面人了解整體專案的完整流程，而且一定要跟對方專案的介面人完全對一遍專案整體流程，讓對方明白我知道整體專案流程目標和自己所在環節和作用。
溝通專案流程時要保證產品、技術（前端、後端）、內外介面人都在場，這可以避免出現缺失某個環節導致的實現問題。
二、明確需求
明確需求在專案正式開始之前是非常必要的一步。開發以及測試需要對產品功能有乙個全面的了解和時間上的風險評估。
這一方面需要產品同學給出乙個詳細的產品流程、原型圖以及需求文件 ，同時需要拉上相關團隊負責人、以及技術同學進行需求評審 。
碰到過幾次產品的需求不明確結果專案進行**現問題，需要產品重新梳理相關模組邏輯，有很大的專案延期風險。
同時產品的需求受到多方面的因素影響，比如時間、歷史包袱等因素，肯定會存在初期有部分細節不明確等問題。這也是專案的漸進明細原則，遇到這種問題要及時反饋，在各方博弈中找到乙個相對適用的平衡點。
三、技術選型
對於從0到1的專案，技術選型是非常關鍵的一步。
做技術選型一定要從業務角度思考，而不是做技術炫技 。要考慮整體業務時間、團隊成員的基本水平、團隊成員對某些技術的熟練程度、技術工具框架的成熟程度、社群的活躍性、業界是否有成功的案例、生態的完善程度以及背後的支撐團隊。
有技術追求的同學在初期技術選型時容易盲目追求新技術工具和框架，從而帶來專案風險。
最早在上一家公司做專案時，業界成熟的框架是react和angular2，不知為什麼負責選型的同學選了還在beta版本的angular2，導致後期公升級迭代出現重大問題。
同時在技術選型確定後，在開發之前一定要規劃技術架構。做架構的基本思路是分層，層內分模組，模組要做到單一職責。各模組之前盡量降低耦合，保持架構的可擴充套件性。
做架構時可以問自己兩點：
這個架構能夠允許多少人同時參與；
這個架構能夠支撐業務發展多長時間。
四、人力盤點
等到專案流程和需求確認完畢後，我們需要梳理專案涉及的整體人員。專案人力盤點需要明確專案所需要的角色、人員、人力投入。建議人力盤點分為以下方面：
外部人員：介面人、具體功能對接人；
內部人員；
對外介面人；
主體業務團隊：產品、視覺、互動、前端、後端、客戶端、qa、專案負責人、研發負責人；
依賴團隊：產品、具體功能對接人；
在專案過程中最怕遇到的是人員的變動。拿個人實際工作來說，遇到過技術人員變動、產品人員變動。發生人員變動往往會給專案帶來極大的風險，人員變動需要做好工作交接，前期的工作（需求文件、產品原型、功能流程）做得越多越規範，對專案帶來的風險越小。
五、專案排期
專案排期階段最重要的是確認專案時間點及人力成本。需要研發負責人梳理需求、拆分需求，明確各方的依賴關係和完成時間點做版本規劃迭代 。
做排期一定要預留足夠的buffer（以月為單位的專案最好預留一周的buffer）以應對可能插入的事情，同時安排好足夠的測試時間。
迭代的時間最好以兩個週為單位進行規劃，每乙個小版本做一次測試，同時在後面的時間安排兩天來修復重要bug，前兩個版本可以只修復嚴重bug，其他bug放到後面專案進行過程中進行修復。
專案排期時一定要了解專案成員的技術水平和能力模型 ，尤其對於新人和剛加入的同學，要給他們預留一定的buffer。曾經帶著一群新人做專案，專案執行過程**現了不少問題：
缺少主動推進意識，佛系；
沒有風險同步意識，自己瞎搞；
描述問題不清晰，溝通成本高；
沒有全域性意識，隨意改介面；
新介面不向後相容，對老版本造成影響。
還有一種專案排期叫倒排 ，時間點確定，必須在規定時間內完成。這種專案往往是時間緊、任務重、壓力大，我在這家公司經常遇到這種情況，這也跟業務發展有關。遇到這種情況，需要及時向上溝通，調整部分功能或者增加人力。當然如果實在不行，只能加班加點硬著頭皮上，這時候往往能看出人的品質。
六、專案啟動會
在專案規劃完成後，專案正式執行前，最好能夠把大家都叫在一起，開乙個統一的專案啟動會。專案啟動會的主要目的是正式認可專案管理計畫 。
專案背景
專案目標
專案參與人員、角色
專案排期
專案規章制度
專案啟動會結束後，發起一封郵件，確認專案正式啟動時間。
七、專案規章制度
專案規章制度主要明確風險同步機制、需求變更機制、獎罰制度和專案站會。
在所有專案中最簡單實用的是專案站會，往往在每個版本迭代進入後半程的時候開始。站會時間最好選在上午時間，每次站會時間在15分鐘左右，站會每個人回答三個問題：昨天做了什麼、遇到問題的解決方式、今天做什麼。同時負責人記錄其中所遇到的問題，跟蹤解決。
八、協調衝突
專案進行過程中難免出現衝突，依賴於被依賴雙方的時間可能存在不吻合情況，或者由於某些事情的插入導致原先時間點出現偏差，這種情況需要專案負責人及時發現問題、協調解決，或者調整排期，或者申請人力，或者調整功能，再或者加個班內部消化。
專案進行過程中需要指定以為專案推進者，負責與外部團隊對接，及時同步需求和發現問題，拉動雙方快速會議，進行決策。尤其在專案接近尾聲暴露出來的問題，可以犧牲一些安全性和規範來及時支援，同時完善長期合理計畫。
實在有高優專案插入，對本專案造成影響，那就按照正常的需求變更和專案延期流程來合理delay 。
九、測試與上線計畫
專案進行到尾期，這時候測試以及修復bug佔主要部分。確定測試環境、預發環境、以及上線回歸流程。要確保這個時間測試和預發不與別的專案衝突，以及與測試同學同步產品邏輯確定測試用例。
同時要盡量保證測試環境與正式環境的一致性，防止專案上線後由於某些環境變數不統一引起的線上bug，造成損失。
上線之前要確定各個環節的上線順序，線上回歸用例，以及緊急回滾策略，尤其是依賴方。站會時要明確各個環節都清楚上線順序，並且傳送郵件通知各團隊相關人員。
十、專案總結
專案上線結束後，還需要進行專案總結，目的是對專案進行整體覆盤，發掘專案中遇到的問題，以及思考解決方案，避免下次發生類似問題。同時對於專案中存在的問題進行排期解決。
專案總結可以按照以下幾個方面來進行：
專案回顧（開發周期、需求、版本、bug修復）；
專案過程反思（需求、排期、溝通、review）；
todo專案。
在專案過程中的成長收穫；
在專案進行過程中遇到的一些問題；
對本次專案的一些建議以及想法。
最後，帶人其實一件出力不討好的事情，領導力是責任和委屈撐起來的。
做專案，還是做產品？
昨天,聽了乙個講座,是 達內外企it 培訓 單位組織的乙個講座 前半期主講現在世界人才就職趨勢,比較 it及其他行業的優劣 一併介紹了一些 it領域的級別評定標準.最後 則是推薦達內集團 做廣告 聽完這個講座,我知道,很高興,主講總監所提到的東西 我都知道 這不就是我們平時學到的東西嗎 我們平時做專...
做專案，還是做產品？
昨天,聽了乙個講座,是 達內外企it培訓 單位組織的乙個講座,前半期主講現在世界人才就職趨勢,比較it及其他行業的優劣,一併介紹了一些it領域的級別評定標準.最後,則是推薦達內集團,做廣告.聽完這個講座,我知道,很高興,主講總監所提到的東西,我都知道,這不就是我們平時學到的東西嗎,我們平時做專案都在...
做人做專案
一專案計畫 1.專案計畫並不是一邊將自己所熟悉的工作內容留給自己一邊不停的說這個工作量太大，讓mm來協助，你要這樣的話我建議你當老總找個秘書。2.開會 開會的目的是解決問題，不是休息，不是乙個會可以開它半天，要講究效率 開會時在討論大家所關心的問題，而不是幾個組員的問題，如果幾個人有問題可以會後來解...