热门标签 | HotTags
当前位置:  开发笔记 > 后端 > 正文

我们的管理:定制研发管理

我们的管理:定制研发管理一、组织结构我们先按照客户规模分类,行业500强之外属于非战略客户定制研发中心,行业500强属于战略客户定制研发中心。在战略客户定制研发中心又细分为核心战略

我们的管理:定制研发管理

一、组织结构

我们先按照客户规模分类,行业500强之外属于非战略客户定制研发中心,行业500强属于战略客户定制研发中心。在战略客户定制研发中心又细分为核心战略客户定制研发团队和非核心战略客户定制研发团队。核心战略客户定制研发团队是一个客户专属的,也就是说这个团队全体成员只为这一个客户而服务,不会被其他项目组抽调,当然前提是这个客户和我们签订了长期发展框架规划,可以保证每年300-500万的IT综合投入,这样我们就可以单独设立团队。对于达不到这样级别的非核心战略客户,我们是把客户按省区划分,大客户大多集中在北上广深,所以我们匹配的项目团队也会大一些,对于一些省区客户比较少那就多个省区合并在一个项目研发组,这样每个客户都有了明确的项目团队在对应。

再打开每一个项目研发团队来看,又被细分为两个组,一个组叫快速开发组,一个组叫大项目组。大项目组一般承接客户的定制周期超过20人天以上的需求合同,往往是一个业务模型或业务流程的整体改变而非小修小补,客户对时间要求不太高,但对质量要求高,因为这样的定制往往涉及的修改面大、关联项多,所以需要很好的系统设计/评审、编码调试、测试验收、更新验证、正式上线,这必然需要时间长、协调团队多,项目管理复杂,所以这样的项目必须设立一名项目经理。对于快速开发组,往往是紧急Bug需要赶快修补、客户高层提出的小工作量需求需要快速响应。这个小组就以开发Leader为中心,带领两名开发一名测试,开发leader负责和一线进行需求确认、负责进度推进任务分配、系统修改设计、代码审查,甚至做核心代码修改编写。因为这个组负责的项目在1-20人天,张力很大,虽然大多是5人天以下的修改任务,所以遇到10-20人天的中型任务也会有不少轻型项目管理工作。

二、定制研发流程

对于战略客户和非战略客户,需求来源也不同。

对于战略客户,我们采取的是战略合作长期经营的策略。我们在一线有专门的战略客户经营团队,这个团队以一线大客户经营团队(偏销售)为领导,整合市场、咨询、销售、实施、服务各个部门经理,为自己管辖下的每个战略客户制定年度经营计划。我们是每年第四季度开始制定,先对该战略客户今年的扩容购买、实施、培训、定制、运维、支持做总结,然后建议规划明年的IT发展。我们会拿着这份总结规划报告与客户IT部门、业务部门一起开IT发展讨论会,对彼此明年的IT规划进行了解与融合,形成了甲乙双方共同认同的明年IT发展规划。我们也会促进甲方进行各个项目的立项,这样就能预先锁定我们各个部门的工作事项、业绩、人员需要、上下游链条配合。在这样的框架下,定制研发团队的需求也就被基本锁定了。

对于非战略客户,需求一般有三拨,一是新购买模块的实施阶段会有专门的需求调研,这时候会聚集一批需求,另外是实施试点推广阶段这时候基层业务用户都开始真实使用系统了发现有些实际操作还是和之前讨论的不太符合所以会再进行一拨修改,最后是实施阶段结束把后期持续提升交给服务部门,服务部门会根据该客户的应用情况制定服务规划,这就会有最后一拨定制需求。在持续服务阶段的定制需求就大部分以查询报表制作为主。

定制研发团队还会接到内部团队推送过来的一些定制开发专项。

一方面是来自产品研发中心,每年会有一批产品重要漏洞补丁包,需要定制研发中心针对不同客户购买的不同版本的不同模块进行补丁升级。虽然我们的产品接口是明确且有工具检查的,但过去的定制需求还是会或多或少的新增或修改一些接口,所以还是有一些整合开发工作量的,尤其对于测试,企业管理软件的数据是按流程变化的,所以这一处代码的融合不仅要验证功能逻辑正确性,还得扩散验证往下走的几个环节是否也处理正常。

对于产品研发中心推送的补丁包,我们遵守自己吃自己的“狗食”才能更好的激励我们自己的原则,所以要求定制研发中心选择一些客户项目,由产品研发中心派骨干人来参与这些客户项目的修补工作。让产品研发团队自己独立干吧,这里面还有很多客户定制的业务与代码是产品研发团队所不了解的,可能不仅会修复不了问题反而引入更多新的问题。让定制研发团队自己干吧,这是产品研发团队埋下的地雷,一定要让产品研发团队吃吃苦头,在实际劳作中琢磨为什么过去犯这些错,以后如何保证不犯,并且在做开发的时候也在反思自己以后制作的补丁包如何更快更高质量的整合与测试。另外,在日常定制开发中也会发现一些产品遗留的问题,定制研发团队修复自己客户问题的同时也会记录一条需求给产品研发中心,这就是产品研发中心每年制作补丁包的需求来源。所以说产品研发中心和定制研发中心是相辅相成的。

另一方面是来自服务中心运维团队、技术支持团队推送过来的一些问题。他们在给客户做系统运维监控检查、疑难问题异常问题跟踪查错中会发现一些隐藏的软件问题,这些也需要穿插安排到日常的开发计划中。

我们有一个需求管理系统,所有人,可能也包含销售人、实施人、服务人、运维人等等,他们在产品演示时、客户走访时随时随地发现的一些问题,都会记录到需求管理系统中。不进入系统的需求我们定制研发中心团队不予处理。进入系统也要详细记录什么人在什么时间收集的、什么系统什么功能、需求描述/截图/报错信息、需求提出人/提出人部门和岗位/提出人联系方式,这样便于后续深入了解需求、并且安排计划。我们的计划系统中的每条任务都会关联到一条需求编号,完成该需求的开发任务后会推送一条通知给当时的需求登记人。

来自外部的需求都由项目经理来统一对接,项目经理和需求登记人一一了解需求概况以确认需求的重要级别以便根据自己现状安排后续任务。我们有服务响应时间服务解决时效级别,不同的需求重要级别有不同的对应,超过时限没有达成目标,系统就会自动发送预警,根据重要级别发送给不同级别的人。服务响应时间服务解决时效级别也是定制研发团队、服务中心各个团队都共同背负的绩效指标,大家按照流程要求进行升级联动。

对于典型的功能、常见的修改,我们的最佳实践标准委员会总结有一整套工作量评估方法可以帮助项目经理估算合理工期。我们在研发这套工作量评估方法时就类似丰田流水线改善一样进行现场观察、时间记录、动作分解,把需求讨论、确认、设计文档编写、评审、开发环境准备、代码修改规划、代码编写与调试、自测、测试方案准备/测试环境准备/测试数据准备/测试/测试报告编写、Bug分析/Bug修改设计/Bug修改与测试、回归测试、打包发布的时间都进行了详细的切分与计算。经过我们实际工作修正,我们的这套工作量估算表越来越精确了。虽然我们还达不到客户所期望的那样快速度低成本高质量,但至少我们先做到承诺的计划必达。

除了典型功能常见修改,我们会有一些不成熟系统、一个大变更版本、或者是新技术、高难技术,在定制前三家客户时,我们采取的方法是产品研发中心和定制研发中心联合作战,共同背负项目质量和项目进度绩效指标,我们称作扶上马送一程的流程机制。具体说来就是产品研发中心承接这个客户的定制任务主体,按照定制研发项目管理流程进行运作,派定制研发中心的骨干团队坐在产品研发团队工位间里和产品研发团队一起工作,在实际开发中传帮带做知识转移。到了第三家客户定制时就以定制研发团队为主体,产品研发骨干进驻做指导、咨询、验收工作。对于定制研发中心再有这样的新项目时,就由定制研发中心独立承担,定制研发中心这几个先遣火种人就对其他项目组进行这样的内嵌传递工作。如果有些复杂问题连这几个火种人都没法解决,就再升级给产品研发中心特定的对口人。这样就是扶上马送一程。所以我们的上下游链条协同,有明确流程、明确对口人、明确时效要求、明确的共负绩效指标。

定制研发团队和我们所有项目团队一样也是天天早立会、晚上日报、周五PMO会、月度PMO会、月度与一线实施/服务召开项目资源计划接洽会。这都是一些很定期的管控动作。

三、绩效

定制研发团队也是360度的、平衡的绩效指标体系,量化的时效进度/质量指标都可以系统中自动统计、项目经理和上下游岗位会对团队配合、成就客户进行评分、部门经理会对学习成长总结分享进行评分。

但我们对于定制研发中心还有项财务指标的评分,目前还只是定制研发中心总监在关键背负。这是因为我们的需求定制是一个合同一个合同的,每个合同都根据甲乙双方认同的工作量与进度进行推进,定制工作量是计算合同费用的关键依据。比如项目经理、系统设计、开发leader、开发人员、测试leader、测试人员、QA人员,都在什么阶段工作,各个岗位在每个阶段工作量是多少,每个岗位的人天报价是多少,这样一张复杂的工作量-费用计算二维表就产生了,根据这个模板就能很容易算出合适的工作报价。所以干什么活、什么人干活、干多少活、干多长时间、费用多少,这些合同判断的关键都能很快算出,就能很快推进项目启动。

我们目前对定制研发中心考核的是利润率,但还没有细化到每个项目,项目经理目前有人员选择权、计划任务管理权、绩效评价权、项目经费管理权,还没有财务核算权。我们以后会逐步做到项目级的财务核算。现在我们在一些需求变更严重进度超时严重的项目已经实行项目财务核算与控制了。

但就是这样还不算完。企业应用软件行当有句俗话:“软件公司都是被撑死的而不是饿死的。”这说的就是定制研发中心,随着企业逐年做的客户越多,定制开发的总规模量就越大,这样定制研发中心的人数就越来越多,最终导致刚性成本巨大、组织缺乏弹性、组织规模太大引发组织崩溃。

为了有效控制规模、成本弹性,我们也引入了外包驻场团队。主要是中级开发人员和中级测试人员,可以有效弥补我们中腰的成长速度成长数量的短板。其招聘面试、训练营上岗证走的是我们正规的人才成长体系,在项目团队工作中也走的是统一的项目管理流程,走的绩效考核也和我们员工一样,享受的普遍福利待遇也和我们员工一样。

我们并没有只是简单的把外包团队看作是我们一个有效的补充,而是我们的一个大战略布局。我们必须突破模式,让我们的定制研发能够形成合作伙伴产业链模式。我们也希望采取扶上马送一程形式,现在是外包团队驻场受我们管理,以后我们的项目经理、系统设计师、开发Leader、测试Leader可以驻场外包公司,再未来我们就可以输入我们的管理流程、培训认证、成果标准、IT协同管理平台,我们就真正成为轻公司了。


推荐阅读
  • 58同城的Elasticsearch应用与平台构建实践
    本文由58同城高级架构师于伯伟分享,由陈树昌编辑整理,内容源自DataFunTalk。文章探讨了Elasticsearch作为分布式搜索和分析引擎的应用,特别是在58同城的实施案例,包括集群优化、典型应用实例及自动化平台建设等方面。 ... [详细]
  • 智能全栈云风暴:AI引领的企业转型之路
    当提及AI,人们脑海中常浮现的是天才少年独自编写算法,瞬间点亮机器人的双眼。然而,真正的AI革命正由大型企业和机构推动,它们利用全栈全场景AI技术,实现数字化与智能化的深度转型。 ... [详细]
  • 随着5G、云计算、人工智能、大数据等新技术的广泛应用,人们的生活生产方式发生了深刻变化。从人际互联到万物互联,数据存储与处理需求激增,推动了数据与算力设施的发展。 ... [详细]
  • 我的新书已正式上市,可在当当和京东购买。如果您喜欢本书,欢迎留下宝贵评价。本书历时3至4年完成,内容涵盖MySQL的安装、配置、开发、测试、监控和运维等方面,旨在帮助读者系统地学习MySQL。 ... [详细]
  • 强人工智能时代,区块链的角色与前景
    随着强人工智能的崛起,区块链技术在新的技术生态中扮演着怎样的角色?本文探讨了区块链与强人工智能之间的互补关系及其在未来技术发展中的重要性。 ... [详细]
  • mysql 分库分表策略_【数据库】分库分表策略
    关系型数据库本身比较容易成为系统瓶颈,单机存储容量、连接数、处理能力都有限。当单表的数据量达到1000W或100G以后,由于查询维度较多, ... [详细]
  • LambdaMART算法详解
    本文详细介绍了LambdaMART算法的背景、原理及其在信息检索中的应用。首先回顾了LambdaMART的发展历程,包括其前身RankNet和LambdaRank,然后深入探讨了LambdaMART如何结合梯度提升决策树(GBDT)和LambdaRank来优化排序问题。 ... [详细]
  • 个人用户可借鉴的企业级三大安全准则
    在数字时代,个人数据安全变得尤为重要。本文将探讨三个来自企业实践的安全原则,这些原则不仅适用于企业,也能帮助个人用户提升自身的信息安全防护水平。 ... [详细]
  • 在现代社会,学历被视为重要的个人资质证明。因此,教育机构的学历数据库成为关键的信息资源。一旦这些数据库受到攻击或数据被篡改,将极大增加假学历的识别难度。 ... [详细]
  • 自SQL Server 2005以来,微软的这款数据库产品逐渐崭露头角,成为企业级应用中的佼佼者。本文将探讨SQL Server 2008的革新之处及其对企业级数据库市场的影响。 ... [详细]
  • 深入解析Apache SkyWalking CVE-2020-9483 SQL注入漏洞
    本文详细探讨了Apache SkyWalking中的SQL注入漏洞(CVE-2020-9483),特别是其影响范围、漏洞原因及修复方法。Apache SkyWalking是一款强大的应用性能管理工具,广泛应用于微服务架构中。然而,该漏洞使得未经授权的攻击者能够通过特定的GraphQL接口执行恶意SQL查询,从而获取敏感信息。 ... [详细]
  • VMware vRealize 平台高危漏洞安全公告
    近期,VMware 发布了关于其 vRealize 平台存在服务器端请求伪造(SSRF)及任意文件上传两个严重漏洞的安全公告。这些漏洞可能导致未授权的远程代码执行,建议用户尽快采取措施进行防护。 ... [详细]
  • 数据集成策略:ETL与ELT架构对比及工具选择
    随着企业信息化的深入发展,‘数据孤岛’问题日益突出,阻碍了数据的有效利用与整合。本文探讨了如何通过构建数据仓库解决这一问题,重点分析了ETL与ELT两种数据处理架构的特点及适用场景,为企业选择合适的ETL工具提供了指导。 ... [详细]
  • ArchSummit深圳2014将于7月18日拉开帷幕,所有讲师已确认,涵盖9个热门话题,共36场精彩报告。InfoQ中文站提供了详细的讲师和报告列表。 ... [详细]
  • Dubbo线程池满载引发的技术探讨
    本文深入探讨了由于第三方推送服务集成不当导致Dubbo线程池满载的问题,通过详细的故障排查与解决方案分享,旨在为同类问题提供参考。 ... [详细]
author-avatar
阿悅11
这个家伙很懒,什么也没留下!
PHP1.CN | 中国最专业的PHP中文社区 | DevBox开发工具箱 | json解析格式化 |PHP资讯 | PHP教程 | 数据库技术 | 服务器技术 | 前端开发技术 | PHP框架 | 开发工具 | 在线工具
Copyright © 1998 - 2020 PHP1.CN. All Rights Reserved | 京公网安备 11010802041100号 | 京ICP备19059560号-4 | PHP1.CN 第一PHP社区 版权所有