项目实施就是做人（二）----能不能明确责任？

最近这两天，手头上有两个项目让我很头疼。其中一个项目还让项目总监上了火。归结起来原因很简单，我负责了4个项目的项目协调，其中有2个项目是要求我亲力亲为去实施的，其他2个让我负责指导两位软件开发人员实施。那么我亲力亲为的项目表现很顺利，而其他2个我负责指导的项目就让客户优点恼火，而这两个项目属于小项目，钱不多，从合同签订开始，我就意识到风险。
公司现在的项目运作流程是，项目实施团队负责沟通、文档、测试（该职能是我最近强烈要求分给我们的）、维护、培训。开发人员与实施人员的比例大概是2：1，而我手下仅仅有两名实施专员，其中一位还兼顾嵌入式的开发。这种模式，说起来很奇怪，但确实是这样。我想，任何项目组织的形式可以这样也可以那样，关键是明确责任，哪怕你有多个职能，也得一一给你明确下来。但是，我想任何实施经理，都会抱怨，能不能把软件的功能开发的责任明确给开发经理。因为我们不管开发，我们只负责沟通、文档、测试、培训，对照合同，功能有就好，不管好用不好用，反正能用就可以。但往往，客户那边一反应系统的问题，老板会直接找我，你怎么搞的？老板认为项目的事情，项目经理要负责全责。而不会为你考虑，这属于开发的问题，责任应该有开发经理承担。对于这个问题，我想以项目运作流程，也就是从头开始，我们分析分析，为什么往往明确不了责任。
售前阶段。我想售前打单阶段，往往是项目经理上场（也就是实施经理），因为这帮人能忽悠，可以用稍微技术的语言忽悠的很流畅。关键是非常了解客户的心理和系统的业务价值，所以销售人员要打单，不会要求带上开发经理，而是实施经理。这就是实施经理提前介入项目。这种好处是不言而喻的，但是缺点同样也是明显的。那就是开发经理对客户的理解不到位，同样对项目的需求理解也不到位。而且最关键的是，开发经理感受不到这套系统能为客户带来哪些好处。电子政务系统，说白了，是政绩工程。那么你就得在系统上，至少是宣传上要反映出主管领导的意图，这就是政绩。但是开发人员不会考虑这些，也没法去考虑这些。所以项目开头就有问题，但这是谁的责任我们需要好好考虑。所以，在售前阶段，实施经理负责打单，同时也要负责向技术经理报告客户的意图，打单的过程，竞争对手的策略。这不是为了别人，是为了我们自己以后减少实施的难度。如果有一天，开发经理可以独立配合销售人员打单了，不是更好吗？售前阶段造成开发经理不能全面理解客户的意图，是实施经理的责任没错。那接下来的问题是，就算我跟开发经理沟通了，客户的意图是A、B、C，那么开发经理能接受多少呢，是不是变成了B、C、D了呢。我想这是沟通的技巧和沟通的控制问题，沟通不是我们想象的，说了就完了，那是沟，并没有通。说得对方能明白了，也认可了，是通了，但是不能保证它做的时候就记得这些东西，所以沟通除了沟和通，接下来就是监控。沟通需要监控，也有很多方法，例如不断的重复。我曾经有一次，因为某个项目需要，某件事跟客户达成了一致，但因为是方针性的东西，无法签字确认，我采取的方式是隔两三天就跟客户说我有事跟你沟通一下，就把之前沟通的结果在重复一次，前两次客户以为我得了失忆症，怎么一件事老翻来覆去的说呀，但重复3、4次效果就出来了，他后来也理解我这是在时刻提醒他。那有人会说，不过是提醒，到时间就给客户发个邮件、打个电话提醒一下不就完了吗。实际上不能这样，你老以提醒的名义，客户就会有反感，说你以为我是白痴呀。反而造成不好的影响，合适的做法是把自己当成白痴，这就是技巧。所以售前解决的问题，是让开发经理也能参与进来，这就是实施经理的责任。开发经理能理解并且能按照这个方向去设计软件，也是我们的责任，这都是我们自己的事。
合同签订阶段。我们公司的合同是有实施经理和销售人员一起拟定然后报请老板审批。基本上没有开发经理什么事。但我发现，对合同的条款，要求，即使是事后你把合同发给开发经理了，他也不看，或者不怎么看。具体开发起来，总是缩小了项目的边界，而到了部署的时候发现这个问题就晚了。所以要采取手段让他参与合同的编制，什么手段？有人说，大家都是平级同事，我总不能安排给他，命令他一定要看合同，而且要仔细看吧。你也不能跟老板说，老板，让谁谁谁也参与一下合同的编制吧。这样一来，老板就警觉了，你想推脱责任吗？那怎么弄？那就是自己压低自己的级别，把开发经理当成自己的上级。跟他说，合同我已经草拟了一下，还需要请你花点时间斧正一下，并在什么时候反馈一下，因为客户着急要。这样一来，开发经理会领情，会帮你看一下合同，哪些地方不合适，他会说出来。这样他就参与到了合同的编制了，对项目的要求、边界都有了个清晰的认识。这也是实施经理的责任，我们要掌握技巧，我们经常与人打交道，难道还伺候不了开发经理吗？人，往往对自己没有参与的东西不感兴趣，你让他参与了，他还能提一些意见，对以后实施也有利了。
项目计划阶段。这个阶段，说实在话，有很多问题。这个问题，不是我们项目人员自身欠缺相关的项目管理知识或者经验，而是整个电子政务系统建设的大环境不好。我经常想，政府大力支持软件行业，每年信息化投入占城市基础设施投资的比重约为10%，这是很大的比例了。可以想象，政府如果将信息化投入缩减一半，我想至少有40%的中小软件企业要倒闭了。所以IT行业多半还是政府在扶持，这是好事，能促进我们的信息化产业；但时间久了，我们的软件质量上不去，过程规范了不了。关系户打单，公司恶性竞争很严重。往往计划常常在更新，更新到我们很难从整体把握这个计划，尤其是时间计划。实施经理要做的，就是缩短项目周期，尽快验收还款。当开发的时间不能适应项目整体时间时，我们要做的，就是与客户博弈。而不能完全按照客户的时间要求来匆忙的部署软件、开展培训。这样遗留的问题太多，大大增加了实施的难度。我们也知道，我们往往在客户那边争取3个月的开发时间，而要求开发人员的开发时间控制在2个月，因为还有一个月是机动时间，作为浮动资源，这往往是开发与实施的矛盾所在。计划阶段实际上项目整体管理，关于这个课题我想在后面的系列blog里单独阐述。
需求调研阶段。需求管理与需求开发大家都觉得是软件开发最重要的一点，需求的改动经常发生。有些需求客户当时想不出来，等系统部署了，一堆修改意见就提出来。实施专员疲于奔命，一旦部署软件之后就是漫长的控制需求阶段。更严重的问题是，有些已经明确的需求，经过实施人员的转述，开发人员的理解，需求就从一个苹果变成了一个梨。而实施的高手，为了减少开发变更，即使这个变更起始源头是由于内部的原因造成的，我们使用一切手段告诉客户，苹果不一定好，而梨更加适合你。久而久之，我们实施人员都快变成了销售人员，能说会道，把客户忽悠的一愣一愣的。但是毕竟人家不是傻子，会在心里面留下不好的印象，一个企业连客户的需求都弄不清楚，怎么给人家服务？而且对于我们自己的产品也是有害的，现在开发人员基本看不到客户，也不愿意直面客户。很多东西就是几个开发工程师一个开发经理，开了一个会，于是定下来产品的下一个升级版本要解决哪些问题。我想这些都是不正常的现象，所以在我负责的项目，需求调研一定要有一个主干的开发人员参与，这样客户的需求才能稍好一些带入到软件开发中。但是这样往往也面临两个问题：第一是主干的开发人员经常最后都不负责这个项目，于是我们的苦心白费，解决办法往往需要实施经理非常强硬的态度，那就是既定的主干开发人员既然指定了，以后就不能换了，但往往我们也是无奈的，毕竟我们不是老板，但即使是这样我们也得有那种架势，明知不可为而为之(^_^)；第二就是开发人员往往只参与一次调研，后续的零星的客户意见他们听不见了，需要我们实施人员提出来，但是实施人员提出来以后，要么就是开发人员觉得没有必要解决，要么就是解决之后实施人员上系统一看，怎么跟原来说的差别这么大？这就是需求提出来和开发人员设计、编码的理解不一致造成。实施经理权限就到提出来，而怎么解决的，还是开发经理的范畴，所以怎么能融入系统开发，或者至少在设计阶段能参与一直也是我考虑的问题。这倒不是说我们要越权，我是感到不符合客户真实意图的开发，最后倒霉的只能是我们，客户不会管你那么多，说到底是你公司内部沟通的问题。我也想到一种办法，那就是多和开发人员沟通，但实施专员又经常要出差，不能老在公司待着，那么就一有机会就跟开发人员沟通。实施经理一有机会就跟开发经理沟通，实施专员一有机会就和主力开发人员沟通，现在，也只能这么解决。有人也会会说，你把需求以图形化的方式表达不行吗，画界面草图，画表格。我想，如果开发经理买你帐，ok，可如果不是，反倒造成内部矛盾，怎么你还插入到设计阶段了，你好好搞沟通就得了，有了抵触情绪，沟通就更难了。
系统部署阶段。我想国内大多数实施专员都会抱怨，为什么我们的软件部署起来一定要那么复杂。光配置文件就有7、8个，没有部署说明，没有部署规范。配置文件需要哪些东西，开发人员不会主动告诉你。我们带着产品去部署，发现按照上次的部署方法，怎么老出问题。于是我们打电话给开发人员，这是怎么回事？电话说不清楚？ok，那我截图。等待1、2个小时候，他说我们这没问题，你再检查一下A、B、C、D，实施人员晕。于是检查A、B、C、D，给开发人员打电话，还是不行。开发人员说，那我再看看。于是又是几个小时过去了。实施经理问实施专员，部署成功了么？回答：没呢，出现了#￥%……&问题。客户问实施经理：怎么还没部署成功呀。实施经理又开始忽悠，什么操作系统有点问题呀，Oracle本身的Bug呀一堆。客户听不懂，于是说那你们快点，明天上午9点我们局领导要看演示。接下来就是混乱的打电话、协调、第一套方案、第二套方案。后来我一分析，造成这个局面有这几个原因：第一，出场前没有做好测试工作，往往是开发人员赶进度，弄好了简单测试一下就交工了。第二，我们的系统与数据绑定很严重，由于我公司是一家GIS企业，空间数据往往又不是我们自己提供，所以数据一旦录入，就会发现这不合适那有问题。第三，我们没有把现场部署的压力带给开发人员，即使他们不在现场。面对第一个问题，我主张由实施团队兼任测试团队。国内的中小IT企业，不养专门的测试人员，这是常识(^_^)，而开发人员自己检查自己，往往不过关。而实施人员，既是业务专家又有技术功底，由我们来测试最合适不过，所以实施经理应该在进度紧张的情况下，勇敢跟客户说不，需要专门的测试时间测试，而不是每次都是打仗，没有一点准备和计划，让客户看起来也非常不专业。第二，专门的数据检查报告。数据哪不行哪不行一条一条写下来，这样我们实施人员才有筹码跟客户争取时间，你看，数据有这么多问题，您别要求我们这么紧张的时间了。第三，系统第一次部署，一定要有主干的开发人员到现场，并把安装部署出现的问题一条一条用文档列清楚，发给总监、开发经理，让大家都紧张起来而不是只有实施人员紧张。
结尾：人们对自己没有参与的计划总是不关心。在销售面前，实施人员是技术人员；在开发人员面前，实施人员是销售；在客户面前，实施人员是炮灰。我想，在软件项目整个过程域，我们实施人员要全程参与，也许会加重我们的工作量，但是也是减轻我的工作量，我想这就是对立统一的思想。