马云在一次公开演讲中提到，"过去数字化是企业活得更好的一个手段，而现在和未来，数字化是企业活下去的关键。"在数字化的过程中，最大的成本就是软件研发的成本, 通过数字化管理软件研发就变成越来越重要的事情。
本文作者杜仲（肖劲青），健信科技创始人 &CEO，TGO 杭州滨江 2 组成员。有二十余年软件研发经验，旗下有自研的“软件研发数字化管理产品——Joyone”。本文将总结杜仲团队在软件研发管理领域的多年的实战经验。
数字化，是一个大家耳熟能详的词，国家十四五的规划报告中，关于数字化、数字经济相关字眼反复多次提到，且在相关的数字指标中，软件和信息服务业从 2020 年的 8.16 万亿到 2025 年的 14 万亿，行业领域持续高增长，年复合增长率超过 11.4%，无疑是一个巨大的朝阳产业。
马云在一次公开演讲中提到，"过去数字化是企业活得更好的一个手段，而现在和未来，数字化是企业活下去的关键。"
而我们都知道，企业、政府的数字化转型，都离不开软件系统的支撑，对应的业务系统无法落地，那么数字化转型也就是空谈了。在数字化的过程中，无论企业是选择自研还是外包由第三方来实施，最大的成本始终是研发人工成本。软件研发团队中的角色、岗位随着时间的发展将越来越多、越来越复杂，带来的软件研发的组织难度也会越来越高，所以通过数字化管理软件研发就变成越来越重要的事情。
我们团队在软件研发管理领域有多年的实战经验，这篇文章将我们的一些实战心得总结下来，以飨读者。
首先，要使研发过程数字化，必须要先将业务过程信息化，也就是得有一套业务管理系统（相应的企业、政府数字化，也是将业务系统先上线）。在业界也有类似的全流程管理系统，大家耳熟能详的 JIRA 就是其一，我们其实当年也是在 JIRA 中开发了自己的小插件来实现研发过程数字化的。
第二，从研发管理的角度来说，如何能让脑力劳动变成可排序、比较的数字呢？这个是一直以来的一个难题。我们都知道管理的核心是制定规则，规则的合理性和有效性会让团队的一些行为规范自动变得更积极正向。
一个好的流程规则，可以让很多事情变得简单，可以先听两个故事：
故事一 和尚分粥
寺庙里僧多粥少，每到开饭时，和尚们一拥而上，本来就少得可怜的粥被挤翻了，大家都挨饿。和尚们推荐了一位长者分粥，可分粥者大权独掌，为能多分点粥，一些和尚开始溜须拍马，加上平时相互关系就有厚薄，分粥者把粥分的多的多，少的少。
饿得受不了的和尚提议轮流分粥。这下可好，轮到自己分时撑个半死，他人分时饿得发昏。
方丈云游回来了，决定由其中一名和尚全权分粥，其他不得有异，但又规定分粥者最后取粥。从此和尚们均等地吃上了热粥。
故事二 巴顿将军与降落伞的故事
士兵跳伞员：这个降落伞的质量可靠吗？兵工厂商人考文垂：当然，要是到时候打不开，我们包退换。
结果，二战时，巴顿将军所在盟军中有一半牺牲者都是跳伞死的。
巴顿将军十分恼火，质问兵工厂商人考文垂，怒斥道：每个降落伞都关系到一个士兵的生命，你就不能做到百分之百合格吗？
兵工厂商人考文垂：我已经尽力了，99.9% 是最高极限，再没有提升的空间了。
巴顿怒不可遏，走进车间，忽然从流水线上随意抓起一只降落伞包，大声地对考文垂说：这是你制造的产品，我现在命令你抱着它上飞机。
考文垂吓得几乎快要尿裤子，想：这个伞包刚刚下线，根本未经过任何检验，万一是次品，自己就将粉身碎骨呀！
可是迫于将军的权威，只能胆战心惊地拿着伞包，上了飞机……还算有运气，考文垂有惊无险地回到地面。
巴顿随即严厉地说：从今天起，我将不定期来这里，命令你背着新做成的降落伞从天上跳下去。
从那以后，巴顿一次都没再去兵工厂，盟军也未再发生跳伞伤亡事故。
这两个故事告诉我们至少三个道理：
① 凡事必须有制度、机制去规范；
② 制度必须不断创新，与时俱进；
③ 好的机制不一定复杂，复杂的机制不一定好。
在我们软件研发的团队协作中也同样是如此，有好的流程规范和正确的规则，会让团队管理变得简单高效，我们在前段时间服务了一家客户，研发团队的交付效率和交付质量总是达不到业务的要求，我们跟对方 CTO 交流的时候，问他们是否有研发流程规范的时候，说有的而且很详细，我们一看之后发现在这个流程中设计了非常多的节点，大大小小加起来可能有二三十个节点，每个节点上的各种情况都有规定该怎么做，我看流程图就头皮发麻。
问：团队兄弟们都能准确理解各个节点的要求吗？
答：研发主管应该都明白，下面的兄弟们不确定，毕竟东西还是比较多的。
如果一个流程规则对于参与者来说是不能清晰理解和执行到位的话，那么就形同虚设了。相信制定规则的人肯定能理解个中奥妙，并且能将规则设计得逻辑通顺和有理有据，但执行者不能做到，也就是规则最终无法有效落地，则跟没有规则的结果是差不多的。
管理者在设计流程规则的时候，要考虑以下几个要求：
1、规则要尽量简单、清晰。只有这样，团队所有人才能执行到位，越简单越容易执行，才能起到规则的效果；
2、执行规则要有监督保障机制。人都是有惰性的，边界不清晰则一定会越界。举个简单的例子：对团队要求早上 9:00 之前上班，不能迟到，如果规则就这么定，那么刚开始大家都会遵守，慢慢的发现都迟到了，因为 9:01 到也没啥问题，毕竟只比要求的晚了几秒钟。所以要有监督，明确 9:01 就算迟到，并且迟到了有相应的惩罚措施。
3、多制定正向引导规则，尽可能少的惩罚规则。损失厌恶机制会让人在受到惩罚的时候很不爽，在一个团队中，对一部分人惩罚和对另一部分奖励的效果其实是一样的，管理者尽可能多地对做的好的人进行奖励，可以避免损失厌恶对团队带来的不良影响。
4、根据规则执行情况进行完善，可以借用 PDCA 的原则，进行流程规则的改进，提升团队效率和质量是永无止尽的。
所以我们团队在多年的实践之后，制定了一系列的规则，充分体现了以下几条管理原则：
1、高效思维——流程性的活动，一次性把事情做对做好，别返工，效率是最高的；
2、闭环思维——任务的完成都有对应的交付物，任务都有关闭节点，并且是由任务发包方进行关闭和确认；
3、协作思维——软件开发是一个高度依赖协作的活动，任何人在组织中，承诺的事情都需要按要求交付；
4、在线思维——软件研发过程中的点点滴滴，都在线记录，包括所有的文档、代码变更等。
通过这些正向的规则引导，可以让整个团队在统一的规则下去做事情，就跟中国人民解放军为什么战斗力那么强，那是因为军队的组织纪律严明，有统一的行动规则，同样我们的研发团队，有统一的规则和行为，战斗力自然会变高。
另外一个观点，我们认为技术团队中的个体能力非常重要，但对于整体组织的效率来说，管理者的组织管理能力更重要，就如同金庸的武侠世界里，武林高手有绝技，但面对朝廷大部队的时候，还是以卵击石，整体组织的效能更多的来自于组织的协同作战能力。
有句话说，一头狮子带一群羊，是一群狮子的战斗力，一只羊带领一群狮子，也是一群羊的战斗力。
再举个例子，商鞅变法前的秦国军队，战斗力其实并不强，商鞅变法后，军队还是那支军队，但通过不同的组织分工后，战斗力已经完全不一样了，面对战国诸雄能做到所向披靡，体现的就是管理组织能力。
第三、通过对这些规则的落地执行，符合规则的同学进行加分，而对违反规则的同学进行扣分，最终就会有一个积分表出来，每个人都会清晰地知道自己的得分，是因为哪些事情做得好或者做得不好，而规则都是提前跟大家沟通到位的，这样团队所有人都能慢慢地统一行为规范了。
举几个规则的例子：
- 工作项指派后超过 8 个小时未接受
- 超过计划完成时间未进行任何处理
- 开始时间在今天之前（包括今天）的任务，状态没有更新
- 项目没能按时提测（每延迟一天）
- 冒烟测试打回（每打回一次）
- 冒烟一次性通过
- 项目结束后，开发责任人名下的 reopen 累计次数超过 3 次（从第 3 次起，每增加 1 次积分 -1）
- Bug 最少的 30% 开发责任人
- ......
通过这些规则的执行落地，进行加减分的方式最终会得到一个相对排名，我们很难去区分 95、96 分有多大的区别，但团队中排名靠前的和排名靠后的相对比，中间的差距就会非常明显，对于团队管理者，也会很清晰地了解到技术人员在日常工作中的一些情况，从而让管理者更轻松地带领技术团队高效地协作、高质量地交付。
