同类服务企业对比案例.pdfVIP

同类服务企业对比案例

序言

在这个案例中，我们姑且称主角为小王，因为这样的称呼在一

个语气助词“吧”的推波助澜下会显得特别有趣。小王从2010年毕

业到现在，一共经历了两家公司，姑且称之为A,B两个公司吧。在

A公司待了两个合同期，也就是6年，在B公司待了两年。先简单

介绍一下两家公司的背景，A公司是一名海归创建的中日合资的公

司，主要的客户都是日企，工作方式也是日本式的。B公司在上世

纪曾经是一个政府事业单位，后来分离成一家专注于政务系统的公

司。虽然已经新三板上市，但是仍有着大量的中国特色的管理实操。

在B公司的遭遇。

来到B公司的第一天，小王就被高效的聘用流程所震惊，从面

试，面谈，发offer到入职一共只打了两个电话。虽然和相关负责

人曾经共事，但是这个效率也太高了点儿。一切还算正常，但是经

历了几个项目之后，小王发现B公司的以下几个问题尤其凸显。

项目管理的等级不高。

人才的成长计划为0。

甩锅成性，国企遗风。

项目管理的等级不高。

B公司的自我认定的开发标准是CMMI3,即，在这个水平上，企

业不仅能够对项目的实施有一整套的管理措施，并保障项目的完成；

而且，企业能够根据自身的特殊情况以及自己的标准流程，将这套

管理体系与流程予以制度化，这样企业不仅能够在同类的项目上得

到成功的实施，在不同类的项目上一样能够得到成功的实施。

科学的管理成为企业的一种文化，企业的组织财富。

但是在小王的观察里，CMMI3要求的管理措施和实际工作中的

完全搭配不上。在项目的最终交付清单上，虽然有【概要设计】和

【详细设计】，但是这些文档基本都是在最终交付日期之前统一赶

工完成。也就是说，指导程序员进行编码的文档在开始编码的时候

根本都没有做。那么，程序员是根据什么来进行编码的呢？大多都

是项目经理对于需求进行口述。虽然，项目也存在一个类似“需求

说明书”之类的文档，但是这个文档的实用性也比较差。大量的需

求还是依赖项目经理口述完成。

口述需求这件事带来的风险就非常大了，主要集中在以下几点：

需求的可追索性。

对于需求理解的歧义。

编码缺乏整体考量。

于是，在小王的工作经验中经常出现下列的场景：

程序员在对应需求的时候经常遗漏。

项目经理忘记了自己曾经提过的需求。

因为双方都是通过口头的形式进行沟通，导致没有反馈，缺乏

检查。表现为：

程序员和项目经理沟通的时候，大量的使用“这个”，“那个”

类似的代词。

项目经理发现程序员的修改不是他想要的结果，并埋怨程序员

没理解对。

程序员发现项目经理自己理解错了客户需求，反倒赖自己没理

解对。

在开会的时候，“还有一个事儿”，“还有一个问题”经常出

现。缺乏整体性。

在修改其他人的代码的时候出现莫名其妙的代码，不理解。

业务和业务之间会出现逻辑冲突，在编码时期没有发现。

最终交付时，发现还有客户的某些需求没对应。但是时间已耗

尽。

测试团队在进行测试的时候不知道什么状态是对的。

代码在向维护团队进行交付的时候，没有办法进行整体性的说

明。

项目经理不做检查和品质管理，然后在功能上线的时候拉着程

序员到客户现场驻点。

除此之外，小王在维护组的一段时间内，还发现了下列状况：

开发组提交的代码无法完成编译。

开发组的代码出现“回退”的情况，即曾经出现的且已经修改

完的BUG还会出现。

开发组找不到当前版本的代码，需要维护组去真实环境里反编

译。

线上版本的LIB库中出现冗余的，谁也不知道干什么用的jar.

开发组在提交成果物的时候，忘记了告知维护组有数据库变动，

配置文件变动等等。

开发组的相关人员离职后，谁也搞不清楚业务逻辑。连项目经

理都说“忘记了”“记不清了”。

小王回想了一下A公司在早期创业时也遇到了类似的问题，但

是最终经历了几轮博弈之后，形成了下列的各方都能接受的方式。

DEMO优先于设计书，客户确认DEMO无误后，利用DEMO指导开

发。

搭建了一套redmine，用途有以下几点：

所有的需求的变动都记入redmin