從0到1帶人作項目

項目：在既定的資源和要求的約束條件下，爲實現某種目的而相互聯繫的一次性工做。

項目成功的三個要素：

一、必勝的信念

二、正確的信息同步

三、可靠的人力

項目風險每每在以下幾方面

1、信息同步

尤爲是跟外部團隊合做時，信息同步是重中之重。明確總體項目的目標，清楚本身所在的細分項目在總體項目中所處的環節和做用，以及同其餘團隊的協同依賴關係。在這裏須要向對外的接口人瞭解總體項目的完整流程，並且必定要跟對方項目的接口人徹底對一遍項目總體流程，讓對方明白我知道總體項目流程目標和本身所在環節和做用。溝通項目流程時要保證產品、技術（前端、後端）、內外接口人都在場，這能夠避免出現缺失某個環節致使的實現問題。

2、明確需求

明確需求在項目正式開始以前是很是必要的一步。開發以及測試須要對產品功能有一個全面的瞭解和時間上的風險評估。這一方面須要產品同窗給出一個詳細的 產品流程、原型圖以及需求文檔 ，同時須要拉上相關團隊負責人、以及技術同窗進行 需求評審 。碰到過幾回產品的需求不明確結果項目進行中出現問題，須要產品從新梳理相關模塊邏輯，有很大的項目延期風險。

同時產品的需求受到多方面的因素影響，好比時間、歷史包袱等因素，確定會存在初期有部分細節不明確等問題。這也是項目的漸進明細原則，遇到這種問題要及時反饋，在各方博弈中找到一個相對適用的平衡點。

3、技術選型

對於從0到1的項目，技術選型是很是關鍵的一步。 作技術選型必定要從業務角度思考而不是作技術炫技 ，要考慮總體業務時間、團隊成員的基本水平、團隊成員對某些技術的熟練程度、技術工具框架的成熟程度、社區的活躍性、業界是否有成功的案例、生態的完善程度以及背後的支撐團隊。有技術追求的同窗在初期技術選型時容易盲目追求新技術工具和框架，從而帶來項目風險。最先在上一家公司作項目時，業界成熟的框架是React和Angular2，不知爲何負責選型的同窗選了還在beta版本的angular2，致使後期升級迭代出現重大問題。

同時在技術選型肯定後，在開發以前必定要 規劃技術架構 。作架構的基本思路是分層，層內分模塊，模塊要作到單一職責。各模塊以前儘可能下降耦合，保持架構的可擴展性。作架構時能夠問本身兩點：

1. 這個架構可以容許多少人同時參與
2. 這個架構可以支撐業務發展多長時間

4、人力盤點

等到項目流程和需求確認完畢後，咱們須要梳理項目涉及的總體人員。項目人力盤點須要明確項目所須要的角色、人員、人力投入。建議人力盤點分爲如下方面：

1. 外部人員：接口人、具體功能對接人
2. 內部人員：
3. 對外接口人
4. 主體業務團隊：產品、視覺、交互、前端、後端、客戶端、QA、項目負責人、研發負責人
5. 依賴團隊：產品、具體功能對接人
6. 其它相關干係人：leader、老闆等

在項目過程當中最怕遇到的是人員的變更。拿我的實際工做來講，遇到過技術人員變更、產品人員變更。發生人員變更每每會給項目帶來極大的風險，人員變更須要作好工做交接，前期的工做（需求文檔、產品原型、功能流程）作得越多越規範，對項目帶來的風險越小。

5、項目排期

項目排期階段最重要的是 確認項目時間點，以及人力成本 。須要研發負責人梳理需求，拆分需求，明確各方的依賴關係和完成時間點作 版本規劃迭代 。作排期必定要預留足夠的buffer（以月爲單位的項目最好預留一週的buffer）以應對可能插入的事情，同時安排好足夠的測試時間。迭代的時間最好以兩個周爲單位進行規劃，每個小版本作一次測試，同時在後面的時間安排兩天來修復重要bug，前兩個版本能夠只修復嚴重bug，其餘bug放到後面項目進行過程當中進行修復。

項目排期時必定要 瞭解項目成員的技術水平和能力模型 ，尤爲對於新人和剛加入的同窗，要給他們預留必定的buffer。曾經帶着一羣新人作項目，項目執行過程當中出現了很多問題：

1. 缺乏主動推動意識，佛系
2. 沒有風險同步意識，本身瞎搞
3. 描述問題不清晰，溝通成本高
4. 沒有全局意識，隨意改接口
5. 新接口不向後兼容，對老版本形成影響

還有一種項目排期叫 倒排 ，時間點肯定，必須在規定時間內完成。這種項目每每是時間緊、任務重、壓力大，我在這家公司常常遇到這種狀況，這也跟業務發展有關。遇到這種狀況，須要及時向上溝通，調整部分功能或者增長人力。固然若是實在不行，只能加班加點硬着頭皮上，這時候每每能看出人的品質。

6、項目啓動會

在項目規劃完成後，項目正式執行前，最好可以把你們都叫在一塊兒，開一個統一的項目啓動會。項目啓動會的主要目的是 正式承認項目管理計劃 。項目啓動會的參加方包括髮起人、項目成員、各個依賴方、相關leader和老闆。項目啓動會主要介紹如下幾個方面：

1. 項目背景
2. 項目目標
3. 項目參與人員、角色
4. 項目排期
5. 項目規章制度

項目啓動會結束後，發起一封郵件，確認項目正式啓動時間。

7、項目規章制度

項目規章制度主要明確風險同步機制、需求變動機制、獎罰制度和項目站會。在全部項目中最簡單實用的是 項目站會 ，每每在每一個版本迭代進入後半程的時候開始。站會時間最好選在上午時間，每次站會時間在15分鐘左右，站會每一個人回答三個問題：昨天作了什麼、遇到問題的解決方式、今天作什麼。同時負責人記錄其中所遇到的問題，跟蹤解決。

8、協調衝突

項目進行過程當中不免出現衝突，依賴於被依賴雙方的時間可能存在不吻合狀況，或者因爲某些事情的插入致使原先時間點出現誤差，這種狀況須要項目負責人及時發現問題，協調解決，或者調整排期，或者申請人力，或者調整功能，再或者加個班內部消化。

項目進行過程當中須要指定覺得項目推動者，負責與外部團隊對接，及時同步需求和發現問題，拉動雙方快速會議，進行決策。尤爲在項目接近尾聲暴露出來的問題，能夠犧牲一些安全性和規範來及時支持，同時完善長期合理計劃。

實在有高優項目插入，對本項目形成影響，那就按照正常的需求變動和項目延期流程來 合理delay 。

9、測試與上線計劃

項目進行到尾期，這時候測試以及修復bug佔主要部分。肯定測試環境、預發環境、以及上線迴歸流程。要確保這個時間測試和預發不與別的項目衝突，以及與測試同窗同步產品邏輯肯定測試用例。同時要儘可能保證測試環境與正式環境的一致性，防止項目上線後因爲某些環境變量不統一引發的線上bug，形成損失。

上線以前要 肯定各個環節的上線順序，線上迴歸用例，以及緊急回滾策略 ，尤爲是依賴方。站會時要明確各個環節都清楚上線順序，而且發送郵件通知各團隊相關人員。

10、項目總結

項目上線結束後，還須要進行項目總結，目的是對項目進行總體覆盤，發掘項目中遇到的問題，以及思考解決方案，避免下次發生相似問題。同時對於項目中存在的問題進行排期解決。

項目總結能夠按照如下幾個方面來進行：

1. 項目回顧（開發週期、需求、版本、bug修復）
2. 項目過程反思（需求、排期、溝通、review）
3. TODO項目

對於項目參與人員，可讓你們都參與進來，考慮不限如下幾個方面：

1. 在項目過程當中的成長收穫
2. 在項目進行過程當中遇到的一些問題
3. 對本次項目的一些建議以及想法

最後，帶人其實一件出力不討好的事情，領導力是責任和委屈撐起來的。