提升组织“效率”

这是一篇关于提升组织“效率”的思维导图，主要内容包括：如何优化效率问题?，7个优化效率的着力点，如何洞察效率问题，随着产品及组织的成长，管理工具和手段也在不断的变化，优秀的产品经理价值。

提升组织“效率”

• 1. 优秀的产品经理价值
  • 企业的商业价值、用户的功能价值，
  • 产品的用户的体验价值和共鸣价值
• 2. 随着产品及组织的成长，管理工具和手段也在不断的变化
  • 需求管理从Email、Excel到Web工具，如：JIRA、Wiki。
  • 会议管理从全临时会议到逐步增加重点会议。
  • 文档管理从纯PRD、接口规范到操作手册、功能发布说明书。
  • 项目管理从早期的赶工到现在地向敏捷靠拢。
• 3. 如何洞察效率问题
  • 1. 被动发现
    • 自己的效率：当自己被同一类困难困扰时在一个坑摔一次是没经验，在一个坑摔两次是不长记性，在一个坑摔三次那就不可被原谅了。重复被同一类困难困扰时，这个困扰便极有可能是效率待提升的点。
    • 例如：
      • 场景一：每周都需要进行本周需求处理情况汇总，Excel记录的需求，多部门难以联合维护，状态转换过程难以记录。想要一个本月从“待验收”转变成“已上线”的需求的数量特别困难，需要耗费大量时间整理，而且每周一次。
      • 场景二：接收来自多个项目针对本产品的需求时，来自不同项目，不同背景的人书写的需求描述各不相同。即使提供了Word版本的需求沟通模板+填写示例，依然有很多人不照常理出牌，导致重复进行电话确认，影响效率。
  • 2. 主动探索
    • （1）从产品质量角度
      • 在从产品质量角度探索组织效率时，我会从功能质量、体验质量、共鸣质量及文档质量四个方面，来考量组织是否有效沟通和传递信息，以使得生产的产品满足质量要求。
      • 思考产品功能设计是否满足用户需求，产品的体验设计是否让用户愉悦，产品设计是否可能在情感上与用户共鸣，以及产品相关文档的质量是否可以满足用户及协同部门的诉求。
      • 如果功能质量出了问题，可能是产品经理做需求调研或者设计时除了差错，最后可能导致产品无法满足上线要求，整个产品-开发-运营链条做了很多无用功-极度低效！
      • 如果体验质量出了问题，可能产品经理给UI团队传递信息失真，或者UI团队设计出差错，又或者UI设计在给研发宣讲时出差错，最后可能导致产品体验受到影响，使用阻力增强，降低用户转化率-低效！
      • 如果共鸣（情感）质量出了问题，可能是市场、营销和运营团队与产品经理没有沟通好营销策略，没法将产品与品牌更好的融合和表达给用户-降低了产品的品牌及情感效应，无形中降低了用户粘性和品牌溢价空间。
      • 如果文档质量出了问题，很可能来自于主要撰写人疏忽了阅读角色及经验背景，遗漏了本该书写的文档或内容。这将给产品价值的传播、产品的落地带来极大阻力。原本可能光芒四射的功能在一层一层沟通中消失殆尽。
      • 子主题
    • （2）从产品范围角度
      • 在从产品范围角度探索组织效率时，我会从产品是否缺失了范围内的功能和产品是否【超出范围内的功能】来考量组织是否高效地实现了产品。功能少做势必是组织效率低的一个重要特征，但功能做多了也不可小视。
      • 因为多做会影响产品价值上线时间，并且如果多个团队同时开发同一个功能，一个团队的多做可能会导致与其他团队代码的不兼容，引发更大的效率问题。
    • （3）从产品时间角度
      • 在从产品时间角度探索组织效率时，时间超长、超短可以帮我们洞察到组织效率的问题。可能是实际过程出现了效率问题，亦或者估算办法本身就有问题。无论是哪个问题，为了提升效率都应该关注。
    • （3）从产品成本角度
      • 产品成本相对于产品时间来说较容易忽略，因为用时间来换算效率看起来更直观，而且资源成本也并不是产品经理很直观能考虑和控制到的。但如果想把组织效率做得更精细，“成本”确实是一个值得考虑的角度。
      • 完成同样一件任务，使用相同的时间，用了成本不一样的资源，那成本将是不一样的。尤其初创公司，不仅分秒必争，而且还需要分文必“省”（花在最合适的地方）。所以成本是时间维度上，另一个挖掘组织效率的重要考量点。
      • 尽管省钱这个事产品经理不一定能管理到，但是如果把成本换算成资源，那这个问题就很明显了。例如：研发资源本身在产品视角来看其实也是有区别的，A适合做X事情，B适合做Y事情。那么将资源合理安排在他最拿手的地方，将可能在最大程度上优化组织效率。
  • 以上探索方向看起来虽然都是按产品结果导向的维度来考虑的，但是实际上在追溯原因时都需要回到过程中去。从过程视角去思考形成结果的原因，无论做得好的，或者不好的，都可能帮助我们找到效率优化的机会。
  • 当然关于以上例子，还有另外一个思考效率的维度，就是让A做B能更快完成的事情。这种时候往往是在培养A/B角，让团队能力可以复制，减少未来人员调整的风险，这站在长远角度看其实也是另一种“效率优化”。
  • 几个要点是：
    • 用心积累产品质量、范围、时间、成本案例，横向将当前项目和其它项目对比，纵向将本期项目与前期项目对比。
    • 了解与你合作的伙伴的习惯、特长和能力水平。
    • 适时适度开展回顾会，回溯效率问题。
    • 更为强势的主动探索手段，可以考虑给团队的下一期工作制定计划，通过设计协同，对协同进行A/B测试的形式优化组织效率，慎用。
• 4. 7个优化效率的着力点
  • 1. 从文档下手
    • 文档是组织协作过程中，面对面沟通的一个重要补充，也是工作流程中记录和追溯的重要手段。恰当的文档管理可以减少重复沟通，减少责任推诿，增加责任感。
    • 如果企业内部管理要求不高，“敏捷”团队可以将“文档要求”和“内容框架”做成自检工具，而非必须死板恪守的“规矩”，只要自检保证自己所归档的内容满足高效沟通要求即可。
    • 例如：随着产品用户增加，产品实施部署团队及客服团队在新功能上线时时常收到用户对于新功能的提问，大量的解答工作及问题的传导无论对实施、客户或者产品都十分影响效率。适时提出《功能发布说明文档》并安插在系统上线流程中要求完成，将大大优化这个新功能解答的过程。
    • 优化方式示例：
      • 构建合适的“文档规划”，将需要文字明确说明，长期可复用或者需要持久保存的沟通内容，适度设计成标准文档，落入“文档规划”，并安插到工作流程中。
      • 为每一个文档建立标准“内容框架”，把沟通中容易疏忽的点规范有条理的设计到内容框架中，在组织过程中不断优化。
  • 2. 从会议下手
    • 会议曾一度盛行而后又进入提倡少开“会议”的阶段。其实会议是一个工具，并不是无所不能的发起，它有它擅长解决的问题，例如：快速决策、多人讨论、复杂讨论、预约关键人物时间、面对面冲突缓和与承诺、促进交流。
    • 例如：产品团队每个迭代开始都需要确认上一个迭代开发任务的情况，以及接下来两个迭代的任务安排。在这些任务安排的过程中，可能涉及到研发细节、涉及细节的澄清和沟通，并且与会者往往是不同团队的Leader。这种情况下通过JIRA、邮件都难以及时，高效的完成这样的协同工作。
    • 因此建立了迭代沟通与排期会，专门就以上工作进行统一讨论。讨论过程中往往可能针对某个具体功能细节带偏，这是需要主持人快速反应并将话题拉回主线。
    • 优化方式示例：
      • 组织可以为日常需要集体决策或者集中商讨的复杂议题，适度建立固定的“会议规划”。
      • 组织还应为每一个会议建立基本的“会议框架”。
      • 备注：注意培养提升与会者的会议“主持人技能”，会议本是为了解决效率问题，可是会议本身如果管理不当容易低效。
  • 3. 从工具下手
    • 市面上已经有一系列工具可以被用于提升组织效率，例如：软件项目管理常用的JIRA、禅道、文档与内容管理工具Confluence或者团队协同工具明道、Teambition等。重要的是找到团队遇到的问题，然后选择适合团队的工具去提升那一块的效率。
    • 例如：前述场景一、二：原先通过Excel和邮件来管理和沟通需求，在制作产品汇报统计数据和记录，反馈前端需求时就遇到了效率低下的问题。原先进行汇报要用过Excel各种筛选公式去计算不同状态变化，并且绘制出图形展示给领导。
    • 原先进行需求沟通，通过邮件收到需求，翻译成Excel内容格式录入进Excel，需求处理状态有变动，例如：上线时，还可能需要通过邮件通知干系人。
    • 引入JIRA之后就大不一样了，统计数据通过JIRA查询语言可以很好组合，需求录入由干系人自己创建，处理状态JIRA系统自动邮件通知。
    • 实施方式示例：
      • 根据效率问题发生的业务环节，适度引入适合组织的效率提升工具。
      • 尽可能统一工具，例如脑图工具、文档工具、图片工具等。
  • 4. 从流程下手
    • 流程往往是公司统一认可的工作顺序和输入输出标准，完备的流程可以确保工作完成的质量、效率。
    • 例如：前述场景五、六：原先由产品根据不同需求干系人的需求描述，结合需求价值评估的方式，来进行需求排序和处理，这样的方式往往不一定能很好契合整体“干系人集合”的要求，往往人们容易偏向于觉得自己的需求最着急。
    • 为了处理这个问题，我们增加需求处理流程，要求干系人们在提交需求时对“干系人需求集合“进行统一排序，将全力和责任交由最应该对这个需求集合排序的人。不仅解决了产品与需求干系人的矛盾，让需求干系人知道产品团队的工作量及难度，并且提升了需求交付对干系人来说的“效率”。
    • 优化方式示例：
      • 根据公司实际业务需要，删除或者合并意义不大的流程，减少流程链条提升业务效率。
      • 根据公司实际业务需要，增加或优化意义重大的流程，避免因流程缺失带来的产品质量、范围、时间、成本等效率问题。
  • 5. 从组织结构下手
    • 组织结构决定权责分配也决定决策流程，是影响组织效率的关键，但正因为是关键因素，所以并不是轻易可以受到影响和变化的。
    • 例如：前述场景三、四：新产品的产品、设计、研发团队往往方向明确（开发具体产品），大家按部就班开发未曾上线的产品。到了中期，产品在探索和扩张期，来自销售、客户、实施、内部新功能等各种需求变得多种多样。
    • 而在团队内部，不同的同事间因为陆续的合作存在不同的默契度和自己所擅长的功能领域。为了最大可能优化组织效率，我们提出了组建细粒度小分队的建议，通过默契度组建小分队，每个小分队拥有基本可以覆盖开发需求的技能（前端、后端）。
    • 并且为每个小分队打上功能标签，先让每个小分队拥有1~2个拿手的产品功能。以这样的形式，在团队内建立起处理各种功能需求的Queue，以期实现效率提升。
    • 当然随着团队组建成熟，可以考虑牺牲一部分效率培养能力的相互备份，从而也能帮助团队接触新知识提升综合能力，并且加强各功能模块间的优秀经验共享。
    • 优化方式示例：
      • 组织结构横向调整，增加或减少部门或者团队数量。
      • 组织结构纵向调整，增加或减少组织层级。
      • 职能型结构与项目型结构的组合运用，如增加临时项目团队、组建PMO等。
  • 6. 从人下手
    • 组织的效率来自于每个人效率以及人与人间协作效率的聚合，如果组织内的每个人都有极高的效率，相互之间也乐于和善于协作，那组织的效率势必会很高。
    • 优化方式示例：
      • 增加培训和职业规划引导提升员工个人能力、自驱力从而提升工作效率。
      • 保持良好的团队建设，促进团队协作效率。
      • 抓稳人员的“入”和“出”，在入口严格筛选有助于组织效率的人员，对对组织效率还有重大影响人员进行及时妥善的调整。
  • 7. 从文化下手
    • 企业文化并非一朝一夕可以建成，在我看来成立10年的企业都未必可以创造出自己的企业文化。这几年的工作经验体会到的是，企业文化需要创始人/团队的传导，同时还需要在一定程度控制人员流动性的基础上来培养。
    • 如果人员流动性强，凝聚力涣散，文化就不知从何谈起了。当企业培养起共同价值观、愿景及员工主人翁精神后，很多决策、工作的推动就会变得轻松。因为它们有价值观做标准，有主人翁精神做动力。比起没有培养起企业文化的公司会大不一样。
    • 例如：我曾经听说过定制化To B产品企业转型产品化To B产品的例子。定制化产品的文化和思维，和产品化产品的文化和思维本身就存在一定冲突。这种冲突还会来自于人力资源的分配，也来自于产品的收费模式。
    • 产品化产品一般没有项目专项支持的资源，也不是全靠定制化开发赚单个用户的钱。它一般通过实现通用功能将开发成本，分摊到多个客户身上，来给客户提供性价比极高的功能。这种变化让传统定制化产品的销售、实施和需求分析师都措不及防，以至于在一段时间内都没切换过思路，产品文化冲突内耗。
    • 优化方式示例：
      • 促进公司价值观、愿景、使命和定位，并传导到公司各个部门。
      • 促进公司形成适合公司和产品的工作文化。
      • 适当树立标杆员工，控制好人员流动。
  • 细心的读者可能会发现：这七个着力点我是按照实施的难易程度来进行排序的，文档调整较为容易，而文化的调整就很困难了。但是它们可以解决的问题也一般是由易至难的，如果文档能解决的问题就不要随便考虑用文化解决，那样的成本就太高了。
• 5. 如何优化效率问题?
  • 发现效率问题
  • 确定提升方案
  • 实施提升方案
  • 回顾方案效果
  • 举例
    • （1）循序渐进，寻找适合组织的最佳模式
      • 没有一个既有项目管理模式是完全可以搬来就最合适的，例如：即使SCRUM再被推崇现在也很难适配每一个团队。我推荐的是找一个产品类型、团队组成接近的管理模式，套用后逐步优化。遇到一个问题，“迭代”一次，敏捷地对项目进行管理。
    • （2）让别人知道你有多高效。
      • 当你知道你自己足够高效，并且你也真的很高效了，但并不代表别人觉得你高效。及时共享你的工作任务，告诉别人你真的高效。
    • （3）没有职权、威望，就等那个Driver出现。
      • 有时你发现了问题，也找到了解决方法，但是你不一定是那个最合适推动的人，并且最可怕的是别人不知道现在的效率有问题。如果这真的是个重要的问题，我相信很快就会凸显出来，别着急，谁最“痛”，谁就会成为这个优化方案的Driver，这时候找到他，推荐给他，你的成功几率应该会大许多。
    • （4）把干系人引入过程。
      • 别人说你效率低，而你确实已经努力了。如果探索也没有探索出其它问题，可以尝试把提出的干系人引入处理过程中。或许你正是缺了他的参与才效率低下，又或者他参与后发现你其实很高效。