这篇文章我们就来说一说，产品经理在保证产品“价值”之后的第二大重要任务：保证组织“效率”。

抛砖引玉

优秀的产品经理不仅要确保产品对于企业的商业价值、用户的功能价值，还要确保产品的用户的体验价值和共鸣价值。可以说确保产品的诸多价值是产品经理的第一要务，我对这一点也是深信不疑的。但是不是保证了价值后，产品就定能突出重围获得成功？我相信大家的答案一定和我一样：“不是的！”。

产品从点子到知名产品的道路上充满荆棘，至少需要经历三个大阶段，设计->生产->销售。对于互联网产品来说，可以翻译为设计->开发->运营。即使产品的商业价值论证做得再好，功能和体验价值设计得再完善。低效的开发、运营过程都有可能毁掉你“完美”的设计。

有幸经历过几家不同类型的企业（外企、国企、创企、民企），尤其是最近一段经历，在十几岁的民企的“创新业务”事业部伴随着部门基本从“0”到“1”的成长，在领导的带领下，我收获了不少在组织效率上实践和思考的机会。产品成长的过程，其实也包含了组织成长的过程。

随着产品及组织的成长，管理工具和手段也在不断的变化：

1. 需求管理从Email、Excel到Web工具，如：JIRA、Wiki。
2. 会议管理从全临时会议到逐步增加重点会议。
3. 文档管理从纯PRD、接口规范到操作手册、功能发布说明书。
4. 项目管理从早期的赶工到现在地向敏捷靠拢。
5. ……

这篇文章我们就来说一说，我认为产品经理在保证产品“价值”之后的第二大重要任务：保证组织“效率”。

如何洞察效率问题

在我自己工作经验里，洞察组织效率问题的工作往往是深入在日常工作过程中的。有被动的发现，也有主动探索，在实际工作过程中，我更多思考和处理的是被动发现的效率问题。

1. 被动发现

自己的效率：当自己被同一类困难困扰时

在一个坑摔一次是没经验，在一个坑摔两次是不长记性，在一个坑摔三次那就不可被原谅了。重复被同一类困难困扰时，这个困扰便极有可能是效率待提升的点。

例如：

• 场景一：每周都需要进行本周需求处理情况汇总，Excel记录的需求，多部门难以联合维护，状态转换过程难以记录。想要一个本月从“待验收”转变成“已上线”的需求的数量特别困难，需要耗费大量时间整理，而且每周一次。
• 场景二：接收来自多个项目针对本产品的需求时，来自不同项目，不同背景的人书写的需求描述各不相同。即使提供了Word版本的需求沟通模板+填写示例，依然有很多人不照常理出牌，导致重复进行电话确认，影响效率。

这类组织效率问题，较容易发现，最重要的是产品经理需要培养起自己的效率意识！

同事的效率：当同事提出工作优化需求时

产品经理是一个在产品过程中影响力较为广泛的角色，许多的产品过程都会被引入其中，无论是早期的商业论证、线框设计、UI设计、评审、宣讲到后期的验收和运营策略设计。如果产品经理乐于与不同的协作角色讨论工作过程，并且你遇到有丰富经验又追求高效工作的同事，他们往往会向你主动提出协同优化工作效率的需求。

例如：

场景三：产品早期，因为产品资源相对研发和测试资源少，并且产品未大范围推广所以需求变更数量也不多，所以往往需求都可以在1、2个迭代周期内消化完毕。研发、测试资源不会有太大冲突，项目平稳前进。

到了产品中期，随着需求数量，产品研发资源调整，研发和测试资源开始遇到瓶颈，需求已经无法被及时消化，时而会形成多个产品经理的需求多头管理。这时有经验的研发和测试就会主动提出问题，希望产品团队可以统一管理需求，避免多头管理的情况，以尽可能减少研发测试切换上下文时间而提升团队效率。

场景四：产品中期，产品需求与设计的复杂度逐渐增加，一个需求可能涉及2、3个研发团队协同开发，而测试也会有提前准备完备测试用例的需求。因此为了更好的完成需求与设计的传递工作，研发和测试团队提出了开展固定需求周例会的工作。

通过例会梳理、澄清需求，确定每个需求研发主责任人，并通过会议“通气儿”，达成任务上的一致。

这类组织效率问题，其实也不难发现，重要的是：

1. 产品经理要善于和乐于沟通组织效率问题，让同事愿意对组织效率畅所欲言。
2. 尽量让自己在组织过程中扮演更重要的角色，例如：由产品负责搭建JIRA系统，配置工作流。
3. 遇到有主人翁意识的同事。
   

别人眼中的效率：当别人不知道你有多高效时

互联网产品往往诞生于项目，有项目就有干系人。你的直属上司，你的大老板、你的对口客户，客户的老板，推广你产品的运营销售团队，实施你产品的实施部署团队，甚至对你加班埋怨已久的媳妇。

你在一个迭代做了15件事情，干系人可能只关心他的那一件，即使他是优先级最高第一个完成的，他也会在质量、范围、时间等各种维度产生不满。

用最近看的一本书《项目管理心理学实践》里的一句话（大概是这么说的）来解释：

“结构使然，与人品无关”。

身居其位谋其政，我们能做的是增强沟通、缓解氛围。短线看，花了更多时间去做沟通，降低了工作效率，但长远看团队协作氛围及凝聚向心力的提升，会为后续各种合作带来“好处”。

例如：

场景五：做为一个产品化产品（与定制化产品对立）的产品经理，你会收到来自各个渠道的需求反馈。有一些是定制化的，有一些是确实有价值的。对于确实有价值的需求，适时会开展设计工作，对于有技术基础、相对强势的需求方往往会吐槽需求实现耗时长，尤其在To B产品中较为常见。例如：一个要求在业务操作页增加新字段或者业务约束，以匹配客户管理诉求的需求。

对定制化开发来说，一个字段，一个逻辑检查可能1~2小时开发、测试加部署就可以上线。但是落到产品化产品中，如果原先产品设计假设里假设这部分不会有定制化需求，那么设计架构、数据库字段就不会对这部分做灵活支持。

为了实现产品化的通用支持，往往是一组配置项或者一套配置模板来适配不同客户的需求。这样一套配置项或者模板的设计就不是1~2个小时可以轻松解决，更不用说开发、测试了。

场景六：又或者，对于To B产品，你千辛万苦按照需求的价值（即使已经涵盖了客户价值和商业价值）为产品开展设计并安排开发。需求干系人仍然可能认为你效率低下，因为干系人有他自己内心的优先级衡量标准，每一个项目的实际情况可能因为客户关系及竞争对手的变动而在随时变化。

这类组织效率问题，只要产品经理愿意“换位思考”（产品经理其实擅长这个），其实也不难发现，重要的是：

1. 洞悉产品项目干系人，干系人的“痛点”。
2. 理解“结构使然、与人品无关”，愿意倾听，不害怕埋怨，乐于寻找组织效率的原因。

2. 主动探索

（1）从产品质量角度

在从产品质量角度探索组织效率时，我会从功能质量、体验质量、共鸣质量及文档质量四个方面，来考量组织是否有效沟通和传递信息，以使得生产的产品满足质量要求。

思考产品功能设计是否满足用户需求，产品的体验设计是否让用户愉悦，产品设计是否可能在情感上与用户共鸣，以及产品相关文档的质量是否可以满足用户及协同部门的诉求。

例如：

1. 如果功能质量出了问题，可能是产品经理做需求调研或者设计时除了差错，最后可能导致产品无法满足上线要求，整个产品-开发-运营链条做了很多无用功-极度低效！
2. 如果体验质量出了问题，可能产品经理给UI团队传递信息失真，或者UI团队设计出差错，又或者UI设计在给研发宣讲时出差错，最后可能导致产品体验受到影响，使用阻力增强，降低用户转化率-低效！
3. 如果共鸣（情感）质量出了问题，可能是市场、营销和运营团队与产品经理没有沟通好营销策略，没法将产品与品牌更好的融合和表达给用户-降低了产品的品牌及情感效应，无形中降低了用户粘性和品牌溢价空间。
4. 如果文档质量出了问题，很可能来自于主要撰写人疏忽了阅读角色及经验背景，遗漏了本该书写的文档或内容。这将给产品价值的传播、产品的落地带来极大阻力。原本可能光芒四射的功能在一层一层沟通中消失殆尽。

（2）从产品范围角度

在从产品范围角度探索组织效率时，我会从产品是否缺失了范围内的功能和产品是否【超出范围内的功能】来考量组织是否高效地实现了产品。功能少做势必是组织效率低的一个重要特征，但功能做多了也不可小视。

因为多做会影响产品价值上线时间，并且如果多个团队同时开发同一个功能，一个团队的多做可能会导致与其他团队代码的不兼容，引发更大的效率问题。

（3）从产品时间角度

在从产品时间角度探索组织效率时，时间超长、超短可以帮我们洞察到组织效率的问题。可能是实际过程出现了效率问题，亦或者估算办法本身就有问题。无论是哪个问题，为了提升效率都应该关注。

（3）从产品成本角度

产品成本相对于产品时间来说较容易忽略，因为用时间来换算效率看起来更直观，而且资源成本也并不是产品经理很直观能考虑和控制到的。但如果想把组织效率做得更精细，“成本”确实是一个值得考虑的角度。

完成同样一件任务，使用相同的时间，用了成本不一样的资源，那成本将是不一样的。尤其初创公司，不仅分秒必争，而且还需要分文必“省”（花在最合适的地方）。所以成本是时间维度上，另一个挖掘组织效率的重要考量点。

尽管省钱这个事产品经理不一定能管理到，但是如果把成本换算成资源，那这个问题就很明显了。例如：研发资源本身在产品视角来看其实也是有区别的，A适合做X事情，B适合做Y事情。那么将资源合理安排在他最拿手的地方，将可能在最大程度上优化组织效率。

Tips：当然关于以上例子，还有另外一个思考效率的维度，就是让A做B能更快完成的事情。这种时候往往是在培养A/B角，让团队能力可以复制，减少未来人员调整的风险，这站在长远角度看其实也是另一种“效率优化”。

以上探索方向看起来虽然都是按产品结果导向的维度来考虑的，但是实际上在追溯原因时都需要回到过程中去。从过程视角去思考形成结果的原因，无论做得好的，或者不好的，都可能帮助我们找到效率优化的机会。

这类组织效率问题，答案比较开放，往往有许多综合要素需要考虑（这些要素会在下一小节介绍），面对主动探索效率问题，几个要点是：

1. 用心积累产品质量、范围、时间、成本案例，横向将当前项目和其它项目对比，纵向将本期项目与前期项目对比。
2. 了解与你合作的伙伴的习惯、特长和能力水平。
3. 适时适度开展回顾会，回溯效率问题。
4. 更为强势的主动探索手段，可以考虑给团队的下一期工作制定计划，通过设计协同，对协同进行A/B测试的形式优化组织效率，慎用。

7个优化效率的着力点

在发现效率问题后，如何解决这些问题呢？

以下是我惯常考虑的7个提升效率着力点，分别是：文档、会议、工具、流程、组织结构、人和文化。

1. 从文档下手

文档是组织协作过程中，面对面沟通的一个重要补充，也是工作流程中记录和追溯的重要手段。恰当的文档管理可以减少重复沟通，减少责任推诿，增加责任感。

如果企业内部管理要求不高，“敏捷”团队可以将“文档要求”和“内容框架”做成自检工具，而非必须死板恪守的“规矩”，只要自检保证自己所归档的内容满足高效沟通要求即可。

例如：随着产品用户增加，产品实施部署团队及客服团队在新功能上线时时常收到用户对于新功能的提问，大量的解答工作及问题的传导无论对实施、客户或者产品都十分影响效率。适时提出《功能发布说明文档》并安插在系统上线流程中要求完成，将大大优化这个新功能解答的过程。

优化方式示例：

1. 构建合适的“文档规划”，将需要文字明确说明，长期可复用或者需要持久保存的沟通内容，适度设计成标准文档，落入“文档规划”，并安插到工作流程中。
2. 为每一个文档建立标准“内容框架”，把沟通中容易疏忽的点规范有条理的设计到内容框架中，在组织过程中不断优化。

2. 从会议下手

会议曾一度盛行而后又进入提倡少开“会议”的阶段。其实会议是一个工具，并不是无所不能的发起，它有它擅长解决的问题，例如：快速决策、多人讨论、复杂讨论、预约关键人物时间、面对面冲突缓和与承诺、促进交流。

例如：产品团队每个迭代开始都需要确认上一个迭代开发任务的情况，以及接下来两个迭代的任务安排。在这些任务安排的过程中，可能涉及到研发细节、涉及细节的澄清和沟通，并且与会者往往是不同团队的Leader。这种情况下通过JIRA、邮件都难以及时，高效的完成这样的协同工作。

因此建立了迭代沟通与排期会，专门就以上工作进行统一讨论。讨论过程中往往可能针对某个具体功能细节带偏，这是需要主持人快速反应并将话题拉回主线。

优化方式示例：

1. 组织可以为日常需要集体决策或者集中商讨的复杂议题，适度建立固定的“会议规划”。
2. 组织还应为每一个会议建立基本的“会议框架”。

备注：注意培养提升与会者的会议“主持人技能”，会议本是为了解决效率问题，可是会议本身如果管理不当容易低效。

3. 从工具下手

市面上已经有一系列工具可以被用于提升组织效率，例如：软件项目管理常用的JIRA、禅道、文档与内容管理工具Confluence或者团队协同工具明道、Teambition等。重要的是找到团队遇到的问题，然后选择适合团队的工具去提升那一块的效率。

例如：前述场景一、二：原先通过Excel和邮件来管理和沟通需求，在制作产品汇报统计数据和记录，反馈前端需求时就遇到了效率低下的问题。原先进行汇报要用过Excel各种筛选公式去计算不同状态变化，并且绘制出图形展示给领导。

原先进行需求沟通，通过邮件收到需求，翻译成Excel内容格式录入进Excel，需求处理状态有变动，例如：上线时，还可能需要通过邮件通知干系人。

引入JIRA之后就大不一样了，统计数据通过JIRA查询语言可以很好组合，需求录入由干系人自己创建，处理状态JIRA系统自动邮件通知。

实施方式示例：

1. 根据效率问题发生的业务环节，适度引入适合组织的效率提升工具。
2. 尽可能统一工具，例如脑图工具、文档工具、图片工具等。

4. 从流程下手

流程往往是公司统一认可的工作顺序和输入输出标准，完备的流程可以确保工作完成的质量、效率。

例如：前述场景五、六：原先由产品根据不同需求干系人的需求描述，结合需求价值评估的方式，来进行需求排序和处理，这样的方式往往不一定能很好契合整体“干系人集合”的要求，往往人们容易偏向于觉得自己的需求最着急。

为了处理这个问题，我们增加需求处理流程，要求干系人们在提交需求时对“干系人需求集合“进行统一排序，将全力和责任交由最应该对这个需求集合排序的人。不仅解决了产品与需求干系人的矛盾，让需求干系人知道产品团队的工作量及难度，并且提升了需求交付对干系人来说的“效率”。

优化方式示例：

1. 根据公司实际业务需要，删除或者合并意义不大的流程，减少流程链条提升业务效率。
2. 根据公司实际业务需要，增加或优化意义重大的流程，避免因流程缺失带来的产品质量、范围、时间、成本等效率问题。

5. 从组织结构下手

组织结构决定权责分配也决定决策流程，是影响组织效率的关键，但正因为是关键因素，所以并不是轻易可以受到影响和变化的。

例如：前述场景三、四：新产品的产品、设计、研发团队往往方向明确（开发具体产品），大家按部就班开发未曾上线的产品。到了中期，产品在探索和扩张期，来自销售、客户、实施、内部新功能等各种需求变得多种多样。

而在团队内部，不同的同事间因为陆续的合作存在不同的默契度和自己所擅长的功能领域。为了最大可能优化组织效率，我们提出了组建细粒度小分队的建议，通过默契度组建小分队，每个小分队拥有基本可以覆盖开发需求的技能（前端、后端）。

并且为每个小分队打上功能标签，先让每个小分队拥有1~2个拿手的产品功能。以这样的形式，在团队内建立起处理各种功能需求的Queue，以期实现效率提升。

当然随着团队组建成熟，可以考虑牺牲一部分效率培养能力的相互备份，从而也能帮助团队接触新知识提升综合能力，并且加强各功能模块间的优秀经验共享。

优化方式示例：

1. 组织结构横向调整，增加或减少部门或者团队数量。
2. 组织结构纵向调整，增加或减少组织层级。
3. 职能型结构与项目型结构的组合运用，如增加临时项目团队、组建PMO等。

6. 从人下手

组织的效率来自于每个人效率以及人与人间协作效率的聚合，如果组织内的每个人都有极高的效率，相互之间也乐于和善于协作，那组织的效率势必会很高。

优化方式示例：

1. 增加培训和职业规划引导提升员工个人能力、自驱力从而提升工作效率。
2. 保持良好的团队建设，促进团队协作效率。
3. 抓稳人员的“入”和“出”，在入口严格筛选有助于组织效率的人员，对对组织效率还有重大影响人员进行及时妥善的调整。

7. 从文化下手

企业文化并非一朝一夕可以建成，在我看来成立10年的企业都未必可以创造出自己的企业文化。这几年的工作经验体会到的是，企业文化需要创始人/团队的传导，同时还需要在一定程度控制人员流动性的基础上来培养。

如果人员流动性强，凝聚力涣散，文化就不知从何谈起了。当企业培养起共同价值观、愿景及员工主人翁精神后，很多决策、工作的推动就会变得轻松。因为它们有价值观做标准，有主人翁精神做动力。比起没有培养起企业文化的公司会大不一样。

例如：我曾经听说过定制化To B产品企业转型产品化To B产品的例子。定制化产品的文化和思维，和产品化产品的文化和思维本身就存在一定冲突。这种冲突还会来自于人力资源的分配，也来自于产品的收费模式。

产品化产品一般没有项目专项支持的资源，也不是全靠定制化开发赚单个用户的钱。它一般通过实现通用功能将开发成本，分摊到多个客户身上，来给客户提供性价比极高的功能。这种变化让传统定制化产品的销售、实施和需求分析师都措不及防，以至于在一段时间内都没切换过思路，产品文化冲突内耗。

优化方式示例：

1. 促进公司价值观、愿景、使命和定位，并传导到公司各个部门。
2. 促进公司形成适合公司和产品的工作文化。
3. 适当树立标杆员工，控制好人员流动。

细心的读者可能会发现：这七个着力点我是按照实施的难易程度来进行排序的，文档调整较为容易，而文化的调整就很困难了。但是它们可以解决的问题也一般是由易至难的，如果文档能解决的问题就不要随便考虑用文化解决，那样的成本就太高了。

如何优化效率问题

知道如何发现效率问题，以及提升效率的7个着力点后，优化效率问题的过程其实很容易可以规划处理，基本过程可以参照：发现效率问题->确定提升方案->实施提升方案->回顾方案效果，四个步骤。

关于效率优化的一些Tips

（1）循序渐进，寻找适合组织的最佳模式

没有一个既有项目管理模式是完全可以搬来就最合适的，例如：即使SCRUM再被推崇现在也很难适配每一个团队。我推荐的是找一个产品类型、团队组成接近的管理模式，套用后逐步优化。遇到一个问题，“迭代”一次，敏捷地对项目进行管理。

（2）让别人知道你有多高效。

当你知道你自己足够高效，并且你也真的很高效了，但并不代表别人觉得你高效。及时共享你的工作任务，告诉别人你真的高效。

（3）没有职权、威望，就等那个Driver出现。

有时你发现了问题，也找到了解决方法，但是你不一定是那个最合适推动的人，并且最可怕的是别人不知道现在的效率有问题。如果这真的是个重要的问题，我相信很快就会凸显出来，别着急，谁最“痛”，谁就会成为这个优化方案的Driver，这时候找到他，推荐给他，你的成功几率应该会大许多。

（4）把干系人引入过程。

别人说你效率低，而你确实已经努力了。如果探索也没有探索出其它问题，可以尝试把提出的干系人引入处理过程中。或许你正是缺了他的参与才效率低下，又或者他参与后发现你其实很高效。

最后

让我们用脑图回顾一下文章主要内容：

本文由 @ Talen 原创发布于人人都是产品经理。未经许可，禁止转载

题图来自Unsplash，基于CC0协议