项目总是延迟交付?可能一开始你就做错了

许多互联网中小公司,团队里不一定配备项目经理,产品经理往往身兼项目经理的角色,对项目进度进行全程把控,直至项目及时交付......

许多互联网中小公司,团队里不一定配备项目经理,产品经理往往身兼项目经理的角色,对项目进度进行全程把控,直至项目及时交付。

在笔者刚负责项目那会,由于非项目管理专业出身,当时那个忐忑不安啊!许多事情都是凭着固有的思维与认知去行事和判断,加之缺乏经验,有时会主次不清或管控流程上有所纰漏,项目经常濒临无法准时交付的风险。

可见,在行业内,大部分产品经理都必须去学习掌握项目管理的知识,毕竟市场千变万化,一个好项目如果一而再,再而三的延期交付,那么多半产品出炉的质量不怎么样,即便可以,也可能因慢竞争对手一步,市场表现大打折扣。

本次系列篇主要分享一些项目管理的一些方法与经验,希望可以帮助小伙伴提前认识与避坑。

笔者是小菜鸟的时候(diss:如今也是个老点的菜鸟),听闻要兼管项目管理的活儿,即忐忑又兴奋,抱着“天降大任于斯人也,我必对得起老天”的心态匆匆忙忙地制定了详细、标准、帅气的甘特图,画完有种“老子真是天才,这计划真TM完美”的感慨。

结果,显而易见,那脸是啪啪作响。虽然敢做计划和提前做计划,但是忽视了做计划的核心理念—— “渐进明细”与“反复修正”。俗话说,计划永远赶不上变化,毫无弹性的计划一定会被现实击打得七零八碎,除非你是这类项目的老手高手。

立项之前,我们需要的是表示大概进度的时间表即可,最大的作用就是让团队与领导知道几个关键的时间点,如调研评估时间、项目启动日、第一个里程碑。

立项之后,这时各类资源基本就位,与研发经理、领导等对团队的生产力进行预估,进一步推导需求确认、设计确认、等中间的时间节点。

需求确认后,与负责设计、前端等各环节的成员共同讨论,详细估算具体的工作量,进一步明确设计确认、功能完成、测试完成、里程碑等时间点。

至于“反复修正”非频繁调整,调整计划应当有合理的数据和论据来支撑,时间宽松还好,时间紧张可能会让团队梁山起义。

我们要谨记,好的计划表都是大家共同商榷出来的,因为功能实现方案是他们执行的,他们更为清楚,此外,计划表代表着一种对项目的共识,有共识才好一起发力做事情。

在计划制定后,要谨记交付物的标准是什么?比如设计稿完成到什么程度,研发就可以准备产品代码;什么叫功能完成,可以允许多少需求比例没有完成;怎样算里程碑,产品质量达到什么水平,允许多少BUG什么类型BUG暂时存在等等。我们需定义好,避免后期有所争执,这些也是大家对项目理解达成共识的细节体现。

做计划的核心理念上便是“合理切割并分而治之”。在产品探索期,我们往往还在寻找合适产品方向,方向变动可能频繁,迭代的长度应当更多,俗话说的话,船小好掉头。

最后,计划一定要趁早,不要担心太早做计划会有太多不确定因素,正因为有不确定因素,所以我们当我们披露初期计划时,自然会有人跳脚指出不合理之处,这才是我们的目的,根据提供的信息进行合理调整,计划便会变得越来越充实和准确。

下回我们分享项目沟通的那些事儿,也推荐下相关书籍。

0条评论 添加新讨论

登录后参与讨论
Ctrl+Enter 发表