挨踢项目求生法则——实施篇
摘要:
安装部署系统、培训客户使用系统、推动系统上线等工作就是实施工作。实施工作的重要性有点象足球比赛的“临门一脚”,前面所有工作都做好了,如果临门一脚特别臭,前面的工作都会付诸一炬。实际上实施工作需要从项目一开始就要进行,并且对实施工程师的要求很高,除了技术要求,还有业务以及商务上的技能要求!
说明:
这是“挨踢项目求生法则”系列文章,之前已经为大家分享了战略篇、团队建设篇、需求篇、设计篇、编码篇、测试篇,这篇是实施篇。
什么叫挨踢项目?
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)往产品经理的方向发展。