我理想中的团队，首先要有一个核心理念：先做正确的事，再把事情做正确。
开发前的准备——为什么不一开始说清楚需求呢？
有没有遇到这样的情况：
- 需求就是一句话的文字描述，没有任何的设计；
- 需求从来都不评审，开发被迫实现一些非常恶心的功能；
- 从来不看现有的功能是什么样的，导致做的功能风格差别大； ……
看似跳过评审和设计阶段是节约了时间，但最终做出的东西质量很差，或者经常返工。其实开发前的准备，需要做到团队每个人，知道自己要做什么。如果通过原型图或者需求文档，开发无从下手，那么就需要评审会议，把需求说清楚。
真实案例：
需求描述：把附件上传功能的上限调大一点，把背景色调浅一点。
更离谱的是，让开发现场调颜色，直到他满意为止，需求人员也不知道需要什么颜色。
虽然有些交互的细节，原型图或者需求文档可能描述不全，但大的需求框架应该要描述清楚，确保开发知道要做什么。
开发过程中的沟通——为什么不用群聊呢？
真实案例一：线上有问题，客户反馈给实施，实施反馈给客服部，客服部反馈给测试，测试反馈给开发部门经理，再反馈给开发人员。紧急的时候，实施、客服、测试、部门经理都去问开发什么时候能改好，开发要回复好几遍。
真实案例二：需求变更之后，只通知前端怎么改交互，测试都不知道。等提交测试的时候，测试看到功能实现和需求不一样，又要去花时间沟通。
群里沟通，目的就是降低沟通成本，提升团队的效率。众所周知，JavaScript的对象访问，要比数组遍历快。群，就是栈的数据结构，想知道什么信息，直接寻址即可；私聊，就是队列，需要遍历才能知道想要的信息。
开发过程中的核心——末梢管理——为什么不自测呢？
这个词是自己造的，末梢，就是一件物品对外连接的地方。末梢管理，要求我们在和其他人对接的时候，要确保自己的东西是正确的。
真实案例一：腾讯新闻推送事故：
虽然只少了一个字，但意思确实天壤之别。公司内部培训时一直都会拿这个事情举例，希望我们把东西交付给别人之前，自己先检查一遍（检查交付出去的东西）。因此我们公司的消息推送平台都有一个发送给自己的按钮，先发给自己看看，检查一下。
真实案例二：
程序员经典语录：It works on my machine.——我本地是好的。我自己也出现过好几次。有一次只是改一个字，改完提交之后，用自动化编译平台打包部署，看这个命令跑完，我就通知测试改好了，结果打包服务器恰巧出了问题，没部署成功。
最终处理方法：自己去测试环境上看看是不是真的生效了，测试环境上的东西才是我们交付给测试人员的成果。
真实案例三：
和后端对接接口的时候，后端有这样的行为：后端不自测他的接口功能，等到前端对接的时候，前端发现各种问题，依靠前端去告诉他哪里有问题。这种行为，本质上就是让前端帮后端测接口。
最终处理方法：后端接口也要提交测试，目的是为了检查接口有没有返回一些额外的敏感信息，以及检查一下后端逻辑（有可能后端逻辑不对，但是前端显示没有问题）。
项目总结——努力做到“不贰过”
不贰过，是非常困难的，我们只有不断总结，才能在未来的工作中提前避开一些坑，以及平时做的不到位的地方，也需要指出来。
- 如果有返工，需要总结一下，是谁的工作没到位导致的；
- 如果产品质量差，需要分析bug的原因；
- 如果项目延期，是哪一个环节没有做好； ……
项目负责人的关键作用
项目负责人主要是业务负责人和技术负责人。项目负责人需要对什么是“正确的事”有认知。
- 把控交互和技术的细节
真实案例：
一个表单输入开始日期和结束日期，会得到天数。这个天数其实是开始日期和结束日期的计算值，是否需要再把天数传给后端。
其实天数传不传，都不影响业务功能的实现，只是正确的事在不同人之间的不同体现而已。有人觉得传的数据越简洁越好，有的觉得都已经前端计算出来了，后端就直接用这个值了。每个人都有每个人的看法，这时候就需要负责人去解决这些争议，并且形成一定的规范。
常见规范：
- 数据来源关系强绑定，就是上面的例子，天数就是开始日期和结束日期的计算值，而不是手动输入的一个字段，不可手动写入；
- 所见即所得，即后端返回的数据就可以直接展示出来，不需要再进行转换了；
- 监督团队成员的工作
这里的监督并不是指盯着写代码，而是这样的工作：
我们团队的构成是前端、后端、测试分属不同的部门，群里面都有部门经理。 如果群里有人被@了但是一直没有回复，需要部门经理提醒一下，所以我们@别人的时候，也会带上他的上级领导。
总结
什么是正确的事？实际上就是有利于团队的事。理想中的团队，就是团队的每个成员都在想办法提升团队的效率，让每个人都轻松，在此基础上，才有机会去提升产品质量。
