技术领导力实战笔记_63_第50讲_|_你的研发流程符合你的组织架构吗？谈高效研发流程那些事（二）
你好，我是珍亚管理顾问公司负责人，同时也是TGO坤鹏会台北分会学习委员。
尤舒凡今天想跟大家分享的话题是高校研发流程的第二步，研发管理流程的选型。
在上一篇文章中，我与大家分享了组织架构与打造高校研发流程间的关联。
本文将着重于研发过程的探讨。
刚出社会时，我家一家ERP软件公司从事研发工作，我在那里接触到了非常正规的软件工程，也见识到。
当研发流程与业务特性匹配时的高效以及不匹配时产生的诸多问题。
在两千年初期，软件开发大多仍遵循瀑布式方法，必然得先进行需求收集、分析、设计，然后进入开发与测试，经过一道道程序后将成品完整的交付。
在ERP软件公司，那些年，我也参与了软件成熟度模型CMMI level four的导入与认证过程中，我见识到了CMMI的严谨之处，同时也体会到严谨背后带来的低效与冗余。
由于当时我所负责的产品处于需求不明确，市场信待验证的状态。
如果要依照CMMI规则产出完整的需求，求表及完整整的分析文件，估计是不可能的。
因此呢，过程程我所试着提出假需性性需求，以及用雏形替代成品的方法来进行市场验证。
出乎意料的是，这个提议获得了CMMI顾问团队的认同，而这也是我对CMMI有所改观的转折点。
公司内推动小组的负责人告诉我，CMMI本来就是一个模型，每家公司得依照自己最适合的方式构建流程，但最终须能达到CMMI要求的水平。
二零一一年，我开始负责sars,相关业务也首次接触了敏捷观念以及scrum.与此同时，互联网开始进入火爆增长期，所有的企业都在求新求快，技术团队也被要求要具备更灵活、更弹性、更迅速的特性。
只是一两年时光。
国内所有公司都在讨论敏捷开发，而不再有人讨论PMP和CMMI所主张的瀑布式项目管理与研发流程管理方法。
二零一三年，我开始在团队中大量引用敏捷观念，通过频繁的交付来验证用户与市场需求，也在技术社区中与许多朋友交流项目管理与软件开发方法。
我看见越来越多的人想拥抱敏捷，但同时我也发现许多人对敏捷其实一知半解，并且对PMP以及CMMI有着错误的偏见。
二零一五年，我进入互联网公司，后人人口中所谈的都是敏捷。
万一在讨论过程中，有人提到CMMY或PMP,就会有人露出鄙视的眼神，他们误以为过去项目做不好，是PMP与CMMY造成的，却未曾思考过。
或许项目失败的真正原因不再流程与工具，而是运用的那些人关于瀑布式或敏捷开发方法的选择。
在前一篇文章中，我提到，当企业内外部状况稳定需求的变化性较少，可预测性高时，功能型组织是相对适合的组织架构，而相同的概念其实也适用于传统的PMP管理方法。
Pnp强调程序输入输出与全责，这与功能型组织不谋而合。
相较之下，敏捷强调的快速响应迭代，则与产品型组织或战斗小组更加匹配。
当一家公司内可能存在多种组织架构时，是否也意味着应该存在多种开发流程呢？我的答案是肯定的。
当我们过度坚持，公司内只能有少数一两套程序，硬要逼所有人配合时，其实已经与敏捷所追求的专注于更快的创造价值，持续精进的理念背道而驰了。
最近几年呢，我一直在同时并行管理，多种组织与开发流程，接下来将跟大家分享在不同的场景下，我是如何选择的。
一、需求具备高度不确定性，重要性高，但时程紧迫度一般。
例如，新商业模式的探索，从to b跨入to c的新产品等。
这样的任务，我一般会以战斗小组的形式组成团队，团队成员会根据当下需求随时做调整。
可能是一位产品经理配两位研发工程师，也可能是三位具备分析能力的资深工程师。
这样的团队基本上不会有太明确的分工与流程来局限。
他们团队可以选择自己熟练的工具协议，适合的分工，唯一的目标就是把问题给解决掉。
二、需求有一定不确定性，且时程紧迫，例如要赶集在某一天推出新产品或新feature,借此创造市场话题。
这样的任务一般我会交由产品型组织来完成。
而为了持续降低不确定性，他们需要频繁的交付成果以验证市场反应，以期在电line之前把产品交付出来。
在我过去几年实施敏捷的经验里，这一类的项目约占总项目的七成左右。
在这类项目中，为了同时兼顾效率与质量，团队基本上会依循一定的程序进行项目目标定义、需求，理清开发、测试与部署。
而在分工上，一个人可能会同时兼任多种角色，例如资深工程师，除了要写代码外，也要负责架构设计与原求理清。
而产品经理可能同时兼任项目经理与原型设计复杂度较高的项目，可能是有独立的项目经理。
例则多数状况下，产品经理必须兼任项目经理角色，他们必须对项目负责，而架构师与用户体验设计师则不见得会参与每一个项目，除非项目设计较大的架构、变迁或选型，以及明显的用户体验缺陷或改进分工的方式，会根据不同的项目而有所不同。
唯一的原则就是分工必须是必要的。
如果只是在工作流程上卡一关，但没有对项目带来实质效益，那分工便非必要。
三、需求具有高度确定性，例如与战略伙伴合作的项目，彼此已经先把所有需求理清，并且敲定了验收时间。
这样的项目，一般我会另外组织项目团队按瀑布式开发流程推进，并切出几个重要的里程碑进行阶段性验收。
如果敏捷是借由更快、更频繁的交付，以期降低不确定性并更快的创造价值。
那么在目前的项目中，需求基本上已经非常明确，时程也按照彼此协议好的时间进行，中间其实不存在太多，需要通过迭代来验证了内容。
唯一需要的是按表操课如期如质的将成果交付出来，独立的团队明确的计划分工与全责，加上里程碑查核这类案子的稳定度是最高的。
所以时至今日，多数的外包项目都还是依循着这种程序，否则将在报价、管理与验收上产生诸多困难。
因此，根据目标与需求的不确定性的高低，所采取的项目管理方法、团队组织与分工方式也不同，追求敏捷，但更要重视项目管理基本功。
在领导团队时，我特别强调项目管理的基本功，因为我认为多数的问题都是出在基本功不够扎实。
在项目开始前与进行中，一般我会对产品经理提出很多问题，以确保项目能如原先预期推进。
在项目启动阶段，一般会由团队就已知信息先拟定draft plan,其内容主要是陈述项目要做哪些事儿，打算如何进行，由谁来做，预计花费多少时间，以及将得到什么样的结果。
而当团队将计划产出后，我会问产品经理，而个项目中有哪些不确定性，可能会导致你无法准时交付项目。
早期的主要问题大多是需求不够清晰，不确定人力资源能否配合，对工作的估事过长或过短，技术可行性待验证，老板可能还会改动需求等等。
而这些就是导致项目进行阶段会频繁发生变更的原因相对的，如果你在规划时期就已经先把这些问题排除了。
那运行时会面临的变更就相对减少了，案子的进行也会相对轻松许多。
这些对我来说都是项目管理的基本功敏捷。
虽然强调拥抱不确定性并欢迎随时的更动，但不意味着我们要对那些不确定性置之不理，而是要尽快的让不确定成为确定。
例捷强调，不断进步与规馈。
我们必须通过一个又一个项目的磨练，若自己能把需求看得更清楚，对时程估算的更准确，能更有效的对其老板的期待。
而要做到这些团队就需要逼着自己不断进步。
若你对scrum架构有所研究，你便会发现best practice里头强调的架构。
其实正是针对上述几个最常见的项目不确定性而来的。
例如，针对时程scrum强调固定的交付周期以一到四周为价，而且强调是固定团队在过程中，也尽可能避免团队成员同时参与多个项目。
在这个基础上再来讨论这样的团队，在一个迭代时间内可以完成多少工作。
Scrum给出了一些框架与规范，确实有助于提升团队的项目管理水平。
如果团队原本的项目管理能力只有六十分，或许导入scram后能提升到八十分。
但如果要做到九十分，团队还要根据所遭遇到的问题进行持续不断的改善，进步是永远不变的追求。
曾有一个team leader在一次会议后问我，老大不断打破与调整流程，让大家忙得要命，背后追求的到底是什么？我说进步忙是一时的，但你想想，一年前我们做一样的事情，花多少时间，现在又花多少时间？针对一个异常，过去，我们是发生后才知道，现在我们已经可以米平于未发之时。
从前我们没日没夜的工作换来的却是很多谩骂。
但现在我们花更少的时间却换回更多的掌声，因为我们持续在进步。
如果需求管理不当，实程估算误差过大，未以正确的态度面对不确定性，项目过程管控差劲儿，却总是靠着团队加班来填补落差，团队可以靠着热情撑过一小段时间，但随着时间延长，团队总是会乏力。
身为技术领袖，应该要以持续进步为己任，而不该沾沾自喜于团队的抄时工作，记得永远都要追求更快更好，更有价值，别用战术上的勤奋来掩饰战略上的带动。