吃了没做需求分析的亏
我们产品团队比较特殊，属于中途接手、临危受命，额，说临危也不至于，但坑确实不少。当时产品1.0版本已经发布，正在规划2.0版本，我们接手了，在三个月内更换了发动机（目标识别的核心算法）、重新设计制造了外观（前端和UI），按时发布了2.0版本。然而因为时间有限，传动、转向、制动系统我们只能沿用1.0版本的部件，于是这辆看起来V587的2.0超跑战战兢兢上路了。真是谁开谁知道，担心绝对不是多余的，转向基本靠手，刹车基本靠吼，要不要了解一下？产品上线的第一个正式项目，某天远程查了下事件报表（产品的一个核心功能是通过视频分析，发现画面中的车辆违法行为，并触发相应告警和记录），word天！半个月报告车辆违法事件30000多次，然而真实事件只占1/500左右！大量的重复报警和误报，让我和我的小伙伴都惊呆了，半个月，也就是21600分钟，每分钟都在报告事件，我们真应该站在单向玻璃背后看看客户那复杂的表情，然而并没有这个机会，这样的车客户显然是不会开上路的。于是，我们决定找负责这个功能模块的Dev来“祭天”，不，我们还是理智的，赶紧商量对策。
那么，先看看1.0版本的该模块是怎么设计的，然而并没有找到任何Spec，不管是Functional还是Technical的。需求是Dev自己分析的，设计是Dev脑中构思的，边写边改，边改边写，bug不断，一直处于按下葫芦浮起瓢的状态。为什么要设计这么几种事件类型？每种事件类型为什么是这样的判断逻辑？不同事件之间有没有优先级？相同事件需不需要合并？问题太多，Dev回答的句式基本是：“我觉得……应该是……吧”或者“当时就是……那样想的吧”。说实话，这位Dev也挺委屈的，直接甩一个功能模块给他（同一时期还有其他重要任务分配给他），却没有任何需求输入，天知道他都经历了什么。没人告诉他怎样的用户会使用这些功能，没人告诉他需要实现哪些功能，也没人告诉他用户需要这些功能来解决什么问题，一切都靠着自己仅有的产品和行业经验在猜测，整个过程完全是自由发挥的。另外，我们发现1.0版本的其他几个功能模块基本也都有类似的问题，于是，长痛不如短痛，我们决定逐个重构。
先苦后甜
趁(忍)热(无)打(可)铁(忍)，紧接着一个周末的下午，我开始梳理该模块的基本需求，用户的使用场景、不同类型事件发生的场景等等，越深入越发现我们不该一味责怪那位Dev，其实真正分析起来，这么一个看似简单的功能模块，场景也是非常复杂的。到了工作日，马上叫上相关人员讨论、验证需求，先达成对需求理解的一致。过程自然磕磕碰碰（PM和Dev打架不是没有原因的，哈哈），行业术语难理解，咱就讲故事（Use Case），甚至扯到了哲学思想。最后，需求达成了一致，那位Dev还嘤嘤的说了一句：“早怎么没说？”对呀，1.0版本的问题，责任并不全在他。
后面的过程就越来越顺利了，团队的技术负责人花了一周时间做了详细的Technical Spec，并经过两次讨论最终确定，之后一周时间编码，一周时间编写测试用例进行测试，集成到2.1版本的相关功能上线了好几个项目，至今没有大的问题。如法炮制，我们陆续对其他几个模块重新进行需求和场景分析，也许这部分花费了较长时间，但编码过程反而没有过多障碍，某些用户场景还能直接形成测试用例供测试人员使用，重构的这些功能模块集成后，效果也都很好。
另一个正面的例子：春节放假前两天，一个项目要定制一个报表功能，客户打电话给我讲了需求，由于在出差赶路，电话沟通可能会有误解，虽然时间很紧，但还是没有让公司的同事立即开始编码，而是先用excel做了一个报表样式（快速原型）给客户确认，客户认可后再开始后续工作，第二天功能顺利上线后，客户只提了一些排序意见。时间越是紧张，越是应该按正确的方法做事，节省的时间、人力不是一星半点。
反思
团队中的每个成员都应该重视需求分析，熟悉用户场景，知道自己在做什么样的产品/功能，PM应该知道，Dev应该知道，Test也应该知道，每个人都能利用“电梯时间”自信的讲明自己在做的产品/功能。
PM在抱怨Dev和自己沟通不在一个频道的时候，也应该反思一下，我们对需求的理解是对等的吗？Dev知道这个产品/功能背后的需求吗？
Dev（特别是涉及交互）也应该多想象自己在单向玻璃背后，或者自己就是客户，看看客户愿意使用某项功能么？是按你想像的样子在使用么？
以上，读《构建之法》第8章、10章，结合实际工作有感，文笔浮夸，多有得罪。