我们目前采用的是onboarding-oriented （改良敏捷）的开发模式，可以先熟悉这个过程中的各个基本概念，看完产品开发流程sop，再来看这个协作原则。在我们目前开发的模式里，产品开发的过程就像是踢球赛，重要的是如何配合协作赢得球赛的胜利，每个开发者都是不可或缺的队友。
以下是产品开发过程中的基本协作原则：
- 明确目的，统一目标
- 明确分工，确认分工
- 全员对最终产出负责
- 了解项目进度，及时告知自己的进度
- 对项目高标准，对自我高标准
- 过程透明，不做信息黑洞
- 发现问题即时反馈
- 主动协作
- 用户思维为第一导向
- 学会处理分歧
- 信任队友，做一个可以被信任的人，说到做到
参与开发的队员需要都明确目的是什么，目标是什么？
-
通常接到一个指挥官任务，或者接到一项需求，首先要明确为什么要做这件事，做这件事的目的是什么。
-
确认目的才能够辨别目前所做的事是否有助于目标达成，在之后的开发过程中也以目的为第一原则
目标通常情况下是：为了达成什么样的目的，在什么时间前，做完一件什么样的事。
参与开发的队员应该都明确为了达成这个目标，我们具体要做什么。每个人的具体分工是什么，自己的分工是什么。
- 为了达成目标，需求应该是什么。这个是由全体队员讨论的结果，比如要做徽章系统，具体要做哪些徽章。第一版要做成什么样。
- 接下来要明确分工
- 谁负责拆分User Story，和CEO确认User Story
- 谁负责设计，谁负责写前台界面，谁负责后端
- 谁负责组织跑onboarding
- 谁负责最终确认成果，确认上线节点
- 在目前团队采用的改良敏捷的开发模式中，所有人都是对产出负责的。就像一场球赛一样，如果球赛输了，那相当于所有的队员都输了。如果赢了，成功是每个人的。
- 改良敏捷的模式里，需要全员对整个项目都有责任意识。
- 区别于传统瀑布开发，出问题大家不需要互相甩锅，因为全员都有责任，需要共同检讨，做AAR
- 由于是全员负责模式，所以每个人都有义务了解目前项目的进度。
- 至少做到，当天结束工作时，每个队员知道自己项目目前的进度是怎样的。当天结束工作时，让队友知道你的进度是怎样，是快了还是慢了，有没有什么问题或者困难。
- 以A级标准来要求项目，如：通常指挥官级别的User Story能切分至30 - 60张票，指挥官任务级别的onboarding通常会开出50-100张票，解决大致30 - 50张票
- 以A级标准来要求自己，如：中高阶产品开发工程师一天至少解决10张票，熟练应用onboarding，拆分User Story，确保项目按照进度上线
- A级的定义是：在市场范围内，该选手输出成果能达到前10%的选手输出的标准。
- 所有的进度都要通过redmine可查，可复原，如果是通过口头沟通得出的结论，也应该更新在票上。这样其他队员和公司其他人才能得知你目前的进度如何。
- 应该做到：哪怕不专门和其他人沟通，其他人也可以通过redmine activity还原你今天的工作内容
- 涉及到全公司的内容，比如产品release，应该告知相应的人。例如：徽章功能上线后，需要告知cs组，不然客户问题来，客服组并不知道上了这个新功能。
- 出现工作疏失会引起问题的，也应该第一时间汇报，早期发现火苗是容易的，到后期就不好灭火了。
- 如果在项目中任何一环观察出现了问题，主动向上反馈，如：
- 需求不清楚，不知道做的对不对
- 分工不明确，没人确认需求，或者写User Story
- 项目进度明显慢低于预期
- 开发过程中，大家对需求的理解严重不一致，无法协商
- 或者是任何你觉得影响进度，结果的问题，一定要主动向上反馈
- 区别于瀑布开发模式，不会有有一个pm做专门的协调，沟通的工作。
- 如果需要队友的配合才能完成一件事，你发现队友的进度不如预期，请尽快主动找他沟通
- 不要被动等待队友来跟你沟通
- 在产品开发过程中，用户思维是第一导向。
- 凡是不清楚怎么样比较好的，回归第一性原理，我们的用户希望怎样比较好。
见 [如何处理产品开发过程中产生的分歧]
- 相互信任是敏捷开发的核心之一
- 每个人都应该说到做到，对项目负责，如果没有做到，一定要及时告知队友，找到补救措施。