项目管理者如何应对需求的不断变化
| 主题：IT龙门阵第75期—创业者如何应对需求管理 时间：2009年5月19日 地点：清华紫光国际交流中心B2第一会议室 主办：TechWeb 腾讯科技 大度咨询 主讲嘉宾：《走出软件作坊》作者、北京润霖汽车科技有限公司CTO吕建伟（网名：阿朱） 5月19日IT龙门阵邀请到了《走出软件作坊》的作者吕建伟（网名：阿朱），从外表上看给人一种很实在的感觉，这是我的印象，听完他的演讲，我也更加肯定了我的感觉是对的。他很热情的分享了他在信息化十多年来的一些工作经验，并且从亲身经历的一些管理经验举例说明了一个成功的软件是如何完成的，阿朱还介绍到，如何作为一个成功的底层的信息化开发项目经理，你只要懂技术，不需要要会写代码也能成功。阿朱这次演讲从五大方面来阐述了创业者如何应对需求是魔鬼这个问题。 1、需求是如何变成魔鬼。 阿朱从五个小的观点（进度、加班、成本、终结、情绪压力）来阐述了项目开发中怎样产生的把需求变成的魔鬼，如何用什么方案来应对这些问题。 2、要从战略高空进行掩护。 阿朱阐述了，开发需求的前期，要进入到这个行业领域，真正深入到这个行业，做到和客户拧成一条绳，做到亲身体会客户的需求，和客户打成一片，真正做到你中有我，我中有你。 3、组团轰炸。 阿朱阐述了，一个成功的项目，从开始提出需求到真正落实进行项目开发，需要不同分工的人员进行协同合作，从高层到底层，层层相互“掩护”，让客户感觉到，你是在下大力气在和客户进行交流，是一条心在为他们做，而不只是靠嘴皮子说。 4、集中火力 快速定位 阿朱阐述了，在一个项目开发过程中，项目负责人是一个唯一入口，他是一个项目成功的关键。并且从需求、范围、调研、设计、验证五个方面来说明项目开发的一些细节问题，让项目开发事半功倍。 5、兄弟连搞定 阿朱阐述，在开发过程中，开发人员协调工作的必要性，还阐述了如何调动开发人员的积极性，怎样让一个分散的项目个体最后整合到一个完整的项目。
高朋满座
阿朱 主持人：我们的活动马上开始。各位网友大家好，欢迎大家来到IT龙门阵，今天我们邀请到的嘉宾是阿朱，阿朱请。 今天我们在座70后的有多少？70后朋友会知道，软件开发在十年之前是一个非常不错的职业，今天经济形势不太好，职业也不是很好找，但是阿朱坚持了下来，他写的《走出软件作坊》，今年一月份刚刚出版。有请阿朱！ 吕建伟：我跟大家一起交流，因为我从事的行业，我只从事在企业信息化行业，在切入式软件、互联网，我全没有做过，今天我讲的经历跟大家的具体的实践切合不是特别紧密， 但是我把自己奉献出来，我今天演讲的主题跟需求有关，做企业的信息化需求比大家做消费类软件和互联网软件更加难以把握，因为大家想做一个游戏，或者想做一个什么东西，很多的思路都是咱们观察这些用户，观察消费者，然后把需求做进我们的功能里面，哪些不能做、哪些能做，都是由我们控制，做产品类、消费类、娱乐类的，其实比较好把握需求，在我从客观层次上去看，对于企业来说，有时候我们为了收回企业的款，不得不满足它的需求，这需要如何平衡需求和利益的发展。 我演讲的思路，需求的不仅仅是一个环节，软件开发当中，很多把需求看作一个环节，但是我们做信息化过程中，我们把需求当做一个战略来管理，首先在战略上引导，然后在收集、验证，再把需求转化成我们的设计、编码，然后成为一个产品，然后把产品推广，落实到客户的使用应用，这样的需求才能落地，所以我的演讲思路是这样一个思路，在高中低各个层面多管齐下，才能把需求这个魔鬼杀死。 比如咱们是一个研发中心的管理者，或者项目经理，或者CTO，或者技术总监，大家想一想，我们作为管理者，最主要的是管什么，我们每天在工作中焦头烂额，我们跟谁做斗争呢？最主要是跟产品的需求和功能在做斗争，如果需求管理不好的话，最重要影响的肯定第一个是进度，咱们把进度定在第一位，因为咱们添加很多需求以后，我们首先想在这个月把这个版本推出的话，我们总是希望把竞争对手出的特性加入我们的版本，但是我们的产品老出不了，总希望完美，但是没有完美，我们总是把它定义在一个商业性的成功。 第二就是影响质量，因为我们的程序员不可能一天工作25个小时，一天不休息，也就是24小时，我们的企业有成本，有限的人、有限的时间内，要做更多的事情，质量肯定没有办法保证，很多人说我们的软件越来越不稳定，根源是需求的控制。 当然跟技术相关的可以加班，我不希望我们的团队加班，比如他今天晚上加班了，加到凌晨一点了，第二天肯定不能早来。大家都这样做，客户一看，这个公司怎么回事啊？全都在睡觉，这个公司的管理相对比较混乱。而且人的生理周期在晚上有睡眠休眠的期，有的人白天有劲，晚上没有劲，身体状态受到很多的干扰。 还有一个就是成本上。还有一个终结，永远没有一条要结束的路，我们总是在这儿不断的赶，有一个网友对我说，我们现在怎么办？员工人心涣散，经过我分析，大家太疲劳了，好象不知道这个事情该做到什么程度才算完结，什么时候是个头。咱们先阶段性的终结一下，做开发的都一样，需求会影响方方面面的团队，不仅仅影响我们的产品，还影响我们的人。我们要杀死它。 怎么杀死它呢？开发经理只负责开发部门在需求管理整个产品的设计方面，他的力量是处于公司的中层，但是客户可以直接给老板打电话，老板压给开发经理，开发经理没有办法，只能做，这个事情变得很尴尬，不断的越权，不断的产生冲突，在我们的实际中，不仅是解决了老板和中层的矛盾，也解决了公司内部和客户之间的矛盾，大家走到一条线上，在战略的高度上去重视它，我们首先在行业协会做一些事情。 因为做企业信息化方面，我们总是跟行业结合，以前是医疗行业，后来是汽车行业，很多行业信息化，这些行业都是传统企业，不属于IT企业，他们往往有行业的会议、展会，我们也会参与其中，当我们在2005年的时候，第一次参与汽车行业的会议，参加的时候发现，别人问我们是哪家汽车公司？我说我们不是做汽车的，他们不明白为什么我们这样一个另类坐到他们的身边，但是讨论议题的时候，我们会和他们一起讨论，我们也会针对这些问题去讲，我们不讲IT，我们参与到其中，跟他们是一样的，这好像张楚的歌里唱的：和大伙儿一起去乘凉。我不是IT企业，我是你们的一员，我就是汽车行业。 经过不断几年的发展，比如今年我没有去参会，可能他会觉得很别扭，每年有这样的公司，现在不在了，所以说我们在行业协会这儿，我们做了很多的事情。 我们很多的人全在第一线，在跟着客户一起贴着客户飞，我们公司是这样的，有咨询部门、培训部门、客服部门，销售部门、实施部门，全在客户的第一线，我们会做常年的培训、咨询，而且跟客户零距离的客户服务，实施、培训。这些人在第一线，跟这些企业的用户在一起，有些企业的用户如果对我们有一些疑惑，或者对我们产品不是特别深入的了解，我们的员工在第一线跟他们不断的讲，我们有什么好处，什么价值，怎么使用，这样一个事情，如果不这样做，跟用户的距离会远一些，产生的误会会越来越多，如果我们的员工这样做，会形成亲人间的亲密关系，中国人关系到位了，大事化小，小事化了。 而在产品上，我们也知道用户第一手的想法，我们的产品也符合客户的应用。而且我们的企业的很多销售单子，并不是我们宣传说我们有这样的方案，有这样的产品，我们很便宜，我们不是这样销售，我们很多销售都是客户主动提出来的，然后成为一个合同，成为一个产品。 还有你中有我，我中有你，我们公司的很多人不是来自于IT的行业，不是来自程序员，很多人来自于这个行业内，也就是说，我们公司一些中层、包括一些高层，是从汽车厂商或者汽车的经销商来的。客户的人已经变成了我们的人，我们的人客户做一些事情的时候，往往没有资源，我们的客户往往是国企型的客户，往往想指挥手下的小兵的时候，会发现大家都是国企，你指挥不动，你辞退不了，他们想干活，机制不是很灵活，我们会派人，这个人的工资我们先付，你想做什么事情，我们做，把我们的人嵌入到你的企业里面，我们和客户绑在一条线上，不分彼此，这是在战略高度上的考虑，没有客户，没有厂商，大家是一伙的。 我们是组团的轰炸，一开始我们公司小的时候，比如一个单子，50万，或者100万，你需要什么，咱们改，不满意，再改，这样我们就钱挣了，公司越来越大，单子额越来越高，他会提高你的要求，比如200万的单子怎么样做到一些规则，我们为了使公司发展得更大，我们总是在一个项目里面会出现多达10—20人，也可能这个项目是一个比较小型的项目，但是给客户做方案的时候，我们肯定是商务经理和开发项目经理一起工作。开发项目经理去做演示、商务是为了请客户吃饭，保持客户关系。这样各有结合，把客户吸住了。 在开发阶段，开发项目经理会率领开发人员、测试人员、文案人员去那个团队工作，会报告很多的文案档案，实施的时候，我们把实施和培训分开，项目经理负责实施推进，培训也要做很多工作，真正把培训做成培训认证，这样我们有了常年培训部门存在。我们有专门的呼叫中心的系统，我们还有咨询部门，这些咨询部门每年会给客户做一些题解式的公司，IT系统运用一年以后，哪些指标提高，降低，对你的业务有什么影响，都是我们IT部门在工作，客户会觉得我这个项目很值，我受到了全程关注，而且不是一两个程序员，是很多人的关注，这个都有专业性。 在团队的层面上，如何框定在一个框架，如果你自己做得专业了，你的企业做事也会正规的去做，这都是相对的，这是一个很规整的环境。 高层中层讲完了，我们会落实到需求的收集，现在需求来自很多的部门，包括老板，我们的老板去客户那儿进行寻访，客户会提出一些需求，我们老板会直接打电话，很多人可能遇到这个问题，包括现在我们也遇到，但是不管老板还是谁直接跟我们打电话，我们会记录在需求库里面，很多人说，口头说的不行，必须写邮件、或者盖戳什么的，其实这是在拒绝客户，我们不希望这么做，客户的需求是我们财神的来源。 我们全会归到需求库里面，而且我们同等的关注，而且是统一的负责人，也就是说，有很多人，比如某一个呼叫中心的客服小姑娘跟开发部门的程序员好，我们不要这么做，我们会把这条线断掉，我们会有一个唯一的负责人，这个产品项目属于哪个开发经理的，不管是什么部门的需求，全找他，如果不通过他这块，这个需求没法落实下去，因为开发经理要给他的开发组下达任务，如果不安排在下个月的开发任务当中，这个需求怎么会得到满足呢？而且我们比较严格，不可能去满足没有记录的需求，我们有唯一的负责人，有唯一的需求库，而且全体知道。 这些需求我们开会了，我们要给客户答复，这个客户是谁负责的，我们也会告诉的，如果客户提的需求非常多，非常的刁难，商务经理也会出面做这些事情，很多人会做这个事情。 范围上，刚才把需求从唯一的口收集进来，由唯一的人负责，我们会把需求框定范围，限定每一个月内我们能完成的事情，客户会提出很多需求，我们也经常会听客户说，你让我语音输入吧？这样的需求提出来，会怎么做呢？我们往往把它定为一个月能够完成，如果超过一个月，我们没有办法控制，如果一个事情需要半年才能完成，我们真正做的时候，现实跟计划脱离了，我们不希望脱离，所以我们限定在一个月时间内完成，就是分阶段了，我们实现企业信息化，我们需要效率更高，团队协作更好，这些目标非常的模糊，我们要量化到可落实的，我们库存周转，过去是20天周转，我们能不能降到15天？我们想让我们的团队更加透明，这个目标是个假的目标，我们一定会在目标上、时间上框定好几个最着急的目标，做完一个阶段，我们实现一个阶段，我们把这个项目分成好几个月，一个月一个月的完成。 我们有调研这块，很多人调研，想什么说什么，这些人认识的高度层次不一样，你全部记录下来，然后去开发的话，你其实在画一张画，如果人家说了一半的话，你就画了半张画。 画一张素描会比一张照片还值钱。当然一幅向日葵花比一个照片值好几千倍，我们开客户研讨会，让客户不断的说，这是释放他的需求，也许这些事情说出来不一定实现，只是让他对过去的感觉说一下，这是我们以后做好的一个亮点，客户将会非常的感激。 我们会进行咨询的调研过程。刚才讨论的客户需求，咱们先放一边，企业每一个部门的组织结构是什么，每个人的职责是什么，你们干每项过程的时候，使用的表格是什么， 如何表现这个工作。我们先把企业拍了一个大框架，先搭建一个大的结构，然后把需求落到这个大框架里头。就是看哪个事情的哪个环节有问题，我们会落到那儿。 从这个观点，大家会思考，我们总是会把需求越掐越紧，最后范围非常小的一块，我们会做这个，不是随便的做。 当然我们设计的时候，有的单位通常做UML，但是客户不懂。我们的做法是，客户最熟悉什么样的工具，我们就使用什么样的工具，用客户的思维思考，我们做企业的管理软件，大量的输出表单、查询表单，我们是用EXCEL设计的，输入客户名称、地址。日本外包的项目，界面非常的精确，我们没有这么做，我们只是对内部说，客户要的就是这样的，明确就行了，咱们达到咱们的目的，用咱们熟悉的工具做最小成本的事情，用EXCEL做界面。 在管理软件里头，有一定的业务流程，我们会把它做到PPT里头，很多动画能够自动的跳转，这是PPT很擅长的分析。当然如果这些都不能很好的说明，我们就用文字表明，就用VISIO和WORD。 我们做完这些设计，不是立即投入到开发当中，开发项目经理成为一个靶子，需要让人来打，因为这些东西都是他做的，测试人员、开发人员和文档人员同时测试，如果测试人员不满意，必须修改，这个东西什么对，什么错，你先告诉我，给我一个定论。开发也会做。如果测试人员说这份文稿没法开发，写到这儿模棱两可，不能用这样的语言，我不是这样理解的，这样，开发经理也会把这个文档进行丰富、修正，直到测试人员能够测试，文档人员也能够写说明了，开发人员可以开发了，现在大家可以进行编码了，我们达到大家的一致性就OK了。大家经常在工作，如果有一块确实理解得不是一致，我们会开一些小会把它变更，当然变更的东西，我们会放到库里面。 编码的工作已经讲到，我们在一起工作，千万不要脱离它，全体开发组员都要知晓，要及时的开会，我们让用邮件，让大家都知道这个事情，然后进行文档，我们要知道，这条思路为什么要这样的发展。 在进行工具化完以后，我们进行开发，开发要有一个计划，我们这个月一个月其实是22天，而不是30天，我们首先需要把这个概念弄清楚，先是程序员自己做自己工作量的估算，你觉得这个事情是几天，你自己估计，我们会看跟客户要求项目的周期是否一致，如果超期，我们会缩短一些时间，会做一些平衡，肯定是一个互相商量和平衡的时间，如果是开发经理和开发人员商量了以后，还超过客户要求的项目时间，我们会砍功能，开发经理做这个事情，我作为CTO，我会拍板，也许会简化，这样也是个需求更改的过程，我们在工作量的平衡，其实是开发人员，开发经理定，最后我拍板定。
听讲观众 而且开发的时候，有一个人负责所有底层的工作，中国要不要架构师？其实对于中小型的团队，中国需要的架构师数量比较少，我把它定为公共开发人员，大家会想，大家到底要做什么样子。经常有时候，每个小软件没有问题，但是凑到一起，会有问题，为了防止这样的问题，我们有公共开发人员，你的模块自己调自己的，千万不要调用或者改写别人的东西，如果非要改写，让公共开发人员来做，做一个接口，两个连在一起，到底谁修改了，找公共开发人员就可以，问题有了负责人，我们的问题有人来控制了，而不是相互的扯皮。
|