[转]走出软件作坊:三五个人十来条枪 如何成为开发正规军(二)

本文转自:http://blog.csdn.net/david_lv/article/details/2461329

 

上一次,写了一篇文章《三五个人十来条枪 如何走出软件作坊成为开发正规军》,反响异常激烈。

我的一个朋友也看到了我的博文,他是做某个行业企业管理软件的。他说:你这个方法,在我从事的行业不适用。

我对他从事的那个信息化的行业还是有一定了解的。

他们的实施模式是:

1一个实施项目,大约50万的签单额,做完验收后给最后的20%-30%的尾款。

2他们是一家小公司,为了多做项目多赚钱(企业都希望利润保持的很高,如果毛利低,做软件就不合适了,受的苦和压力和不规律性比其他行业多的多),所以一个项目只派一个人去,而这个人需要培训、辅助导入旧系统数据、清洗合并数据、规范化数据、报表制作、需求协调、推动切换上线、现场运行监控、个性化定制修改代码。

3如果不能推动客户上线,就无法验收结项。不结项,就无法去追尾款。

4一个项目这个人,身兼项目经理、开发员、需求调研、软件设计、功能测试、实施培训、定制化开发,还有时候写培训文档。因为公司里都是这样的人,根本没有分工出专门的文档人员,所以产品根本没有培训手册和帮助手册。除非客户必须要,这个项目的这个人才写一份草稿应付。而公司又没有人来做文档管理工作,所以各个项目各个人写,也没有人合并,也没有人来统一收集。每个文档都在项目每个人的移动硬盘里。

5由于项目就老哥一个人全活儿,所以自己答应了客户修改什么需求就自己修改,根本没有啥需求调研方法和版本管理方法,就看这个老哥和客户之间的博弈了。每个项目一套源代码,而且都在各个项目的各个人手里。返回公司后,往公司的服务器上一扔做个备份。以后谁的项目出了问题或需求,就谁负责继续修改。但是,很有可能这个人已经在做其他项目了,还需要修改前几个项目的需求或BUG,还需要接听前几个项目的支持电话。如果这个老哥是在顶不住压力和焦虑而跑路了,只能把这些所有的活交给现存活的人的手里,啥也没有。无法交接也得交接,反正人要跳槽。

6由于每个人都是这样一人挡一摊或数摊项目,而且项目周期长,每个项目都需要2-3个月的时间。老板也想把公司做大,但是每个项目能去实施的人,要求都非常的高,新人来了一年也上不了前线干不了活。所以,对招新人也是不愿意招,干花钱没见起作用,小公司培养不起人。而对项目游刃有余的人,都是跑单帮跑惯了,带着个新人,还干不了活,还浪费出差费用,真是气死人了,还不如自己亲自动手三下五除二搞定爽。

于是,公司五六年了也就那么大规模,老板员工都干的很辛苦,当然老板得到的钱要多一些,赚个500多万没啥问题,自己后半辈子算是有靠了。所以,老板也得过且过,反正现在赚钱速度已经比较满足了,这样也熟练习惯了,经验路径依赖,就这样顺坡下驴做吧。

我的朋友是个理想和现实总是不断冲突的人。一方面,他确实想把项目做的很是顺畅,另一方面,他却觉得一切都像是被各种因素牵扯,根本无法转变模式,于是只能认命继续现在。

我说,你这种情况其实在中国很普遍。中国大部分软件公司都是从事行业信息化,因为这块技术难度最低,而且只要有人脉关系就可以做销售开干。而很多软件公司的成立,就是由于老板有一个关系,接到了某个项目,于是拉住了某个客户,小活不断,于是成立了公司。这是很多老板成立公司的原因。既然这类公司成立就没有目标,其目的就是认识几个人多拉一些项目多赚一些钱,所以如何复制模式,他们其实关注性也不大。原因很明白,就是自己不认识的客户,要想打入这个单子,很难,每个客户庙前都有N多关系户。对于自己有关系的客户,也就那么多个,有多大关系就能做多大的摊子,那就尽量从现有客户中持续做项目。维护好客户关系是最重要的。这类模式非常常见,并不是你这个行业特殊。

老板的生活已经趋向于小康稳定,而你呢?你还在挣工资。你也在一线客户那里天天呆着,要么你把老板的客户抢过来你做,要么为了你自己工作能轻快些,你必须自己给自己找方法。

我的朋友说,抢过来不可能。自己虽然天天在第一线和客户天天在一起,关系也处的不错。但现在人先认的是钱,后认的是感情。而老板给他们这帮人都持续吃喝玩乐送东西分回扣,自己只是一个干苦力的。自己只能找方法。但你说的方法是针对一个公司的变革,不是针对我个人而言的,所以不适用。我想有一个方法能帮助我自己的方法,你帮我想想。

我想了想我过去写过的文章,确实是,自己一直从事职业经理人操盘产品研发管理,也统管咨询、实施、培训、支持,但都是在公司管理的层面上看问题分析问题解决问题,而没有从一个个体上去思考。而中国,大量像我这样的朋友,他们需要帮助,而我写的却是公司层面的,无法帮助他们,所以他们老说我的文章空洞、理想。

我说,咱们俩一起分析解决。也是给大量像我朋友这样辛苦的人带个福音。

咱们首先先说一下你想达到什么效果。

我朋友说:我现在在这里待的很烦,出差时间太长了,我就想早点回家。

那你什么地方费时间了,需要2-3个月在客户现场?

我朋友说: 嗯,我看完你的那篇文章,我也做了一下反思和总结。我感觉有三个方面特别费时间:客户需求,数据准备,报表制作。

一去客户那里,你是见不到客户老板的,也是看不到用户的,你主要面对的是客户信息科的人。他们一开始要求你先做演示,看看是否符合他们本企业使用。在这个演示过程中,就不断提出需求让你修改。而且,你不修改完,他们没法接受你以下的演示,说想象不出后来的样子,对着你画的界面图想象以后的功能变化,有点纸上谈兵的感觉。而且,往往演示的时候必须信息科科长在,否则底下的科员都做不了主,演示了也是白演示。而信息科科长却老不在。而他们上班时间也极为规律,该下班时立马下班,根本不加班。所以边演示变修改再边演示。好容易修改完了,也演示完了,时间一俩个星期就过去了。

信息科算是通过了,就需要录入基础数据了。问题又来了。现在大部门企业都已经上过一套软件了,可能是Foxpro的,也可能是PB的。人家要求你把数据倒进新系统中,但是一看过去的数据,都乱七八糟的,过去上线都是没经验,后来也用的乱了,积腋成疾了。现在要导入,真是要把垃圾输入,得出来的也是垃圾。你苦口婆心的说服让他们重新录入,但是他们一看都好几千条,不想录入,让你能导多少导多少,然后在基础上再维护。这一松口不要紧,你不仅忙活了一个多星期写各种SQL导数据,而且往往旧系统也没有文档,数据结构需要你自己理解,理解有误也是你的事。好容易导完了,再维护,发现数据是通过SQL导入的,在界面上却不能维护,因为很多校验都是写死在程序里的,而不是约束在数据库。磕磕碰碰,自己边后台修改数据,边让他们信息科维护。他们信息科首先先检验导进去的数据对不对,没有填写齐的字段填写齐。然后把没有导进去的数据录入进去。然后再打印出来,统一对一遍,看看哪些数据录入的有错误。这样折腾,一个月,22天工作日就过去了,用户还没培训呢。

第二个月开始用户培训了,但一培训就发现了问题。用户的需求和信息科所的需求,根本不是一码事。原来一个企业,信息科也和业务科室是两张皮,就和在软件公司一样,开发部和销售部是两张皮。于是,用户和信息科开始吵架,各说各的道理,谁都在维护自己的利益。而且用户部门有业务在身,也不可能天天大部分时间泡在IT讨论上面,开会不来人,或者要来人也来了个小兵充数,根本起不了决定,还提自己的意见,过几天开会,用户部门的主任来开会,又把需求再推翻。业务部门主任是站在主任的层次上看IT管理, 而业务部门科员是站在自己轻松使用的角度上提需求,而信息科是为了自己以后维护着想。不断的讨论不断的推翻不断的扯皮。

讨论扯皮推翻再讨论再修改。终于消停了。开始培训了。但问题来了,用户上机一操作,发现基础数据很多不是平常现实那样的。计算机数据过去就和现实数据脱离了,现在想借新系统上线再回到计算机管理上。于是,一边培训一边修改数据,有人报告数据错误就修改。而培训没有文档,培训也没有课程,培训也没有专业训练。培训如何层层开展,培训如何组织,都不知道。反正就老哥一个被订在这里了,只能这么上手了。人没有来齐,也得开始。等来了再重新讲一次。一次不会,再讲一次。有人年龄大打字不熟练,有人看不清屏幕,需要调整大字。一调整,界面发生错位了。有人不会用鼠标双击和单击,有人不会控制打印机。过去是UCDOS系统,还没用过WINDOWS的,用不惯。从基础培训起吧。否则怎么办呢?人家不上线用起来,人家不给验收结项啊,尾款回不来啊。

用户也培训完了,该上线了,就需要初始化库存了。先得现实盘点,然后再录入计算机,还必须一边得继续营业。于是,真实库存和计算机库存肯定对不上去。由于品种太多,所以只能一批批盘点一批批录入。

由于操作不熟练,特殊业务不知道如何处理,只能瞎处理。处理完后发现不对,想冲抵回去。没有冲抵功能,只能修改数据库中的数据。

由于前期修改,根本没有测试,就是老哥自己一个人改。改完了有时候烦了连自己都不想测试。于是上线用着用着就不能运行了,需要当时就立即修改,中午晚上的连续作战紧急解决,否则第二天一早还需要开门迎客。

好容易业务录入了,但是报表不对。一检查,原来是前段时间录入的非法业务数据造成,功能没想到没拦住。怎么办?偷偷自己修改数据,然后使报表平账。过段时间,发现报表又不平了,发现还是非法数据进入造成。怎么进来的呢?想不明白。只好蹲点现场,直到客户都运行正常了才能走人,算是上线成功。

这个累呀,两三个月都是紧着过的。好不容易回来休息会,另一个项目就要启动了,就这么几头能干活的蒜,老板笑着脸让你去。于是,遭遇再次上演,日子就是这么过来了,一月又一月,一年又一年。顶不住的就跑路。

我听完了我的朋友的诉苦。我说咱们一件件事情的排查。

第一件事,边演示边修改,还得信息科长在,还得他拍板。这段时间的浪费如入缩短。我过去也作过灯塔客户的实施,我过去一去了客户那里,并没有一开始就这么做。我先是调研此次项目组的人员构成、能力、职责、上线时间、用户计算机能力、用户部门对上一套系统的最突出的抱怨,信息科对上一套系统的最突出的抱怨,现在还有哪些系统在持续运行,上一套系统用户部门和信息科觉得哪里好,上一套系统的功能结构和操作流程。这样,我就确定了我该如何开展项目实施。这就是项目调研阶段。人往往很眷恋自己已经习惯的事情。而且人的想法,人的能力,各个部门的利益冲突,人和人的私人关系和恩怨,都有助于项目的推进。亚洲人做事,需要面上的和面下的都得下功夫。纯粹都是正式的或者都是不正规的,都无法做好一个项目。我会在项目调研后,重新建议项目组人员构成、职责、流程、项目阶段时间、各方面负责人、本项目的最突出要解决的前5个目标问题。

人常说,上下同欲者胜,庙算者胜。你一开始必须界定好项目的边界和目标和执行标准和责任人,否则大家谁都想管或者谁都不管,大家没有目标,或者大家各有各的目标,肯定无法项目很好的推进。

有了目标,责任人、标准、时间计划,就要按照这个目标来分解做。基础数据的校验,需要用户参与先来校验原有系统的数据。不要认为用户现有这套系统就没有问题。如果没有问题,企业也不会用你这套来代替他现有这套。所以校验现有基础数据很有必要。没有的数据,先让他们做准备,但你要书面把要准备的规范写好交给要参与的各个用户,而且要做好培训工作,不能讲讲就认为他们理解了。有了的数据,需要校验。地基打好,才能上面很快盖房子。而且,信息科和用户对老系统很熟悉,校验数据比你快的多,而且准确的多。只有经过他们的确认,你可以导数据,也可以不负责导数据。其实,基础数据,虽然多,但只要有5-10个人,2-3天就能录入完毕。比你导更快更准确。

在用户嚷嚷需求的时候,一定要以系统目标为约束。因为每个人看法不一样,站的利益角度不一样,每个人的计算机应用水平也不一样,所以每个人都有看法。你让百家争鸣,而且什么需求都可以提,没有目标没有边界,就让你一个人修改,那么你结果不会好而且你会心身疲惫,你会很快就厌烦了项目。吃力不讨好,就是方法不对。需求,一定要围绕时间阶段和目标为约束,大家要一个目标。

还有你刚才讲到的没有培训方法、培训文档、培训素质,说明必须要有专人来做培训。这块是项目实施非常重要而且工作量大的一块。这才是真正的项目实施。项目实施不是让你来修改需求来了。培训做不好,上线会出一堆麻烦,软件再约束不强,报表就是平不了。而培养一个培训的人员还是容易的。如果想培养一个会协调推进来事的、会修改软件的、懂得业务需求的、会SQL语句导数的、会培训的,这样的专业神人确实很难。而且这样的神人一定不专业。所以,要带人,先要让他搞培训,而且让他编写针对不同用户的培训手册,有培训时间课程、培训规范、考试考核、模拟练习环境、模拟数据。这是这个培训专员可以做到的。

软件修改,尤其项目型软件,不修改是不太可能的。我不赞成在客户处修改软件。因为不仅仅你只会以事论事的修改,容易陷入到这家客户具体的需求中,而不会考虑其他客户的需求兼容,所以你修改的软件有很大局限性,最后形成只能一家维护一套代码,最后客户越多越累成本越高越不赚钱,被客户多而拖累死。而且你在现场那么多事情,那么多人打扰,你根本无心踏实下来修改软件,只想着赶快改完上线回家,你急躁,潦草,应付,软件质量就没法保证了。你想改变这种现状,你必须把需求整理好,交给在家里专门编写代码的程序员。你在现场,你也很懂业务,你和你本公司的程序员沟通肯定比客户沟通要顺畅的多。

这样,你在现场,你的任务就是当好一个项目经理,专门协调,控制,理顺,制定流程、规范、目标、时间,保证执行到位。现场还有培训专员分担你的培训工作,可以帮助你校验数据,测试功能。公司里还有专门coding的程序员分担你的开发测试工作,而且人家写的代码更加多家客户兼容使用,而且质量稳定性比你高。

只有专业分工合作,才能转成正规军。否则,你只能把自己熬倒了,心力交瘁,最后心灰意冷,跳槽而走。

从民兵,到武工队,到土八路,到正规军。这条路有好几个阶段。不能想着一步到位。现实情况也不容许我们一步到位。我们只能是能改进什么就改进什么,天天进步一点,我们就会大变样。

如果从心里就认为不可更改,直到心冷不想改进,那么我们永远不会进步。

为了我们自己心身愉快,我们也要进步。

记住,你是项目经理。你是这个项目的领头人。你决定这个项目的成败。

如果你连这个定位都没有,那么你什么都决定不了,你这个项目的成败只能随波逐流,那样你真的很失败了,你什么作用都没有,要你干吗

 

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
内容简介   《IT项目管理那些事儿》采用叙事的风格,通过11篇来自一线项目经理的实际经历的文章,分享项目经理人自身的实践和经验的案例,阐述项目管理的实施过程、项目经理的成长和团队成员的培养历程,从而和读者达到共鸣并跟随作者叙事的脉动,以从中得以进一步的思索和升华。   简而言之,通过感受项目经理人的喜怒哀乐、经验教训,达到“它山之石可以攻玉”的目的。   《IT项目管理那些事儿》适合软件工程师、测试工程师、项目经理、IT经理人阅读。 第一篇 项目篇 第1章 中小型民营IT企业项目管理手记 1.1 项目管理是什么 1.2 背景介绍 1.2.1 个人背景 1.2.2 公司背景 1.2.3 项目背景 1.3 软件工程 1.3.1 系统概述 1.3.2 系统规划 1.3.3 系统需求 1.3.4 系统设计 1.3.5 系统开发 1.3.6 系统测试 1.3.7 系统部署 1.3.8 系统验收 1.4 之后的事情 1.5 项目经理感悟 1.5.1 大中小型项目管理的区别 1.5.2 系统架构 1.5.3 风险管理 1.5.4 沟通管理 1.5.5 时间、成本、范围和质量的平衡艺术 1.5.6 项目经理自身学习的加强 1.5.7 政治问题 1.6 民营企业IT项目管理之路 1.6.1 完善企业管理基本制度 1.6.2 领导者的学习 1.6.3 建立PMO组织 1.6.4 构建专业的IT项目管理制度 1.7 小结 第2章 电信行业应用软件项目管理案例 2.1 项目背景 2.2 项目阶段定义 2.3 项目第一阶段 2.3.1 软件设计 2.3.2 项目团队 2.4 项目第阶段 2.4.1 需求工程与需求管理 2.4.2 项目计划与跟踪 2.4.3 项目风险管理 2.4.4 项目流程规范 2.5 项目第三阶段 2.5.1 割接的技术准备 2.5.2 割接的组织与保障 2.6 反思与总结 2.6.1 另一种选择 2.6.2 项目经理的成长 2.6.3 对组织级项目管理的期望 第3章 说说银行项目那些事儿 3.1 引子 3.2 知己知彼,百战不殆 3.2.1 银行的基本背景 3.2.2 银行系统的特点 3.2.3 银行项目的特点 3.3 准备行动 3.3.1 项目的前期调研 3.3.2 前期调研的成果 3.3.3 项目成员的物色 3.3.4 项目成员的安排 …… 第3章 说说银行项目那些事儿 第4章 软件外包项目的项目管理和快速开发篇 组织篇 第5章 IT企业PMO工作实践 第6章 小型软件企业CMMI评估实战 第7章 项目管理体系之形成与演变 第三篇 支持篇 第8章 IT项目经理的修炼 第9章 一家互联网公司的项目管理进化史 第10章 如何带好80后研发团队 第11章 项目管理之兵者诡道

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值