<strike id="cy2gs"><menu id="cy2gs"></menu></strike>
  • <del id="cy2gs"><dfn id="cy2gs"></dfn></del>
  • 面對項目中的不確定性,設計師如何決策?

    2023-2-28    鶴鶴

    最近看到了一個很有用的知識,它是項目管理中的一個概念,叫做Stacey矩陣模型


    這個模型我看完之后,對應到設計行業上,

    發現它對于“設計師面對不同類型項目,應該如何做決策”,很有啟發和幫助。


    而我自己最近也剛好離開了熟悉的環境,要面對一些新的挑戰,

    這個模型也給我提供了一些可借鑒的思路。


    所以決定整理下自己的心得,給大家分享一下。

    這個模型將項目分為“技術”和“需求”兩個維度,建立了一個坐標系:

    橫軸是“技術”層面,判斷技術的確定性和不確定性,可以理解為技術是否成熟。

    縱軸是“需求”層面,判斷需求是明確的還是不明確的。


    根據這兩個維度,可以將項目劃分為五種類型:


    1. 簡單型(Simple):技術確定,需求也明確

    2. 燒腦型(Complex):技術確定,但需求不明確

    3. 棘手型(Complicated):需求明確,但技術不確定

    4. 混亂型(Chaotic):技術不確定,需求也不明確

    5. 模糊型(Hazy):并非完全不確定,介于混亂型與其它類型之間


    而針對不同區域的項目,這個模型給出了相對應更適合的開發方式、解決方案。

    “技術”的確定與否,與“需求”的確定與否,基本上就涵蓋了所有的項目情況。

    我們可以將目前的項目情況對應到這個模型里,判斷它是處于哪個區域的,

    再根據它所在區域,選擇性使用這個區域所對應的解決方案。

    相比沒有任何方法原則,僅憑經驗做事,

    借助一個成熟的方法論模型框架,來輔助自己做決策,

    條理會更清晰,做決策的效率也更高,

    這就是建立思維模型的好處。

    思考一下,你目前的項目是處于什么樣的區域呢?

    一、不同項目類型的應對思路


    在具體介紹不同項目類型對應的解決方案之前,

    我們要先從大方向上來看一下這個模型。

    從模型整體來看,最理想的項目類型,必然是處于區域1的簡單型項目:

    技術確定,需求也確定。


    所以在大方向上,

    我們應先采取一種向下的“簡化思路”:

    也就是盡可能將項目引導向最簡單、最可控、最穩定的“簡單型”區域,


    需求維度上,引導客戶明確需求,達成共識。

    技術維度上,盡可能選擇更可控、更成熟的技術。



    所以項目的前期階段很重要,這個階段決定了項目最后的導向。

    前期多花點時間溝通討論,可以為后續執行減輕很多負擔,

    目的是為了在這個過程中盡量減少不確定性,

    讓項目類型流向更簡單的區域。

    接下來介紹下不同項目類型對應的應對方案:

    1. 簡單型(Simple):預測型,做好計劃,按計劃執行。

    2. 燒腦型(Complex):增量型:逐步構建,每次增量一部分。

    3. 棘手型(Complicated):迭代型:先搭建基礎框架,再逐漸迭代改進細化。

    4. 混亂型(Chaotic):避免掉,很難成功

    5. 模糊型(Hazy):敏捷開發(更多是對于產品層面了,對設計領域的借鑒意義可能不大,所以這里不做引申。)


    01 預測型:

    適合需求明確,技術也成熟的項目。

    這種通常是比較簡單的項目,或者是已經做過多次的很成熟的項目。

    對于這種可控性高的項目,可以提前制定好完善的計劃,

    之后執行就按之前的計劃,按部就班完成即可。



    02 迭代型:

    適合需求明確,但技術不成熟的項目。

    對于處于初期階段的設計師,通常面對的都是這樣的項目,缺少經驗,技術還未成熟。

    這時候應該先去做一個比較簡略的粗稿,明確大方向,再去逐漸細化完善。

    而錯誤的做法是:先去摳細節,在一個局部的小細節上磨半天。

    結果就是,細節也不對,大方向更不對,

    不僅效率低,做的還全是錯的。

    我自己以前就犯過這樣的錯誤,非要把東西做的差不多了,調了很多細節,再拿給主管看。

    結果整個方向都是錯的,而且因為已經做了很多細節,改起來還很麻煩。


    實際上我應該在做好大方向的粗稿后,就拿去給主管看,

    確定了大方向,再去打磨細節。


    因為當你經驗成熟后就會發現,只要大方向出來了,之后能細化成什么樣,基本可以預見了,剩下的只是時間問題而已。


    03增量型

    較適合技術成熟,但需求不明確的項目。

    這種類型的項目很普遍,比如客戶需求不明確,不知道自己具體想要什么。

    還有可能是項目體量比較大,要考慮好所有細節,需要很長的時間。



    這時候就可以嘗試用“增量開發”的模式,

    也就是先做好確定的那部分,然后交付給客戶,

    客戶提出了新的需求,再增量進去。

    像堆積木一樣,想到一點做一點,每次完成一部分,

    而不是等全部想好再動手。


    這樣做的好處是:


    1. 可以在執行上先做起來,避免因為需求還未確定,導致執行無法推進。

    比如在項目前期,雖然腳本還有很多東西沒有完善,但一些已經確定要做的東西,就可以先進執行,或者做技術上的測試等等。


    2.交付客戶的部分模塊,通常是已經比較完善的,客戶能盡早看到一個直觀的結果,減少理解偏差。

    比如有時候明明草圖階段已經確定了,

    結果等成品出來,客戶又不滿意了。

    因為每個人想象出來的東西是不一樣的。

    很多設計師還會遇到這樣的問題:難以理解領導者的想法。

    無論是自身經驗的原因,還是溝通上的問題,

    總之,對于需求的理解是模糊的,

    不清楚領導想要的到底是什么樣的。

    這時候其實就可以采用“增量”的設計思路:

    先完成自己能理解,能確定的部分,然后拿給領導看,

    這時候他可能會提出一些新的反饋,告訴你接下來應該做些什么。

    再根據反饋,繼續往下做。

    這樣可以快速產出一個可見的結果,加快溝通頻率。

    而不太好的做法是:

    自己在那死磕,自己在那猜,非要做完再交。

    最后,這個過程消耗了很多時間,得到的結果卻根本不是對方想要的。

    小步快跑,多次更新,這種“增量”的設計思路,

    對于需求不清晰的情況,執行效率很高。

     如何運用到其它方面?


    除了項目上,Stacey模型對于設計師遇到的一些其它問題,同樣有借鑒價值。

    接下來我們看看在職業成長和技能學習上,可以如何借鑒:


    職業成長上如何借鑒:

    根據Stacey矩陣模型圖,我們不難推演:

    對于處于初期階段的設計師,由于能力不成熟,技術上是不確定的。

    如果再加上客戶需求也不確定,

    項目類型就會變為“技術不確定,需求也不確定”的混亂和模糊類型,難度很高。

    這就像是,剛出新手村,就要去打BOSS一樣。


    所以在職業生涯的初期,應盡量去一些大公司,或比較成熟的公司。

    因為這樣的公司,往往需求到你手里時,基本已經是確定的了,

    只要專心去打磨你的技術就好。


    如果去一些本身不夠成熟的公司,需求也不確定,自身的技術也不確定,

    無疑進入了困難模式,導致很難提升,一團亂麻,還會打擊自己的信心。

    技能學習上如何借鑒:


    如果我們想要掌握一個新的技能,它是處于什么樣的區域呢?

    需求是確定的,而技術不成熟,

    所以屬于“棘手型”項目。


    那就可以用“迭代”的方法。


    比如你要學動效,那就可以先去找一個簡單但完整的動畫小案例,

    先去把整個流程、一些最基礎的知識點弄明白。

    學完之后,就已經可以做一點簡單的小動畫了。

    然后再逐漸加大難度,不斷完善和迭代你的技能。


    這種方法的好處顯而易見,在很短的時間,就能把技能運用起來,

    而不必等到學的差不多了,才能開始運用。


    我最早學軟件時,用的就是一種很低效的方法:對著一本工具書,一點一點學軟件的每個功能。

    結果整本書看完了,都還不知道要怎么用。

    這也跟當時的教學資源環境不成熟有關。現在很多教程都是基于具體、完整的案例教學了,學習起來效率很高。

    所以在選擇教程時,應優先選擇案例型的教學,而避免單純功能模塊的講解。


    小結一下:

    面對需求的不確定,或技術的不確定性,無論是迭代開發的思路,還是增量開發的思路,方向上其實都是在逐漸減小不確定性。


    面對技術的不確定、不成熟,那就先大致完成一個粗略的版本,再去逐漸細化、優化、迭代。


    面對需求的不確定,那就先完成確定的部分,做一步看一步,隨著想法、需求的逐漸完整,不斷填充完善設計。


    而對于技術也不確定,需求也不確定的混亂和模糊項目,但又無法避免的,可以嘗試多種方法混合使用。

    整體來說,這是一種向下簡化,減小不確定性的思路。

    拓展:逆向應用的“挑戰模式”

    而根據這個模型推演,逆向思考,

    會發現其實還有一種向上復雜化的思路。

    我把它稱為“挑戰模式”。

    顧名思義,就是將處于區域1的簡單項目,向復雜的方向演變。

    一般是在技術的軸向上,將確定性變為不確定。


    為什么要把它變復雜?找虐嗎?

    當然不是。

    處于區域1的簡單項目,因為它簡單可控,容錯率高,

    所以恰好是用來嘗試新技術的最佳實驗對象。

    在這樣一個非常穩妥的環境里,你可以放手大膽去嘗試新的技術,新的想法。

    失敗了也問題不大,大不了還是換回老方法唄。

    比如我們有一些日常的EP項目,每個月都有一兩條的產出,技術上和需求上都已經很成熟。


    這類項目就是我們的快樂實驗場,可以大膽嘗試一些新的技術,新的想法。


    而且,適當給自己加點挑戰,也可以消除重復性工作帶來的無聊感。

    嘗試下這種“挑戰模式”,非常有利于設計師能力的成長。

    在簡單的項目里,將新的技術打磨成熟,

    之后就可以在復雜的項目中去應用了。

    可以不斷拓寬自己在技術軸上的確定性范圍。

    避免陷入技術和需求雙雙不確定的混亂情況。

    結語

    最后,出于嚴謹考慮,要說一下,

    我對這個模型的一些理解,不一定絕對準確。

    畢竟它是另一個領域的知識。


    但我們學習借鑒其它領域的知識,

    本來就不是為了照搬過來。

    而是為了從中吸取能夠借鑒的部分,

    最終目的,是要為自己所用。

    最后留給大家一個思考題,可以按照步驟依次進行,

    1. 你目前的項目是處于什么樣的區域?

    2. 如果處于較復雜的區域,能否引導向更簡單的區域?

    3. 根據Stacey模型,使用什么樣的方式更合適?預測型、迭代開發、增量開發還是混合使用?

    4. 具體可以如何做?

    作者:崔小俊

    轉載請注明:站酷

    藍藍設計建立了UI設計分享群,每天會分享國內外的一些優秀設計,如果有興趣的話,可以進入一起成長學習,請加藍小助,微信號:ben_lanlan,報下信息,藍小助會請您入群。歡迎您加入噢~~希望得到建議咨詢、商務合作,也請與我們聯系01063334945。


    分享此文一切功德,皆悉回向給文章原作者及眾讀者.
    免責聲明:藍藍設計尊重原作者,文章的版權歸原作者。如涉及版權問題,請及時與我們取得聯系,我們立即更正或刪除。


    藍藍設計www.skdbbs.com )是一家專注而深入的界面設計公司,為期望卓越的國內外企業提供卓越的UI界面設計、BS界面設計 、 cs界面設計 、 ipad界面設計 、 包裝設計 、 圖標定制 、 用戶體驗 、交互設計、 網站建設 平面設計服務UI設計公司、界面設計公司、UI設計服務公司、數據可視化設計公司、UI交互設計公司、高端網站設計公司、UI咨詢、用戶體驗公司、軟件界面設計公司




    日歷

    鏈接

    個人資料

    藍藍設計的小編 http://www.skdbbs.com

    存檔

    主站蜘蛛池模板: 国产精品视频色视频| 精品国产三级a乌鸦在线观看| 久久国产精品久久| 亚洲一日韩欧美中文字幕欧美日韩在线精品一区二 | 国产情侣大量精品视频| 国产成人精品无码免费看| 亚洲欧美精品一区久久中文字幕| 国产精品免费久久久久影院 | 久久综合九色综合精品| 无码国产69精品久久久久网站| 精品视频一区二区三区四区五区| 久久99国产精品二区不卡| 久久精品国产亚洲av麻豆色欲| 久久伊人精品青青草原日本| 97久视频精品视频在线老司机 | 精品欧美一区二区在线观看| 久久精品国产久精国产| 激情亚洲一区国产精品| 亚洲国产精品VA在线观看麻豆| 日韩欧美亚洲国产精品字幕久久久| 99久久精品免费看国产免费| 国产69精品久久久久777| 精品久久久久久无码专区| 日韩精品无码一区二区三区免费 | 国产精品9999久久久久| 久久亚洲国产成人精品性色| 在线亚洲欧美中文精品| 另类国产精品一区二区| 狠狠色伊人久久精品综合网| 99精品国产一区二区| MM1313亚洲精品无码| 91无码人妻精品一区二区三区L| 久久久精品午夜免费不卡| 国产精品亚洲午夜一区二区三区| 1000部精品久久久久久久久| 国产精品一久久香蕉国产线看观看| 久久亚洲私人国产精品| 国产人妖乱国产精品人妖| 国产精品亚洲片在线| jizz国产精品网站| 久久se精品一区精品二区|