研发痛点
软件项目的研发，不只是“写写代码，改改Bug”这么简单。
创业团队早期注重野蛮生长和快速扩展，随着人员越多，业务越复杂，涉及的技术领域越广，更需要一套完整、清晰、规范的研发协作流程。否则，就会容易陷入团队混乱、流程混乱、项目混乱、系统混乱的窘境。
一旦陷入混乱，就会对以下常见的研发痛点更加深有体会：
- 都是“一句话需求”，开发不知要做什么，测试人员不知要测什么，只能边做边想，很可能做到最后做不下去，前面的时间白白浪费，需求搁置；
- 需求混乱，需求方或产品经理直接找一线开发人员，谁提的需求急就先做谁的，开发人员每天都很忙，天天在加班，但总感觉整体的产能不是那么理解；
- 时不时出现线上故障，不知道又是谁在发布了什么系统，不断“救火”；
- 内部的沟通协作冲突明显，消息得不到有效的流转和同步，甚至开会时公然拍桌子叫板；
- 团队不稳定，人员流动率高……
严控两个源头：需求+源代码
软件工程是一门学科，引自百度百科的定义：
软件工程是一门研究用工程化方法构建和维护有效、实用和高质量的软件的学科。
为了构建和维护有效、实用和高质量的软件，势必会存在对应的解决方案。
追本溯源，我建议可以从两个源头进行严格的控制。
一方面，严控需求源头。
需求提出后，产品经理要对需求进行文档化。不管是用Word文档，还是使用Axure的专业制作工具。好的需求文档，是整个协作流程的起点。坏的需求，自提出后，就会持续污染下游和后续的协作流程，包括：开发对需求不明确、测试对需求不理解、上线后客服和用户对需求的价值不清晰、后续发生了故障无法维护。更重要的是，需求不明确或没有记载，非常容易产生“纠纷”和“扯皮”，影响内部协作的氛围，增加内耗，损失时间成本不说，还损伤心情和增加心理负担。除了做好需求记录，还要做好需求评审。千万不要各自去猜产品的需求。
图片来自于网络
另一方面，严控代码质量。
需求规划和整理得再好，如果施工执行不当，也会大打折扣。Bug问题多，上线后容易出故障，维护成本高，存在安全漏洞，用户使用困难和体验差，对不同终端设备兼容性差等。严控代码质量，更为有效的方式是三角验证，通过第三方来评定。例如：测试验收、进行相互code reivew、使用Sonar等专业工具分析评估静态代码质量、通过自动化测试测试进行360度全方位的白盒测试、要求开发人员针对复杂和核心的需求提供技术开发文档并进行审查。
需求是方向，方向不明确则越走越步履维艰；代码是根基，根基不稳则越盖越可怕。
系统非常稳定，图片来自于网络
闭环管理的意义
作为技术负责人，或者作为老板，要考虑研发的整体闭环管理。
首先，要对整个团队和最终的结果负责任。
其次，要基于对结果负责的目标，制定和构建团队的协作流程和规范，以敏捷开发为蓝本，结合人员、业务特点、每周的时间线、内部的习惯和偏好，搭建闭环管理。
最后，落地实施。
闭环管理的意义在于形成正向的反馈和闭环，使得技术人员有成长、项目可以更快更稳持续迭代升级、公司的业务持续增长和迎来新的突破。犹如种子破土而出，向阳而生，开枝散叶，欣欣向荣。
所以，从个人、到项目、再到企业，分为三个闭环。
个人小闭环：注重高效的个人工作和习惯偏好，同时也要注意让团队成员每个人能充分发挥各自的优势和主观能动性，发挥集成智慧的力量。明确好职责和分工。
项目闭环：软件开发是一个需要高智力、频繁沟通和密切协作的过程。从一个抽象的需求提出来，到最终发布上线交付有价值且可正常运行的软件，这个过程需要多个部门、多个学科领域进行通力配合。由此，每次项目迭代的时间越紧凑，这个组织就越有活力；迭代得越频繁，企业的产品和业务就越有市场竞争力。当然，前提是，不以过度损坏项目质量为前提。
创业大闭环：把软件产品做出来是一回事，把产品卖出去又是另一回事，把产品卖出去同时提供好售后技术服务又是另一回事。如果要赢得客户的信任和口碑，需要整个企业组织更加密切地配合。大闭环跑通，通过MVP以最小的代价成本和风险验证产品，把产品卖出去以赢得付费客户，跑出ROI、ARR、付费漏斗和“性感的”增长曲线。
软件研发全流程闭环管理
结合我们自己在使用以及研发的YesDev工具，粗略分享下如何构建自己创业团队的闭环管理。分别五个主要步骤：
- Step 1. 需求池维护（需求越简陋，协作越痛苦）
- Step 2. 项目迭代（计划、统筹和协调能力）
- Step 3. 即时研发协作流（专注当下的高效工作）
- Step 4. 增量跟踪（风险把控，积极达成目标）
- Step 5. 一键发布（持续交付）
依次介绍如下。
Step 1. 需求池维护（需求越简陋，协作越痛苦）
坚持：一切需求，统一记录到需求池里。
针对需求，可以由产品经理或产品专员统一收集和记录，并整理成需求文档，在产品内部评审通过后，再流转给研发部门进行需求评审。
1、直接用富文本编辑器（会记录需求的历史变更）
2、上传Axure制作的PRD，并关联到需求
3、上传word或excel等需求文档的附件（word可以直接粘贴）
4、如果是使用第三方平台制作PRD，可以以链接形式提交，例如：墨刀、蓝湖的链接。
需求要记得做好记录，切莫以庞大的大版本需求为主，应以具体、细小、清晰的需求为工作单元。
Step 2. 项目迭代（计划、统筹和协调能力）
梳理好需求后，下一步就是进行需求评审，然后由技术负责人员组织开发人员和测试人员进行开发排期。细说下来就是：
1、需求评审通过后（若需求评审不通过，应打回，下次再评），规划好迭代的需求，指定项目负责人；
2、由负责开发的人员和测试人员评估工时和计划完成时间；
评估后的任务列表：
3、汇总项目总工时、项目排期和开发计划。
项目总工时体现了本次项目迭代需要投入的人力成本，
项目排期，可以让你提前知道项目的里程碑和计划完成时间，
开发计划表，可以让你更精确地把控每个计划的细节和更充分的信息，
4、使用项目燃尽图持续跟进项目的进度和把控延期风险，直到项目完成。
Step 3. 即时研发协作流（专注当下的高效工作）
高效的协作，离不开频繁的沟通，包括：面对面交流、每日站会、会议、视频，这些都需要实时和被动的通知。
为此，我们需要在日常办公中使用最多最频繁的企业微信群、钉钉群或飞书群中，和项目干系人等其他部门，一起围绕某个项目或产品线接收公开、实时的项目动态消息。
例如需求指派的通知：
又如Bug修复的通知：
群消息的意义和作用在于，让项目成员同步接收公开、透明和一致的实时消息动态。同时，邮件通知则是针对具体的工作负责人，进行的点对点的精准通知和推送。
例如Bug指派时的邮件通知：
更为重要的是，除了给开发人员提供实时的消息通知外，还要在减少对开发人员的干扰和不增加额外的人工操作成本，实现更高效、自动化和简单易用的协作流。这时，就需要用到GitOps了，即通过集成Git代码提交和关联到YesDev，同时实现智能通知和自动流转。
例如，按以下格式，
需求注释格式是：
需求#{需求ID}：开发人员填写的注释内容
其中，{需求ID}对应YesDev的需求ID，注释示例：
需求#666：首页静态页面开发
在开发人员提交注释后，就可以自动完成以下事情和动作。
1、需求状态，自动更新为【研发中】，方便更新和提供最新最准确的开发进度；
2、自动备注和上屏，方便针对需求进行code review（现有的Git工具都是针对分支的code review）；
3、自动为开发人员添加当天的任务，减少每天登记工时的烦恼；
4、发送必要、精准的邮件通知和IM群通知推送；
5、联动记录变更，形成操作记录。
你也可以通过统计报表，查看团队成员最近的活跃程度。
Step 4. 增量跟踪（风险把控，积极达成目标）
项目迭代颗粒度大时，你可以使用有效的工具和方式，进行更有针对性的管控，抓住核心，有的放矢。
一方面，你可以使用项目的任务看板，和敏捷看板，在每日站会时，实时更新团队的最新动态和遇到的问题。
另一方面，除了可以用项目的燃尽图跟踪单个项目的进度和风险外，你也可以使用项目甘特图和导出Excel，对多个项目或项目集进行宏观的分析和统筹。
还有，就是要学会看懂数据，并使用邮件进行有效地向上汇报。
为此，针对单个项目，可以使用项目汇总邮件，自动对比上一次的发送结果，从而可以有效地追踪在此的持续变化和增量内容。
在时间周期维度，可以按周或按每周二、每周四等时间频率进行汇总汇报，结合邮件和清晰完整的Excel附件，为上级提供简要和充分的数据和信息，辅助上级做出决策。
Step 5. 一键发布（持续交付）
最后，还可以接入一键发布。
在工作台上，找到一键发布。
进入一键发布后，就可以选择需要发布的系统，并关联到项目。
也可以查看发布历史记录，
以及发布成功后的群通知：
至此，从一个需求提出到发布上线，中间的研发闭环已经跑通。
更多的功能，以及具体的作用，可以直接免费注册YesDev体验使用。
