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