面对项目中的不确定性，设计师如何决策？

最近看到了一个很有用的知识，它是项目管理中的一个概念，叫做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. 具体可以如何做？

看看这个模型对你目前是否有帮助和启发~