挨踢项目求生法则——实施篇，避免”一失足成千古恨“！

摘要：


安装部署系统、培训客户使用系统、推动系统上线等工作就是实施工作。实施工作的重要性有点象足球比赛的“临门一脚”，前面所有工作都做好了，如果临门一脚特别臭，前面的工作都会付诸一炬。实际上实施工作需要从项目一开始就要进行，并且对实施工程师的要求很高，除了技术要求，还有业务以及商务上的技能要求！


 


说明：


这是“挨踢项目求生法则”系列文章，之前已经为大家分享了战略篇、团队建设篇、需求篇、设计篇、编码篇、测试篇，这篇是实施篇。


什么叫挨踢项目？


IT项目，特别是软件开发项目，都属于“挨踢”项目的范畴。挨踢项目的几大特点：
1.需求不确定。
2.技术不确定。
3.工期限死。
4.预算限死
两大不确定和两大限死，你想不“挨踢”都难！


 


什么是实施工作？


实施工作内容主要有：


1）安装系统，包括整治网络环境、安装数据库、安装程序等一系列工作；
2）培训客户使用系统，解答用户使用中的问题，推动系统上线；
3）推动验收；
4）反馈客户对系统的意见给项目组。


看上去实施工作似乎是项目后期的工作，但实施工作其实是需要从项目一开始就要准备的，以下工作需要前期就做好：


1）熟悉客户业务，熟悉需求；
2）了解客户的IT环境，根据系统的要求提出整治要求，并帮助客户做好准备；
3）编写用户文档，通常至少包含两种文档：一种是给一般用户使用的，一种是给系统管理员使用的。
4）编写实施计划，准备实施环境进行演练；
5）熟悉客户各层次的关键人物，和他们搞好关系，为后续工作做好准备。


 


实施工作需要具备的技能


要完成上述工作，实施工程师需要具备以下的技能：


1）熟悉网络、操作系统和数据库；
2）熟悉客户业务，熟悉需求；
3）能和客户沟通和保持良好关系的技能；
4）需要有一定的商务触觉。


 


不要“歧视”实施工作


我曾经“歧视”过实施工程师，甚至认为不需要专职的岗位，开发人员或者是项目经理亲自去实施就可以了。


我“歧视”的原因有：


1）当时的实施工程师技能比较欠缺，经常还装不上系统，需要开发去支援；
2）当时的实施工程师对业务不熟悉，需求不了解，客户很多问题不会回答，不会“顶”回一些问题，只会做客户的“传声筒”；
3）当时的实施工程师学习的动力不大，没有意愿去改善业务水平。


实施工作其实相当重要，下面开始为你分享一些求生法则，希望对你有帮助。
 
法则1：实施的首要工作是推动验收


实施工作的首要目标是推动验收，安装程序、培训客户等等这些仅仅是手段，最终目的就是要验收！


通常合同中规定的付款方式是这样的：


1）合同签订后给一笔头款，通常占合同总金额的20-30%；
2）验收后付款合同总金额的60-70%；
3）维护期后给合同总金额的10-20%。


付款大头就是验收后的那笔付款，所以推动验收是实施工作的首要目标！你要这样看待这个工作：如果不能验收，你将没有60-70%的工资！这样你就会足够重视实施工作了。当然推动验收这个工作通常要和负责商务的同事一起来做的。


 


法则2：验收除了搞定甲方老板还需要搞定业务骨干


案例：验收失败


某项目甲乙双方老板很熟，验收之前乙方老板已经做了很多工作，甲方老板也表示验收没有问题。于是验收大会上，甲方老板一开始就定了基调：验收是可以通过的，有问题可以记录下来，验收后继续跟进。于是甲方老板问大家的意见，结果“惊喜”来了。由于事先的实施工作不到位，出现了以下状况：


1）设备没有采购都到位，大部分人还没有用过这个系统；
2）某业务骨干已经用了该系统，但他反馈的意见乙方没有重视，该业务骨干表示该系统无法验收。


乙方老板没想到是这样的一种情况，也觉得相当不好意思和丢面子，甲方老板也很不满，你不能这样忽悠老子验收啊！


所以结果你懂的，验收自然没有通过，乙方还需要再付出更多的工作才能搞定这个事情。


这个是真实个案，验收是需要大小Boss通吃的，固然要搞定大Boss，也需要搞定小Boss！


大Boss是需要下面的人工作的，他手下哪些人能干活、哪些人不能干活，他自然很清楚，所以如果他手下的业务骨干认为系统不可用、不能验收，他自然也不会同意验收。


 


法则3：一定要避免“一失足成千古恨”的错误


悲惨案例1：数据库数据被删除


某项目要安装一个小版本，对客户的原有版本进行了升级。本来以为是一个小事一桩，但升级后客户说见不到数据了，我们查看数据库，发现数据库中的一些表的记录全部没有了！检查后发现，我们的开发人员去做数据库升级的时候，犯下了超级低级的错误，居然直接用SQL Server自动生成的SQL去升级，而且居然还不去看一下这些SQL语句，哪怕是去看一眼。SQL Server自动生成的SQL是很坑爹的，它首先检查有没有这个表，有的话就Drop掉，然后重新建表，这样当然就删掉了很多记录了。本来这个悲剧的事情是有挽救的机会的，我们规定所有的升级工作之前要备份数据库，无奈我们一直无视这个规定，一直贪方便不备份数据库。


悲惨案例2：格式化客户服务器的硬盘


某客户服务器出问题，找我们去解决问题，实施工程师检查后决定用“绝招”——重装系统！实施工程师问客户：格掉C盘有没有问题？C盘有没有东西要备份？客户说：没有！实施工程师又再次确认：格调后数据都会丢失，不能恢复的，确认没有东西要备份？客户说：没有！于是C盘被格掉，系统重装了，问题解决了。但几天后，另外一个客户说：C盘的某些数据怎么没有了？后来客户的大Boss自然就来追究我们责任了，而之前一直说可以格掉C盘的客户就没有吭过声，而我们又不能“捅”他出来。


实施工作中会有升级数据库、格式化硬盘等“危险性”动作，做这些工作之前一定要做足备份。哪怕我们之前的工作做得很好，客户关系搞得很好，万一不小心干了无法挽救的错事，例如：删掉了客户几年来的数据又不能恢复、干掉了客户有重要数据的硬盘而没有备份等，这些都会直接导致灾难性的后果。


 


法则4：用户文档要同步交付


通常系统好不容易按期发布了，但用户文档是不会同步发布的，因为根本就没有时间去做这个事情。


但我们的要求是用户文档必须同步发布！这样的要求是因为：


1）用户文档是推动验收的有力工具；
2）用户文档可以降低服务工作量（参见下一条法则）。


 


法则5：用户文档是为了降低服务工作量


某电视机的说明书是这样写的：按什么菜单，弹出什么窗口，按“确定”按钮确定，按“取消”按钮取消……


看了等于没看，这样的说明书写了等于没写，不如不写！


应该写怎样的用户文档呢？


通常的写法是按照功能点一个一个的讲解，这些的写法是没有什么实质性用途的。要从客户的角度，业务的角度来写，通常要针对客户的不同用户群，模拟不同的角色的日常工作环境，告诉他要完成你的某项工作，你要怎样使用这个系统。不需要写“按确定按钮确定，按取消按钮取消”之类的废话，客户不是傻滴。


另外一个重要的用户文档就是管理员手册，要针对客户管理员的水平，写他能看懂能操作的文档，管理员手册通常写得内容是如何安装、调试、备份系统，通常需要写得比较傻瓜化，要有很多截图，要一步一步来写。


客户不喜欢看用户文档，就喜欢找我们，咋办？


我们首先保证用户文档的质量，然后就是要引导客户多看文档，让客户遇到问题第一反应是看文档，仍然不懂才找我们。


写用户文档不是为了要和软件配套，不是为门面好看，而是有“阴谋”的，就是降低我们的工作量！用户文档的方式可以是Word文档、打印出来的手册、在线帮助、视频等。


 


法则6：培训要有针对性


技术人员做培训，最容易犯的毛病就是从技术人员的角度来讲解，结果让大家听到一头雾水。我以前就经常这样干，而且还以为自己很牛B，你们听不懂是因为你们不懂技术！


给客户培训系统，目的就是让客户尽快上手，然后方便验收。通常这样的培训要分几次：


1）第一次培训：这次培训通常叫启动大会之类的名字，客户最高领导会参与，中层领导也会参与，然后是大量的基层员工。


我曾经也在类似的大会上做过这样的培训，效果不是很好；后面我总结出这样的大会，你的主要目标就是让客户的高层领导满意，你不需要面面俱到，你需要重点介绍：


a）系统的愿景和目标；
b）高层领导需要用到系统什么功能，能帮助他实现什么业务价值；
c）用户的其他关键角色需要用到系统什么功能，能帮助他实现什么业务价值。


2）后续的多次培训：这些培训通常是针对特定的受众的，例如：分别为不同的部门讲解如何使用这个系统，这个时候的培训就需要讲得比较细了。


培训可能是推动客户使用系统的最节省工作量的方法。要让客户几百人都用上这个系统，一对一手把手教肯定不行，我们需要有策略的培训，同时要注意培养客户的内部讲师，让他们可以内部进行分享。


 


法则7：降低差旅标准并不能降低实施成本


某公司为了节省实施成本，降低了实施工程师的差旅标准，原来可以坐飞机的改成坐火车，原来可以住3星酒店的改为2星……


实施工作通常要出差，出差工作诸多不方便，其实是挺辛苦的，如果再来一些”不人道“的差旅标准，对士气打击其实相当大，其实一点都不能节省成本！


降低实施成本的最有效办法是：


1）规划好实施工作，保证每次实施都有效果。
2）不要随传随到，每次实施之前都要和客户做好沟通，让客户做好准备。
3）用尽量少的实施次数和时间来达到验收这个目的。


对实施人员的差旅待遇要好一点，当然不是非要要求住5星级酒店，但至少要给多一些的人文关怀，让实施工程师安心和放心了，每次的工作效果自然更好，这样就会减少实施次数，节省更多成本。


 


法则8：“挨义气”做的事情一定要讲清楚


客户电话过来说：你们昨天安装系统，搞坏了我们的系统，快来看看！


我们吓一大跳，跑去一看，原来不关我们事，昨天动过这个服务器的还有其他人，但是我们还是帮助客户修复了问题。


上述仅仅是一个小个案，我们常常会帮客户做一些合同以外的事情，但客户并不一定知道这些是合同以外的事情，如果我们不加说明，久而久之，客户就会认为这是”理所当然“的事情。所以一定要说明，最好一开始就说明，并且每隔一段时间来一个汇总，说明我们干了哪些”挨义气“的事情。我们干的这些”挨义气“事情，要事先请示我们的老板，并且要报告我们的完成情况。从我们的角度看来，我们干这些”挨义气“的事情就是为了不得罪客户，维持客户关系，但从我们老板的角度看来，我们干这些事情是他和客户老板谈判的筹码。


 


法则9：最好设置专职的实施岗位


我曾经反对设置专职的实施岗位，我认为这个事情让开发人员“顺便”干了就行了。但后来体会到实施工作没有这么简单，对实施工程师的要求也很高，设立专职是必要的，而且效果更好。看看上文列出来的实施工程师需要掌握的几个技能，和客户沟通的能力、商务触觉这两点，一般开发人员是很难具备的。另外实施工作其实工作量挺大的，如果有专职的实施工程师，可以让开发人员更加专注开发工作。


但刚开始设立实施岗位的时候，很可能会出现“阵痛”，总体工作量更高。当时我们实施部刚刚成立不久，但部门项目组不喜欢找实施部来实施，他们说还不如开发人员直接实施了，这样更加节省时间，因为实施部的人不具备相应的技能。而实施部的头反驳说：1）实施部一直等待项目组的召唤，并且一开始就打招呼了；2）实施部的同事具备相应的技能。这样公司出现了开发部门忙死，实施部很闲的情况，而两个部门还在PK。


要尽快完成这个过渡，我们需要：


1）无论是开发部还是实施部，都需要理解实施工作的重要性和难度；
2）所有人都需要理解为什么要设立实施部，这个部门会降低开发部的工作量，并且更加有利于推动项目验收。
3）前期需要开发部的同事多帮助实施部提升水平，而实施部的同事需要严格要求自己，尽快进步。


 


法则10：实施工作需要贯穿项目整个过程


这个法则我放到最后再说，看了上述法则后，相信你对实施工作应该有新的认识了，所以实施不是最后才做的工作，一开始就需要准备，并且贯穿整个过程。


 


实施工程师的职业发展建议


我曾经招聘过实施工程师，我必须思考这个岗位的职业发展路线，帮每一位应聘者“画一个饼”。


这个岗位有三个比较好的发展路线，供你参考：


1）往销售和市场的方向发展。


实施工作帮助你沉淀了技术知识和业务知识，锻炼了你和客户相处的能力，为你成为超级销售打下了基础。从打工的角度看，可能销售这个职位是最赚钱的，当然这个职位是高风险高收入的，但你的实施工作积累会大大地降低你的风险。


2）往项目经理方向发展。


3）往产品经理的方向发展。


 


小结：


实施工作是高技术含量的工作，是需要和客户相处的工作，是需要商务触觉的工作。


作为项目管理者的你，希望本文能对你改善项目工作带来一些帮助；如果你是实施工程师，那么本文特别是职业发展建议部分希望能对你有一点点小帮助。