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

原创 2008年02月28日 11:27:00

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

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

的悲哀。

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

为什么呢?

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

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!
 

版权声明:本文为博主原创文章,未经博主允许不得转载。

相关文章推荐

从流水程序到SOA

从流水程序到SOA 咱就从函数代码开始谈起,更史前的Goto和汇编代码咱就不谈了。 函数和变量写多了,自然也就发现有些函数和变量互相粘在一起很高耦合,而与其它的一些却没多达关系,于是为了显性化让其他的...

一个优秀的研发团队应该具备什么特征

1、计划执行:计划安排得当,不要老加班,不要老是现实和计划不匹配。不要做到哪儿计划就推后到哪儿。 2、研发成果:成功产出几个重影响力级别的、完整成块的、有成就感自豪感的产品或项目 3、团队氛围:这个团...

人,是人,真的是人---走出软件作坊:三五个人十来条枪 如何成为开发正规军(四)

写了《三五个人十来条枪 如何走出软件作坊成为开发正规军》(一)、(二)、(三)后,每篇都点击上万跟贴评论无数。有网友评论我之前的几篇博文:分析的不错,方案似乎也很能解决问题!不过必须满足一个潜条件:一...

任正非对研究部门的方向指导

一、不打卡、出去多交流、多想象未来生活是什么样一杯咖啡吸收宇宙的力量交流也是在提升我们自己,因为我们真的想不清楚未来是什么。华为公司的圈子还太小,你们这些fellow都不出去喝咖啡,只守在土围子里面,...

异步赠书:9月重磅新书升级,本本经典

敲重点:        活动规则:试读样章,评论区留言说一下你对本书的一些感想,同时关注异步社区博客,并留言你想要得到的图书。        活动时间:即日起-9月20日(活动奖项公告在10月9日) ...

CRM下午茶(七)-潜在客户流失排查

昨天去一家客户处调研。 目标就是帮助客户提高成交率。但成交率为什么低,我们也不知道。我们又不是那种销售神人,眼光毒到犀利,江湖经验丰富,寥寥几句直指问题关键环节与关键人的真实想法。可惜我们不是这类人,...

中国儒家三大圣

中国儒家三大圣我国的历史大致是这样的:周、【春秋战国】、秦汉、【三国】、两晋、【南北朝】、隋唐、【五代十国】、宋、【元】、明、清、【民国】。每经历一个历史碎片割据期,就会出来一个圣人说礼崩乐坏了该重整...

国内研发团队普遍常见问题

以下是国内研发团队普遍常见问题,大家说说各个岗位怎么提高质量和效率吧。一、产品设计1、业务需求不会解构洞察,客户提什么就做什么,业务需求和软件功能要求混在一起2、不会建立业务模型和产品模型,客户提什么...

SAAS破解(二)

上次我写了SAAS破解(一),许多人仍然争论ASP和SAAS的区别,说我写的云山雾罩故意忽悠,最后也没说清。这些天也和不少网友交流,一一讲解,所以我一直想给大家再写一篇,集中把大家的迷思再解解。我的前...
内容举报
返回顶部
收藏助手
不良信息举报
您举报文章:深度学习:神经网络中的前向传播和反向传播算法推导
举报原因:
原因补充:

(最多只允许输入30个字)