协作
WARNING
该部分需要完善。
没有人能永远单兵作战，所以协作是一个无可避免且非常现实的话题。
工具
Git
Git 是目前最流行的版本管理系统。我们提供了 GitHub、GitLab 和 Atlassian 三个版本的速查表供你翻阅，你也可以阅读 Pro Git 来深入了解、运用它。
Microsoft Azure DevOps
司内使用 Azure DevOps 作为 Git 服务商。也就是说，你和你的同事会把代码存放到 Azure DevOps 上，并用 Git 管理它们。
你可以查阅它的文档了解它的最佳实践。
YesDev
司内使用 YesDev 作为研发协同工具。也就是说，你和你的同事需要在上面记录需求、记录任务、登记工时、追踪问题等。
你可以查阅它的文档了解它的最佳实践。
GitHub
GitHub 是全球使用最广泛的 Git 服务商，上面存放了大量的开源项目。你可以从上面的大量开源项目中吸取经验。
人
产品经理
产品经理往往负责调研用户需求，确定研发具有什么功能的产品，协调研发、营销、运营等⼀系列相关的产品管理活动。
用六何法来描述，产品经理需要把控目标用户是谁 Who、目标用户需要什么产品 What、为什么需要该产品 Why。他还需要协调研发、营销、运营等人员 Who，以及确定交付时间 When 等以维护与目标用户的关系。
常见反例
❌ 产品功能我说了算，不用问客户了。
产品的目标始终是客户，不能忽略客户的意见和建议，但也不能全盘接收客户的意见和建议，需要加以甄别和判断。
❌ 其它的产品有这个功能，我们的产品也加一下吧。
❌ 我觉得这个功能挺有用，我们的产品也加一下吧。
产品经理应该要明确指出这个功能的实际作用和使用场景，确保功能是真实被需要的。
❌ 客户临时加了一个功能，我看着不难，你们研发赶紧做一下吧，争取这个星期上线。
产品经理可以和研发团队协商、调整、确认后再回复客户，避免影响研发进度和项目整体进度。
研发人员需要从产品经理处了解目标用户、用户需求，理解自己即将参与的是一款什么样的产品。了解这些概念后，研发人员可以从更高的上下文来试着调整自己当前的工作目标，也能在研发过程中提出自己的见解等，帮助产品变得更好。
常见反例
❌ 我只需要按着要求做出来就行，不需要过多思考。
如果只是一味地做而不思考，团队会极其脆弱，也容易陷入个人崇拜。每个人都可能犯错，每个人都可能有更好的想法，只有每个人都能为每一环做出贡献，团队才会足够健壮。
如果你想要了解更多产品经理的知识，你可以阅读 人人都是产品经理、人人都是产品经理 2.0、产品经理方法论 等书籍。
项目经理
项目经理往往具有技术背景，负责接收、核对、评估产品经理传达的用户需求，敲定架构，攻克技术难点，拆解任务并分配、落实给相关的研发人员，在预定时间内高质量地完成预期产品目标。项目经理也需要协调研发相关的工作，可能也会参与到研发中。
用六何法来描述，项目经理需要确认和核对产品功能 Why & What、处理架构和技术难点 What、分配目标或任务到个人 Who、把目标拆解成任务 How、落实产品质量 What、在预定时间完成目标 When。
常见反例
❌ 客户需求已经由产品经理落实，我只需要推进落地。
这会导致团队严重依赖产品经理，团队会极其脆弱，也容易陷入个人崇拜。每个人都可能犯错，每个人都可能有更好的想法，只有每个人都能为每一环做出贡献，团队才会足够健壮。
❌ 这个功能比较难，交给别人做需要多花一点时间，即使预计时间很充足，但还是我自己来做这个吧。
项目经理需要合理评估难度。如果只有自己能做出来，那确实是需要自己来做。如果说时间还充裕，交给别人做只需要多花一点时间，应该要交给别人做，这对于别人来说是一个锻炼的好机会，有利于提高团队整体素质，同时也符合四象限工作法的思想。
❌ 我需要一直为我的同事拆解任务。
授人以鱼不如授人以渔。项目经理应该为研发同事展示如何将目标拆解成任务，并教授其中的技巧。这有利于提高团队整体素质，形成相对合理的工作流程。
❌ 我的同事完成了功能，让产品通过验收，一切完事大吉。
完成功能应同时满足以下三个条件：功能符合需求文档、具备基本测试、通过基本测试或手工测试。在实践中，允许缺少基本测试，但这时必须通过手工测试。过于宽松的要求容易降低团队整体素质，降低产品质量。
研发人员需要和项目经理核对任务、工期，落实代码质量，并及时给予反馈。在研发过程中，研发人员可以向项目经理寻求更高上下文的帮助，请求协调工作安排，也可以沟通研发细节，提高产品质量。
常见反例
❌ 我只需要按着要求做出来就行，不需要过多思考。
如果只是一味地做而不思考，团队会极其脆弱，也容易陷入个人崇拜。每个人都可能犯错，每个人都可能有更好的想法，只有每个人都能为每一环做出贡献，团队才会足够健壮。
❌ 我不需要自行将目标拆解成任务，一切都交由项目经理处理。
项目经理并非全知全能，每个人都可能犯错，每个人都可能有更好的想法，只有每个人都能为每一环做出贡献，团队才会足够健壮。
❌ 我可以花很多时间来调试一个难题，只要我准时完成就行。
花很多时间来调试一个问题，本身是极具风险的。一来，你没法保证你的时间投入是值得的，也就是你可能到最后也没有得到结果；二来，你没法保证你可以准时完成。在花费一些时间无果后，你应该向你的项目经理汇报并寻求帮助，以便正常推动研发进度。
❌ 在有别的任务需要我去完成时，我应该立刻完成它再回来继续原本的任务。
任务需要区分轻重缓急，否则容易陷入不知所向的迷茫之中。如果不能自行决断，你应该向你的项目经理汇报并寻求帮助。
设计人员
设计人员的工作是把产品设计得更有逻辑的好看，往往包括用户界面设计和用户体验设计。
用户界面设计考虑的是如何把组件组合成页面、组件应该放置在哪个位置等，而用户体验设计考虑的是组合的方式是否满足用户使用需求，如上传大文件时不应该要求用户等待文件上传完毕后才能做其它无关操作，否则算得上没有逻辑，是一个失败的用户体验设计。
用六何法来描述，设计人员需要考虑目标用户 Who、设计用户如何使用产品功能 How & What。
研发人员需要结合目标用户和用户需求等，理解设计人员的设计意图，落实设计人员提供的设计稿，还原到实际产品上。
常见反例
❌ 我只需要按着要求做出来就行，不需要过多思考。
如果只是一味地做而不思考，团队会极其脆弱，也容易陷入个人崇拜。每个人都可能犯错，每个人都可能有更好的想法，只有每个人都能为每一环做出贡献，团队才会足够健壮。
如果你想要了解更多设计相关的知识，你可以阅读 About Face、Web 界面设计、界面设计模式、写给大家看的设计书、简约至上、设计心理学、Web 表单设计 等书籍。
研发人员
研发人员具有技术背景，负责落实产品的实际研发，包括从前端到后端的功能研发。
用六何法来描述，研发人员主要需要在预定时间内实现功能并保证质量 When & What & How。同时，研发人员也应该理解产品背后真实的用户需求 Why。
不同的研发人员可能负责不同的功能模块，也可能共同开发一个功能模块，甚至可能需要负责一整个项目。在协作时，应预先划分工作范围，并及时安排联合调试等。
常见反例
❌ 某某比我更有经验，他说的一定正确。我只要跟着做就行。
每个人都可能犯错，每个人都可能有更好的想法，只有每个人都能为每一环做出贡献，团队才会足够健壮。
测试人员
测试人员具有技术背景，需要在规定的条件下操作产品，以发现产品潜在错误，衡量产品质量，并评估其是否能满足需求和设计。
和研发人员类似，用六何法来描述，测试人员主要需要在预定时间内测试功能 What。同时，测试人员也应该理解产品背后真实的用户需求 Why，以避免构造了错误的测试样例。
不同的测试人员可能负责不同的功能模块，甚至可能需要负责一整个项目。测试人员应记录并整理功能缺陷，反馈给研发人员，并及时向上汇报。
常见反例
❌ 这是一个找茬的工作。
这是一个发现产品潜在错误、促进提高产品质量的工作，并非是找茬、鸡蛋里挑骨头的工作。
运维人员
运维人员具有技术背景，根据业务需要规划信息、网络、服务，通过网络监控、事件预警、业务调度、排障升级等手段，使服务处于长期稳定可用状态。
用六何法来描述，运维人员主要需要架设好服务器并提供部署服务可用的环境 What，并保证服务持续稳定可用 When。运维人员的工作往往涉及 docker、nginx 等工具，保证研发成果得以对外正常展现。
不要设限
不要被角色限制了自己。
你可以是研发人员，你也可以是设计人员、测试人员、运维人员，你更可以是产品的用户、产品的使用者。
不要局限于一个角色，尝试调整自己的角度，站在不同的立场和上下文看待同一个事物，你会有不同的想法，进步得更快。
流程
一个简单但完整的协作流程表格如下所示。
| 阶段 | 人员 | 内容 |
|---|---|---|
| 需求分析 | 全员 | 开会明确需求、预期使用者量级等，接收团队反馈，确保需求认知统一 |
| 文档产出 | 产品经理 | 落实需求、反馈、思考等内容到文档并及时更新，之后沟通以文档为准，给出产品原型图 |
| 文档产出 | 项目经理 | 落实架构、研发难点等内容到文档并及时更新，之后沟通以文档为准 |
| 文档产出 | 设计人员 | 根据产品原型图做设计图 |
| 文档产出 | 研发人员 | 落实接口设计到文档并及时更新，之后沟通以文档为准，可能需要原型图和设计图做调整 |
| 架构设计 | 项目经理 | 构建项目架构，如有必要可给出架构文档 |
| 实际研发 | 研发人员 | 前后端根据接口文档并行研发，前端模拟请求，后端自测接口 |
| 联合调试 | 研发人员 | 前后端联调，检查接页面、功能、接口等内容是否有误 |
| 提交测试 | 测试人员 | 代码交由测试人员测试，如有必要可请求运维人员部署到内网协助测试 |
| 部署发布 | 运维人员 | 部署到线上环境，对外开放 |