建站
咨詢
售后
建站咨詢
新聞中心
15年初，我懷揣著實現(xiàn)一個人生小目標(biāo)的夢想加入到一家初創(chuàng)公司，希冀能見證公司產(chǎn)品從0到1，從1到10，融資從A到C?？墒前肽旰螅m然產(chǎn)品從0到1是有了，但由于運(yùn)營模式的限制，從1到10走的很難，用戶規(guī)模上不去，融資也是沒有影子。我開始焦慮起來，這樣下去，我要當(dāng)上總經(jīng)理，出任CEO，迎娶白富美的人生小目標(biāo)，可是要萎掉的啊。
成都創(chuàng)新互聯(lián)公司-云計算及IDC服務(wù)提供商，涵蓋公有云、IDC機(jī)房租用、四川樂山服務(wù)器托管、等保安全、私有云建設(shè)等企業(yè)級互聯(lián)網(wǎng)基礎(chǔ)服務(wù)，咨詢熱線：18982081108
于是，那時還是程序猿的我，漸漸”多事”起來：
一會跑到產(chǎn)品經(jīng)理那里：
- “我看到一篇某某博客，作者用Axure把需求文檔、產(chǎn)品原型、PRD等等結(jié)合到了一起，這樣不同文檔切換查看就很方便，會節(jié)省大家一些時間，還特顯高大上，我們也試試?”
一會跑到測試那里：
- “這次迭代不僅新增了很多模塊，還換血了不少舊接口。我們要不要來一次集體測試，大家都參與進(jìn)來，對各個模塊進(jìn)行地毯式掃蕩測試，這樣能快速發(fā)現(xiàn)問題，也給你減輕了些負(fù)擔(dān)?”
一會跑到項目經(jīng)理那里：
- “這次迭代中出現(xiàn)了某某問題，之前也發(fā)生過，我們可不可以在迭代結(jié)束后開展一個總結(jié)會議，統(tǒng)計下遇到的問題，是如何解決的，以后好吸取教訓(xùn)?”
- ……
- 因為多事，我后來還學(xué)會用Auxre和墨刀做原型了;下班回家測自己開發(fā)的App，給自己提Bug單;主持一些會議并進(jìn)行紀(jì)要……
- 因為多事，我成了公司加班最多的人，也是微信步數(shù)最多人(經(jīng)常跑堂);
- 因為多事，在項目經(jīng)理離職后，公司沒有招人，而是讓我頂上了。雖然不得不說，當(dāng)時的項目千瘡百孔，是個臟屁股。但是我知道，我的轉(zhuǎn)型是從自己看待項目視角的轉(zhuǎn)變開始的，而不是職責(zé)的轉(zhuǎn)變。所以既然公司給予了認(rèn)可，手臂就可以揮的更開了，屁股再臟，也能擦得干凈。
接手項目后，做的第一件事，就是把我之前思考的項目中存在的問題進(jìn)行了梳理。把那些大坑找出來，填了能立竿見影出效果。
一、使用Git
此前，團(tuán)隊用svn進(jìn)行協(xié)作開發(fā)，最主要問題在于分支的切換合并不方便，以致于實際編碼的時候，大家都只在主干上提代碼，所以開發(fā)階段，主干上的代碼是沒發(fā)隨時打包的。測試要想針對已開發(fā)完成的模塊進(jìn)行提前測試，只能經(jīng)常跑到開發(fā)那問，做到哪里啦?這個功能可以測了嗎?現(xiàn)在可以打個包嗎?導(dǎo)致開發(fā)的工作時常會被打斷，而且即便測試拿到包，也會出現(xiàn)不同開發(fā)給的包是互斥的情況，即A給包有只有A功能，B給的只有B功能，分別測都OK了，最后合到一起又是一坨bug。
為了解決這個問題，我們嘗試用git取代svn，并引入gitflow的協(xié)作方式。效果嘛，用一個字來形容，“爽的結(jié)蓋蓋”。進(jìn)入編碼階段，開發(fā)兄弟會根據(jù)自己實現(xiàn)的功能模塊從develop分支上拉出對應(yīng)的feature分支，如feature-im，feature-moments。一個功能點開發(fā)完成，就可以合并到develop分支上，然后刪掉對應(yīng)的feature分支，接著拉出新feature繼續(xù)開發(fā)。這就保證develop分支上是可以隨時打包的，根據(jù)提交日志，也可以清楚的了解哪些功能是完成了的。測試只要從develop更新代碼，腳本打包，完全可以自給自足了。
二、優(yōu)化估算
估算千萬不能隨意，估算的準(zhǔn)確度直接影響著項目進(jìn)度計劃的安排。那選擇什么估算單位，如何進(jìn)行估算呢?估算單位一般有理想人日，理想人時和故事點數(shù)，估算方式有自下而上估算，專家判斷和撲克估算等。這里不分別展開討論，只介紹下，進(jìn)過實踐調(diào)整，我們團(tuán)隊所選用的最為合適有效的估算方法：故事點數(shù)+專家判斷+公式計算。
我們迭代會出現(xiàn)兩種情形，一是實現(xiàn)固定需求，需要根據(jù)需求估算出完成時間，二是迭代周期確定，需要根據(jù)時間估算能完成多少需求。于是選擇了故事點數(shù)作為估算單位，不僅僅因為故事點數(shù)估算是敏捷推薦的，更重要的是很適用于第二種迭代情形。具體怎么估算呢?以客戶端開發(fā)為例，根據(jù)經(jīng)驗，一個功能模塊的開發(fā)量與包含的界面數(shù)量、接口數(shù)量、數(shù)據(jù)同步方式成一定正比關(guān)系，所以只要找到合適的公式，就能根據(jù)這些因子算出開發(fā)量，即故事點數(shù)。我們先由經(jīng)驗豐富的開發(fā)定義一個參照基準(zhǔn)：
(1)把界面根據(jù)復(fù)雜程度分成了三級，賦予不同數(shù)值：
- 一級最簡單，值為1，像微信的登錄界面，通訊錄列表界面這類;
- 二級值為2，界面稍復(fù)雜點，開發(fā)量大概是一級的2倍;
- 三級為4，像頭條的首頁。通常用到的是這三級，當(dāng)然如果有的界面非常復(fù)雜，在計算的時候可以代入更高的值。
(2)接口數(shù)量直接代入計算。
(3)數(shù)據(jù)同步也根據(jù)復(fù)雜度分了三級，直接從服務(wù)端獲取數(shù)據(jù)展示，與本地?zé)o關(guān)，為一級，定義值為0，展示本地數(shù)據(jù)，和服務(wù)端無關(guān)，為二級，值為1，通過推送方式增量獲取數(shù)據(jù)，本地需要做存儲和同步，則為三級，值為3。
定義好這些基準(zhǔn)后，便有了計算故事點的公式：故事點數(shù)=a*界面總復(fù)雜度+b*接口總數(shù)+c*數(shù)據(jù)同步總復(fù)雜度。a、b、c反應(yīng)的是開發(fā)時間基準(zhǔn)，由經(jīng)驗我們將a取1，b取0.5，c取0.6。所以故事點數(shù)=界面總復(fù)雜度+0.5*接口總數(shù)+0.6*數(shù)據(jù)同步總復(fù)雜度。故事點數(shù)估算是相對估算，體現(xiàn)的是需求的開發(fā)規(guī)模，不是具體的時間，需要乘上系數(shù)才能得到開發(fā)所需時間。同樣的功能給業(yè)務(wù)熟悉，技術(shù)大牛做，乘的系數(shù)可能是0.8，給業(yè)務(wù)不熟，經(jīng)驗不足的新員工做，乘的可能就是1.5。
通過故事點數(shù)，我們還能了解團(tuán)隊的開發(fā)效率，例如分析一個sprint完成的故事點數(shù)，和過去比是多了還是少了?什么原因?是團(tuán)隊狀態(tài)變化了，還是公式不準(zhǔn)確需要調(diào)整。
雖然這種方式?jīng)]有直接估算人日來的直接快速，但能在保證了估算準(zhǔn)確性的同時，反應(yīng)團(tuán)隊的開發(fā)速率和迭代規(guī)模，能更好的幫助項目經(jīng)理把控項目狀態(tài)。團(tuán)隊適應(yīng)后，再也不用煩心因為估算問題帶來的計劃風(fēng)險。
三、強(qiáng)調(diào)需求
需求不等于功能。此前，我們產(chǎn)品的用戶體驗不好，一部分原因在于產(chǎn)品需求沒有正確傳遞給開發(fā)，開發(fā)只知道要做哪些功能，只關(guān)心如何實現(xiàn)功能。似乎只要功能做出來，就等于滿足需求了。
功能是解決方案，需求是其解決的問題。在PRD評審會議討論功能技術(shù)問題前，要先傳達(dá)清除為什么要做這個功能，能帶來哪些用戶價值和公司價值。否則一旦評審時發(fā)現(xiàn)功能在技術(shù)實現(xiàn)上難度較大，開發(fā)往往只會站在力求把功能實現(xiàn)的角度給出曲線救國的其他方案，忽略了用戶體驗，甚至違背需求。好比一個快餓死的人，想要吃東西，你卻讓他先回家洗個澡換身正裝，然后進(jìn)了西餐店點了份甜點。你的方案看似優(yōu)雅，還考慮到了就餐環(huán)境，但實際把人給等死了，就算能堅持到最后，發(fā)現(xiàn)端上的只是一份不夠塞牙縫的甜品，可能他也氣死了。開發(fā)研究的是技術(shù)，討論方案問題時容易在技術(shù)上鉆牛角尖，這就需要項目經(jīng)理產(chǎn)品經(jīng)理具有用戶視角，抓住需求本質(zhì)，引導(dǎo)討論方向。
另外在需求的管理上，做了兩件事，一是重新建立需求池，并注意跟進(jìn)。一開始團(tuán)隊也有需求池，但由于過分強(qiáng)調(diào)溝通，忽略文檔，導(dǎo)致漸漸流于形式，無從追溯產(chǎn)品需求的真實情況。需求池中要記錄需求實現(xiàn)的版本號，對于計劃放到更高版本中實現(xiàn)的需求，一定要在相應(yīng)的迭代中納入計劃評審，不能遺忘。WBS表中，每個Task也要記錄對應(yīng)的需求池中的需求編號，方便追本溯源。二是實施需求凍結(jié)。我們要擁抱變化，但不是允許無休止的變化，無節(jié)操的需求蔓延和朝令夕改的需求變更要禁止，否則會嚴(yán)重影響產(chǎn)品的快速交付。在迭代進(jìn)入編碼階段的2/3時期，會凍結(jié)需求，對于改動較大又不一定能帶來實際價值的變更直接拒絕擁抱。當(dāng)然需求凍結(jié)階段也不是拒絕所有變更，重大變革如蘋果審核機(jī)制改變，客戶明確要求修改方案等等，經(jīng)過評審后然而可以擁抱。
四、規(guī)范會議
會議方面，主要是啟動會議和站會進(jìn)行了開刀。
啟動會議
迭代的啟動，不能是由項目經(jīng)理一聲口頭通知就開始了，哪怕團(tuán)隊就幾個人。一定要有啟動會議，在會議上交待清除迭代目標(biāo)，統(tǒng)一大家對實現(xiàn)需求及其背景的認(rèn)識，避免大家只知道要做什么，卻不知為何做，有什么價值。此外，會議會給人一種儀式感，嚴(yán)肅感，能使團(tuán)隊做好心理準(zhǔn)備正式進(jìn)入新一階段的工作狀態(tài)。
站會
之前，團(tuán)隊的站會時間不固定，有時是連續(xù)3天都舉行，有時是隔了3天才舉行，而且每次時間很隨意，一會早上，一會下午。導(dǎo)致大家沒有例行的習(xí)慣，也常常在工作中途被打斷去參加站會，然后站會成了匯報會，各自交待做了哪些任務(wù)，便趕緊結(jié)束，把屁股挪回椅子上。這樣的站會成了雞肋。所以我把站會固定在了每日早上9點10分，明確站會目標(biāo)是為了跟蹤項目進(jìn)度和問題，同步成員狀態(tài)。會上每個人應(yīng)交待昨天完成的工作;今天計劃做的工作;面臨什么阻礙，需要什么幫助。這樣團(tuán)隊成員形成站會習(xí)慣，每天到公司都會腦子先過一下這些內(nèi)容，同時在站會前解決一些雜事，如吃早飯。
上面說的這幾個方面的動作，現(xiàn)在回想起來，當(dāng)時推進(jìn)的都很困難。一方面，大家都已對原來的方式方法形成習(xí)慣，即便存在問題，打破習(xí)慣也不是易事，另一方面，公司遲遲未能融資成功，領(lǐng)導(dǎo)間還存在利益矛盾，一些同事?lián)墓咀卟涣藥讉€月，因而士氣低落。那時不知道該怎么辦，最后用軟磨硬泡加請了幾頓飯的方式，讓事情順利進(jìn)行起來。雖然新習(xí)慣的建立，需要一定的學(xué)習(xí)成本，試錯成本，好在團(tuán)隊適應(yīng)后，效果改善的非常明顯，交付能力變強(qiáng)，產(chǎn)品質(zhì)量也有保證。遺憾的是，屁股算是擦干凈了，半年后，公司還是因為融資和內(nèi)部矛盾問題，涼了。之后公司一位領(lǐng)導(dǎo)找到新的合伙人成立公司，把我拉去繼續(xù)負(fù)責(zé)項目。
由事到人
進(jìn)入新的公司，依然是初創(chuàng)團(tuán)隊，雖然有了之前的經(jīng)驗，迭代的流程框架很快就搭建起來，但我面臨了新的挑戰(zhàn)：人。如果說前一階段的項目管理，重點在管事，那來到新的環(huán)境，面對互相不熟悉的新同事，我開始重點關(guān)注到如何“管人”。
(1)影響他人
說到項目管理，老生常談范圍、時間、成本鐵三角，而在我看來，互聯(lián)網(wǎng)行業(yè)里，還有兩個角非常重要，一個是“價值”，一個是“人”。做項目，簡單理解就是找來一些人(資源)，按照一定要求協(xié)作完成一件事(過程)，最終產(chǎn)出可交付成果(結(jié)果)。我們常說的“范圍”、“時間”、“成本”，是從項目過程的三個方面去管理把控，確保把事情做對。“價值”看的是項目成果，從公司利益和用戶利益角度去審視判斷，所完成的項目是否具有價值，確保項目做得是對的事情?！叭恕笔琼椖孔钪匾馁Y源，團(tuán)隊能否整齊劃一，高效協(xié)作，直接影響著項目的成敗。而恰恰“人”是最難管理的，不同于物資，作為項目成員的每個“人”都是鮮活的，富有個性的，有不同訴求和見解的個體，難就難在如何影響他人，驅(qū)動他人去做一件事情。
這里先介紹下Fogg行為模型。Fogg說人的行為由動機(jī)，能力和觸發(fā)條件這三要素組成，這三個要素同時都滿足了行為才會發(fā)生。舉個栗子，到中午你肚子餓了要吃飯，可以下樓吃，也可以叫外賣，此時外面下著小雨，于是你打開外賣App，叫了外賣。從Fogg行為模型去看你叫外賣吃的這個行為，它的動機(jī)是你餓了，外賣平臺是能力，觸發(fā)條件是外面下著小雨。
產(chǎn)品經(jīng)理就常常會利用Fogg行為模型去設(shè)計產(chǎn)品，刺激用戶在產(chǎn)品上產(chǎn)生行為，提高活躍度、轉(zhuǎn)化率等。項目經(jīng)理也可以從這個角度出發(fā)，進(jìn)行團(tuán)隊建設(shè)，驅(qū)動團(tuán)隊成員去做事。比如，iOS開發(fā)兄弟A想成長為全棧工程師(動機(jī))，工作之余學(xué)習(xí)了Android(能力)，那項目經(jīng)理如果發(fā)現(xiàn)項目中Android開發(fā)的任務(wù)有點重(觸發(fā)條件)，就可以適當(dāng)分配些給A。再如，新員工技能水平不足，渴望和老員工有更多的學(xué)習(xí)機(jī)會，老員工渴望建立個人影響力，那項目經(jīng)理可以根據(jù)時間安排開展內(nèi)部的分享沙龍，讓大牛分享他們的技術(shù)研究成果。在滿足個人訴求的前提下，即便事情是額外多出來的，員工也會發(fā)自內(nèi)心的愿意主動去把事情做好。命令式要求，或者像我之前通過請吃飯來進(jìn)行推進(jìn)，都只是短期有效，實屬下策。
(2)自我管理
有的人以為，做項目管理應(yīng)該要比開發(fā)輕松許多，因為不用寫代碼，就盯盯進(jìn)度。就像我們小時候覺得上學(xué)好辛苦，還是大人舒服，不用寫作業(yè)。但實際上，項目經(jīng)理就像父母，項目是孩子，天下有哪個爹媽不為孩子操碎了心呢。最近一年來，我覺得我的工作時間和地點是不分上班下班的。在微博上看到一個長圖或橫圖，立馬想到保存下來發(fā)到自家App上看看顯示效果怎樣;進(jìn)入電梯或坐地鐵，立馬想到打開我們的App看看網(wǎng)絡(luò)連接正不正常;手機(jī)24小時不靜音，話費(fèi)充的足足的，公司群、用戶群統(tǒng)統(tǒng)置頂…..可是，依然會覺得時間不夠用。一天下來，事情雜七雜八做了很多，可也說不上來到底做了些啥?！蹲坑谐尚У墓芾碚摺芬粫姓f“管理者的時間往往只屬于別人，不屬于自己”，“管理者常常被迫忙于日常運(yùn)作”，我很感同身受。后來，我學(xué)著進(jìn)行自我管理，管理自己的時間，管理事務(wù)的處理。
我先記錄了自己一周每天時間所花的地方，以及不同時間點的精神狀態(tài)。接著找出哪些時間是浪費(fèi)掉的，哪些時間段不容易被打擾，什么時候工作狀態(tài)不佳，什么時候精神更專注，哪些事情是臨時處理的，哪些事情例行公事的…..然后做出相應(yīng)的改善調(diào)整，最終形成舒服的工作節(jié)奏。比如我發(fā)現(xiàn)自己睡得晚，導(dǎo)致有時候起得遲，會在路上買早飯帶到公司吃，9點半之前的狀態(tài)也不佳，10點鐘還習(xí)慣性的去蹲大號。這使得我開始工作的頭1個半小時效率是不高的。為了改善這個情況，我調(diào)整作息，保證7點起來，在家解決掉早飯和大號，留半小時看看資訊、博客，出門前10分鐘拿出ToDo List看看今天要做哪些事情，排個優(yōu)先級。這樣堅持下來，的確很有效果。
(3)向上管理
剛做項目管理的時候，自己還并沒有從一個執(zhí)行者的角色完全轉(zhuǎn)變過來。只知道要去協(xié)調(diào)資源，規(guī)范流程，解決阻礙，推進(jìn)迭代順利進(jìn)行。對下是有一定的管理了，對上依然是接受任務(wù)，執(zhí)行任務(wù)，接著就是在會議上匯報完成情況。似乎沒什么問題，但在隨時都有可能死掉的初創(chuàng)公司，這還遠(yuǎn)遠(yuǎn)不夠。初創(chuàng)公司往往是小團(tuán)隊，上上下下一共沒十幾二十個人，大家孤注一擲一做一個項目，項目經(jīng)理作為承上啟下的角色，對上也要有個主動溝通的過程，要正確理解傳達(dá)Boss對產(chǎn)品的決策，對團(tuán)隊的期望，確保公司上下目標(biāo)一致，避免把項目帶跑偏。團(tuán)隊遇到障礙也要及時反饋，尋求必要的資源和幫助。
當(dāng)時，我們新公司Boss由于還有別的工作在身，平時一周只來公司一次。如果我僅在周會上向Boss匯報工作，很可能一個月后出來的產(chǎn)品不是他想要的。因為每個人對于產(chǎn)品都有自己的理解，即便啟動階段大家方向一致，但在迭代過程中會不斷有新的idea出來，需求在經(jīng)歷一次次調(diào)整后，方向很可能就偏離了最初的目標(biāo)。所以，我會每隔一小段時間就找老大聊聊。老大不在公司，就電話說。大不用覺得不好意思，或者怕打擾Boss，其實Boss也希望下屬能及時找他溝通。當(dāng)然也有些要注意的地方：1.明確溝通目的，直蹦主題。你的時間很寶貴，老板的時間當(dāng)然更貴;2.選擇合適的時間。我們老大白天要忙于別的工作事務(wù)，所以一般我是在晚上8點左右找他，盡量一次溝通到位;3.不要報喜不報憂。遇到難以應(yīng)對的困難和挑戰(zhàn)，拋出來，憋著就是定時炸彈;4.給出你的方案。發(fā)現(xiàn)問題反饋給領(lǐng)導(dǎo)時，要拿出你的解決方案，而不是只問怎么辦;5.提出你的想法。創(chuàng)業(yè)絕不是靠老板一個人思考就能成功的，當(dāng)你對產(chǎn)品有自己的想法時，要敢于說出來。無論是獲得支持還是反對，你都會釋懷，知道該如何繼續(xù)工作。
結(jié)束語
上面聊得這些都是自己在初創(chuàng)小團(tuán)隊里，作為項目經(jīng)理兩年來的一些感受。有的是填別人的坑，有的是填自己的坑。雖然公司平臺很小，沒人教你該怎么做，一切靠自己摸石頭過河，但這樣的環(huán)境讓自己成長很多，也真切感受到創(chuàng)業(yè)的不易，九死一生。
文章題目：轉(zhuǎn)型項目經(jīng)理，鬼知道我經(jīng)歷了什么
分享URL：http://m.fisionsoft.com.cn/article/djpopgd.html
