读后感:三五个人十来条枪 如何走出软件作坊成为开发正规军

三五个人十来条枪 如何走出软件作坊成为开发正规军

http://blog.csdn.net/david_lv/archive/2008/02/28/2127299.aspx

读后感:观察细致,问题分析深刻,一针见血。解决方案有却不够详细,操作性中下。


原文:

自从发了上一篇博文,这几天收到很多朋友的来信。

大家从各个开发语言的优缺点和适用领域,一直讨论到设计模式、框架、重构、单元测试,乃至敏捷编程,最后都讨论到了软件开发过程管理,甚至都谈到了盈利模式和中国软件

的悲哀。

最后不了了之,都觉得改善中国内地现在的软件生产状况不可能。

为什么呢?

我重新把这几天大家的讨论留言翻了一遍,发现大家的软件团队都存在着这样一种普遍现象

1大部分人所在的公司,开发人员仅3-5人,多的在10人。别看就这几条枪,还从售前支持,软件开发,测试、打包发布、文档编写、实施安装、培训、技术支持都做。
这还不算什么,而且几乎是一个人负责一个产品或一个项目,一个人从头跟到尾,而且负责多个客户的维护工作。
这还不算什么,而且随时老板会找来八竿子打不着的新活,要的还挺紧,突然要开发,打乱了所有的计划,最后都懒的按计划行事,每天撞钟,老板有事就吩咐,没事就上网,还不让听歌,当然更不让打游戏。甚至还不让看技术书籍,呵斥不干工作。只能上网装作在工作。

2老板和员工互相斗智斗勇,在年终奖、报销、出差、平时福利上啊,都明争暗斗。老板卡的紧,员工就在项目和产品上下药,还不知道是谁占了谁便宜,谁给谁打了工。

3员工一边在刻苦钻研各种开发工具,阅读源代码,学习做DEMO例子,阅读UML、设计模式、单元测试、敏捷编程等等,一边却懒的修改现在公司的产品,有问题就打补丁,客户不嚷嚷就懒的修改,代码不优化,界面不友好,架构没架构,代码不封装

但是,在讨论中,我时时都强烈感觉到,大家是想把产品开发好,把开发过程管理的井井有条,但是都心有余而力不足。阅读了N多软件工程的书籍,从重型方法到轻型方法都阅读了,但都无法把现在的开发状态一点点扭转好。

许多人想闹革命,把现在这些产品和团队都砸塌,然后重新来过,但这只是梦想,说说而已。只能希冀下一次跳槽,能找到一个好的公司,把自己平生所学全部发挥出来,但这好像也只是梦想,因为交流了一下,大家彼此的境况基本相同。

一些极端主义者自己开了公司,才发现不持家不知道油盐贵,现在自己和手下变成了老板和员工的关系,走了过去的老路。

更有一些极端主义者辞职,自己做软件,最后由于生活拮据或做做发现这个软件没什么意义,就丢弃了自己的梦想,随便找一家公司开始沉默撞钟。

一些聪明的家伙,有的入了外企,有的进了大的网游公司,有的进了外包公司,有的进了大网站公司,都是讲究大规模开发的公司,希望能找到一条中国式团队开发产品保证之路


作为小软件公司,我们真的无能为力了么?我们真的成为炮灰了么?

但是,中国软件行业大部分都是这样的公司。从每年的CSDN的程序员调查都可以看到,中国软件公司大部分都保持在这种开发团队规模,开发人员大部分都在毕业1-3年。

我们是在等待时间让人变得成熟么?我们是在等待时间让人变得技术综合实力增强么?

依笔者看,作为中国软件群体最大的小软件公司,需要的不是UML/RUP/CMM这些重型方法,不是前几年大家关注的小组开发方法,也不是敏捷编程这样的结对方法,我们都无法有这样的资源实现这样的方法。

但是,想想,星星之火可以燎原。红军能从爬雪山过草地起家,最后解放全中国。我们就没有方法?

那我们就需要想,就我们目前能拥有的权力和资源,我们如何一点点改进。我们需要的是从游击队到兄弟连,从兄弟连到正规军的方法。我们现在还处于游击队,一个队长领了一帮游兵散勇,有的人甚至没有枪还背着大刀,有的人还没杀过鬼子。

首先,要把我们自己变成兄弟连。

我常常观看国际著名的CS战队的比赛录像,他们配合的多好啊。如果他们都单兵作战,那么早就死翘翘了。这和咱们的软件开发多么相像。我们多么神往这种默契的配合,打的多么流畅。我们要的就是这个。他们也不几个人么。

那让我们来分析分析吧。

我们想好好专职的开发软件,但我们的时间都被实施安装、培训、技术支持占去了。为什么我们要做这些?是因为我们软件 没有操作说明,其他部门人都不会用。而且我们也没有培训机制,其他部门人更不会用。而且我们的软件不稳定,其他部门人都拒绝实施。由于我们软件不稳定,老 出问题,出了问题其他部门人也帮不上忙,只能我们自己去做技术支持。

从以上来看,主要矛盾就是在:操作说明、培训机制、稳定性。如何保证这三点。而且从以上来分析,稳定性是最重要的。 不稳定,你即使有操作说明和培训机制,其他部门人都躲着实施,谁想去客户那里尴尬丢脸挨骂呀。所以,其他部门人会找各种理由向老板告开发部的状,以躲避实 施,说软件太烂,根本无法拿出去。这也就是开发部往往和其他部门关系都不好,开发人员老抱怨自己就闷头辛苦开发解决问题,没有人说好,却被奸人陷害。天长 日久,积怨颇深。其实说起来,根源还在开发部自己这里。

如何保证稳定性?

大家第一想到的就是招测试人员。当然,一些公司的老板是拒绝养测试人员的。另外,如果你只想到招测试人员,其他方法不配合测试人员,即使有了测试人员,软件稳定性仍然不会有提高。所以,有一些工作,是不管有没有测试人员,都必须是我们开发人员要做的:

每个人的技术水平都参次不齐的,每个人对自己代码的负责认真性也都是不一样的,所以要想提高稳定性,必须专门从队伍 中找一个人,他作为公共代码开发员。每个产品或项目的修改需求,必须首先经过他的思考,能做成公共代码,能封装成函数,就他来做。其他的程序员只管调用函 数,实现客户UI操作和辅助功能。这个公共代码开发员必须具备以下能力:
A参与过几个主要项目的开发、实施、支持。这样,他对客户需求有综合的把握。如果队伍中没有这样的人,只有开发经理一个人有这样的经理,那么接到客户需求,分析客户需求,分解析辨是公共代码员来做还是其他开发人员来做。
B公共代码开发员具有负责认真的工作态度,代码细心严谨考虑周详异常保护做的到位内存创建释放有头有尾,代码优美,代码可阅读,代码重构,代码性能和稳定都高
C公共代码开发人员的技术能力高,知道封装成什么样的函数接口,在灵活性,以后的修改变化性上最好

应该说,找一个技术能力好的,工作认真负责的人,应该是不难找到的。而且专门做这件事,不让他参与各种杂事,他是应该能干好这件事的,而且会越做越好,这就是术有专攻。

刚才还讲到一件事,那就是开发经理要熟悉客户需求,而且是深刻理解客户需求。

客户需求,客户需求。这个让开发部最头疼的字眼。每当想起客户需求,就想起了以下这些话:
1 程序员说:这是你们家个性的需求,太邪门,我们不做。客户说:不做我们找你们老板去,我们是花钱买了你们的产品的。
2 客户说:我不会用鼠标,你给我做一个语音输入吧。我们还想要一个类似QQ的东西供我们内部沟通,你们给我们做一个吧。程序员:我晕。
3 程序员说:等你们内部斗争完,你们协调完了,我再调研需求。

似乎,我们在需求上无能为力,我们永远在追赶客户的需求,满足他们的现状,把N多家的客户需求都加进软件中,只要能实现的,我们尽量咬牙实现了。

最后,我们发现,我们的软件无比复杂,谁也不会用了,连开发部门都不会用了,谁也不知道这个需求当时为什么是这样 的。因为无比复杂,所以实施、培训、技术支持都成了问题,稳定性更成了问题。代码互相交叉,根本无法理清有多少交叉影响点。维护的程序员都快崩溃了,天天 在祈求,千万别接到客户电话,千万别接到客户电话。

这个问题终归是问题,而且是软件开发最大的问题。虽然我们也动用了这样的技巧:
1 客户业务部门不能随便提需求。必须集中汇总到客户IT部门,由客户IT部门汇总过滤完,再集中报给软件公司
2 客户IT部门的需求,必须客户方负责IT项目的老板签字才能生效,才能报给软件公司
3 不能随时报,每3个月集中报一次
4 不能口头报(即使在现场实施支持也不行),不能电话报,只能MAIL或传真来报
5 必须按我们规定的格式报,要严格写清楚需要实现的功能的界面,输入数据或输出数据,输入输出数据的格式要求,谁操作,多长时间操作一次。
6 软件上线后只能免费修改3次。以后再有需求,就必须另签合同另收费,否则不予修改。

经过这么几招,客户也疲了。需求是不提了,开发部欢呼雀跃。但我们真的做好了么?难道客户真的满意了么?客户为什么要用我们的软件?难道仅仅是为了把他们现在手工做的,然后转到计算机去做。让计算机的查询统计计算速度代替人工?

客户为什么要提这样的需求?客户要根本解决什么问题?这些问题谁来想,谁来想解决办法?

OH,My God!我们无能为力,因为我们是技术人员,我们不懂业务。

那这个问题谁来解决?

程序员苦笑了:没有人解决,也没有人能解决。客户就要,你不做他就要给老板打电话。

噢,那就让程序员的噩梦继续吧。谁也救不了你,能救你的只有你自己。

要救我们自己,必须我们自己走出我们自己。谁让我们就处在这样的处境呢?我们都想过的好,只能我们自己救我们自己。

那我们就鼓足勇气,走出来,从我们的设计模式、OO、软件工程、虚拟接口、反射、持久化、框架中走出来。开发经理来承担起客户行业研究来:
1 客户行业这个群体有多大?大中小规模各有多少家,各分布在什么省?我们面对的最佳客户是什么规模什么信息化程度的?我们的次佳客户是什么规模什么信息化程度的?
2 我们的上层竞争对手、本层的竞争对手、下层竞争对手目前的产品怎么样?他们各自的优点是什么?他们各自的缺点是什么?我们应该突出的优点是什么?我们的缺点是什么?
3 客户行业的过去5年,现在2年,未来3年的发展历史和趋势是什么?他们面临哪些挑战和机遇?
4 我们现在所做的典型客户,他们的组织结构,人员规模,每个岗位每日业务流程、每个岗位每日每周每月每季每年的异常处理业务流程,每个岗位每日每周每月季每年的输入表格,每个岗位每日每周每月季每年的常用数据查询,每个岗位每日每周每月季每年的统计报表
5 针对以上的了解,客户面对未来挑战和机遇,未来应该如何变更他们的岗位和职责和流程,尽量流程少,效率高,运转快?

其实,开发经理就相当于业务架构师(因为我们还是游击队,不可能有专职的业务架构师),公共代码开发员就相当于技术架构师。

柳传志说的非常好:搭班子,定战略,带队伍。你班子不行,上什么需求管理软件、版本管理软件、项目进度管理软件、自动测试、自动集成软件,都是无法落地执行的。

有了夯实的业务+技术,功能实用、功能符合客户操作、功能稳定。这是软件最基本的要求,就都能满足了。这时候再招测试人员,就能把质量再夯实了。

而且,测试人员由于熟知产品,他们还能做技术支持呢,这样可以有更多的开发人员来专职开发,开发的专业性就能越来越提高了。

好的产品,还需要有好的文档和培训,否则其他部门还是不会接开发部的产品的。

那就招一个文案人员,写帮助说明,制作操作视频,制作学习版数据库,参与辅助测试(这个很重要,否则文案人员不熟知 产品,无法写出有质量的文案)。有了这些文案的基础,最熟悉产品的非开发人员就有了两个岗位:测试兼技术支持,那么文案就兼起培训工作(由于他自己写文案 自己用自己的文案做培训,在培训中会有各种提问,会更加增进他对文案和产品的理解,能写出更好的文案。而且他不是开发人员,他能站在使用者的角度上来写来 讲,而且他属于开发部门,他会给产品开发带来更多更好的产品易用性建议)。

好了,开发部的四套马车终于起来了,这就是我要讲的开发模式:从游击队转变为兄弟连,从软件作坊走向

记住:业务架构、技术架构、测试兼技术支持、文案兼培训,四套马车。

我们一直用它,效果很好,搭建团队容易,循序渐进不革命。

有了这么好的团队,就能比过去产出更好的软件,软件的质量,软件的进度,软件的竞争力就都上来了,再上各种管理软件:如项目管理软件、版本管理软件、BUG管理软件、自动测试软件,就水到渠成了。

其他部门也愿意接软件了,软件的实施和培训和技术支持都被其他部门接过去了。开发部门也终于专职专业起来了,整个公司都很协调了,部门间也不互相陷害抱怨了。公司发展速度蹭蹭的。

老板看着形式这么好,也不抠门了。奖金福利随之而来。老板看着公司产品销售这么好,也不用再为公司生存发愁了,不用随处找单子养活了,给开发部门更带来了专业理顺的计

划发展。老板也开始重视研发部门了,研发部门在公司的地位高多了,给与研发部门的资源和支持也更多了。

OH,My God!
内容简介   《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、付费专栏及课程。

余额充值