技术领导力实战笔记
TGO鲲鹏会
100位CTO的真知灼见
立即订阅
14777 人已学习
课程目录
已完结 268 讲
0/6登录后,你可以任选6讲全文学习。
开篇词 | 卓越的团队,必然有一个卓越的领导者
免费
第1讲 | 你的能力模型决定你的职位
第2讲 | 七位CTO纵论技术领导者核心能力
第3讲 | CEO实话实说:我需要这样的CTO
第4讲 | 技术领导者不等于技术管理者
大咖对话 | 从几个工程师到2000+个工程师的技术团队成长秘诀
第5讲 | CTO的三重境界
第6讲 | 像CEO一样思考
第7讲 | 要制定技术战略,先看清局面
第8讲 | 技术领导力就是“成事”的能力
大咖对话 | 未来技术负责人与首席增长官将如何协作?
第9讲 | CTO是商业思维和技术思维交汇的那个点
第10讲 | 创业公司CTO的认知升级
第11讲 | 最合适的技术才是最有价值的技术
第12讲 | 谈谈CTO在商业战略中的定位
大咖问答 | 打造自己的个人品牌,你也可以
第13讲 | 把脉高效执行的关键要素
第14讲 | 从零开始搭建轻量级研发团队
第15讲 | 定制高效研发流程
第16讲 | 培养中层团队的管理认知
大咖问答 | 发现下一个小米,不是只能靠运气
第17讲 | 团队成长要靠技巧和体系
第18讲 | 做到这四点,团队必定飞速成长
第19讲 | 将企业打造成一所终身大学
第20讲 | 论团队管理与共同升级
大咖对话 | 技术人真正需要的是升维思考
第21讲 | 绩效管理的目标不仅仅是绩效考核
第22讲 | 验证研发团队价值的绩效考核机制
第23讲 | 产品技术团队OKR使用法则
第24讲 | 996、987,程序员加班文化你怎么看?
大咖对话 | 技术管理者应该向优秀的体育教练学习
第25讲 | 建立有效的员工淘汰机制
第26讲 | 让细节的“病毒”感染你的团队
第27讲 | 如何在不同组织文化下推行技术管理
第28讲 | 业务高速增长期的团队管理:“知轻重、重绸缪、调缓急”
大咖对话 | 让团队成员持续的enjoy
第29讲 | 被80%的人误解的工程师文化
第30讲 | 关于工程师文化的六个问题
第31讲 | 五位技术领导者的文化构建实战
第32讲 | 文化是管理的那只无形之手
大咖对话 | 创业就是把自己过去的经验快速的产品化
第33讲 | 选对的人,做正确的事情
第34讲 | 打好技术团队搭建的基础
第35讲 | 做个合格的技术岗位面试官
第36讲 | “高潜力人才”的内部培养
大咖对话 | 如何高效管理8000+规模的技术团队
第37讲 | 技术创业该如何选择赛道
第38讲 | CTO要掌握的产品哲学:理性与人性的权衡
第39讲 | 从客户价值谈技术创新
第40讲 | 技术人投身创业公司之前,应当考虑些什么?
大咖对话 | 技术人创业前衡量自我的3P3C模型
第41讲 | 技术人创业前要问自己的六个问题
第42讲 | 团队激励之分配好你的奖金
第43讲 | 通过积分考核提升技术团队的绩效
第44讲 | 空降技术高管的“择业七计”
大咖对话 | 如何打造自我驱动型的技术团队?
第45讲 | 选好人生下一站——CTO空降上篇
第46讲 | 走出“至暗时刻”——CTO空降下篇
第47讲 | 空降领导者平稳落地要做的四道题(上)
第48讲 | 空降领导者平稳落地要做的四道题(下)
大咖对话 | 管理者是首席铲屎官?
第49讲 | 打造高效的研发组织架构:高效研发流程那些事(一)
第50讲 | 你的研发流程符合你的组织架构吗?谈高效研发流程那些事(二)
第51讲 | 聊聊研发流程管理中的那些坑:高效研发流程那些事(三)
第52讲 | 数据如何驱动研发高效运转?谈高效研发流程那些事(四)
大咖对话 | 对人才的长期投资是人才体系打造的根本
第53讲 | 如何打造高效且敏捷的组织文化?谈高效研发流程那些亊(五)
第54讲 | 打造高速运转的迭代机器:现代研发流程体系打造(一)
第55讲 | 用机器打造迭代机器:现代研发流程体系打造(二)
第56讲 | 有了敏捷开发,那交付期限去哪儿了?
大咖对话 | 项目成功的秘诀——技术产品双头负责制
第57讲 | 敏捷中的期限之殇,软件业该怎么做?
第58讲 | 如何打造个人技术品牌?
第59讲 | 技术演讲,有章可循
第60讲 | 正确对待技术演讲中的失误
大咖对话 | 不可替代的Java:生态与程序员是两道护城河
第61讲 | 刘俊强:技术最高决策者应该关注技术细节吗?
第62讲 | 张溪梦:技术领袖需要具备的商业价值思维
第63讲 | 未来组织形态带来的领导力挑战
第64讲 | 如何判断业务价值的高低
大咖对话 | 池建强:做产品不要执着于打造爆款
第65讲 | 如何打造高效的分布式团队?
第66讲 | 如何打造有活力、持续创新的研发团队?
第67讲 | 如何打造独属自己的工程师文化?
第68讲 | 如何打造一个自组织团队?
大咖对话 | 童剑:用合伙人管理结构打造完美团队
第69讲 | 茹炳晟:QE团队向工程效能团队转型的实践之路
第70讲 | 王昊:技术、产品、管理的不同视角
第71讲 | 王昊:什么样的人适合考虑管理角色
第72讲 | 创业公司如何招到合适的人才
大咖对话 | 以产生价值判断工程师贡献——读者留言精选
第73讲 | 用数据来分析管理员工
第74讲 | 为什么给了高工资,依然留不住核心员工?
第75讲 | 刘俊强:一本正经教你如何毁掉一场技术演讲
第76讲 | 内部技术会议的价值
大咖对话 | 韩军:CTO转型CEO如何转变思路
第77讲 | 陈晨:谈谈Instagram文化和文化背后的故事
第78讲 | 陈晨:团队重组过程中踩过的坑
第79讲 | 程军:从0到1打造高效技术团队的方法论
第80讲 | 马晋:技术Leader的持续成长
技术领导力实战笔记
登录|注册

第15讲 | 定制高效研发流程

特赞CTO、TGO会员黄勇 2018-05-09
当我们的研发团队组织架构搭建完毕后,接下来需要思考的是,如何让这个架构跑起来、跑得快、跑得稳。此时,我们需要定义出一个高效的研发流程,还要尽可能降低研发过程中所遇到的风险,确保在流程的每个环节中都不能出错。
在定义具体的研发流程之前,我们需要从整体入手,先把研发流程体系架构定义清楚,便于让团队从全局上把控整个过程。接下来需要从局部入手,将研发流程中所涉及的操作步骤罗列出来,便于指导团队完成具体的工作。
现在我们就从整体开始,对研发流程的体系架构进行探讨。

研发流程体系架构

高效的研发过程应该具备“多线程”的特性,仿佛多条并行流淌的河流,上游是业务,中游的是产品,下游是技术,流量取决于业务,流速取决于产品和技术。
需要说明的是,这里的“业务”其实包括两类人:一是公司内部使用产品的业务同事,二是公司外部使用产品的最终用户。为了便于描述,下文统一将他们称为“业务需求方”或“业务方”,简称“业务”。
根据我的上篇文章可知,整个研发工作流程体系架构是职能团队与项目团队的有机结合,团队职责清晰且协作高效(如图 1 所示)。
图 1:研发流程框架图
在职能团队中,产品委员会的产品专家们将业务需求统一记录到“需求池”中。需求池中的每一个需求都要描述业务的当前现状,还要包括业务对产品的未来期望。每隔一段时间(一般是 1~2 周),产品委员会将根据需求池中所记录的需求细节加以讨论,并将优先级较高的需求进行立项和排期,项目团队可知晓近期需要实现的业务需求是什么,整个团队的方向感也更加清晰了。
需求池中一个典型的需求可包括以下字段:
需求名称:用一个关键词描述,最多 15 个字。
需求来源:该需求来自于哪里?包括业务、运营、财务、法务、市场、其他。
业务痛点:为何要实现该需求?即业务当前的现状。
需求描述:该需求具体是什么?即业务将来的诉求。
渴望程度:期待何时可以上线?包括:本周、本月、下月、本季度、下季度、未来、或具体截止日期。
需求类型:包括:新功能(从 0 到 1)、优化(从 1 到 100)。
需求规模:包括:大(两周以上)、中(一至两周)、小(一周以内)、未知。
备注:可写下对该需求的补充或疑问,以便深入交流。
附件:可通过相关文档对需求进行补充描述。
创建人:该需求被谁创建?
处理状态:包括:未处理(默认)、处理中、已处理、关闭。
优先级:包括:A(重要 & 紧急)、B(重要 & 不紧急)、C(不重要 & 紧急)、D(不重要 & 不紧急)、X(待定)。
负责人:该需求由谁跟进?
简单情况下,可使用电子表格的方式来维护需求池,比如:Numbers、Excel 等,当然也可通过在线方式来管理,比如:石墨文档、金数据等。
需要注意的是,需求池对公司全员共享,由产品委员会管理并维护,其他人员只能阅读但无法编辑。产品专家们首先需要和业务需求方进行有效沟通,深刻理解他们的业务痛点与未来期望后,才能将这些需求入池。
从需求池中挑出的高优先级需求将分别“流入”对应的项目团队中,在项目的执行过程中难免会遇到技术上的遗留问题,然而团队不希望因为这些问题而导致项目工期受到影响。因此,这些技术遗留问题将被列为“技术债”,技术委员会中的技术专家们将对这些技术债加以管理和跟踪,在后期会有针对性地解决这些技术问题,偿还这些技术债。
了解了研发流程体系架构后,下面我们进入具体的研发流程操作步骤。
取消
完成
0/1000字
划线
笔记
复制
© 版权归极客邦科技所有,未经许可不得传播售卖。 页面已增加防盗追踪,如有侵权极客邦将依法追究其法律责任。
该试读文章来自付费专栏《技术领导力实战笔记》,如需阅读全部文章,
请订阅文章所属专栏。
立即订阅
登录 后留言

精选留言(11)

  • self-discipline
    请教:我们公司的产品经理呢,产品原型出来后,我们也评估了,开始开发,开发中,要上线了,产品经理不断改逻辑,加逻辑,小版本迭代变成大版本迭代,我是个中层吧,一直想在评估后开发前,做封版处理的,但是一直有上层的压力,封不了版本,求教如何处理呢,快两年了,心力憔悴
    2018-05-10
    1
    16
  • Eric
    我对特赞币的做法的理解应该是需求方和执行方在责任心、沟通、反馈上面增强的手段,但是手段之下如果对货币的价值定义不清晰,会有适得其反的效果
    2018-05-26
    5
  • 黄勇
    回答:易永健

    项目启动阶段第一条需求确定,如果放到项目计划阶段,那么项目估计可能更准一些,计划可能更合理些

    回答:考虑到项目计划阶段可能会结合实际情况对需求范围做一定调整,因此将需求确定放在了项目启动环节,也是为了给团队一个信号,只要项目启动了,需求就能随意变化了。

    对于领域已经划分好的迭代增量需求,文中提到的研发流程比较合适,但如果要做一个新领域需求,那么可能要有一个独立的领域建模子阶段,可以放在产品需求定稿前执行,形成通用语言和服务边界划分,运用ddd的思路方法

    回答:认同!全新的领域,可采用更加适合的方法。
    2018-05-09
    5
  • 七七默默
    特赞币很好
    2018-10-30
    1
  • wenhao
    特赞币的做法确实挺好,不过这个虚拟货币没有一定的价值,各角色又为什么要去获取它。价值又是怎么定义的了?
    2018-08-01
    1
  • muzili
    能再详细解释一下,功能团队,效率团队和创新团队的区分和功能吗,规模比例是怎么样的?
    2018-05-12
    1
  • 黄勇
    回答 nopsky

    项目上线以后,产品一般都会持续向研发反馈优化和bug,或者新功能,一般不会出现得不到反馈吧,您说的反馈内容是指项目好坏的使用数据和用户的评价吗?

    回答:反馈主要包括用户使用行为上的反馈,以及数据表现上的反馈。前者比较主观,需要通过调查来完成;后者比较客观,需要通过事实来说话。

    业务人员跟研发人员反馈的内容是什么?研发人员是不是也有获取币的方式?解决需求获取币吗?

    回答:业务人员主要反馈的是用户使用行为上的反馈,研发人员可以通过数据来反馈。研发人员也可以获得币,比如提出了一个很好的脑洞,被产品委员会采纳了。研发人员得到币以后,也能提自己的痛点,比如为了完成运营工单,希望产品如何提供功能上的满足。
    2018-05-09
    1
  • 易永健
    项目启动阶段第一条需求确定,如果放到项目计划阶段,那么项目估计可能更准一些,计划可能更合理些

    对于领域已经划分好的迭代增量需求,文中提到的研发流程比较合适,但如果要做一个新领域需求,那么可能要有一个独立的领域建模子阶段,可以放在产品需求定稿前执行,形成通用语言和服务边界划分,运用ddd的思路方法
    2018-05-09
    1
  • 一_FVision
    业务研发相互信任是关键,好的业务方,产品对每次的需求都要有明确的方向和目标,好的研发不光是埋头实现功能的代码机器,更需要注重业务收益,需求上线后的反馈,才能让自己的劳动与公司发展保持一致,拥有使命感
    2019-03-01
  • nopsky
    项目上线以后,产品一般都会持续向研发反馈优化和bug,或者新功能,一般不会出现得不到反馈吧,您说的反馈内容是指项目好坏的使用数据和用户的评价吗?
    2018-05-09
  • nopsky
    业务人员跟研发人员反馈的内容是什么?研发人员是不是也有获取币的方式?解决需求获取币吗?
    2018-05-09
收起评论
11
返回
顶部