Shell's Home

Oct 21, 2008 - 1 minute read - Comments

程序生产流程管理的一些想法

程序的生产管理本质上说应当可以纳入生产管理中,然而程序毕竟是一种特殊的产品,因此程序的生产管理也有其特殊性。下面贝壳从小到大阐述一下个人对生产管理的一些想法。当然,30人以上的团队规模贝壳根本没有碰到过,因此就不予置评。

首先我们从软件的生产流程开始论述,当然你可以没有流程,然而你不能没有过程。没有流程叫做不正规,低成本和高效率,没有过程……没有过程我也不知道你怎么做的,直觉?

管理的头一步是计划,软件生产的头一步是调研和需求分析,然后是紧密关联的系统构架,包括构架选择和结构设计。调研的典型情况是回答以下问题,软件为了谁而做(Who),设计周期和维护周期是多长(When),软件的适用范围(When),软件的意义和核心价值(Why),软件要达成什么目的 (What),如何设计达成这些目的(How)。这些问题中,要达成的目的和如何达成是核心。而后通过详细的讨论,得出到底要做什么东西,具备什么功能,以及一些细节问题。这时期形成的是软件需求分析报告和软件需求说明书。需求说明书的尺度是一个很难把握的问题,一般来说,需要灵活对应市场反馈的软件,需求说明书不用过早细化,反之则可以早细化一些。开发人员多,结构复杂的系统,设计说明书必须详尽,反之则可以简单一点。不过如果忽视甚至无视需求说明书,或者将需求说明书仅仅作为一个官样手续的团队,必定会在后面吃大苦头。如果要规避需求说明书,也并非不可以。贝壳会在最后描述一个原型系统方法,来规避灵活和不确定的需求对需求说明书的挑战。然而注意,这只是需求说明书的形成手段,本质上是以程序员和最终用户的互动来清晰需求,同时潜在的让程序员熟悉需求。并非真的不用讨论和细化需求,更不是提倡做项目不出需求说明。

项目的构架选择是在基本明确需求后做的事情,这个阶段主要明确以下问题。是单机软件还是群体软件,C/S还是B/S,.net还是java还是 C,Windows还是Linux。中间是否使用ORM,使用的话怎么设计细粒度表,不使用的话怎么使用冗余设计。结构设计和构架选择互相分离又紧密结合,结构理论上是脱离构架的,然而某些结构就必须适用某些构架(例如如果用了事务明显就不能用mysql,性能会差死),某些构架则要求你特殊设计结构。结构设计是系统一个非常广阔专业而复杂的问题,有兴趣的可以看系统结构和构架的一些书,还有设计模式和UML的,这里就不细说了。

在系统完成结构设计后,就开始系统的编码过程了。而项目时间确定,到这个时候才有依据。粗说是编码过程,其实又细分为构架实现,技术研发,编码,自测试,系统整合几个部分。结构设计完成后,抽象的结构必须经过严格定义才能进行使用,其中进行严格定义并且文档化的过程绝对不要轻率处理。如果是大型团队,应当指定一个人负责结构定义的维护,并指定几个技术骨干来讨论定义,讨论修改。这个人需要处理每一个对结构修改的请求,分辨是否应当修改结构,并且交给骨干团队讨论。讨论确定后,对定义进行修改,修改定义文档,并且通知所有部门进行修改。

当结构定义后,系统的框架模型已经清晰可见了,剩下的就是编码了。可是否能进行顺利编码呢?未必可行。因为实际上会在过程中碰到很多技术问题。例如需要使用以前没有接触过的框架和组件,需要对抽象数学模型提出可行算法等等。这些问题如果不先行解决,后面的编码无法顺利进行,技术骨干的最主要作用就在这里。在他们解决技术问题后(或者,更经常的,在中间提出的问题被他们解决后),系统就进入了编码阶段。编码阶段的代码一般来说会有不同级别的自测试,从最简单的写个小程序到最复杂的单元测试+冒烟测试,按照项目的级别具体分析。不过即使是再小的项目再小的模块,一般写一点代码就写个小片断测试下是否可行是最基本的常识,除非你能保证所有程序不论大小一次写对。在完成自测试后,还需要整合入系统,并可能伴随冒烟测试。如果结构设计良好,这个阶段会非常顺利,甚至不出现什么大的问题。反之,如果结构散乱,不用到客户那里,在这步就会碰到非常大的阻力。

在完成主程序的编码和整合后,项目进入收尾阶段。一般是漫长的测试和后续工作,主要包括叠代测试,性能分析,编写使用手册和编码手册,编写项目的技术分析,系统分析报告和各种材料。在这个阶段最主要是要通过测试,先于客户找出错误,并且逐步修改掉。良好的测试结果应当是逐步收敛的,当你看到一个逐步发散或者不稳定,根本没有规律的测试修改结果时,你的麻烦就大了。这通常是因为没有构架,构架错误,中间有不适应构架的修改,构架变化,核心算法错误,需求浮动太大等根本问题所导致的。当然,在测试的同时还要进行全面的文档化过程。

在测试和交付后项目是否结束呢?恐怕还没有。下面是漫长的客户服务期,需要收集和分析客户反馈,进行持续改进。不过那就是后面的问题了。下面我们按照团队的大小来逐步讨论团队的分配和任务。

首先是从一人团队开始,当然,如果也能叫团队的话。作为一人团队,也就没有什么分工问题。文档化要以轻量为主,方便自己日后理解,除非是客户特别需求。

而后是典型的一个团队,一个PM带几个技术,可能还有外面的美工支援什么的。人数不超过五人,不分组。这里前期的需求/后期文档都要由PM完成,程序员主要注重编码和测试(尤其是单元测试)。如果时间充裕,建议一些专门编码一些专门测试,这样可以有效保证代码质量。互相的沟通以开会为主,信息的沟通要诀是让每个人都知道别人的事情,尽量多的向别人传递信息。

再下面是一个典型的“大”团队,两个PM带四个程序员四个测试,其中有两个以上技术骨干,再加上一个专职美工和专职的UI Design(或者两个美工,基本差不多),8-16人的“大型”团队。说大型是因为这个团队开始内部就要分工协作了,加引号是因为……即使10个人,基本也就刚够分工的底线而已。

贝壳个人建议,除开美工等支持岗位,将这种团队分成三个部分。一个是PM组,负责和用户沟通协调,产生需求文档,盯项目进度,调度程序员,产生用户文档,产生其他材料。这组PM不要求高技术,对于技术建议会用,但不用精通(最好也别精通,业务骨干做PM是非常浪费的)。但是对于沟通技巧,协调能力和领导能力要求非常高,也要求有相当的文字功底。毕竟他们是要和客户沟通的人,要是鸡同鸭讲就麻烦了。和客户产生矛盾,文档写不好,更是麻烦中的大麻烦。由于协调要求非常高,因此PM组强烈建议至少两人,手机24小时开机!建议设立正副职,采取正职负责,副职挂钩的方式。

第二个团队是研发组(Dev),至少一个技术骨干带队。这组需要负责编码,自测试,系统整合,出开发文档,出技术文档。对于他们要求是沟通能力过关,程序编码效率高。对于系统经验,思考方式的全面和独特没有特殊要求。一般经过培训的新程序员就可以在研发组中担任工作。他们年轻力壮精力旺盛,相对编码效率比较高。不过如果有条件,还是用比较有经验的程序员比较好。在系统的整合测试,返工引发的效率低下控制方面会有相当的好处。

第三个团队是测试组(Test),至少一个技术骨干带队。这组要求负责系统的叠代测试和性能测试,可能还要帮助编写用户文档,进行项目实施,培训和售后支持。这组人的要求是工作勤奋(叠代测试的工作量是非常高的),技术过关(否则无法发现一些问题),系统经验丰富,思考问题全面而独特。因此强列建议由最强的技术骨干和一帮能吃苦的年轻人组成。一般来说测试组和研发组的人员比例在1:2到1:1之间。如果小于1:2,那么会发生测试不充分的情况。如果大于 1:1,只要成本允许,到是强烈支持。

最后一个团队(有人算了算……怎么还有),是系统的管理组。负责项目的构架选择,结构设计,时间节点认定,人事事务,开发成本控制,技术研发。这个团队有非常高的技术能力,管理能力和执行权限,一般由主PM,研发组和测试组骨干,客户代表,公司代表(多数和主PM是一个人)组成。主要是要对项目过程的监控,项目中人员权限的分配,核心技术的研究和管理进行处理。这个团队等若公司和客户的联合代表,对项目负全部责任。

对于30人以下的团队,估计可以按照比例放大组规模来使用同样的组织结构。不过如果再大,同样结构就不合适了。这主要是因为同一个组中的信息是互相完全流通的,超过10人的组会造成非常高的沟通成本。这时候一般是分解系统结构,分解研发组和测试组。将一个大型系统分解为两个或者多个独立的部分,让每个组分别研发和测试。这样可以避免每组内的信息沟通成本过高,可对文档的严密性和规范性提出了更高要求。通常来说,拆分方法有按照功能和按照构架。即按照功能划分出一个一个的业务模块,每个组开发一个完整的业务模块。和按照构架层次分为数据库组,业务逻辑层组和客户层组。通常来说,我支持以业务为主的拆分方法。因为此时组已经够大,让一个组精通所有层次不难。但是让所有组全部完整了解需求可就很难了。

对于这种成规模的开发,注重的主要是两点,文档和测试。最高的要求(也是我认为最好的褒奖)是及时的文档和全面的测试。此时的难点在于,研发过程中程序员经常为了修补问题而修改代码,但是忘记修改程序文档。或者需求变更后PM改了需求说明,通知了Dev,但是忘记通知Test。又或者通知了Test,但是忘记修改用户手册。因为诸多文档其实是对同一内容的不同描述,所以相互具有关联性。其中之一变化经常导致其他文档落后陈旧,而且版本不统一。

测试应当贯穿正规研发过程。从程序员实现一个个功能起就应当开始叠代,直到项目完成后。并且bug的管理应当和需求管理合并,成为几个组沟通的核心。测试的时候一定要注意充分测试和叠代测试,不要象微软一样弄出新的补丁补出老Bug的状况。

下面贝壳讲以下系统原型法,其实这个就是业界常说的敏捷开发。系统原型方法是指以构建非常简单的系统,实现非常核心功能的原型系统为基础,逐步推导出正规系统的功能和需求的系统分析方法。主要适用于系统需求不清晰,分析困难,开发周期短,程序员数量适中的项目。如果上述条件不成立,那么建议不要使用原型方法。

原型法的头一步是分析需求,不用说不确定的,就说为了实现业务目的(至少这个应该知道吧?)需要哪些功能。然后实现一个可用的,不用很美观,不用性能优化的系统。有了这个系统后,客户可以逐步分析使用这个系统哪里不方便,而后交给程序员改进。逐步反复,直到客户满意为止。使用这个方法,客户和程序员间,程序员互相之间要保证充分沟通,文档可以容后再写(前期还不确定呢,怎么写?)。主要是注意逐个的需求管理和Bug管理,这正好和我上面说的合并管理对应。使用这个方法的好处是当不清楚需求的时候可以马上做,逐步清晰。过程比较直观,做出来东西比较实用,也节约时间。坏处就是会浪费一定的程序员人力,而且一个没控制好就一直改一直改不知道哪里是头了……

当前国内软件业企业的几个问题就是,不注重需求,不注重测试,不尊重专业,不尊重规范,不培养人才,不积累技术,不重视信誉,不打算做事。下面贝壳逐个细说。

不尊重需求,一般来说,老板讲的时候都是需求为重的,可当客户需要变的时候,老板很容易同意需求变更(虽然我可以理解,做生意也不容易)。不尊重测试,做程序的非常理解测试的重要性,然而老板却认为那个岗位可以随便找个人来做。实际上,测试是一个非常专业非常流程化非常严密的东西,测试的主管最好是公司里面最有经验的人。同时,还有不尊重专业的问题。并不是说老板干预程序员的决策,而是很多时候老板根本不了解技术骨干和PM,测试的区别。让技术骨干来做策划,或是负责、或者主导和客户沟通,这都是超级缺乏效率的做法。至于不尊重规范,事先划定的流程,在遇到重大问题的时候,往往就变成了废纸一张。到不是说在重大问题前非要坚持僵硬的步伐,可一个项目一半时间都是重大问题,这就过分了把?先说了项目过程中要推进知识积累,推进技术交流,推进这个推进那个,等项目一忙就全飞了。

同时由于程序员的超高流动率,当前中国的程序界有一个非常不良好的风气,公司基本不培养自己的程序员。都不知道公司是否能开到明年呢,培养了做什么呢?这点在大型公司就比较好,无论什么情况,基础的内部交流总是保证的。只要签长约,多数可以弄到一些培训。中小公司不培养人才一方面是没有必要,另外一方面就是没有能力。于是程序员就被迫自我培训,自学或者脱产参加培训。付出了成本,自然要赶快跳到能实现价值(能把钱赚回来)的公司里面去。中小公司为人员流动付出巨额成本,而且很多都根本无知觉。

举贝壳公司的例子吧。因为发展需要,今年年初公司曾大型招人,C#程序员,结果可用者寥寥无几,很多都是浮夸碰运气的。以至于一天面试十多个人,竟然一个备选都没有的情况经常发生。一个人过来投简历,硕士,要价10K多。不说公司能否负担,看了看做的题目,算法题还不错,C#技术,解决实际问题都一塌糊涂。这种人招进来差不多就是研究算法写Paper的主,要做程序还得培训一下。还有一个人,我前周刚刚送走,转眼又回来,估计是批量投简历的时候忘记筛公司了。还有一个项目经理真的是不错,讲起问题来很深入,经验丰富,可老板认为用不到,贝壳一点办法都没有。由于人员仓促到位,我们在开发后期付出惨烈代价!有一个程序员从到岗到离开公司,最大的贡献就是拖了三个多月的进度,因为他连static函数干吗用的都不知道。还有一些人,很适应岗位,可做不到多久就走了(当然,这是有各种原因的,试用和刚满期的人走是比较正常的事情)。问题是,其他人就要重新接手他的事情,等来了人再换手。这样的直接结果是什么呢?如果说项目拖延有一半是因为我们需求没做到位,另外一半就是团队的人才损失。如果在普通项目上碰到类似问题,来的人不能做事情,人员替换率高。那么本来能按时完成的任务就一定会延后,而且分析的时候很难直接表现出来,多数会被认为是工作效率不够高,工作态度不认真之类的(某种意义上也没错,毕竟不能做事的人,不是因为效率不高就是因为做事不认真)。不能留住人才造成的后果,是通过项目拖延表现出来的,使得公司往往失去了隐性可能的良好口碑。这种软性杀伤是非常致命的但是又是难以直接表现的。

如果说不注重人才,还怎么能积累技术呢?人是技术最主要的载体。尽管我们可以通过互相培训,技术交流,技术文档化来积累技术。但是如果没有老员工的指点,那么新员工是很难吸收企业的原有技术体系的。无法积累技术的直接表现有两个,一个是中国企业没有核心技术,另外一个就是掌握技术的人就卡了公司的脖子。可能有人会举出中国有多少专利多少成果。贝壳告诉你,按照贝壳做项目的经验,那个多数都是项目做好了用来表功的牌坊。很多技术都是公司不敢给个人,个人不敢给公司,因为浮动率太高。许多真正有价值的核心技术往往是因为缺乏大公司(或者缺乏人)作为后台,而无法正式的走向商业化运作,更无法走向系统化理论化。因此中国不但缺乏真正的核心技术(我指能解决问题,有实现难度的技术),更缺乏(这点可以确认)系统化理论化的技术体系。而掌握公司核心技术的人往往就能卡公司的脖子,尤其是技术都掌握在一个人手中的时候。并非说程序员都有坏心或者什么的,而是程序员有很多和老板不一样的想法(例如要重视测试,要重视专业等等)。当程序员觉得他是对的时候,为了和老板争辩,往往会使出走人的杀手锏。固然,公司是对产品拥有产权的。可是掌握核心技术的人不在,没有人能继续改进,研发新的产品系列,这不是要公司的命么?这时候老板就处于弱势的一方。从某个事情来说程序员往往是对的,可是从企业发展来说却绝非好事。

最后两个问题则是中国软件业更深层次的问题,不重视信誉,不打算做事。整天就想着前辈一夜暴富的事情,或者谁谁风投成功吃喝不愁的事情。根本不打算花心思将事业做好,而是设法请客招待人拉风投,找人做假买点击量买排名,花钱黑掉对手的网站,盘剥底层员工,炒作一些无聊的事情增加知名度。某种意义上说,这个才是中国软件业最大的毒瘤。