小公司刚开始起步时，做产品的仅几个人，此时是不需要任何管理的，很多事情大家碰个头商量一下即可。但是，随着公司持续发展壮大，产品越来越多，领导和技术骨干都会陷入低级繁琐的事务活动中。经常导致一种现象：企业貌似越来越大，大家越来越忙，但产品却越来越差，研发时间也越来越不可控。
出现这类问题时，大家习惯性开始引入各种管理体系，最常见的就是各种流程管理软件了。我们在引入这类管理流程时，经常会抱有不切实际的幻想，如：可自动监督员工的所有工作、可自动记录每件事的工作量，自动提醒每个人下一步做什么等。很不幸，如果这类软件是用于仓库管理或超市收银等场合时都非常高效，但如用于软件研发管理时就会差强人意。
造成这类管理困惑的底层原因是什么呢？记得美国某一位教育专家曾经说过一段话，大意如此：“我们应该教育我们的公民，让他们刚好聪明到能操作自动化系统，又刚好笨到能无奈接受所有那些较差的工作”。简单来说，要想让这类自动化流程系统顺利运行，就要求依附于该系统上的员工是傻瓜式员工。
软件研发，是高智商纯脑力活动，软件工程师大多也是经过多年训练的知识分子，内心的躁动、人性的欲望，会导致人员和系统之间经常发生冲突。最典型的表现就是大家乐于钻流程的空子，尤其是各类KPI考核机制的漏洞，这会让团队成员过于急功近利，没人考虑企业长期利益，最终导致公司内部斗争多过协作。
公司做到一定程度后，没有管理肯定不行，传统的流程管理也不行，管理之殇，好像是个人和企业成长过程的必经之路，有没有更好的策略呢？
全面质量管理体系（TQM）中花很大篇幅来抨击各种KPI考核，强调个人的领导力。接触TQM后，我感觉自己好似发现了另外一条路径，找到了一条适合小团队的、低成本的、团队成员具备主动性的软件研发管理体系。
认为这套管理体系的最主要特点是尊重人性。软件研发工程师大多具备强烈的渴望向上的成长欲望，由这种底层人性的内生性需求驱动的管理制度，可能从专业管理人员的角度理解比较low，但实施过程中阻力较小，效果明显。
需要额外强调，全面质量管理体系（TQM）更多的是一套方法论，有点类似于道。需要结合真实的产品特点，考虑团队成员能力等多种约束条件后，才能构建出可行的策略，这些策略已经类似于术了。本节我们会描述一些我们团队喜欢用的策略，但因为各种约束条件不同，大家只能意会，很难照搬。
◇◇◇
文档体系是软件研发过程中很让人困惑的一项工作。很多公司产品的提交物仅仅是一堆代码，如果碰上关键员工离职，后人很难接手，这会给企业造成很大损失，甚至导致相关产品线被割裂。
大家能自然意识到这种状态不对，因此在一些工作不忙的间隙，领导会要求大家补文档。很遗憾，这种为了应付领导要求而临时撰写的文档，大多数情况下没有太大价值，如出现文档和代码不相符的情况，甚至还有负作用。一番辛苦，浪费了大量人力物力，最终化作一堆无用功。
如何来破解文档困局呢？
全面质量管理体系中讲究以人为本，文档由人产生，就应该为人服务。基于这样的理念，我们团队达成一条基本共识：仅写有用的文档，写好有用的文档。基于这样的设计理念，我们团队构建的研发支撑文档体系结构如下图所示（注：立项、用户调研、需求汇总、验收等相关文档属于公司上一级流程性文档，本节的文档体系仅指研发工作支撑性文档）：
架构设计文档，前面已多次阐述，不仅用于指导产品架构设计，额外一个很重要的使命是协助团队内部交流并达成共识。有新人加盟时，也需要先了解架构设计文档，才能开始具体的工作。为了达成这些目标，架构设计文档多以图形为主，辅以必要的文字说明。
在我们的规划中，并不存在具体的详细设计文档。详细设计文档侧重于描述各软件模块，有些模块比较简单，仅仅是架构设计中的一段描述；有些模块接口抽象比较复杂，如果能有一段文字来描述其设计思想会更佳；有些模块适合采用状态机编程，此时它的详细设计文档就是一幅状态图。
多年的实践磨合，我们团队喜欢代码及文档的策略。将详细设计文档和代码整合在一起，首先是便于审核，审核代码时如能先理解其设计思想，审核效率也能高很多。更进一步，借助审核机制，也有助于保持文档和代码同步。
分布式架构中，需要基于can网构建通信链路，此时最适合使用状态机了。下述代码就是can网通信链路状态机。经过长期训练，大家已经熟悉这种基于文字的状态图了，如果有多条状态路径，我们会习惯用不同的注释行去描述。
/* 主CPU和各扩展CPU连接状态机 */
#define LINK_STATE_IDLE 0 /* 初态。成功发出连接命令后进入LINK状态 */
#define LINK_STATE_LINK 1 /* 连接态
* 接收到板类型进入状态TIME,发送对时命令,并设置连接正常;
* 超时后重发连接命令,并设置连接异常
*/
#define LINK_STATE_TIME 2 /* 对时态。超时后发送对时命令,进入RX态 */
#define LINK_STATE_RX 3 /* 接收态
* 接收任何帧时返回TIME状态;
* 超时后返回LINK状态,发送连接命令,并设置连接异常
*/
代码审核checklist是一份持续迭代的团队性文档，其主要用途是指导代码审核过程。代码审核checkList文档是团队内部最宝贵的一份财富，但重要并不等于紧急。平时大家陷在具体的工作中，没有人会主动去构建该文档的，需要适当辅以一些制度去保证。如审核员如果碰到共性问题，就需要考虑是否要补充checkList；如某个bug解决后，也需要去同步考虑是否补充checklist，……，实际工作中，需要明确哪些职位或工作有维护checklist的职责。
在构建checklist时，我们习惯在给每条记录增加撰写人。checkList是团队财富，我们经常将checklist作为新人培训和考核依据，不仅有助于团队步调一致，更有助于在团队内部培养领导力，是一种团队荣誉。很多人非常享受这种荣誉，因此会积极参与到checklist维护中，也有助于诞生优秀的审核员。
额外需要补充一点，checklist文档切忌简单的拿来主义。一些公司刚开始感觉自己的checklist数量少，有点寒酸，就快速的拷贝进来一大堆，最终反而让checklist变的不可用。少就是多，慢就是快，基于自己公司、团队和产品的特点去持续构建，一条一条筛选补充，保持可用性，切忌形式化。
◇◇◇
工业产品嵌入式软件类研发工作，“人”的因素永远是第一位的，如何打造一个积极的人才梯队，可能是团队负责人的首要任务。
为了构建人才梯队，我们需要培训，但道理很简单，现实很尴尬。很多公司，也就是在员工刚入职的时候有一些集中的入职培训，讲解公司基本制度后就处于放养状态，大家能走多远，更多的依赖于个人努力和运气了。
我个人一直不太喜欢那种集中的培训模式，记得我的入职培训，就是一个老师换一个老师的讲解，听的我昏昏欲睡。后续产品研发过程中本应该有更多的培训，但又经常缺失。
培训难于实施，与此同时，职场也有很多工作大家都不乐意做。还记得我以前讨论过的两个环吗？
现实工作中，大家都比较喜欢编写代码的工作，但不喜欢代码审核和集成测试工作。如果没有统一的代码规范要求，读别人的代码是一件很痛苦的事情，甚至不如自己重写一遍。同理，如果没有统一的架构和接口思考，集成测试也很难实施。
不知大家能否意识到，实际上代码审核是比编码更高级的工作。代码审核之前，不仅应该已经思考过程序的大致结构，而且需要兼顾产品、团队等多个角度，甚至需要学会包容其他员工，更重要的是，审核就是最好的培训策略。
我刚开始有一种误解，认为测试工作比较低级，是一种“傻傻”的工作。实际上，集成测试也是一种更高级的工作，不仅需要思考模块内部的实现是否合理，测试各模块是否配合，更经常需要基于产品的角度思考。同审核类似，集成测试也是一种针对模块程序员的培训策略。
与此类似，工程现场问题分解、同步互斥等工作也都需要具备一定的能力后才能应对。排除大家的误解，对产品研发过程中的这些工作进行重新定义，不仅避免一些工作没人做的尴尬，更有助于自动筛选出人才梯队。
普通员工中能力强、态度认真、在团队内部有一定领导力的员工会自然成长为支撑性员工，成长为审核员，此时他的工作任务会升华为：审核普通员工代码，在普通员工碰到困难或发现异常时协助，有人员请假或离岗时快速临时替代，承担一定难度模块的编码，产品级别集成测试等工作。
随着这种人员筛选制度的持续迭代，审核员中会诞生产品经理，产品经理中会诞生产品线负责人，产品线负责人中会自然诞生出架构师。这种自然成长的架构师，一般都具备较强的领导力和协调力，远比领导指派的要强的多。
你想赚更多的钱，具备更高的职位，必须具备培养上一层人员的能力，成长为更高级别的支撑性员工，这种人才结构呈层层支撑的梯队组织模式，只要划分好工作，在人性的驱动下，一个自我迭代的优秀团队就自然构建出来了。
额外补充一点，支撑性员工工作时，经常采用人盯人的现场就地策略。有两种人盯人策略，一种是自己做工作，让新人在旁盯着观看学习，另一种是新人做工作，自己在旁观看。这种策略效率蛮高的，可以快速发现新人存在的问题，比仅审核最终成果物高效的多。
◇◇◇
文档体系、团队建设，这类工作都是传统研发工作中的老大难问题。现在，借助全面质量管理体系（TQM），靠积极上进的人性驱动，我们将这些工作拆解融入到日常的具体事务中，执行起来反而有一种顺水推舟的感觉。
以这种理念去重构整个研发流程，最终会形成一个好似没有管理的高效管理体系。
——————————————
我是小马儿，一个渴望良知与灵魂的嵌入式软件工程师，欢迎您的陪伴与同行，如需最新版PDF电子书，或期望深入交流，可加我个人微信nzn_xiaomaer，需备注“异维”二字。
8397
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
