[[324422]]

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

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

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

主線

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

時間線分為三部分：

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

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

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

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

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

 

 

 

 

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

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

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

 

 

 

 

第一個現象：估工時，砍工時

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

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

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

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

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

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

請假后，自己越想沒事，往往時刻盯著群里。第二天去公司已經發(fā)現有很多問題需要回復和處理了。

第四個現象，會議多而長

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

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

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

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

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

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

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

越迷茫越糾結，越糾結越迷茫。我糾結著很多問題，比如：

 

 

 

 

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

第二章：初始敏捷，小試牛刀

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

 

 

 

 

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

 

 

 

 

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

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

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

2)中臺會議連環(huán)發(fā)問

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

會議讓我?guī)芷?，成了我的抱怨會。因為剛剛成為項目經理嘛，遇到很多問題自己總是認為不是我的問題是其他人的問題。

3、瀑布模式的痛

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

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

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

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

4)嘗試敏捷

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

 

 

 

 

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

 

 

 

 

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

 

 

 

 

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

 

 

 

 

總結模板——我們每次項目迭代后雖然開了項目總結會，但真也就總結一下就完事了，完全沒有形成閉環(huán)。

 

 

 

 

 

 

 

 

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

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

 

 

 

 

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

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

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

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

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

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

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

4)對于心態(tài)

如果我當時多站在業(yè)務系統(tǒng)的角度去看問題，就會發(fā)現很多的問題都是可以理解的。

比如：他們上線前幾天才通知我加接口。如果我抱著服務的態(tài)度去解決這個問題，就不會那么消極。

為了避免后續(xù)再有這些問題，我會建群，提前關注業(yè)務系統(tǒng)的項目動態(tài)，經常群里問問他們的迭代計劃。有問題解決問題，而不是抱怨。

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

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

 

 

 

 

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

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

我從書中總結，現實中再去實踐后，又有了一些收獲和思考。

 

 

 

 

1、物理面板

 

 

 

 

 

 

 

 

 

 

 

 

優(yōu)勢：

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

不足：

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

方案：

1)堅持物理面板：

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

2)使用電子面板：需要投屏，需要培養(yǎng)移動電子面板任務的習慣。

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

2、產品列表和用戶故事長遠規(guī)劃，可以粗可以細

 

 

 

 

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

 

 

 

 

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

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

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

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

建議：

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

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

難點：

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

3、計劃

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

 

 

 

 

4、估算

 

 

 

 

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

5、開會

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

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

建議：

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

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

6、評審

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

 

 

 

 

 

 

 

 

 

 

 

 

7、代碼走查

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

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

8、驗卡

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

9、技術債

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

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

 

 

 

 

10、項目總結

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

 

 

 

 

第四章：敏捷路上的思考

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

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

 

 

 

 

敏捷有標準嗎?

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

敏捷不是銀彈

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

敏捷的價值

我們劈里啪啦實施敏捷，到底是圖什么?

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

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

 

 

 

 

第五章：總結

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

 

 

 

 

1、業(yè)務和技術互相促進

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

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

2、平級溝通

與優(yōu)秀的人一起工作是一種幸福。

3、向下溝通

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

4、向上溝通

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

5、項目管理

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

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

7、堅持做下去，持續(xù)精進下去