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