Categories
程式開發

2次轉管理失敗後,我對項目、團隊、敏捷轉型的新認知


本文由 dbaplus 社群授權轉載。

大家好,我是孫衝。這次分享是我從技術轉管理後,經歷的一些項目管理和敏捷轉型的實踐和經驗總結。希望能對一些初步轉管理,剛涉及項目管理和正在嘗試敏捷的團隊提供一定借鑒的思路。

主要由以下五部分內容組成:

  • 以現在的角度重新去看過往的一些項目
  • 第一次真正實踐敏捷
  • 再一次嘗試敏捷
  • 經歷敏捷的實踐後對敏捷的一些思考
  • 最後是概述總結

主線

在整個分享過程中,主要穿插著兩條主線:時間線和能力線。

時間線分為三部分:

  • 第一部分是2016年-2018年的一段項目經歷。 當時的背景是,沒有轉型管理,沒有項目管理經驗,沒有敏捷常識知識。
  • 第二部分是18年到19年的一段項目管理經驗。 當時的背景是,剛剛開始轉型管理,項目管理經驗較少,第一次嘗試敏捷。
  • 第三部分是19年到現在。 自己已經完成初級管理轉型,項目經驗也有了一定的積累,開始第二次嘗試敏捷。

第二條主線是一條能力主線,並且隨著時間主線的延申,能力主線也在不斷變化。

從管理能力(對下管理、對上管理、以及平級之間的競合關係),到項目管理能力,再到敏捷項目管理能力。

第一章:回顧以前的項目經驗

好,我們開始第一章節,回顧以前的項目經驗。站在當前這個位置,回望自己16年到18年的印象深刻的一個項目。

2次轉管理失敗後,我對項目、團隊、敏捷轉型的新認知 1

這是一個內部項目,CRM客戶管理系統,級別很高。公司不是矩陣架構,各個職能部門之間進行協調配合,所以沒有真正的項目經理。

再就是開發在青島,但是測試、產品和前端都在北京,是典型的異地溝通。這個項目迭代兩年多,自己一個人差不多維護了近兩年。所以我被稱為活文檔,甚至說比產品更了解當時的這個系統。

那麼在以上這些背景下大家能夠預料到存在哪些問題?

2次轉管理失敗後,我對項目、團隊、敏捷轉型的新認知 2

第一個現象:估工時,砍工時

各種”O“大大們強調30天后必須上線,我作為開發估了50天,

主管看後砍到45天,經理看後砍到35天。最終”O“大大們接受了從50天壓縮到35天的這個事實。我也間接為自己多爭取了5天時間。

第二個現象:級別差距懸殊,沒有話語權

上面提到了各種”O“直接提需求,好的方面是系統等級提高了,不好的是領導的需求提過來基本沒有還手的餘地,更別說是中途改需求,加需求這些事情了。

經常是我們非常不理解領導層這麼快上線的初衷,也就是不能夠明白這一次迭代的價值。

第三個現象,因為主要是我來維護,所以問題理解程度有的甚至比產品更深入

請假後,自己越想沒事,往往時刻盯著群裡。第二天去公司已經發現有很多問題需要回復和處理了。

第四個現象,會議多而長

因為是異地溝通,再加上需求的頻繁變化和沒有實質的項目經理,所以基本是面向產品開發,產品指哪兒我就打哪兒。

我們經常是臨時拉起會議,然後討論一個流程上的問題。有時也會組織一次會議,專門討論需求,但是會議的效果不理想,經常超時,討論進展緩慢,每一次會議產生的成果也少,很多時候我們就一個問題深入討論很長時間都沒有結論。

關鍵是我那時對會議超時反而覺得自豪,心裡想:看吶,我們討論的多激烈,這個項目多複雜,需要我們來回討論好幾輪。

大家經常參與會議的應該會深有體會,預定會議室,協調各個工種人的時間,會議上討論,沒有討論完的繼續預定下一輪討論。再加上我們時異地溝通,其中的溝通成本可想而知。

其實這些現像對項目中的每個人而言都是一種煎熬。表面上我們看上去很忙,實際上我們的產出價值有待商榷。

期間我至少有兩次機會可以轉型管理,因為對這個項目太熟悉了,但我印像中的兩次都失敗了。

我一步一步越陷越深,直到我自己都有些迷茫了。我到底要不要轉管理?轉管理這個問題是充滿誘惑的。轉,是一種瓶頸突破。不轉,可以全力投入技術。

越迷茫越糾結,越糾結越迷茫。我糾結著很多問題,比如:

2次轉管理失敗後,我對項目、團隊、敏捷轉型的新認知 3

現在的我再來看這些問題我已經有了答案。有幾點總結吧,首先我認為轉管理最好自己有轉管理的意向,其次可以看一些管理認知方面的書籍,如果有人指導一下更好,最好的情況是有行政命令,逼迫你必須轉變。

第二章:初始敏捷,小試牛刀

現在我們再回到時間線,進入第二段:18~19年 敏捷小試牛刀。

2次轉管理失敗後,我對項目、團隊、敏捷轉型的新認知 4

18年進入到輪子科技,自己開始了帶人,也開始學習帶項目。這個轉型過程也是讓我印象深刻,簡單舉出幾個例子。

2次轉管理失敗後,我對項目、團隊、敏捷轉型的新認知 5

1)重構32個接口是怎麼回事呢?

在我第一次成為項目經理時,內心是激動的,幻想短時間內打造一個優秀的項目。

這個項目叫”產品中心“,我在這個項目重構後的1個月後接手。沒幾天我就像領導提出要重構對外的著32個接口,領導應該當時很詫異,只是說一會要去開會,讓我回去等等。這一等就把我再次重構的熱情降了下來,因為業務系統開始慢慢對接了,後續的需求迭代也開始了。

2)中台會議連環發問

當時我們在討論一個中台戰略的項目會議,現在我稱之為杰哥的人在會上強調了10條建議。我為了顯擺自己,針對這10條建議,一一進行了反問、訴苦。

會議讓我帶跑偏了,成了我的抱怨會。因為剛剛成為項目經理嘛,遇到很多問題自己總是認為不是我的問題是其他人的問題。

3、瀑布模式的痛

第一次做項目經理,比較沒有自信,也比較天真。難的任務給自己留下了,一些臨時任務也沒敢往下分積壓在自己這裡,例會也沒有抹開面子去開。

這一次迭代,就迭代了2個月,第一個感覺就是項目快失控了。第二個想法就是測試別測了,趕緊上線吧,真的快被折磨瘋了。

有時候會對自己很失望,啥也不會。有時候會對其他人很憤怒,怎麼這麼多事。

一個是漫長的瀑布模式,一個是欠缺的項目管理經驗,都讓我走得很難。在這個版本結束後,我第一次接觸了敏捷相關的一些理論。

4)嘗試敏捷

是的,我們開始嘗試了敏捷。我們學站立會,學估點,學使用面板,學使用短週期迭代。這種方式我們嘗試了2個版本,每個版本基本一個月。也算是積累了一些東西。

2次轉管理失敗後,我對項目、團隊、敏捷轉型的新認知 6

項目概況模板——算是闡述這次迭代的核心點和注意事項。

2次轉管理失敗後,我對項目、團隊、敏捷轉型的新認知 7

檢查單——這個主要是彌補項目管理經驗的不足。

2次轉管理失敗後,我對項目、團隊、敏捷轉型的新認知 8

打分模板——這個我們雖然打了分,但是每個人對打分的理解完全不一樣。

2次轉管理失敗後,我對項目、團隊、敏捷轉型的新認知 9

總結模板——我們每次項目迭代後雖然開了項目總結會,但真也就總結一下就完事了,完全沒有形成閉環。

2次轉管理失敗後,我對項目、團隊、敏捷轉型的新認知 10

2次轉管理失敗後,我對項目、團隊、敏捷轉型的新認知 11

所以我後來就想形成閉環,這一次迭代做了總結然後形成電子版記錄,下一次迭代總結會上會再拿出來,對承諾的一個提升點進行盤點。

從上面這四個小案例,現在的我再去看那時的我。會發現當時我轉變一下思路,很多問題其實就會迎刃而解。

2次轉管理失敗後,我對項目、團隊、敏捷轉型的新認知 12

關於項目管理,項目管理本質是管理好項目,讓項目順利上線。如果我當時拿著這條準則去做,那麼很多事情我會安排下去而不是積壓在我這。

1)這期間我也對向下管理有了一些新認識

如果我好好分配自己的時間,給新人一些壓力和指導,那麼他會成長快一些,反過來還能承擔一些工作,我就可以有更多的時間去做其他更重要的事情,這是一個良性循環。

2)我也對同級管理有了新認知

以前我總是比誰的技術厲害,同級之間是攀比競爭。現在我覺得同級之間很多時候需要互相支持。競爭也算是一種學習,我覺得你項目中好的東西,我可以拿過來嘗試一下。

3)那個時候對向上管理認知不夠

以前總覺得領導就是必須主動關心我,如果不經常關心我我就覺得自己被拋棄了,被忽視了。

4)對於心態

如果我當時多站在業務系統的角度去看問題,就會發現很多的問題都是可以理解的。

比如:他們上線前幾天才通知我加接口。如果我抱著服務的態度去解決這個問題,就不會那麼消極。

為了避免後續再有這些問題,我會建群,提前關注業務系統的項目動態,經常群裡問問他們的迭代計劃。有問題解決問題,而不是抱怨。

經歷了職能轉型,項目管理轉型,初步嘗試了敏捷後,有收穫也有慘痛的教訓。當公司提出想做敏捷轉型,我們開始做試點,於是我們又一次踏上了敏捷之路。

第三章:再次開啟敏捷之路

2次轉管理失敗後,我對項目、團隊、敏捷轉型的新認知 13

在重新開始敏捷前,我自己看了很多資料很多書籍,對敏捷有了一個全局觀的認識。

在看書期間也發現了我之前道聽途說的一些敏捷是錯誤的。也發現我們第一次實踐敏捷的時候沒有準備就上路了,所以很多東西並不知道其中的價值。

我從書中總結,現實中再去實踐後,又有了一些收穫和思考。

2次轉管理失敗後,我對項目、團隊、敏捷轉型的新認知 14

1、物理面板

2次轉管理失敗後,我對項目、團隊、敏捷轉型的新認知 15

2次轉管理失敗後,我對項目、團隊、敏捷轉型的新認知 16

2次轉管理失敗後,我對項目、團隊、敏捷轉型的新認知 17

優勢

  • 在物理面板前一戰,確實顯得正式有儀式感。
  • 成員會主動貼、移任務,能夠關注到自己在做的需求。
  • 粗粒度看到項目整體概況。

不足

  • 用戶故事、任務、便利條慢慢佔滿了物理面板。密密麻麻的信息,此時的物理面板反而不夠全局了。
  • 視覺上的衝擊很容易讓我們分散關注整體,需求,任務的注意力。
  • 字體小的話很難平和的心態去關注這些具體的任務了。
  • 依賴物理面板可能會丟失項目過程中的數據。

方案

1)堅持物理面板:

  • 需要空白地方:玻璃牆,白板
  • 需要同步好信息:項目需要一些項目數據的,所以同步到電子版是有必要的,每天的站會物理板拖動後,有個人負責同時拖動電子板(為了統計項目信息)。

2)使用電子麵板:需要投屏,需要培養移動電子麵板任務的習慣。

3)兩者結合:電子麵板及時同步物理面板信息。

2、產品列表和用戶故事長遠規劃,可以粗可以細

2次轉管理失敗後,我對項目、團隊、敏捷轉型的新認知 18

產品列表按照優先級排列,裡面有產品需求也有技術債。以前的我被灌輸使用敏捷,需求必須轉成用戶故事。

2次轉管理失敗後,我對項目、團隊、敏捷轉型的新認知 19

現在看來,這只是一種形式,一種成員都認可接受的描述需求價值的形式。所以只要是成員能夠理解這個需求價值到底在哪,至於怎麼描述就看大家的接受認可度。

“我是開發,我想重構隊列服務,隊列任務隔離,各自處理各自的,不互相影響,好擴展。”

“我是運維,我想最好有一個導出按鈕,這樣響應客戶速度快,我就不用每次郵件申請等待DBA導出了。”

“我是用戶,希望你們提供一個接口,我能知道某個時間的具體稅率信息,這樣才能保證我每月的月初訂單對賬。”

建議

我覺得描述完全沒什麼不妥,就看大家怎麼看,哪種接受度高,從語境中能夠認可它的價值。大白話一點,直白一點,不需要那麼死板官方。建議第一人稱,代入感強,身臨其境。

我認為這個用戶故事或者說需求沒有硬性要求。合適的就是最好的。

難點

難點在於找到團隊成員大部分認可的一種表達方式。對產品的要求較高,幾句話能夠抓住讀這句話那個人的大腦,讓他跟著你的語境思考這個需求到底做了什麼事。然後這個需求實現後能夠帶來什麼。

3、計劃

  • 每一次提前做計劃,大家的時間充分利用。
  • 提前參與需求的討論,理解需求的源來。

2次轉管理失敗後,我對項目、團隊、敏捷轉型的新認知 20

4、估算

2次轉管理失敗後,我對項目、團隊、敏捷轉型的新認知 21

這裡的估算我們使用的後面的一種方式,理想工時。當然還有估點,只是我們使用得不夠熟練。後面會慢慢嘗試,對比兩種哪種更適合團隊。

5、開會

以前開會,自認為會議就是用來討論的,一次不行兩次,兩次不行三次。期間一個大家否感興趣的話題一出,群口相聲來了。討論確實激烈,但是時間過得也快。

既然是討論嘛,時間長點就長點,大不了轉戰另一個地方再戰。搞到最後,大家爭論不休,會議不止,都很疲憊。會議上沒人記錄,會後沒人總結。一些細節點,一些結論不久的將來忙起來漸漸忘記。

建議

  • 前期將一些重要的點可以先找相關人討論對對。
  • 會議找個資深的作為主持人,控制會議節奏。
  • 有問題沒事,記下來會有再重點細緻討論。沒有必要妨礙後面的進度。
  • 會後趁熱打鐵,把會議的問題去確認對應的解決方案。
  • 同一天,最多第二天。把會議上的問題處理方案,發到群裡廣而告之。
  • 不能確人的問題,記錄好接下來持續解決。

2次轉管理失敗後,我對項目、團隊、敏捷轉型的新認知 22

2次轉管理失敗後,我對項目、團隊、敏捷轉型的新認知 23

2次轉管理失敗後,我對項目、團隊、敏捷轉型的新認知 11

2次轉管理失敗後,我對項目、團隊、敏捷轉型的新認知 12

6、評審

關於評審,我覺得作用非常大。評審會議需要線下多花精力對接討論。主流程和難點都浮出水面可以再拉起會議進行溝通。

2次轉管理失敗後,我對項目、團隊、敏捷轉型的新認知 13

2次轉管理失敗後,我對項目、團隊、敏捷轉型的新認知 14

2次轉管理失敗後,我對項目、團隊、敏捷轉型的新認知 15

7、代碼走查

關於代碼走查的好處不用多說,這裡代碼走查的可以融合部門規範,樹立良好的代碼風格。同時可以檢測出相關的bug。這個功夫要花在平時,不太建議拉冗長的會議,大家再會議上去找茬。

2次轉管理失敗後,我對項目、團隊、敏捷轉型的新認知 16

2次轉管理失敗後,我對項目、團隊、敏捷轉型的新認知 17

2次轉管理失敗後,我對項目、團隊、敏捷轉型的新認知 31

2次轉管理失敗後,我對項目、團隊、敏捷轉型的新認知 32

2次轉管理失敗後,我對項目、團隊、敏捷轉型的新認知 33

2次轉管理失敗後,我對項目、團隊、敏捷轉型的新認知 34

2次轉管理失敗後,我對項目、團隊、敏捷轉型的新認知 35

8、驗卡

驗卡,其實可以看作里程碑的交接。就是開發發起,產品驗收的同時測試也在旁邊。對主流程走通即可。不需要冗長的會議。人少建議工位前花10分鐘走一下即可。

9、技術債

我們的系統隨著時間的推移,慢慢會積累技術債。到最後往往是我們不怕新增特性,而是怕在原來的基礎上需求變更。主要原因是技術債導致我們系統的擴展性和可維護性大大降低。

所以在平時迭代我們會將一定比例的技術債進行迭代(比例:1/6)

2次轉管理失敗後,我對項目、團隊、敏捷轉型的新認知 36

10、項目總結

總結如同反省,有反省有思考才會有進步的可能。所以可以和戴明環類似,使項目和成員在迭代中螺旋上升。這一次的項目總結,提出下一次的精進目標。下一次迭代項目總結拿出上一次的總結進行盤點,形成閉環來精進。

2次轉管理失敗後,我對項目、團隊、敏捷轉型的新認知 37

第四章:敏捷路上的思考

很多時候我都會到技術微信群裡拋出一句“大家有實踐敏捷項目的嗎?”接下來很多人回复,有的回复“不好用”、“累死”。

我就在想說得這些人是不是真正了解過敏捷,又是不是實踐過敏捷?

2次轉管理失敗後,我對項目、團隊、敏捷轉型的新認知 38

敏捷有標準嗎?

在我看來沒有~,我們部門四個團隊試點敏捷,但是大家對敏捷的這些方法實踐各種各樣,順序和形式各種各樣。組內的項目成員對敏捷的形式又是一種理解。所以有時候感覺敏捷確實難以實施推動。

敏捷不是銀彈

我一開始比較迷信敏捷,覺得敏捷是一個能解決所有問題的方式。

敏捷的價值

我們劈裡啪啦實施敏捷,到底是圖什麼?

有一個共同的目標引導,自己能力迭代提升(認知、技能、溝通、主動性、心態)。獲得更好的收入,更高層次的職級,升職加薪何樂而不為呢?

其實這也反推項目的成長,相輔相成。

2次轉管理失敗後,我對項目、團隊、敏捷轉型的新認知 39

第五章:總結

成長往往伴隨著痛苦,誰不想在舒適區待一輩子。面對著社會壓力,面對著家庭壓力,面對著自己的價值實現,應該走出舒適區,重新定義自己。

2次轉管理失敗後,我對項目、團隊、敏捷轉型的新認知 40

1、業務和技術互相促進

技術人學帶項目,會發現平時項目經理處理的事情表面上自己都會。但是一旦自己成為項目經理後發現事情不是自己想像得那麼簡單。你要考慮客戶的感受,你要考慮項目能不能可控,你要考慮組員的成長。

你會擁有大局觀,你也不再認為技術就是一切。總之會在業務和技術之間學做平衡。

2、平級溝通

與優秀的人一起工作是一種幸福。

3、向下溝通

技術人轉管理會發現帶出一個人很難,但是一旦帶出來又很有成就感。

4、向上溝通

理解了領導也是人,領導也會有情緒,我和領導不是站在對立面,而是站在同一戰線,互相支持互相成就。

5、項目管理

我認為項目管理是技術人的一種基本能力了。

6、敏捷雖然不是銀彈,但價值無限

7、堅持做下去,持續精進下去

2次轉管理失敗後,我對項目、團隊、敏捷轉型的新認知 41

附錄:書單

2次轉管理失敗後,我對項目、團隊、敏捷轉型的新認知 42

作者介紹

孫衝,輪子科技項目主管

  • 關注人、技術、架構三者聯繫,現在的工作方向為微服務、DDD、中台、架構、項目管理以及敏捷相關。
  • 對業務架構感興趣,當前正在嘗試DDD在項目中的落地。

原文鏈接

https://mp.weixin.qq.com/s?__biz=MzI4NTA1MDEwNg==&mid=2650787834&idx=1&sn=85958865ce0cdbf68b​​335c94d4c07650&chksm=f3f97a6fc48ef37973a49e58579af3fc7d07a3706a56a37f796e8c907064d34b51faa09d6d0c&scene=27#wechat_redirect