以下是本人一個真實項目的經(jīng)歷，如有雷同純屬巧合。

2018年9月下旬，因同事離職臨時接了一個項目，是公司內(nèi)部各業(yè)務(wù)線對外提供服務(wù)IM工具的一個更新?lián)Q代，目標(biāo)是將之前各業(yè)務(wù)線自行開發(fā)的各種IM工具全部替換統(tǒng)一新研發(fā)的工具，同時將知識庫平臺遷移到公司最新的AI平臺上。

講故事前，把相關(guān)的項目背景稍微描述下，讓各位看官了解。

1. 項目范圍：接入業(yè)務(wù)線從大的講有10多個業(yè)務(wù)線，有些業(yè)務(wù)線內(nèi)部還有不同業(yè)務(wù)形態(tài)和服務(wù)場景的小業(yè)務(wù)；每個業(yè)務(wù)基本會分售前售后，還有給外部供應(yīng)商用的平臺。
2. 原有工具：app端大概有2~3個業(yè)務(wù)線自研的工具，還有微信群等外部工具；online端有獨立的工具，H5也有獨立的工具，還有自己的知識庫。
3. 目標(biāo)用戶：用戶1是公司所有終端用戶，用戶2是各業(yè)務(wù)線服務(wù)部門坐席，用戶3是外部供應(yīng)商。公司內(nèi)部坐席加起來大概有幾千的坐席，坐席服務(wù)解答客人問題的工具，有PC端、手機端；
4. 接入工作量：各業(yè)務(wù)線研發(fā)團隊需要和我們研發(fā)團隊對接，完成新IM工具的對接，且部分業(yè)務(wù)線因業(yè)務(wù)邏輯復(fù)雜需要自行維護分配分層邏輯。

接手項目后， 第一步肯定是了解項目背景和目標(biāo)，了解過后第二步干嘛呢？熟悉項目團隊。

經(jīng)過幾次會議，基本熟悉了項目組織架構(gòu)，內(nèi)部涉及6個team，從外到內(nèi)分別是：

1. app端研發(fā)
2. app 服務(wù)端研發(fā)
3. 客服端研發(fā)
4. 知識庫AI研發(fā)
5. 報表BI研發(fā)
6. 產(chǎn)品經(jīng)理團隊

幾個team都有自己的垂直匯報領(lǐng)導(dǎo)（職能結(jié)構(gòu)）

接手后發(fā)現(xiàn)困難是什么呢？

1. 有1個大業(yè)務(wù)線已經(jīng)接入新IM工具，但一直生產(chǎn)灰度驗證沒有明確的開流量時間表；
2. 另有1個大業(yè)務(wù)線自己花了2年多時間開發(fā)的類似工具，用戶使用也很習(xí)慣，要改動比較難；
3. 項目內(nèi)部團隊多，各團隊開發(fā)進度等信息透明化程度不高，尤其聯(lián)調(diào)階段進度緩慢；
4. 項目階段目標(biāo)不夠清晰，甚至有些團隊成員并不了解；
5. 現(xiàn)成產(chǎn)品無法cover所有業(yè)務(wù)線的需求，很多業(yè)務(wù)線都有自己個性化的需求，很難統(tǒng)一，所以每接入一個業(yè)務(wù)線工作量都很不小。
6. 領(lǐng)導(dǎo)們對項目完成時間過于樂觀（12月底完成全部業(yè)務(wù)線接入）。我接手時好像就接入了1家大業(yè)務(wù)線。要在3個月時間完成全部接入，難度非常大，項目組內(nèi)部戲稱“不可能完成的任務(wù)”。

針對這些項目背景、組織架構(gòu)、已知問題，采取了以下措施：

1.針對架構(gòu)， 引入大規(guī)模敏捷模式，我任項目SM，負(fù)責(zé)項目整體的里程碑進度及對外協(xié)調(diào)，重要問題的升級；

2.產(chǎn)品團隊進入各開發(fā)team作為PO并兼任SM，負(fù)責(zé)條線產(chǎn)品需求及優(yōu)先級安排，同時負(fù)責(zé)對BU的需求溝通，同時每個PO會負(fù)責(zé)一個大業(yè)務(wù)線的對接；

3.加強團隊間溝通：做了“集中辦公”“War room”“一起加班吃晚飯”等。還好這幾個開發(fā)team基本都在一個樓層，溝通比較方便，然后我從其他樓層就搬到他們那邊，一起辦公。War room主要是為了占個小會議室，我們的日站會、臨時會議都在這個War room；加班自然不可避免，每天和不同團隊同學(xué)一起吃個晚飯順便了解一些他們工作進展也對項目整體非常有幫助。

4.每日站會。除各開發(fā)team自己組織的站會外，大項目組每天都會站會，team leader和PO參加，站會除了review白板的重要事件外，主要就是各種問題的碰撞；當(dāng)然作為SM需要把控會議，我們用了口哨、鈴鐺來應(yīng)付大家大聲亂討論問題的情況。細(xì)節(jié)問題，一般是站會后，留下相關(guān)同學(xué)再行溝通，站會只需要明確問題的負(fù)責(zé)人及要求解決時間。

5.物理看板，我來維護。一般根據(jù)發(fā)布節(jié)奏2-3周一次看板，標(biāo)明階段目標(biāo)、當(dāng)前階段的主要任務(wù)及里程碑事件。詳細(xì)需求或任務(wù)會在各team的白板。每次迭代前啟動會，根據(jù)階段目標(biāo)，分解任務(wù)到各team，尤其是一些需要互相聯(lián)調(diào)的點，明確責(zé)任和時間點。各team領(lǐng)到任務(wù)后內(nèi)部再行拆細(xì)。

6.會議：每個沖刺都有啟動會和回顧會。啟動會明確目標(biāo)、團隊進行撲克估算、分解任務(wù)，認(rèn)領(lǐng)任務(wù)?；仡檿罕┞秵栴}，總結(jié)經(jīng)驗。

7.“虛擬專家組織”：因為涉及開發(fā)team比較多，在遇到一些技術(shù)問題，尤其是架構(gòu)性問題時，需要有一些“專家判斷”，所以組織了一個虛擬組織，每當(dāng)有一些重大技術(shù)問題需要拍板時，由他們進來做分析判斷。

8.先打一個有把握的勝仗。對于一個周期較長的項目，能取得階段性的成績并讓大家看到，這對項目推動有積極的作用。我在接手項目后，第一時間和前面提到的“已上線但遲遲無法開流量”的大業(yè)務(wù)線取得溝通，非常幸運的是這個大業(yè)務(wù)線的聯(lián)系人非常負(fù)責(zé)也很細(xì)心（當(dāng)然也因為太細(xì)心提了很多問題，哈哈）。和這位聯(lián)絡(luò)人溝通后，我拿到了開流量前置問題的list，然后立馬在內(nèi)部召集各team開會一一過問題（記得大概是50多個問題），然后看下來這些問題都可以解決的。Sure，作為最高優(yōu)先級處理。很快，一個迭代，這些問題都得到了解決。然后這個業(yè)務(wù)線在10月下旬開放了流量，打了第一個勝仗，也吹響了全面進攻的號角。

9.Checklist：綜合之前項目的經(jīng)驗，我梳理了一個checklist（在confluence全團隊可見可維護），標(biāo)注了需要完成的業(yè)務(wù)線、對應(yīng)聯(lián)系人、計劃上線時間、前置任務(wù)（比如知識庫維護、分配邏輯聯(lián)調(diào)、入口發(fā)布、AB分流配置、外部依賴項等）、流量開放任務(wù)，完成的事項就打上勾，沒完成的會主動去push完成。這樣一來，全團隊對項目整體的狀態(tài)、下一步方向都心里有數(shù)。

10.到一線用戶中去。因為是一個偏業(yè)務(wù)產(chǎn)品的項目，實際用戶的體驗和反饋對我們尤其重要，所以我們要到一線去。除了去上海的服務(wù)部門職場外，我們還去了南通服務(wù)職場，和一線操作用戶進行了面對面現(xiàn)場的溝通，了解他們的實操場景及訴求，對于我們了解需求、需求設(shè)計有了非常好的幫助。

11.借助外部或高層力量。這個項目可以算是公司級別，涉及全公司的服務(wù)部門，所以公司服務(wù)中心會有專人監(jiān)督和支持我們項目，他們會定期召集BU和我們一起溝通問題、解決問題。有些我們搞不定或者認(rèn)為不合理的問題，就會拉上他們一起和業(yè)務(wù)線協(xié)商，也感謝他們的支持。

12.抓大放小。我既是項目經(jīng)理，也是大規(guī)模敏捷群的SM。因為這個項目過于龐大復(fù)雜，工期又緊。需要關(guān)注處理的事情非常多，如果作為大SM過于關(guān)注細(xì)節(jié)問題，自然你會漏掉一些重要事件。所以，你必須抓大放?。ó?dāng)然不是完全不管，而是授權(quán)給其他同學(xué)去負(fù)責(zé)）。作為敏捷群的大SM需要對項目有一個high level的總覽思路，牢牢抓住為達成總目標(biāo)服務(wù)的關(guān)鍵事件并去完成它。（實際上前面提到的checklist也有異曲同工）

最后，故事要講完了，說下目前項目完成情況。截止18年12月底，目標(biāo)范圍的業(yè)務(wù)線全部完成接入，當(dāng)然項目還沒最終完成，因為新老工具的流量還在逐步切換，欲知后事如何，且聽下回分解。