一个工程师在企业中对流程管理的思考.docxVIP

PAGE 1 PAGE 1 一个工程师在企业中对流程管理的思考  流程管理在生产上已被奉行多年，但围绕它的争议仍不停留。  我平常很少写博客，我是个技术人员，一般来说技术人员的博客应当以技术为主，但同时我又是一个懒人，对于技术我喜欢“亲身体验”而不喜欢“写出来”，因为我觉得把技术对别人说清晰要比实现它更困难。实际上这段时间我都在看别人的博客，所以一直以来我只是个吃白食的。  为什么现在我要跨界谈一个偏重管理类的话题呢？因为过去经历的一些事促使我对项目的流程管理进行一些思索，并形成了自己的一套看法和规律，而我也很情愿将我的看法发表成文，不喜欢憋在脑海里太久。至于能得到多少认同倒是并不在意，我觉得一个人观念的形成源于他对事物本质的理解和认知，而这种理解和认知又同他过去的经历有关。在此通报一下我过去的工作经历，本人电气专业出身，在一家台资IC企业做过三年软件工程师，无任何工程管理上的学位和经验，所以题目定为“一个工程师的思索”以避免把话说太满。但我不认为一个话题出自一个非专业人士之口就得贴上“瞎BB”的标签，作为工程师的我好歹也是大工业时代整条生产链上的一颗“螺丝钉”，虽然项目流程不是我设计的，但身为一颗“螺丝钉”也有反馈一下的权利吧。何况我也不想洋洋万言写成精品，权当一家之言耳。  流程管理在生产上已被奉行多年，但围绕它的争议仍不停留。有些人喜欢它，认为流程提升了生产效率，有利于培育企业文化；有些人排斥它，认为它束手束脚，僵化死板。前者大多出自管理层，后者大多出自工程师，他们都是站在自己的立场看问题的，能不能统一起来看呢？我们究竟需不需要流程？或者多大程度上接受它？在阐述我的规律之前，先从我对流程的认知说起。  流程的本质是什么？我的理解是流程是一种介入机制和托管机制。“介入”是指生产环节上多大程度让外部势力参与和干预，主要表现为人员分工；“托管”是指存在一种自动化工具帮你简化一些步骤，表现为对工具的使用。它们的区分相当于载人飞船和无人飞船。当我们说“这个项目应当走个流程”实际上等价于“要让外部人员参与进来”以及“你该试试这个工具”这些同义语。  让我们以开源项目Linux为例深入解释一下。在上世纪90年月初出现了Linux内核，是由芬兰21岁的大学生LinusTorvalds开发的，他先是写了一个多任务的终端仿真程序来连接modem，又写了一个磁盘驱动程序访问硬盘，再写了一个文件系统管理资源，后来又移植了bash和gcc，一个操作系统雏形就这样建立起来。在这个阶段都是Linus一个人DIY，并没有他人介入，顶多也就通过邮件同少量用户交流一些需求。而且当时工具也不太发达，他甚至不得不手动修改gcc源代码以实现内核自编译。不管怎么样，个人项目还是发布了。后来开始有人协助加入图形、网络各种服务和模块，再后来就演变成一项声势浩大的开源运动，连商业公司都参与进来开发各种发行版。这是Linus意识到自己必需放手，因为随着用户需求的增多，代码量膨胀，版本发布周期也在缩短，这也是为何Linus又创造了版本掌握软件git；社区发展壮大导致成千上万开发者参与其中，不仅仅贡献代码，测试、写文档、打包、做网页、翻译、技术支持、售前售后……把整条生产线纳进来了。这么多人，这么多活，没有分工，没有秩序明显是行不通的，于是就像商业公司一样，开源项目也要建立一套好流程，以便外部人员顺当平滑地介入。  上面提到的“介入”和“托管”两种机制，前者是参与分工，后者是工具使用，现在大多数开发者和管理层对工具使用都有某种共识，而且事实上实施许多年了。真正的分歧在于“介入”，这也是流程管理中最大的争议，因为工具是可以替换的，而一旦“介入”是不可逆转的，因为一旦介入，你很难把别人清退出去。何时介入，介入程度多深都会成为争议焦点。一个工程师在项目早期的构思建模阶段一般是不欢迎他人参与进来的，许多人说这会干扰他们的思路，顶多开放一些有限的口头交流，但想要往我的代码中提交pullrequest（以下简称PR），没门！这种情形不禁让人联想到家里养的母猫在小猫尚未睁眼之前不允许任何人触碰，就算自家主人也不行，不然就摆出一副凶巴巴要跟你舍命的架势（狗妈妈可能无所谓，这也是为何有的程序员性格更像猫而不是狗一样易于管教）。母猫的想法可能是这样的：1.这是我亲生的，凭什么让你碰？2.抚养的细节只有我最懂，兽医也不行。这同一些主观意识剧烈的工程师心理如出一辙，这也解释了他们同别的工程师甚至管理层在流程问题上发生争吵，说白了就是不想被介入。但随着小猫的成长，母猫终究还是会允许主人帮忙照料养育自己的孩子，以分担一些麻烦，犹如工程师最终还是会与团队一同坐下来商谈软件打包发布等各种琐事，以及放开并回应来自社区提交的PR。