走出软件作坊：三五个人十来条枪 如何成为开发正规军（二十六）
好多人都说：你这个方法根本就不是三五个人十来条枪的方法，项目经理，公共代码开发员，测试员，文档员，那得多少人的公司才能配得齐这样的团队。
嗯。其实，我们的团队也不怎么大，我们本身也是一个很典型的中小企业。
一般，都是一个产品或一个项目，由一名业务开发组长、一名主程、一名辅程组成。如果项目简单，基本就是一名业务开发组长和一名主程构成。如果业务开发组长的开发实力也能和主程相当，而且刻苦努力，不仅协调做的好，需求设计做的好，代码开发也做的好，那么比较中型的项目也是这两个人组成。有几个产品，就会有几个这样配对的开发团队。
研发部其他的人就剩下项目经理、公共代码开发、测试员、文档员这些角色了。
一般，研发部会有一到两名项目经理。我们老承接一些大的合作开发集成项目，老需要有人去客户现场去和其他合作伙伴一起开会，讨论，方案提交、工作量报告、工作进度报告。总需要有人去跑这些项目协调会。另外，销售打单的时候，客户总会提出一些技术性的问题或某个需求能不能做的问题，销售也模棱两可，不知道能做还是不能做，于是总会拉上一名项目经理。关于产品的、技术的、开发周期、工作量估算、项目团队组成的PPT和方案由研发部的项目经理来做，关于价格和商务条件上的由销售来做。在打单过程中需要讲解产品或回答客户产品疑问，都让这名项目经理来兼任售前支持。对于项目型的，项目经理有时还担任需求调研经理，使用需求调研方法产出需求说明书。不过，需求调研，有时也是业务开发组长来做。主要看业务开发组长在客户面前的沟通力。因为业务开发组长是开发人员出身，但技术一般，业务知识很熟，管理能力差不多够管理个1-2人，工作年限长一些工作经验也多一些，但有些人比较内向，不适合和客户调研沟通，就不做需求调研。所以谁来做，看具体人。不过按职责来，项目经理和业务开发组长都要能做需求调研。
然后就是公共代码开发人员，一般就一个人。对于企业管理软件的开发，框架的开发和维护，公共代码的开发，高难度的问题跟踪，需要高性能的设计，需要高扩展性的设计，需要高稳定的代码，需要高安全的代码，需要高并发的操作，需要复杂代码重构。需要性能优化，不知道的技术API，都可以寻求这位公共代码开发人员的帮助。他还负责新技术跟踪、新技术介绍、新技术试验。但这个新技术必须是为了改进公司现有产品和现有客户。新技术的跟踪必须上报给技术总监，以防不符合公司目标乱跟踪或跟踪方法和思路不对。对于有利于现有开发的新技术，可以筹备好培训课，由研发部经理安排时间，让公共代码人员给研发部全体人员讲解。如果大家认可这种方法，就需要选择适当的时机在产品中引入。
研发部的测试人员，一般也兼任服务部门技术支持人员。如果有服务部门解决不了的技术问题，可以转给他。而且测试人员还兼任配置人员，在产品打包、产品安装测试、产品发布、版本分支管理、源代码备份、历史版本归档方面都由他来管理。兼职是有好多好处的。如果他不兼任技术支持，他就不了解客户是怎么使用的，他测试也是瞎测试。如果他不管理产品打包发布，程序员就会自己私自发布版本。可能版本还有问题，为了修补问题，就赶快修改完再打包一个，但版本号却不改变，引起了一个版本号代码不同错误不同，让服务支持起来很莫名其妙。由测试人员控制产品版本发布，能不能发布，就是测试员说了算。测试员感觉质量没有达到，就有权不发布。很多软件作坊，程序员权力很大，一个老哥从头到尾负责整个项目，项目质量如何，全看这位老哥自己的素质和责任心了。为了不让项目质量和特定人密切相关，使公司研发保持连贯性水准，必须做到分工专业，互相配合互相牵制。
一般，研发部也就配1-2名测试人员，根据同时并行的项目和产品开发和开发的强度来定。我们并不生产向国际上的产品那样的质量。我们做行业企业管理软件开发，是在客户质量要求、客户签单额、竞争对手质量水准这三者平衡上做到一个质量的认可。我们无法做到微软那样一比一的开发测试人员比例。研发部所有的产品和项目，都由这1-2名测试人员负责所有的测试工作，包括编写测试案例，编写测试结果，参与项目的需求测试、设计测试。
对于研发部的文档方面，如文档的正规化，都由文案来负责。项目经理经常要提交给客户一些文档，而项目经理往往是技术出身，文档工作水平不行，于是文档的正规化、美化、文字校对、空格段落措辞标点符号，都由文案制作。帮助文档，也由文案负责。帮助方面，有版本更新说明帮助、安全配置帮助、系统维护管理帮助、基础数据配置与维护帮助、业务功能操作帮助、软件操作演示视频、产品简介PPT、产品演示版，都由文案来做。为了防止文案不懂产品而写产品帮助，在需求说明书、设计说明书这些文档性的工作上，如果有什么文档体力活之类的工作，也由文案人员来做。文案人员还兼任产品辅助测试，主要是作为一个普通的操作者来测试，在制作演示版的过程中模拟客户流程客户数据来进行操作录入，测试出普通使用中的BUG。一般，一个专业的测试，经常呆在软件的环境中，思维就有一种定势，但实际的用户并不那样操作，但测试人员自身感不到。而文案人员就能充当普通用户来测试。我们招聘文案人员也没有强调会什么软件，文案写的好就 OK。他们确实是最普通的用户，他们的困惑和操作手法代表了大量的普通用户。而一个研发部，文案人员也往往是1-2名，随并行的项目数量和规模来定。
所以说，一个研发部，一名研发部经理，1-2名开发人员，一名项目经理，一名公共代码开发人员，一名测试，一名文案，也就是5-6人完全符合一个软件作坊的人员数量。有时候团队小了，研发部经理就是项目经理，公共代码开发人员就是主程，这样，一个开发团队也就是3-4人就OK了。但方法照样能用起来。因为我所讲的方法也就是适应于这四套马车的组织架构的。每个人都身兼数职，而且都对自身的提高非常有好处，而不是给他身上堆砌毫不关联的工作内容。每一项职责都是能互相互补的，整体提高他的岗位专业性。
作为业务开发组组长，他很大的一个职责就是开发项目的进度和质量管理。手下也就1-2个人，开发人员的素质也就这么高，我们也会经常遇到突然来了个项目的事情或者突然有个过去的项目问题必须开发人员跟踪，所以开发人员也总是会被左抽右调。对于还能保证开发进度正常，业务开发组长确实每天都在监控进度异常，监控每个开发人员目前身上背着的开发任务和开发进展。每天下午5点的时候都要询问一下自己手下这两个人的开发进展。因为有的人不喜欢主动说自己遇到的什么问题，总喜欢自己去到处找答案，弄的延误了正常的开发计划。所以，开发组长必须每天下午5点主动问遇到了什么问题，是不是很棘手，能不能保证进度。如果不能保证，业务开发组长就会想办法，是全小组一起诊断出谋划策呢，还是寻求公共代码开发员呢，还是寻求研发部经理呢。为什么是下午5点？主要因为 5：30-6：00就下班了。如果快下班了你才去问，大家早就心思不在这里了，谁都想赶快下班回家，问题就被隔了一夜，留了个不清楚的尾巴。如果在5点钟询问，有了问题，如果此问题业务开发组长有经历，他会很快决定该怎么解决。如果详细听完了此问题的来龙去脉，业务开发组长也无法决定，他已经清楚了问题，他会在晚上思考，第二天一上班来就有了决定。这就一叫一点都不耽误。
我们使用的是BUG管理系统来管理开发任务。这并不要紧，谁说BUG管理工具只能管理BUG。我们只需要解决我们的问题而已。当然，我们管理真正BUG的系统是另一套，只不过我们使用的是同一个工具而已，我们当然不会把BUG和任务混在一起。
来自需求管理系统中的需求，来自BUG管理系统的BUG，都会被业务开发组长来评估，根据自己团队当前每个人的工作量来适机添加、定优先级、分配任务、调度任务。也根据这个任务分配，哪些任务超期了，哪些任务完工了，哪些任务还没有开工，哪些任务正在进行当中，来判别开发人员的开发进度和工作量。
业务开发组长也会每日主动向研发部经理报告进度，简要说明一下现有问题和解决思路。进度列表，当然是从工具中导出的，列明今日关闭的任务，还没有关闭的任务。这样，研发部经理一思考：项目已经开始了这么多天，还有这么多任务没有完成，到期能不能完成，他就会思考是不是要做些调整。
对于项目进度，不管客户是不是需要必须在XX月XX日之前上线，我们都会设立一个项目最终结束的日期。而不能让项目随波逐流。
这个最终的项目开发结束日期，并不是由业务开发组长排脑门想出来的。
我在以前的文章中就有介绍。业务开发组长负责功能点清单整理、功能优先级划分、详细功能说明书编写。而且每编写一块就开始分配任务给开发人员。
在业务开发组长划分完功能优先级以后，因为每个功能的复杂性都差不多，如果某个功能复杂，就会再被拆分。业务开发组长就能预估出一个大概的项目开发周期。根据以往的团队经验，也能预估出给集中测试时间和集中文档测试打包发布的时间。这样，整个软件什么时候能最终出来，业务开发组长是有个预估的。如果一个团队是新组建的，每个人的能力还不清楚，预估就会有偏差，需要磨合才能得到经验值。如果磨合，我也会在以后讲到。
在实际分配开发人员的时候，就是根据这个总目标完成时间来倒推时间的。这个倒推出来的，有一个每个功能的完成时间周期，而项目经理对于某个特定的开发人员的能力预估也有一个时间，而开发人员自己对完成这个功能自己也有一个预估时间。开发人员怕完不成任务被追究，往往会把完成时间往后放1/3时间，甚至有人想偷懒干自己的活，会更多出自己预估时间一倍，也就是说自己觉得3天能完成，就说6天才能搞定。当然，业务开发组长也不是吃素的。业务开发组长也是开发出身，到底难度多大心里有数。而且业务功能就是业务开发组长设计的，如何实现，会遇到什么难点，自己一清二楚。而且天天管这帮开发人员，谁能力高低谁想偷懒，天天在一个办公室，谁不知道谁。所以，每个任务的时间，都会是业务开发组长在开发人员自己预估的时间基础之上进行调整，获得一个开发人员和业务开发组长都能接受的任务时间段。然后根据每天的进度报告来随时调整这个时间，让开发进度尽量能现实，而不是计划前就定好实际工作中就不能改。
对于项目进度的保证，还必须有一个条件，就是：我们不允许开发人员在客户现场开发，我们更不允许开发人员和业务开发组长不在一起。
开发人员在客户现场，往往开发进度和功能需求变更容易受客户控制，致使开发团队做的计划和设计都被客户视为扯淡的东西。开发人员不满客户的做法，但在现场又没有办法，只好敷衍答应开发权且应付。本来一个理性的设计，被客户自己自以为是的好做法而推翻。软件什么扩展性啊，兼容性啊，都被扔在了一边。来客户现场，就要听这个特定客户的，你必须口对口服务这个特定客户，你如果和他讲其他客户怎么办，他才不管呢，反正他付了你的钱，在你眼中他必须是你唯一的客户。（客户和女人一样，都希望是男人眼中唯一的女人，但现实的是，世界上都很多女人，而且很多女人都差不多，都要求她所对应的那个男人必须唯一）
另外，开发人员在客户现场开发，就无法实现每日构建每日测试。开发，是个团队配合的事情。一个软件，并不是开发人员就能全部完成的（许多老板都这认为有开发人员就行）。缺少了测试，质量就无法保证；缺少了文档，产品就是光秃秃的软件。而许多老板还认为测试和文档可以在代码编写完后可以做，真是对软件质量如何保证一无所知。
我们也不允许开发人员和业务开发组长分离。因为在开发当中，设计文档又不是代码，机器运行完就一种结果。每个业务开发组长的文档水平有高低，每个人的思考思路也不同。我们经常会遇到一个现象，就是用邮件、MSN沟通老出误会，而且由于不及时调整，误会越来越大，后来干脆气愤的直接打电话。而打电话呢，有时还不行，你问他理解了么，他说理解了，你根本看不到他的表情，你猜测不到他是真理解了还是假理解了。你以为他理解正确了，他也以为自己理解正确了。你问他进度，他说没有问题。开发出来了，测试人员又有自己的理解，到底这三者理解的是不是一个东西，谁都没个准。只有业务开发组长和团队一起工作在一起，每天能看到实际的软件，能面对面和每个人交流反馈，才不至于代码开发完毕才一看不行。有许多刚当上业务开发组长的朋友，往往和手下搞的很僵硬。手下认为他一天三变，频繁推翻自己的代码，很气愤。而业务开发组组长认为手下的理解能力低，多次讲都讲不清楚，还跟自己顶嘴，还不如自己去开发代码省事。完了，又回到程序员了。
我也同样不允许团队出现多种技术。多个技术，会让团队成本升高，每个人都得会多种技术。而我们做企业管理软件，要想上升赚钱，必须大规模一般员工团队低成本开发，这是我和老板都认同的一种思路。所以，我们必须使用最常用最普通的技术。除非没有办法。我曾经有一个手下，怕自己跳槽没有竞争力，于是老学习流行技术。PHP火的时候，他就学PHP。Ruby火的时候，他就学Ruby。如今网游和嵌入、通信、无线很火，他就开始学C。手机开发火的时候就学 J2ME。而且他还想有实际的开发经验，以在应聘中说自己拿这门技术做过什么。于是他想尽办法在项目中要引入这些技术。说：用.net，我没法保证性能和稳定性，所以我必须使用VC++。？？唬谁呢？大家都是开发出身，这个借口未免太可笑。
我也不允许团队使用最新技术。我们只使用最合适的技术。我们不要客户为不需要的新技术而买单。客户的水平只能管理了SQLSERVER这样的数据库，我们就决不使用Oracle。如果客户要求在unix上运行，我们就使用JAVA开发。我们谨慎的评价和引入框架，都在核心围绕客户能不能简单维护，我们有没有显著好处，我们面临最棘手的问题能不能很好解决。如果只能解决我们不怎么紧急的问题，如果只能解决我们通过人工或管理就能解决的问题，我们就不引入。一切的一切，都围绕速度、成本、质量在寻找解决方法。
我们也采取了每日构建每日测试，来保证软件的进度和质量。不每日测试，哪到什么时候才测试。到那个时候测试，会不会出现其他什么不可控的问题，我们都说不清。这种对未来的恐惧，让我们需要把风险控制到最小，到天，而且到今天。今天关闭的任务，明天一测试，就知道问题大不大。有问题的，必须由测试人员登记BUG系统，并且业务开发组长根据目前情况适机把BUG修复当作一项任务来添加。
我们也采用了版本管理工具。版本管理工具不仅可以使我们对比源代码差异，找回历史版本，随时打包更新版本，分支每个客户的定制需求，还可以是我们的一个工作的体现。大家经常会听到这样的话：不知道开发部这帮家伙在干吗？是不是故意利用我不懂代码在偷懒。
我们到底在干吗？我们能否证明。有的时候确实是，一个问题三两天都解决不了。我们真的不好意思说我们三天就做了一个功能。我们如果解释这般技术难题为什么为什么，老板更是没有兴趣听，他认为你在嘲弄他不懂开发技术故意拿技术问题来骗他。
我们能如何证明呢？能拿一些大家都能理解的方法来证明自己呢？所以，我想到了文档数量和尺寸大小，想到了BUG数量，想到了任务数量，想到了需求数量，想到了开发进度报告，想到了版本发布次数，想到源代码归档容量和源代码行数。
一个项目开发结束，任务数300多，BUG数量400多，文档尺寸70多M，项目历次讨论开会纪要30M，项目历次方案提交20多M，开发进度报告100多份，帮助文档100多M。这些都能量化都能看得见的东西，让老板觉得确实做了许多事。
我们曾经有一个客户，嫌10万块钱买了一张光盘，觉得贵死了。说地摊上一张才5块，你卖我10万。我们于是就把所有的帮助文档都打印了出来，600多页，装订成3本书，印刷好封面交给他。然后把软件装在一个很精美的木制盒子里，客户笑的很开心，把盒子和手册都郑重其事的放在了IT部门的柜子最上面。我想，软件是由代码组成的，确实不容易让客户理解其中的艰辛和付出，所以客户并不认可我们的付出。能拿客户可以理解的方式去讲明白就是解决方法。我一贯遵守的原则就是：要么解决问题，要么闭嘴。如果你想不出解决方法还抱怨影响团队情绪，那么滚蛋，这种人就是团队的毒药。
过去，我们讲了业务开发组长如何履行功能设计的职责的一些方法，今天，我们又介绍了业务开发组长在任务分配、软件进度、软件质量保证、工作量化的一些心得，这就是一个开发组组长的份内之事。希望能给被提上开发组长的朋友一些启发，不要把自己定为一个写代码的头儿，那样你不符合国内现状，国内的开发组组长就需要做这些事情。外国怎样怎样那是外国的事情，你也享受不到，这是中国。要么去做，要么老老实实继续当个程序员。
嗯。其实，我们的团队也不怎么大，我们本身也是一个很典型的中小企业。
一般，都是一个产品或一个项目，由一名业务开发组长、一名主程、一名辅程组成。如果项目简单，基本就是一名业务开发组长和一名主程构成。如果业务开发组长的开发实力也能和主程相当，而且刻苦努力，不仅协调做的好，需求设计做的好，代码开发也做的好，那么比较中型的项目也是这两个人组成。有几个产品，就会有几个这样配对的开发团队。
研发部其他的人就剩下项目经理、公共代码开发、测试员、文档员这些角色了。
一般，研发部会有一到两名项目经理。我们老承接一些大的合作开发集成项目，老需要有人去客户现场去和其他合作伙伴一起开会，讨论，方案提交、工作量报告、工作进度报告。总需要有人去跑这些项目协调会。另外，销售打单的时候，客户总会提出一些技术性的问题或某个需求能不能做的问题，销售也模棱两可，不知道能做还是不能做，于是总会拉上一名项目经理。关于产品的、技术的、开发周期、工作量估算、项目团队组成的PPT和方案由研发部的项目经理来做，关于价格和商务条件上的由销售来做。在打单过程中需要讲解产品或回答客户产品疑问，都让这名项目经理来兼任售前支持。对于项目型的，项目经理有时还担任需求调研经理，使用需求调研方法产出需求说明书。不过，需求调研，有时也是业务开发组长来做。主要看业务开发组长在客户面前的沟通力。因为业务开发组长是开发人员出身，但技术一般，业务知识很熟，管理能力差不多够管理个1-2人，工作年限长一些工作经验也多一些，但有些人比较内向，不适合和客户调研沟通，就不做需求调研。所以谁来做，看具体人。不过按职责来，项目经理和业务开发组长都要能做需求调研。
然后就是公共代码开发人员，一般就一个人。对于企业管理软件的开发，框架的开发和维护，公共代码的开发，高难度的问题跟踪，需要高性能的设计，需要高扩展性的设计，需要高稳定的代码，需要高安全的代码，需要高并发的操作，需要复杂代码重构。需要性能优化，不知道的技术API，都可以寻求这位公共代码开发人员的帮助。他还负责新技术跟踪、新技术介绍、新技术试验。但这个新技术必须是为了改进公司现有产品和现有客户。新技术的跟踪必须上报给技术总监，以防不符合公司目标乱跟踪或跟踪方法和思路不对。对于有利于现有开发的新技术，可以筹备好培训课，由研发部经理安排时间，让公共代码人员给研发部全体人员讲解。如果大家认可这种方法，就需要选择适当的时机在产品中引入。
研发部的测试人员，一般也兼任服务部门技术支持人员。如果有服务部门解决不了的技术问题，可以转给他。而且测试人员还兼任配置人员，在产品打包、产品安装测试、产品发布、版本分支管理、源代码备份、历史版本归档方面都由他来管理。兼职是有好多好处的。如果他不兼任技术支持，他就不了解客户是怎么使用的，他测试也是瞎测试。如果他不管理产品打包发布，程序员就会自己私自发布版本。可能版本还有问题，为了修补问题，就赶快修改完再打包一个，但版本号却不改变，引起了一个版本号代码不同错误不同，让服务支持起来很莫名其妙。由测试人员控制产品版本发布，能不能发布，就是测试员说了算。测试员感觉质量没有达到，就有权不发布。很多软件作坊，程序员权力很大，一个老哥从头到尾负责整个项目，项目质量如何，全看这位老哥自己的素质和责任心了。为了不让项目质量和特定人密切相关，使公司研发保持连贯性水准，必须做到分工专业，互相配合互相牵制。
一般，研发部也就配1-2名测试人员，根据同时并行的项目和产品开发和开发的强度来定。我们并不生产向国际上的产品那样的质量。我们做行业企业管理软件开发，是在客户质量要求、客户签单额、竞争对手质量水准这三者平衡上做到一个质量的认可。我们无法做到微软那样一比一的开发测试人员比例。研发部所有的产品和项目，都由这1-2名测试人员负责所有的测试工作，包括编写测试案例，编写测试结果，参与项目的需求测试、设计测试。
对于研发部的文档方面，如文档的正规化，都由文案来负责。项目经理经常要提交给客户一些文档，而项目经理往往是技术出身，文档工作水平不行，于是文档的正规化、美化、文字校对、空格段落措辞标点符号，都由文案制作。帮助文档，也由文案负责。帮助方面，有版本更新说明帮助、安全配置帮助、系统维护管理帮助、基础数据配置与维护帮助、业务功能操作帮助、软件操作演示视频、产品简介PPT、产品演示版，都由文案来做。为了防止文案不懂产品而写产品帮助，在需求说明书、设计说明书这些文档性的工作上，如果有什么文档体力活之类的工作，也由文案人员来做。文案人员还兼任产品辅助测试，主要是作为一个普通的操作者来测试，在制作演示版的过程中模拟客户流程客户数据来进行操作录入，测试出普通使用中的BUG。一般，一个专业的测试，经常呆在软件的环境中，思维就有一种定势，但实际的用户并不那样操作，但测试人员自身感不到。而文案人员就能充当普通用户来测试。我们招聘文案人员也没有强调会什么软件，文案写的好就 OK。他们确实是最普通的用户，他们的困惑和操作手法代表了大量的普通用户。而一个研发部，文案人员也往往是1-2名，随并行的项目数量和规模来定。
所以说，一个研发部，一名研发部经理，1-2名开发人员，一名项目经理，一名公共代码开发人员，一名测试，一名文案，也就是5-6人完全符合一个软件作坊的人员数量。有时候团队小了，研发部经理就是项目经理，公共代码开发人员就是主程，这样，一个开发团队也就是3-4人就OK了。但方法照样能用起来。因为我所讲的方法也就是适应于这四套马车的组织架构的。每个人都身兼数职，而且都对自身的提高非常有好处，而不是给他身上堆砌毫不关联的工作内容。每一项职责都是能互相互补的，整体提高他的岗位专业性。
作为业务开发组组长，他很大的一个职责就是开发项目的进度和质量管理。手下也就1-2个人，开发人员的素质也就这么高，我们也会经常遇到突然来了个项目的事情或者突然有个过去的项目问题必须开发人员跟踪，所以开发人员也总是会被左抽右调。对于还能保证开发进度正常，业务开发组长确实每天都在监控进度异常，监控每个开发人员目前身上背着的开发任务和开发进展。每天下午5点的时候都要询问一下自己手下这两个人的开发进展。因为有的人不喜欢主动说自己遇到的什么问题，总喜欢自己去到处找答案，弄的延误了正常的开发计划。所以，开发组长必须每天下午5点主动问遇到了什么问题，是不是很棘手，能不能保证进度。如果不能保证，业务开发组长就会想办法，是全小组一起诊断出谋划策呢，还是寻求公共代码开发员呢，还是寻求研发部经理呢。为什么是下午5点？主要因为 5：30-6：00就下班了。如果快下班了你才去问，大家早就心思不在这里了，谁都想赶快下班回家，问题就被隔了一夜，留了个不清楚的尾巴。如果在5点钟询问，有了问题，如果此问题业务开发组长有经历，他会很快决定该怎么解决。如果详细听完了此问题的来龙去脉，业务开发组长也无法决定，他已经清楚了问题，他会在晚上思考，第二天一上班来就有了决定。这就一叫一点都不耽误。
我们使用的是BUG管理系统来管理开发任务。这并不要紧，谁说BUG管理工具只能管理BUG。我们只需要解决我们的问题而已。当然，我们管理真正BUG的系统是另一套，只不过我们使用的是同一个工具而已，我们当然不会把BUG和任务混在一起。
来自需求管理系统中的需求，来自BUG管理系统的BUG，都会被业务开发组长来评估，根据自己团队当前每个人的工作量来适机添加、定优先级、分配任务、调度任务。也根据这个任务分配，哪些任务超期了，哪些任务完工了，哪些任务还没有开工，哪些任务正在进行当中，来判别开发人员的开发进度和工作量。
业务开发组长也会每日主动向研发部经理报告进度，简要说明一下现有问题和解决思路。进度列表，当然是从工具中导出的，列明今日关闭的任务，还没有关闭的任务。这样，研发部经理一思考：项目已经开始了这么多天，还有这么多任务没有完成，到期能不能完成，他就会思考是不是要做些调整。
对于项目进度，不管客户是不是需要必须在XX月XX日之前上线，我们都会设立一个项目最终结束的日期。而不能让项目随波逐流。
这个最终的项目开发结束日期，并不是由业务开发组长排脑门想出来的。
我在以前的文章中就有介绍。业务开发组长负责功能点清单整理、功能优先级划分、详细功能说明书编写。而且每编写一块就开始分配任务给开发人员。
在业务开发组长划分完功能优先级以后，因为每个功能的复杂性都差不多，如果某个功能复杂，就会再被拆分。业务开发组长就能预估出一个大概的项目开发周期。根据以往的团队经验，也能预估出给集中测试时间和集中文档测试打包发布的时间。这样，整个软件什么时候能最终出来，业务开发组长是有个预估的。如果一个团队是新组建的，每个人的能力还不清楚，预估就会有偏差，需要磨合才能得到经验值。如果磨合，我也会在以后讲到。
在实际分配开发人员的时候，就是根据这个总目标完成时间来倒推时间的。这个倒推出来的，有一个每个功能的完成时间周期，而项目经理对于某个特定的开发人员的能力预估也有一个时间，而开发人员自己对完成这个功能自己也有一个预估时间。开发人员怕完不成任务被追究，往往会把完成时间往后放1/3时间，甚至有人想偷懒干自己的活，会更多出自己预估时间一倍，也就是说自己觉得3天能完成，就说6天才能搞定。当然，业务开发组长也不是吃素的。业务开发组长也是开发出身，到底难度多大心里有数。而且业务功能就是业务开发组长设计的，如何实现，会遇到什么难点，自己一清二楚。而且天天管这帮开发人员，谁能力高低谁想偷懒，天天在一个办公室，谁不知道谁。所以，每个任务的时间，都会是业务开发组长在开发人员自己预估的时间基础之上进行调整，获得一个开发人员和业务开发组长都能接受的任务时间段。然后根据每天的进度报告来随时调整这个时间，让开发进度尽量能现实，而不是计划前就定好实际工作中就不能改。
对于项目进度的保证，还必须有一个条件，就是：我们不允许开发人员在客户现场开发，我们更不允许开发人员和业务开发组长不在一起。
开发人员在客户现场，往往开发进度和功能需求变更容易受客户控制，致使开发团队做的计划和设计都被客户视为扯淡的东西。开发人员不满客户的做法，但在现场又没有办法，只好敷衍答应开发权且应付。本来一个理性的设计，被客户自己自以为是的好做法而推翻。软件什么扩展性啊，兼容性啊，都被扔在了一边。来客户现场，就要听这个特定客户的，你必须口对口服务这个特定客户，你如果和他讲其他客户怎么办，他才不管呢，反正他付了你的钱，在你眼中他必须是你唯一的客户。（客户和女人一样，都希望是男人眼中唯一的女人，但现实的是，世界上都很多女人，而且很多女人都差不多，都要求她所对应的那个男人必须唯一）
另外，开发人员在客户现场开发，就无法实现每日构建每日测试。开发，是个团队配合的事情。一个软件，并不是开发人员就能全部完成的（许多老板都这认为有开发人员就行）。缺少了测试，质量就无法保证；缺少了文档，产品就是光秃秃的软件。而许多老板还认为测试和文档可以在代码编写完后可以做，真是对软件质量如何保证一无所知。
我们也不允许开发人员和业务开发组长分离。因为在开发当中，设计文档又不是代码，机器运行完就一种结果。每个业务开发组长的文档水平有高低，每个人的思考思路也不同。我们经常会遇到一个现象，就是用邮件、MSN沟通老出误会，而且由于不及时调整，误会越来越大，后来干脆气愤的直接打电话。而打电话呢，有时还不行，你问他理解了么，他说理解了，你根本看不到他的表情，你猜测不到他是真理解了还是假理解了。你以为他理解正确了，他也以为自己理解正确了。你问他进度，他说没有问题。开发出来了，测试人员又有自己的理解，到底这三者理解的是不是一个东西，谁都没个准。只有业务开发组长和团队一起工作在一起，每天能看到实际的软件，能面对面和每个人交流反馈，才不至于代码开发完毕才一看不行。有许多刚当上业务开发组长的朋友，往往和手下搞的很僵硬。手下认为他一天三变，频繁推翻自己的代码，很气愤。而业务开发组组长认为手下的理解能力低，多次讲都讲不清楚，还跟自己顶嘴，还不如自己去开发代码省事。完了，又回到程序员了。
我也同样不允许团队出现多种技术。多个技术，会让团队成本升高，每个人都得会多种技术。而我们做企业管理软件，要想上升赚钱，必须大规模一般员工团队低成本开发，这是我和老板都认同的一种思路。所以，我们必须使用最常用最普通的技术。除非没有办法。我曾经有一个手下，怕自己跳槽没有竞争力，于是老学习流行技术。PHP火的时候，他就学PHP。Ruby火的时候，他就学Ruby。如今网游和嵌入、通信、无线很火，他就开始学C。手机开发火的时候就学 J2ME。而且他还想有实际的开发经验，以在应聘中说自己拿这门技术做过什么。于是他想尽办法在项目中要引入这些技术。说：用.net，我没法保证性能和稳定性，所以我必须使用VC++。？？唬谁呢？大家都是开发出身，这个借口未免太可笑。
我也不允许团队使用最新技术。我们只使用最合适的技术。我们不要客户为不需要的新技术而买单。客户的水平只能管理了SQLSERVER这样的数据库，我们就决不使用Oracle。如果客户要求在unix上运行，我们就使用JAVA开发。我们谨慎的评价和引入框架，都在核心围绕客户能不能简单维护，我们有没有显著好处，我们面临最棘手的问题能不能很好解决。如果只能解决我们不怎么紧急的问题，如果只能解决我们通过人工或管理就能解决的问题，我们就不引入。一切的一切，都围绕速度、成本、质量在寻找解决方法。
我们也采取了每日构建每日测试，来保证软件的进度和质量。不每日测试，哪到什么时候才测试。到那个时候测试，会不会出现其他什么不可控的问题，我们都说不清。这种对未来的恐惧，让我们需要把风险控制到最小，到天，而且到今天。今天关闭的任务，明天一测试，就知道问题大不大。有问题的，必须由测试人员登记BUG系统，并且业务开发组长根据目前情况适机把BUG修复当作一项任务来添加。
我们也采用了版本管理工具。版本管理工具不仅可以使我们对比源代码差异，找回历史版本，随时打包更新版本，分支每个客户的定制需求，还可以是我们的一个工作的体现。大家经常会听到这样的话：不知道开发部这帮家伙在干吗？是不是故意利用我不懂代码在偷懒。
我们到底在干吗？我们能否证明。有的时候确实是，一个问题三两天都解决不了。我们真的不好意思说我们三天就做了一个功能。我们如果解释这般技术难题为什么为什么，老板更是没有兴趣听，他认为你在嘲弄他不懂开发技术故意拿技术问题来骗他。
我们能如何证明呢？能拿一些大家都能理解的方法来证明自己呢？所以，我想到了文档数量和尺寸大小，想到了BUG数量，想到了任务数量，想到了需求数量，想到了开发进度报告，想到了版本发布次数，想到源代码归档容量和源代码行数。
一个项目开发结束，任务数300多，BUG数量400多，文档尺寸70多M，项目历次讨论开会纪要30M，项目历次方案提交20多M，开发进度报告100多份，帮助文档100多M。这些都能量化都能看得见的东西，让老板觉得确实做了许多事。
我们曾经有一个客户，嫌10万块钱买了一张光盘，觉得贵死了。说地摊上一张才5块，你卖我10万。我们于是就把所有的帮助文档都打印了出来，600多页，装订成3本书，印刷好封面交给他。然后把软件装在一个很精美的木制盒子里，客户笑的很开心，把盒子和手册都郑重其事的放在了IT部门的柜子最上面。我想，软件是由代码组成的，确实不容易让客户理解其中的艰辛和付出，所以客户并不认可我们的付出。能拿客户可以理解的方式去讲明白就是解决方法。我一贯遵守的原则就是：要么解决问题，要么闭嘴。如果你想不出解决方法还抱怨影响团队情绪，那么滚蛋，这种人就是团队的毒药。
过去，我们讲了业务开发组长如何履行功能设计的职责的一些方法，今天，我们又介绍了业务开发组长在任务分配、软件进度、软件质量保证、工作量化的一些心得，这就是一个开发组组长的份内之事。希望能给被提上开发组长的朋友一些启发，不要把自己定为一个写代码的头儿，那样你不符合国内现状，国内的开发组组长就需要做这些事情。外国怎样怎样那是外国的事情，你也享受不到，这是中国。要么去做，要么老老实实继续当个程序员。