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

2023-2-28    ui设计分享达人

最近看到了一个很有用的知识,它是项目管理中的一个概念,叫做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.lanlanwork.com )是一家专注而深入的界面设计公司,为期望卓越的国内外企业提供卓越的UI界面设计、BS界面设计 、 cs界面设计 、 ipad界面设计 、 包装设计 、 图标定制 、 用户体验 、交互设计、 网站建设 平面设计服务UI设计公司、界面设计公司、UI设计服务公司、数据可视化设计公司、UI交互设计公司、高端网站设计公司、UI咨询、用户体验公司、软件界面设计公司




日历

链接

个人资料

蓝蓝设计的小编 http://www.lanlanwork.com

存档