設計師如何做好項目管理？

很多設計師會問，我只是一名設計師呀，項目管理有PM撐腰，我為什么要做項目管理？文本將從設計師的角度來闡述項目管理如何做？

項目管理是什么？

·項目管理是有效資源整合，高效實現目標的一整套管理理念

·在復雜多變的環(huán)境中，如何做好一件事情

按照時間軸羅列，項目管理分為：啟動 規(guī)劃 執(zhí)行 監(jiān)控 收尾

那我套用到設計的項目管理，大致會分為以下幾個階段：

項目開始，在正式進入客戶場地以前，就是項目啟動階段，該階段需要了解：

項目啟動

項目：

項目的整體背景

挑戰(zhàn)

目標

項目范圍

時間周期

客戶關注方向

干系人：

客戶組織框架

核心關系人數量，匯報關系

是否有第三方人員對接

是否有合作的同類型角色

現狀：

該項目是否存在上下游系統(tǒng)，是否有依賴

現有系統(tǒng)狀態(tài)（是否有現存系統(tǒng)，沒有是如何完成工作過的）

里程碑規(guī)劃：

基于以上所了解到的信息，對項目全局時間計劃有整體性安排，明確項目被劃分為哪些階段

階段性產出和匯報時間節(jié)點梳理

（需要拉入客戶進來討論的時間節(jié)點需要提前規(guī)劃，需要邀請用戶研究的時間段需要提前規(guī)劃）

規(guī)劃里程碑時，一定要考慮部分風險和可變化因素 ，比如需求變更，干系人多，溝通成本增多，匯報層級鏈路長 ，需要等待領導決策，或者部分業(yè)務內容可能涉及第三方的一些依賴，合理增加里程碑的總體規(guī)劃時間 ，后期可以優(yōu)化和調整規(guī)劃內容，在一定規(guī)劃時間內，部分階段可以適當延長，其他的相應縮短，給項目一些buffer，減少項目延期的風險。

成員安排：

對安排上來的小伙伴需要有一定的了解，了解人員的能力方向。安排能匹配或是跳一跳能摸得著的難度系數任務

如果上項目的小伙伴經驗比較少，需要建立團隊培養(yǎng)機制

保證項目成員安排的連續(xù)性，最好不要出現中間停一段時間，后面在續(xù)上，或者每天只安排0.2天

在安排時間計劃上，需要注意哪些工作是無法通過加人來完成的

資源規(guī)劃：

資源包括：人/物/場地

人：外部專家支持/其他部門支持（除內部項目人員外）

物：workshop要用到的所有工具，包括白紙，筆，便利貼，藍膠，馬克筆，故事卡等等

場地：日常辦公場地/會議場地

風險識別：

根據現有狀況，預測部分可能風險

將想到的可能風險一一列舉出來，并給出相關應對措施，這個如果無法獨立完成，可以和甲方一起協(xié)商完成。

   當風險點都已經列舉完成，為了避免風險，大家需要提前達成一致的東西，提起和大家同步信息，如定義項目上的規(guī)則，保證會議不延期，要提前一周安排會議時間，保證信息同步，每天or每周制定同步會議。當需求變更，或者需求膨脹的情況下，可以參考的優(yōu)先級排序，根據某項原則，完成優(yōu)先級排序，將非必須的需求先劃分出去，保證需求在一定合理的范圍內。

枚舉風險有兩個好處：

預判一些可能的風險，提前做好準備工作

拉著客戶與團隊一起定義規(guī)則，不要隨意破壞

可以用這樣的表格管理風險，也可以直接在后面加上這個對應項的相關責任人，有什么問題，我們可以方便 跟蹤

舉例子：

風險點：比如會議干系人核心無法到場，造成會議延期，那么遇到這種情況怎么辦呢？

應對措施：提前和核心干系人確定時間，雙方協(xié)商會議時間，提前一周規(guī)劃時間安排，合理調整時間

風險點：疫情期間，出差隔離時間不可控

應對措施：Plan A 出差前提前了解當地相關政策，提前到達辦公地區(qū)。Plan B：部署遠程工作環(huán)境，建立信息共享機制，建立定期會議時間，同步信息，如果不能按時到達現場，可以啟用的Plan B

粗顆粒度任務拆分：

還是基于里程碑規(guī)劃的圖示舉例，在途中表示出來每一個階段的階段性活動是什么，產出物是什么，對齊產出物的顆粒度以及內容

項目規(guī)劃

愿景對齊：

讓所有的核心干系人參與該活動，避免大家后面信息沒有對齊，目標沒有對齊，產出結果無法達成一致。

高能預警：此處有深坑：注意避坑。

我參與的這個項目，如開頭所說有三股神秘的力量（在開始階段PO 都沒有介紹是三股力量，而是2邊，他們的關系有點復雜），但是由于地域影響，和各個力量之間存難以琢磨的關系，他們并沒有同時出現在愿景對齊工作坊中，來參加工作坊的只有一波人。愿景工作坊順利完成，項目目標，干系人關系，在這里才得以澄清。

雖然后面抄送了全員，并單獨去找了另外一邊的老大溝通目標，才發(fā)現他的目標和其他人的都不一樣，甚至應該不屬于這個項目范疇。

此事件復盤：

核心決策人必須參加

如果核心決策人沒有發(fā)表意見，請主動請他來表達觀點

如果實在無法到場，和他1Vs1的郵件會議紀要也要抄送全員。

如果發(fā)現多方意見無法統(tǒng)一，請不要繼續(xù)項目，把他們拉在一起，對齊愿景再出發(fā)

   以下附上愿景對齊的工具——電梯演講

在項目開始階段，我們都會進行愿景工作坊，拉上所有的核心干系人一起，通過貼便利貼的方式，將大家的理解收集起來，并對所有的便利貼進行分類，最終收斂出最為核心的電梯演講

電梯演講海報的相關原則：

精煉，簡介——這個愿景海報將伴隨整個項目，越簡單越容易被人回憶起來

對于用戶需求這一項，大家一定會寫很多很多，但是在項目初期，大家寫出來的需求很多是作為客戶方，理解用戶想要的東西，是不是真實需求，還需要進一步被細化，所以這里對整體需求做較大顆粒度的歸納即可，不要深入細節(jié)

電梯演講可以出幾張？部分小伙伴可能會問我的目標用戶差異很大，出兩張，三張可以嗎，可以！可以將上半部分分開，比如目標用戶 For 哪幾類人群，他們的需求差異也可以規(guī)組，但是下半部分，產品名稱，產品形態(tài)，幫助企業(yè)獲得的價值，以及競品和賣點，可以是一致的，都可以在一張海報上所呈現

干系人識別：

我們大致梳理了公司的管理層級。現在要把他們匹配到相當的關注層級之中

識別哪些干系人是重點關注的，那些是一般關注即可

  高能預警：此處有深坑：注意避坑。一般來說項目的干系人優(yōu)先級都比較穩(wěn)定，不會發(fā)生改變，但是在去年的那個項目里面完全不同了，在項目的第一階段干系人A非常的重視，干系人B基本沒有太多的意見，但是到了項目的第二個階段，畫風發(fā)生了反轉，干系人A參與的越來越少，相反干系人B有更多的見解和想法。對于不同的干系人，他們想要的成功是不一樣的。需要明確不同階段核心干系人的差異，匯報給不同人有不同側重點。

所以在干系人梳理這塊，還需要注意的點是：

如果workshop 這種形式的大會很難讓干系人透露心聲，可以通過通過 1vs1 的溝通了解他們的真實需求，問他們的KPI是什么，是非常直接詢問他們最關系問題的方式。這對于復雜干系人的項目尤為重要。

也可以在workshop上新增期望對齊的環(huán)節(jié)，在下一個part會講到。

以下附上愿景對齊的工具——干系人/團體地圖

   下面兩種干系人/團隊地圖的差異不大，可以根據需要任選其一即可，圖一更多可以梳理出干系人，或者團體之間的關系，除了判定干系人的權重，還可以在途中不中干系人之間匯報的關系，以及他們之間使用的不同系統(tǒng)的關系

 下圖也是對干系人的權重和優(yōu)先級的排序，與上圖不同的地方在于它更清楚的展示了我們如何去區(qū)分這些干系人的維度，維度可以根據項目需求哦進行變化。

期望對齊：

從各個維度對齊干系人對項目的期待

幫助干系人對各個維度有一些認知

   這個有兩種做法，如果是干系人相對簡單的項目，可以在電梯演講的海報哪里，加上一類表示這個項目期望達到的目標，可以是定型的，如果團隊中有很好的數據監(jiān)控埋點，這個指標也可以是定量的。如果干系人繁多，大家對想要達成的期望不是非常明確的時候，可以加上這個環(huán)節(jié)，這樣也能方便我們了解我們在項目過程中應該如何側重，因為現場的時間非常有限，我們不對所有的期望一一判斷是否合理。會在會后對一些超出范圍的期望和項目負責人達成一致。事先，可以列舉以下幾個維度，幫助大家思考：功能，項目本身，技術，體驗和成效，維度可以隨項目目標的不同自由變更，如果大家還有新的維度，也可以在現場添加

以下附上對齊期望的工具——期望看板

權重識別：

    這個是千萬不要省略的一個對齊項目，后面有諸多事宜，我們需要跟俊權重的識別來判斷。比如在需求膨脹的時候，我們用什么方式判斷那個需求的優(yōu)先級更高，應該把哪些需求摘出去?；蛘咴谧鲆恍Q策的時候，用來判斷，那些事我們應該優(yōu)先處理，而另一些我們可能需要有一些妥協(xié)。后面在說到項目執(zhí)行過程各種突入起來的變故的時候，這個參考項是必不可少的。在文章后面會更為詳細的列舉。

輔助決策

判斷優(yōu)先級

以下附上權重識別的工具——權衡滑塊

詳細日程排期：

細化工作安排

提前約定相關干系人時間

提前預約用戶驗證時間

注意那些是客戶需要參與的時間點，無比準確

以下附上詳細日程排模版，這個相對來說沒有特定的方式，可以做到 Excel 表格中管理。也可以放到 日歷 中管理，當然如果你們有設計排期的服務軟件，都可以使用，我這里只呈其示意樣式

下一步我們就是正式開始進入項目拉

項目執(zhí)行

任務優(yōu)化調整：

   進一步的細化工作安排，如果發(fā)現團隊的小伙伴是新手，無法上手，就需要對任務進行拆分，拆分到什么顆粒度呢，拆分到團隊的小伙伴可以上手的顆粒度，當然拉，千萬不要全部包辦代替的把它做完。在項目允許的范圍內，讓風險發(fā)生！這是團隊人才梯隊建立的關鍵時刻，說到這里，如何培養(yǎng)團隊設計能力，又是一篇長篇大論了，我們回歸正題。如過小伙伴就有很多經驗，那就更可以安心的把整快大的蛋糕分給他，把他劃分為責任人，下面的工作內容如何拆解，應該分幾步來做，請放手。只用在關鍵節(jié)點和把控質量就好。

明確產出目標

明確產出內容

明確產出目的

明確產出物依賴

拆分責任人：

   這塊和上訴的任務優(yōu)化調整是聯系在一起的，當我們合理拆分任務后，當然要他這個任務匹配到相關的責任人，如任務優(yōu)化調整所訴，可以是比較大的一大塊任務，比如信息架構這一個大塊，用戶調研這個大塊，制定相關人作為Owner ，至于他如何來拆解自任務，還需要請到那些人進行協(xié)作，由Owner 來全權負責，Owner 是需要對結果負責的人 。如果是新人，拆分成一個大塊是無法下手的，并不知道我每一步應改怎么做，那就把大蛋糕切細，切到他可以嘗試下咽的顆粒度即可。

   在項目活動中，對于2個設計師以上的團隊，我們就可以利用設計看板。長期做敏捷交付的小伙伴對這個工具一定不會陌生。

對于有經驗的人，按照大塊拆分

對于新人，在按大塊拆分以后，需要對分支任務或是階段任務在進行下一步拆解

以下附上日常設計工作管理工具——設計看板

還是那句話，有設計進度跟蹤的工具的小伙伴請繞道哦，這個是非常簡單的且直白的一種設計管理模型，這樣就可以每日跟蹤大家的手上的工作進度了，也可以跟中哪些任務已經完成拉。上面的標題欄“待設計”“設計中”“已完成”也可以根據項目的不同階段，放置不同的標題，當我們設計完成后，就可以領取新的設計任務拉。

每天這樣移動卡片會不會亂呢，怎么和大家同步信息呢？那我們就要說到設計工作中一個關鍵活動了？

站會/業(yè)務對齊會

組內同步：

每日站會對項目來說是比不可少的，一般會定在每日早上，項目全體小伙伴都要參加，上班的第一件事就是開站會拉，多么有儀式感的一天，站會通常會占用10-15mins，站會可以用來：

同步信息包括，昨天，今天的工作內容

提出風險，有困難就喊出來，找大家一起需求幫助

這樣大家就非常明確每個人都在做什么，我的工作有什么依賴，我應該找誰解決獲取上下文，另外就是及時暴露風險。及時尋求幫助

另一項活動是我特別喜歡在團隊中使用的：業(yè)務對齊會

當項目比較大，每個設計師或者業(yè)務分析師分為了多個條線跟蹤業(yè)設計和業(yè)務。那業(yè)務對齊會也是比不可少的，當然業(yè)務對齊會不僅僅可以對齊業(yè)務輸入，當需要開發(fā)判定方案是否可行，或者需要其他的角色一起討論問題時，我們都會放到放到每日或者隔天的或者隔周的業(yè)務對齊會上一起討論，會議頻次根據項目實際情況自行安排，邀請成員通常是設計師和業(yè)務分析師一起，又是也會邀請其他角色，視會議需要討論問題而定

方便參與不同業(yè)務條線的同學對業(yè)務全景保持一致

不對角色的思維方式存在差異，可以轉換視角看待問題

可以相互評審設計稿，業(yè)務分析流程等活動，查漏補缺

它的優(yōu)勢是：

保證出方案時間的完整。不會隨意打斷大家輸入和思考的時間，固定時間同步信息

高效同步信息。不會一次同步太多信息，信息量太大，趨于飽和，會少量多次，最長不要超過1h，如果超過就要增加會議頻次來減少時長。

干系人溝通：

終于寫到干系人溝通了，這真正是一個大坑

干系人溝通有幾個關鍵點：

建立信任 — 一切良好溝通的基礎

頻繁溝通 — 減少風險

及時提出自己的見解 — 體現你的價值

建立信任—特別是在項目開始的時候，這一點是致命的，如果開始時能建立良好的信任關系，那么在后期很多小問題的決策上，還有客戶對你方案的認可上都會容易的多。

如何在項目開始的時候建立信任呢？

對客戶現有產品業(yè)務能快速的理解——C端的可繞過（相對比較簡單，容易理解）。這里特指B端產品，部分B端產品的業(yè)務有時專業(yè)性極強，特別是之前我們做的這個項目，做用戶訪談時，每一句話都能用多個專業(yè)術語，你還沒有弄清楚這是怎么回事，就要跟上下一個話題了。對于我們這種非本專業(yè)的設計師來說，要想做好設計，提升用戶體驗，開始就要建立對產品業(yè)務的了解。

   -自主學習，通過各種渠道找學習課件，提前對該領域專業(yè)術語作出梳理；對相關的背景知識有所了解，對領域現狀有所認知，包括現存的競品也可以找來看看，借鑒學習。

   -找領域專家尋求幫助，對于是在無法獲取經驗的領域，也找不到相關的一些信息渠道，可以涉及到一些行業(yè)機密，可以酌情尋找第三方領域專家，和領域專家進行訪談，從他們哪里可以拿到很多一手資料。當我們對項目有一些假設時，也可以找領域專家驗證假設的可行性

  -向訪談對象學習，可以判斷訪談對象的性格特質，如果很明顯的流露出善于表達，喜歡和你傾訴更多的信息，那么可以把握好機會，適當的詢問一些領域問題

  -向客戶學習，PO也許不負責具體的業(yè)務條線，也可能多年不再碰具體的業(yè)務操作，但是他們對于理論的掌握還是有一定的借鑒作用的。

   

    當然了，現在收集到了這么多信息，還需要整理和消化，并且驗證信息的可靠心是否是正確。

    多渠道信息交叉驗證

    信息之間能否相互關聯，相互串聯，形成閉環(huán)

專業(yè)技能維度——專業(yè)能力維度是設計師的立足之本了，毋庸多說，但這里需要強調幾點

-設計邏輯清晰，設計結果很重要，但設計思路同樣重要，很多設計師在展示自己的方案的時候，只呈現做了什么，結果如何，很好，很精良，但是一定要有邏輯連貫的思考過程，才能體現你的思維邏輯，我們的方案不是憑空捏造的，不是一拍腦袋想出來的，我們的設計是經經過了哪些步驟，這個步驟的作用是什么，設計結論是如何推倒的，這樣的設計包含了哪些設計原理 ，好處是什么。犧牲了什么，如何權衡它的犧牲的。

設計從戰(zhàn)略層倒表現層，越是取近于表現層，其評判標準就越主觀，眾口難調，特別是面向非設計領域的專業(yè)人員來說，這個評判標準在我們手上，我們要給出來我們這樣做的理由是什么，好處是什么，才能得到客戶的信任。

頻繁溝通 不要悶頭設計哦，在項目的每個階段都要定義定期展示案例的時間點，除了這些時間點外，還可以約

這里從問題的角度來會切入吧

需求變更，反復無常

半路殺出程咬金 — 干系人變更

增加項目范圍

老大不滿意

干系人意見沖突

干系人不認之前做的決策

》需求變更，反復無常

一般情況下，按照正常的項目流程來走，我們我們通過痛點發(fā)散出來的機會點一步步的收斂出需要繼續(xù)設計的方案后 ，用戶側的需求優(yōu)先級是已經被考慮進去的，所以突然變更的需求大多可能是來自也無方，或者超級VVVIP 用戶

判斷是什么類型的需求？

合理需求：可以對需求進行規(guī)劃，判斷項目需求的優(yōu)先級，如果合理且緊急，可以和相關干系人對齊，給予初步方案計劃，對部分現有需求做出置換（如果干系人經常變更需求，可以對設計方案作出估點，按照人/天置換需求），如果合理不緊急，拿出我們的權衡滑塊， 明確需要 foucs 在當前項目優(yōu)先級下，不要過于發(fā)散，可以定制相關產品演進路線通過迭代演進方式逐步實施

不合理需求：可以委婉拒絕，如果實在無法拒絕，可以花費一些小effort，告知他為什么不合理

》半路殺出程咬金—干系人變更

可以在識別核心干系人的時候，詢問清楚在項目進行過程中是否有核心干系人的變更，提前識別

有時干系人的變更是突然的，無法提前識別，不要慌，繼續(xù)往下做。一般干系人變更可能會帶來以下問題：

要推翻之前的方向——相當于要從新立項，如果方向都被否定了，就不要繼續(xù)往下做，及時止損，重新規(guī)劃項目方向。

要新增項目范圍——新增的范圍非常大，大到可以重新規(guī)劃一個新的項目，就在規(guī)劃新的項目；如果新的范圍可控，還是根據本項目的權衡滑塊來判斷,哪些是優(yōu)先級高的范圍，先做，不高的置換出來。

》老大不滿意

1.減少老大不滿意的風險，就是多建立溝通，最好可以親自向上層級匯報。

2.保證方案的邏輯性，所有的設計思路都是有據可依。

3.保證方案給用戶給企業(yè)帶來的價值。對于比較成熟的項目，最好價值是可以被量化，可衡量的，如果無法用數據橫向衡量，可以用定性的方式來判斷價值，比如在用戶驗證的時候，檢測新的方案是否能滿足客戶的需求，用戶對新的方案是如何評價的，在無數“證據”下，老大也不會無緣無故的不滿意

》干系人意見沖突

不要做干系人之間的傳話筒

拉著意見不一致的干系人一起討論問題

》干系人不認之前做的決策

這件事情在某些客戶干系人身上還挺常見的，對于超級難管的干系人，每次大會都要發(fā)郵件，不是不敏捷，是為了介紹缺少文字證據，而出現更多的坑

重要結論，會議紀要+郵件跟蹤

注意：一定要結論先行，大部分的人沒有耐心看完所有的內容，但是加粗字體的會議結論是能簡明扼要的概括，本次會議通過了什么決策。有什么遺留事件，具體的責任人是誰，需要完成的截止事件都要標明

以下附上郵件紀要的格式介紹

項目監(jiān)控

這個過程和項目執(zhí)行的過程應該是穿插進行的，時間是非常有限的，不要面面俱到的跟蹤，抓大放小，只在關節(jié)節(jié)點驗收，比如前面項目執(zhí)行中提到的如何拆分任務，同理，在驗收的過程中，也可在組內的對齊會上驗收設計輸出內容是否符合標準，是否有易用性問題，如果這是非常細小的圓角，交互的方式，布局的方式，可以交給團隊成員自己把控，如果一個設計師從用戶體驗要素的5層出發(fā)，每一層都面面俱到，無微不至，在這樣的大項目里面是很難管理的，把更多的空間留給設計師自己。

把有效的時間集中放在有較大提升價值的事情上：

保障產品價值交付

用戶體驗是否有所提升

現有的資源下，如何平衡，實現價值

拆分對內驗收節(jié)點：

把大的任務蛋糕拆分給每一個小伙伴后，他具體怎么吃，可以讓他自行安排，告知完成的時間階段，在特定時間端內驗收質量問題。

定期復盤：

通常我們通過 Retro 的方式進行復盤，時間周期視項目的時長來定，較短的項目可以安排為每兩周一次的 Retro，Retro 的步驟。1.宣誓（可以跳過）/2安全性檢查/3分別梳理 好的部分，不好的部分，和建議。好的部分鼓勵團隊繼續(xù)保持，不好的部分通過投票，選取前 Top 問題進行 討論整改建議。在下一次的 Retro 的時候進行復盤，看看這些問題是否都有改進。

當然還有很多做復盤的方式，方法本身不是最重要的，復盤的核心就是為了改進上一階段做的不好的地方，并且在下一階段有所改進措施。讓項目運行變得越來越好。

進度跟蹤：

通常會用項目周報的方式，想客戶展示項目的進度，現在進行到項目的什么階段，有哪些產出物，項目是否存在風險，項目計劃及人員投入比例

項目收尾

整體&歸檔：整理交付物，包括設計資產，使用說明和相關目錄，方便其他人員可以持續(xù)迭代

設計歸檔包含的重要組成部分包括且不限于：

設計源文件

用戶研究報告

用戶驗證錄屏材料

用戶訪談大綱

遺留問題跟蹤

Showcase材料

知識傳遞錄屏

...

如果文件夾過于分散，則需要寫一張目錄，目錄上附上文件夾的鏈接，方便呢其他的小伙伴能快速的找到

知識傳遞：注意保留錄屏文檔，當項目人員變更，可以及時傳遞上下文

在做知識傳遞之前，要和大家確認現有的產出，保障產出物不會在作修改，保障所有人都達成一致后，在開始后做知識傳遞。

做知識傳遞的時候，一定要記得錄制屏幕，以防有的小伙伴沒有參加，或是之后還要分享給其他的小伙伴使用，這樣就可以避免一邊一邊的重復人工講解啦，還有預留給大家提問題的時間，看看大家還有沒有不清楚的地方，盡量在會上一一解答。

PS：還想再分享一個，當項目中所要處理的事情過多時，如何排列優(yōu)先級的問題

一般情況下，先看一下這些事情的依賴關系/事件難度，當緊急成度都很高的情況下

有依賴的關系的一般需要提前去收集信息，跟催進度，但花費是假相對較多，可能還有相互依賴，外力因素不可控

或者需要提前與人溝通事件，判斷溝通時間是否合適，但花費是假相對較少，但需要提前預約，外力因素不可控

事件越難的越需要留更多的時間處理，內在因素不可控，事件簡單的則可以安心放在后面進行，內在因素可控

可以按照風險等級排序方案：信息收集類> 約人溝通類>困難事件類>簡單事件類

分享標題：設計師如何做好項目管理？
當前地址：http://www.muchs.cn/news24/163024.html

成都網站建設公司_創(chuàng)新互聯，為您提供品牌網站制作、Google、網站制作、小程序開發(fā)、定制開發(fā)、電子商務

廣告

聲明：本網站發(fā)布的內容（圖片、視頻和文字）以用戶投稿、用戶轉載內容為主，如果涉及侵權請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網站立場，如需處理請聯系客服。電話：028-86922220；郵箱：631063699@qq.com。內容未經允許不得轉載，或轉載時需注明來源： 創(chuàng)新互聯