創(chuàng)業(yè)項(xiàng)目管理中的難題和解決方法
說(shuō)起創(chuàng)業(yè)，很多人心生向往，可是卻沒有勇氣去做，其實(shí)創(chuàng)業(yè)并沒有那么難，當(dāng)你決定創(chuàng)業(yè)的時(shí)候，你就已經(jīng)領(lǐng)先了一大部分人。那么創(chuàng)業(yè)項(xiàng)目中的難點(diǎn)有哪些呢？下面由小編與大家分享，希望你們喜歡!歡迎閱讀!
說(shuō)起創(chuàng)業(yè)公司，在創(chuàng)業(yè)初期面臨的一個(gè)比較大的痛點(diǎn)，莫過于如何實(shí)現(xiàn)高效低成本的項(xiàng)目管理模式 – 小步快跑、快速迭代?
如何將研發(fā)團(tuán)隊(duì)有效組織起來(lái)，在可控、可視化的范圍類進(jìn)行產(chǎn)品版本迭代更新?
現(xiàn)如今，大多數(shù)互聯(lián)網(wǎng)創(chuàng)業(yè)公司都追崇者敏捷開發(fā)的思路，甚至很多成熟型大公司都沿用這種開發(fā)管理模式。
敏捷開發(fā)是一種以人為核心、迭代、循序漸進(jìn)的開發(fā)方法。“ Fix time, Flex Scope”是敏捷迭代的核心理念。
在創(chuàng)業(yè)公司，很多創(chuàng)業(yè)者初期在項(xiàng)目管理上都使用任務(wù)看板、每日站會(huì)、計(jì)劃紙牌等手段進(jìn)行項(xiàng)目管理，這也是比較常見的項(xiàng)目管理手段。
因?yàn)檫@種方式會(huì)更加便捷，沒有“套路”，能讓人一目了然、快速看到現(xiàn)在在發(fā)生什么，未來(lái)將要發(fā)生什么。
但是這里會(huì)存在以下幾個(gè)難題：
人工線下操作、記錄粘貼耗費(fèi)時(shí)間和精力;
修改刪除麻煩，不方便隨時(shí)更新;
歷史記錄看不到，無(wú)法回顧歷史數(shù)據(jù);
子任務(wù)拆分不方便，拆分后無(wú)法修改;
對(duì)人員管理不便，隨著團(tuán)隊(duì)擴(kuò)張，操作越來(lái)越困難。
我們?cè)趧?chuàng)業(yè)道路上是如何做的呢?
最近兩年在創(chuàng)業(yè)的道路上，經(jīng)歷了從0到1的團(tuán)隊(duì)搭建，直到研發(fā)團(tuán)隊(duì)超過40人，包括產(chǎn)品、設(shè)計(jì)、研發(fā)、測(cè)試。整個(gè)研發(fā)團(tuán)隊(duì)按照一個(gè)項(xiàng)目的節(jié)奏跑自己的產(chǎn)品，曾經(jīng)也拆分過小項(xiàng)目組跑其他項(xiàng)目。
不論是大項(xiàng)目組跑也好，小項(xiàng)目組跑也好，都是以產(chǎn)品為核心導(dǎo)向進(jìn)行功能迭代開發(fā)。
40多人都在一個(gè)辦公區(qū)域(基本不存在異地溝通問題)，整個(gè)項(xiàng)目采用敏捷開發(fā)、版本迭代的過程在跑，產(chǎn)品版本迭代將近30次，基本保持每1-2周一次迭代的過程。
雖然跑的很快，但開始我們也存在一些問題創(chuàng)業(yè)公司共同的項(xiàng)目管理問題。
整個(gè)產(chǎn)品分為android/ios/網(wǎng)頁(yè)端/PC端等 多系統(tǒng)多平臺(tái)。但后臺(tái)人員是公用的，基本是1對(duì)多的關(guān)系。
這種多終端協(xié)作開發(fā)的方式需要一套成熟的項(xiàng)目流程進(jìn)行管理，整個(gè)團(tuán)隊(duì)也嘗試過用任務(wù)看板等線下的方式進(jìn)行項(xiàng)目研發(fā)管理。然而依然會(huì)碰到下面幾個(gè)問題：
耗費(fèi)時(shí)間和精力：最初大家還是愿意接受線下手工的方式寫字操作各自任務(wù)記錄，后面每人每日都要花費(fèi)大量時(shí)間手寫任務(wù)列表，進(jìn)行卡片粘貼。到最后整個(gè)團(tuán)隊(duì)都覺得這樣寫起來(lái)很麻煩，逐漸放棄了手動(dòng)寫的過程，轉(zhuǎn)而進(jìn)入線上工具的管理。
更新刪除麻煩：團(tuán)隊(duì)每個(gè)人每天都需要對(duì)今天完成的任務(wù)進(jìn)行更新，多數(shù)時(shí)候當(dāng)大家拿起筆去更新時(shí)重寫內(nèi)容時(shí)就開始愁苦。寫了一天代碼要下班了還得重新寫字更新今日任務(wù)，尤其碰到需要?jiǎng)h除重新的需求任務(wù)更是崩潰。
歷史記錄找不到：每天只能看到當(dāng)天完成了什么，昨天完成了什么。當(dāng)整張墻貼的密密麻麻時(shí)，想找一個(gè)人任務(wù)時(shí)，眼睛都要瞅半天。此時(shí)大家真想有個(gè)“搜索”功能。尤其在每期迭代結(jié)束后，統(tǒng)計(jì)每個(gè)人任務(wù)進(jìn)度時(shí)，簡(jiǎn)直要崩潰。此時(shí)多希望有個(gè)工具能幫我做這件事。
子任務(wù)拆分不方便：產(chǎn)品需求永遠(yuǎn)都會(huì)拆分子任務(wù)，研發(fā)在開發(fā)時(shí)也需要拆分更細(xì)的子任務(wù)。此時(shí)自己用人工的方法來(lái)做就顯得特別麻煩，尤其拆好的子任務(wù)要做拆分修改時(shí)，更是麻煩。
人員管理麻煩：我們當(dāng)初整個(gè)看板名字是固定的，隨著后續(xù)有新同事進(jìn)來(lái)，舊同事離開，整個(gè)看板都需要更新。這時(shí)就需要把看板上的所有任務(wù)全部清除后再重新布局。
后面嘗試轉(zhuǎn)移到線上工具管理后，整個(gè)研發(fā)團(tuán)隊(duì)的迭代節(jié)奏明顯加快許多，原先將近兩周才完成的迭代、現(xiàn)在相同任務(wù)量縮短到一周。每日晨會(huì)、站會(huì)時(shí)間也由半小時(shí)縮短到15分鐘。研發(fā)團(tuán)隊(duì)每日下班的時(shí)由原先花費(fèi)將近10分鐘更新今日任務(wù)的時(shí)間，縮短至1-2分鐘搞定下班回家。
從這個(gè)現(xiàn)象可以看出：一個(gè)有效的工具能幫助研發(fā)團(tuán)隊(duì)提高效率。
在產(chǎn)品迭代流程方面，我們采用周期的研發(fā)節(jié)奏，整個(gè)產(chǎn)品研發(fā)的迭代順序大致是 需求收集 – 需求分析 – 功能策劃 – 原型設(shè)計(jì) – 需求評(píng)審排期 – 開發(fā)階段 – 測(cè)試階段 – 上線階段，這里實(shí)現(xiàn)一個(gè)完整的迭代。
對(duì)項(xiàng)目時(shí)間管理，本來(lái)采取的是線下excel表格管理，后面也逐漸轉(zhuǎn)移線上工具化管理。
下面就詳細(xì)講解下 在產(chǎn)品迭代項(xiàng)目的每個(gè)階段我們都做了什么。
需求收集階段
產(chǎn)品部門有自己的需求收集和分析方法，我們會(huì)在建立一個(gè)“需求池 ”，產(chǎn)品會(huì)將收集來(lái)的各方面需求收錄到池子里。
需求池的需求主要來(lái)源于市場(chǎng)、用戶、競(jìng)品、老板、產(chǎn)品經(jīng)理。我們會(huì)用線上工具將需求進(jìn)行分類管理，比如APP端需求、運(yùn)營(yíng)需求、網(wǎng)頁(yè)端需求等等。并定期對(duì)需求池中的需求進(jìn)行合并刪減。
在需求收集階段，產(chǎn)品部會(huì)和運(yùn)營(yíng)、市場(chǎng)、商務(wù)等同事進(jìn)行詳細(xì)溝通，確保了解每一個(gè)需求的目的和意義。
需求分析階段
對(duì)建立的“需求池”，產(chǎn)品對(duì)定期進(jìn)行評(píng)估，評(píng)估也是基于產(chǎn)品內(nèi)部的討論，在討論前一定要確保了解每一個(gè)需求背景和意義，不要一個(gè)人拍腦袋把需求拍出來(lái)。
我們崇尚以產(chǎn)品為公司核心導(dǎo)向，所以產(chǎn)品經(jīng)歷的決定權(quán)很重要，直接影響公司戰(zhàn)略走向。所以對(duì)于需求池的需求進(jìn)行詳細(xì)分析時(shí)，一定多基于用戶、市場(chǎng)和公司角度出發(fā)。
對(duì)需求池的需求分析主要做兩件事：
整理需求池內(nèi)容，從優(yōu)先級(jí)和重要性兩個(gè)緯度進(jìn)行產(chǎn)品功能篩選。
確定需求池優(yōu)先級(jí)和重要性后，進(jìn)行需求標(biāo)記，創(chuàng)建新迭代并關(guān)聯(lián)需求。
確定要做的需求后，就需要開始細(xì)化需求。這時(shí)候就考驗(yàn)產(chǎn)品經(jīng)理的功底了。
功能策劃階段
在確定要做的需求后，為了保證需求在研發(fā)階段的完整性和可分工，需要在功能策劃階段就要對(duì)產(chǎn)品需求進(jìn)行模塊拆分和任務(wù)拆分;確保需求的顆粒度與研發(fā)時(shí)間評(píng)審的模塊一致，如果不知道怎么拆分，需要提前與研發(fā)同學(xué)溝通。
在任務(wù)拆分后，為了保證及時(shí)同步給研發(fā)同事，需要將子任務(wù)先在線上工具關(guān)聯(lián)到迭代，目的主要有兩個(gè)：
可以讓研發(fā)同時(shí)知道下一期功能范圍和模塊，提前進(jìn)行技術(shù)框架搭建或技術(shù)預(yù)研。
方便產(chǎn)品同事(多人負(fù)責(zé)一個(gè)模塊)的協(xié)作設(shè)計(jì)。
在線上工具上，可以對(duì)需求進(jìn)行關(guān)聯(lián)，比如父子關(guān)系，方便連續(xù)查找，樹形結(jié)構(gòu)更容易一目了然。
原型設(shè)計(jì)階段
原型設(shè)計(jì)階段最難管理的是版本問題，這里包括兩類文件的版本管理。
產(chǎn)品經(jīng)理的原型稿件
設(shè)計(jì)師的高保真設(shè)計(jì)稿
首先，原型稿修改的次數(shù)遠(yuǎn)遠(yuǎn)會(huì)大于設(shè)計(jì)稿，主要因?yàn)橐恍┬枨髸?huì)在評(píng)審后或者開發(fā)中才會(huì)發(fā)現(xiàn)問題，修改或者補(bǔ)充的。再者，我們的創(chuàng)業(yè)公司原型稿上大都有交互說(shuō)明一起的，一般修改/補(bǔ)充文字說(shuō)明比較多。而且原型稿的使用對(duì)象更多是研發(fā)和測(cè)試同學(xué)，所以每一次版本記錄和修改后同步都是巨大的工作量。
做好的方法是建立統(tǒng)一的svn或線上管理工具，如果有修改可以實(shí)時(shí)同步。
設(shè)計(jì)稿也是類似，一般設(shè)計(jì)稿改動(dòng)的頻率較小，但我們當(dāng)時(shí)為了保持同步也會(huì)統(tǒng)一以版本命名，上傳到在線管理工具上，統(tǒng)一管理。確保信息同步及時(shí)，研發(fā)過程中不至于使用版本不同而導(dǎo)致提測(cè)是幾個(gè)端的功能效果不同。
需求評(píng)審排期
需求評(píng)審我們一般會(huì)有3次評(píng)審，之前有過兩次，但發(fā)現(xiàn)在開發(fā)時(shí)存在很多重復(fù)溝通，很多需求研發(fā)同事都沒有搞明白。
分析原因主要是需求評(píng)審會(huì)上時(shí)間短，很難短時(shí)間就搞懂所有邏輯。所以后面換成了3次，添加了一次“預(yù)評(píng)審會(huì)”。
在第一次“預(yù)評(píng)審會(huì)”上，不討論需求細(xì)節(jié)，只討論框架和流程。讓大家知道下個(gè)迭代要做什么，先在腦海中有概念。
一般預(yù)評(píng)審會(huì)的時(shí)間會(huì)在上個(gè)迭代的測(cè)試階段，這樣在距離這個(gè)迭代結(jié)束的下次評(píng)審會(huì)前，大家有時(shí)間提前帶著框架和流程去熟悉下需求細(xì)節(jié)，這樣就可以帶著問題進(jìn)行第二次需求評(píng)審會(huì)評(píng)審了。
同時(shí)也可以在這個(gè)評(píng)審會(huì)上遇到一些技術(shù)改動(dòng)比較大的問題，或者技術(shù)難點(diǎn)提前周知產(chǎn)品，評(píng)估看是否要對(duì)需求進(jìn)行調(diào)整。
第二次評(píng)審會(huì)上，屬于正式評(píng)審，會(huì)把產(chǎn)品需求從每個(gè)細(xì)節(jié)進(jìn)行一次評(píng)審。每個(gè)人都帶著問題來(lái)聽，沒問題的地方快速過，有問題的地方著重討論確定的方案，這樣就節(jié)省大量時(shí)間。
因?yàn)槎际蔷€上需求管理，遇到問題直接當(dāng)場(chǎng)標(biāo)記，會(huì)議后針對(duì)標(biāo)記的地方進(jìn)行修改。有記錄，而且還不會(huì)遺漏。
第三次評(píng)審會(huì)，主要對(duì)第二次需要修改的地方過一遍，順便加深研發(fā)同學(xué)對(duì)需求的理解程度。一般第三次評(píng)審會(huì)會(huì)在第二次評(píng)審會(huì)的第二天。我們一般選擇第二次在前一天下午，第三次在第二天上午。利用晚上的時(shí)間修改需求，這樣就可以節(jié)省項(xiàng)目時(shí)間。
緊接著就是第二天下午的項(xiàng)目排期了，會(huì)直接在線上工具已經(jīng)拆分好的子任務(wù)上進(jìn)行人員分配，包括開發(fā)人員、測(cè)試人員，之后進(jìn)行開發(fā)周期的安排。
在線上管理的目的是：分配好人員后，大家就能自己登錄后看到負(fù)責(zé)的任務(wù)，同時(shí)系統(tǒng)也會(huì)自動(dòng)計(jì)算出開發(fā)周期。
開發(fā)階段
開發(fā)人員按照每個(gè)子任務(wù)的排期時(shí)間，在每個(gè)需求的時(shí)間節(jié)點(diǎn)前完成開發(fā)即可。
在開發(fā)周期內(nèi)會(huì)安排幾種會(huì)議：
每日晨會(huì)：每天早上全員參加，圍繞 昨天進(jìn)度，今日安排，遇到問題 三個(gè)話題展開。每人大約幾十秒時(shí)間，不討論詳細(xì)解決方案。遇到問題的同事或者需要跟xx對(duì)其的人在晨會(huì)后 以小組的形式單獨(dú)詳細(xì)討論。晨會(huì)的目的是做到明確每個(gè)人的安排，同步及知道要解決的問題。
每周例會(huì)：每周的例會(huì)一般安排在周五下午。1個(gè)小時(shí)左右，主要同步項(xiàng)目整體進(jìn)度，集中解決規(guī)則及制度性的問題。
臨時(shí)會(huì)議：一般遇到開發(fā)過程中的重大問題，需要即可解決的，才會(huì)組織臨時(shí)會(huì)議。一般是問題的干系人及老大們參加。
分享會(huì)議：每周會(huì)安排一次項(xiàng)目成員的分享會(huì)，由一個(gè)人準(zhǔn)備，分享自己的所聞所感。建立團(tuán)隊(duì)間樂于分享的友好氛圍。
開發(fā)階段，會(huì)項(xiàng)目的管理主要是線上工具，同步及溝通的工具一般都是線上管理平臺(tái)及在線聊天工具。因?yàn)槲覀兌荚谝黄疝k公，遇到問題吼一聲，人就過去了。
測(cè)試階段
測(cè)試同事會(huì)提前根據(jù)需求編寫測(cè)試用例，測(cè)試用例也會(huì)在開發(fā)前進(jìn)行評(píng)審。測(cè)試用例會(huì)更新到線上工具，讓每個(gè)人都能看到。測(cè)試時(shí)也會(huì)根據(jù)評(píng)審的用例進(jìn)行，防止帶入主觀判斷。碰到的測(cè)試問題也會(huì)自動(dòng)提交到bug池，關(guān)聯(lián)給對(duì)應(yīng)的開發(fā)人員，確保不遺漏bug修改。
因?yàn)閯?chuàng)業(yè)公司測(cè)試人力少，我們一般都是全員找bug，可以設(shè)置一些有獎(jiǎng)活動(dòng)。比如誰(shuí)找的bug多，誰(shuí)就可以獲得獎(jiǎng)勵(lì)。
上線階段
當(dāng)所有任務(wù)測(cè)試 完成后，即可上線。上線前產(chǎn)品、運(yùn)營(yíng)都需要列出對(duì)應(yīng)的負(fù)責(zé)內(nèi)容。建立checklist，逐一檢查是否有遺漏問題。
一般版本是否上線會(huì)由測(cè)試郵件發(fā)布測(cè)試質(zhì)量報(bào)告，并提出是否可以上線的建議，產(chǎn)品會(huì)根據(jù)郵件反饋進(jìn)行判斷是否可以上線。這樣既有了雙保險(xiǎn)，由能一封郵件就完成上線同步工作，提高上線效率。
除了研發(fā)團(tuán)隊(duì)外，公司還將運(yùn)營(yíng)和商務(wù)也劃歸到項(xiàng)目中統(tǒng)一管理。為了讓各部門信息互相同步，讓技術(shù)同學(xué)了解業(yè)務(wù)幫助他們更好基于業(yè)務(wù)層面進(jìn)行開發(fā)，讓業(yè)務(wù)同學(xué)更了解技術(shù)難處，能提出更加合理的需求，用開發(fā)的語(yǔ)言跟開發(fā)同事溝通。
以上是從創(chuàng)業(yè)經(jīng)歷的實(shí)戰(zhàn)項(xiàng)目總結(jié)出來(lái)的創(chuàng)業(yè)公司項(xiàng)目管理流程，并不一定適用于每一家創(chuàng)業(yè)公司，但其中一些方法不論是大公司還是小公司都可以嘗試使用。
相關(guān)文章：
1.自己創(chuàng)業(yè)的6個(gè)項(xiàng)目
2.五個(gè)精選白手創(chuàng)業(yè)項(xiàng)目
3.創(chuàng)業(yè)找項(xiàng)目的八種辦法