2次轉(zhuǎn)管理失敗后，我對項目、團隊、敏捷轉(zhuǎn)型的新認知

孫沖

輪子科技項目主管

• 關(guān)注人、技術(shù)、架構(gòu)三者聯(lián)系，現(xiàn)在的工作方向為微服務(wù)、DDD、中臺、架構(gòu)、項目管理以及敏捷相關(guān)。

• 對業(yè)務(wù)架構(gòu)感興趣，當前正在嘗試DDD在項目中的落地。

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

主要由以下五部分內(nèi)容組成：

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

時間線分為三部分：

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

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

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

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

那么在以上這些背景下大家能夠預(yù)料到存在哪些問題？

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

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

第二個現(xiàn)象：級別差距懸殊，沒有話語權(quán)

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

經(jīng)常是我們非常不理解領(lǐng)導(dǎo)層這么快上線的初衷，也就是不能夠明白這一次迭代的價值。

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

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

第四個現(xiàn)象，會議多而長

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

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

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

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

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

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

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

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

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

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

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

1）重構(gòu)32個接口是怎么回事呢？

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

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

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

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

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

3、瀑布模式的痛

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

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

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

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

4）嘗試敏捷

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

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

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

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

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

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

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

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

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

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

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

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

3）那個時候?qū)ο蛏瞎芾碚J知不夠

以前總覺得領(lǐng)導(dǎo)就是必須主動關(guān)心我，如果不經(jīng)常關(guān)心我我就覺得自己被拋棄了，被忽視了。

4）對于心態(tài)

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

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

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

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

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

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

我從書中總結(jié)，現(xiàn)實中再去實踐后，又有了一些收獲和思考。

1、物理面板

優(yōu)勢：

不足：

方案：

1）堅持物理面板：

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

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

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

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

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

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

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

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

建議：

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

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

難點：

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

3、計劃

4、估算

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

5、開會

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

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

建議：

6、評審

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

7、代碼走查

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

8、驗卡

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

9、技術(shù)債

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

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

10、項目總結(jié)

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

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

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

敏捷有標準嗎？

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

敏捷不是銀彈

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

敏捷的價值

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

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

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

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

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

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

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

2、平級溝通

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

3、向下溝通

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

4、向上溝通

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

5、項目管理

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

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

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

附錄：書單

特別推薦一個分享架構(gòu)+算法的優(yōu)質(zhì)內(nèi)容，還沒關(guān)注的小伙伴，可以長按關(guān)注一下：
長按訂閱更多精彩▼
如有收獲，點個在看，誠摯感謝