項目管理之摸着石頭過河的那些日子

本文來自 Worktile 用戶 @李文強 同窗的分享，講述了他近十年來在項目管理上走過的坑。

應Worktile團隊之約，撰寫了此文。我歷來不喜歡敷衍了事，因而準備良久，回顧了這些年的點點滴滴，才成此文，以此祭奠那些年，項目管理之摸着石頭過河的那些日子。

首先介紹下本身：

本人IT屌絲一枚，人稱「程序猿」，目前已經在這個行業摸爬滾打6年左右。

曾經是一名文藝青年，現代詩人，覺得會成爲文壇上的冉冉新星，結果卻成爲了碼界的猩猩——《跟我學C#程序設計》、《跟我學ASP.NET》的做者，《SharePoint 2013開發高級教程（第四版）》的譯者。

性格上擁有理想主義和完美主義情節，熱愛編程（目前主要以業餘編碼爲主），致力於爲中國開源社區作貢獻（開源項目有：https://github.com/magicodes/Magicodes.NET）。一直擁有不少想法，是一個追逐夢想和興趣的人，喜歡思惟碰撞，喜歡技術交流，喜歡設計與規劃軟件（含遊戲）產品。

上過兩次梁山（創業過2次，剛出來的時候蠻幹過一年），都被招安了，目前是第三次。當過游擊隊（接私活），攬過技術活，帶過團隊，作過各類軟件和網站以及企業業務系統開發，玩過SharePoint，作過微信APP，如今在業餘學習Unity3D。目前在公司擔任產品經理&技術總監。

以我這麼多年的碼農生涯來看，IT行業比其餘行業更加須要項目管理工具，更加依賴項目管理工具，也更加願意使用項目管理工具。一路走過來，說多了都是淚，下面就分享下，這些年我在項目管理上跌倒過的坑。

摸着石頭過河砸到腳的日子

前兩次創業都沒有團隊的概念（持續一年），因此更談不上項目管理了。一我的一杆槍挑起所有，作完一個仿淘寶的電子商務網站（叫汽配通），而後繼續編寫了客戶端管理軟件（相似於管理汽配的進銷存），總之一我的從設計到編碼到測試所有搞定。偌大個項目，加上老闆，就咱們倆（以前有個老程序員，幹了半拉子走了）。就這樣一直堅持了差很少一年，直到厭倦了這種生活。因而告別了第一段創業，而後匆匆結束了第二段創業生涯（IT培訓，堅持了不到一個月），來到了上海，開啓了一段暗黑的旅程——從旁觀者，到成爲團隊Leader，從開發者，到項目經理的艱苦蛻變。

在這裏第一個項目是作XX加盟店系統，一個失敗的項目，我是被當作壯丁抓過來的。曾經有幾個月每天晚上二、3點回家，打的費多的一個月報了2000多。給個人節奏就是——加班，趕進度，再加班，再趕進度。因爲需求沒控制住，因此作到後面，項目天然死掉了——公司和客戶撕破臉，直接結束。我做爲Coder的感覺是——項目管理=需求分析+需求設計+需求把控，另一個收穫就是——我推進團隊使用了源代碼管理。

接下來，開始帶隊開發是某某銀行項目，拉了幾個壯丁，直接宣佈開戰。不少小公司到如今爲止都是這樣的——誰技術強，誰就來帶團隊。這種方式是存在很多問題的，可是這個項目是相對比較完美的完成了——雖然中間被另外一個部門的項目經理投訴了一把，可是客戶一直對我念念不忘、「關懷備至」。這個項目的成功主要有幾個緣由：項目並不複雜，業務理得比較清楚，銀行客戶需求確認比較完全，客戶項目管理的意識比較強，當時每週都要發週報，噁心死我了。那時我得常常安排任務，你們定期交工就OK，Delay就加班，有問題就討論，沒問題就你們看小說（沒辦法，寫個代碼都得層層遠程服務器編寫，還沒網，沒事的時候，除了盯着手機就只剩下睡覺了（不過被客戶盯着，不大好睡覺）），總之仍是比較和諧的完成了工做。

完成了這個項目，領導很讚揚，因而開始了帶隊開發某某移動項目三期，因而最黑暗的日子就來了。首先，項目很宏大（七、8個子項目），人員多並且雜而不精。我既要作項目管理，又要擔任核心開發，並且須要談需求，確認需求，安排計劃，任務，帶隊開發，作測試，督促部署，應付客戶投訴（這個是那個時候常常要兢兢戰戰應對的事情，國企的人貌似都喜歡這樣）等等——一大坨瑣事，想一想都是醉了。剛開始還信心十足，到後面已經疲於應付了。每次領導到現場都是——我與大家同在，我請你們吃飯，而後大家繼續加班……

由於事多又雜，我想過不少方式——起初是靠腦子管理，而後模仿上面XX銀行的週報制——沒堅持下來；也曾靠過本本，紙撕得一張一張的，並且有時忘桌子上了，另外一天來時，說不定就被大媽拿去擦屁股了。也曾祭出過Excel神器，甚至用過Project，最後都不了了之。最終，項目最終仍是悽慘落寞了——我感受身心俱憊，疲於伺候那幫孫子，因而遞交了辭職書（固然後來沒批）——不過最終是我留下了，團隊成員都走了。此次經驗也讓我身心受創，過後我也進行了反思：

• 主要緣由是公司資源有限：如人手不夠、缺少骨幹；
• 次要緣由是項目管理存在太多問題，好比不能很好地開發迭代，測試把關不足致使Bug反覆出現（常常沒有測試角色），需求沒有控制住（好不容易你這邊控制住了，那些孫子打電話給領導，而後領導又拍板了），開發人員沒有獲得最佳利用等等。
• 固然做爲一名技術宅，我當時以爲還有一個關鍵的點——缺少一款好的項目管理工具。在個人理想中，項目經理在系統上安排計劃和任務，開發人員在系統上查看本身任務，更新任務狀態，而後測試人員測試並提交Bug，而後項目經理繼續安排任務，就這樣不斷地迭代。爲何有這種想法，由於Excel用的我快吐了。浪費時間還浪費精力。

總之，那是一段摸着石頭過河的日子，不過最後砸到本身的腳了。

真的是項目管理工具的問題嗎？——敏捷開發

基於第三點，我開始反思項目管理。那時公司也組織過項目管理考試，雖然就上了一次課，以我天資絕佳的資質——天然沒過（也許要上兩次課才行，哈哈）。因而在這個項目的尾期，我開始有意識的學習其餘團隊的項目管理經驗，而後瞭解了敏捷開發，而且使用了TFS的敏捷開發模板。當時看到的第一眼就是——那不就是我苦苦找尋日思夜想的玩意兒嗎？！要知道，技術宅都比較容易激動。因而爲此爭取到了領導的支持，買了臺服務器部署，而且在開發部門進行了一次敏捷開發的培訓——我當講師，雖然當時我也是半罐子水，可是當你晃了這麼久的時候，你也就習慣了。

敏捷開發確實是一種不錯的並且也很先進的理念，它是以用戶的需求進化爲核心，採用迭代、按部就班的方法進行軟件開發。由於如今軟件項目基本上都會經歷需求變動，而敏捷開發是適應這個需求變動的。TFS2012的敏捷開發模板則將其應用到了實際開發當中，能夠添加需求、任務、Bug、風險、測試用例等等，並且提供相應的流程，而且可以配置無限的迭代以及工做區域。此外，還提供了不少客戶端，好比集成VS，可以在簽入代碼時與工做項掛鉤，提供了測試管理器和反饋管理器，可以錄屏、截圖甚至生成自動化的測試用例來提交TFS，總之是一款針對軟件項目的很是強大的管理工具。

但是當那次培訓事後，個人心立馬就冷下來了，放棄了開始在公司推廣這個工具——此玩意兒只應國外有，小公司用它太複雜。儘管微軟在敏捷開發流程方面，圍繞開發和測試作得很細緻，可是在中國大部分小公司小團隊根本行不通。

緣由有如下幾個：

• 極可能團隊角色都湊不齊，測試和美工常常是痛腳；
• 測試不肯意學習這些工具，寧願純手工測試（這不是主因）；
• 增長了不少工做量，而且大部分項目經理基本上不具有這個素養（這是根本緣由），不肯意帶着團隊來使用這個工具——這是我開會直接獲得的心聲（若是我推廣，那就是衆多項目經理的罪人啊）。首先對項目經理的要求很高，並且工做量的增長是很龐大的，尤爲是前期。從上面的截圖能夠看出，能夠添加需求、任務、Bug等等，也就是至關於把軟件開發管得死死的，項目經理不但須要這種規劃的意識，還須要將之前只要郵件往來的內容都要整理添加到上面來，並且有些還有很多流程，好比審批，還得將每一個任務詳細的分配給開發人員，因此基本上項目經理都會潛意識的排除。相對開發人員而言，首先是源代碼管理工具須要用TFS，工做項等更改或者查看在開發工具中就可以查看與修改。而對於測試人員來講，首先須要學習測試管理器，之前只要簡單截截圖，QQ往來的或者郵件往來的，如今則要使用這麼一個高端工具，天然也會有些排斥
• 只管理到了軟件項目的生命週期（不過人家目標就是這樣）；
• 不夠靈活。由於敏捷開發模板都規範好了，天然不能更改，可是中國領導大都是不規範的。他們不會從上到下來推進規範的東西，不少時候他們只會橫插一腳，把你絆倒。

由於其模板太細，太規範，通常人都堅持不下去，並且我既是項目經理，又是開發骨幹，很難及時去梳理需求和任務以及Bug，遇到工做繁忙時，就忽略或者簡化了，最後我也沒能堅持下去，可是在使用的過程當中，感受從敏捷開發中學到了不少理念（好比我知道了針對需求變動，還有這麼一種先進的理念，其實後續的項目管理中，我或多或少都用到了這種理念），受用不淺。

不過此次培訓卻是幫公司開發部作了一點貢獻——大部分項目組開始用源代碼管理工具了，哈哈，你如今終於知道有些開發團隊有多落後吧！以前採購的那臺服務器被我裝了N個虛擬機，除了放TFS，還部署了SVN和SharePoint。

照例，我也進行了一次反思，我以爲敏捷開發過重，項目經理須要不少，工做量也比較大，是否能夠考慮一些輕量級的工具呢？

輕量級的管理工具——SharePoint？

在這種迷茫中，又作了一些項目，客戶使用了Redmine之類的管理工具，功能簡單輕量，還比較好用。雖然使用情景比較有限，可是有時候也夠用了。

再後來，我又上梁山了，此次準備不佔魔都不罷休，誰都不要來招安我！哈哈。

此次我擔任了產品經理和技術總監的重任。由於是創業公司，從0到有，歷經了項目（產品）管理的9*9=81難。

基於以前的經驗和教訓，在產品伊始，我就開始尋找適合的項目管理工具。TFS的敏捷開發流程天然被我放棄了，按照個人想法，我須要一個輕量級的項目管理工具，因而我決定使用SharePoint列表來承載這個重任（其實一開始我是拒絕的，由於當時我不知道Worktile，也實在找不到合適的工具）。固然，SharePoint其實也是能夠用的，好比：

不少能夠選擇的列表模板：

開發任務列表（視圖能夠定義（好比排序和篩選））：

日曆：

文檔庫：

Wiki頁：

在沒使用Worktile以前，咱們一直是基於其進行產品管理的，包括目前還有部分信息仍在上面。

雖然使用SharePoint管理產品以及項目是知足個人需求的，可是它仍然有不少不足:

• 用戶體驗不夠好。
• 並非專門的項目管理工具，缺少不少規範與機制，難以有效的規範的利用。
• 我須要定製SharePoint工做流來推送通知。
• 團隊成員上手難，須要培訓。
• 因爲我部署的是內網環境，所以在外面的時候不方便溝通與查看。
• 沒有手機端，每次都須要我去催辦。

固然在這個階段的尾聲，我已經意識到了——並非工具不行，而是人不行。固然好的工具能帶給最佳的輔助。

痛定思痛，蛻變——從敏捷開發到產品（項目）管理

曾經在2013年12月20日的時候，我無心中發現了Worktile，當時試用了一下，感受眼前一亮，可是我並無應用到項目管理中。

直到今年1月份，回顧過去的一年，我以爲是時候該有點變化了——新年的鑼鼓敲出新的鐘聲，而我已經準備好了新的紅內褲。回顧去年一年，產品在需求的抨擊下猶如暴風雨下的孤帆，而咱們是那被困已久的憔悴的船伕。做爲所謂的產品經理，我該肩負起歷史的責任了。痛苦的思考了很長一段時間，不斷地反思，不斷地討論和交流，我意識到了敏捷開發不是產品管理，我意識到了我須要更好的梳理和管理產品的每個環節，讓其規範可控合理。所以，單純的計劃+任務的模式不是解決此問題的神器，我必須從開發者身份跳脫出來，真正迴歸到產品管理的角色上來。意識到了，就要行動，我一直是一個執行力很高的人。因而揹負了全部，放棄了編程的衝動，全身心的投入到產品規劃和梳理中來了，同時我將Worktile做爲這次蛻變的工具。

說作就作，我開始根據產品狀況定製了不少管理模板，好比 RodeMap、計劃、反饋、研發、CRM、招聘、項目 等等，我從這些方面挨個梳理，不斷地考量，通過這幾個月的努力，我感受產品終於回到了正軌，亦有了一種盡在掌控之中的感受——只有此時，我才以爲我是一個真正的產品管理者。所以，敏捷開發不是產品管理，亦不是項目管理，從一開始，我就沒有走對。

下面是我對公司產品管理的一個規劃：

RodeMap示例：

研發的模板與流程：

CRM:

下面是某些方面的應用場景。好比檢查項的：

相似於Wiki頁的：

固然還有不少，這裏就不一一列舉了。

從這段時間用下來的感覺來看，我以爲遷移到Worktile的這個決定毋庸置疑是很是正確的：

1. 從上面不少功能來看，均可以看住SharePoint功能的升級版，好比Wiki，日曆，任務列表，Web Office App等等；
2. Worktile用戶體驗至關不錯，團隊成員上手簡單。並且我開始帶動全部可能的人來使用。由於其用戶體驗的優越性，你們都並不排斥，也不會出現帳號忘了的狀況（都使用的企業郵箱）。包括如今，銷售和業務我都歸入了使用者的範圍；
3. 敏捷開發不是產品管理，固然也不是項目管理，只是項目管理的一部分，產品管理的一小部分。產品管理應該包括如下內容：產品RodeMap，產品計劃（包括市場計劃），需求、Bug，研發，CRM等等，這是我下決定遷移的最重要的緣由。由於基於Worktile的列表和任務組合模式，我能夠很靈活的管理這些。輕量靈活卻不失功能，這就是我想要的；
4. 手機端的支持。我如今要求每個成員天天上班都優先打開手機端，只要狀態更改了便有通知，方便及時溝通，省卻了不少跑路和溝通的時間；
5. 溝通很便捷。基本上大部分功能模塊均支持討論或者評論功能；
6. 免費。創業公司能省就省；
7. 輕量靈活卻不失功能，就如第3點後面所說；
8. 很便於梳理事情、任務和問題。你能夠討論，能夠發佈Wiki，也可使用檢查項陳列，你還能用列表作個小流程，總之，你能夠用不少方式來呈現和表達。
9. 一直在不斷的迭代進步，並且在使用過程當中我提了不少建議與意見。

寫在最後

產品管理和項目管理是一條很漫長的路，也許大家也會有我這樣的經歷，也會如我通常歷經種種傷痛。時間老是一堵不可逾越的牆，老是證實咱們過去是錯的。那麼，咱們只要確保咱們每一天都在前進就行。就現在天開會時，一個團隊成員說，今年最大的變化是，咱們有產品經理了，我是欣慰的。

最後，但願Worktile越作越好，也但願大家都找到本身的路，而我將繼續勇往直前。