现实点,不要急! [ 公司软件过程改进案例]

 现实点,不要急! 

        算是咨询服务:这间人数超过百人的公司,没有基本的软件过程。这种情形比较常见,公司技术负责人做过努力,但很难推动。这是最终建议的草稿,文字未经组织,直接写完。思路的唯一优点是:现实,抓关键点。解释了一些简单的概念,非常初级,供大家参考。

      从公司现状来说,流程改进有三个目标:确保项目和产品研发工作高质量完成,大幅度降低人工成本,保障公司技术团队的总体稳定。三者说白了,就是提升公司的营销能力和降低成本的问题,技术永远是为公司经营服务的。若不能达到这三个目标,就是在做样子。改进过程中的全面折腾,虚耗人力、正常的项目实施受到影响,我一般称之为:既无益,反有害。我所强调的,都是最低限度的东西,是影响成本、质量、响应速度的关键点,期望做最少的事情,实现平稳过渡,不冲击现有部门架构、不影响现行经营。  
   
一、必须立刻将技术团队和实施团队分开:
1、怎样分开:
    现状:我们以XX行业为例,同一个产品,不同地市、县几乎都作为单独的项目,一到三个人负责,很多情形下,技术人员在现场编程,实施人员和销售,对客户新增需求经常承诺难以达成的时限。
    合理的安排应该是:行业部门筛选主力程序员,成立项目组,集中在公司。软件将划分成数个区块,分别指明数名程序员承担前端、后端的开发工作。行业部门的其他人员,包括未能进入项目组的初级程序员、新人,作为实施人员。初级程序员在公司期间,也会承担少量的编程任务,作为项目组的后备补充人员,熟悉之后有可能进入项目组。新录用的初级程序员,只能进入实施小组。项目组人员,原则上不到现场。
    工作的流程:实施人员收集用户需求、将需求和用户时限要求书面形式报项目组,可向客户承诺完成,但不得第一时间承诺时限。项目组评估后,决定具体时限、哪些功能可说服客户暂缓,一到两小时内文字回复。实施人员再据此与用户落实。这样的流程,既避免盲目承诺无法做到,又不至于影响营销竞争力,规范的流程相反会令用户更加认同。
 
2、为什么要分开?
    我们经常听到一些公司经理或技术负责人,抱怨手下完全没有可用之人,几乎所有的技术人员都不合格。这种抱怨是普遍现象,但真正的罪魁祸首,不是技术人员,恰恰是这些在抱怨的、高高在上的管理者。
    每个人的能力是有限度的,按照现在的划分,一个技术人员,需要精通(不是了解):整个软件系统的所有业务需求、前端编程、后台编程、理解原有程序每个部分的代码、懂得所有性能和安全方面的技巧。更要命的,是所有这些,必须在非常短的时间内做到,在现场工作也很难得到同事的支援。这种要求难道不变态吗?
    按照改进的安排:程序员只需要了解软件系统一部分的需求、前端开发人员只需要使用他掌握的技能、遇到不擅长的问题可即时请教同事,这是现代工厂的流水线模式。实施人员根本不需要编程,工作压力也大幅降低。这是从用人的角度,必须做到的,技术团队只有在这种状态下,才能保持稳定,新人才能很快上手工作。
   人数的需求大幅降低:几个人在公司负责软件某个区块,面对全省客户,做自己熟悉的事情。
   人员素质的要求大幅降低:初级程序员也是能够胜任工作的,不一定非要名校本科、硕士之类。
   人员的稳定性更容易保证:主力程序员技能的起步要求大幅降低,出差不多,工作中能随时和同事交流,资金投入倾向他们,这样工作的情绪会大为改善,生存状况向好,稳定性容易保障。过于强调吃苦耐劳、要求技术人员以健康为代价奉献,这是不切实际的幻想。不能保障体面生活,如何能要求对方的忠诚度?   
 
3、如何平稳过渡,降低对现有架构和项目实施的冲击?
    这种改进,不影响公司的部门结构。改进的结果,除了降低对项目组和实施人员的工作技能要求、减轻工作压力之外,对所有成员无现实利益损失。
    实施的步骤,以筛选骨干程序员,组建项目组为起点。指定两名候选人,由项目组决定项目组长。骨干程序员通常薪酬更高,视情况增加适量津贴。对实施人员,不安排整体培训,提供文字形式的业务知识、沟通技巧、工作流程与纪律、需求采集、系统使用等手册,并安排专人答疑。
 
二、必须立刻改进技术人员聘用条件和流程:
    结合行业部门架构的改进,程序员聘用条件和流程,必须相应变化。
    1、招聘条件降低为有一次实际项目经验、不限学历:
    2、笔试以自编的基础题和项目过程描述为主,绝不出难题、偏题,多出选择题、填空题。
    3、面试的核心目标,是弄清项目经验的真实性、对方承担的真实职责。面试不对潜力评估,这将在进入实施小组后在工作中考察。
    4、在团队相对稳定后,中层以上的关键岗位,将主要从现有人员中选拔提升,除特殊情形不对外招聘。
    5、初级程序员不得直接进入项目组。在实施工作过程中,他们会理解业务、掌握软件系统的操作,在公司期间承担简单编程任务,有助于技术能力提升。
 
     现有模式存在的隐患,是人员会无止尽的扩张,上次提及的某个案例,投资100万元在八个月用完、产品却没有研发完成的例子,其实和公司现在的状况很相似。我知道公司目前资源雄厚,但现在同时做40个”项目”,60人尚觉得不够,一年人工成本其实也有1000万样子。如果,不幸,公司接到了80个项目,人员又需要增加,但这个期间一过,增加的人员可以辞退吗?辞退,影响公司骨干的稳定性,兔死狐悲。不辞退,如果今后一到两年项目不饱和,这种成本如何承担?天长日久,消耗和浪费的资金,并不是眼下拍拍脑袋,就觉得可以一直承受的。
    尤其这种模式下,新增人员对产品质量、公司在客户心目中的评价,经常会带来损失,新手更多的时候是拖累项目进度,而不是人越多做事越多,新手至少有三个月对项目产生的是负价值,这是不可忽视的、无形的负面成本。
 
     改进的模式:当接单较多人员吃紧的时候,实施人员是最好的后备力量。新招的初级程序员只能补充进实施队伍,这样就避免了在项目关键时期,因为新手的介入影响进度。
     而初级程序员,最初做实施工作,有助于了解业务。在公司期间,适当承担少量编程任务,有助于提升技术能力、增进对现产品的了解。他们第一个明确的目标是进入项目组,一部分人可能因为沟通能力、需求分析能力,转到相关领域,无法进入项目组且希望继续做技术工作的,会因为待遇、兴致问题离职,这是新陈代谢。
   这样能清晰的弄明白:哪些人是必须要尽量长期稳定的,哪些人可能具备需求分析、现场项目经理甚至售前能力,那些人是公司需要自然淘汰的。
 
三、必须立刻启动源代码版本统一管理:
    从目前的情形来看,项目在省内不同县市,或多或少都有不同。
    没有任何人能说清楚,每个县究竟增加了什么功能,修复了哪些Bug,调整了哪些功能。
    如果存在30个不同的版本,程序员每到一个新的地方,面对的任务往往不是他完全掌握的,他甚至难以理解为什么这个县的版本里,会有这样一串奇怪的代码。
 
     组织少量人力,将每个版本部署运行,然后存入源代码库,作为一个分支。每个版本,需要列出与主版本明显的不同,并将其文档化。之后,程序员临时接到某县的新增需求任务,几秒钟内即找到这个县的分支,与主版本的区别也很容易看到文档。所有修改都在同样的分支存入,项目整个生命周期,某个版本对应唯一的一个分支,单是这样,每个程序员至少要少花费半天的人工。大家其实都有体会,临时送来的源码压缩包,说不准有多个,挑选、调试运行通过,往往需要2-4小时。
    当程序员离职之后,由于他只负责软件的一部分,同时是和多人负责的,对项目冲击较小。新加入的程序员,透过源码库能清晰看到每次改动的内容,更容易立刻接手。
    没有源码版本管理,是混乱不堪的。这种混乱不堪,在我看来,就是人力的浪费,本质上是资金的浪费,同时也是在用户现场造成恶劣后果的主要原因。带错版本,到现场增加功能,却发现几处以前修复的Bug又冒头,这时候找到原来的版本、再合并此次的修改,1个人天就浪费了,日积月累,绝不可轻忽。
 
四、必须立刻建立任务单制度:
    很多项目经理,往往是粗略的要求,你做这项功能、他做那项,什么时间完成,一张嘴说话。这种情况,等同于靠天吃饭,5天后发现毫无进展的时候,项目经理能做什么?
    因此,开发任务的划分,我本人的经验,是不要超过半天工作量,给程序员一天时间。细致,导致的结果,是项目经理每天都会检查完成情况,即时的调配人力。工作量看似增加,但项目经理是做什么的?下达命令之后,休息五天再来看结果?
    至于公司技术负责人说:找不到能够分配任务的人,指定谁分配任务,最后的结果是这个人一个人做了,其他人没活干。
    这是培训的问题,多数情况一天能够做到:每项功能,界面逻辑设计、页面设计、页面美化、数据层、逻辑层、逻辑层与页面衔接、可能存在的服务接口、测试,根据复杂程度每个划分成1到3项任务,普通程序员能做到。现在觉得困难,是因为没有确立规范,2个小时、一篇文档和一个例子就能解决大部分问题。
 
   对于任务单制度,目前只设立项目、功能、任务三个层次。Bug修复、疑难解决也作为额外的任务,分配到人。
   纸张传递费时且不安全,对于asp.net方向,我建议使用Tfs管理整个生命周期,Tfs能够在局域网和互联网上完整的支持上书5种任务的共享,项目经历随时能看到每项工作进展程度,程序员每天能在开发环境中找到他的任务。
   这些功能、任务、Bug、疑难,本身和Tfs源代码管理是结合的,你完成任意一项任务,都能找到对应的修改是哪些,能够看到开发过程中,所有代码的变更历史。
    好的制度,要有可行、简单的工具做支撑。项目管理本身是有成本的,这种成本会蔓延到每一个程序员身上,尽量的简单、尽量的抓住核心,非常重要。
 
    任务单制度建立之后,对每个程序员的工作绩效,将有非常清晰的客观判断。
    谁是对公司最重要的?谁一直在混时间?一目了然。光靠管理者的印象,是非常不靠谱的,人性中最重要的特征:是喜欢他人逢迎。情感决定项目经理判断的成分,远比我们想象的多。很多管理者,总强调”我不喜欢听好听的,我希望一切就事论事直截了当”,这个,只有圣人才能真正做到。据我所知,当代的中国,圣人这种动物早就不存在了。
    解决问题的方式只有两点:客观和透明。任务单制度,是一种客观的评价,每个人做过哪些事情,按照他每项”一天“这种度量单位的工作结果记录在案,每一个bug的责任人,代表不同人的工作质量,每一个疑难的解决,代表技术人员的分析、学习能力。使用项目管理工具,所有项目组成员都能看到每个人的任务和完成情况,这是透明的力量,项目经理绝无可能过于不公平,数据在那里,每个人都知道,不平则鸣是最好的矫正。
 
五、不急:java和Asp.net双团队问题要慎重
    建立单一团队的代价,包括:
    1、旧项目维护问题,会影响客户关系,造成市场流失。
    2、旧项目会投入人力重新开发,但新开发的产品是否能稳定运行,替换旧版本,周期较长。
    3、技术部门应以营销部门为上帝,在遇到商业前景巨大的单子时,java团队很难撤销。
 
    只有满足如下条件,才能考虑单一技术方向问题:
    1、旧项目生命周期有限,短期内将被替换。
    2、有新的项目,允许我们重新开发新版本。
    3、有所为有所不为,新的、要求用java的项目,无关战略的要勇于舍弃。
posted on 2012-10-28 05:03  玄歌2  阅读(3008)  评论(14编辑  收藏  举报