在小公司的PM由于公司规模或者其他原因。公司并没有一个规范化的流程来帮助工作中使用正确的方法完成任务，给人的感觉就是路子野，在这种情况下的PM有什么有效的方法来加强自己的方法论体系或者提高专业能力呢？
以下是自己总结的几点小建议：
公司没有规范的流程就自己定义工作流程
基本流程包括以下两个部分：
一）与同事配合的工作流程
①了解互联网公司需求迭代流程，如图：
②根据自己公司的情况细化，明确自己自己需要做以上流程中的哪些事，比如我们公司就需要做需求调研、产品设计、产品方案宣讲、研发过程跟进、上线后收集反馈这几类事情；
③确定以上的事情需要哪些人对接，以及如何和他们对接：
1.需求调研
需求调研根据需求来源一般分为两种，一种是内部需求，一种是外部需求。内部对接人包括BOSS、研发、测试、运营、市场、自己，这些需求调研的工作和他们约好时间，反复沟通直到双方都没有异议就可以了；外部需求一般对接人是客户，要复杂一点，产品助理的阶段一般只要做好访谈记录，回来可以和决策人（一般小公司是boss，有些是产品总监或者技术总监）讲清楚大概需求，至于要不要做，怎么做，什么时间做，这些问题留给决策人。
2.产品设计
产品设计一般情况下是初级产品经理最重要的工作，对接人主要是需求方，需要和需求方反复确认以保证最终的方案能够满足需求。
3.产品方案宣讲（评审会）
产品方案宣讲，一般对接人包括UI/研发/测试，有时需求方也会参与，这时候要提前预约时间，准备好产品方案的产出物，比如流程图、功能架构图、原型图、PRD文档，如果涉及项目管理，要在禅道等团队协作的工具中建好需求号，便于开发人员领任务。
宣讲的顺序一般是先业务流程图，再功能架构，然后根据业务讲一遍原型图，至于文档就不用讲了。记得讲完一定要同步，如果团队有同步的软件，比如svn,git，也可以用邮箱，我们公司用的git，然后在群里发一句，“***原型图V1.0.0,PRDV1.0.0已经更新至git，请有需要的小伙伴自取”（PS：请在每次需求变更后，及时更新原型图和PRD文档，并同步给相关同事，必要时重新开会强调变更，这一点尤为重要，不要问我为什么）
4.研发过程跟进
研发过程中可能会出现各种各样的情况，对接人一般是开发和测试。比如开发、测试不理解需求，你要解释；开发、测试发现需求有些情况没有考虑到或者有规则不清晰的，你要补充需求（这种情况虽不能避免，但越少越好，否则你真的会被打死）；甚至，前后端联调出现问题，需要你定义接口。总之，就是在开发过程中一切的问题你需要负责解释。
5.上线后收集反馈
收集反馈一般对接人是运营或者用户，这里主要是记录上线后出现的问题。
以上的5点是仅为个人总结的内容，不同公司的情况可以略有不同。
二）定义自己的工作流程
这里我认为最重要的就是产品设计的过程，这个过程需要自己反复思考总结成标准作业程序（SOP），每一阶段都有相应的输出物，并且在平常工作中不断实践才有效果，目前我还在摸索中，以我现在总结的产品设计SOP为例：
需求调研→业务模型搭建→流程图→产品功能架构→原型图→PRD文档
①需求调研
这一步需要尽可能多的收集需求的信息点，如果只是需求方只是一个人，那么他会提关于很多需求的描述，尽可能记下来；如果是头脑风暴式的需求，那么有不同的人提出不同的需求描述以PCG(Professionally-generated Content)的课程APP为例，A可能说课程要能定义属性（视频/文档），包括价格，名称等，B可能说课程要能下架，下架后前台就看不到了，C说用户要能够选课程，购买课程，D说要有购物车，只要是会上没有发现有明显问题的信息，统统记下来；我一般用onenote分点记，很多人喜欢用思维导图。
推荐工具：onenote
②业务模型搭建
根据会上记录的信息点搭建业务模型，过程中你会发现有一些信息点之间是相矛盾的，这样的信息点统统都忽略或者修正。听起来好像很难，但实际操作比较简单，在草稿本上列两点：参与角色、每个角色涉及的操作。同样以上述课程APP为例，涉及到的角色：包括平台运营人员、用户，涉及到的操作：平台运营人员上架课程，用户选择购买商品；注意，这里涉及的操作不是要列系统中详细的操作，而是业务过程中完整的闭环操作（包括线上、线下）。PCG的内容是自己生产的，所以线下还包括制作流程，那么完整的业务模型应该是：
运营人员制作课程→运营人员上架课程→用户选择并购买商品
这时候我们的目的就达到了，公司赚到钱了。
我一般只会粗略的列，因为这个时候列得太细反而会干扰自己的思考。
推荐工具：草稿纸，笔
③流程图
一般画三种业务流程图，功能流程图，任务流程图。业务流程图一般用泳道图，这里不赘述，主要讲一下功能流程图与任务流程图的区别：功能流程图主要是为了实现某种具体的功能，比如登录功能的验证流程，包括不同情况下的结果说明（用户名为空是什么提示，验证码不对是什么结果）、正常登录的流程，开发很有可能拿着你的流程图去写逻辑判断的；任务流程图是为了实现某种任务的整个流程，只会在关键节点做判断，主要是为了让开发和测试知晓用户的核心使用路径。关于流程图，有兴趣去看下PMCAFF上的相关文章。
推荐工具：processon（在线工具）
④产品功能架构
产品功能架构是就是用思维导图呈现，该需求包含哪些功能模块，这些功能模块包含哪些功能；
推荐工具：x-mind
⑤原型图
用界面化的方式展现元素，一般分角色，把对应的模块列在相应角色的文件夹下，先把框架搭起来，再从数据流的角度一个一个页面去画，我一般会把页面跳转和一些动态面板的交互画出来，比只画静态页面要直观很多。过程中会有很多创意和想法，记录下来，画完自己按照流程跑一遍，看下有没有流程上的障碍，如果有的话，记录下优化的点，逐个优化。
推荐工具：axure
⑥PRD文档
PRD文档每个人写法不同，不必按照别人的模板生搬硬套，现在很多敏捷开发直接在原型旁边标注，看起来很方便。我一般是在原型旁边注明重要的逻辑，另外再写一份WORD文档。文档需要做一个目录，方便后期定位，还有每次更改的记录，最好在相应的位置标上最新更改的时间并显红，内容主要包括流程图、功能架构图、功能描述、原型图。
（1）流程图
把业务流程图贴在PRD文档里，记得axure第一页也贴一份，功能流程图、任务流程图在相应模块或者功能下。
（2）功能架构图
功能架构图我一般就只贴在PRD文档里，现在想想axure放一份也不错。
（3）功能描述
功能描述需要分角色、分模块，分页面，一般是一个页面一段描述，弹窗放在同一段描述，但也不绝对，也可以用功能点划分，比如列表、增、删、改、查，规则就是用MECE（互相独立，完全穷尽）的原则分清楚，具体描述主要包括三个方面：一是数据的呈现，这个页面呈现的数据是哪里来的；二是每个原型每个元素的描述，按照原型的页面，从左到右，从上到下撸一遍，每个UI/字段代表什么意义，有哪些规则，每个操作相应的页面变化是什么，数据变化是什么，想清楚，写出来；三是描述异常情况，每种异常情况对应的页面是怎么样的，提示是什么。功能描述就是穷尽所有你能想到的注意点，如果你自己都觉得哪些规则好像不对劲，那一定是哪里没想清楚，否则开发和测试后面会找你的。
（4）原型图
原型图在相应的功能描述下的贴图就可以了