小公司产品经理：如何改善“野路子”，构建自己的方法论？
所谓“野路子”，即没有规范的工作方式，做事情没有依据，想到哪做哪，做到哪算哪，经常会陷入自己不知道干嘛的境地，这样的工作状态会极大的降低工作效率，长期以往甚至会影响自己的工作情绪。
如何改善“野路子”，即流程化、标准化做事，最佳的方法就是定义Standard Operating Procedure(标准作业程序），以下简称SOP，让自己在遇到问题时有所依据。
下面我将结合个人经验，详细阐述产品工作中如何通过定义SOP，改善野路子，形成自己的产品方法论。
一、定义与同事配合的工作流程
1. 了解互联网公司需求迭代的流程
如图：
2. 明确自己需要做以上流程中的哪些事
根据自己公司的情况细化，明确自己需要做以上流程中的哪些事，比如我司就需要产品做需求调研、产品设计、产品方案宣讲、研发过程跟进、收集反馈这几类事情。
3. 确定以上的事情需要哪些人（WHO）对接，以及如何(HOW)和他们对接
（1）需求调研
需求调研根据需求来源一般分为两种：
一种是内部需求，一种是外部需求。内部需求对接人包括BOSS、研发、测试、运营、市场，这些需求调研的工作和他们约好时间，反复沟通直到双方都没有异议就可以了；
外部需求一般对接人是客户，要复杂一点，懂得随机应变，不要当场答应实现需求，只要做好访谈记录，回来可以和决策人（一般小公司是boss，有些是产品总监或者技术总监）讲清楚大概需求，至于要不要做，怎么做，什么时间做（需求优先级的问题），这些问题留给决策人。
（2）产品设计
产品设计一般情况下是初级产品经理最重要的工作，设计过程中的对接人主要是需求方，有时也要需要技术参与讨论方案可行性，最重要的是和需求方反复确认以保证最终的方案过关，这一点会在定义自己工作的SOP中详细讨论。
（3）产品方案宣讲（评审会）
产品方案宣讲，一般对接人包括UI/研发/测试，有时需求方也会参与。这时候要提前预约时间，准备好产品方案的产出物，比如流程图、功能架构图、原型图、PRD文档，如果涉及项目管理，要在禅道等团队协作的工具中建好需求号，便于开发人员领任务。
宣讲的顺序一般是先业务流程图，再功能架构，然后根据业务流讲一遍原型图，至于文档就不用讲了。记得讲完一定要同步，如果团队有同步的软件，比如svn,git，也可以用邮箱，我们公司用的git，然后在群里发一句，“**原型图V1.0.0,PRDV1.0.0已经更新至git，请有需要的小伙伴自取”。
【PS：请在每次需求变更后，及时更新为原型图和PRD文档，并同步给相关同事，必要时重新开会强调变更，这一点尤为重要】
（4）研发过程跟进
研发过程中可能会出现各种各样的情况，对接人一般是开发和测试。比如开发、测试不理解需求，你要解释；开发、测试发现需求有些情况没有考虑到或者有规则不清晰的，你要补充需求（这种情况虽不能完全避免，但越少越好）；甚至，前后端联调出现问题，需要你定义接口。总之，就是在开发过程中一切的问题你需要负责解释。
（5）收集反馈
收集反馈一般对接人是运营或者用户，这里主要是记录上线后出现的问题，为后续产品迭代提供依据。
以上的5点是仅为个人总结的内容，不同公司的情况可能略有不同。
二、定义自己的工作流程
最重要的就是产品设计SOP的定义，这个过程需要自己反复思考总结，每一阶段都有相应的输出物，并且在平常工作中不断实践才有效果，以我总结的产品设计SOP为例：
需求调研→业务模型搭建→流程图→产品功能架构→原型图→PRD文档
1. 需求调研
这一步需要尽可能多的收集需求的信息点，包括需求的目的，参与的角色，上线时间，很多细节的想法等等。如果只是需求方只是一个人，那么他会提关于很多需求的描述，尽可能记下来；如果是头脑风暴式的需求，那么有不同的人提出不同的需求描述。
以PCG(Professionally-generated Content)的课程APP为例，A可能说课程要能定义属性（视频/文档），包括价格，名称等，B可能说课程要能下架，下架后前台就看不到了，C说用户要能够选课程，购买课程，D说要有购物车，只要是会上没有发现有明显问题的信息，统统记下来；我一般用onenote分点记，很多人喜欢用思维导图。
示例：
推荐工具：onenote
2. 业务模型搭建
根据需求调研记录的信息点搭建业务模型，最重要的是梳理主流程，听起来好像很难，但实际操作比较简单，在草稿本上列两点：参与角色、每个角色涉及的操作。
同样以上述课程APP为例，涉及到的角色：包括平台运营人员、用户，涉及到的操作：平台运营人员上架课程，用户选择并购买商品；注意，这里涉及的操作不是要列系统中详细的操作，而是业务过程中完整的闭环操作（包括线上、线下）。PCG的内容是自己生产的，所以线下还包括制作流程，那么完整的业务模型应该是：
运营人员制作课程→运营人员上架课程→用户选择并购买商品
注意：业务模型的搭建一定要闭环，所谓的闭环就是实现最终的效果，比如C端的产品一定是要通过用户直接购买/广告/增值服务赚钱的，B端产品一定是要解决闭环解决问题的，一定要考虑系统层面做到哪一步，作为需求的边界。
我一般只会粗略的列，因为这个时候列得太细反而会干扰自己的思考。
推荐工具：草稿纸，笔
3. 流程图
一般画三种业务流程图，功能流程图，任务流程图。
业务流程图一般用泳道图（如有并行则用UML），主要是根据搭建的业务模型，在相应的泳道里按照顺序画出每个角色的操作。切记，不要想一步把所有流程画在一个业务流程图中，只需要把整个过程中最关键的一条/多条业务流画出来即可，否则适得其反。
示例：
功能流程图：主要是为了实现某种具体的功能，比如支付功能的验证流程，需要给出不同情况下的结果说明，包括支付成功的流程，支付失败的各种异常流程，开发很有可能拿着你的流程图去写逻辑判断的，测试可以直接拿着流程图写测试用例；
示例：
任务流程图：是为了实现某种任务的整个流程，只会在关键节点做判断，主要是为了让开发和测试知晓用户的核心使用路径。
示例：
推荐工具：ProcessOn
3. 产品功能架构
产品功能架构是就是用思维导图呈现，该产品需求包含哪些模块，这些模块包含哪些功能；
示例：
推荐工具：X-mind
4. 原型图
用界面化的方式展现元素，一般分角色，把对应的模块列在相应角色的文件夹下，先把框架搭起来，再从数据流的角度一个一个页面去画，我一般会把页面跳转和一些动态面板的交互画出来，比只画静态页面要直观很多。
过程中会有很多创意和想法，记录下来，画完自己按照流程跑一遍，看下有没有流程上的障碍，如果有的话，记录下优化的点，逐个优化。
原型图需要保留版本，每更新一个版本同步更新给团队成员。
示例：
推荐工具：axure
5. PRD文档
PRD文档每个人写法不同，不必按照别人的模板生搬硬套，现在很多团队敏捷开发直接在原型旁边标注，看起来很方便。我一般是在原型旁边注明重要的逻辑，另外再写一份Word文档。文档需要做一个目录，方便后期定位，还有每次更改的记录，最好在相应的位置标上最新更改的时间并显红，内容主要包括流程图、功能架构图、功能描述、原型图。
（1）流程图
把业务流程图贴在PRD文档的总述里，记得axure第一页也贴一份，功能流程图、任务流程图贴在相应的功能描述下。
（2）功能架构图
功能架构图在PRD文档综述里贴一份。
（3）功能描述
功能描述需要分角色、分模块，分页面，一般是一个页面一段描述，弹窗放在同一段描述，但也不绝对，也可以用功能点划分，比如列表、增、删、改、查，规则就是用MECE（互相独立，完全穷尽）的原则分清楚，具体描述主要包括三个方面：
- 数据的呈现，这个页面呈现的数据是哪里来的；
- 每个原型每个元素的描述，按照原型的页面，从左到右，从上到下撸一遍，每个UI/字段代表什么意义，有哪些规则，每个操作相应的页面变化是什么，数据变化是什么，想清楚，写出来；
- 描述异常情况，每种异常情况对应的页面是怎么样的，提示是什么。功能描述就是穷尽所有你能想到的注意点，如果你自己都觉得哪些规则好像不对劲，那一定是哪里没想清楚，一定要静下心来好好理理，否则开发和测试后面会找你的。
（4）原型图
在每段功能描述下贴上相应的原型图。
PRD需要记录版本，每一版本记录修改的地方、时间等，而且每次变更及时修改并同步给团队成员。
示例：
在小公司没人指导一定要勤于总结经验并运用在以后的工作中，不断调整，最终形成自己的方法论，这样一方面可以提高自己工作的效率，另一方面不论是转行或是跳槽都能很快的适应，为以后的工作打下坚实的基础。
以上。
本文作者 @娃哈哈 。
版权声明
本文来自互联网用户投稿，文章观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若转载，请注明出处。如若内容有涉嫌抄袭侵权/违法违规/事实不符，请点击 举报 进行投诉反馈！
