声明：本文不参考、不作为任何行业标准，完全是个人日常工作中的一些思考沉淀。目前没有成体系的知识，只能从各种角度进行探讨；本文所述的内容，大前提是已经有了具体的需求，有了需求之后该怎么做。

团队的主要特点就是分工与协作，每个人都有自己的任务，完成任务的同时需要与其他成员协作。

项目经理把握整个项目的方方面面，可以看做是航行在大海上的一艘船的船长，或许不能方方面面做能事无巨细，但是把握着项目的大方面、进度、决策等各种关键，或许也能看做是中央处理器，数据进出都得靠他。主要就是“拍板”！

产品经理，字如其意，我们的产品到底要做成什么样？负责和客户对接需求，把客户抽象的描绘，具现化成一个具体的、看得见的、摸得着、能让大家理解的产品。同后端开发协作、同前端开发进行协作、同UI设计进行协作？同运维人员进行协作？

一般都是同产品经理进行协作，产品应该做成什么样？应该使用什么样的交互方式？最后做出产品的设计稿，交付前端人员开发。

实现系统后端部分的功能，考虑怎么又快又好的实现需求。

实现系统前端部分的功能，考虑怎么又快又好的实现需求。

从各种刁钻、极端的角度测试系统功能的稳定性，找BUG

维护系统稳定运行。

项目里的各种文档应该是很重要的一个组成部分。有时也可以作为责任划分的标准和证明

能让整个团队成员知道自己要做的是一个什么样的产品，自己需要做成什么样，思考自己该怎么做。一般由产品经理总结，大家一起探讨可行性、实现方案、优先级。（竞品分析）

标准化、成体系的东西，可以让大家协作起来更加的方便，设计风格统一。UI设计规范包括系统内元素的字体大小规范、颜色规范、边距、补白等。可以避免协作时出现不同的标准。

很大一方面的作用是让前端专注于开发，让一个前端去思考怎么做才好看实在是太难了。

前后端人员一起探讨、交流得出（交流尤为重要），作为双方开发过程中的数据交换标准。后端人员只需要按照文档开发接口、前端人员只需要按照文档对接接口。可以避免很多无用的交流，以及部门开发过程的矛盾。

产品的原型，可以在开发初期用来给客户演示产品，避免开发进度过半了，客户说这不是我想要的东西。

代码规范、注释规范、变量命名规范等，让大家写出来的代码风格差不多，相互看代码的时候更容易理解。

记录项目开发进度、开发期限等。

前后端选择合适的开发框架，然后开发开始。

多人协作开发，这个理当是标配。主分支作为永远是最新可用版的分支，其他开发人员在各自的开发分支上工作，合并只能提交PR由专人审核。

记录项目开始之后，所有的变化。主要是让大家知道每天都达成了什么目标？干了什么？让大家的开发节奏保持稳定

代码谁来审核，谁来管理PR？

搭建项目的开发框架、构建工具，参与系统拆分。让其他人员专注于页面开发。

按照系统 -> 子系统 ->页面 -> 容器组件、公共组件、UI组件 等划分成更加细化的需求，划分之后更加容易分工，统筹开发进度。

在老手们的带领下，专注于页面开发。

新手可以专注于静态页面的编写，编写OK了交给其他人去编辑编辑、对接数据、对接接口。

1.如何界定一个人的劳动产出？

2.如何让大家一起协同进步？

3.如何保持团队和睦？

4.如何让大家明白沟通的重要性？

5.如何让成员敢于、善于表达自己的想法？

5.应该保持什么样的工作氛围？