本文作者主要談談自己在初創小團隊裏，作爲項目經理兩年來的一些感受。希望可以給你帶來一定的啓發~
15年初，我懷揣着實現一個人生小目標的夢想加入到一家初創公司，希冀能見證公司產品從0到1，從1到10，融資從A到C。可是半年後，雖然產品從0到1是有了，但由於運營模式的限制，從1到10走的很難，用戶規模上不去，融資也是沒有影子。我開始焦慮起來，這樣下去，我要當上總經理，出任CEO，迎娶白富美的人生小目標，可是要萎掉的啊。
於是，那時還是程序猿的我，漸漸”多事”起來：
一會跑到產品經理那裏：
“我看到一篇某某博客，作者用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更新代碼，腳本打包，完全可以自給自足了。詳細瞭解gitflow，可參看我的這篇總結《使用Git必須要理解的GitFlow》
二、優化估算
估算千萬不能隨意，估算的準確度直接影響着項目進度計劃的安排。那選擇什麼估算單位，如何進行估算呢?估算單位一般有理想人日，理想人時和故事點數，估算方式有自下而上估算，專家判斷和撲克估算等。這裏不分別展開討論，只介紹下，進過實踐調整，我們團隊所選用的最爲合適有效的估算方法：故事點數+專家判斷+公式計算。
我們迭代會出現兩種情形，一是實現固定需求，需要根據需求估算出完成時間，二是迭代週期確定，需要根據時間估算能完成多少需求。於是選擇了故事點數作爲估算單位，不僅僅因爲故事點數估算是敏捷推薦的，更重要的是很適用於第二種迭代情形。具體怎麼估算呢？以客戶端開發爲例，根據經驗，一個功能模塊的開發量與包含的界面數量、接口數量、數據同步方式成一定正比關係，所以只要找到合適的公式，就能根據這些因子算出開發量，即故事點數。我們先由經驗豐富的開發定義一個參照基準：
（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.提出你的想法。創業絕不是靠老闆一個人思考就能成功的，當你對產品有自己的想法時，要敢於說出來。無論是獲得支持還是反對，你都會釋懷，知道該如何繼續工作。
結束語
上面聊得這些都是自己在初創小團隊裏，作爲項目經理兩年來的一些感受。有的是填別人的坑，有的是填自己的坑。雖然公司平臺很小，沒人教你該怎麼做，一切靠自己摸石頭過河，但這樣的環境讓自己成長很多，也真切感受到創業的不易，九死一生。