轉自本人營運的公衆号“ 攜程技術中心PMO”（ID：cso_pmo）
以下是本人一個真實項目的經曆，如有雷同純屬巧合。
2018年9月下旬，因同僚離職臨時接了一個項目，是公司内部各業務線對外提供服務IM工具的一個更新換代，目标是将之前各業務線自行開發的各種IM工具全部替換統一新研發的工具，同時将知識庫平台遷移到公司最新的AI平台上。
講故事前，把相關的項目背景稍微描述下，讓各位看官了解。
1、項目範圍：接入業務線從大的講有10多個業務線，有些業務線内部還有不同業務形态和服務場景的小業務；每個業務基本會分售前售後，還有給外部供應商用的平台。
2、原有工具：app端大概有2~3個業務線自研的工具，還有微信群等外部工具；online端有獨立的工具，H5也有獨立的工具，還有自己的知識庫。
3、目标使用者：使用者1是公司所有終端使用者，使用者2是各業務線服務部門坐席，使用者3是外部供應商。公司内部坐席加起來大概有幾千的坐席，坐席服務解答客人問題的工具，有PC端、手機端；
4、接入工作量：各業務線研發團隊需要和我們研發團隊對接，完成新IM工具的對接，且部分業務線因業務邏輯複雜需要自行維護配置設定分層邏輯。
項目背景
接手項目後，第一步肯定是了解項目背景和目标，了解過後第二步幹嘛呢？熟悉項目團隊。
經過幾次會議，基本熟悉了項目組織架構，内部涉及6個team，從外到内分别是：
1、app端研發
2、app 服務端研發
3、客服端研發
4、知識庫AI研發
5、報表BI研發
6、産品經理團隊
幾個team都有自己的垂直彙報上司（職能結構）
接手後發現困難是什麼呢？
1、有1個大業務線已經接入新IM工具，但一直生産灰階驗證沒有明确的開流量時間表；
2、另有1個大業務線自己花了2年多時間開發的類似工具，使用者使用也很習慣，要改動比較難；
3、項目内部團隊多，各團隊開發進度等資訊透明化程度不高，尤其聯調階段進度緩慢；
4、項目階段目标不夠清晰，甚至有些團隊成員并不了解；
5、現成産品無法cover所有業務線的需求，很多業務線都有自己個性化的需求，很難統一，是以每接入一個業務線工作量都很不小。
6、上司們對項目完成時間過于樂觀（12月底完成全部業務線接入）。我接手時好像就接入了1家大業務線。要在3個月時間完成全部接入，難度非常大，項目組内部戲稱“不可能完成的任務”。
針對這些項目背景、組織架構、已知問題，采取了以下一些措施：
1、針對架構，引入大規模靈活模式，我任項目SM，負責項目整體的裡程碑進度及對外協調，重要問題的更新；
2、産品團隊進入各開發team作為PO并兼任SM，負責條線産品需求及優先級安排，同時負責對BU的需求溝通，同時每個PO會負責一個大業務線的對接；
LeSS架構
3、加強團隊間溝通：做了“集中辦公”“War room”“一起加班吃晚飯”等。還好這幾個開發team基本都在一個樓層，溝通比較友善，然後我從其他樓層就搬到他們那邊，一起辦公。War room主要是為了占個小會議室，我們的日站會、臨時會議都在這個War room；加班自然不可避免，每天和不同團隊同學一起吃個晚飯順便了解一些他們工作進展也對項目整體非常有幫助。
4、每日站會。除各開發team自己組織的站會外，大項目組每天都會站會，team leader和PO參加，站會除了review白闆的重要事件外，主要就是各種問題的碰撞；當然作為SM需要把控會議，我們用了口哨、鈴铛來應付大家大聲亂讨論問題的情況。細節問題，一般是站會後，留下相關同學再行溝通，站會隻需要明确問題的負責人及要求解決時間。
5、實體看闆，我來維護。一般根據釋出節奏2-3周一次看闆，标明階段目标、目前階段的主要任務及裡程碑事件。詳細需求或任務會在各team的白闆。每次疊代前啟動會，根據階段目标，分解任務到各team，尤其是一些需要互相聯調的點，明确責任和時間點。各team領到任務後内部再行拆細。
團隊實體看闆
6、會議：每個沖刺都有啟動會和回顧會。啟動會明确目标、團隊進行撲克估算、分解任務，認領任務。回顧會：暴露問題，總結經驗。
攜程定制估算撲克
7、“虛拟專家組織”：因為涉及開發team比較多，在遇到一些技術問題，尤其是架構性問題時，需要有一些“專家判斷”，是以組織了一個虛拟組織，每當有一些重大技術問題需要拍闆時，有他們進來做分析判斷。
虛拟專家組織
8、先打一個有把握的勝仗。對于一個周期較長的項目，能取得階段性的成績并讓大家看到，這對項目推動有積極的作用。我在接手項目後，第一時間和前面提到的“已上線但遲遲無法開流量”的大業務線取得溝通，非常幸運的是這個大業務線的聯系人非常負責也很細心（當然也因為太細心提了很多問題，哈哈）。和這位聯絡人溝通後，我拿到了開流量前置問題的list，然後立馬在内部召集各team開會一一過問題（記得大概是50多個問題），然後看下來這些問題都可以解決的。Sure，作為最高優先級處理。很快，一個疊代，這些問題都得到了解決。然後這個業務線在10月下旬開放了流量，打了第一個勝仗，也吹響了全面進攻的号角。
攜程自研項目管理工具iKanban
9、Checklist：綜合之前項目的經驗，我梳理了一個checklist（在confluence全團隊可見可維護），标注了需要完成的業務線、對應聯系人、計劃上線時間、前置任務（比如知識庫維護、配置設定邏輯聯調、入口釋出、AB分流配置、外部依賴項等）、流量開放任務，完成的事項就打上勾，沒完成的會主動去push完成。這樣一來，全團隊對項目整體的狀态、下一步方向都心裡有數。
10、到一線使用者中去。因為是一個偏業務産品的項目，實際使用者的體驗和回報對我們尤其重要，是以我們要到一線去。除了去上海的服務部門職場外，我們還去了南通服務職場，和一線操作使用者進行了面對面現場的溝通，了解他們的實操場景及訴求，對于我們了解需求、需求設計有了非常好的幫助。
和使用者一起工作
11、借助外部或高層力量。這個項目可以算是公司級别，涉及全公司的服務部門，是以公司服務中心會有專人監督和支援我們項目，他們會定期召集BU和我們一起溝通問題、解決問題。有些我們搞不定或者認為不合理的問題，就會拉上他們一起和業務線協商，也感謝他們的支援。
12、抓大放小。我即是項目經理，也是大規模靈活群的SM。因為這個項目過于龐大複雜，工期又緊。需要關注處理的事情非常多，如果作為大SM過于關注細節問題，自然你會漏掉一些重要事件。是以，你必須抓大放小（當然不是完全不管，而是授權給其他同學去負責）。作為靈活群的大SM需要對項目有一個high level的總覽思路，牢牢抓住為達成總目标服務的關鍵事件并去完成它。（實際上前面提到的checklist也有異曲同工）
最後，故事要講完了，說下目前項目完成情況。截止18年12月底，目标範圍的業務線全部完成接入，當然項目還沒最終完成，因為新老工具的流量還在逐漸切換，欲知後事如何，且聽下回分解。
Key Word：靈活總動員,攜程技術中心,靈活實踐幹貨,OKR,攜程技術,大規模靈活,靈活沙龍,靈活社群,攜程PMO