许多互联网中小公司，团队里不一定配备项目经理，产品经理往往身兼项目经理的角色，对项目进度进行全程把控，直至项目及时交付。
刚负责项目那会，由于非项目管理专业出身，当时那个忐忑不安啊！许多事情都是凭着固有的思维与认知去行事和判断，加之缺乏经验，有时会主次不清或管控流程上有所纰漏，项目经常濒临无法准时交付的风险。
可见，在行业内，大部分产品经理都必须去学习掌握项目管理的知识，毕竟市场千变万化，一个好项目如果一而再，再而三的延期交付，那么多半产品出炉的质量不怎么样，即便可以，也可能因慢竞争对手一步，市场表现大打折扣。
本次系列篇主要分享一些项目管理的一些方法与经验，希望可以帮助小伙伴提前认识与避坑。
笔者是小菜鸟的时候（diss：如今也是个老点的菜鸟），听闻要兼管项目管理的活儿，即忐忑又兴奋，抱着“天降大任于斯人也，我必对得起老天”的心态匆匆忙忙地制定了详细、标准、帅气的甘特图，画完有种“老子真是天才，这计划真TM完美”的感慨。
结果，显而易见，那脸是啪啪作响。虽然敢做计划和提前做计划，但是忽视了做计划的核心理念—— “渐进明细”与“反复修正”。俗话说，计划永远赶不上变化，毫无弹性的计划一定会被现实击打得七零八碎，除非你是这类项目的老手高手。
立项之前，我们需要的是表示大概进度的时间表即可，最大的作用就是让团队与领导知道几个关键的时间点，如调研评估时间、项目启动日、第一个里程碑。
立项之后，这时各类资源基本就位，与研发经理、领导等对团队的生产力进行预估，进一步推导需求确认、设计确认、等中间的时间节点。
需求确认后，与负责设计、前端等各环节的成员共同讨论，详细估算具体的工作量，进一步明确设计确认、功能完成、测试完成、里程碑等时间点。
至于“反复修正”非频繁调整，调整计划应当有合理的数据和论据来支撑，时间宽松还好，时间紧张可能会让团队梁山起义。
我们要谨记，好的计划表都是大家共同商榷出来的，因为功能实现方案是他们执行的，他们更为清楚，此外，计划表代表着一种对项目的共识，有共识才好一起发力做事情。
在计划制定后，要谨记交付物的标准是什么？比如设计稿完成到什么程度，研发就可以准备产品代码；什么叫功能完成，可以允许多少需求比例没有完成；怎样算里程碑，产品质量达到什么水平，允许多少BUG什么类型BUG暂时存在等等。我们需定义好，避免后期有所争执，这些也是大家对项目理解达成共识的细节体现。
做计划的核心理念上便是“合理切割并分而治之”。在产品探索期，我们往往还在寻找合适产品方向，方向变动可能频繁，迭代的长度应当更短，俗话说的话，船小好掉头。
最后，计划一定要趁早，不要担心太早做计划会有太多不确定因素，正因为有不确定因素，所以我们当我们披露初期计划时，自然会有人跳脚指出不合理之处，这才是我们的目的，根据提供的信息进行合理调整，计划便会变得越来越充实和准确。
下回我们分享项目沟通的那些事儿，也推荐下相关书籍。
