zoukankan      html  css  js  c++  java
  • 挨踢项目求生法则——实施篇,避免”一失足成千古恨“!




    摘要:


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


     


    说明:


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


    什么叫挨踢项目?


    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)往产品经理的方向发展。


     


    小结:


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


    作为项目管理者的你,希望本文能对你改善项目工作带来一些帮助;如果你是实施工程师,那么本文特别是职业发展建议部分希望能对你有一点点小帮助。
  • 相关阅读:
    iOS 成员变量和属性的区别
    程序如何在RAM ROM运行,内存分配与分区
    iOS CGAffineTransform你了解多少?
    iOS配置字符表,查看Crash
    苹果开发账号过期不续费会怎样?
    iOS蓝牙接收外设数据自动中断
    数据结构简述
    antd按需加载,配置babel-plugin-import插件,编译后报错.bezierEasingMixin()解决方案
    docker 启动 nginx 服务
    安装docker
  • 原文地址:https://www.cnblogs.com/baiduligang/p/4247290.html
Copyright © 2011-2022 走看看