一个有趣的企业的对比案例
序言
在这个案例中，我们姑且称主角为小王，因为这样的称呼在一个语气助词“吧”的推波助澜下会显得特别有趣。小王从2010年毕业到现在，一共经历了两家公司，姑且称之为A,B两个公司吧。在A公司待了两个合同期，也就是6年，在B公司待了两年。先简单介绍一下两家公司的背景，A公司是一名海归创建的中日合资的公司，主要的客户都是日企，工作方式也是日本式的。B公司在上世纪曾经是一个政府事业单位，后来分离成一家专注于政务系统的公司。虽然已经新三板上市，但是仍有着大量的中国特色的管理实操。
在B公司的遭遇
来到B公司的第一天，小王就被高效的聘用流程所震惊，从面试，面谈，发offer到入职一共只打了两个电话。虽然和相关负责人曾经共事，但是这个效率也太高了点儿。一切还算正常，但是经历了几个项目之后，小王发现B公司的以下几个问题尤其凸显。
- 项目管理的等级不高
- 人才的成长计划为0
- 甩锅成性，国企遗风
项目管理的等级不高
B公司的自我认定的开发标准是CMMI3,即
在这个水平上，企业不仅能够对项目的实施有一整套的管理措施，并保障项目的完成；
而且，企业能够根据自身的特殊情况以及自己的标准流程，将这套管理体系与流程予以制度化，
这样企业不仅能够在同类的项目上得到成功的实施，在不同类的项目上一样能够得到成功的实施。
科学的管理成为企业的一种文化，企业的组织财富。
但是在小王的观察里，CMMI3要求的管理措施和实际工作中的完全搭配不上。在项目的最终交付清单上，虽然有【概要设计】和【详细设计】，但是这些文档基本都是在最终交付日期之前统一赶工完成。也就是说，指导程序员进行编码的文档在开始编码的时候根本都没有做。那么，程序员是根据什么来进行编码的呢？大多都是项目经理对于需求进行口述。虽然，项目也存在一个类似“需求说明书”之类的文档，但是这个文档的实用性也比较差。大量的需求还是依赖项目经理口述完成。
口述需求这件事带来的风险就非常大了，主要集中在以下几点：
- 需求的可追索性
- 对于需求理解的歧义
- 编码缺乏整体考量
于是，在小王的工作经验中经常出现下列的场景：
- 程序员在对应需求的时候经常遗漏。
- 项目经理忘记了自己曾经提过的需求。
- 因为双方都是通过口头的形式进行沟通，导致没有反馈，缺乏检查。表现为：
- 程序员和项目经理沟通的时候，大量的使用“这个”，“那个”类似的代词。
- 项目经理发现程序员的修改不是他想要的结果，并埋怨程序员没理解对。
- 程序员发现项目经理自己理解错了客户需求，反倒赖自己没理解对。
- 在开会的时候，“还有一个事儿”，“还有一个问题”经常出现。缺乏整体性。
- 在修改其他人的代码的时候出现莫名其妙的代码，不理解。
- 业务和业务之间会出现逻辑冲突，在编码时期没有发现。
- 最终交付时，发现还有客户的某些需求没对应。但是时间已耗尽。
- 测试团队在进行测试的时候不知道什么状态是对的。
- 代码在向维护团队进行交付的时候，没有办法进行整体性的说明。
- 项目经理不做检查和品质管理，然后在功能上线的时候拉着程序员到客户现场驻点。
除此之外，小王在维护组的一段时间内，还发现了下列状况：
- 开发组提交的代码无法完成编译。
- 开发组的代码出现“回退”的情况，即曾经出现的且已经修改完的BUG还会出现。
- 开发组找不到当前版本的代码，需要维护组去真实环境里反编译。
- 线上版本的LIB库中出现冗余的，谁也不知道干什么用的jar.
- 开发组在提交成果物的时候，忘记了告知维护组有数据库变动，配置文件变动等等。
- 开发组的相关人员离职后，谁也搞不清楚业务逻辑。连项目经理都说“忘记了”“记不清了”。
小王回想了一下A公司在早期创业时也遇到了类似的问题，但是最终经历了几轮博弈之后，形成了下列的各方都能接受的方式。
- DEMO优先于设计书，客户确认DEMO无误后，利用DEMO指导开发。
- 搭建了一套redmine，用途有以下几点：
- 所有的需求的变动都记入redmine,通过redmine来跟踪这个需求是否反映到了demo里，设计书里，代码里和测试用例里
- 所有的内部BUG都记入redmine的内部bug分类里面
- 所有的外部BUG都记入redmine的本番障碍里面，并要求进行5W分析
- 所有临时工作内容都记入redmine,便于跟踪检索
- 搭建了一套SVN来替换掉VSS进行的代码管理。因为SVN可以进行文件的非排他式的操作。
- 所有的成果物都上传SVN，尤其是版本变化。代码在实战中的管理更多强调SVN的TAG以及分支管理。
- 测试中使用数值分析，强制对BUG进行分析，用以反馈给开发团队。
- 要求代码REVIEW，并要达到一定的review值。
- 使用代码静态检查工具，对代码的风格和一些简易错误进行静态分析。
- 要求PL级对成果物进行全局检查。
- 要求项目经理对测试结果经行抽查。
- 推荐：使用【塗りつぶし】的方式进行文档的review.
人才的成长计划为零
小王在B公司的第二点体会就是没有得到一个公司层面的人才成长计划，虽然B公司在全员邮件内对于软件类的国考给予一定的奖励，但是也只是简单的提及。并没有形成一个哪怕是简易的成长体系。同时对于项目经理的定位比较靠近下游。一般而言，项目经理的职责为整个团队对外的总入口和总出口。但是在B公司中大量的项目经理要么自己撸胳膊挽袖子写代码，要么就一边打着手机游戏一边简单跟程序员“口述需求”。
公司层面对于项目经理的入口很松，同时并没有提供一个非常好的管理技能的指导和培训。有一次HR找到了小王，因为小王在之前的公司参与了一些企业新进员工的培训工作，所以HR希望小王为本公司今年的新员工提供一次入职培训。小王非常开心，准备了相关的PPT，同时去找HR咨询了一下公司对于人才的成长计划，HR摇头表示并不知道有这么个东西。
小王心里凉了半截。
这种成长体系和管理技能指导的缺乏，直接导致了下列的几个问题：
- 新入职的员工不太了解自己的定位和未来方向。大概率在一个合同期左右选择离开。
- 因为成长体系的缺乏导致年底考核的KPI的缺乏。使得员工的成长出现停滞。
- 项目经理的定位不准确，导致项目经理天真地认为自己是管理者，所以“不用干活了”，“我又不懂技术，我哪儿知道”这种思想泛滥。
- 项目经理的入口过于宽松，导致很多正值黄金成长期的员工，出现了懒惰的思想。
- 由于人才的成长计划达不到一个梯度式的，导致现在大量的工作十年的项目经理直接指导应届生开发。企业人才储备匮乏。
- 缺乏管理技能的指导使得项目在展开的过程中，非常混乱。大概率鸡飞狗跳，而且最终做偏了。
- 缺乏管理技能的指导使得项目经理在客户处表现为“毛毛草草”，“办事不靠谱”。
- 缺乏管理技能的指导使得项目经理的驾驭力极差，最多指导3人团队，当人员达到5-10人时，团队立即崩溃。
在2017年的时候，B公司的管理层好像意识到了这个问题，于是安排了一次公司骨干的管理培训之旅。
当看到在该培训过程中的管理层穿着八路军军装齐声喊口号的照片时，
小王的心里彻底凉了。
小王回想了一下A公司在早期创业时第二年就推出了一份比较简易的职级表。对于软件企业的职位大概进行了下列分类。后期修修补补，也一直延用到了现在。
- 实习生
- PG（程序员）： 分为1，2，3 三个级别。
- SE（系统工程师）：分为1，2，3 三个级别。要求SE可以直接进行中小项目的程序框架的搭建，在整个SE期间都有管理技能的指导。虽然，比较粗放。
- BSE（桥梁工程师/窗口）：日语可以书面交流，简单的对话。可以将客户的需求反馈给开发团队。
- TSE（技术工程师）：已经对某一方面的技术进行深入研究。相当于SE之后的技术岗位，更多承担技术管理者的职责。
- PL（项目Leader）：可以独立面对客户的所有需求，可以制定预算。
- PM（项目经理），更多的参与制定预算，管理下属，可以同时监管几个小项目，可以独立带队完成大项目。
其实从A公司的职级对应上来看，PG阶段更多的是技能上的提升，SE阶段就需要进行技术决策，同时在整个SE阶段会有管理技能的指导。BSE和TSE的分支代表着两个方向。一个是和技术打交道，一个是和人打交道。PL/PM的定位比较模糊，区别大概就是项目的规模的区别，而且更多的是一种政治考量。
而B公司的职级对应就比较让人摸不到头脑。
程序员-》项目经理-》项目总监、技术总监-》部门经理-》分管领导-》CEO
对于一名新进入企业的员工，他的努力目标也就只有项目经理了.......
甩锅成性，国企遗风
小王在B公司的几个项目发现了一个特别让他接受不了的问题，就是项目经理特别愿意甩锅。具体表现为以下几个事例：
- 当小王遇到一个事情问到小李时，小李说“这个事情你找小赵吧，我记着他做过”，当小王找到小赵时，小赵说：“你去找小李吧”
- 当客户给公司的座机打电话时，如果不是自己桌面上的电话响起，很少有人主动去接。除非有大领导看着。
- 当客户指责项目经理某一个需求并不是他预想的时候，项目经理会天然地认为是程序员的责任。俗称“溜肩膀”
- BUG过多时，项目经理和程序员最后沦为互相指责。
- 当项目经理整合了一个第三方的功能，然后所有的问题就都丢给第三方了。哪怕这个第三方是自己的分公司。
- 最严重的一个实例，某项目的总项目经理是小李，给这个客户做静态网站的项目经理是小孙。由于小孙经常和客户就颜色图片等功能进行交流，客户随口告诉了小孙关于整体项目的三个需求，小孙在回到公司后，告诉给了小李。三个月后，项目交付，这三个需求根本没做，客户来质问时，小李说并不知道有这三个需求。客户于是不由分说地给小孙一顿臭骂。
其实这些问题的成因都很多，并不能简单武断的就说是这些小李，小赵喜欢甩锅。
小王依次分析了这几种情况及其成因：
- 企业的知识管理没有形成体系，某些经常出现的状况没有固化成文章，手册或者文档。
- “多接一个电话与我何干”“他的项目又不是我的项目”的思维还是存在的。
- 所有项目上的变动没有得到记录，会议也没有得到记录。
- 项目经理倾向于“能者多劳”，于是就慢慢忘记了边界感。
- 小孙的社会经验不足，没有使用邮件等可追索的工具。
小王挠了挠头，其实这些问题在A公司早期也同样遇到过，由于日系的背景，A企业早期还将出现BUG和“羞耻心”，“责任心”联系在了一起。也是经历了数轮博弈，包括一些关键职位的大换血，A企业最终达成了下列妥协：
- 公司鼓励内部分享经验，但是严禁内部资料外传。中间有过一次公司内部论坛的建立，但是效果不好。最后发现在实际工作场景下使用邮件是非常便捷的方式。（企业还不用额外增加服务器开销）
- 电话的接打都是有专人负责，如果是在服务时间段外，电话响起，旁边的同事需要强制接听，但是只需记录下来电人，并告知来电人相关人员稍后会回电即可。
- 参见上文 redmine部分
- 加强内部品质管理，强制执行一些信息系统在测试过程中的CHECKLIST，收效非常好。使得开发人员也明确了哪些是对的，哪些是不应该出现在最终结果里的。
- 职业习惯的强制养成：邮件沟通 + 会议记录。以及在会议记录中明确写入【会后行动】一栏，明确相关人士的后续行动和目标。
- 解绑bug和“羞耻心”“责任心”的关联，设定一个合理的客户BUG率。
小王想了想，A公司的履职经历给了他好多的看不见的经验。当然A公司也不是没有问题，内部的派系倾轧的比较重，同时出现了一些“养闲人，养大爷”的情况。不过小王最后也淡然了，因为并不存在没有问题的组织，这就是一种动态平衡而已。