最近身边一产品经理在那抱怨，说业务的一个领导（研发出身）要求，IT要走在业务前面，要把系统与功能等都先行实现，然后给业务运营培训就可以，不要等待业务都想明白了需求提清楚再开始！但去年出现了几个项目发布上线了因业务发生变化就没对外开展过业务！
我理解这位产品经理的困惑，也知晓这位领导说这话的背景；
产品经理的困惑在于，我自己规划设计并实施上线当然没问题，但在项目上线后，业务运营反过来经常问为什么这么设计？为什么这个功能没有？没有这些功能模块怎么运营？当然更多的是做了很多功能，结果被使用或常用的不到1/10. 自己辛辛苦苦从业务刚开始有想法时就介入，一直到产品上线，结果竟然很难获得业务的认同，财务最后核算项目成本时惊讶发现怎么做了这个模块花了那么多研发成本？相比那些等着业务需求提过来，按照需求实现，业务对他们反而更认可；究竟是哪里错了？
而这位业务领导说的则是他过往的经验，他当时做的系统项目是提升业务运营效率与管理质量的ERP及内部员工用的信息化系统项目；注意，这些系统的用户是内部员工为主体，公司提供的信息化系统及相关工具，具有不可替代及半强制性，强调流程闭环，而操作体验则非首要考量因素，通俗来说能用即可！其次，这类IT项目通常是相对成熟的行业类产品，更多的是已实现功能场景化落地，用户都没见过或没使用过，真的无法提出详细需求；再者，负责实施这些项目的产品经理，通常也是了解业务的相对资深人员，说是比业务更懂业务一点也不夸张！因而这类项目IT人员更具主导性。“我做啥你用啥”
我们可以看做是ERP时代的特征！
文中开头产品经理的的背景则是互联网时期，研发的产品使用对象成了无法直接接触的普通用户；用户对象变了，对产品要求不一样了，因不再直接接触用户，产品的使用体验要求更高，除了完成基本功能外，更需要关注操作体验，方能获取留住用户，这是其一；
其二，互联网时期通常不再是成熟产品的场景化改造，而是满足业务目标的针对性系统解决方案，研发方式也发生根本性的变化，进而催生出产品经理、交互设计师、视觉设计师、前后端开发工程师、产品体验官等新兴岗位，研发流程也从瀑布式开发到敏捷开发转变，小步快跑、大胆试错，不断迭代优化；
其三，团队分工的变化，ERP时期，以提升效率与运营管理质量为主的工具式使用，对系统的研究与需求是IT人员主导的事，业务运营人员是被动接受的，好用最好，能用即可，系统实施好给业务人员做好培训；而互联网时期以线上业务为主时，有着明确的业务与运营团队，IT团队做出的信息化产品是他们为用户提供产品与服务最核心载体，也是实现他们业务运营指标的最重要通道，有想法、更专业是对业务运营团队的基本要求；满足用户需求是必须，但还得看是否对业务目标达成有帮助。
其四，需求来源发生根本性变化；ERP时期的项目推行通常是公司管理高层的意志，通常是战略性的，那时叫“信息化”，决定做的项目一定会推进并能够得到很好的执行，IT团队不用过多考虑项目研发成本，觉得对业务有帮助就可以做；而如今针对以线上开展业务为主的互联网时期，各业务单元独立核算，对应研发费用通常会被纳入业务财务指标中，故新增研发项目，业务会考虑该功能实现的价值是否能够覆盖成本，IT团队自行启动不由其买单的项目就显得“我行我素”了；业务运营团队的角色已从原先的被动执行变成了买单者；也就是说驱动此研发项目的需求从原内部高层转变成了负责用户及市场运营的业务团队。
看完以上分析，你自然会得出结论，不同时期、不同阶段、不同组织会有组织形式、工作流程等方面的差异；但加强协作、提早参与、聚焦共同的业务目标永远不会过时，组织再大、分工再细，无论是组织上的事实统一还是虚拟组织上的统一，都需要共同为业务目标达成体现自己的价值。
因而，在业务运营都还没能力没想清楚的情况下，如果你比业务还懂业务，自然可以你做好了给她们用；但即使此种情况下，也要统筹考虑时间成本、机会成本、资源投入等，匹配当前的组织成熟度与市场用户接受度；实现结果上的按需实现！这样，方能真正体现产品经理的价值。
一句话，有能力提供成品给业务用固然很好，因为现在有诸多现成的工具与系统，稍做调整就可以；但针对此文中提到的新业务，已有工具或模块无法满足时，需要消耗诸多资源方能实现时，无论是节约成本还是时间要求角度，都需要团队各方做好沟通，达成共识。
（——做个有灵魂的产品经理）
网友评论