怎么能确诊白癜风 http://pf.39.net/bdfyy/qsnbdf/140908/4467176.html当产品经理积累大量实战经验与岗位认知后，学会从中总结方法论与心得能够帮助我们高速成长。那么具体要怎么做呢？过程中有哪些要点要掌握呢？笔者将结合这些点梳理如何打造产品方法论。28岁岁末的时候，立了个flag，希望在30岁时，能形成自己的产品方法论，如今而立已过，开始做数据产品相关工作也近有五年；这五年来，因为人生轨迹的跳跃，产品本身所在的行业并不固定。好在产品逻辑本身可以触类旁通，加之无论行业如何，自己的兴趣和做的事情，都是数据产品本身。行业上走过了电商O2O、在线教育、智能硬件、金融风控，产品范围也从之前的数据分析产品跨度到了数据服务、数据应用产品。外人看来只见其宽，而自己而言，实际一直在数据产品的领域耕耘沉淀。遂尝试着整理过往的思考和笔记，算是自己的成长，也是不成熟的分享。01建立自己理解业务的方法模型理解业务是理解需求的大前提，所谓理解业务，往大了说是理解公司的商业模式，往小了说是理解产品的具体应用场景。事实上，即使是相同行业的不同公司，业务模型也是千差万别；掌握一套理解业务的方法论，能够使我们的产品之路不局限于行业和平台，快速向新的领域拓展自己的产品力，能够使我们快速的理解新平台的需求场景，更好的推进产品实施；就实践而言，当我们接手一个新的产品之后，可以分以下步骤去了解业务，以及负责产品对业务的意义：1.与业务核心KP沟通，了解业务流程，并自己绘制一个业务流程图，明确以下信息整个业务分几个环节、步骤？每个步骤的具体内容是什么？每个步骤之间的依赖关系？2.梳理业务业务流程图后，对着业务流程图，我们要知悉并思考以下信息业务各步骤涉及的人员、应用系统都有哪些？我们负责的产品处于哪个步骤，涉及人员有哪些，解决的核心问题是什么？这个时候，我们基本已经定位了自己产品所处的位置，以及产品解决的问题，那么就可以通过具体了解该环节产品涉及人员的具体操作流程，来理解产品的需求本质；如果条件允许，最好自己参与到业务的实际操作中去；这种参与不是简单的用用自己设计的产品，而是要以业务角色的身份，融入到业务中。02掌握基本的产品研发流程产品经理需要了解一个产品从需求到上线运营的整个流程。虽然各类产品课程都有这方面的介绍，但落地到每一个公司，这个流程又千差万别。产品的实现的基本阶段可以分为以下几个环节：需求阶段；（收集需求，需求调研，竞品调研）产品设计阶段；（信息架构设计、交互原型设计、需求文档撰写）开发实现阶段；（需求评审、排期、开发、测试、验收）上线运营阶段；（发版、运营）整个流程，根据各公司的组织结构、采取的开发模式不同，具体做的事情可能会不一致，比如很多后台产品，本质上没有竞品调研阶段；很多产品经理其实也没有信息架构设计的习惯，某一些研发团队会把需求评审和排期放一起，等等，不一而足。但无论所处的环境如何，产品经理自己心中一定要有一杆秤，知道哪个阶段该干什么事情。我们不一定非要按照哪本书定义的方式来，心中有杆秤的意义在于，如果需要我们从0开始打造一个团队打造一个产品，能够如何快速的组织起项目工作。落到实践上，产品经理至少能画清楚三个流程图：传统的瀑布开发模式下的研发流程图；敏捷模式下的研发流程图；自己当前所处的团队所采用的实际研发流程图；以下是笔者之前整理的一个研发流程图：流程图仅仅只是体现了研发过程的框架，我们还要知道并且能够写清楚，某一个节点的关键事项和输出，比如需要一个什么会议，产出什么文档；同时各公司可能都有自己的项目管理协作工具（比如teambition、jira等），我们要梳理清楚这个流程如何在协作工具上体现；如下图梳理了一个研发流程的关键动作以及输出：对于很多公司而言，这个开发流程可能由专门的项目经理或研发经理搭建并把控。笔者的意见是，无论流程具体的onwner是谁，将一件具体的事情抽象化、流程化，本来就是产品经理逻辑能力的体现，无论从提升自己的产品专业能力角度、还是加强自己的项目管理能力角度，都具有重要意义。03有一套自己的产品设计风格我们常说的产品化，本质上是将一套解决方案固化下来，说白了，就是套路，产品化即套路实体化。前述的业务理解模型、开发流程，亦是业务理解的套路、开发流程套路。产品经理要有一种无时无刻不在做产品的思维习惯，亦即无时无刻不在总结套路，所谓的自己的产品设计风格，即是自己做设计时有一套成型的方案套路。总结下来，三个方面：1.根据所在团队的开发偏好，确立自己的文档规范BRD、MRD、PRD、原型图这些产品经理的产出文档，网上没有统一的模板，但作为个人要有统一的规范。所谓的规范，即前后一致，逻辑自洽，比如写PRD的时候，同样是功能描述，一般有两种方式：前端逻辑、后端逻辑、统计需求分开描述，好处是相关开发能够更快的get到自己要做的事情，坏处是任何一个开发都缺乏对功能的全局掌控，不清楚自己的这个接口、表设计最终展现给用户是什么形态。主要描述交互逻辑，后端逻辑夹杂在交互描述中，好处是开发能以用户视角清楚功能最终的形态，坏处是前后端的逻辑要由开发做二次拆分。产品经理可以根据开发团队的偏好，选择一种模式，但同一个项目下的PRD，最好保持相同的方式，而不是这个需求用第一种，另一个需求用第二种。以下是笔者之前在某家公司的梳理的PRD文档规范：2.原型设计时，有一套自己风格的素材库很多产品经理会在网上找一些原型素材，作为自己设计的模板。但进阶的产品经理，一定要能够将已有的素材融入自己的设计风格，甚至根据所在公司的业务特点和设计规范，自建自己的素材库。当别人在看到一个原型、一个文档、一个产品时，能说出“这很有XXX的风格”，笔者认为，这就是产品经理的一步成功。04选择并建立自己的产品理念乔布斯、俞军、张小龙、梁宁等产品大佬都会在各种场合输出自己的产品价值、产品理念、方法论。作为产品界的芸芸众生，对于这些理念当然先是理解，其次是尝试着在实践中运用。但到了一定阶段之后，我们需要选择并坚持打磨，只有坚持的理念才能称为理念，也才算是理解。再之后，就要尝试着建立自己的理念、价值、方法。以下分享几条笔者坚持的产品理念：MVP原则：抓住核心需求，以最小可行化最低成本方式去验证需求是否成立。如无必要，勿增实体：一个功能、一个控件、一个操作的新增，很多时候并不是看起来那么简单，很可能会对现有架构、流程造成极大的改动。取舍理念：这个世界没有十全十美的解决方案，任何一个方案，都有其优势劣势，你不是三井寿，不能什么都想要。通用化：任何一个设计，不能只考虑眼前，一定要考虑是否兼容未来的规划和产品的最终形态。再分享几条产品工作的方法原则：坚持学习技术：要对自己负责的产品所使用的技术逻辑有基本的了解，才能更好的跟开发合作；主动背锅：主动承担产品开发、运营过程中出现偏差的责任，当产品功能与预期不符时，首先一定要反思是否自己的需求描述没有讲清楚。任何时候，不要有开发理所应当这么理解的想法；善意沟通：不要去为沟通对象预设立场，永远抱着解决问题的姿态去沟通。关于产品理念和工作方法，这里只简单的点一下。更详细更多的内容，未来会单独整理文章。这里想表达的核心是：进阶的产品经理，要有自己的做事方法、理念，而不再是见步看步，被环境左右。这些其实都是平时整理的点点滴滴关于产品的思考和总结的拼凑。工作七年，产品工作五年，看了下为知笔记，在各公司各项目输出的规范、文档、流程该接近百万字了，平时吐槽不少，但却并没有时间好好整理自己的思考。这是一个开头，如果你也热爱产品，热爱数据，赐教。本文由尘寰原创发布于人人都是产品经理。未经许可，禁止转载题图来自Unsplash，基于CC0协议
