Categories
程式開發

在家辦公是軟件研發組織的“敏捷試金石”之項目管理篇


前言

在上一篇文章(溝通篇)中,我們講了有關軟件研發組織“在家辦公”受到的溝通方面的挑戰。

可能是在一家敏捷的公司待得久了,所以我很長一段時間認為“敏捷”在中國已經是家喻戶曉不需要再去談的東西。可是直到我後來做了技術顧問,開始為客戶提供架構和工程能力的諮詢服務時才發現,絕大多數技術架構和持續交付實踐難以落地的問題,最後都會遇到團隊不夠敏捷這個關鍵障礙,而真正敏捷的團隊,在整個中國的IT行業中,則是極少的。

因為不夠敏捷,所以能夠用於改進的帶寬就不足,因為改進的帶寬不足,所以就難以應用更好的技術實踐,如此反复就變成了死循環……

而在眾多導致不敏捷的原因中,首當其衝的,就和軟件研發組織的項目管理方法和項目管理人員的能力有直接的關係。

而本次新型冠狀病毒(2019-nCoV)疫情導致的“在家辦公”的要求,則瞬間放大了相關影響——尤其是那些依賴於傳統項目管理方法的軟件研發組織。

那麼,在這一篇中,我們就聚焦“傳統的項目管理方法”和“敏捷的項目管理方法”的區別,來談談對於在家辦公的影響:

  • 傳統管理方法的缺陷
  • 敏捷管理方法為什麼更適合在家辦公?

傳統管理方法的缺陷

傳統的項目管理方法以資源投入為著眼點,強調按約定進行交付

說起項目管理三角形(Project Management Triangle),我相信很多學過項目管理的人,都會脫口而出: 时间(Time)范围(Scope)成本(Cost)

PS:在實際中,很多團隊的項目管理人員過去都是從開發人員幹上來的,我特別喜歡在客戶現場問這個問題,相當一部分團隊所謂的項目管理人員,則根本回答不上來這個項目管理的基本概念,這也是一個國內軟件研發企業很有意思的一個現象,屢試不爽……

但是在“脫口而出”的時候,卻很少有人記得或者忽略了,作為“傳統的項目管理三角形”,時間、範圍、成本所構成的三角形中間,是非常重要的: 质量(Quality)

在家辦公是軟件研發組織的“敏捷試金石”之項目管理篇 1

項目管理三角形

這個三角形告訴我們了這樣一個相互影響的關係:

在項目質量要求不變的情況下(一般來說,在傳統的工程類項目中質量要求都是一經確定難以變更的):

  • 如果需要縮短項目時間,那麼就要減少項目範圍或增加項目成本投入;
  • 如果要節約項目成本,那麼就需要減少項目範圍或延長項目時間;
  • 如果要增加項目範圍,那麼就要增加項目成本或延長項目時間。

這個“傳統的項目管理三角形”非常科學,就拿這次抗擊新型冠狀病毒(2019-nCoV)的“雷神山”和“火神山”兩個醫院的神速建設來說:

首先,兩個醫院的建設標準和質量是不可妥協的,同時,施工範圍是不可變的,工期也是不可變的,那麼在這個基礎上,只能不計成本的動用體制優勢進行建設。

是不是特別有道理!

但是呢?這個“傳統的項目管理三角形”(注意我一直在用引號強調“傳統”二字),在我們的軟件工程中,則通常是不能正常工作的!

為什麼呢?因為傳統的工程項目,其項目本身的 范围 更加可控,經驗或資源的“復用性”更強,項目過程中的變化相對穩定;而軟件工程,是屬於“知識型工作”,其“創新性”更高,項目過程中的變化往往非常頻繁,所以項目的 范围 則通常很難控制

在家辦公是軟件研發組織的“敏捷試金石”之項目管理篇 2

“雷神山”和“火神山”這樣的工程規模和速度在軟件行業中非常困難

所以,這也是為什麼“雷神山”和“火神山”兩個醫院的建設工程,能夠在2天左右的時間出圖紙,然後在5-7天基本完工的關鍵,因為這裡面有大量現成的經驗和方案組合,完全依據設計圖紙進行施工的方式,以及固定的施工工藝和預製件的使用——這一切能夠確保所有參戰工人和施工隊,按照統一的標准進行快速的建設工作。

而作為一個軟件項目,想要從0開始,做到這兩個醫院的建設方式,則是極其困難的。首先我們就很難完全按照詳盡的設計圖紙或者嚴格的工程標准進行工作——除非此類軟件所解決的問題已經在業內屬於通用型問題,有大量的現成產品、開發套件或者開源方案拿來改改就能用(嗯,尤其是開發套件這個東西,往往是誤入歧途,成為未來變更瓶頸的開始)。

一般來說,如果一個軟件研發組織,在平時進行項目管理的時候,是基於“甘特圖”的管理方式,那麼大概率的就是在用以資源為核心的傳統管理方法,來錯誤的管理以價值為核心的軟件研發項目。(嗯,曾經做項目管理時的我也年少輕狂甘特圖過……)

在家辦公是軟件研發組織的“敏捷試金石”之項目管理篇 3

基於Microsoft Project的甘特圖式項目管理

在實際中,“甘特圖式”的項目管理,與強調精準管控,基於嚴格階段劃分和詳盡文檔的瀑布式軟件開發流程往往密不可分。在這種開發流程中,一個可工作的軟件,往往只有在某個開發節點到達後,其全部的功能才有可能被集成完畢,然後進行批量測試和驗收。而在這個節點前的過程中,是難以集成甚至是“可工作”的,所以更不用提測試和驗收了。正所謂越是想精確,越是十萬八千里。

在這種管理模式下,由於項目精準管控的需要,往往項目管理人員都具備相當的管理權力或職級,屬於比較強勢的管理人員,而很多程序員八卦中那些對於項目管理人員聲嘶力竭和官僚式的管理風格的描述,往往也是反映的這種管理風格下的研發團隊。

而一旦轉入在家辦公,隨著現場辦公的便利性的消失,工作透明度的降低,以及各種協作難度的增加,軟件研發的進度將變得愈發不可控,能否按時完成所有工作項的開發、集成、測試和驗收,就變成了一個更加“燒香拜佛聽天由命”的事情。

到時候項目管理人員怎麼辦呢?嗯……買套非常“好用”的在線協作工具,靠更多的視頻會議來繼續“聲嘶力竭”和“追著屁股”的“連環Call”嗎?

(你要是再不趕緊搞定,就在家里永遠不要來公司上班了!!!手動滑稽……)

敏捷管理方法為什麼更適合在家辦公?

敏捷的項目管理方法以價值交付為著眼點,強調適應變化。

與“傳統的項目管理方法”相比,“敏捷”類的軟件項目管理辦法,強調“以價值交付為核心”,通過“適應”的方式,著眼提升應對需求變化的能力。

PS:我的同事,ThoughtWorks中國區CTO徐昊曾經總結過針對“敏捷”價值觀的經典一句話描述,就是“Value delivery over follow practice(價值交付優於循規蹈矩)”,這也體現了“適應”的精髓。換句話說,如果有人告訴你,敏捷就一定要做……(例如迭代式開發),那就是有問題的了,必須要綜合多方考慮,在不同的環境下,找到最利於價值交付的方式,才是真正的敏捷。

如何做到“以價值交付為核心”和“適應”呢?僅就項目管理的方式來講,在我看來,這裡面有兩個非常關鍵的區別,我們分別來講一講:

  • 敏捷三角形(Agile Triangle)
  • 可視化卡片系統(kanban)

敏捷三角形

首先,我們來講一講用“敏捷三角形(Agile Triangle)”代替“傳統的項目管理三角形”。

在家辦公是軟件研發組織的“敏捷試金石”之項目管理篇 4

從傳統的項目管理三角形到敏捷三角形

如上圖所示,“敏捷三角形”所關注的三個角是: 价值(Value)质量(Quality)约束(Constraints),其中 约束就是以前的“傳統項目管理三角形”。從這張圖上我們可以看到,敏捷三角形在傳統三角形的基礎上將 质量价值進行了顯式的關注。

簡單來說(我所總結的):

因為在軟件領域,隨著時間的推移,影響 约束變化的東西太多了,敏捷的項目管理,應該在 约束的條件下,優先關注以適合的 质量為客戶交付優先級最高的 价值。而另一方面,由於精準的度量實在是太難了,所以我們應當以更輕量級的手段,來跟踪和度量 价值的交付速度(例如燃燒圖、燃盡圖、累積流圖等等),從而獲得雖然模糊但是相對更準的預測。

PS:有關敏捷三角形的相關概念,這裡不展開講​​,感興趣的話可以參考這篇文章:https://www.infoq.cn/article/2009/08/agile-triangle

那麼這樣做的好處是什麼呢?

首先,敏捷的管理辦法,強調整個團隊關注價值交付的進度,發揮團隊中每個個體的優勢,通過集體的力量來跟踪和度量項目交付。這樣能夠降低中心化管理的依賴,不再依賴由具體的一個人來進行項目的管理(嗯,就是那個權力很大的項目管理人員),為更鬆散的管理方式提供便利。(這對在家辦公時的分佈式協作提供了一個關鍵保障,少一個吼叫的人是一件多麼令人開心的事情啊!)

其次,以價值交付為導向,能夠降低過去關注資源的利用的複雜性,使得管理方法更加輕量和易於操作,進一步降低了項目管理的工作量和學習成本。(這會有助於降低在家辦公所增加的管理壓力)

同時,另一個好處,就是更輕量級的管理方式,能夠更容易應用讓整個團隊(而非少數項目管理人員)共享和關注的可視化手段,來增強團隊工作的透明度,讓每個人的工作暴露在陽光之下——這個就是基於“可視化卡片系統”的管理辦法。(嗯,上一篇說了,工作的透明度是在家辦公特別重要的依賴)

可視化卡片系統

由於以關注“價值的交付”代替了“關注資源的使用”,所以我們可以用以卡片為可視化單元的“可視化卡片系統”進行項目進度的跟踪和度量,也就是我們常說的“卡牆”或者“看板”,如圖所示:

在家辦公是軟件研發組織的“敏捷試金石”之項目管理篇 5

看板方法的拉動式看板

有關可視化的好處,我們在上一篇文章(溝通篇)中已經有過介紹,這裡不再展開講。

在基於卡片的可視化系統中,我們所關注的,主要是:

  • 團隊的工作流程(縱向分欄)
  • 當前的卡片數量(累積工作)
  • 卡片的狀態(工作的進度)

而我們所要做的事情,就是要去想辦法讓卡片系統中的卡,盡快的從左邊一步一步的挪到右邊的“完成(Done)”一欄。

這種只需要便利貼和大白板的管理辦法,比基於“甘特圖”這種需要依賴重量級管理工具(Microsoft Project等)還不直觀的方式,簡直是輕量級太多啊!嗯,而且這種輕量級的辦法,特別有利於協作,讓對於項目管理這件事變成團隊每個人都可以關注和參與的事情!

正因為敏捷的可視化卡片系統具有這樣的好處,所以大家會注意到當今以Trello和Jira為代表的在線可視化項目管理工具,都是以卡片系統的方式來實現的(嗯,包括最近因為在家辦公大火的各種在線協作產品也是這樣的)。

在家辦公是軟件研發組織的“敏捷試金石”之項目管理篇 6

Trello

PS:特別需要注意的是,敏捷的卡片系統一定是以價值交付為核心的,卡片代表的是價值。我曾經在客戶現場見過一種非常典型的“偽敏捷看板”(很可惜因為保密原因不能拍照)——在看板的左側從上往下以每個人的名字為一欄進行拆分(橫列俗稱泳道),然後跟踪每個人所負責的卡片,這種就是一種典型的將人作為關注的核心(把人當資源用),將卡片系統用成了甘特圖。 (嗯,各位趕緊回去自查一下自己的看板是不是這種……)

總結

洋洋灑灑圍繞項目管理說了這麼一大堆,綜上所述,如果一個軟件研發組織,不能以敏捷的項目管理方法來管理項目,如何能夠降低在家辦公的項目管理成本呢

最起碼的就是:你就算現買一個在線協作辦公的產品,也用不起來嘛!

但很遺憾,現實中,我們還是能夠看到大量的軟件研發組織,還是依靠傳統的項目管理方法來管理軟件開發,或者使用錯誤的方式來應用敏捷的項目管理方法。

按理來說,以上內容但凡是看過基本敏捷方法相關的書籍都應該知曉,但是非常殘酷的是,通過我在實際諮詢工作中的觀察,現實中的絕大多數軟件研發團隊項目管理​​人員,除了是從開發人員轉過來的以外,還有大量的是從傳統的項目管理轉過來的(或者學的是傳統的項目管理方法論),所以能夠說清楚以上項目管理方法論區別的人,則屬於少數。

由於篇幅原因,我無法對影響在家辦公的項目管理問題進行一一講解,這裡只能專注於最基本的傳統項目管理與敏捷項目管理的差異,但還是那句話:

以絕大多數軟件研發組織的敏捷實踐水平之低,還談不上如何在家辦公

希望本文能為眾多因為“被在家辦公”搞得雞飛狗跳的軟件研發組織提供一些參考和幫助。

後續文章,我會從另外的方面,來繼續講一講,為什麼在家辦公是軟件研發組織的“敏捷試金石”。

作者介紹

胡皓,ThoughtWorks首席諮詢師。十年以上軟件開發工作經驗。從士兵成長起來的軟件技術顧問,從事過廣泛的業務分析,項目管理,全棧軟件開發、培訓和技術諮詢等工作。當前,作為ThoughtWorks中國區諮詢BU數字化架構能力團隊的負責人,正深耕於以演進式架構、領域驅動設計、雲原生微服務為代表的數字化架構能力,幫助客戶實現軟件工程能力提升和數字化轉型的目標。

本文轉載自公眾號槍砲與代碼(ID:guns_n_code)。

原文鏈接

https://mp.weixin.qq.com/s/t_J1hmTdBEMziPI2nHkCiw