简介：作者 | 李辉责编 | 郭芮大蒜，牛油果，西葫芦，包菜，鸡蛋，西红柿，鸡腿，三文鱼，土豆，洋葱，黄瓜，杏仁干……这是我买菜前在手机里列出的购物清单。我觉得我已经比很多相信自己脑子记得住、却常常丢三落四买了酱 ...
|
大蒜，牛油果，西葫芦，包菜，鸡蛋，西红柿，鸡腿，三文鱼，土豆，洋葱，黄瓜，杏仁干……这是我买菜前在手机里列出的购物清单。我觉得我已经比很多相信自己脑子记得住、却常常丢三落四买了酱油忘了醋的理工男靠谱了。毕竟我买东西都是一样不少买回去的，但是每次回家还总是被老婆数落，这个不对那个不满意的。 有一天我终于忍不住爆发了，说那你给我个购物清单吧，到底要买什么？！然后她的清单发来了：
你可能要问：土豆不就一种吗，不就是马铃薯，洋芋？那你太天真了，德国是个有200多种土豆、能把土豆吃出花来的国度。 我在超市里盯着这个采购清单，突然无比后悔刚才的冲动。本来作为直男，采购的速度是以光速计算的，只要找到货架位置，刷刷刷把东西扔进购物车就行。现在我必须一个个按规定检查，在一排排同类但不同生产商的货中挑出符合规定的东西，还要看保质期。采购速度直接翻了五倍，本来一刻钟左右我就应该出现在收银台的，现在快一小时了我还在干果区找碳水含量低于4%的杏仁干，最后抓了一个路过的店员一起找了半天才在零食区发现。 好不容易采购完毕回家后，心想这次总该不会不满意了吧。结果棋差一着，还是被抱怨了：那盒鸡蛋有一个蛋破了。我按习惯是打开盒子，扫视一下外壳的，但我万万没想到，那个蛋底部破了。所以今后清单上又多了个标注：鸡蛋检查盒子底部，看有没有蛋液渗出。 回归正题 男人的思维方式，大多数情况下是直线式、收敛式、简单式的，他们天生排斥“不必要”的修饰和麻烦。我敢打赌，99.999%程序猿的购物单和我一样。那些各种各样的“细节”和“形式”，在女人看来无比重要的细枝末节，在多数男人看来，只是浪费时间和吹毛求疵的表现。 这和软件开发有什么关系？如果把这份购物清单看做客户发给你的产品需求，或者一份软件设计文档呢？ 产品需求分析 因为工作领域关系，经常有朋友找我咨询一些软件项目的问题，比如：
我的回答一般都是以这句话反问：
别人一般回答：
我会接着说：
然后再一步步细问对方的实际需求，最终可以得出一个大概的项目开发预算和时间预估。 需求设计文档 我平时习惯在谈项目初期，先做业务和构架需求分析，但还是时不时一个方面没考虑到，就入了坑。曾经有一个做产品经理的朋友找我合作一个项目：客户要做一个电商系统，项目第一版的要求很简单，只要能运行正常购物流程即可：
我自己手头有一套完整的基于Spring的CMS开发框架，包括前端API模块、后端管理模块、用户权限模块、数据持久化模块等等，所以上面这些按估算很容易搞定。第3点里的产品，购物车、订单分成三个小模块，做个二维码支付也不是大问题。而且第一版只要基本功能，不用考虑任何的分布式，大流量，并发抢购等今后做大了要考虑的问题，无需过度设计。 我这个朋友也是个资深程序猿出身，所以我也很放心他作为客户传话筒，所有需求遵循KISS原则，但保留基本的模块扩展性。讨论过后，这第一版的构架图简单如下图所示，我也写了个相应的需求列表。
我们这边技术层面一切OK，客户那边看起来也很佛系，对于我们写的第一版的基本需求列表没有异议，事情似乎向着阳光的方向发展。我想到了所有技术和构架上能想到的点，却单单漏了一点： 朋友是个男性产品经理。 所有该谈的事情谈定了后，最终朋友从客户那里得到了一个产品需求细节文档：
如果真正做过电商系统的朋友，看到第5点可能会心里一颤，这个就是要做一个完整的SKU系统啊！SKU是大型电商系统的基础，复杂度不言而喻。按之前的开发预算和时间预估，这么多关联模块根本不可能完成。 把朋友电话里暴揍一顿后，按客户的产品需求，产品构架思维导图变成了这样。
我得到的教训就是： 在没有客户的详细需求设计文档之前，绝对不要做任何项目估算，更别提动手开发！ 看到这，各位是不是很容易联想到你们的男性产品经理或是项目经理，和客户开个会后，就急冲冲地列出一份新的Feature所需大致功能，然后马上发邮件或者口头传述给开发团队，程序员直接就开始开发。 这里可没有性别歧视，我工作中遇到的男性产品经理或程序猿在做功能设计文档时，常常没有女性产品经理那么细心和耐心。这种文档不明确就开发的做法，看似敏捷快速迭代，但做出来的功能往往和客户所需相差甚远，最后返工付出的代价难以计算。 分析细节标准 我们公司有个客服系统，客户在使用产品遇到问题时，会邮件或者电话给客服，客服录入系统后会分配给相应研发团队。这是一个常见的一问一答流程，我们的反馈会通过客服发给客户。
有没有感觉这样的沟通成本其实很高，客户提供的信息模糊，研发问得也不尽清晰。这里和产品需求文档类似，到底细节的标准在哪？ 我建议我们程序猿在做需求分析时，先向你的女朋友或妻子学习如何分析细节，比如分辨下面这些：
呃，好吧，当我没说…… 我的建议是需求也业务拆分尽可能详细，考虑周全，最好能覆盖今后绝大部分的测试用例。 比如需要开发一个用户注册登录的功能，从某个男性产品经理嘴里说出来可能就一句话：给我开发一个用户系统，能注册，能登录，三天够不够？ 从女性角度，她们习惯把一件简单的事情变的复杂化——如果这里的简单并没有你想象的那么简单呢？ 如果你足够细心，就需要和客户做仔细沟通后达成共识，最终交付给研发团队的应该是如下一份需求Kickoff列表（只是举例，考虑并非100%全面）：
需求文档越详细，后期开发与测试遇到的误解就越少，试错成本也越低。 该文档必须保持在线实时更新，有任何变更，研发团队必须第一时间得知。不要通过短信或者Email更改需求，这会使团队和产品经理陷入无尽的扯皮炼狱之中。 细节的力量 如果说女性太注重于细节，是期待对方给足自己安全感。那么我们在做项目时注重细节，其实也是给自己一种安全感：减少返工。一个口碑好的软件，肯定是从用户需求分析开始就研究细节，设计时重视细节。 大部分程序猿都是非常看重技术，但从男性视角介入软件产品设计时，很容易陷入工程师思维：先考虑怎么做，再考虑做什么，最后考虑为什么做？一看到新项目，脑海里浮现的立刻是各类框架、各类中间件、高并发，恨不得立刻开机撸码。 而从女性角度介入软件产品设计时，她们往往会带有与生俱来的消费者直觉，会从第三方角度看事情。 我这里不是简单地贴职场标签，而是提醒不管是程序猿还是程序媛们，思考一下自己在设计产品时思维的盲区。 最后，女人天生都是产品经理，只不过：
本文仅代表作者个人观点，不代表巅云官方发声，对观点有疑义请先联系作者本人进行修改，若内容非法请联系平台管理员，邮箱2522407257@qq.com。更多相关资讯，请到巅云www.rzxsoft.cn学习互联网营销技术请到巅云建站www.rzxsoft.cn。 |
