项目系列（一）：不是每个产品经理都能做好项目

做to B项目的回报周期和投入产出比，相较烈火烹油的to C真是相形见绌。也许这就像影视行业孵化IP一样，孵化一部叫座的电影很难，有太多的不可堆积因素。何况我想孵化的是一个电影系列，而不仅是单单某个电影。

自8月以来，我一直派驻在外负责一个大型项目，这对于我职业生涯里也是第一次。最近临近派驻结束，2021年也即将落幕，回想起这几个月，竟觉得一开始那么难熬的日子硬扛到底也没那么难过。

好吧，无论如何还是要跟这段时光做个总结，对自己有个交代，希望也对你有所启发。

也许你在公司内也陆续负责过一些跨团队产品合作的项目、对外服务支持的项目，也许你经常深耕到前线和销售、售前、项目经理、交付团队共同作战。不知道你是否想过一个问题：为什么要做这个项目？

一、了解你为什么做项目比做什么更重要

明面上，出差嘛，没什么道理可言。我呢，是在8月初的一个深夜接到领导的电话，随后电脑包也被紧急送到了小区门口，一番嘱咐后第二天一早就拉着行李箱飞去了异乡。原以为待个把礼拜支持下前线团队就行，谁知道一周复一周，一月复一月，到现在已经堪堪120天了。

事后我也多次和现场派驻的同事沟通，为什么要做这个项目，有必要让产品经理深入前线支持吗？

先以旁观者的心态审视项目的来龙去脉：这项目的背景是什么，前期我们和友商是如何pk的？打动客户的提案是什么，为什么客户选择了我们？之前和客户汇报过的材料在哪里，客户给过什么指示？

再以主导方的视角来分析接下来的局势：为什么我们要挑在这个时候交付，有必要投入这么多人力吗，是不是在重复造轮子？入局的厂商有哪些，接下来的重心是什么，我要作为什么角色来参与到这个项目，我能为这个项目带来什么？

了解了项目的始末之后，新的问题摆在面前：在涉猎一个全新的项目时，我要如何避免水土不服？

二、调整心态：认清项目的可堆积和不可堆积因素

先交代下背景。我在公司内一直都是负责平台性产品，支撑泛政行业的项目。但对于该行业里的实际业务没有深入钻研过，也鲜少和专门的厂商长期接洽过，此前所有的经验都仅限于一些蜻蜓点水的方案交流。

而这个项目需要你统筹平台并联合多家ISV根据客户需求共建行业应用，作为产品负责人，你哪来的底气？

老实说，刚来项目前线时我挺焦虑。项目经理、销售、售前、交付、运营团队，以及公司的服务商和软件开发商，每个人看起来都有一把刷子，我就好比一位被保护太好的大家闺秀第一次出远门，迈着小碎步踯躅前进，焦虑得不得了。

焦虑者们一般是怎么回事呢？惧怕不可预知的改变，惧怕进入不熟悉的环境，惧怕驾驭不了新的业务，惧怕自己无法融入新的项目团队，惧怕自己在别人眼中就是个弱鸡。所以一开始常常自我否认，给自己找一万个理由来劝退内心的激情。

怎么打破这种被焦虑捆住手脚的状态呢？

1. 认栽

既然人都来了，责任和使命都背在身上了，后退的路已经堵死了（其他工作均已交接），那就只能硬着头皮往前走了。往前走的过程甩下身上原先的包袱和莫须有的光环，逐步解耦自己和原先环境的关系，脸皮厚点，通过新项目去经营自己。

一知半解的话就去翻资料、找资源、找专家求助，承认“我就是不懂，我就是需要帮助，我就是要向你学习”，这并不丢脸。不断拓展自己的视野，加深对各业务领域的认知，让焦虑无从插手。

事实上，后续上手了解整个项目的利益关系，摸清客户决策层的小算盘后，也确实无暇顾及这种若有似无的情绪，即便偶然闪现也会通过一次次的实践验证让自己摆脱出来。

2. 连接

斯科特·佩奇在《多样性红利》一书里提过，所谓创造性，其实就是“不同想法的连接”。把两个视角加起来，你就获得了一对想法的连接，它能帮助你解决新的问题。

在一个大项目里，你能接触的角色、遇到的事情比你在家潜心做一款产品的时候更多，可以连接的想法也会更多。

举个例子，有一次我们在讨论政府内“信息简报”的业务场景时，作为一个内容性产品，无非从收、发两个维度切入，分为：编制简报——接收简报——简报批示——接收批示意见。与此同时，各模块下的角色也就浮出水面：编制人、接收人。

乍一想流程简单明了，没什么疑虑。但深究下去发现，政府内的公职人员实际的信息传递场景，似乎并不是这么简单。

信息简报的定位是什么，它是公职人员向各级单位领导以简要形式传递工作或业务要情的信息载体和传递工具，尤其在跨单位跨层级的汇报场景里会有较高频的运用。经过和专门负责政府传统oa业务的厂商沟通后，抓住简报和其他信息内容的差异点：专题性强、有一定周期性、相对更高频：

• 对简报创建方而言：在简报之上引入“栏目”的概念，每个单位均能创建多个栏目，基于栏目去编制、审核和分发简报。由业务管理员注册栏目并按栏目维度确定编制人、审核人，以及有权接收该栏目下的简报接收人；
• 对简报接收方而言：本单位内以领导为主，查看和批示简报；跨单位时以接收单位的简报管理员作为唯一接口人来进行简报分发。

在和ISV共同商议后，最终拟定的简报主流程为：注册栏目——编制简报——审核简报——接收简报——批示简报——接收批示意见。然后再根据不同环节再开展分支流程的梳理，以及每个流程里覆盖的角色和权限。

整个过程我最大的感受是，要充分利用我们的产品能力和ISV的业务能力，二者进行有效地组合，才能让最终的交付物更贴合客户需要。

对个人而言，学习用“工”字形的结构来积累自己的能力：先划一横，广泛涉猎多个领域，积累经验；再划一竖，从某一个业务领域专精下去。然后再划一横，把积累的领导力迁移到各个领域，最终实现多个维度的成功。

3. 堆积

在一个项目里，总会存在一系列可堆积因素，它是可被计划的、可控的、可被堆积出来的。

比如人力物力财力，只要你有足够的意愿和执行力，你可以通过反复给它加码、给它堆出来。只要你投入的成本足够高，组织有道管理有方，有明确的流程、分工、责任、权力、利益分配，这事儿就有较大的概率能搞定。

但同时，一个项目里难免也会存在一些不可堆积因素，你无法计划也无法指挥，可能需要一个机遇，一个突如其来的决策，一个灵光乍现的想法。你只能等这个因素已经露出苗头之后，再集中精力去跟进。

因此，一个项目的成功与失败都不会取决于你一个人。你可以堆积很多的资源和努力，但你堆积不出来那个让所有人眼前一亮的X因素。所以犯不着给自己太大压力，把握可堆积的因素，充分发扬不同团队的优势，共同把整个项目撬动起来。

三、他山之石：集各家ISV的业务能力之长

在我负责的这个项目里，涉及到10多个行业内的业务应用，这都不是一朝一夕就能了解透彻的。

对个人而言，一个项目中涉及到多少业务，分别需要你快速熟悉并给出判断。做深10多个业务意味着要深挖10多口井，并从中找到水源。

对于ISV而言，他们在这个细分行业里沉浸多年，拥有丰富的know-how，要在短期内交付这个项目，我们应该支持合作伙伴去做，或是联合合作伙伴的业务能力共建，而不是自己下场去做。

但这并不意味着交给合作伙伴之后就可以高枕无忧，直接拿现成的方案给到客户。你还需要深入客户侧调研客户的需求场景和痛点，再来看已有的方案是否能够满足。

事实证明，在这个项目里，这些业务在实际调研之后的确有很多地方需要推倒重来：有些产品需要重新定义业务逻辑，有些产品需要充分结合其他产品的组件能力，有些产品需要提升鲁棒性，有些产品需要按最新定义的规范开展设计，实现产品的本地化建设。

举个例子，我们在设计一款日程应用时，目标是汇聚和管理个人的工作计划和安排。照理说，这是一个相对通用的办公工具。而对于通用的工具，在政府内的业务场景下，是否有一些个性化的差异点？

首先拆解下目标，“个人的工作计划和安排”，这里要划分角色：所有人看待日程的视角一样吗？普通员工和领导的日程会有什么差异？怎么去定义普通员工和领导？

其次对实体的权限进行管理：谁有权限建日程，日程的公开范围有哪些，由谁来定义？由谁来变更？

经过和ISV的多轮探讨，最终将日程分成三类：个人日程、领导日程和关注日程，即：除了规划和查看个人日程外，我还能查看到领导公开的日程，还能关注本单位内其他人员的公开日程。不同类型的日程公开范围不同，日程之间的关联性也不同。

比如领导日程，在政府内一般由秘书或办公室副主任代理设置，因此在领导日程里增设代理人模块。由日程管理员设置哪些领导由哪些代理人来设置日程，并定义好日程的公开范围。那么对于公职人员来说，就可以查看到本单位内所有公开的领导日程。

整个产品就是在一点点的讨论和细化中，丰满起来的。

亚当·格兰特在《离经叛道》一书里提到，人们获得越多的专业知识和经验，他们观察世界所用的某种方式就变得越发根深蒂固。
不同专业领域的合作伙伴，都会恪守原有的业务逻辑和产品走向。

研究显示，当桥牌规则被改成由拥有最小牌的玩家先出牌，而不是拥有最大牌的玩家先出牌，专业的桥牌选手表现得比新手更难适应；在使用取消了旧规定的新税法时，专业会计师比新手做得更糟糕。随着我们对某一领域的知识增多，我们也成了自己头脑中原型的囚徒。

在与isv联合研发的过程中，的确会遇到双方各执一词无法决断的情况，这时候划清双方的分工边界、开展柔性化的协作则非常重要。

1. 明确定位

比如我司，主要以平台型产品为主，作为一家从互联网公司切入To B战场的企业，我们很难在短时间内构建复杂行业应用的能力。当我在推动整体协同应用在各行业赛道上的建设时，虽然我大概了解这些应用在实际客户办公场合里有什么场景，但我并不真正了解客户为什么要这么用，单凭一己之力构建不了完整的行业解决方案。

因此，在项目初期，多方聚在一起就要先把丑话说在前头，互揭老底，开诚布公地来定义整个方案能实现到什么程度，有哪些是可以保底的，哪些是可以争取的，哪些是需要引入外援的。

2. 发扬优势

如果你无法深入业务，那么你的优势是什么？一开始我就清楚，我们的优势是产品和技术能力，在和多方合作伙伴的联合共建的过程中，我们应该做一些能最大限度发挥自身技术能力优势的方案，做能标准化、可复制、轻交付的产品。

比如在做办公门户的时候，ISV已有较为成熟的标品，但是产品本身在角色权限管理、应用管理、数据源配置上都没有做好标准化，在多单位场景下也很难做到应用数据的切换。

这些都是基于我对底座平台和产品标准化的理解，即便我没做过门户，不清楚门户内各元件的设计逻辑，也不妨碍我们和合作伙伴之间共同推进该产品的优化，形成更完整的解决方案。

3. 锚定目标

取他人之长，集各家ISV的业务能力之长，目的不是为了卖行业解决方案本身，而是为了增强自有产品的行业适配性，形成可复制的标准能力。

而对于isv而言，他们也会有自己的心思，如何充分发挥自己的行业实力和业务强项，如何让产品在更大的平台和项目上得到印证，树标杆、赢口碑、名利双收，后续可以有更多的商业合作机会。

四、构建队形：明确合作模式和协作平台

业务规模要匹配上相应的组织能力，组织能力是To B企业的最大瓶颈。如果组织能力跟不上，项目就算拿的多，也消化不了。管理不善时，项目甚至会亏损。

坦白说，我们都太习惯组织内的协作了，跨组织间的合作一搬上台面，似乎就要顶着锅盖、抛出盾牌、紧盯战况，如有风吹草动随时准备防御、后撤。

在当下这个互联的技术系统下，所有组织本质上都是生存在一个无限链接的空间中。我们常常看到的是，组织内部之间是开放的、互通的；组织之外表现为以顾客为核心的相互链接的价值共同体。

我们也承认，分工使得劳动效率最大化，但我们要解决是合作团队的整体效率，既有你方团队成员，又有我方成员，跨组织的合作更需要依靠协同，依靠信息交换和共享。

那么落实到实际行动上，怎样才算是协同合作呢？

一个一个说。

1. 定机制

项目在一开始搭建团队的时候就要明确多方协作的机制，并形成文字上的规范进行宣导，包括日常研发合作模式和临时突发情况的应对机制，从始至终要和合作伙伴保持信息透明和同步，确保双方背靠背，共进退。

跨公司联合研发的过程中，有太多需要磨合的地方了，尤其是当一个项目聚集了多家公司，每个公司内还涉及到多个团队，各团队的利益不完全一致的情况下，如何让整个项目团队群策群力，是一件特别有挑战的事儿。

每个公司的研发流程各不相同，当大家汇聚到同一个项目里，就需要有人牵头明确整体协作机制。你需要基于项目实际情况，比如项目的成本和交付周期、各团队的人力资源、需求的复杂程度、标品的匹配程度、总体项目的质量要求等综合去定义产品的迭代节奏和研发流程。

以产品研发流程为例，你需要明确定义各家厂商分别要配备哪些人力资源，每个角色的职责边界和分工，以及各角色之间在研发各环节中如何协作。其中每个环节谁为主谁为辅，大家必须要达成共识。

由于整个项目是我们牵头由多家厂商合作，涉及到产品联调的环节，需要由我们来从中协调，主动给出决策判断。

以产品方案设计为例，从前期的客户需求调研、业务流程梳理、产品原型设计、需求方案设计到面向客户汇报方案，全程有哪些输入，哪些输出，哪些注意事项。在这个过程中，ISV产品给出初步的业务流程设计，再由我方的产品同事进行把关审核，双方达成一致意见后约客户面谈对齐方案，得到印证后再开展详细的需求原型设计。

2. 定平台

一个大项目的协作仅停留在流程机制层面肯定是不够的，在这过程中还需要引入平台性工具，比如需求研发管理工具、知识管理工具、代码分支管理平台、设计管理工具等，让所有厂商的产研相关人员均养成同样的习惯，在同一个平台上交换信息，提升组织协同的效率。

在这个过程中，最大的挑战是反复、刻意地培养所有人养成使用平台的习惯。

以研发管理平台为例，在项目伊始宣导过规范，但各家isv在实际执行时仍然会延续自己公司内的做法。比如用表格管理需求、记录缺陷，等需求缺陷实现后再补录到研发平台上。对于整个项目而言，通览数据的准确性和完整性就无法保障，研发流程也无法及时流转到下一位处理人，整体研发进度不够清晰透明。

这种情况下，一方面要持续宣导平台的使用规则，各产品线分头指定对应的负责人跟踪到底；一方面通过日会汇报的机制，以平台数据为准，每天由各厂商的项目经理对数据进行盘点，对风险点进行晾晒，倒逼每个团队将习惯扭过来。

3. 有仪式

上述无论是在明确合作机制和协作平台的过程中，都需要保持一种仪式感。

大型的数字化项目或软件开发项目，尤其是涉及到甲乙丙丁等多方的合作，都需要一个“仪式感”的会议，代表项目正式的kickoff。

这不单单是将项目计划告诉所有参与项目的领导和执行人员，最重要的是让所有人都对项目的目标、计划、分工有统一的认识，也对项目过程中各方的协作模式加深理解，让所有的参与人员统一思想。

我在这个项目负责了三个产品版本的迭代，每个版本推进前都会开展一次版本启动会，明确该版本的阶段性里程碑和迭代计划，并和各厂商的项目负责人提前对齐，了解他们对产研的期许和意见。在版本启动会时，也会主动让项目负责人在所有项目组成员面前去发表自己的想法和看法，树立威信。

此外，不仅是启动前要有仪式感，一个版本即将告一段落的时候，也要有一个仪式：成果+复盘。

1. 汇报成果前，最好能拉上各团队相关负责人约客户当面演示和验收产品，向整个团队传达客户的表扬或提议，增强项目组成员的获得感；
2. 复盘，给各方团队一个自省和吐槽的机会，是为了更好地总结之前的问题，更好地应对接下来的挑战。

据我观察，这类型的会也更容易拉近各团队间的关系，就像是在日常公事公办的场合里打开了一扇小窗，大家都可以吐露心里的想法，整个气氛是比较宽松自在的。

五、小结：饭要一口一口吃

以上是我这几个月以来作为产品经理深入到项目的大体总结，不舍昼夜紧锣密鼓的团队奋战中，当中的细节远不止这些。针对每个关键阶段的心得分享，比如方案设计、需求管理、团队管理、项目管理等过程中的实操经验和感悟，我会在接下来的时间里持续输出（先把flag立下了）。

回顾这几个月，和不少前线的高人交流过，有一点大家都心有戚戚：做to B项目的回报周期、短期投入产出比，相较烈火烹油的to C真是相形见绌。

在传统互联网下，我们赚快钱习惯了，现在要慢下来。做to b项目的过程中，我发觉新的挑战点发生了范式转移，不仅是产研的合作模式，也包括业务盈利模式、运营模式和从业者的心态等。这些都需要所有角色齐心攻克。

我常和项目组的伙伴们说，不管项目如何，对个人而言都已经是一个很大的成长了。

也许这就像影视行业孵化IP一样，孵化一部叫座的电影很难，有太多的不可堆积因素。即便成了，我们的野心也不止于此，我想孵化的是一个电影系列，而不仅是单单某个电影。

参考文献：

• 《多样性红利》，斯科特·佩奇
• 《离经叛道》，亚当·格兰特

#作者#

健壮的大姐姐，微信公众号：健壮的大姐姐（ID: is_strong）。腾讯高级产品经理，专注于To B服务项目管理和行业分析，欢迎各路好汉一起探讨。

本文

版权声明

本文来自互联网用户投稿，文章观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若转载，请注明出处。如若内容有涉嫌抄袭侵权/违法违规/事实不符，请点击 举报 进行投诉反馈！