秋叶上班记之三十二—第一个实施软件项目:武汉凯迪电力CAPP/BOM项目
(2012-09-03 15:06:52)
标签:
教育 |
2001年2月初的时候,我终于接到部门给我安排的第一个项目,负责武汉凯迪电力下属一个制造厂的CAPP和BOM 项目(要说明的是BOM是当时开目公司发展的一个汇总各种明细报表的软件,定制复杂报表格式和汇总规则的能力非常强,而且是用自然语言逻辑完成汇总规则和CAD绘图工具完成制表和定义,非常方便。)
从我进来开目到接到项目整整三个半月过去了,中间有一个春节不算,也有三个月了,在当时人力资源紧张的情况下,也是一个个案或特例。
但给我的这个项目并不是个好项目,为什么这么说呢:
第一这个项目总金额非常低。
我们当时帮企业汇总一张复杂的材料定额表要收费5000,但我这个项目要汇总图样目录,通用件明细表,标准件表,产品明细表,材料消耗定额表,工艺定额路线表,工艺文件目录一系列的表,这些表里面象材料消耗定额表,工艺定额路线表都需要详细调研企业的定额计算公式,需要花费很多时间和精力,因此这样的一张表收5000,而且这个企业的通用件汇总和其他企业要求不同,有很多归类和排序的小要求,非常复杂,事实上最后是这个看起来最简单的通用件表花费了我最多的配置时间。而且我这个项目除了BOM还有CAPP软件的实施,成交实际总价格是其它类似项目的1/5,这样的话项目做下来人累得要死,却没有提成。
第二这个项目不是标准项目,存在大量开发点。
这样一个低价格的项目我看其它同事做的初步需求,和企业协商了一轮后还是给公司提出了七个必须实现的功能,这些功能都是软件无法实现的,而公司肯定不会优先响应这样的一个小项目的需求,项目看起来陷入了僵局。因此这个项目分派给一个老员工后,老员工以精力管不过来的理由转给我做。
不过当时我完全没有意思到这些,我反而是很高兴的接受了这个任务,现在想一想当时部门领导和老员工看到我如此勇敢,心情一定很愉快。换了现在谁要甩这样的项目给我,我一定会很圆滑的拒绝,呵呵!
我之所以很高兴接受这个项目有两个原因,第一这个项目在武汉,我就不用出差,我当时对一个人出差外地做项目还是有些不安的,而且当时和老婆刚结婚生活上很多事情在调整,需要在武汉稳定上一阵子班;第二我在部门是唯一一个没有项目的人,在实施部这太反常了,有一个项目证明自己,当然好,我当时压根不在乎提成,关键是别人做不好的我能做到,还怕领导不承认你?(实际上我把这个项目做完了才晓得我在武汉市内做项目也可以报销公交车费,但我这个人一向嫌麻烦,武汉公交车也未必总有票,每天为2块钱去报销走一堆流程没必要,我后来报都没有报)。
项目来了,就要开始做,我当时只会操作CAPP软件,但CAPP项目该如何进行我并不清楚,于是就请教把项目转给我的老员工,这里还要感谢他配合,告诉我先把商务方面合同技术协议看一遍,然后找商务人员了解情况,然后让商务带你去见一见企业负责人,约时间上门开始调研,调研后确认需求就可以做配置,配置做好了家里验证通过后就可以去现场测试,如果一切顺利就要签个项目验收表,可以回家通知商务去回款,你就可以拿提成啦。当时老大哥讲完拍着我的肩膀:“好好干,这个项目提成我全部让给你了!”
这个项目前期已经做过需求调研,资料也收集得很细致,我的工作安排是先根据需求写一个技术方案,说明这些表如何配置,然后去现场给企业用。
我自己也没有头绪,就写了一个工作提纲:
1、先确认全部已有资料全部在我手上并看过,对项目有初步认识,和公司涉及项目相关人员做过沟通
2、确认企业CAPP和BOM表格之间的数据信息流,画出流程图(从哪个时候我才开始涉及画数据流和信息流图,原来很少真正的画过)
3、确认每张要汇总或配置的表格的输入输出和约束条件,对数据库的要求,企业的个性要求,形成详细配置技术方案(我觉得做项目把关键环节形成文字的习惯很重要,将来遇到问题才可能被追溯,否则不出问题还好,一出问题就不晓得从哪里查)
4、确认项目中无法解决的技术难点,和业务重点表格(一定要先解决)
5、形成可行的解决方案(当时对一些难点如何解决也没思路,但相信路是人走出来的,车到山前必有路)
6、规划测试方案,测试通过去现场测试(这个测试方案设计很重要,非常体现个人经验,如果能够在公司系统完整测试,在现场就问题少,效率高,用户满意度高,如果在现场反复调整还不能解决问题,这样的公司内部测试会让用户失去信心)
提纲出来了,项目是有时间压力驱动的,我就很快投入到配置工作中,有项目压力人学技术也确实特别快,当时也没有其他想法,就是一张表一张表配,配置出来测试通过再配下一张表,这样就可以尽早配完去现场验证了。
说实话,如果是现在我一定会先去企业做个沟通,把每张表思路拿出来后和企业懂的人一一谈过再去做配置,加上这个一个需求和技术方案确认阶段,一定可以避免很多无用功的情况,甚至找到一些原来以为很难解决问题的简单新思路,当时我不懂,只知道领导让我配置我就得赶紧做,做完了去现场解决公司项目的麻烦。不过时候看来我运气不错,第一老员工的需求做得很认真,写得很仔细,和用户也确认过,我只需要按需求配置出来,也就是我在这个项目主要遇到的问题是技术问题(后来我才明白在项目中明确的技术问题都好克服,最怕的是软问题,管理问题,模糊变动的问题,而且一个项目中技术问题真的和需求调研质量紧密相关);第二我在工厂干了三年,一看需求我就明白他们要什么,不存在我理解发生偏差的问题,这个行业背景对实施顾问确实非常重要。正因为这样,我后面去现场调试配置基本上都是小问题,没有出现大的反复。
话虽这么说,但在当时技术问题也把我搞得够惨,我当时根本就不懂得去抱怨,指责产品能力不足导致我做不好项目,只是想着做不好就太没用了!
这些技术问题我当时请教了很多人,一些同事告诉我没有做过类似配置,所以也帮不了我,一些告诉我这个现在的功能做不出来,你可以提需求,但如果这样的话周期很长,这显然不是解决我这个项目问题的出路。
我当时相信总有办法的,结果我就反复看公司的技术资料和配置,当时公司软件开发了一个巨大的配置体系,没有人能全部都用过,我希望这里面有解决我问题的宝贝,最后居然所有的技术问题我都通过把软件不同功能强化,衔接和创造性应用都解决了,这个经历给我留下了很深的印象。
从此我培养每一个实施人员都希望他在确定无法解决之前能够问自己是否把功能真的用尽了,大部分业务问题都可以用20%的功能解决,还有一些就是80%不常用功能去解决,问题是你知道这80%不常用的功能吗?少一个开发就等于给公司创造了巨大的收益。
问题解决后我就去了企业,说实话我去的时候很担心,因为项目等我去的时候已经离原来的约定计划延期了一个月多,到了企业,企业反而很客气,和我约定上班时间,他们8点,我只需要8点半,然后中午管饭,就在食堂(当时很高兴,不管伙食如何,不用自己掏钱了,这样我当时每个月1400多的工资就松一点了),然后给我一台电脑做配置,当时出差没有笔记本,做项目就是带一个光盘,然后企业提供条件,只是催促我尽快做,看看效果。我把做出来的东西给他们看了,基本上认可,就提供实际图纸进行测试。
这个体会给我一个感觉,企业的人大部分是很讲道理的,特别是国企,他们没有必要把合作供应商搞得难看,关键是你按承诺做一些工作,即使有些技术问题说清楚都能理解,就怕你不联系不沟通不响应,这样把企业搞急了就麻烦。
一测试问题出来了,第一我当时的配置没考虑到企业图纸不规范的情况,导致定额计算出问题,例如¢的符号就有七八种;第二我当时设置的操作没考虑到企业反复操作的情况。
为了解决这个问题,我不得不和企业约定了图纸标准化规范,同时做了一些错误检查的功能,自动替换一些不符合要求的信息,减轻了企业的整理工作量。另外我又修改了配置做到无论企业怎样误操作都不会影响已经得到的正确结果。
然后我为了让企业用起来,主动把企业的基础数据库建立完整,然后一个一个培训操作,边培训边按企业需求进行修改,当时我几乎是只要是企业要求的我就答应做,唯一拒绝的就是要开发的功能。
就这样不知不觉两个月过去了,企业终于给我把项目验收了。验收的时候感觉非常好,大家都觉得做不好的项目做不了的项目我两个月就做完了,拿回了一万多回款,我两个月只用了公司3000块人力工资成本,还是赚的,而且企业对我非常认可,过了5年,这个企业当时负责配合我的一个主任离开的时候还主动联系我,问我现在在哪里忙?真是有些感动。
这两个月安装中也积累些经验,我们当时软件控件管理存在一些问题,某个软件功能可能依赖某个具体版本控件,谁也搞不清楚,做了这个项目后,我就知道出差一点要把所有的控件都带着,遇到问题一个一个测试,看哪个控件解决问题就用哪个。后来我把这个经验告诉一个老员工,他拍拍我的肩膀,说:“欢迎你正式成为实施部的一员,明白这个道理的人就可以算老员工了!”
后来公司坚决要实施CMM搞配置管理,也是被我们这些一线人员投诉搞怕了。
这次项目另外一个意外收获就是营销系统注意到我,他们很喜欢我这样的工作风格,不考虑个人得失帮他们把钱搞回来,甚至在现场的时候各种协调我自己能处理就处理了,很少麻烦他们,只叫他们两次,一次带路,一次验收,当然觉得愉快。