創業專案管理中的難題和解決方法

　　說起創業，很多人心生嚮往，可是卻沒有勇氣去做，其實創業並沒有那麼難，當你決定創業的時候，你就已經領先了一大部分人。那麼創業專案中的難點有哪些呢？下面由小編與大家分享，希望你們喜歡!歡迎閱讀!

　　說起創業公司，在創業初期面臨的一個比較大的痛點，莫過於如何實現高效低成本的專案管理模式 – 小步快跑、快速迭代?

　　如何將研發團隊有效組織起來，在可控、視覺化的範圍類進行產品版本迭代更新?

　　現如今，大多數網際網路創業公司都追崇者敏捷開發的思路，甚至很多成熟型大公司都沿用這種開發管理模式。

　　敏捷開發是一種以人為核心、迭代、循序漸進的開發方法。“ Fix time, Flex Scope”是敏捷迭代的核心理念。

　　在創業公司，很多創業者初期在專案管理上都使用任務看板、每日站會、計劃紙牌等手段進行專案管理，這也是比較常見的專案管理手段。

　　因為這種方式會更加便捷，沒有“套路”，能讓人一目瞭然、快速看到現在在發生什麼，未來將要發生什麼。

　　但是這裡會存在以下幾個難題：

　　人工線下操作、記錄貼上耗費時間和精力;

　　修改刪除麻煩，不方便隨時更新;

　　歷史記錄看不到，無法回顧歷史資料;

　　子任務拆分不方便，拆分後無法修改;

　　對人員管理不便，隨著團隊擴張，操作越來越困難。

　　我們在創業道路上是如何做的呢?

　　最近兩年在創業的道路上，經歷了從0到1的團隊搭建，直到研發團隊超過40人，包括產品、設計、研發、測試。整個研發團隊按照一個專案的節奏跑自己的產品，曾經也拆分過小專案組跑其他專案。

　　不論是大專案組跑也好，小專案組跑也好，都是以產品為核心導向進行功能迭代開發。

　　40多人都在一個辦公區域基本不存在異地溝通問題，整個專案採用敏捷開發、版本迭代的過程在跑，產品版本迭代將近30次，基本保持每1-2週一次迭代的過程。

　　雖然跑的很快，但開始我們也存在一些問題創業公司共同的專案管理問題。

　　整個產品分為android/ios/網頁端/PC端等 多系統多平臺。但後臺人員是公用的，基本是1對多的關係。

　　這種多終端協作開發的方式需要一套成熟的專案流程進行管理，整個團隊也嘗試過用任務看板等線下的方式進行專案研發管理。然而依然會碰到下面幾個問題：

　　耗費時間和精力：最初大家還是願意接受線下手工的方式寫字操作各自任務記錄，後面每人每日都要花費大量時間手寫任務列表，進行卡片貼上。到最後整個團隊都覺得這樣寫起來很麻煩，逐漸放棄了手動寫的過程，轉而進入線上工具的管理。

　　更新刪除麻煩：團隊每個人每天都需要對今天完成的任務進行更新，多數時候當大家拿起筆去更新時重寫內容時就開始愁苦。寫了一天程式碼要下班了還得重新寫字更新今日任務，尤其碰到需要刪除重新的需求任務更是崩潰。

　　歷史記錄找不到：每天只能看到當天完成了什麼，昨天完成了什麼。當整張牆貼的密密麻麻時，想找一個人任務時，眼睛都要瞅半天。此時大家真想有個“搜尋”功能。尤其在每期迭代結束後，統計每個人任務進度時，簡直要崩潰。此時多希望有個工具能幫我做這件事。

　　子任務拆分不方便：產品需求永遠都會拆分子任務，研發在開發時也需要拆分更細的子任務。此時自己用人工的方法來做就顯得特別麻煩，尤其拆好的子任務要做拆分修改時，更是麻煩。

　　人員管理麻煩：我們當初整個看板名字是固定的，隨著後續有新同事進來，舊同事離開，整個看板都需要更新。這時就需要把看板上的所有任務全部清除後再重新佈局。

　　後面嘗試轉移到線上工具管理後，整個研發團隊的迭代節奏明顯加快許多，原先將近兩週才完成的迭代、現在相同任務量縮短到一週。每日晨會、站會時間也由半小時縮短到15分鐘。研發團隊每日下班的時由原先花費將近10分鐘更新今日任務的時間，縮短至1-2分鐘搞定下班回家。

　　從這個現象可以看出：一個有效的工具能幫助研發團隊提高效率。

　　在產品迭代流程方面，我們採用週期的研發節奏，整個產品研發的迭代順序大致是 需求收集 – 需求分析 – 功能策劃 – 原型設計 – 需求評審排期 – 開發階段 – 測試階段 – 上線階段，這裡實現一個完整的迭代。

　　對專案時間管理，本來採取的是線下excel表格管理，後面也逐漸轉移線上工具化管理。

　　下面就詳細講解下 在產品迭代專案的每個階段我們都做了什麼。

　　需求收集階段

　　產品部門有自己的需求收集和分析方法，我們會在建立一個“需求池 ”，產品會將收集來的各方面需求收錄到池子裡。

　　需求池的需求主要來源於市場、使用者、競品、老闆、產品經理。我們會用線上工具將需求進行分類管理，比如APP端需求、運營需求、網頁端需求等等。並定期對需求池中的需求進行合併刪減。

　　在需求收集階段，產品部會和運營、市場、商務等同事進行詳細溝通，確保瞭解每一個需求的目的和意義。

　　需求分析階段

　　對建立的“需求池”，產品對定期進行評估，評估也是基於產品內部的討論，在討論前一定要確保瞭解每一個需求背景和意義，不要一個人拍腦袋把需求拍出來。

　　我們崇尚以產品為公司核心導向，所以產品經歷的決定權很重要，直接影響公司戰略走向。所以對於需求池的需求進行詳細分析時，一定多基於使用者、市場和公司角度出發。

　　對需求池的需求分析主要做兩件事：

　　整理需求池內容，從優先順序和重要性兩個緯度進行產品功能篩選。

　　確定需求池優先順序和重要性後，進行需求標記，建立新迭代並關聯需求。

　　確定要做的需求後，就需要開始細化需求。這時候就考驗產品經理的功底了。

　　功能策劃階段

　　在確定要做的需求後，為了保證需求在研發階段的完整性和可分工，需要在功能策劃階段就要對產品需求進行模組拆分和任務拆分;確保需求的顆粒度與研發時間評審的模組一致，如果不知道怎麼拆分，需要提前與研發同學溝通。

　　在任務拆分後，為了保證及時同步給研發同事，需要將子任務先在線上工具關聯到迭代，目的主要有兩個：

　　可以讓研發同時知道下一期功能範圍和模組，提前進行技術框架搭建或技術預研。

　　方便產品同事多人負責一個模組的協作設計。

　　在線上工具上，可以對需求進行關聯，比如父子關係，方便連續查詢，樹形結構更容易一目瞭然。

　　原型設計階段

　　原型設計階段最難管理的是版本問題，這裡包括兩類檔案的版本管理。

　　產品經理的原型稿件

　　設計師的高保真設計稿

　　首先，原型稿修改的次數遠遠會大於設計稿，主要因為一些需求會在評審後或者開發中才會發現問題，修改或者補充的。再者，我們的創業公司原型稿上大都有互動說明一起的，一般修改/補充文字說明比較多。而且原型稿的使用物件更多是研發和測試同學，所以每一次版本記錄和修改後同步都是巨大的工作量。

　　做好的方法是建立統一的svn或線上管理工具，如果有修改可以實時同步。

　　設計稿也是類似，一般設計稿改動的頻率較小，但我們當時為了保持同步也會統一以版本命名，上傳到線上管理工具上，統一管理。確保資訊同步及時，研發過程中不至於使用版本不同而導致提測是幾個端的功能效果不同。

　　需求評審排期

　　需求評審我們一般會有3次評審，之前有過兩次，但發現在開發時存在很多重複溝通，很多需求研發同事都沒有搞明白。

　　分析原因主要是需求評審會上時間短，很難短時間就搞懂所有邏輯。所以後面換成了3次，添加了一次“預評審會”。

　　在第一次“預評審會”上，不討論需求細節，只討論框架和流程。讓大家知道下個迭代要做什麼，先在腦海中有概念。

　　一般預評審會的時間會在上個迭代的測試階段，這樣在距離這個迭代結束的下次評審會前，大家有時間提前帶著框架和流程去熟悉下需求細節，這樣就可以帶著問題進行第二次需求評審會評審了。

　　同時也可以在這個評審會上遇到一些技術改動比較大的問題，或者技術難點提前周知產品，評估看是否要對需求進行調整。

　　第二次評審會上，屬於正式評審，會把產品需求從每個細節進行一次評審。每個人都帶著問題來聽，沒問題的地方快速過，有問題的地方著重討論確定的方案，這樣就節省大量時間。

　　因為都是線上需求管理，遇到問題直接當場標記，會議後針對標記的地方進行修改。有記錄，而且還不會遺漏。

　　第三次評審會，主要對第二次需要修改的地方過一遍，順便加深研發同學對需求的理解程度。一般第三次評審會會在第二次評審會的第二天。我們一般選擇第二次在前一天下午，第三次在第二天上午。利用晚上的時間修改需求，這樣就可以節省專案時間。

　　緊接著就是第二天下午的專案排期了，會直接在線上工具已經拆分好的子任務上進行人員分配，包括開發人員、測試人員，之後進行開發週期的安排。

　　在線上管理的目的是：分配好人員後，大家就能自己登入後看到負責的任務，同時系統也會自動計算出開發週期。

　　開發階段

　　開發人員按照每個子任務的排期時間，在每個需求的時間節點前完成開發即可。

　　在開發週期內會安排幾種會議：

　　每日晨會：每天早上全員參加，圍繞 昨天進度，今日安排，遇到問題 三個話題展開。每人大約幾十秒時間，不討論詳細解決方案。遇到問題的同事或者需要跟xx對其的人在晨會後 以小組的形式單獨詳細討論。晨會的目的是做到明確每個人的安排，同步及知道要解決的問題。

　　每週例會：每週的例會一般安排在週五下午。1個小時左右，主要同步專案整體進度，集中解決規則及制度性的問題。

　　臨時會議：一般遇到開發過程中的重大問題，需要即可解決的，才會組織臨時會議。一般是問題的干係人及老大們參加。

　　分享會議：每週會安排一次專案成員的分享會，由一個人準備，分享自己的所聞所感。建立團隊間樂於分享的友好氛圍。

　　開發階段，會專案的管理主要是線上工具，同步及溝通的工具一般都是線上管理平臺及線上聊天工具。因為我們都在一起辦公，遇到問題吼一聲，人就過去了。

　　測試階段

　　測試同事會提前根據需求編寫測試用例，測試用例也會在開發前進行評審。測試用例會更新到線上工具，讓每個人都能看到。測試時也會根據評審的用例進行，防止帶入主觀判斷。碰到的測試問題也會自動提交到bug池，關聯給對應的開發人員，確保不遺漏bug修改。

　　因為創業公司測試人力少，我們一般都是全員找bug，可以設定一些有獎活動。比如誰找的bug多，誰就可以獲得獎勵。

　　上線階段

　　當所有任務測試 完成後，即可上線。上線前產品、運營都需要列出對應的負責內容。建立checklist，逐一檢查是否有遺漏問題。

　　一般版本是否上線會由測試郵件釋出測試質量報告，並提出是否可以上線的建議，產品會根據郵件反饋進行判斷是否可以上線。這樣既有了雙保險，由能一封郵件就完成上線同步工作，提高上線效率。

　　除了研發團隊外，公司還將運營和商務也劃歸到專案中統一管理。為了讓各部門資訊互相同步，讓技術同學瞭解業務幫助他們更好基於業務層面進行開發，讓業務同學更瞭解技術難處，能提出更加合理的需求，用開發的語言跟開發同事溝通。

　　以上是從創業經歷的實戰專案總結出來的創業公司專案管理流程，並不一定適用於每一家創業公司，但其中一些方法不論是大公司還是小公司都可以嘗試使用。