研发流程与组织架构匹配探讨：高效研发管理流程选型.pdfVIP

这样的团队基本上不会有太明确的分工与流程来局限他们，团队可以选择自己熟练的工具，

协议合适的分工，唯一的目标就是把问题给解决掉。

例如要赶及在某一天推出新产品或新feature，藉此创造市场话题。这样的任务一般我会交由

产品型组织来完成，而为了持续降低不确定性，他们需要频繁的交付成果以验证市场反应，

以期在deadline之前把产品交付出来。在我过去几年实施敏捷的经验里，这一类的项目约占总

项目的7成左右。

在这类项目中，为了同时兼顾效率与质量，团队基本上会依循一定的程序进行项目目标定

义、需求厘清、开发、测试与布署，而在分工上，一个人可能会同时兼任多种角色，例如资

深工程师除了要写代码外，也要负责架构设计与需求厘清，而产品经理可能同时兼任项目经

理与原型设计。

复杂度较高的项目，可能设有独立的项目经理，否则多数状况下产品经理必须兼任项目经理

角色，他们必须对项目负责；而架构师与用户体验设计师则不见得会参与每个项目，除非项

目涉及较大的架构变迁或选型，以及明显的用户体验缺陷或改进。

分工的方式会根据不同的项目而有所不同，唯一的原则就是，分工必须是必要的，如果只是

在工作流程上卡一关，但没有对项目带来实质效益，那分工便非必要。

例如与战略伙伴合作的项目，彼此已经先把所有需求厘清，并且敲定了验收时间。这样的项

目一般我会另外组织项目团队，按瀑布式开发流程推进，并切出几个重要的里程碑进行阶段

性验收。

如果敏捷是藉由更快且更频繁的交付，以期降低不确定性并更快的创造价值，那么在目前的

项目中，需求基本上已经非常明确，时程也按着彼此协议好的时间进行，中间其实不存在太

多需要通过迭代来验证的内容。唯一需要的是按表操课、如期如质的将成果交付出来。

独立的团队，明确的计划、分工与权责，加上里程碑查核，这类案子的稳定度是最高的。所

以时至今日，多数的外包项目，都还是依循着这种程序，否则将在报价、管理与验收上产生

诸多困难。

上述内容汇整后，可以用下面这张图做个概括性的理解，根据目标与需求的不确定性的高

低，所采取的项目管理方法、团队组织与分工方式也不同。

在领导团队时，我特别强调项目管理的基本功，因为我认为多数的问题都是出在基本功不够

扎实。在项目开始前与进行中，一般我会对产品经理提出很多问题，以确保项目能如原先预

期推进。

在项目启动阶段，一般会由团队就已知信息先拟定draftplan，其内容主要是陈述项目要做哪

些事？打算如何进行？由谁来做？预计花费多少时间？以及将得到什么样的结果？

而当团队将计划产出后，我会问产品经理：“这个项目中有哪些不确定性，可能会导致你无

法准时交付？”项目管理早期的主要问题大多是“需求不够清晰”、“不确定人力资源能否

配合”、“对工作的估时过长或过短”、“技术可行性待验证”、“老板可能还会改动需

求”等等，而这些，就是导致项目进行阶段会频繁发生变更(change)的原因。

相对的，如果你在规划时期，就已经先把这些问题排除了，那运行时会面临的变更就相对减

少了，案子的进行也会相对轻松许多。

这些对我来说都是项目管理的基本功，

敏捷强调不断

进步与反馈，我们必须通过一个又一个项目的磨练，让自己能把需求看得更清楚，对时程估

算得更准确，能更有效的对齐老板的期待，而要做到这些，团队就需要逼着自己不断进步。

若你对Scrum架构有所研究，你便会发现bestpractice里头强调的架构，其实正是针对上述几

个最常见的项目不确定性而来的。例如，针对时程，Scrum强调固定的交付周期，以1-4周为

佳，而且强调是固定团队，在过程中也尽可能避免团队成员同时参与多个项目，在这个基础

上，再来讨论这样的团队，在一个迭代时间内可以完成多少工作。

Scrum给出了一些框架与规范，确实有助于提升团队的项目管理水平，如果团队原本的项目管

理能力只有60分，或许导入Scrum后能提升到80分，但如果要做到90分，团队还是要根据所

遭遇到的问题进行持续不断的改善。

曾有一个teamleader在一次会议后问我：“老大，不断打破与调整流程，让大家忙得要命，

背后追求的到底是什么？”

我说：“进步。忙是一时的，但你想想一年前我们做一样的事情花多少时间，现在又花多少

时间？针对一个异常，过去我们是发生后才知道，现在我们已经可以弭平于未发之时。从前

我们没日没夜的工作，换来的却是很多谩骂，但现在我们花更少的时间，却换回更多的掌

声，因为我们持续在进步。”

如果需求管理不当、时程估算误差过大、未以正确的态度面对