1. 程式人生 > >從0到1帶人做專案

從0到1帶人做專案

專案:在既定的資源和要求的約束條件下,為實現某種目的而相互聯絡的一次性工作。

專案成功的三個要素:

1、必勝的信念

2、正確的資訊同步

3、可靠的人力

專案風險往往在如下幾方面

一、資訊同步

尤其是跟外部團隊合作時,資訊同步是重中之重。明確整體專案的目標,清楚自己所在的細分專案在整體專案中所處的環節和作用,以及同其他團隊的協同依賴關係。在這裡需要向對外的介面人瞭解整體專案的完整流程,而且一定要跟對方專案的介面人完全對一遍專案整體流程,讓對方明白我知道整體專案流程目標和自己所在環節和作用。溝通專案流程時要保證產品、技術(前端、後端)、內外介面人都在場,這可以避免出現缺失某個環節導致的實現問題。

二、明確需求

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

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

三、技術選型

對於從0到1的專案,技術選型是非常關鍵的一步。 做技術選型一定要從業務角度思考而不是做技術炫技

,要考慮整體業務時間、團隊成員的基本水平、團隊成員對某些技術的熟練程度、技術工具框架的成熟程度、社群的活躍性、業界是否有成功的案例、生態的完善程度以及背後的支撐團隊。有技術追求的同學在初期技術選型時容易盲目追求新技術工具和框架,從而帶來專案風險。最早在上一家公司做專案時,業界成熟的框架是React和Angular2,不知為什麼負責選型的同學選了還在beta版本的angular2,導致後期升級迭代出現重大問題。

同時在技術選型確定後,在開發之前一定要 規劃技術架構 。做架構的基本思路是分層,層內分模組,模組要做到單一職責。各模組之前儘量降低耦合,保持架構的可擴充套件性。做架構時可以問自己兩點:

  1. 這個架構能夠允許多少人同時參與
  2. 這個架構能夠支撐業務發展多長時間

四、人力盤點

等到專案流程和需求確認完畢後,我們需要梳理專案涉及的整體人員。專案人力盤點需要明確專案所需要的角色、人員、人力投入。建議人力盤點分為以下方面:

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

在專案過程中最怕遇到的是人員的變動。拿個人實際工作來說,遇到過技術人員變動、產品人員變動。發生人員變動往往會給專案帶來極大的風險,人員變動需要做好工作交接,前期的工作(需求文件、產品原型、功能流程)做得越多越規範,對專案帶來的風險越小。

五、專案排期

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

專案排期時一定要 瞭解專案成員的技術水平和能力模型 ,尤其對於新人和剛加入的同學,要給他們預留一定的buffer。曾經帶著一群新人做專案,專案執行過程中出現了不少問題:

  1. 缺少主動推進意識,佛系
  2. 沒有風險同步意識,自己瞎搞
  3. 描述問題不清晰,溝通成本高
  4. 沒有全域性意識,隨意改介面
  5. 新介面不向後相容,對老版本造成影響

還有一種專案排期叫 倒排 ,時間點確定,必須在規定時間內完成。這種專案往往是時間緊、任務重、壓力大,我在這家公司經常遇到這種情況,這也跟業務發展有關。遇到這種情況,需要及時向上溝通,調整部分功能或者增加人力。當然如果實在不行,只能加班加點硬著頭皮上,這時候往往能看出人的品質。

六、專案啟動會

在專案規劃完成後,專案正式執行前,最好能夠把大家都叫在一起,開一個統一的專案啟動會。專案啟動會的主要目的是 正式認可專案管理計劃 。專案啟動會的參加方包括髮起人、專案成員、各個依賴方、相關leader和老闆。專案啟動會主要介紹以下幾個方面:

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

專案啟動會結束後,發起一封郵件,確認專案正式啟動時間。

七、專案規章制度

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

八、協調衝突

專案進行過程中難免出現衝突,依賴於被依賴雙方的時間可能存在不吻合情況,或者由於某些事情的插入導致原先時間點出現偏差,這種情況需要專案負責人及時發現問題,協調解決,或者調整排期,或者申請人力,或者調整功能,再或者加個班內部消化。

專案進行過程中需要指定以為專案推進者,負責與外部團隊對接,及時同步需求和發現問題,拉動雙方快速會議,進行決策。尤其在專案接近尾聲暴露出來的問題,可以犧牲一些安全性和規範來及時支援,同時完善長期合理計劃。

實在有高優專案插入,對本專案造成影響,那就按照正常的需求變更和專案延期流程來 合理delay

九、測試與上線計劃

專案進行到尾期,這時候測試以及修復bug佔主要部分。確定測試環境、預發環境、以及上線迴歸流程。要確保這個時間測試和預發不與別的專案衝突,以及與測試同學同步產品邏輯確定測試用例。同時要儘量保證測試環境與正式環境的一致性,防止專案上線後由於某些環境變數不統一引起的線上bug,造成損失。

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

十、專案總結

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

專案總結可以按照以下幾個方面來進行:

  1. 專案回顧(開發週期、需求、版本、bug修復)
  2. 專案過程反思(需求、排期、溝通、review)
  3. TODO專案

對於專案參與人員,可以讓大家都參與進來,考慮不限以下幾個方面:

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

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