组织级项目管理实例分享——来自项目管理群的讨论

老蔡

说:

1、背景

2、存在问题

3、制度与监控

4、QA审计方法与组织级技术管理的介入点

我们业务软件分公司，有200+人员，下设业务拓展部（市场），5个产品线（开发为主）、集成、支撑等各部门

此外，还有一个项目推进部（PMO）

产品线下设各项目组。需要注意的是，由于产品线由经营指标导向，而项目组是产品线下属机构，所以，PMO实际上只是一个弱PMO。

这种组织结构形成有历史原因。即使从现状看，也不可能做成强PMO，因为毕竟各产品线的业务各异，与客户、各干系人的接口不可能通过PMO进行。

实际上，有一定矩阵式的特点。

产品线经理的考核，主要是经营指标导向的，虽然也有一些其他指标，但明显弱多了。

因此，产品线经理非常注意经营指标，而忽视其他一些关键指标，甚至出现一些短期行为，这都是可以理解的。具体的说，主要有以下问题：

1、项目管理
的随意性。名义上，产品线下属的单位是3-5个项目组，项目组的负责人叫项目经理。实际上，这些项目经理即便上了PMP课，在实际工作中，仍是非常随意的作坊式工作。而产品线经理不会对这些进行辅导，只关注客户的实时要求、经营指标等。

2、对质量的极度忽视。在CMMI的观点中，把质量提高到前所未有的高度。在我们的实践则相反，只要用户无投诉，基本上不会当成项目经理什么大的过失，软件做的好坏完全以客户评价定。

3、由于无质量要求，那么系统设计、技术架构、新技术引入也都谈不上，开发工作在低水平上重复，代码复制率很高，复用率很低。这样，开发人员就缺乏一种技术成长的感觉，也会缺乏团队归属感。

Kerry 说:

产品经理的确只对产品的特性负责，项目经理对项目进度、风险、成本等进行管理

老蔡

说:

4、由于管理的随意性，人为偏好，技术成长困难等因素，导致员工的受挫感的传播，团队难以形成好的氛围。

Kerry的问题我先解释下。我们的

“

产品线经理

”

是项目经理的直接领导，PMO不是项目经理的领导。所以，他们负责的面向是完全一致的。其他问题等最后一起聊吧。

5、各类管理信息无法到达分公司管理层，导致分公司工作被动，有时是客户投诉到总公司时，分公司领导才得知此事的情况。至于组织层面的整体技术管理，根本不可行，如同昨天说到的知识
管理案例也是这么回事。

根据以前管理产品线的经验，针对这些问题，我的考虑是（1)通过《项目流程》的制度，把职责、流程、流程中各角色职责、基本行为规范、基本软件过程定下来。

（2）通过组织级QA审计，检查各项目的流程执行情况，同时取得一手信息，避免信息被项目经理、产品线经理两个管理层面屏蔽。

（3）在信息通道打开之后，技术管理等其他管理手段逐步介入。

现在就着上传的4个文档
给大家说明一下我们的工作方法

Richard李明-项目主管-北京 说:

嗯 有流程，信息流动好像不是很好

老蔡

说:

李明的问题，正是我要说的。

Richard李明-项目主管-北京 说:

请继续哈

老蔡

说:

首先，流程执行的第一个要求是客观，实际怎么执行，怎么表达。

我们是行业应用软件，一是软件开发流程，这是一个时间段。在这个时间段中，可能会出很多很多版本，一般1周至1个月出一个版本。

出版本后，要升级到现有系统去，那么就需要***升级包，升级手册、数据库脚本什么的。升级操作是一个

“

点

”

而不是一个时间段，但由于它非常重要，所以我们也要记录和审计。

打开《版本开发流程单》，这份文档，就是要求每个迭代版本开发时填写。

评审等过程，简化为签字，而不像CMMI要求的那样出评审报告。

对于大的版本，比如1个月出一次的，一般来说，会有与用户的原始交流，即用户提出原始需求
。

然后需求人员进行分析，出需求规格文档。

再和开发人员、项目经理开会，确认做哪些，哪些跟客户解释不做或以后做。这个会议，不要求出评审报告和会议纪要，只要相关开发人员签字认可。

接下来项目经理根据大家评审的结果，进行规划版本；后是测试
。

最后项目经理审核整个版本包，产品线经理复核。

如果是一个紧急补丁，很多过程可以简化。

这样，实际上用于

“

流程

”

的时间，也非常少。

等到版本或补丁***完，开始准备上线时，需要进行现网操作审核

这个细节就比较多，因为维护支撑部其实没有参与前期的开发，那么他们就会对项目组期待很大，而自己不去关心版本的内容。另一面，项目经理也会有同样的期待，这里就有一个漏洞了。

QA审计要关注到这个升级操作是否明晰，是否可执行，是否可回退等。

甚至，如果现场实施人员，同时也是次日保障人员，是否可能？对于一个简单的补丁一般没有问题，但如果大版本肯定不行。

这样，理论上，项目成员只用了签字、填表的时间成本，就把关键的项目信息都透明出来了。

补充上，刚才漏了。在CMMI中，提倡对每个项目的软件过程进行定制。

在实践中，我认为基本不可能。

所以我的做法是，根据项目的重要程度，新系统开发还是迭代式，分别管理。具体见《项目检查点》上的说明。

这样，PMO维护一份项目清单，同步给各产品线，大家按照项目检查点上的要求，结合整体的项目流程，这样实际上就等同于，定义了5-6种标准过程，选择使用（PMO与产品线事前沟通选择）

最后说下执行的情况。

在最初，我摸索这个方法的时候，尽管要求项目成员填写的信息不多，但通过有限的信息，以及相关的工作产品文档，可以发现一些疑点或不清晰的地方，然后找相关人员访谈确认（这个访谈也跟CMMI不同，重实质不重形式上的覆盖率）。

这样，发现了很多并不是一般意义上的流程执行问题。

例如，可以发现补丁包***错误，发回项目组重做后，才同意上线。

（严格的说，是否同意上线不是QA的权力，QA审计是事后的审核点。因我是分公司管理层，才可以这么做）

当我把这个方法移交给QA时，发现执行情况不理想。受CMMI熏陶过多，每个流程单十几分钟就审核完了，要么就是完全违反流程，要么就是没有任何问题。

为此，我重新考虑了我自己的审核的方法，设计了《QA审计报告》文档。本来我认为QA审计应该不受限于审计报告，而以主观经验带入为好，但这样导致我对QA无法监督，而QA发现问题越少也无所谓。现在不得以加入文档化的审计报告

这样，一方面，审计报告中体现出QA对项目原始数据的搜集。这些搜集主要不是通过询问项目人员，而是访问SVN、Jira等

通过原始数据的搜集后，对于软件过程审计，应当能分析出一些有意义的结果。

什么是有意义的结果呢？例如，一个大版本，开发人员200的，有测试报告，但Jira上却没有BUG记录？或者只有少量的小BUG，这肯定不对。

“

软件产品质量审计

”

这个小节，侧重关注产品定义是否清晰，实际上与配置管理关系很大。很多项目组的配置管理非常混乱。

部署包和升级步骤，基本上就是组织级技术管理的主要介入点之一（新系统开发的评审也是重要的介入点）。

在这个点上加强控制，可以提高升级的成功率，减少回退和次日的问题数量、紧急补丁数量。

这个部分，也是要求QA做独立意见的。

徐文锦 - IT Consultant - singapore 说:

问一下 你们有几个环境 除了dev 和production

老蔡

说:

当我看到审计报告时，如果对QA意见明显不认可，可以找QA谈，顺便指导QA的工作。

最后，版本上线情况跟踪分析，实际上形成了一个闭环。

可以关注到，项目经理、产品线经理是否有进行后续跟踪（很多产品线经理根本不管）。

然后与其他版本建立相关性，可以分析是否存在屡次升级失败，是什么原因等。

通过这个审计报告模板，基本上QA的工作可以保证达到一定的细腻度。对于分公司层面进行上线最后的确认也不会太盲目。

主要内容就这些了。麻烦徐文锦再表述一下问题？

徐文锦 - IT Consultant - singapore 说:

我说的是, 从开发环境 到 生产环境 中间还有几个环境几个步骤

老蔡

说:

正常情况下，开发环境就是开发人员的工作电脑＋数据库；测试环境在公司，也独立于开发环境。生产环境不在我们公司。

独立的测试环境，和正确的版本***方法，理论上可以保证版本升级的正确性。

不过，在实践中，项目组混同开发与测试环境的事情也不少见

各位，还有问题吗？

徐文锦 - IT Consultant - singapore 说:

个人感觉 不让开发人员接触测试环境 即QAT 可以较大的提高软件质量.

老蔡

说:

是的，我们是这个要求。但是，从分公司管理层面，到开发人员有管理层级的差距。如果去问项目经理，很可能还告诉你他们分的很清楚，只有在工作实践中的QA数据才能发现问题。

吴柯-管理-北京 说:

你们是为自己的母公司开发软件吗？

老蔡

说:

不是，为电信行业客户开发。

吴柯-管理-北京 说:

哦，一个大软件公司，业务软件分公司是一个大产品线

老蔡

说:

不是。我们的分公司，你可以理解成一个独立公司，除了财务不在我们，其他职能多少有一些。

吴柯-管理-北京 说:

哦

产品版本和项目版本怎么同步？

lastwinner-pm-bj 说:

跟上进度了，老蔡今天讲的这个层次相对较高了

我想问一下，这样做，对QA的技术素质貌似要求很高呀？

老蔡

说:

无所谓产品版本和项目版本，在配置管理混乱的情况下，只能根据各个项目的实际控制来说。实际上，基本是一个地点的一个项目一个版本。产品，只是概念上的，用于包装给客户的。

徐文锦 - IT Consultant - singapore 说:

QA

其实是软件开发中非常重要的一个环节

吴柯-管理-北京 说:

这样啊

徐文锦 - IT Consultant - singapore 说:

microsoft

的office team dev和qa的比例达到1:10

老蔡

说:

lastwinner，由于历史原因，我这边的QA薪酬相当不低。

徐文锦 - IT Consultant - singapore 说:

而且严格的项目一般是要求qa或者专门的deployment team 出包和部署

吴柯-管理-北京 说:

哪质量难以得到保障，产品发展代价反而更大

lastwinner-pm-bj 说:

怪不得分配的任务要求这么高

徐同学说的微软的情况，国内很多公司够不适用的，连用友这样的公司都做不到

徐文锦 - IT Consultant - singapore 说:

我觉得国内公司 特别是小公司对于qa的要求太低 很难保证产品质量

吴柯-管理-北京 说:

比如一个项目里发现的BUG，修改后其他项目未必用得上

lastwinner-pm-bj 说:

国内很多公司都不适用的（刚把 都 打成 够 了）

老蔡

说:

我们是要求测试人员出包。即开发人员宣称代码已经好了，然后测试人员打上版本标签，从SVN库中取文件，用事先提供后的脚本构造编译出包。实际上，个别项目组做的到，大部分做不到。

吴柯-管理-北京 说:

这个是对的

徐文锦 - IT Consultant - singapore 说:

一般这个过程可以采用自动集成/编译/部署 ,不过一般需要专门的部署团队

吴柯-管理-北京 说:

版本一定要专人

老蔡

说:

我的方法是，开发人员可以帮助测试人员写脚本。但提交测试和部署的版本包，一般是在开发人员无法接触的情况下生成的。

吴柯-管理-北京 说:

除了SVN以外，还用到什么辅助开发管理的工具吗？

lastwinner-pm-bj 说:

老蔡你说的 "做不到"，指的是代码的版本管理做不到还是说实际上他们宣称的代码已做好是不符合实际的？

老蔡

说:

这样，只要测试通过的包，拿去升级一定没有问题。

lastwinner-pm-bj 说:

老蔡-技术总监-福州 says (13:24):

这样，只要测试通过的包，拿去升级一定没有问题。

这话太绝对了，不过这样做可以说99.9%的情况下都不会有问题

徐文锦 - IT Consultant - singapore 说:

如果你有兴趣可以研究一下TFS 和微软一整套的软件开发流程

老蔡

说:

lastwinner，是项目经理的意识做不到。我现在的工作层次在组织级项目管理。

lastwinner，别这么认真啊，其实99%没问题就已经非常非常好了。我们目前升级的回退率大概5%，加上升级有问题的情况，应该快10%了。

徐文锦 - IT Consultant - singapore 说:

一般比较正交的测试 把bug降低到1%问题还是不大的, 如果有会写代码的qa 那么还会再降低Bug率

lastwinner-pm-bj 说:

如果是意识问题，那么通过你的方法灌输下去，多数项目经理就能具备这样的意识，对吧？

老蔡

说:

不只是灌输啊，要循序渐进，慢慢渗透进去。

项目经理真想做，一定能做到的。

吴柯-管理-北京 说:

一个产品同时支持多个客户？

多少个？

老蔡

说:

大部分产品是1个。现在慢慢2-4个的，但实际上，那个产品也有很大变更。你理解成项目或许更好些。

徐文锦 - IT Consultant - singapore 说:

问一下, 谁为版本回退/部署失败 负责?

吴柯-管理-北京 说:

以现场客户开发为主，还是在公司开发测试完后在现场只是部署？

老蔡

说:

项目经理

在公司开发为主。

吴柯-管理-北京 说:

这个是电信的行业特点，还是你们公司的业务特点，我们公司做金融行业，大部分是现场开发？

老蔡

说:

电信行业，一般不会大部分现场开发。金融行业，听说大部分是现场开发。

吴柯-管理-北京 说:

公司开发要求客户的需求质量比较高，变动也不能太多

你们这方面如何控制

徐文锦 - IT Consultant - singapore 说:

毕竟你们和钱打交道....软件质量会要求比较高

lastwinner-pm-bj 说:

这种管理方式感觉能让PM较快的成长起来，而且能对自己的工作职责范畴有清晰的了解

MicrosoftInternetExplorer402DocumentNotSpecified7.8Normal0吴柯-管理-北京 说:

客户不参与最后的测试吗？

徐文锦 - IT Consultant - singapore 说:

应该是参与的吧

吴柯-管理-北京 说:

你们测试完就直接上线？

蔡晓东 说:

新系统开发，会参与，但参与度低

徐文锦 - IT Consultant - singapore 说:

不过国内的就不好说了....电信那些人- -#

蔡晓东 说:

迭代式，很多情况已经是在线系统了，客户要求我们1-2周上一次版本，他们没有精力陪我们测试。要测也是等上了再说。

差不多了吧，这次记录我自己发吧

吴柯-管理-北京 说:

我们一般1-2个月一次，1-2周会不会有些短，从需求、涉及开发到测试？

徐文锦 - IT Consultant - singapore 说:

如果是迭代的话这个时间不算短,

瀑布就惨了

蔡晓东 说:

行业不同。有时客户会要求2-3天来一次。

吴柯-管理-北京 说:

哦

徐文锦 - IT Consultant - singapore 说:

你们是如何避免涟漪效应的, 就是你改了一个地方 其他其他也受影响

吴柯-管理-北京 说:

差异还真大

蔡晓东 说:

当然必须迭代。不过目前主流过程对迭代支持都不好。scrum可能会好，但是，scrum的客户参与等是不可用的，我们必须把客户做干系人管理，而不是类同团队成员。

老徐的问题，分两个层面：项目层面，看经验；组织层面，就只能在QA质量审计，QA或者分公司管理层发现疑问，追溯下去分析了。

吴柯-管理-北京 说:

用了scrum吗？

蔡晓东 说:

没有，我是在自己的方法论形成之后，才知道Scrum。感觉Scrum也是受应用场景限制的。