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

 现实点，不要急! 

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

      从公司现状来说，流程改进有三个目标：确保项目和产品研发工作高质量完成，大幅度降低人工成本，保障公司技术团队的总体稳定。三者说白了，就是提升公司的营销能力和降低成本的问题，技术永远是为公司经营服务的。若不能达到这三个目标，就是在做样子。改进过程中的全面折腾，虚耗人力、正常的项目实施受到影响，我一般称之为：既无益，反有害。我所强调的，都是最低限度的东西，是影响成本、质量、响应速度的关键点，期望做最少的事情，实现平稳过渡，不冲击现有部门架构、不影响现行经营。  

   

一、必须立刻将技术团队和实施团队分开：

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的项目，无关战略的要勇于舍弃。