摘要：工作中我们常常遇到例如以下类似的“迷雾”的场景，我们看不清方向。重复试验却发现还是困难重重，怎样才干让项目或产品方向清晰？破除迷雾？……

一、问题情况分析

　　以下用电影《迷雾》的场景举个样例…...

图1：

1、一群人開始好像在一个小超市里面，外面都是“迷雾”根本看不清方向，任务不清晰、技术不清晰、人力不清晰、绩效財务面也不清晰…...。

图2：

2、你试图脱离这样的环境，当你鼓起勇气准备了些人力尝试下、带着自己的团队拖家带口冲了出去，发现战场的能见度极低，尽管比之前看见的远了有点，可是有限，并且你再次到达相同位置可能还会出现新的威胁！总是还非常难让你排出胜率较高的工作计划。

图3：

3、并且可能还会非常受伤，可能在“迷雾”中不定什么地点时间，就出现一些怪物或触手损伤些战斗力….情况非常多这里省略一万字。

图4:

4、然后带着队友又回到了原地（小超市）。团队信心战斗力受到打击。团队包含研发＼领导＼客户都焦虑度上升。还需重整旗鼓试图再次去尝试外面的世界……。

　　如上贴图事实上比較好的体现了。一些研发的囧境，经理或研发人员对整个战场的路都看不清，或仅仅能看见非常少的一部分，为什么要这么做？怎么才算成功?这样的关键性问题模糊不清可能仅仅是短语概述，无法量化成实际工作…

　　个人总结了可能产生这类问题的解决办法

1. 信息缺失：团队的信息是缺失的，你仅仅是得到了一小块地图，看不清整个地图。

2. 周期性问题：非常多事情是有周期叠加的，比方10、5、3、2、1年的长期愿景。或 4季度、3季度、2季度的目标，你或团队仅仅知道极度远期的或仅仅知道极度短期的。
3. 隐含知识：提出的这个事情里面的“隐性知识”点过多，非常难语言化！说明确这个问题有点类似大学生给小学生讲高数得先补课，反过来大学生想听懂小学生也有难度；然后可能说了一堆名词。而你们的名词的刻板印象大家还是不同比方“水波效果”你百度图片下见下“图5”，这些效果对编程来说都是不同的。假设你先写第一个客户或领导说不正确，再改第二个、第三个这样实验下去项目就死了。
4. 半截词：这个和上一条类似，可是应该不属于“隐含知识”比方仅仅说了半个词如“架构”，假设对于个程序猿来说他可能理解成“技术架构”，假设是做安全设置的可能理解成“安全架构”，假设是架构师那就毁了“应用架构”、“技术架构”、“安全架构、“业务架构”等等...省略一万字，并且这有时还会引发一个有趣的事情。可能提出者要的就是技术架构。程序猿做出来了由于他接触最多的是这个，可是架构师迷糊了没准你做了个“业务架构”...,而反过来假设你问多了提出者可能是客户或领导还会烦...。
5. 事情本就是不清晰的：需求或就是愿景提出者本身可能都没想清晰或举棋不定他在期望你给出答案。或本事情就是个实验性的；或者特别远期的目标比方5年级的这样的事实上本就不会太清晰5年内人员技术人员都可能是不定的。这些天然就是迷雾重重也基本无法全然清晰仅仅能相对清晰。

….可能还有非常多种情况可是类型大多大同小异差点儿相同。假设要写可能会几百条。就和垃圾短信一样假设你一个一个电话号的去封杀哪可能永远都封杀不完，所以这就不再一个一个的写了。

图5：百度搜索“水波效果”

二、应对策略

　　对于这类问题的对策，事实上这基本属于交流＼沟通＼參与问题，交流实际上是所有參与者的事情…

　　首先我们要了解一个核心原则。我们真正的目标是把项目产品做好。这一点是第一位的。无论是客户、领导、还是研发人员，事实上在这个事情上大家是个协作关系，分工不同。都相当于“项目生物”的不同的器官有的是心脏、有能是肾脏、有的是大脑哪个器官不好用都不舒服，所以须要大家共同努力来把愿景或远期目标逐步的细化清晰化。做恶心了对大家都没优点,所以无论什么角色。或某些人之间天然有历史隔阂这都要放下，都要力争尽量的让事情清晰起来，否则就不要组队了。既然要组队大家即便思维方式非常难短期统一。可是起码都要想做好这个事情这是必须的，否则还是散伙的好别浪费青春。

　　所以加强沟通、參与度是第一位的，不沟通不參与事情怎么也不会清晰的，事后讨论谁对谁错更没意义...

　　对于信息缺失、周期性叠加类似的情况，最好能尽量看清全貌粗浅~精细的。假设你是提出者让工作者看清全貌是有必要的这样大家会更合理的考虑一些事情，减少在迷雾中被未知威胁杀伤的可能，尤其是夸领域的时候比方你是个项目经理给UI设计解说的时候尽量别就是派一个button或图标，而是尽量给需求目标尽量给UI讲讲，由于在UI这里你并不一定理解的就是对的，假设你是工作者假设发现这样做会影响项目进度或结果，而提出者并没有意识到应该及时提出，当然假设提出者是领导哪可能办理这个事情还是须要些技巧的可是还是要办。

　　对于“隐含知识”、“半截词”类似的情况事实上还是事情没弄清楚，交流时尽量多用图、少用话或文字、在不行用动画。

还有就是利用中间人适配“Adapter模式”。比方业务差的有点大比方纯技术和纯市场天然非常难交流。这时候能够找“产品经理”适配，还有可能一根20年的研发和3年的研发也是无法说明确非常多事情的，这时也须要8~15年左右的研发适配一下，假设是业务类型、经验度双重叠加的情况可能找到个能够适配的人还比較难比方一个20年的研发和20年的市场假设都各持己见。这可能就找不到适配者了。仅仅能你们两个坦诚相待梳理清楚了。

　　对于事情本就是不清晰类的。短期就是非常难看见全貌的。就是须要你尽快知道这就是不清晰的！并一步一步把它做的从不清晰到清晰，这就看你的综合能力咯，就和玩即时战略游戏一样什么时候能够全图全亮哪是战略战术综合经验的综合体实力咯…..。

三、总结

　　事实上说究竟就是交流、沟通、协作，这类问题事实上并不单独属于软件研发，不论什么事件类的有多个人的都可能存在，找到厉害关系人和事情逐步解决才是王道，当然解决也不见得立马会生效有的事情就是须要些时间的好比你头痛吃了药也是须要个半小时一小时才会起效的所以有时须要冷静的等等也非常重要（冷静的等不是拖拉、放弃哦...）。

——最后：或许坏事总会发生、但我们仍要在困难中前行——祝：工作顺利！。！！

广告推广