第一步：业务需求整理
业务需求讨论时要重点交流以下几点：
- 目的性
- 场景多样性
- 约束
目的性
目前为止强调最多，但大家改善最少的思维盲点：站在用户角度协助用户思考并开发出有用的功能；而我们团队却一直疲于开发功能，开发客户不认可的功能，推倒重新开发，再推倒...
-
与客户交流时思考新需求的目的是什么？整理的需求文档中很少提及，这是对客户及自己团队的不负责
费掉时间跑到客户现场认认真真讨论好了需求，客户也付出了时间与精力成本，但带回团队的需求文档中却只字未提需求的目的是什么，团队开发出的功能自然很难满足客户的真正需求。
目前客户对我们的状态刚好解释了为什么有问题非要拉我们的人去他们现场，就是不信任我们团队的沟通理解力。
-
不只是个目的地
关于客户需求目的的最烂理解：
- 想优化样式
- 想改善性能、稳定性
- 想要个很棒的 APP
场景多样性
需求目的必须与客户场景关联，否则坐在开着空调用着稳定 wifi 办公室里的我们是理解不了客户的真正需求。
目前我们依然是被动的被客户怂着质疑我们的 APP 稳定性，为什么他们的用户在使用 APP 时总是提示『网络不稳定，请重新刷新』；如果在讨论需求时就了解了客户场景的网络信号不稳定时，其实开发逻辑中可以适当调整网络请求的重试次数及提示语的诙谐性。
了解了客户场景，再讨论需求时，可以明确提出各种可能性的异常提示，客户有了心理预期，后续客户的用户反馈问题时就更容易相互理解。
如果客户都不了解他们的用户，要不中止合同，要不领着客户去了解他们的用户，否则APP 的真正用户使用不爽时，客户只是问题反馈的传话筒；事前的准备不足或无准备，会是后续影响开发进度最大的障碍。
约束
每个团队都有他们特殊点儿的制度，体现在需求中会有多大的影响？
有时功能很简单，但那些为了某种目的而做的额外工作反而是个大工作量。比如如何防止报表中的数据被截屏公开？若不能避免，如何可以快速定位是谁发布出去的截屏。
实现了功能，最终却因无法实现约束性措施而被中止了合作，谁狼狈，谁损失，谁负责。
第二步：设计稿、流程图
若第一步的需求都未理解，设计稿就会更被动；团队理不出清晰的设计稿，客户给出的设计稿又只知道个所以然。
最懒的行为就是拿客户给出的设计稿作需求文档；反想一下，客户都辛苦整理出来了设计稿，后面的功能实现又不到位，对客户内心的伤害有多大！
APP 中的所有功能都不可能是单一的点击打开再关闭流程，所以一张设计稿是看不出来流程图的。
核心功能的设计稿配合需求理解应该出稿不同场景的操作流程图。
流程图一定要开发团队出，谁与客户讨论需求谁出。
第三步：交流、协作
若前两点都未做位，请努力做好再继续阅读。
交流需要成本，但必须交流；就像之前在微信群里强调『每次交流时，打字慢一些，把思路表述清晰些』，当手指快于大脑时，这那还是交流需求了，明明就是在解释上条消息中的错别字或表述有误的短句。
为什么说手指快于大脑，而不是说大脑比手指慢？倾斜木桶的长板原理，希望长板继续保留，短板继续改善，而不是反之。
目前需求文档要不只有一个设计稿，要不就是一两行代码，后续接手的同事该如何理解需求？
需求文档更新时，一定再通知相关同事，要有统筹交流的大局观。
第四步：接口设计、功能实现、测试用例
request -> server -> response
- 接口设计：服务器接收数据的格式
- 功能实现：需求讨论的处理方式
- 测试用例：模拟接口访问服务器（测试环境）
开发这块真是没什么可说的，talk is cheap show me the code。
该如何写接口代码，如何写功能实现、如何写测试用例，这是能入职团队的基本要求；要不自行学习，要不给团队交培训费用...
列一下团队当前的代码实现，有太多不足有待改善，希望每位成员可以提升它的至高点，而不是探索烂代码的下限。
