2021-7-29 濤濤
本來這樣的形式已經司空見慣，足以應付。但寫這個文章的契機，是因為去年接了一個令人頭禿的項目，這是一個平臺項目，在這個平臺上有 30 多個APP，核心干系人包括運營/APP產品經理/平臺開團隊/PO/APP的開發團隊 ，位置不同，利益點也不一樣，并且這里每個團隊核心干系人都不是一個人，而是 2-3 個人，對接人有層層回匯報關系。拋開項目本身業務是專業領域的內容學習成本高不說，就干系人管理這一項就頗為棘手。
在這個項目中我遇到了哪些問題：
干系人繁多，有三股神秘力量
業務復雜，專業性極強，訪談過程全是專業術語
PO 不是核心決策人
項目中后期，出現新的干系人
團隊成員能力需要培養
時間緊張。客戶預算有限，就我們自己預估的時間直接砍半
綜上，這個項目著實做掉了不少頭發，這樣的項目要怎么做呢？希望大家在遇到這樣的項目的時候也少走一些彎路。聊到這里，就要聊一下項目管理是什么了，我們從頭來梳理以下，查漏補缺。也是對自己的一次復盤
·項目管理是有效資源整合，高效實現目標的一整套管理理念
·在復雜多變的環境中，如何做好一件事情
按照時間軸羅列，項目管理分為：啟動 規劃 執行 監控 收尾
那我套用到設計的項目管理，大致會分為以下幾個階段：
項目開始，在正式進入客戶場地以前，就是項目啟動階段，該階段需要了解：
項目：
項目的整體背景
挑戰
目標
項目范圍
時間周期
客戶關注方向
干系人：
客戶組織框架
核心關系人數量，匯報關系
是否有第三方人員對接
是否有合作的同類型角色
現狀：
該項目是否存在上下游系統，是否有依賴
現有系統狀態（是否有現存系統，沒有是如何完成工作過的）
里程碑規劃：
基于以上所了解到的信息，對項目全局時間計劃有整體性安排，明確項目被劃分為哪些階段
階段性產出和匯報時間節點梳理
（需要拉入客戶進來討論的時間節點需要提前規劃，需要邀請用戶研究的時間段需要提前規劃）
規劃里程碑時，一定要考慮部分風險和可變化因素 ，比如需求變更，干系人多，溝通成本增多，匯報層級鏈路長 ，需要等待領導決策，或者部分業務內容可能涉及第三方的一些依賴，合理增加里程碑的總體規劃時間 ，后期可以優化和調整規劃內容，在一定規劃時間內，部分階段可以適當延長，其他的相應縮短，給項目一些buffer，減少項目延期的風險。
成員安排：
對安排上來的小伙伴需要有一定的了解，了解人員的能力方向。安排能匹配或是跳一跳能摸得著的難度系數任務
如果上項目的小伙伴經驗比較少，需要建立團隊培養機制
保證項目成員安排的連續性，最好不要出現中間停一段時間，后面在續上，或者每天只安排0.2天
在安排時間計劃上，需要注意哪些工作是無法通過加人來完成的
資源規劃：
資源包括：人/物/場地
人：外部專家支持/其他部門支持（除內部項目人員外）
物：workshop要用到的所有工具，包括白紙，筆，便利貼，藍膠，馬克筆，故事卡等等
場地：日常辦公場地/會議場地
風險識別：
根據現有狀況，預測部分可能風險
將想到的可能風險一一列舉出來，并給出相關應對措施，這個如果無法獨立完成，可以和甲方一起協商完成。
當風險點都已經列舉完成，為了避免風險，大家需要提前達成一致的東西，提起和大家同步信息，如定義項目上的規則，保證會議不延期，要提前一周安排會議時間，保證信息同步，每天or每周制定同步會議。當需求變更，或者需求膨脹的情況下，可以參考的優先級排序，根據某項原則，完成優先級排序，將非必須的需求先劃分出去，保證需求在一定合理的范圍內。
枚舉風險有兩個好處：
預判一些可能的風險，提前做好準備工作
拉著客戶與團隊一起定義規則，不要隨意破壞
可以用這樣的表格管理風險，也可以直接在后面加上這個對應項的相關責任人，有什么問題，我們可以方便 跟蹤
舉例子：
風險點：比如會議干系人核心無法到場，造成會議延期，那么遇到這種情況怎么辦呢？
應對措施：提前和核心干系人確定時間，雙方協商會議時間，提前一周規劃時間安排，合理調整時間
風險點：疫情期間，出差隔離時間不可控
應對措施：Plan A 出差前提前了解當地相關政策，提前到達辦公地區。Plan B：部署遠程工作環境，建立信息共享機制，建立定期會議時間，同步信息，如果不能按時到達現場，可以啟用的Plan B
粗顆粒度任務拆分：
還是基于里程碑規劃的圖示舉例，在途中表示出來每一個階段的階段性活動是什么，產出物是什么，對齊產出物的顆粒度以及內容
愿景對齊：
讓所有的核心干系人參與該活動，避免大家后面信息沒有對齊，目標沒有對齊，產出結果無法達成一致。
高能預警：此處有深坑：注意避坑。
我參與的這個項目，如開頭所說有三股神秘的力量（在開始階段PO 都沒有介紹是三股力量，而是2邊，他們的關系有點復雜），但是由于地域影響，和各個力量之間存難以琢磨的關系，他們并沒有同時出現在愿景對齊工作坊中，來參加工作坊的只有一波人。愿景工作坊順利完成，項目目標，干系人關系，在這里才得以澄清。
雖然后面抄送了全員，并單獨去找了另外一邊的老大溝通目標，才發現他的目標和其他人的都不一樣，甚至應該不屬于這個項目范疇。
此事件復盤：
核心決策人必須參加
如果核心決策人沒有發表意見，請主動請他來表達觀點
如果實在無法到場，和他1Vs1的郵件會議紀要也要抄送全員。
如果發現多方意見無法統一，請不要繼續項目，把他們拉在一起，對齊愿景再出發
以下附上愿景對齊的工具——電梯演講
在項目開始階段，我們都會進行愿景工作坊，拉上所有的核心干系人一起，通過貼便利貼的方式，將大家的理解收集起來，并對所有的便利貼進行分類，最終收斂出最為核心的電梯演講
電梯演講海報的相關原則：
精煉，簡介——這個愿景海報將伴隨整個項目，越簡單越容易被人回憶起來
對于用戶需求這一項，大家一定會寫很多很多，但是在項目初期，大家寫出來的需求很多是作為客戶方，理解用戶想要的東西，是不是真實需求，還需要進一步被細化，所以這里對整體需求做較大顆粒度的歸納即可，不要深入細節
電梯演講可以出幾張？部分小伙伴可能會問我的目標用戶差異很大，出兩張，三張可以嗎，可以！可以將上半部分分開，比如目標用戶 For 哪幾類人群，他們的需求差異也可以規組，但是下半部分，產品名稱，產品形態，幫助企業獲得的價值，以及競品和賣點，可以是一致的，都可以在一張海報上所呈現
干系人識別：
我們大致梳理了公司的管理層級。現在要把他們匹配到相當的關注層級之中
識別哪些干系人是重點關注的，那些是一般關注即可
高能預警：此處有深坑：注意避坑。一般來說項目的干系人優先級都比較穩定，不會發生改變，但是在去年的那個項目里面完全不同了，在項目的第一階段干系人A非常的重視，干系人B基本沒有太多的意見，但是到了項目的第二個階段，畫風發生了反轉，干系人A參與的越來越少，相反干系人B有更多的見解和想法。對于不同的干系人，他們想要的成功是不一樣的。需要明確不同階段核心干系人的差異，匯報給不同人有不同側重點。
所以在干系人梳理這塊，還需要注意的點是：
如果workshop 這種形式的大會很難讓干系人透露心聲，可以通過通過 1vs1 的溝通了解他們的真實需求，問他們的KPI是什么，是非常直接詢問他們最關系問題的方式。這對于復雜干系人的項目尤為重要。
也可以在workshop上新增期望對齊的環節，在下一個part會講到。
以下附上愿景對齊的工具——干系人/團體地圖
下面兩種干系人/團隊地圖的差異不大，可以根據需要任選其一即可，圖一更多可以梳理出干系人，或者團體之間的關系，除了判定干系人的權重，還可以在途中不中干系人之間匯報的關系，以及他們之間使用的不同系統的關系
下圖也是對干系人的權重和優先級的排序，與上圖不同的地方在于它更清楚的展示了我們如何去區分這些干系人的維度，維度可以根據項目需求哦進行變化。
期望對齊：
從各個維度對齊干系人對項目的期待
幫助干系人對各個維度有一些認知
這個有兩種做法，如果是干系人相對簡單的項目，可以在電梯演講的海報哪里，加上一類表示這個項目期望達到的目標，可以是定型的，如果團隊中有很好的數據監控埋點，這個指標也可以是定量的。如果干系人繁多，大家對想要達成的期望不是非常明確的時候，可以加上這個環節，這樣也能方便我們了解我們在項目過程中應該如何側重，因為現場的時間非常有限，我們不對所有的期望一一判斷是否合理。會在會后對一些超出范圍的期望和項目負責人達成一致。事先，可以列舉以下幾個維度，幫助大家思考：功能，項目本身，技術，體驗和成效，維度可以隨項目目標的不同自由變更，如果大家還有新的維度，也可以在現場添加
以下附上對齊期望的工具——期望看板
權重識別：
這個是千萬不要省略的一個對齊項目，后面有諸多事宜，我們需要跟俊權重的識別來判斷。比如在需求膨脹的時候，我們用什么方式判斷那個需求的優先級更高，應該把哪些需求摘出去。或者在做一些決策的時候，用來判斷，那些事我們應該優先處理，而另一些我們可能需要有一些妥協。后面在說到項目執行過程各種突入起來的變故的時候，這個參考項是必不可少的。在文章后面會更為詳細的列舉。
輔助決策
判斷優先級
以下附上權重識別的工具——權衡滑塊
詳細日程排期：
細化工作安排
提前約定相關干系人時間
提前預約用戶驗證時間
注意那些是客戶需要參與的時間點，無比準確
以下附上詳細日程排模版，這個相對來說沒有特定的方式，可以做到 Excel 表格中管理。也可以放到 日歷 中管理，當然如果你們有設計排期的服務軟件，都可以使用，我這里只呈其示意樣式
下一步我們就是正式開始進入項目拉
任務優化調整：
進一步的細化工作安排，如果發現團隊的小伙伴是新手，無法上手，就需要對任務進行拆分，拆分到什么顆粒度呢，拆分到團隊的小伙伴可以上手的顆粒度，當然拉，千萬不要全部包辦代替的把它做完。在項目允許的范圍內，讓風險發生！這是團隊人才梯隊建立的關鍵時刻，說到這里，如何培養團隊設計能力，又是一篇長篇大論了，我們回歸正題。如過小伙伴就有很多經驗，那就更可以安心的把整快大的蛋糕分給他，把他劃分為責任人，下面的工作內容如何拆解，應該分幾步來做，請放手。只用在關鍵節點和把控質量就好。
明確產出目標
明確產出內容
明確產出目的
明確產出物依賴
拆分責任人：
這塊和上訴的任務優化調整是聯系在一起的，當我們合理拆分任務后，當然要他這個任務匹配到相關的責任人，如任務優化調整所訴，可以是比較大的一大塊任務，比如信息架構這一個大塊，用戶調研這個大塊，制定相關人作為Owner ，至于他如何來拆解自任務，還需要請到那些人進行協作，由Owner 來全權負責，Owner 是需要對結果負責的人 。如果是新人，拆分成一個大塊是無法下手的，并不知道我每一步應改怎么做，那就把大蛋糕切細，切到他可以嘗試下咽的顆粒度即可。
在項目活動中，對于2個設計師以上的團隊，我們就可以利用設計看板。長期做敏捷交付的小伙伴對這個工具一定不會陌生。
對于有經驗的人，按照大塊拆分
對于新人，在按大塊拆分以后，需要對分支任務或是階段任務在進行下一步拆解
以下附上日常設計工作管理工具——設計看板
還是那句話，有設計進度跟蹤的工具的小伙伴請繞道哦，這個是非常簡單的且直白的一種設計管理模型，這樣就可以每日跟蹤大家的手上的工作進度了，也可以跟中哪些任務已經完成拉。上面的標題欄“待設計”“設計中”“已完成”也可以根據項目的不同階段，放置不同的標題，當我們設計完成后，就可以領取新的設計任務拉。
每天這樣移動卡片會不會亂呢，怎么和大家同步信息呢？那我們就要說到設計工作中一個關鍵活動了？
站會/業務對齊會
組內同步：
每日站會對項目來說是比不可少的，一般會定在每日早上，項目全體小伙伴都要參加，上班的第一件事就是開站會拉，多么有儀式感的一天，站會通常會占用10-15mins，站會可以用來：
同步信息包括，昨天，今天的工作內容
提出風險，有困難就喊出來，找大家一起需求幫助
這樣大家就非常明確每個人都在做什么，我的工作有什么依賴，我應該找誰解決獲取上下文，另外就是及時暴露風險。及時尋求幫助
另一項活動是我特別喜歡在團隊中使用的：業務對齊會
當項目比較大，每個設計師或者業務分析師分為了多個條線跟蹤業設計和業務。那業務對齊會也是比不可少的，當然業務對齊會不僅僅可以對齊業務輸入，當需要開發判定方案是否可行，或者需要其他的角色一起討論問題時，我們都會放到放到每日或者隔天的或者隔周的業務對齊會上一起討論，會議頻次根據項目實際情況自行安排，邀請成員通常是設計師和業務分析師一起，又是也會邀請其他角色，視會議需要討論問題而定
方便參與不同業務條線的同學對業務全景保持一致
不對角色的思維方式存在差異，可以轉換視角看待問題
可以相互評審設計稿，業務分析流程等活動，查漏補缺
它的優勢是：
保證出方案時間的完整。不會隨意打斷大家輸入和思考的時間，固定時間同步信息
高效同步信息。不會一次同步太多信息，信息量太大，趨于飽和，會少量多次，最長不要超過1h，如果超過就要增加會議頻次來減少時長。
干系人溝通：
終于寫到干系人溝通了，這真正是一個大坑
干系人溝通有幾個關鍵點：
建立信任 — 一切良好溝通的基礎
頻繁溝通 — 減少風險
及時提出自己的見解 — 體現你的價值
建立信任—特別是在項目開始的時候，這一點是致命的，如果開始時能建立良好的信任關系，那么在后期很多小問題的決策上，還有客戶對你方案的認可上都會容易的多。
如何在項目開始的時候建立信任呢？
對客戶現有產品業務能快速的理解——C端的可繞過（相對比較簡單，容易理解）。這里特指B端產品，部分B端產品的業務有時專業性極強，特別是之前我們做的這個項目，做用戶訪談時，每一句話都能用多個專業術語，你還沒有弄清楚這是怎么回事，就要跟上下一個話題了。對于我們這種非本專業的設計師來說，要想做好設計，提升用戶體驗，開始就要建立對產品業務的了解。
-自主學習，通過各種渠道找學習課件，提前對該領域專業術語作出梳理；對相關的背景知識有所了解，對領域現狀有所認知，包括現存的競品也可以找來看看，借鑒學習。
-找領域專家尋求幫助，對于是在無法獲取經驗的領域，也找不到相關的一些信息渠道，可以涉及到一些行業機密，可以酌情尋找第三方領域專家，和領域專家進行訪談，從他們哪里可以拿到很多一手資料。當我們對項目有一些假設時，也可以找領域專家驗證假設的可行性
-向訪談對象學習，可以判斷訪談對象的性格特質，如果很明顯的流露出善于表達，喜歡和你傾訴更多的信息，那么可以把握好機會，適當的詢問一些領域問題
-向客戶學習，PO也許不負責具體的業務條線，也可能多年不再碰具體的業務操作，但是他們對于理論的掌握還是有一定的借鑒作用的。
當然了，現在收集到了這么多信息，還需要整理和消化，并且驗證信息的可靠心是否是正確。
多渠道信息交叉驗證
信息之間能否相互關聯，相互串聯，形成閉環
專業技能維度——專業能力維度是設計師的立足之本了，毋庸多說，但這里需要強調幾點
-設計邏輯清晰，設計結果很重要，但設計思路同樣重要，很多設計師在展示自己的方案的時候，只呈現做了什么，結果如何，很好，很精良，但是一定要有邏輯連貫的思考過程，才能體現你的思維邏輯，我們的方案不是憑空捏造的，不是一拍腦袋想出來的，我們的設計是經經過了哪些步驟，這個步驟的作用是什么，設計結論是如何推倒的，這樣的設計包含了哪些設計原理 ，好處是什么。犧牲了什么，如何權衡它的犧牲的。
設計從戰略層倒表現層，越是取近于表現層，其評判標準就越主觀，眾口難調，特別是面向非設計領域的專業人員來說，這個評判標準在我們手上，我們要給出來我們這樣做的理由是什么，好處是什么，才能得到客戶的信任。
頻繁溝通 不要悶頭設計哦，在項目的每個階段都要定義定期展示案例的時間點，除了這些時間點外，還可以約
這里從問題的角度來會切入吧
需求變更，反復無常
半路殺出程咬金 — 干系人變更
增加項目范圍
老大不滿意
干系人意見沖突
干系人不認之前做的決策
》需求變更，反復無常
一般情況下，按照正常的項目流程來走，我們我們通過痛點發散出來的機會點一步步的收斂出需要繼續設計的方案后 ，用戶側的需求優先級是已經被考慮進去的，所以突然變更的需求大多可能是來自也無方，或者超級VVVIP 用戶
判斷是什么類型的需求？
合理需求：可以對需求進行規劃，判斷項目需求的優先級，如果合理且緊急，可以和相關干系人對齊，給予初步方案計劃，對部分現有需求做出置換（如果干系人經常變更需求，可以對設計方案作出估點，按照人/天置換需求），如果合理不緊急，拿出我們的權衡滑塊， 明確需要 foucs 在當前項目優先級下，不要過于發散，可以定制相關產品演進路線通過迭代演進方式逐步實施
不合理需求：可以委婉拒絕，如果實在無法拒絕，可以花費一些小effort，告知他為什么不合理
》半路殺出程咬金—干系人變更
可以在識別核心干系人的時候，詢問清楚在項目進行過程中是否有核心干系人的變更，提前識別
有時干系人的變更是突然的，無法提前識別，不要慌，繼續往下做。一般干系人變更可能會帶來以下問題：
要推翻之前的方向——相當于要從新立項，如果方向都被否定了，就不要繼續往下做，及時止損，重新規劃項目方向。
要新增項目范圍——新增的范圍非常大，大到可以重新規劃一個新的項目，就在規劃新的項目；如果新的范圍可控，還是根據本項目的權衡滑塊來判斷,哪些是優先級高的范圍，先做，不高的置換出來。
》老大不滿意
1.減少老大不滿意的風險，就是多建立溝通，最好可以親自向上層級匯報。
2.保證方案的邏輯性，所有的設計思路都是有據可依。
3.保證方案給用戶給企業帶來的價值。對于比較成熟的項目，最好價值是可以被量化，可衡量的，如果無法用數據橫向衡量，可以用定性的方式來判斷價值，比如在用戶驗證的時候，檢測新的方案是否能滿足客戶的需求，用戶對新的方案是如何評價的，在無數“證據”下，老大也不會無緣無故的不滿意
》干系人意見沖突
不要做干系人之間的傳話筒
拉著意見不一致的干系人一起討論問題
》干系人不認之前做的決策
這件事情在某些客戶干系人身上還挺常見的，對于超級難管的干系人，每次大會都要發郵件，不是不敏捷，是為了介紹缺少文字證據，而出現更多的坑
重要結論，會議紀要+郵件跟蹤
注意：一定要結論先行，大部分的人沒有耐心看完所有的內容，但是加粗字體的會議結論是能簡明扼要的概括，本次會議通過了什么決策。有什么遺留事件，具體的責任人是誰，需要完成的截止事件都要標明
以下附上郵件紀要的格式介紹
這個過程和項目執行的過程應該是穿插進行的，時間是非常有限的，不要面面俱到的跟蹤，抓大放小，只在關節節點驗收，比如前面項目執行中提到的如何拆分任務，同理，在驗收的過程中，也可在組內的對齊會上驗收設計輸出內容是否符合標準，是否有易用性問題，如果這是非常細小的圓角，交互的方式，布局的方式，可以交給團隊成員自己把控，如果一個設計師從用戶體驗要素的5層出發，每一層都面面俱到，無微不至，在這樣的大項目里面是很難管理的，把更多的空間留給設計師自己。
把有效的時間集中放在有較大提升價值的事情上：
保障產品價值交付
用戶體驗是否有所提升
現有的資源下，如何平衡，實現價值
拆分對內驗收節點：
把大的任務蛋糕拆分給每一個小伙伴后，他具體怎么吃，可以讓他自行安排，告知完成的時間階段，在特定時間端內驗收質量問題。
定期復盤：
通常我們通過 Retro 的方式進行復盤，時間周期視項目的時長來定，較短的項目可以安排為每兩周一次的 Retro，Retro 的步驟。1.宣誓（可以跳過）/2安全性檢查/3分別梳理 好的部分，不好的部分，和建議。好的部分鼓勵團隊繼續保持，不好的部分通過投票，選取前 Top 問題進行 討論整改建議。在下一次的 Retro 的時候進行復盤，看看這些問題是否都有改進。
當然還有很多做復盤的方式，方法本身不是最重要的，復盤的核心就是為了改進上一階段做的不好的地方，并且在下一階段有所改進措施。讓項目運行變得越來越好。
進度跟蹤：
通常會用項目周報的方式，想客戶展示項目的進度，現在進行到項目的什么階段，有哪些產出物，項目是否存在風險，項目計劃及人員投入比例
整體&歸檔：整理交付物，包括設計資產，使用說明和相關目錄，方便其他人員可以持續迭代
設計歸檔包含的重要組成部分包括且不限于：
設計源文件
用戶研究報告
用戶驗證錄屏材料
用戶訪談大綱
遺留問題跟蹤
Showcase材料
知識傳遞錄屏
...
如果文件夾過于分散，則需要寫一張目錄，目錄上附上文件夾的鏈接，方便呢其他的小伙伴能快速的找到
知識傳遞：注意保留錄屏文檔，當項目人員變更，可以及時傳遞上下文
在做知識傳遞之前，要和大家確認現有的產出，保障產出物不會在作修改，保障所有人都達成一致后，在開始后做知識傳遞。
做知識傳遞的時候，一定要記得錄制屏幕，以防有的小伙伴沒有參加，或是之后還要分享給其他的小伙伴使用，這樣就可以避免一邊一邊的重復人工講解啦，還有預留給大家提問題的時間，看看大家還有沒有不清楚的地方，盡量在會上一一解答。
PS：還想再分享一個，當項目中所要處理的事情過多時，如何排列優先級的問題
一般情況下，先看一下這些事情的依賴關系/事件難度，當緊急成度都很高的情況下
有依賴的關系的一般需要提前去收集信息，跟催進度，但花費是假相對較多，可能還有相互依賴，外力因素不可控
或者需要提前與人溝通事件，判斷溝通時間是否合適，但花費是假相對較少，但需要提前預約，外力因素不可控
事件越難的越需要留更多的時間處理，內在因素不可控，事件簡單的則可以安心放在后面進行，內在因素可控
可以按照風險等級排序方案：信息收集類> 約人溝通類>困難事件類>簡單事件類
分享此文一切功德，皆悉回向給文章原作者及眾讀者.
免責聲明：藍藍設計尊重原作者，文章的版權歸原作者。如涉及版權問題，請及時與我們取得聯系，我們立即更正或刪除。
藍藍設計( www.73404.com.cn )是一家專注而深入的界面設計公司，為期望卓越的國內外企業提供卓越的UI界面設計、BS界面設計 、 cs界面設計 、 ipad界面設計 、 包裝設計 、 圖標定制 、 用戶體驗 、交互設計、 網站建設 、平面設計服務
文章來源：站酷 作者：青沐CHIMO