蔡晓东的博客

主讲：蔡晓东-技术主管
记录人员：一点红

蔡晓东-技术主管-it-福州 说 (12:26):
给来的早的各位预报一下内容：
这是一个很长的故事：
0、缘起
1、项目组织结构
2、人员培训及开发的启动
3、风险管理
4、需求管理
5、团队文化
6、割接前后

蔡晓东-技术主管-it-福州 说 (12:31):
今天由我和大家分享电信增值业务系统的项目管理经验。

蔡晓东-技术主管-it-福州 说 (12:31):
0、缘起
我刚到公司不久，就接到一个电信增值业务系统的需求
领导问我说，我们公司能做吗？
如果我的回答是不能，那么这个事情的结果，很可能就是由另外一家公司的产品进驻，上线后移交给我们公司。
考虑利弊对比，而且根据我的经验和技能，还是比较有把握的。当然，我不愿意跳槽到一家新公司后，接手其他公司的产品，而不是自主开发。
所以我跟领导所，我们能做。
……

过了一些日子，领导问我，怎么项目没有什么进展？
我说，人呢？她让我把需要的人数和安排告诉她。
之后，回了个消息给我：“还需要加10个人？”
我问“很多吗”？
从那时候开始，我就意识到这个项目今后将面临的种种困难。一切只是一个开始。
我们的公司太缺乏这种大项目的经验，完全没有应对这个项目的思想准备，在很多情况下，只能靠自己了。
好在我的领导还是非常善于接受意见的，后来她详细了解了我在另一家公司参与的类似项目情况、投入人数、时间等，也尽可能补充了一些人员进来，在数量上基本达到了我的要求。

1、项目组织结构
蔡晓东-技术主管-it-福州 说 (12:39):
我们公司以前很少有自主开发的大项目，因此，组织结构是按照人员投入最大化的方式，弱矩阵方式。
一个项目来了，在开发组中找个人负责，然后需求组、自动业务组、维护组都有相应人员配合；考核归各自组长。
蔡晓东-技术主管-it-福州 说 (12:41):
再加上我们公司的股东背景原因，项目成员不太善于接受项目的意思，有时跑到客户的立场去了。例如，在出现分歧时，维护组的人员就说要对电信公司运维部门负责。
需求人员也经常站在客户角度提需求，发挥想象力，而不顾项目的实际。
蔡晓东-技术主管-it-福州 说 (12:42):
最大的问题，在于领导的意识，比较害怕冲突，而在弱矩阵情况下，冲突是在所难免的。
hz_wm-上海 说 (12:42):
站在客户角度提需求，也是有道理的。
蔡晓东-技术主管-it-福州 说 (12:42):
我在一段时间内，也向这种组织结构妥协。
蔡晓东-技术主管-it-福州 说 (12:43):
直到一次电信公司的老总带队到我们公司考察，实际上是来质询项目进度及其他相关问题。
蔡晓东-技术主管-it-福州 说 (12:44):
这带着两个影响：其一，我决定改造组织结构，消除矩阵，建成项目型组织；其二，领导认识到只有给我充分授权，才能对我问责。
蔡晓东-技术主管-it-福州 说 (12:45):
很快，项目组独立与原有的各个专业人员组。项目型组织在表面上形成了。
hz_wm-上海 说 (12:45):
权责一定要清晰，否则，就是糊涂帐
蔡晓东-技术主管-it-福州 说 (12:46):
但人员在这种环境下工作了很久，意识一时转变不过来，而且本位主义严重，经常为了一些小事，讨论这是不是我的工作职责。例如，与客户部门打电话说的事情，都有人认为他不是接口人，不应该做这个事情。
蔡晓东-技术主管-it-福州 说 (12:47):
我的观点是，我能够为职责的事情谈判一次，但不能每次都谈判。尽管是项目经理，但在实际上，权威仍然不足以完全控制项目组。
richard_tl_sh 说 (12:47):
职能型转向项目型
蔡晓东-技术主管-it-福州 说 (12:48):
在这种情况下，借鉴了物流行业的经验，制定了标准作业流程SOP。即对每个岗位的职责，每个典型工作的流程等都做出限定。
之后，再组织了一次有广泛代表性的评审，由大家共同讨论，评审通过。
蔡晓东-技术主管-it-福州 说 (12:49):
在权威不足的情况下，运用“评审”的手段，形成大家一致认可的制度，再通过制度约束包括项目经理在内的所有人，是这个项目的重要经验之一。
蔡晓东-技术主管-it-福州 说 (12:50):
在评审通过以后，只出现了非常少的冲突，并引用SOP作为凭据，大家一看，该谁谁就清楚了。此时，项目型组织完全形成。

2、人员的培训和开发的启动
蔡晓东-技术主管-it-福州 说 (12:51):
显而易见，这个项目的压力远大于其它项目。每个人都能意识到这一点。
因此，留在这个项目里的人，绝大部分都是新员工，包括刚毕业的、工作时间很短和工作若干年刚刚跳槽的。对于我们公司来说，他们需要一个机会。
蔡晓东-技术主管-it-福州 说 (12:52):
但他们普遍缺乏呼叫中心的工作经验，业务知识欠缺。
蔡晓东-技术主管-it-福州 说 (12:53):
技术能力上，也需要针对这个项目做一定提升。
蔡晓东-技术主管-it-福州 说 (12:54):
这种情况下，软件设计非常重要。但是，完整的做一个OO设计是不可能的，因为这是一个高度受限的系统，甚至连某些表都已经被限制。
这个软件分为两个层面的问题：呼叫中心、业务
蔡晓东-技术主管-it-福州 说 (12:55):
呼叫中心方面，设计的重点是各个节点之间的接口协议；业务方面，设计的重点是表结构。由我和开发经理（一位资深开发人员，在本项目中首次任开发经理，后来接任项目经理）。
蔡晓东-技术主管-it-福州 说 (12:56):
我们2人把重点设计把握住以后，让所有开发人员自己做详细设计，我们再对详细设计进行把关、沟通，提醒他们没有考虑到的部分。
在开发结束后，实际上详细设计已经远离了代码，但详细设计文档已经起到了它的作用，它让开发人员最快进入角色，熟悉了相关的业务，并为开发奠定了基础。

3、风险管理
在这个项目中，我第一次真正感受到风险管理的重要性。
之前的很多项目，有什么风险，根本不需要一份风险清单。因为它是显而易见的，每个人都知道。
蔡晓东-技术主管-it-福州 说 (12:58):
但这个项目，很多的风险是项目经理都不知道的。特别是技术风险和进度风险。
蔡晓东-技术主管-it-福州 说 (12:59):
因为骨干较少，各个模块开发人员没有真正的小组长，而我和开发经理只能抓大的问题，一些小的问题，就在开发人员中处理。
开发人员如果及时把问题提交给我们，也能得到处理。但在实际工作中，经常会把问题搁置，直到我们想起来。
蔡晓东-技术主管-it-福州 说 (13:00):
因此，我对风险做了最强的定义：凡是开发人员因为任何原因导致计划内的工作无法如期完成，必须做为风险，列入风险清单。
蔡晓东-技术主管-it-福州 说 (13:01):
载入风险清单的内容还有，相关的人员、预计解决方案、时间等相关事项。如果风险如期消解，可能我只是看看列表。但一旦出现超期，或者我可以预见到他们的能力不足以顺利处理这个问题，就可以采取积极的措施。
风险列表成为每天关注一个重要事项。
不胜人生一场醉-闲人一个-海口 说 (13:02):
这个进度风险考虑的很周到
蔡晓东-技术主管-it-福州 说 (13:02):
当然，严谨的定义上，很多风险可能不能算是风险。但这个问题并不重要。重要的是，作为项目经理，在跟踪管理项目的时候，一定要有合适的工具，并充分发挥它的效用，达到自己的管理目标。

4、需求管理
蔡晓东-技术主管-it-福州 说 (13:04):
我们的需求人员有一些工作经验，但对于呼叫中心也很陌生。因此，一开始，我们就让开发人员参与到需求工作中；在中期迭代的时候，再组织了一次；最后与各地市用户确认的时候，还参与了一轮。
即便这样，需求仍然远远超出预期……
蔡晓东-技术主管-it-福州 说 (13:05):
因为，一个系统的需求，并不是系统界面上或者文档上写的那些。当我们从某个旧系统割接到新系统时，一定要明白：用户对旧系统的使用方式就是需求。
蔡晓东-技术主管-it-福州 说 (13:06):
旧系统年限长了，没有及时升级，用户需求无法满足，他就会发挥想象力，让旧系统能够满足需求，这就形成了特定的使用方式。
蔡晓东-技术主管-it-福州 说 (13:07):
当我们调研时，根本无法发现这些需求。举例来说，需要一个字段表示用户开通了实名业务，但是没有这个字段，怎么办呢？可以更改单位名称，出现一个R，表示实名业务。
我们做数据割接的时候，忽略了这一点，导致最后部分数据返工。其他类似的情况也有，时间长了不太记得。

5、团队文化
这个项目的压力比公司其他项目高。
蔡晓东-技术主管-it-福州 说 (13:09):
最早建成了项目型组织，而且有比较专业的管理团队。在整个项目的过程中，项目骨干人员与项目成员一起共度难关，取得了员工的认可。
蔡晓东-技术主管-it-福州 说 (13:10):
在16个月的项目历时中，共同的环境和紧密的配合，形成了良好的工作氛围。团队成员普遍敢于承担责任，积极进取，呈现出不同的风貌。
蔡晓东-技术主管-it-福州 说 (13:12):
在项目结束后，因工作原因，项目经理也有几次变动。但项目的工作流程、沟通氛围都得到很好的的保留，不受项目经理个人的影响；外面调入的项目经理也很好融入这个团队。

6、割接
蔡晓东-技术主管-it-福州 说 (13:13):
因为对困难和风险的敏感，在割接的准备工作上，我们已经做到了极致：
4次全省业务功能测试
3次数据割接测试
仿真环境1/4压力测试
现网单服务器压力测试和全系统压力测试
蔡晓东-技术主管-it-福州 说 (13:14):
客户方面，对这个项目非常重视，与我们开了几十次割接方面的会议。
蔡晓东-技术主管-it-福州 说 (13:15):
临近割接时，我们的全系统压力测试结果已经出来了。Web应用服务器的压力都只在5%左右，低于我们的计算值，说明程序写的还是好的。
蔡晓东-技术主管-it-福州 说 (13:16):
但数据库服务器同时面临着多方面的压力，而且是旧的小型机，本次没有更换。瓶颈很明显是CPU，压力测试报告显示，话务高峰CPU将达到80%
hz_wm-上海 说 (13:16):
话务高峰CPU将达到80% ，风险偏大。
蔡晓东-技术主管-it-福州 说 (13:17):
这时，我还是把压力测试报告原样提交。电信公司以非常负责的态度，临时借了几个CPU，把原有2个CPU升级到6个CPU。再进行压力测试，CPU只有20%-30%了。
此时万事俱备，只待割接。
蔡晓东-技术主管-it-福州 说 (13:18):
为了规避风险——我又提了一次风险，这对于我们是一个不能失败的割接
蔡晓东-技术主管-it-福州 说 (13:19):
我们根据割接的情况，安排了临时性的组织结构，划分小组。大致上有现场支持组、开发组等。最终每个可以调用的人员都有了适当的安排。
割接当天下午，把所有人员打发回家休息。
蔡晓东-技术主管-it-福州 说 (13:21):
当晚8点左右开始割接，客户公司由老总下割接指令，割接现场我们开始割接。
蔡晓东-技术主管-it-福州 说 (13:22):
开发经理和开发组、集成组进行割接操作，我则作为信息枢纽，与客户、驻各地市人员、其他人员进行沟通，判断问题轻重，在尽可能不打扰开发组的情况下处理。
割接操作还算顺利，进入测试阶段。
蔡晓东-技术主管-it-福州 说 (13:23):
此时，忽然发现我们这边的话务现场人员把一个重要信息遗漏了，是其它地市反馈给我们了。我意识到，这个时候，除了开发经理的应急补丁开发外，最重要的不是信息枢纽，而是前端。
蔡晓东-技术主管-it-福州 说 (13:24):
我们要正确指导客户操作，平息客户的意见，才能不回退。
蔡晓东-技术主管-it-福州 说 (13:25):
所以，当即决定与派驻话务现场人员调换岗位，我到话务现场，他来充当枢纽。
之后，我在话务现场发现问题以后，即电话通知信息枢纽，由他这边（包括其他人员）转告到其他地市。
蔡晓东-技术主管-it-福州 说 (13:26):
到了凌晨4点多，越来越平静了。按照和我在一起的电信产品经理的说法：只要10点的话务高峰能过就没有问题了。
蔡晓东-技术主管-it-福州 说 (13:27):
于是我先回到家休息。到了7点，再到割接现场。
蔡晓东-技术主管-it-福州 说 (13:28):
开发经理已完成了一夜的工作，判断问题的优先等级，分别处理妥当，他9点左右离开割接现场。我带领少数几个人在白天值班。
之后的时间，白天都是由我负责面对客户的压力，搜集问题；夜间由开发经理带队紧急处理。
蔡晓东-技术主管-it-福州 说 (13:29):
1个月后，包括业务模块、数据割接在内的所有问题解决妥当了。项目组终于进入了比较正常的阶段。