如果你是创业公司，或者没有项目经理岗位公司的产品汪，恭喜你，你要兼任项目经理了，但不会加钱。
整个项目流程按我的习惯分成三个部分
一、需求确定（搞清楚要做什么）
二、制定项目计划（准备怎么做）
三、项目推进（做）
可能会很长，看我耐心吧，如果写烦了，我就删减点。
一 需求确定
1、业务导向思考问题（将接到手的任务转变成需要解决的问题）：
一天，老板把你叫过去，意味深长的和你说，“小王啊，我们需要做一个后台运营管理系统？”那你就问了，“这个系统主要是给谁用呢？需要哪些功能呢？希望用什么样的数据平台？…………”回想一下，你是不是每次都是这么问的？从功能实现角度来说，你这么问是没有问题的，可是，你是产品经理啊，你要占在业务的角度去考虑问题啊。当老板跟你说做这个东西，一定要先站在业务角度问三个问题：
“为什么要做这个系统？“
”现在遇到了哪些业务问题？“
”现在主要想解决哪些业务问题？“
作为产品经理，当你想要实各种高大上有炫酷的功能时，一定要先搞明白为什么要做，而不是怎么做。
2、形成自己的解决方案（需求分析的可行性验证）：
老板亲切的叫你过去“小王啊，我们需要做一个后台运营管理系统，有了这个系统我们处理订单的速度能提升三倍，你可以这么做，1 找什么资料，2 找谁帮你做，3 按照什么做……“你在旁边认认真真的记录了三页纸，然后呢，回去就按照老板说的，查资料，出方案……等等，你想没想过，老板说的就是靠谱的吗？
需求分析中重要的一个环节，就是可行性验证，千万不能落下。
你拿到老板这个需求，应该去找相关部门认真沟通，老板希望做什么？目的是什么？他希望怎么做？希望你们部门做到什么？……（一定要了解清楚，毕竟后期执行阶段的时候再被反馈说这个做不了你就傻逼了）。
然后你就会得到每个部门各种不同的信息反馈，比如哪些可以做，哪些不能做，为什么不能做，以及如果做的化能做到什么程度。等你搜集到所有反馈信息后，你就是对这个问题最了解的人了，根据这些信息，出一套可行的解决方案，拿着去找老板沟通，明确老板想要的，你搜集到的，你的解决方案。这个时候，也许你的方案老板认同，那就按你的方案做吧，如果老板觉得这个项目非常重要，一定要按他说的做，那他也会给你分配更多的资源。
当然，许多时候，老板给你的指令只是一个大概的方向，没有具体的行动步骤。接到这样的任务其实行动步骤也是一样的。
作为产品经理，所有的方向步骤一定要转换成自己的解决方案。这样你才不会傻逼到被人问你为什么这么做，你只能说，老板让这么做的？（那要你干啥）
3、解决方案一定要和每个业务相关人确认：
有没有经历过产品立项会上被各项目负责人虐成狗~有没有想过为什么？
你确定的项目方案有没有征求过业务相关人员的建议，有没有和他们沟通过这些功能是不是都能实现。产品经理不是经理，没有权利指派某个部门或者某个人必须完成什么工作。当你出第一版解决方案的时候，就应该开始和所有需要参与的人去讨论方案的反馈了，当然，运营人员一般给的反馈都是很大的方向，如果听他们的那你做的就是另外一个项目了，这就考验你的沟通掌控能力了。开发人员一般都不给你反馈，只是安静的听着，偶尔给个反应，但是不要觉得这样就不需要和开发人员沟通了，虽然人家不说话，不代表人家没有听啊，而且从头到尾的参与到一个产品中，会让开发人员意识到他在给自己做这个产品，省的你后期改需求的时候被人家虐死（开发爸爸，就改一下，最后一下）。
当然这个阶段肯定会出现争吵，扯皮之类的情况，没关系，只要是针对问题，争吵，扯皮也是解决问题的一种形式，早吵早解决。所以不要怕争吵。最后双方妥协，达成一致才是你想要的结果嘛。
最后，在立项会前，搜集到所有人的反馈，说服每一个人接收你的方案，你才会有一个不被虐成狗的立项会。
立项会不是你推销方案的时候，立项会前才是。
二 如何制定一个靠谱的项目计划
是不是经常出现项目进行中突然出现了一个严重的技术问题，这时候你该怎么办？一般出现技术问题都是项目已经进入最后的研发实现阶段了。这个时候出现的技术问题，你提出的所有解决办法都不会是好的办法。没有人能在这个时候提出好的解决方法。那如果这个问题出现在项目开始时，制定计划时。那你可以非常轻松的说”那我们讨论换一个技术方案吧“
可见，制定一个靠谱的项目计划有多么重要。
1 里程碑节点比验收节点更重要
在实际工作中有没有这样的苦恼，明明和程序猿说好了，这周四开发完某项功能，可是直到周四我问他才跟我说没做完，还需要两天时间才能做完。你怎么办？又不能骂人家，也不能打人家。那怎么解决这个问题呢？有没有试着为项目制定里程碑节点。
也许一个功能开发需要两周时间，在这两周时间里，可能发生很多意外情况，比如有一个美女产品汪比你有魅力，拉程序猿帮她做了两天功能，比你高一级的大产品汪中间插了一天他的工作。如果为这两周的项目推进制定里程碑节点呢？比如说两天完成A功能的开发，三天完成B功能的开发，四天完成C功能的开发，一天完成整体功能的调试。这样，每个节点时间你都验收一遍。将最后的交付压力分散到开发的进程中。如果某个里程碑节点出现问题，一定要及时沟通总结，为什么会出现这样的情况，该怎么补救。这样，你就能及时发现和解决项目中出现的问题，哪怕最后项目被迫延期你也能够从容面对了。（不要指望项目能够完全按照你的计划进行，那比天上掉馅饼的概率都低）
另外，制定项目节点一定要足够现实，比如，你问开发部的同事，这个功能需要多少工期，开发部们的同事告诉你“理想情况下，需要五个人做十天……”听到这句话，你应该想到什么？
五个人是什么水平的 五个人？
能给我这个项目分配五个这样的人吗？
在这期间他们有没有其他的工作安排？
……
反正就是，永远都没有理想情况。连正常情况都没有，所以当你做计划时，如果脑子里出现了理想、正常情况这样的词，赶紧抽自己两嘴巴。想想会出现哪些问题。
2 资源是要去争取的
有没有出现过这样的情况，你准备下一周三做一个B功能的修改，需要开发部门提供支持，然后你去找他们负责人，说”大哥，你们下周三有时间没？“人家说”放心吧，到时给你安排人“结果到了下周三，公司另一个项目出了问题，项目负责人和你说，最近都没有时间满足你的需要了。
你觉得这是什么问题呢？项目间资源冲突？公司资源不充足？没有一个公司的资源时充足的，项目间的资源冲突几乎时不可避免的，不要想着去解决这两个问题了。那怎么办呢？只有想办法让资源向自己这边倾斜了。
比如研发负责人和你说“放心吧，到时给你安排人”你就应该直接问“安排谁？”这样问题就落实到了责任人。在开始做的这段时间，时不时的去和人家打个招呼，问问人家最近工作情况，比如“公司另一个项目出了问题，你觉得下周三还有有时间做B功能的修改吗？”这样就能尽早发现突发状况，尽早想出应对的方案了。
作为兼任项目的产品经理，一定要会“抢”资源。没有什么是绝对不可能的，也没有什么是一定“应该”的，最重要的是你的努力。
3 风险控制一定要落在计划中
其实这块要写的内容非常少，但是感觉这里非常重要，所以还是单独列出来写了。
我们需要承认，每一个方案，计划，都不可能是完美的，都存在各种各样的风险，作为产品的负责人，你要尽可能多的去想出，可能会存在哪些风险，如果出现了应该怎样应对，这个风险必须和项目推进表一样，做一个风险列表。每次例会（如果有的话）都要过一遍这些风险。都要检查预防的措施有没有实施到位。
没有一个项目是能够完全按照计划表完成和交付的。作为项目的推进者的职责，就是尽可能早的去发现和解决可能出现的问题。