这篇文章我们就来说一说，产品经理在保证产品“价值”之后的第二大重要任务：保证组织“效率”。
抛砖引玉
优秀的产品经理不仅要确保产品对于企业的商业价值、用户的功能价值，还要确保产品的用户的体验价值和共鸣价值。可以说确保产品的诸多价值是产品经理的第一要务，我对这一点也是深信不疑的。但是不是保证了价值后，产品就定能突出重围获得成功？我相信大家的答案一定和我一样：“不是的！”。
产品从点子到知名产品的道路上充满荆棘，至少需要经历三个大阶段，设计-生产-销售。对于互联网产品来说，可以翻译为设计-开发-运营。即使产品的商业价值论证做得再好，功能和体验价值设计得再完善。低效的开发、运营过程都有可能毁掉你“完美”的设计。
有幸经历过几家不同类型的企业（外企、国企、创企、民企），尤其是最近一段经历，在十几岁的民企的“创新业务”事业部伴随着部门基本从“0”到“1”的成长，在领导的带领下，我收获了不少在组织效率上实践和思考的机会。产品成长的过程，其实也包含了组织成长的过程。
随着产品及组织的成长，管理工具和手段也在不断的变化：
需求管理从Email、Excel到Web工具，如：JIRA、Wiki。会议管理从全临时会议到逐步增加重点会议。文档管理从纯PRD、接口规范到操作手册、功能发布说明书。项目管理从早期的赶工到现在地向敏捷靠拢。……
这篇文章我们就来说一说，我认为产品经理在保证产品“价值”之后的第二大重要任务：保证组织“效率”。
如何洞察效率问题
在我自己工作经验里，洞察组织效率问题的工作往往是深入在日常工作过程中的。有被动的发现，也有主动探索，在实际工作过程中，我更多思考和处理的是被动发现的效率问题。
1.被动发现
自己的效率：当自己被同一类困难困扰时
在一个坑摔一次是没经验，在一个坑摔两次是不长记性，在一个坑摔三次那就不可被原谅了。重复被同一类困难困扰时，这个困扰便极有可能是效率待提升的点。
例如：
场景一：每周都需要进行本周需求处理情况汇总，Excel记录的需求，多部门难以联合维护，状态转换过程难以记录。想要一个本月从“待验收”转变成“已上线”的需求的数量特别困难，需要耗费大量时间整理，而且每周一次。场景二：接收来自多个项目针对本产品的需求时，来自不同项目，不同背景的人书写的需求描述各不相同。即使提供了Word版本的需求沟通模板+填写示例，依然有很多人不照常理出牌，导致重复进行电话确认，影响效率。
这类组织效率问题，较容易发现，最重要的是产品经理需要培养起自己的效率意识！
同事的效率：当同事提出工作优化需求时
产品经理是一个在产品过程中影响力较为广泛的角色，许多的产品过程都会被引入其中，无论是早期的商业论证、线框设计、UI设计、评审、宣讲到后期的验收和运营策略设计。如果产品经理乐于与不同的协作角色讨论工作过程，并且你遇到有丰富经验又追求高效工作的同事，他们往往会向你主动提出协同优化工作效率的需求。
例如：
场景三：产品早期，因为产品资源相对研发和测试资源少，并且产品未大范围推广所以需求变更数量也不多，所以往往需求都可以在1、2个迭代周期内消化完毕。研发、测试资源不会有太大冲突，项目平稳前进。
到了产品中期，随着需求数量，产品研发资源调整，研发和测试资源开始遇到瓶颈，需求已经无法被及时消化，时而会形成多个产品经理的需求多头管理。这时有经验的研发和测试就会主动提出问题，希望产品团队可以统一管理需求，避免多头管理的情况，以尽可能减少研发测试切换上下文时间而提升团队效率。
场景四：产品中期，产品需求与设计的复杂度逐渐增加，一个需求可能涉及2、3个研发团队协同开发，而测试也会有提前准备完备测试用例的需求。因此为了更好的完成需求与设计的传递工作，研发和测试团队提出了开展固定需求周例会的工作。
通过例会梳理、澄清需求，确定每个需求研发主责任人，并通过会议“通气儿”，达成任务上的一致。
这类组织效率问题，其实也不难发现，重要的是：
产品经理要善于和乐于沟通组织效率问题，让同事愿意对组织效率畅所欲言。尽量让自己在组织过程中扮演更重要的角色，例如：由产品负责搭建JIRA系统，配置工作流。遇到有主人翁意识的同事。
别人眼中的效率：当别人不知道你有多高效时
互联网产品往往诞生于项目，有项目就有干系人。你的直属上司，你的大老板、你的对口客户，客户的老板，推广你产品的运营销售团队，实施你产品的实施部署团队，甚至对你加班埋怨已久的媳妇。
你在一个迭代做了15件事情，干系人可能只关心他的那一件，即使他是优先级最高第一个完成的，他也会在质量、范围、时间等各种维度产生不满。
用最近看的一本书《项目管理心理学实践》里的一句话（大概是这么说的）来解释：
“结构使然，与人品无关”。
身居其位谋其*，我们能做的是增强沟通、缓解氛围。短线看，花了更多时间去做沟通，降低了工作效率，但长远看团队协作氛围及凝聚向心力的提升，会为后续各种合作带来“好处”。
例如：
场景五：做为一个产品化产品（与定制化产品对立）的产品经理，你会收到来自各个渠道的需求反馈。有一些是定制化的，有一些是确实有价值的。对于确实有价值的需求，适时会开展设计工作，对于有技术基础、相对强势的需求方往往会吐槽需求实现耗时长，尤其在ToB产品中较为常见。例如：一个要求在业务操作页增加新字段或者业务约束，以匹配客户管理诉求的需求。
对定制化开发来说，一个字段，一个逻辑检查可能1~2小时开发、测试加部署就可以上线。但是落到产品化产品中，如果原先产品设计假设里假设这部分不会有定制化需求，那么设计架构、数据库字段就不会对这部分做灵活支持。
为了实现产品化的通用支持，往往是一组配置项或者一套配置模板来适配不同客户的需求。这样一套配置项或者模板的设计就不是1~2个小时可以轻松解决，更不用说开发、测试了。
场景六：又或者，对于ToB产品，你千辛万苦按照需求的价值（即使已经涵盖了客户价值和商业价值）为产品开展设计并安排开发。需求干系人仍然可能认为你效率低下，因为干系人有他自己内心的优先级衡量标准，每一个项目的实际情况可能因为客户关系及竞争对手的变动而在随时变化。
这类组织效率问题，只要产品经理愿意“换位思考”（产品经理其实擅长这个），其实也不难发现，重要的是：
洞悉产品项目干系人，干系人的“痛点”。理解“结构使然、与人品无关”，愿意倾听，不害怕埋怨，乐于寻找组织效率的原因。
2.主动探索
（1）从产品质量角度
在从产品质量角度探索组织效率时，我会从功能质量、体验质量、共鸣质量及文档质量四个方面，来考量组织是否有效沟通和传递信息，以使得生产的产品满足质量要求。
思考产品功能设计是否满足用户需求，产品的体验设计是否让用户愉悦，产品设计是否可能在情感上与用户共鸣，以及产品相关文档的质量是否可以满足用户及协同部门的诉求。
例如：
如果功能质量出了问题，可能是产品经理做需求调研或者设计时除了差错，最后可能导致产品无法满足上线要求，整个产品-开发-运营链条做了很多无用功-极度低效！如果体验质量出了问题，可能产品经理给UI团队传递信息失真，或者UI团队设计出差错，又或者UI设计在给研发宣讲时出差错，最后可能导致产品体验受到影响，使用阻力增强，降低用户转化率-低效！如果共鸣（情感）质量出了问题，可能是市场、营销和运营团队与产品经理没有沟通好营销策略，没法将产品与品牌更好的融合和表达给用户-降低了产品的品牌及情感效应，无形中降低了用户粘性和品牌溢价空间。如果文档质量出了问题，很可能来自于主要撰写人疏忽了阅读角色及经验背景，遗漏了本该书写的文档或内容。这将给产品价值的传播、产品的落地带来极大阻力。原本可能光芒四射的功能在一层一层沟通中消失殆尽。
（2）从产品范围角度
在从产品范围角度探索组织效率时，我会从产品是否缺失了范围内的功能和产品是否来考量组织是否高效地实现了产品。功能少做势必是组织效率低的一个重要特征，但功能做多了也不可小视。
因为多做会影响产品价值上线时间，并且如果多个团队同时开发同一个功能，一个团队的多做可能会导致与其他团队代码的不兼容，引发更大的效率问题。
（3）从产品时间角度
在从产品时间角度探索组织效率时，时间超长、超短可以帮我们洞察到组织效率的问题。可能是实际过程出现了效率问题，亦或者估算办法本身就有问题。无论是哪个问题，为了提升效率都应该