15年初，我懷揣著實現一個人生小目標的夢想加入到一家初創公司，希冀能見證公司產品從0到1，從1到10，融資從A到C。可是半年后，雖然產品從0到1是有了，但由于運營模式的限制，從1到10走的很難，用戶規模上不去，融資也是沒有影子。我開始焦慮起來，這樣下去，我要當上總經理，出任CEO，迎娶白富美的人生小目標，可是要萎掉的啊。

[[227893]]

于是，那時還是程序猿的我，漸漸”多事”起來：

一會跑到產品經理那里：

• “我看到一篇某某博客，作者用Axure把需求文檔、產品原型、PRD等等結合到了一起，這樣不同文檔切換查看就很方便，會節省大家一些時間，還特顯高大上，我們也試試?”

一會跑到測試那里：

• “這次迭代不僅新增了很多模塊，還換血了不少舊接口。我們要不要來一次集體測試，大家都參與進來，對各個模塊進行地毯式掃蕩測試，這樣能快速發現問題，也給你減輕了些負擔?”

一會跑到項目經理那里：

• “這次迭代中出現了某某問題，之前也發生過，我們可不可以在迭代結束后開展一個總結會議，統計下遇到的問題，是如何解決的，以后好吸取教訓?”
• ……
• 因為多事，我后來還學會用Auxre和墨刀做原型了;下班回家測自己開發的App，給自己提Bug單;主持一些會議并進行紀要……
• 因為多事，我成了公司加班最多的人，也是微信步數最多人(經常跑堂);
• 因為多事，在項目經理離職后，公司沒有招人，而是讓我頂上了。雖然不得不說，當時的項目千瘡百孔，是個臟屁股。但是我知道，我的轉型是從自己看待項目視角的轉變開始的，而不是職責的轉變。所以既然公司給予了認可，手臂就可以揮的更開了，屁股再臟，也能擦得干凈。

接手項目后，做的第一件事，就是把我之前思考的項目中存在的問題進行了梳理。把那些大坑找出來，填了能立竿見影出效果。

一、使用Git

此前，團隊用svn進行協作開發，最主要問題在于分支的切換合并不方便，以致于實際編碼的時候，大家都只在主干上提代碼，所以開發階段，主干上的代碼是沒發隨時打包的。測試要想針對已開發完成的模塊進行提前測試，只能經常跑到開發那問，做到哪里啦?這個功能可以測了嗎?現在可以打個包嗎?導致開發的工作時常會被打斷，而且即便測試拿到包，也會出現不同開發給的包是互斥的情況，即A給包有只有A功能，B給的只有B功能，分別測都OK了，最后合到一起又是一坨bug。

為了解決這個問題，我們嘗試用git取代svn，并引入gitflow的協作方式。效果嘛，用一個字來形容，“爽的結蓋蓋”。進入編碼階段，開發兄弟會根據自己實現的功能模塊從develop分支上拉出對應的feature分支，如feature-im，feature-moments。一個功能點開發完成，就可以合并到develop分支上，然后刪掉對應的feature分支，接著拉出新feature繼續開發。這就保證develop分支上是可以隨時打包的，根據提交日志，也可以清楚的了解哪些功能是完成了的。測試只要從develop更新代碼，腳本打包，完全可以自給自足了。

二、優化估算

估算千萬不能隨意，估算的準確度直接影響著項目進度計劃的安排。那選擇什么估算單位，如何進行估算呢?估算單位一般有理想人日，理想人時和故事點數，估算方式有自下而上估算，專家判斷和撲克估算等。這里不分別展開討論，只介紹下，進過實踐調整，我們團隊所選用的最為合適有效的估算方法：故事點數+專家判斷+公式計算。

我們迭代會出現兩種情形，一是實現固定需求，需要根據需求估算出完成時間，二是迭代周期確定，需要根據時間估算能完成多少需求。于是選擇了故事點數作為估算單位，不僅僅因為故事點數估算是敏捷推薦的，更重要的是很適用于第二種迭代情形。具體怎么估算呢?以客戶端開發為例，根據經驗，一個功能模塊的開發量與包含的界面數量、接口數量、數據同步方式成一定正比關系，所以只要找到合適的公式，就能根據這些因子算出開發量，即故事點數。我們先由經驗豐富的開發定義一個參照基準：

(1)把界面根據復雜程度分成了三級，賦予不同數值：

• 一級最簡單，值為1，像微信的登錄界面，通訊錄列表界面這類;
• 二級值為2，界面稍復雜點，開發量大概是一級的2倍;
• 三級為4，像頭條的首頁。通常用到的是這三級，當然如果有的界面非常復雜，在計算的時候可以代入更高的值。

(2)接口數量直接代入計算。

(3)數據同步也根據復雜度分了三級，直接從服務端獲取數據展示，與本地無關，為一級，定義值為0，展示本地數據，和服務端無關，為二級，值為1，通過推送方式增量獲取數據，本地需要做存儲和同步，則為三級，值為3。

定義好這些基準后，便有了計算故事點的公式：故事點數=a*界面總復雜度+b*接口總數+c*數據同步總復雜度。a、b、c反應的是開發時間基準，由經驗我們將a取1，b取0.5，c取0.6。所以故事點數=界面總復雜度+0.5*接口總數+0.6*數據同步總復雜度。故事點數估算是相對估算，體現的是需求的開發規模，不是具體的時間，需要乘上系數才能得到開發所需時間。同樣的功能給業務熟悉，技術大牛做，乘的系數可能是0.8，給業務不熟，經驗不足的新員工做，乘的可能就是1.5。

通過故事點數，我們還能了解團隊的開發效率，例如分析一個sprint完成的故事點數，和過去比是多了還是少了?什么原因?是團隊狀態變化了，還是公式不準確需要調整。

雖然這種方式沒有直接估算人日來的直接快速，但能在保證了估算準確性的同時，反應團隊的開發速率和迭代規模，能更好的幫助項目經理把控項目狀態。團隊適應后，再也不用煩心因為估算問題帶來的計劃風險。

三、強調需求

需求不等于功能。此前，我們產品的用戶體驗不好，一部分原因在于產品需求沒有正確傳遞給開發，開發只知道要做哪些功能，只關心如何實現功能。似乎只要功能做出來，就等于滿足需求了。

功能是解決方案，需求是其解決的問題。在PRD評審會議討論功能技術問題前，要先傳達清除為什么要做這個功能，能帶來哪些用戶價值和公司價值。否則一旦評審時發現功能在技術實現上難度較大，開發往往只會站在力求把功能實現的角度給出曲線救國的其他方案，忽略了用戶體驗，甚至違背需求。好比一個快餓死的人，想要吃東西，你卻讓他先回家洗個澡換身正裝，然后進了西餐店點了份甜點。你的方案看似優雅，還考慮到了就餐環境，但實際把人給等死了，就算能堅持到最后，發現端上的只是一份不夠塞牙縫的甜品，可能他也氣死了。開發研究的是技術，討論方案問題時容易在技術上鉆牛角尖，這就需要項目經理產品經理具有用戶視角，抓住需求本質，引導討論方向。

另外在需求的管理上，做了兩件事，一是重新建立需求池，并注意跟進。一開始團隊也有需求池，但由于過分強調溝通，忽略文檔，導致漸漸流于形式，無從追溯產品需求的真實情況。需求池中要記錄需求實現的版本號，對于計劃放到更高版本中實現的需求，一定要在相應的迭代中納入計劃評審，不能遺忘。WBS表中，每個Task也要記錄對應的需求池中的需求編號，方便追本溯源。二是實施需求凍結。我們要擁抱變化，但不是允許無休止的變化，無節操的需求蔓延和朝令夕改的需求變更要禁止，否則會嚴重影響產品的快速交付。在迭代進入編碼階段的2/3時期，會凍結需求，對于改動較大又不一定能帶來實際價值的變更直接拒絕擁抱。當然需求凍結階段也不是拒絕所有變更，重大變革如蘋果審核機制改變，客戶明確要求修改方案等等，經過評審后然而可以擁抱。

四、規范會議

會議方面，主要是啟動會議和站會進行了開刀。

啟動會議

迭代的啟動，不能是由項目經理一聲口頭通知就開始了，哪怕團隊就幾個人。一定要有啟動會議，在會議上交待清除迭代目標，統一大家對實現需求及其背景的認識，避免大家只知道要做什么，卻不知為何做，有什么價值。此外，會議會給人一種儀式感，嚴肅感，能使團隊做好心理準備正式進入新一階段的工作狀態。

站會

之前，團隊的站會時間不固定，有時是連續3天都舉行，有時是隔了3天才舉行，而且每次時間很隨意，一會早上，一會下午。導致大家沒有例行的習慣，也常常在工作中途被打斷去參加站會，然后站會成了匯報會，各自交待做了哪些任務，便趕緊結束，把屁股挪回椅子上。這樣的站會成了雞肋。所以我把站會固定在了每日早上9點10分，明確站會目標是為了跟蹤項目進度和問題，同步成員狀態。會上每個人應交待昨天完成的工作;今天計劃做的工作;面臨什么阻礙，需要什么幫助。這樣團隊成員形成站會習慣，每天到公司都會腦子先過一下這些內容，同時在站會前解決一些雜事，如吃早飯。

上面說的這幾個方面的動作，現在回想起來，當時推進的都很困難。一方面，大家都已對原來的方式方法形成習慣，即便存在問題，打破習慣也不是易事，另一方面，公司遲遲未能融資成功，領導間還存在利益矛盾，一些同事擔心公司走不了幾個月，因而士氣低落。那時不知道該怎么辦，最后用軟磨硬泡加請了幾頓飯的方式，讓事情順利進行起來。雖然新習慣的建立，需要一定的學習成本，試錯成本，好在團隊適應后，效果改善的非常明顯，交付能力變強，產品質量也有保證。遺憾的是，屁股算是擦干凈了，半年后，公司還是因為融資和內部矛盾問題，涼了。之后公司一位領導找到新的合伙人成立公司，把我拉去繼續負責項目。

由事到人

進入新的公司，依然是初創團隊，雖然有了之前的經驗，迭代的流程框架很快就搭建起來，但我面臨了新的挑戰：人。如果說前一階段的項目管理，重點在管事，那來到新的環境，面對互相不熟悉的新同事，我開始重點關注到如何“管人”。

(1)影響他人

說到項目管理，老生常談范圍、時間、成本鐵三角，而在我看來，互聯網行業里，還有兩個角非常重要，一個是“價值”，一個是“人”。做項目，簡單理解就是找來一些人(資源)，按照一定要求協作完成一件事(過程)，最終產出可交付成果(結果)。我們常說的“范圍”、“時間”、“成本”，是從項目過程的三個方面去管理把控，確保把事情做對。“價值”看的是項目成果，從公司利益和用戶利益角度去審視判斷，所完成的項目是否具有價值，確保項目做得是對的事情。“人”是項目最重要的資源，團隊能否整齊劃一，高效協作，直接影響著項目的成敗。而恰恰“人”是最難管理的，不同于物資，作為項目成員的每個“人”都是鮮活的，富有個性的，有不同訴求和見解的個體，難就難在如何影響他人，驅動他人去做一件事情。

這里先介紹下Fogg行為模型。Fogg說人的行為由動機，能力和觸發條件這三要素組成，這三個要素同時都滿足了行為才會發生。舉個栗子，到中午你肚子餓了要吃飯，可以下樓吃，也可以叫外賣，此時外面下著小雨，于是你打開外賣App，叫了外賣。從Fogg行為模型去看你叫外賣吃的這個行為，它的動機是你餓了，外賣平臺是能力，觸發條件是外面下著小雨。

產品經理就常常會利用Fogg行為模型去設計產品，刺激用戶在產品上產生行為，提高活躍度、轉化率等。項目經理也可以從這個角度出發，進行團隊建設，驅動團隊成員去做事。比如，iOS開發兄弟A想成長為全棧工程師(動機)，工作之余學習了Android(能力)，那項目經理如果發現項目中Android開發的任務有點重(觸發條件)，就可以適當分配些給A。再如，新員工技能水平不足，渴望和老員工有更多的學習機會，老員工渴望建立個人影響力，那項目經理可以根據時間安排開展內部的分享沙龍，讓大牛分享他們的技術研究成果。在滿足個人訴求的前提下，即便事情是額外多出來的，員工也會發自內心的愿意主動去把事情做好。命令式要求，或者像我之前通過請吃飯來進行推進，都只是短期有效，實屬下策。

(2)自我管理

有的人以為，做項目管理應該要比開發輕松許多，因為不用寫代碼，就盯盯進度。就像我們小時候覺得上學好辛苦，還是大人舒服，不用寫作業。但實際上，項目經理就像父母，項目是孩子，天下有哪個爹媽不為孩子操碎了心呢。最近一年來，我覺得我的工作時間和地點是不分上班下班的。在微博上看到一個長圖或橫圖，立馬想到保存下來發到自家App上看看顯示效果怎樣;進入電梯或坐地鐵，立馬想到打開我們的App看看網絡連接正不正常;手機24小時不靜音，話費充的足足的，公司群、用戶群統統置頂…..可是，依然會覺得時間不夠用。一天下來，事情雜七雜八做了很多，可也說不上來到底做了些啥。《卓有成效的管理者》一書中說“管理者的時間往往只屬于別人，不屬于自己”，“管理者常常被迫忙于日常運作”，我很感同身受。后來，我學著進行自我管理，管理自己的時間，管理事務的處理。

我先記錄了自己一周每天時間所花的地方，以及不同時間點的精神狀態。接著找出哪些時間是浪費掉的，哪些時間段不容易被打擾，什么時候工作狀態不佳，什么時候精神更專注，哪些事情是臨時處理的，哪些事情例行公事的…..然后做出相應的改善調整，最終形成舒服的工作節奏。比如我發現自己睡得晚，導致有時候起得遲，會在路上買早飯帶到公司吃，9點半之前的狀態也不佳，10點鐘還習慣性的去蹲大號。這使得我開始工作的頭1個半小時效率是不高的。為了改善這個情況，我調整作息，保證7點起來，在家解決掉早飯和大號，留半小時看看資訊、博客，出門前10分鐘拿出ToDo List看看今天要做哪些事情，排個優先級。這樣堅持下來，的確很有效果。

(3)向上管理

剛做項目管理的時候，自己還并沒有從一個執行者的角色完全轉變過來。只知道要去協調資源，規范流程，解決阻礙，推進迭代順利進行。對下是有一定的管理了，對上依然是接受任務，執行任務，接著就是在會議上匯報完成情況。似乎沒什么問題，但在隨時都有可能死掉的初創公司，這還遠遠不夠。初創公司往往是小團隊，上上下下一共沒十幾二十個人，大家孤注一擲一做一個項目，項目經理作為承上啟下的角色，對上也要有個主動溝通的過程，要正確理解傳達Boss對產品的決策，對團隊的期望，確保公司上下目標一致，避免把項目帶跑偏。團隊遇到障礙也要及時反饋，尋求必要的資源和幫助。

當時，我們新公司Boss由于還有別的工作在身，平時一周只來公司一次。如果我僅在周會上向Boss匯報工作，很可能一個月后出來的產品不是他想要的。因為每個人對于產品都有自己的理解，即便啟動階段大家方向一致，但在迭代過程中會不斷有新的idea出來，需求在經歷一次次調整后，方向很可能就偏離了最初的目標。所以，我會每隔一小段時間就找老大聊聊。老大不在公司，就電話說。大不用覺得不好意思，或者怕打擾Boss，其實Boss也希望下屬能及時找他溝通。當然也有些要注意的地方：1.明確溝通目的，直蹦主題。你的時間很寶貴，老板的時間當然更貴;2.選擇合適的時間。我們老大白天要忙于別的工作事務，所以一般我是在晚上8點左右找他，盡量一次溝通到位;3.不要報喜不報憂。遇到難以應對的困難和挑戰，拋出來，憋著就是定時炸彈;4.給出你的方案。發現問題反饋給領導時，要拿出你的解決方案，而不是只問怎么辦;5.提出你的想法。創業絕不是靠老板一個人思考就能成功的，當你對產品有自己的想法時，要敢于說出來。無論是獲得支持還是反對，你都會釋懷，知道該如何繼續工作。

結束語

上面聊得這些都是自己在初創小團隊里，作為項目經理兩年來的一些感受。有的是填別人的坑，有的是填自己的坑。雖然公司平臺很小，沒人教你該怎么做，一切靠自己摸石頭過河，但這樣的環境讓自己成長很多，也真切感受到創業的不易，九死一生。