目录
1 软件开发涉及哪些环节
2 团队管理
2.1 建立配套研发管理制度
2.2 选择合适的研发管理软件平台
2.3 配套合适的绩效评价体系
2.4 组建研发团队
2.4.1 产品经理
2.4.2 项目经理
2.4.3 开发团队
2.4.4 测试团队
2.4.5 配置管理员
2.4.6 运维人员
1 软件开发涉及哪些环节
我认为软件开发涉及的环节有：团队管理、开发模式选取、需求管理、开发管理、测试管理、配置管理、发布管理、变更管理。打造出高水平的研发团队，开发出高质量的软件产品，要理顺其中相关的各个环节。
2 团队管理
团队管理包括公司或部门级的能力，也有产品或项目级的。
团队管理主要涉及：研发管理制度、研发管理软件、绩效评价体系及针对某个产品的研发团队的组建。
当然，团队建设还涉及其它方面，如人员培训体系建设、知识库建设等等，本文就不探讨了。
2.1 建立配套研发管理制度
研发管理制度一般是公司级，至少是部门级的。
此处主要针对研发流程、各节点的具体要求而制定的研发制度。
不同公司体量和发展阶段不断，不能生搬硬套，需要建立符合公司或部门实际情况的研发管理制度，目的是规范研发的流程，以研发团队目前的能力水平尽可能高效地开发出可靠、可用的软件产品。
1）规定研发流程，由哪些环节组成，每个节点的输入、输出及关键工作内容，对输入、输出资料的格式或内容要点的要求；
2）规定使用的研发管理软件平台；
3）规定研发团队的开发约定，如：
-
代码规范；
-
评审制度；
-
代码配置规范；
-
代码merge审核规范；
-
单元测试规范；
-
设计规范（如C4模式）；
-
数据库设计和变更的规范；
-
日志或ELK埋点规范；
-
复杂业务逻辑的策略模式代码规范要求；
-
高可靠性消息队列的访问规范；
-
项目阶段性复盘规范；
-
code review规范；
-
项目迭代的MVP编制规范；
-
等等...。
这些研发管理制度及相关子项应有具体的文件和使用指南（比如发布在知识库中，便于访问和更新），并辅以充分培训和检查，使之深入人心。
研发管理制度，是软件质量保障体系的制度保障。
2.2 选择合适的研发管理软件平台
一个好的研发管理软件，可以为研发团队带来极大的便利，大幅度降低沟通成本，是研发管理的利器。
研发管理软件有很多，如禅道、华为软件开发云、码云Gitee、Redmine、Teambition、JIRA等。
有些软件有开源版，或针对小型团队免费。
研发管理软件，最好能覆盖软件项目各个环节，即所谓的一站式，包括需求管理、开发管理、测试管理、发布管理，及相关的文档管理。
但是目前各款软件都有侧重和优劣，还有免费和收费的区别。
我认为，对于中小型团队，使用禅道开源版就差不多够了，其令人诟病的文档支持能力，可以使用其它系统来补充，如FTP服务器、网盘或知识库。
用好研发管理软件，是公司研发软实力的组成部分。
2.3 配套合适的绩效评价体系
合适的绩效评价体系，对激发和保持研发团队战斗力是非常重要的。当然，不合适的绩效评价体系，可能适得其反。绩效评价体系一般是公司级，至少是部门级的。
根据我的经验，大部分研发团队基本符合2/8法则，即20%的人员做了80%的工作。因此，如何激发80%的人员，使之可以承担更多比例的工作，对团队管理非常重要。
这里有主观意愿因素，也有能力因素和业务熟悉度问题，作为研发管理者，应努力提高团队的各个体的能力，激发上进心，营造融洽的沟通文化。
因此，绩效评价体系必不可少，否则容易导致劣币驱逐良币，也就谈不上高效的研发团队。
绩效评价分为客观部分和主观部分。客观部分由工作量和工作质量组成，主观部分一般是主管和协作同事或部门评价打分，包括各种能力和态度。
关于开发工作量评估，我的经验，是在部门建立专家组（高级程序员），评价任务工作量时，抽出2个高级，加上team leader，再临时召集2个中级，作为工作量评估小组。
针对一批任务，先由team leader讲解任务内容，然后大家各自写出工作量（以代码开发任务以中级程序员能力为基准），以小时为单位，然后大家亮出结果，如果最高和最低相差较大，则需要阐述理由，大家觉得理由充分，就投票决定工作量；如果相差不大，取中位数的工作量即可。评估后的工作量，作为标准工作量，不管谁来完成该任务，其标准工作量是不变的。
这种做法，只能是相对客观，但确实是发挥了研发团队的大致能力。当然，还是可以通过度量、复盘来持续改进（多次迭代），提高工作量评估的准确性。
至于不同岗位相对于标准工作量，可以有一个系数，如初级工程师来做，实际工作时间要超过标准工作量，但相对于其能力来说，已经做得很好了，因此需要适当补偿。具体怎么量化，大家可以自行估计，可通过多次迭代，使之符合研发团队现状，这也是成熟研发团队的软实力的一部分。
建立合理绩效评价体系，让我们可以更专注工作本身，而不必拘泥于所谓的996或007的加班形式，避免出现老板与员工关于工作付出和收益之间博弈，提高团队的凝聚力。
2.4 组建研发团队
研发团队，R&D Team，这里是指围绕特定软件产品组建的研发队伍。
组建研发团队是整个研发工作的基础。如果队伍阵容不整，软件项目的成功将面临更多挑战。
对软件产品而言，一个相对健全的研发团队包含产品经理、项目经理、开发团队（包括开发项目经理、系统分析员或高级程序员、UI&UE设计人员、若干前后端开发人员）、测试团队（测试组长及若干测试人员）、配置管理员、运维人员。
管理者要根据产品或项目的特点组建合适的研发团队。要认识哪些岗位是不可或缺的，对不可或缺的岗位，可以安排兼任，但不能丢弃其职责。
2.4.1 产品经理
按照百度百科的说法，产品经理（Product Manager）是企业中专门负责产品管理的职位，产品经理负责市场调查并根据产品、市场及用户等的需求，确定开发何种产品，选择何种业务模式、商业模式等。并推动相应产品的开发组织，他还要根据产品的生命周期，协调研发、营销、运营等，确定和组织实施相应的产品策略，以及其他一系列相关的产品管理活动。
对于大一点的公司，有专门的产品部门。
对于产品类软件，产品经理是不可或缺的。
产品经理一头是对外的，对接市场、销售和客户，其负责规划、裁剪和导入产品需求，制定产品路线图（RoadMap），编制阶段性大版本的功能性能需求集合。其对需求的取舍有最终的裁决权，因为其对最终交付的软件产品负责。
产品经理往往是业务领域的专家，至少要努力成为业务领域的专家，这样才能准确理解和把握客户的需求。对业务领域不熟悉的产品经理，对整个团队而言，可能是致命的。
产品经理另一头是对内的，对接开发、测试、运维团队。产品经理不必是技术专家，但其需要能够理解开发团队的诉求，包括开发测试资源（或环境）需求的满足，对存在技术实现障碍或实现代价较大的需求是否进行需求降级的取舍。
对于工程项目类的定制开发软件，也是需要产品经理的。
如果公司接触的是全新的业务领域，此时往往客户方是业务领域的专家，公司往往会指定开发项目经理来对接技术。此时要求客户方作为产品经理的角色足够投入，并且需要相互信任和理解对方，容易沟通，不会在问题发生时强调责任归属而扯皮，否则项目实施的风险就会很大。
如果公司在某个业务领域有类似经验，公司应将有经验的产品经理加入团队，由其对接客户，可大大提高项目的成功率。这种情况，产品经理可以兼顾多个同类项目。
遗憾的是，很多项目大都是由对业务不熟悉的开发项目经理（Team leader）负责，其可能是软件技术方面的高手，但由于不熟悉业务，于是项目团队不知要踩多少个坑，结果往往不太理想。
2.4.2 项目经理
按照百度百科的说法，项目经理（Project Manager），简称PM，主要负责统筹规划项目进度及产品生命，其工作职能直接对公司高层负责。作为项目的管理者，PM通常会参与到一个或多个项目的管理与决策工作中。主要工作要求即在有限的资源约束下，运用系统的观点、方法和理论，对项目涉及的全部工作进行有效地管理。从项目的投资决策开始到项目结束的全过程进行计划、组织、指挥、协调、控制和评价，以实现项目的目标。
比较认同网上的一个观点：产品经理对产品成功负责，项目经理对完成项目负责。
对于大一点的公司，有专门的项目部门。
项目经理强调过程控制并确保项目有计划、有序的、风险受控方式的开展和完成，而产品经理则强调结果，需要产品成功交付或销售额达到一定数额。
如果公司较大，项目团队的成员分属多个部门，此时项目经理是不可或缺的，需要他来发挥组织、协调、管理进度和质量的作用。
对于小型团队，项目经理不是必需的，此时往往由开发项目经理来兼任。
具体而言，项目经理是协助产品经理，来组织管理产品的每一次交付集合的开发工作。包括：
-
组建项目实施团队并为项目和团队命名；
-
协调研发团队各方并起草项目开发计划；
-
度量和评价项目进度和质量指标；
-
当进度或质量指标发生异常时，及时介入并会同研发团队想方法解决；
-
协调研发团队各参与方的有序衔接，消除无人负责的灰色地带；
-
组织相关评审工作；
-
组织变更的分析、评估、评审和实施；
-
组织配置管理（版本管理）的基线管理；
-
组织版本的发布工作。
2.4.3 开发团队
开发团队，Development Team，这里指针对特定软件需求的开发队伍，负责软件开发实现。主要职责为：
-
软件需求分析；
-
系统设计（或称架构设计）；
-
接口设计；
-
UI&UE设计；
-
子系统或模块的概要设计；
-
重要功能的详细设计；
-
编码实现；
-
单元测试和联调测试。
软件开发团队的核心成员是开发项目经理，即技术负责人，一般是高级程序员或开发总监来担当。其带领整个开发团队进行开发活动。如果项目不大，软件开发团队缩小为一个软件开发小组，开发项目经理即为开发项目组长，即Team Leader。
如果公司较大，有专门的系统部，系统分析员或架构师归属于该部门。
对于中小型公司，仍需要有系统分析员或架构师（中小型项目一般由Team Leader兼任）来参与到项目中，其主要职责是：
-
软件需求分析；
-
系统设计（或称总体设计、架构设计）；
软件需求分析对软件项目是十分重要且必要的。软件需求与产品需求并不是一回事，软件需求来源于产品需求，然后转化为软件需求，包括功能需求、性能需求及各种质量属性需求（如灵活性、安全性、可靠性、可移植性、可用性、可维护性、国际化等等）。做好软件需求分析，等于项目成功了一半。详细阐述在需求管理章节中展开。
系统设计，也是非常重要的。好的架构设计，可以大大延长软件产品的生命期。很多年前，流行一句话：好的产品都是设计出来的，确实如此。
UI&UE设计，即用户界面及交互设计。UI&UE设计，低保真模型，用于产品需求的原型，是非常合适的；高保真模型，可用于软件需求的一部分，指导前端开发，及前后端的接口开发。
开发团队的主体是软件开发小组，小组的数量取决于软件涉及的子系统的数目。中小型软件，只需一个软件开发小组。
软件开发小组的成员组成，与项目选取的技术栈有很大关系。如采用前后端分离模式，后端使用Java语言Spring boot框架，前端使用VUE，则要求相关人员按此需求来配置。
软件开发小组主要工作是编码实现，但应包括子系统或模块的概要设计文档，接口文档；视需要，重要功能也应该有详细设计文档。
软件开发小组还需要实现单元测试。要充分利用已有的单元测试框架，如Java的JUnit，以提高单元测试的效率。
代码提交测试人员测试前，还需要完成联调测试，如果联调测试都通不过，而直接提交测试部门测试，将造成测试资源的极大浪费。
2.4.4 测试团队
测试团队，Test Team或QA，是保障软件质量的重要单元。对于中小型软件，可以是一两个软件测试工程师，甚至一个软件测试工程师兼顾多个项目。
但测试人员是必不可少的。
测试团队使用软件测试方法，根据需要，提供下列测试：
-
功能测试（黑盒测试）；
-
接口测试；
-
性能测试（压力测试）；
-
视需要与开发人员共同完成白盒测试；
-
必要时，搭建自动化测试框架，以更好地支持回归测试。
测试人员和开发人员的视角不同，不可相互替代。
2.4.5 配置管理员
配置管理包含版本管理，对于较复杂的系统，其涉及多个子系统，每个子系统又有依赖的组件版本，这些构成了全部的配置项。
对于Java，有Maven工具，帮助管理组件的版本，可以省心不少。
配置管理员一般由开发项目经理兼任，如果项目较大，可以另行专门指定一个配置管理员。
配置管理员协助项目经理（PM）和开发项目经理（Team Leader），完成配置管理工作。
代码的版本管理，一般使用版本管理工具，如VSS、SVN、Git。现在一般用git。
配置管理员创建必要的代码分支，并进行代码merge审核，设置代码基线（或tag）。
没有良好的配置管理，导致代码版本混乱不堪，质量保证就无从谈起。
2.4.6 运维人员
现在项目大多是云部署的项目。涉及web服务器、数据库服务器、消息队列、Redis等，从可靠性和性能角度，还可能集群或分布式部署，还要考虑网络安全等因素。
因此，如果项目涉及云部署，应该有专门的运维人员，他可以兼顾多个项目。
运维人员往往兼任数据库管理员，及版本上线发布。