你的研发流程符合你的组织架构吗?谈高效研发流程那些事(二)

当企业内外部状况稳定,需求的变化性较少,可预测性高时,功能型组织是相对适合的组织架构,而相同的概念,其实也适用于传统的 PMP 管理方法。PMP 强调程序、输入 (input)、输出 (output) 与权责,这与功能型组织不谋而合;相较之下,敏捷强调的快速响应、迭代,则与产品型组织或战斗小组更加匹配。

当一家公司内可能存在多种组织架构时,是否也意味着应该存在多种开发流程呢?我的答案是”肯定的”,当我们过度坚持公司内只能有少数一两套程序,硬要逼所有人配合时,其实已经与敏捷所追求的“专注于更快的创造价值,持续精进”的理念背道而驰了。

最近几年,我一直在同时并行管理多种组织与开发流程,接下来将跟大家分享在不同的场景下我是如何选择的:

1. 需求具备高度不确定性,重要性高,但时程紧迫度一般

例如新商业模式的探索、从 2B 跨入 2C 的新产品等,这样的任务我一般会以战斗小组的形式组成团队,团队成员会根据当下需求随时做调整,可能是 1 位产品经理配 2 位研发工程师,也可能是 3 位具备分析能力的资深工程师。

这样的团队基本上不会有太明确的分工与流程来局限他们,团队可以选择自己熟练的工具,协议合适的分工,唯一的目标就是把问题给解决掉。

2. 需求有一定不确定性,且时程紧迫

例如要赶及在某一天推出新产品或新 feature,藉此创造市场话题。这样的任务一般我会交由产品型组织来完成,而为了持续降低不确定性,他们需要频繁的交付成果以验证市场反应,以期在 deadline 之前把产品交付出来。

在我过去几年实施敏捷的经验里,这一类的项目约占总项目的 7 成左右。在这类项目中,为了同时兼顾效率与质量,团队基本上会依循一定的程序进行项目目标定义、需求厘清、开发、测试与布署,而在分工上,一个人可能会同时兼任多种角色,例如资深工程师除了要写代码外,也要负责架构设计与需求厘清,而产品经理可能同时兼任项目经理与原型设计。

复杂度较高的项目,可能设有独立的项目经理,否则多数状况下产品经理必须兼任项目经理角色,他们必须对项目负责;而架构师与用户体验设计师则不见得会参与每个项目,除非项目涉及较大的架构变迁或选型,以及明显的用户体验缺陷或改进。

分工的方式会根据不同的项目而有所不同,唯一的原则就是,分工必须是必要的,如果只是在工作流程上卡一关,但没有对项目带来实质效益,那分工便非必要。

3. 需求具有高度确定性

例如与战略伙伴合作的项目,彼此已经先把所有需求厘清,并且敲定了验收时间。这样的项目一般我会另外组织项目团队,按瀑布式开发流程推进,并切出几个重要的里程碑进行阶段性验收。

如果敏捷是藉由更快且更频繁的交付,以期降低不确定性并更快的创造价值,那么在目前的项目中,需求基本上已经非常明确,时程也按着彼此协议好的时间进行,中间其实不存在太多需要通过迭代来验证的内容。唯一需要的是按表操课、如期如质的将成果交付出来。

独立的团队,明确的计划、分工与权责,加上里程碑查核,这类案子的稳定度是最高的。所以时至今日,多数的外包项目,都还是依循着这种程序,否则将在报价、管理与验收上产生诸多困难。

上述内容汇整后,可以用下面这张图做个概括性的理解,根据目标与需求的不确定性的高低,所采取的项目管理方法、团队组织与分工方式也不同。

追求敏捷,但更要重视项目管理基本功

在领导团队时,我特别强调项目管理的基本功,因为我认为多数的问题都是出在基本功不够扎实。在项目开始前与进行中,一般我会对产品经理提出很多问题,以确保项目能如原先预期推进。

在项目启动阶段,一般会由团队就已知信息先拟定 draft plan,其内容主要是陈述项目要做哪些事?打算如何进行?由谁来做?预计花费多少时间?以及将得到什么样的结果?

而当团队将计划产出后,我会问产品经理:“这个项目中有哪些不确定性,可能会导致你无法准时交付?”项目管理早期的主要问题大多是“需求不够清晰”、“不确定人力资源能否配合”、“对工作的估时过长或过短”、“技术可行性待验证”、“老板可能还会改动需求”等等,而这些,就是导致项目进行阶段会频繁发生变更 (change) 的原因。

相对的,如果你在规划时期,就已经先把这些问题排除了,那运行时会面临的变更就相对减少了,案子的进行也会相对轻松许多。

这些对我来说都是项目管理的基本功,敏捷虽然强调拥抱不确定性,并欢迎随时的更动,但不意味着我们要对那些不确定性置之不理,而是要尽快的让不确定成为确定。

敏捷强调不断进步与反馈,我们必须通过一个又一个项目的磨练,让自己能把需求看得更清楚,对时程估算得更准确,能更有效的对齐老板的期待,而要做到这些,团队就需要逼着自己不断进步。

若你对 Scrum 架构有所研究,你便会发现 best practice 里头强调的架构,其实正是针对上述几个最常见的项目不确定性而来的。例如,针对时程,Scrum 强调固定的交付周期,以 1-4 周为佳,而且强调是固定团队,在过程中也尽可能避免团队成员同时参与多个项目,在这个基础上,再来讨论这样的团队,在一个迭代时间内可以完成多少工作。

Scrum 给出了一些框架与规范,确实有助于提升团队的项目管理水平,如果团队原本的项目管理能力只有 60 分,或许导入 Scrum 后能提升到 80 分,但如果要做到 90 分,团队还是要根据所遭遇到的问题进行持续不断的改善。

进步,是永远不变的追求

曾有一个 team leader 在一次会议后问我:“不断打破与调整流程,让大家忙得要命,背后追求的到底是什么?”

我说:“进步。忙是一时的,但你想想一年前我们做一样的事情花多少时间,现在又花多少时间?针对一个异常,过去我们是发生后才知道,现在我们已经可以弭平于未发之时。从前我们没日没夜的工作,换来的却是很多谩骂,但现在我们花更少的时间,却换回更多的掌声,因为我们持续在进步。”

如果需求管理不当、时程估算误差过大、未以正确的态度面对不确定性、项目过程控管差劲,却总是靠着团队加班来填补落差,团队可以靠着热情撑过一小段时间,但随着时间延长,团队总是会乏力,身为技术领袖应该要以持续进步为己任,而不该沾沾自喜于团队的超时工作。

记得,永远都要追求更快、更好、更有价值,别用战术上的勤奋,来掩饰战略上的怠惰。

声明:
1、MuTouTalk是一个资源分享和技术交流平台,本站全部资料仅供个人学习和研究使用
2、帖子内容作者同本站拥有相关版权
3、任何个人或组织,在未征得本站以及该贴作者同意时,禁止复制、盗用、采集、发布本站内容到任何网站、书籍等各类媒体平台
4、如若本帖作者内容侵犯了原著者的合法权益,请发邮件到xiaojie777898@163.com, 本站审核通过后会24小时内立即予以处理。
MUTOU TALK » 你的研发流程符合你的组织架构吗?谈高效研发流程那些事(二)

提供最优质的IT资源集合,一切资源来源于网络,找到你想要的!

开通VIP 了解详情