为什么要在产品线建立统一的需求管理组织
- 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。
为什么要在产品线建立统一的需求管理组织
1.为什么要改变现状?
由于按产品线组织机构的调整,以及人员的更迭必然造成现有组织的适应性减弱,因此对组织进行调整以适应新的形势是历史的必然。产品线组织往往承揽三类不同的工作,其一是正式版本的改造升级;其二是样板客户的开发维护;其三是小客户的改造处理。三类任务有其不同的目标,也有其不同的要求。第一类任务目标是使产品更稳定、质量更高、架构适应性更强、客户化开发速度更快;对人员要求是能力更高;对时间要求相对较为宽松;第二类任务目标是满足样板客户信息化需要,确保样板客户实施成功,同时从样板客户开发中获取更多的需求弥补正式版本的不足;对人员要求是能力要强,对时间要求视客户要求而定,通常略显紧张,一般紧迫度相对较宽松;第三类认为目标是快速实施成功;对人员能力要求相对较弱,对时间要求紧迫。针对这三类不同任务目标必然有必要采取有针对性的组织架构加以应对。
在产品线从事企业管理的一段时间里,需求组织一直作为一个相对独立的团队存在,由于多方原因让开发/测试(主要是开发人员)对需求工作产生一定看法,主要集中于:1)需求不能与小组形成一致的小组目标;
2)需求不能与小组的计划保持一致性;
3)需求在我需要的时候不见了;
4)需求未能满足小组的要求等等。
造成问题的原因很多,不一一阐述,但是我想无论是开发小组还是需求团队大家的目标是一致的,这就是团队的目标。每个开发小组的目标是团队目标的分解,不能片面或孤立的看小组织的目标,之所以表象上有不一致的情况存在,原因在于需求和开发小组任务性质和时间差造成。由于开发和测试的工作都是晚于需求工作而开展的,开发小组任务往往晚于需求分析工作开始,所以需求工作于小组计划一致性有差异。而从另外一种意义上说,正是由于这种差异需求分析工作反而加速了客户化开发的进程。
至于出现的需求人员出差的情况是属于团队工作和目标实现的需要,属于不可抗力,不可避免也无法阻挡。至于需求工作成果与开发/测试工作要求存在距离,这属于需求规范管理问题与组织无关。组织任务开展必须遵循统一的规范和制度,而不是随领导者风格和心愿
随心而欲。
2.怎么样构建内部组织?
组织管理架构无非就三种模式,矩阵型、职能型、项目型。对于产品线这样的目标、任务、岗位相对比较简单和单一的组织而言,矩阵型组织非常不适合。矩阵型组织带来的问题是管理复杂化,多重领导造成基层人员无所适从,造成任务拖延和低效,无论是强弱矩阵总有一方管理权威受到影响,不利于工作开展。因此矩阵的模式不予以考虑。
那么采用项目型还是职能型呢,我认为要看组织内部情况而定。开发和测试人员一方面由于资源相对比较充足,另一方面能力分配相对均匀。可以考虑形成内部的小组,考虑到S 项目组承揽任务的实际情况(参阅第一节说明),倾向于分成负责正式版本开发(含样板)和客户化开发的两个组织,其主要原因是一客户化小组承揽非样板的客户化开发工作量较小的工作,这样该组织对人员能力要求相比比较低,投入力量较小,又比较专一,符合此类客户小规模、低改动、快响应的需要,将主要人员集中于正式版和样板(含客户开发工作量巨大的非样板客户),符合该项工作对人员能力的高要求,也符合此类客户大规模、高改动、弹性响应的需要。同时集中优势兵力,攻坚正式版本和样板客户对产品的标准化推动意义重大。
形成两个组织后,内部是否继续分组,视同管理风格而定。倾向于小团队管理的同事,可以根据敏捷管理的要求,要形成三人团队。但这不影响整个组织架构,不影响人员的管理关系、任务的分配关系。
需求团队是否也应按此划分呢?我认为可以考虑派驻一需求工程师长驻客户化组织,负责交底答疑和解惑以及紧急反馈问题的回复,但是要归属整个需求组织的管理。也就是说需求组织仍然要在大团队下独立存在,为什么要这样,因为:
可以充分协调资源。由于需求人员相对较少,人员参差不齐,形成统一团队利于资源共享、利于人员成长、利于团队目标高效达成;
可以满足需求工作前瞻性的特性。由于需求和开发工作不同,开发工作通常在有任务要求和需求完成前提下开展,缺少前瞻性。而需求工作可以在问题反馈的同时、调研的同时即开展,无论此任务最终计划如何编排,需求都可以先期完成。这是需求工作的特点,及时解决用户的反馈,可以创造良好的用户感受,同时也有利于问题的解决,时间越长问题的清晰度越差,解决的难度则越大,这是开发工作不具备的特性。
可以满足团队任务的需要,除去小规模的客户化任务外,需求工作往往要承揽较大规模的任务,这需要团队的协助,需要统一的分工管理、协作和努力。比如:需求分析、正式版本分析、新版本升级、大客户调研等等。
可以满足通盘掌握,全局掌控的要求。一方面所有人轮流承揽不同的项目,有利于个人成长,另一方面业务线人员可以实时掌握该业务线新的业务需求和进展。
3.做什么来解决问题?
基于上述架构,考虑到大众的反应,可以做一定层次的调整。需求人员实行业务线和产品交叉负责的方式。也就是说每2个需求人员负责指定的客户(不含样板),同时负责一条正式版(样板)的业务线。需求人员在时间允许情况下,全程参与所负责产品的相关活动,如晨会等。业务线需求人员也可以和该业务线开发测试组织敏捷团队。针对问题解决问题,高效高质是团队的目标。
4.综述
改革是阵痛的,但又是新生的。但是我们不能为了改革而改革。清晰了目的,才能做出正确的判断。