43-面对探索型功能开发任务，如何避免常见陷阱？
前言 在软件开发过程中，我们经常会遇到一些探索型的功能开发任务，就是那些没有做过、没有参考案例、甚至整个部门都没人有经验的功能开发。 这种任务往往充满了不确定性，也最容易出现问题。 书接上回 还记得之前张三和李四因为临时方案爆发的争论吗？ 李四最近的开发工作一直都差强人意。 每次功能做完在会议上演示，总是会被挑出很多问题：功能实现丢三落四、界面样式不够美观、逻辑处理不够完善等等。 问题表现 这个问题到底出在哪里呢？是李四做事情不够用心吗？ 经过一段时间的观察，我发现问题主要出在两个方面： 问题一：需求沟通不到位 首先是需求沟通的问题，很多时候，需求给出来的时候就存在可协商的空间，什么意思呢？就是需求描述不够明确，没有达到可量化的程度。 比如只说 “界面主题色是蓝色”，但没有给出具体的十六进制值。对于开发人员来说，蓝色可以是天蓝色、浅蓝色、粉蓝色，甚至深蓝色。 结果等开发完成了，你又不满意了，说想要的是深蓝色。这个时候功能都实现完了，找谁说理去？ 问题二：探索型任务的特殊性 第二个原因是，李四的开发任务是探索型的任务，这类功能没有做过，甚至整个部门就他一个人开始做。 对于这种类型的任务，最容易出现的问题就是口头沟通的局限性，两个人在座位上你一句我一句地讨论功能实现、技术预研、技术框架、设计方案、函数封装等，都是口头沟通。 因为没有参考案例，沟通双方很容易出现 “我觉得我说清楚了，你觉得你听明白了” 的情况。 结果呢？ 等功能开发出来，李四觉得自己已经做到位了，张三一看，觉得和之前沟通的完全不是一回事儿。 解决方案 面对这些问题，我们应该怎么办呢？ 对策一：需求量化是基础 首先，需求必须可量化、可验证，这是解决问题的第一步。 颜色要给出具体的十六进制值，尺寸要给出具体的像素或百分比，功能要明确输入输出，性能要给出具体的指标要求。 所以说，模糊的需求必然导致模糊的结果。 对策二：方案文档不可少 其次，对于探索型任务，方案文档是关键。 李四应该在开始敲代码前，先在脑子里过一遍整个开发流程，找出可能存在的技术难点和争议点，针对每个难点提供 1-2 个解决方案，然后形成方案文档，文档应包括：做什么、为什么、怎么做、有什么问题、怎么解决、结论。 一来可以把思路梳理清楚，二来可以提前预知可能出现的问题，把风险在开发前就排除掉。 对策三：多人讨论是保障 最后，一个人拍脑袋决定的方案往往存在隐患，正确的做法是召集项目负责人、相关同事等一起过一遍方案文档，大家从不同角度提出意见和建议，明确解决方案和实现方式。 为什么要这么做？ 因为每个人掌握的信息不同，多人讨论可以避免信息盲区，可以发现个人思考中忽略的问题，最重要的是，集体决策可以分摊责任，如果最后方案还是不太理想，也怪不到某一个人头上。 总结 说实话，探索性功能开发确实充满挑战，很多人会觉得这类型的任务，最大的难点是在技术层面的攻关，但实际上，只要做事情的方式不对，同样得不到自己满意的结果。 所以说，探索不代表可以随意，创新也需要规范。按照正确的流程和方法去做，你会发现，很多看似复杂的问题其实都有章可循。