软件研发管理和研发文化培训总结和分享

今天整理和分享下原来做研发管理和研发文化培训方面的内容。在前面已经分享过两篇关于个人知识管理和个人自我管理的文章，今天则是结合人在职场下应该有的一些行为习惯和思维意识。

对于个人管理和自我提升，我始终强调了一个关键点，即：

首先是由被动变化为主动，逐渐养成自我强大的内驱力来推动自己不断进步。其次是从积极主动态度到思维意识提升培养，努力肯干是好事，但是最终需要通过是否提升了自我，体现了价值来衡量，否则所有努力都是原地打转。

每次做类似研发文化培训，听众往往两种，一种始终认为是洗脑或者鸡汤，一种则是认为需要自我复盘并开始改进。两类人实际上代表了两种典型的个人自我成长态度和价值观。但是无论是哪种，我还是要强调，真正能够促使你个人成长的，唯有你自我意识的转变。

为何要构建上面这个研发管理整体框架？

从上图可以看到在研发日常管理和工作中，所有内容仍然是目标驱动的。有了目标才会启动具体的项目，并安排计划，将计划分配给具体的团队或个人。

团队人员执行工作任务并及时反馈形成闭环。而任务的执行本身又分为了效率和态度两个关键方面。对于效率方面又分解为生产率和质量两个关键指标，这两个指标本身的体现也就是项目能够多快好省，高效的执行和完成。

做任何事情，风险管理都必须贯彻始终，而对于项目日常管理，基于敏捷的短周期迭代就是管控风险的核心思路。做任何项目当能够从问题驱动转变到风险驱动的时候，那么项目执行才能够真正掌控在自己手中。

任何项目管理，计划编制和执行，研发过程管控都需要从单纯的项目团队级别提升到组织级别，形成一定的标准规范和流程。到了项目团队单个项目或任务的执行，同样应该形成流程意识，形成做事情的章法或节奏，否则就会导致混乱。

流程和活动

流程是基础的基础，一个人也涉及到流程，即我们说的做事情的方法和步骤。工作中涉及两类流程，以以业务单据申请为主的审批流，其次是输出一个业务价值成果需要内部多岗位角色协同运作而完成的业务流。

流程有输入，中间经过一系列相互协同的活动或步骤，最终产生一个有价值的输出。

流程活动最基本的还是我在哪个时间点，需要根据什么输入，利用什么工具，输出什么内容。即常说的流程核心5要素，包括了流程输入（输入准则），流程输出（输出准则），执行岗位或角色。

为何如此强调流程？

在日常工作中经常会发现有些员工入职都1年了，还没搞清楚自己当前岗位的工作职责和工作内容，不清楚自己内部的上游是谁，自己应该接收什么样的输入，同时自己工作完成后应该输出什么样的结果，应该达到什么样的质量指标。

一说到这点很多人觉得委屈，认为是公司本身流程不规范，或者指定的流程没有严格的去执行。但是很少去思考自己的工作和输出，是否严格按照流程在做？是否符合输出质量要求。

对自己的产出物负责，不仅仅是面对外部客户，同样包括面对内部下游岗位或团队。

为何很多人反流程？

很多人反流程，本质还是不希望受到太多的管理和约束，但是流程往往是形成自我做事方法论的基础，在流程执行顺畅后你可以考虑对流程进行简化，但是绝对不是一开始就否定流程和规范。

过程和目标

过程很多时候和流程是一个意思，英文里面可能也存在flow和process的区别。如果一个流程是全自动的，那一定不会纳入到过程范畴。过程更加强调的是流程+人+方法工具技术三者的整合。

过程可以看做是个体需要采用什么方法工具，在什么场景下来更好的执行流程。因此过程更多是一种适合企业或组织的经过初步验证的方法论结合。

在CMMI里面谈的最多的就是过程，其过程的核心思想仍然是上面三者，包括各个过程域的展开描述重点也在这几点上面。

目标，即符合常说的SMART原则的一个成果和产出。目标管理本身也是项目管理的基础，但是过程资产库同样重要，因此目标管理+过程资产+过程相关外围扩展构成完整的项目管理知识域。

有好的过程不一定达到目标，因为过程不能代替行为主体人的思维，人的技能和效率，人解决问题的能力。好的过程可以养成好的习惯，可以促进个体的学习，但是关键还是个人。同样，好的目标并不一定代表遵循了好的过程，结果导向重要，但是不是全部。

过程的意义始终在于积累复杂问题解决应该遵循的方法论。可以看到，在小型项目和任务上完全凭自己的经验没有问题，但是到了大型复杂工作任务的时候，会发现没有前期良好的过程和方法积累，原有纯粹的经验很难达成目标。

项目和项目管理

确定了目标后一般涉及到项目管理，一个人也可以是完整的项目管理，如GTD相关方法。

项目本身的定义包括不可复制，临时性努力，有价值的产品或成果的输出，这些都是和目标和目标管理相同的。因此目标管理是项目管理的基础，但是项目管理仍然注重过程，希望项目管理的方法和经验能够沉淀到项目管理过程资产库里面。

项目管理一般会更加针对团队或组织，有特定的需求和目标，也有明确的时限性和输出要求。从这个层面来看可以看到项目管理核心是将输入分解为具体的任务或活动，组织和排序这些活动，同时整合各种资源来协同和完成这些活动或任务，最终形成满足需求的有价值输出。

特别是研发类项目管理可以看到，人是核心资源，项目管理本身的难点就会转变到团队人力资源的分配，协同和整合上面。

计划和任务

项目管理里面最重要的一个就是做项目计划，而项目计划核心输入是项目目标要求，项目范围，当前已有的资源。你在综合分析和需要给出一个完成项目目标的可执行路径。

简单来说做计划核心就是分解，排序，任务分配，执行，反馈几个关键动作。

当接收到任何一个项目首先就是WBS分解，要明确你最终要交付哪些输出和内容，同时基于这些内容来进一步分解具体有哪些工作要开展。

如果对应到Scrum敏捷项目管理的思路，那么分解的两个层次可以理解为，先将项目需求或用户需求分解到最细粒度的User Story故事，第二次进一步将用户故事分解为具体的工作任务。

排序不是简单的需求优先级，同样包括了任务依赖关系的梳理。

在排序完成后需要进行任务的分配，任务分配实际上是最难的点。简单来说就是在项目团队当前现有人力资源和技能约束的情况下，你如何通过工作的分解，任务的排序等来实现最佳的资源利用，最短的项目周期，这个不是简单的计算下关键路径，而是需要项目经理或负责人能够明确的理解需求，同时又能够完全熟悉项目团队人员的技能，才能完成这个匹配。

可重复和可定义

对应可重复和可定义是CMMI里面经常会用到的两个概念，可重复对应到二级，而可定义对应到三级。简单来说可以这样理解两者的关系：

可定义 = 可重复 + 组织级 +基线

一个公司有多个开发团队，一个开发团队用的微服务架构开发，一个用的传统的SSH架构开发，当前即使同样用SSH架构开发，采用的数据访问访问，前端开发技术都还存在不同。

对单独一个开发团队来说，相关的方法和实践是可重复的。

但是这个方法并不一定在整个组织级可以重复使用，同时对于整个组织来说也没有方法去衡量当前组织级的开发效率，开发质量水平究竟如何。正是这个原因需要制定一个组织级的标准或过程规范，将项目团队好的东西提升到组织过程资产可复用。

提升到组织级，对单个团队肯定是受到更大约束，不是说你想选择什么框架，采用什么技术就随意选择，而是受到组织过程和技术标准规范约束。但是这样对组织来说是好事，简单来说在整个组织层面，资源的可复用度，技术平台和框架的可复用度都大幅度增加。

任务和迭代

在前面已经谈到在做项目计划的时候，将需求进行WBS分解，同时将WBS分解后的工作项再分解为具体的项目任务。一个需求工作项是明确的客户可验证的内容，而任务涉及到具体的开发方法和模式，比如在前后端分离的开发下，分解如下：

//报账单提交增加预算管控(需求点）     1.需求编写和细化-需求人员（task)     2.后端功能开发-开发人员01（task）     3.前端功能开发-开发人员02（task）     4.功能测试和验证-测试人员(task)

分解完成的需求点必须满足用户能够独立验证，在满足该要求的情况下，所有的需求故事点就可以基于优先级安排迭代计划和版本。

每个迭代版本都是可以独立向用户交付的版本。

增量是堆砌，容易一叶障目，不见泰山

迭代是精雕细琢的过程，通过快速可见来降低风险

压力区和舒适区

当你对工作感到紧张,恐惧或底气不足的时候说明你压力太大了，而压力太大往往是由于我们知识技能的缺乏，我们原来的积累很难支持我们去做更有挑战性的工作。当你始终在做重要紧急的事情时候会始终感受到压力，当你能高瞻远瞩做重要而不紧急的事情时候,你走在了压力的前面。

当存在太多的不确定性因素或未知事件的时候,你对目标的掌控力不断减弱,你受到的压力呈现指数级的增长。出现压力首先应该考虑的是时间管理和工作效率的提高而不是单纯通过加班来解决，我们需要不断的补充自己的知识,熟练运用各种辅助工具,提高技能水平,形成适合自己的分析解决问题的方法论。

在项目任务安排的时候同样需要考虑压力区和舒适区平衡。

如果所有的工作任务都安排在员工的舒适区，比如本身员工3天能够完成的工作你反而安排1周时间，那么带来两个典型问题就是项目周期变长，同时员工本身也难以成长。当任务在员工舒适区的时候，实际个人是很难去思考如何提升自己的开发效率，解决问题效率的。

风险和问题

没有风险的项目就一定会成功，因此项目风险管理贯彻项目完整生命周期。

风险管理的最难点在于风险意识和关键风险的识别，关键风险识别能力本身又在于项目经理的实践经验积累。一个优先的项目经理一定是风险驱动性，具备敏锐的嗅觉提前化解各种未知和不确定性，而不是被动的解决问题。

研发项目中一个常说的比较大的风险即需求变化频繁和不稳定，而迭代思路则是化解这类风险的关键思想。前面很多文章谈到敏捷，我一直强调的也是敏捷重点在于短周期迭代和自适应能力提升，都是在为了提前发现问题或应对风险。

对于风险管理工作来说，风险定义和分析流程是其次的，最重要的仍然是能否识别出项目关键风险并制定相应的缓解措施。这个才是真正体现项目经理的经验和整体把控力。

对于软件项目范围的衡量应该是规模而不是工作量。

简单来说一个小系统的开发一共包括了100个功能点。当前有两个开发人员，张三的效率是10个功能点/天，李四的效率是5个功能点/天。

那么这项工作张三做工作量是10人天，而李四做工作量是20人天。如果对应到个人的工资水平，如果李四是10K，那么张三应该是20K。

当能够以规模去衡量一个软件需求的时候，才能够更加客观的反映个人本身的价值贡献。这本身实际和经常谈到的价值工程的思路一致。

生产率和质量

对于范围或WBS分解的最终活动，都是要以任务的方式安排到具体的人员来完成。项目是否可控其实经过转化后会变化为分解后的关键任务是否可控。这个可控性体现在团队成员的效率和态度。

效率本身包括了生产率和质量，任何一个岗位角色的工作绩效往往都可以通过生产率和质量两个层面来度量，而不是应该通过人员的工作负荷来度量。

而要提升效率本身又涉及到两个方面的内容：

一个是个人的责任心和态度问题，一个是个人本身的思维意识和思考力。

减少返工，减少个人工序上缺陷泄漏就是最基本的质量意识。

要做一件事情可能很容易，但是要真正做好一件事情就很难，需要的是投入更多的时间和精力，这个我们可以举出很多的例子来说明。

1. 考试得60分及格很容易，考100分很难。得60分花1周得时间，考100分可能花1年的努力。 2. 你考98分，别人考100分，并不是对方只比你高了2分，而是这个试卷本身只有100分。 3. 懂一个道理可能不到1分钟，但是真正要亲身去证悟往往需要毕生的投入。

团队和沟通

这点可以看到互联网很多公司是做的相当好的，即开放，包容的团队文化的建设。任何一件工作或任务，只有团队成员能够从内心想去做好，真正有兴趣做好，真正在做完后能够体会到成就感的时候，才可能促进一个积极主动的高效团队。

即首先还是长期的企业文化积累起到了作用，这种文化促进了团队中个体的能力和态度，都是正能量的个体本身的高效协同又促进了整体团队运作绩效的提升。

没有高效和负责的个体，就不会有高效的团队，因此即使在团队协同中首先还是强调的个体当责，每个人首先得做好自己岗位角色下的工作，其次才是更好的配合他人协同上下游工作。原有的文化积累越弱，这种个体责任感也就越弱。当你期望通过各种严格奖惩机制去解决的时候，往往又会走到另外一个极端。

思维和意识

对于思维和意识，再展开谈下里面的一些关键点。

学习意识，这个在过去的文章里面谈得最多，强调的重点是兴趣驱动的主动式学习。但是我们要看到碎片和点滴知识的学习可以是零散的时间随时吸收和完成，而完整的总结和经验提取往往才是需要大块时间和系统化的进行。

任何找理由说没时间学习都是本身惰性而已，包括你平时工作实践和他人沟通时刻都是在进行学习和信息采集。那为何有的人学习了吸收了，有的人本身没任何知识学习上的进展，这个在学习意识上的差异就体现在很多事情都是单纯的工作任务驱动，目的是单纯完成工作，而不是本身兴趣和长远个人发展目标驱动，目的是完善自我知识结构。在做任何事情上都能够突破传统工作任务本身边界，留意申报的事和物，相关资料和知识的外延，凡事都能够深入和朝前走一步，才可能获取和吸收到足够的知识量，这些知识积累在当前工作中可能不会用到，但是往往在后续的工作实践中会发挥巨大的作用。

举个例子来说，如果你本身是一个绘画爱好者，接到一个工作任务是要到一个知名的画展去取一副画，从单纯的任务完成来说取到画交付即可，而实际如果真有自身兴趣驱动，往往一定会停驻在展厅学习和欣赏其他各个大师的画作。如果本身工作任务有时限要求，你也可能第二天或周末再单纯去参观这个画展。

而实际工作和实践中可以看到大部分是第一类人，有只有少量是第二类或第三类人。这就是学习意识上的差异，这个差异本质还是兴趣驱动，个人长远规划驱动的，这个意识难以落地，原因还是在于学习成本投入是当下，但是价值兑现是远期或未知。这种学习不是被动的而是主动的，没有任务，没有指标，没有短期利益，没有绩效考核，全靠自我驱动。少去抱怨没有培训，没有学习氛围，没有环境，只要自己多留意，想去学，在当下信息如此发展情况下就不可能没有途径。

一个人如果这个意识没有，兴趣没有，去沟通再多的学习方法和工具都是徒劳的。

风险意识，对于风险也是我谈的比较多的一个话题，任何事情或项目的执行，如果没有风险那就一定会取得成功，一个项目的执行过程往往就是一个风险识别，分析和解决的过程。但是今天谈风险却要转谈责任和纪律，因为很多时候不是没有风险意识的问题，而是没有责任和纪律感的问题。

举个例子来说，我出门的时候看到天气阴沉，我意识到可能会下雨，风险应对措施是需要回去带雨伞，但是很多时候我并没有返回去，原因不是没有意识到要下雨的风险，而是即使下雨了也无所谓，我能够承受这个风险转问题的损失。

再举个例子

你去参加一个同学聚会可能会迟到，但是你要去拜访一个关键大项目的领导你会迟到吗？两件事情我们都会意识到交通堵塞可能导致的迟到风险，但是我们会选择性的应对。

所以很多时候不是风险无法识别问题，而是责任感和纪律问题，有可能公司并没有严格的惩罚措施情况下，自己能否保存高标准自我要求和严格一致的行为准则。我们很多人往往就是小的事情上不做好，老是出问题，本质还是自我不足够重视，所有的小事都做不好，到了真正有大项目或大事情的时候，你会发现自己想做好也力不从心了，到了这个时候往往才是已经真正无能力识别风险了。

做事情，我们是经常按100分高标准要求去做而保持都能在90分以上的水准，还是说按着60分要求，而经常出现不及格情况，这就是一个重要的意识问题，一个专业态度和严谨性的问题。

认责-岗位意识和服务意识，在意识里面谈这个内容可能会觉得比较奇怪，因为其不仅仅是意识，也包括了做人和做事的态度，个人性能和习惯的改变等。今天谈这个意识就是在工作和实践过程中，需要考虑让你的下游团队成员，让你的客户感觉足够的舒服。是站在客户或下游的角度再考虑如何把事情做好，如何更好的交付，而不是自我立场来考虑和判断问题。

你能想到的我都帮你想到了，你没有想到的我也帮你想到了，会给出了建议，如果都是这个方式做事情不可能让对方不满意。自己可能天天在那抱怨接受到的输入质量差，导致自己花了数倍的时间完成后续事务，但是却从来不会意识到自己输出给下游和客户的成果同样差，然后还可以心安理得的归咎到上上游的责任，如果每个人都是这种做事情方法事情不可能做的好。

举个例子来说，一个客户请我去出差去做一次培训，前面经过一次沟通后发现，包括机票的预定，酒店的安排，机场的接送，培训教室和设施的准备都提前安排的妥妥当当。

你会发现到了你这环节的工作开展十分顺畅，中间并不需要太多的频繁的沟通，你能够想到的别人都已经安排好了，因为对方是站在我的角度去想问题不断提升服务水平。还是说我们经常遇到情况没安排，一问到对方的回复往往是我以为你自己会做或想到，把自己做的不到位寄托到对方身上。如果我们在工作和实践中都能够这样换位思考和交付成果，对方想不满意都难。

天下难事必作于易，天下大事必作于细。所有细节和小事多做到位，多留意多观察，凡事都深入和扩展一点，不断持续的随时随地的实时积累，定期的总结和系统化，才逐步能具备做大事情的能力，具备自我终生受益的专业和严谨的态度。