2023-2-28 ui設(shè)計分享達(dá)人
最近看到了一個很有用的知識，它是項目管理中的一個概念，叫做Stacey矩陣模型。
這個模型我看完之后，對應(yīng)到設(shè)計行業(yè)上，
發(fā)現(xiàn)它對于“設(shè)計師面對不同類型項目，應(yīng)該如何做決策”，很有啟發(fā)和幫助。
而我自己最近也剛好離開了熟悉的環(huán)境，要面對一些新的挑戰(zhàn)，
這個模型也給我提供了一些可借鑒的思路。
所以決定整理下自己的心得，給大家分享一下。
這個模型將項目分為“技術(shù)”和“需求”兩個維度，建立了一個坐標(biāo)系：
橫軸是“技術(shù)”層面，判斷技術(shù)的確定性和不確定性，可以理解為技術(shù)是否成熟。
縱軸是“需求”層面，判斷需求是明確的還是不明確的。
根據(jù)這兩個維度，可以將項目劃分為五種類型：
1. 簡單型（Simple）：技術(shù)確定，需求也明確
2. 燒腦型（Complex）：技術(shù)確定，但需求不明確
3. 棘手型（Complicated）：需求明確，但技術(shù)不確定
4. 混亂型（Chaotic）：技術(shù)不確定，需求也不明確
5. 模糊型（Hazy）：并非完全不確定，介于混亂型與其它類型之間
而針對不同區(qū)域的項目，這個模型給出了相對應(yīng)更適合的開發(fā)方式、解決方案。
“技術(shù)”的確定與否，與“需求”的確定與否，基本上就涵蓋了所有的項目情況。
我們可以將目前的項目情況對應(yīng)到這個模型里，判斷它是處于哪個區(qū)域的，
再根據(jù)它所在區(qū)域，選擇性使用這個區(qū)域所對應(yīng)的解決方案。
相比沒有任何方法原則，僅憑經(jīng)驗做事，
借助一個成熟的方法論模型框架，來輔助自己做決策，
條理會更清晰，做決策的效率也更高，
這就是建立思維模型的好處。
思考一下，你目前的項目是處于什么樣的區(qū)域呢？
一、不同項目類型的應(yīng)對思路
在具體介紹不同項目類型對應(yīng)的解決方案之前，
我們要先從大方向上來看一下這個模型。
從模型整體來看，最理想的項目類型，必然是處于區(qū)域1的簡單型項目：
技術(shù)確定，需求也確定。
所以在大方向上，
我們應(yīng)先采取一種向下的“簡化思路”：
也就是盡可能將項目引導(dǎo)向最簡單、最可控、最穩(wěn)定的“簡單型”區(qū)域，
需求維度上，引導(dǎo)客戶明確需求，達(dá)成共識。
技術(shù)維度上，盡可能選擇更可控、更成熟的技術(shù)。
所以項目的前期階段很重要，這個階段決定了項目最后的導(dǎo)向。
前期多花點時間溝通討論，可以為后續(xù)執(zhí)行減輕很多負(fù)擔(dān)，
目的是為了在這個過程中盡量減少不確定性，
讓項目類型流向更簡單的區(qū)域。
接下來介紹下不同項目類型對應(yīng)的應(yīng)對方案：
1. 簡單型（Simple）：預(yù)測型，做好計劃，按計劃執(zhí)行。
2. 燒腦型（Complex）：增量型：逐步構(gòu)建，每次增量一部分。
3. 棘手型（Complicated）：迭代型：先搭建基礎(chǔ)框架，再逐漸迭代改進(jìn)細(xì)化。
4. 混亂型（Chaotic）：避免掉，很難成功
5. 模糊型（Hazy）：敏捷開發(fā)（更多是對于產(chǎn)品層面了，對設(shè)計領(lǐng)域的借鑒意義可能不大，所以這里不做引申。）
01 預(yù)測型：
適合需求明確，技術(shù)也成熟的項目。
這種通常是比較簡單的項目，或者是已經(jīng)做過多次的很成熟的項目。
對于這種可控性高的項目，可以提前制定好完善的計劃，
之后執(zhí)行就按之前的計劃，按部就班完成即可。
02 迭代型：
適合需求明確，但技術(shù)不成熟的項目。
對于處于初期階段的設(shè)計師，通常面對的都是這樣的項目，缺少經(jīng)驗，技術(shù)還未成熟。
這時候應(yīng)該先去做一個比較簡略的粗稿，明確大方向，再去逐漸細(xì)化完善。
而錯誤的做法是：先去摳細(xì)節(jié)，在一個局部的小細(xì)節(jié)上磨半天。
結(jié)果就是，細(xì)節(jié)也不對，大方向更不對，
不僅效率低，做的還全是錯的。
我自己以前就犯過這樣的錯誤，非要把東西做的差不多了，調(diào)了很多細(xì)節(jié)，再拿給主管看。
結(jié)果整個方向都是錯的，而且因為已經(jīng)做了很多細(xì)節(jié)，改起來還很麻煩。
實際上我應(yīng)該在做好大方向的粗稿后，就拿去給主管看，
確定了大方向，再去打磨細(xì)節(jié)。
因為當(dāng)你經(jīng)驗成熟后就會發(fā)現(xiàn)，只要大方向出來了，之后能細(xì)化成什么樣，基本可以預(yù)見了，剩下的只是時間問題而已。
03增量型：
較適合技術(shù)成熟，但需求不明確的項目。
這種類型的項目很普遍，比如客戶需求不明確，不知道自己具體想要什么。
還有可能是項目體量比較大，要考慮好所有細(xì)節(jié)，需要很長的時間。
這時候就可以嘗試用“增量開發(fā)”的模式，
也就是先做好確定的那部分，然后交付給客戶，
客戶提出了新的需求，再增量進(jìn)去。
像堆積木一樣，想到一點做一點，每次完成一部分，
而不是等全部想好再動手。
這樣做的好處是：
1. 可以在執(zhí)行上先做起來，避免因為需求還未確定，導(dǎo)致執(zhí)行無法推進(jìn)。
比如在項目前期，雖然腳本還有很多東西沒有完善，但一些已經(jīng)確定要做的東西，就可以先進(jìn)執(zhí)行，或者做技術(shù)上的測試等等。
2.交付客戶的部分模塊，通常是已經(jīng)比較完善的，客戶能盡早看到一個直觀的結(jié)果，減少理解偏差。
比如有時候明明草圖階段已經(jīng)確定了，
結(jié)果等成品出來，客戶又不滿意了。
因為每個人想象出來的東西是不一樣的。
很多設(shè)計師還會遇到這樣的問題：難以理解領(lǐng)導(dǎo)者的想法。
無論是自身經(jīng)驗的原因，還是溝通上的問題，
總之，對于需求的理解是模糊的，
不清楚領(lǐng)導(dǎo)想要的到底是什么樣的。
這時候其實就可以采用“增量”的設(shè)計思路：
先完成自己能理解，能確定的部分，然后拿給領(lǐng)導(dǎo)看，
這時候他可能會提出一些新的反饋，告訴你接下來應(yīng)該做些什么。
再根據(jù)反饋，繼續(xù)往下做。
這樣可以快速產(chǎn)出一個可見的結(jié)果，加快溝通頻率。
而不太好的做法是：
自己在那死磕，自己在那猜，非要做完再交。
最后,這個過程消耗了很多時間，得到的結(jié)果卻根本不是對方想要的。
小步快跑，多次更新，這種“增量”的設(shè)計思路，
對于需求不清晰的情況，執(zhí)行效率很高。
二 如何運用到其它方面？
除了項目上，Stacey模型對于設(shè)計師遇到的一些其它問題，同樣有借鑒價值。
接下來我們看看在職業(yè)成長和技能學(xué)習(xí)上，可以如何借鑒：
職業(yè)成長上如何借鑒：
根據(jù)Stacey矩陣模型圖，我們不難推演：
對于處于初期階段的設(shè)計師，由于能力不成熟，技術(shù)上是不確定的。
如果再加上客戶需求也不確定，
項目類型就會變?yōu)椤凹夹g(shù)不確定，需求也不確定”的混亂和模糊類型，難度很高。
這就像是，剛出新手村，就要去打BOSS一樣。
所以在職業(yè)生涯的初期，應(yīng)盡量去一些大公司，或比較成熟的公司。
因為這樣的公司，往往需求到你手里時，基本已經(jīng)是確定的了，
只要專心去打磨你的技術(shù)就好。
如果去一些本身不夠成熟的公司，需求也不確定，自身的技術(shù)也不確定，
無疑進(jìn)入了困難模式，導(dǎo)致很難提升，一團(tuán)亂麻，還會打擊自己的信心。
技能學(xué)習(xí)上如何借鑒：
如果我們想要掌握一個新的技能，它是處于什么樣的區(qū)域呢？
需求是確定的，而技術(shù)不成熟，
所以屬于“棘手型”項目。
那就可以用“迭代”的方法。
比如你要學(xué)動效，那就可以先去找一個簡單但完整的動畫小案例，
先去把整個流程、一些最基礎(chǔ)的知識點弄明白。
學(xué)完之后，就已經(jīng)可以做一點簡單的小動畫了。
然后再逐漸加大難度，不斷完善和迭代你的技能。
這種方法的好處顯而易見，在很短的時間，就能把技能運用起來，
而不必等到學(xué)的差不多了，才能開始運用。
我最早學(xué)軟件時，用的就是一種很低效的方法：對著一本工具書，一點一點學(xué)軟件的每個功能。
結(jié)果整本書看完了，都還不知道要怎么用。
這也跟當(dāng)時的教學(xué)資源環(huán)境不成熟有關(guān)?，F(xiàn)在很多教程都是基于具體、完整的案例教學(xué)了，學(xué)習(xí)起來效率很高。
所以在選擇教程時，應(yīng)優(yōu)先選擇案例型的教學(xué)，而避免單純功能模塊的講解。
小結(jié)一下：
面對需求的不確定，或技術(shù)的不確定性，無論是迭代開發(fā)的思路，還是增量開發(fā)的思路，方向上其實都是在逐漸減小不確定性。
面對技術(shù)的不確定、不成熟，那就先大致完成一個粗略的版本，再去逐漸細(xì)化、優(yōu)化、迭代。
面對需求的不確定，那就先完成確定的部分，做一步看一步，隨著想法、需求的逐漸完整，不斷填充完善設(shè)計。
而對于技術(shù)也不確定，需求也不確定的混亂和模糊項目，但又無法避免的，可以嘗試多種方法混合使用。
整體來說，這是一種向下簡化，減小不確定性的思路。
拓展：逆向應(yīng)用的“挑戰(zhàn)模式”
而根據(jù)這個模型推演，逆向思考，
會發(fā)現(xiàn)其實還有一種向上復(fù)雜化的思路。
我把它稱為“挑戰(zhàn)模式”。
顧名思義，就是將處于區(qū)域1的簡單項目，向復(fù)雜的方向演變。
一般是在技術(shù)的軸向上，將確定性變?yōu)椴淮_定。
為什么要把它變復(fù)雜？找虐嗎？
當(dāng)然不是。
處于區(qū)域1的簡單項目，因為它簡單可控，容錯率高，
所以恰好是用來嘗試新技術(shù)的最佳實驗對象。
在這樣一個非常穩(wěn)妥的環(huán)境里，你可以放手大膽去嘗試新的技術(shù)，新的想法。
失敗了也問題不大，大不了還是換回老方法唄。
比如我們有一些日常的EP項目，每個月都有一兩條的產(chǎn)出，技術(shù)上和需求上都已經(jīng)很成熟。
這類項目就是我們的快樂實驗場，可以大膽嘗試一些新的技術(shù)，新的想法。
而且，適當(dāng)給自己加點挑戰(zhàn)，也可以消除重復(fù)性工作帶來的無聊感。
嘗試下這種“挑戰(zhàn)模式”，非常有利于設(shè)計師能力的成長。
在簡單的項目里，將新的技術(shù)打磨成熟，
之后就可以在復(fù)雜的項目中去應(yīng)用了。
可以不斷拓寬自己在技術(shù)軸上的確定性范圍。
避免陷入技術(shù)和需求雙雙不確定的混亂情況。
結(jié)語
最后，出于嚴(yán)謹(jǐn)考慮，要說一下，
我對這個模型的一些理解，不一定絕對準(zhǔn)確。
畢竟它是另一個領(lǐng)域的知識。
但我們學(xué)習(xí)借鑒其它領(lǐng)域的知識，
本來就不是為了照搬過來。
而是為了從中吸取能夠借鑒的部分，
最終目的，是要為自己所用。
最后留給大家一個思考題，可以按照步驟依次進(jìn)行，
1. 你目前的項目是處于什么樣的區(qū)域？
2. 如果處于較復(fù)雜的區(qū)域，能否引導(dǎo)向更簡單的區(qū)域？
3. 根據(jù)Stacey模型，使用什么樣的方式更合適？預(yù)測型、迭代開發(fā)、增量開發(fā)還是混合使用？
4. 具體可以如何做？
作者：崔小俊
轉(zhuǎn)載請注明：站酷
藍(lán)藍(lán)設(shè)計( www.teruid.com )是一家專注而深入的界面設(shè)計公司，為期望卓越的國內(nèi)外企業(yè)提供卓越的UI界面設(shè)計、BS界面設(shè)計 、 cs界面設(shè)計 、 ipad界面設(shè)計 、 包裝設(shè)計 、 圖標(biāo)定制 、 用戶體驗 、交互設(shè)計、 網(wǎng)站建設(shè) 、平面設(shè)計服務(wù)、UI設(shè)計公司、界面設(shè)計公司、UI設(shè)計服務(wù)公司、數(shù)據(jù)可視化設(shè)計公司、UI交互設(shè)計公司、高端網(wǎng)站設(shè)計公司、UI咨詢、用戶體驗公司、軟件界面設(shè)計公司
藍(lán)藍(lán)設(shè)計的小編 http://www.teruid.com