前言

在软件开发过程中，我们经常会遇到一些探索型的功能开发任务，就是那些没有做过、没有参考案例、甚至整个部门都没人有经验的功能开发。

这种任务往往充满了不确定性，也最容易出现问题。

书接上回

还记得之前张三和李四因为临时方案爆发的争论吗？

李四最近的开发工作一直都差强人意。

每次功能做完在会议上演示，总是会被挑出很多问题：功能实现丢三落四、界面样式不够美观、逻辑处理不够完善等等。

问题表现

这个问题到底出在哪里呢？是李四做事情不够用心吗？

经过一段时间的观察，我发现问题主要出在两个方面：

问题一：需求沟通不到位

首先是需求沟通的问题，很多时候，需求给出来的时候就存在可协商的空间，什么意思呢？就是需求描述不够明确，没有达到可量化的程度。

比如只说 “界面主题色是蓝色”，但没有给出具体的十六进制值。对于开发人员来说，蓝色可以是天蓝色、浅蓝色、粉蓝色，甚至深蓝色。

结果等开发完成了，你又不满意了，说想要的是深蓝色。这个时候功能都实现完了，找谁说理去？

问题二：探索型任务的特殊性

第二个原因是，李四的开发任务是探索型的任务，这类功能没有做过，甚至整个部门就他一个人开始做。

对于这种类型的任务，最容易出现的问题就是口头沟通的局限性，两个人在座位上你一句我一句地讨论功能实现、技术预研、技术框架、设计方案、函数封装等，都是口头沟通。

因为没有参考案例，沟通双方很容易出现 “我觉得我说清楚了，你觉得你听明白了” 的情况。

结果呢？

等功能开发出来，李四觉得自己已经做到位了，张三一看，觉得和之前沟通的完全不是一回事儿。

解决方案

面对这些问题，我们应该怎么办呢？

对策一：需求量化是基础

首先，需求必须可量化、可验证，这是解决问题的第一步。

颜色要给出具体的十六进制值，尺寸要给出具体的像素或百分比，功能要明确输入输出，性能要给出具体的指标要求。

所以说，模糊的需求必然导致模糊的结果。

对策二：方案文档不可少

其次，对于探索型任务，方案文档是关键。

李四应该在开始敲代码前，先在脑子里过一遍整个开发流程，找出可能存在的技术难点和争议点，针对每个难点提供 1-2 个解决方案，然后形成方案文档，文档应包括：做什么、为什么、怎么做、有什么问题、怎么解决、结论。

一来可以把思路梳理清楚，二来可以提前预知可能出现的问题，把风险在开发前就排除掉。

对策三：多人讨论是保障

最后，一个人拍脑袋决定的方案往往存在隐患，正确的做法是召集项目负责人、相关同事等一起过一遍方案文档，大家从不同角度提出意见和建议，明确解决方案和实现方式。

为什么要这么做？

因为每个人掌握的信息不同，多人讨论可以避免信息盲区，可以发现个人思考中忽略的问题，最重要的是，集体决策可以分摊责任，如果最后方案还是不太理想，也怪不到某一个人头上。

总结

说实话，探索性功能开发确实充满挑战，很多人会觉得这类型的任务，最大的难点是在技术层面的攻关，但实际上，只要做事情的方式不对，同样得不到自己满意的结果。

所以说，探索不代表可以随意，创新也需要规范。按照正确的流程和方法去做，你会发现，很多看似复杂的问题其实都有章可循。