大蒜，牛油果，西葫芦，包菜，鸡蛋，西红柿，鸡腿，三文鱼，土豆，洋葱，黄瓜，杏仁干……

这是我买菜前在手机里列出的购物清单。我觉得我已经比很多相信自己脑子记得住，却常常丢三落四买了酱油忘了醋的理工男靠谱了。毕竟我买东西都是一样不少买回去的。但是每次回家还总是被老婆数落，这个不对那个不满意的。
有一天我终于忍不住爆发了，说那你给我个购物清单吧，到底要买什么？！

然后她的清单发来了：

大蒜一挂，要 Bio（有机）的
牛油果3个，暗绿色的捏着要硬，软的深褐色的存储不了，也不能太硬，口感不好
西葫芦一根，注意不要破损的，指甲印太多的
包菜一个，要买Spitzkohl（一种尖头包菜），不是那种圆滚滚的包菜，这个口感更好，像国内吃的
鸡蛋一盒6个装，黄壳，不要白壳
西红柿Bio 650g 8个装那种，买前捏一下，软的不能要
两个鸡腿，500g左右盒装，盒子上要标“非转基因”
三文鱼200g，不要冷冻，要冰鲜的，去鲜鱼柜台买
土豆1kg，一定要标注Festkochend，前后多一个少一个单词都不可，比如Mehlig festkochend, vorwiegend festkochend就不行。这种少淀粉炒土豆丝较脆。
洋葱一包，白皮圆形大个的，不要红皮
小脆皮黄瓜，9cm左右的买6根
杏仁干，250g一袋，碳水含量低于4%
……
PS: 所有上述食品都要看保质期。

你可能要问：土豆不就一种吗，不就是马铃薯，洋芋？那你太天真了，德国是个有200多种土豆，能把土豆吃出花来的国度。

我在超市里盯着这个采购清单，突然无比后悔刚才的冲动。本来作为直男，采购的速度是以光速计算的，只要找到货架位置，刷刷刷把东西扔进购物车就行；现在我必须一个个按规定检查，在一排排同类但不同生产商的货中挑出符合规定的东西，还要看保质期。采购速度直接翻了五倍，本来一刻钟左右我就应该出现在收银台的，现在快一小时了我还在干果区找碳水含量低于4%的杏仁干，最后抓了一个路过的店员一起找了半天才在零食区发现。

好不容易采购完毕回家后，心想这次总该不会不满意了吧。结果棋差一着，还是被抱怨了：那盒鸡蛋有一个蛋破了。我按习惯是打开盒子，扫视一下外壳的，但我万万没想到，那个蛋底部破了。所以今后清单上又多了个标注：鸡蛋检查盒子底部，看有没有蛋液渗出。

 

1. 正题

现在再回到我那个最原始的购物清单：大蒜，牛油果，西葫芦，包菜，鸡蛋，西红柿，鸡腿，三文鱼，土豆，洋葱，黄瓜，杏仁干……

男人的思维方式，大多数情况下是直线式，收敛式，简单式的，他们天生排斥“不必要”的修饰和麻烦。我敢打赌，99.999%的程序猿的购物单和我一样。那些各种各样的“细节”和“形式”，在女人看来无比重要的细枝末节，在多数男人看来，只是浪费时间和吹毛求疵的表现。

这和软件开发有什么关系？

如果把这份购物清单看做客户发给你的产品需求，或者一份软件设计文档呢？

 

1-1. 产品需求分析

因为工作领域关系，经常有朋友找我咨询一些软件项目的问题，比如：

• 开发一个教育类App多少钱？
• 做一个网店多少钱？
• 我想做一套在地图上实时显示数据并且分析的可视化平台，开发周期一般多久？
• 我需要一套采购物流系统，开发周期一般多久？

我的回答一般都是以这句话反问：

我问一下，你所在城市房子多少钱一套呀？

别人一般回答：

这要看房子大小，朝向，哪个区买的，差别很大啊。

我会接着说：

做软件和买房子一样的，按软件实际的需求和开发构架的差别，开发周期和费用也是有很大的变化区间的。

然后再一步步细问对方的实际需求，最终可以得出一个大概的项目开发预算和时间预估。

 

1-2. 需求设计文档

我平时习惯在谈项目初期，先做业务和构架需求分析，但还是时不时一个方面没考虑到，就入了坑。曾经有一个做产品经理的朋友找我合作一个项目：客户要做一个电商系统，项目第一版的要求很简单，只要能运行正常购物流程即可：

1. 电脑和手机可以访问。
2. 用户可以邮件注册，也能微信注册。
3. 有产品列表展示，购物车，订单，用户扫二维码支付即可。
4. 用户界面自己决定，以后可以换模板
5. 管理员后台能管理产品，批量上传订单，上传上传图片，查看客户订单。

我自己手头有一套完整的基于Spring的CMS开发框架，包括前端API模块，后端管理模块，用户权限模块，数据持久化模块等等。所以1245这四点按按估算很容易搞定。第3点里的产品，购物车，订单分成三个小模块，做个二维码支付也不是大问题。而且第一版只要基本功能，不用考虑任何的分布式，大流量，并发抢购等今后做大了要考虑的问题，无需过度设计。

我这个朋友也是个资深程序猿出身，所以我也很放心他作为客户传话筒，所有需求遵循KISS原则，但保留基本的模块扩展性。讨论过后，这第一版的构架图简单如下图所示，我也写了个相应的需求列表。

我们这边技术层面一切OK，客户那边看起来也很 佛系，对于我们写的第一版的基本需求列表没有异议，事情似乎向着阳光的方向发展。我想到了所有技术和构架上能想到的点，却单单漏了一点：

朋友是个男性产品经理。

所有该谈的事情谈定了后，最终朋友从客户那里得到了一个产品需求细节文档：

1. 用户分级别，享受不同折扣率
2. 产品含品牌属性
3. 产品归于相应的一级和二级目录
4. 产品由不同供货商提供
5. 产品含颜色和大小等属性
6. 产品分官方价格和折扣价格，订单扣费按当天折扣
7. 支付和交易需要后台管理
8. 产品按重量和大小分不同的物流渠道以及关税申报登记
9. 订单最终价格是折扣后价格，加上动态计算的物流价格
10. 订单表含发票和发货模块，同时扩展物流模块
11. 发票模块需要调用一个第三方发票在线生成系统
12. 支付模块并不和支付宝直接对接，而是和一个境外第三方支付机构。
13. 特价，打折模块
14. 官方Blog模块
15. 若干其它模块

如果真正做过电商系统的朋友，看到第5点可能会心里一颤，这个就是要做一个完整的SKU系统啊！SKU是大型电商系统的基础，复杂度不言而喻。按之前的开发预算和时间预估，这么多关联模块根本不可能完成。

把朋友电话里暴揍一顿后，按客户的产品需求，产品构架思维导图变成了这样。

我得到的教训就是：

在没有客户的详细需求设计文档之前，绝对不要做任何项目估算，更别提动手开发！

看到这，各位是不是很容易联想到你们的男性产品经理或是项目经理，和客户开个会后，就急冲冲地列出一份新的Feature所需大致功能，然后马上发邮件或者口头传述给开发团队，程序员撸起袖子就开始开发。这里可没有性别歧视，我工作中遇到的男性产品经理或程序猿在做功能设计文档时，常常没有女性产品经理那么细心和耐心。这种文档不明确就开发的做法，看似敏捷快速迭代，但做出来的功能往往和客户所需相差甚远，最后返工付出的代价难以计算。

1-3. 分析细节标准

我们公司有个客服系统，客户在使用产品遇到问题时，会邮件或者电话给客服，客服录入系统后会分配给相应研发团队。这是一个常见的一问一答流程，我们的反馈会通过客服发给客户。

客户：我App突然登陆不了
研发：请问您用的系统版本是什么，App的版本是什么？登陆时发生什么错误？
客户：我的系统版本是xx，App版本是xxx。输入用户民和密码后，登陆界面跳转到浏览器，然后就没反应了。
研发：请问浏览器里显示什么，有没有错误代码，是什么时候登陆的？
客户：浏览器里显示“Request Error”，时间是xxxx
研发：请尝试清空App的缓存，以及浏览器的缓存。步骤如下……….
…….

有没有感觉这样的沟通成本其实很高，客户提供的信息模糊，研发问得也不尽清晰。这里和产品需求文档类似，到底细节的标准在哪？

我建议我们程序猿在做需求分析时，先向你的女朋友或妻子学习如何分析细节，比如分辨下面这些：

呃，好吧，当我没说……

我的建议是需求也业务拆分尽可能详细，考虑周全，最好能覆盖今后绝大部分的测试用例。

比如需要开发一个用户注册登录的功能，从某个男性产品经理嘴里说出来可能就一句话：给我开发一个用户系统，能注册，能登录，三天够不够？

从女性角度，她们习惯把一件简单的事情变的复杂化—-如果这里的简单并没有你想象的那么简单呢？

如果你足够细心，就需要和客户做仔细沟通后达成共识，最终交付给研发团队的应该是如下一份需求Kickoff列表（只是举例，考虑并非100%全面）：

• 用email注册还是用户名注册？
• 如果是用户名，最短几位，最长几位，允许特殊字符吗，密码最短几位，最长几位？
• 如果email注册，是密码一起填写注册，还是有验证步骤？
• 点击注册前，是否展示用户协议。不勾选显示什么错误？
• 如果有验证步骤，需要手机验证吗？如果要，要对接哪个API，验证码长短，过期时间？
• 手机验证码发送时间间隔，以及发送频率限制
• 如果只需邮箱验证，发送给用户的激活链接有效期多久，过期了怎么办？
• 验证这个业务要不要持久化？
• 发送激活邮件的模板，HTML还是txt，谁来设计？
• 激活链接过期后，显示什么错误，然后跳转到验证邮件重发界面？
• 激活链接激活后，显示什么信息，自动跳转到哪个界面，比如设置密码界面？
• 密码设置允许特殊字符吗，最短几位，最长几位？
• 密码入库前采用何种加密算法，以哪个属性作为salt？
• 用户密码设置成功后，跳转哪个界面，显示什么消息？
• 用户后期允不允许改用户名或注册邮箱吗？
• 用户后期修改密码是否需要邮件或手机验证
• 允不允许单用户多地点登录，如果不允许，显示什么错误自动登出
• 支不支持单点登录SSO
• 要不要开发移动端App，需不需要提供注册和登录API
• API需不需要支持OAuth2，或是Token
• 登录构架是单体还是需要考虑分布式Session
• 用户权限系统设计，多Role或是单Role设计
• 鉴权系统设计是无状态还是有状态
• 用户自己或者管理员关于权限系统的操作流程是什么？
• 有没有第三方SNS接口注册接入，如果接入，需不需要同步头像，需不需要同时必须新建本地账号。
• 第三方SNS接入的流程，回调接口，以及界面设计
• 相关前端和App界面设计图，错误对话框UI

需求文档越详细，后期开发与测试遇到的误解就越少，试错成本也越低。该文档必须保持在线实时更新，有任何变更，研发团队必须第一时间得知。不要通过短信或者Email更改需求，这会使团队和产品经理陷入无尽的扯皮炼狱之中。

1-4. 细节的力量

如果说女性太注重于细节，是期待对方给足自己安全感。那么我们在做项目时注重细节，其实也是给自己一种安全感：减少返工。一个口碑好的软件，肯定是从用户需求分析开始就研究细节，设计时重视细节。

大部分程序猿都是非常看重技术，但从男性视角介入软件产品设计时，很容易陷入工程师思维：先考虑怎么做，再考虑做什么，最后考虑为什么做？一看到新项目，脑海里浮现的立刻是各类框架，各类中间件，高并发，恨不得立刻开机撸码。

而从女性角度介入软件产品设计时，她们往往会带有与生俱来的消费者直觉，会从第三方角度看事情。

我这里不是简单地贴职场标签，而是提醒不管是程序猿还是程序媛们，思考一下自己在设计产品时思维的盲区。

最后：

女人天生都是产品经理，只不过