实战第五步:项目管理的白与黑

1 评论 6335 浏览 22 收藏 11 分钟

前面几篇文章讲了从市场需求到功能的过程和如何把功能落地,本篇文章主要讲项目管理中一些需要注意的细节,与大家分享。

消失了1年,文章很有没有更新,很多读者和好友期待我的后续文章,说实话很感动,写作的目的就是帮助产品新人,很多与我沟通的PM觉得文章很受用。所以我下定决心继续写下去。你们的热爱是我写作的动力。肉麻的话就说到这里,咋们继续续写前几篇干货文章后续。

其实本篇章本不应该写的,因为项目把控是PMO(项目经理)的事情,产品在输出相关交付物后,本应该就是在开发过程中解答技术的需求疑问和验收就行。

但是绝大部分中小型公司未设立项目经理岗位(估计觉得PM应该兼任),这个时候产品经理就需要充当PMO去把控项目的开发进度。

本次文章内容基本写的大白话(主要是语文差),希望能帮到各位。

一、什么是项目管理?

项目管理:项目的管理者,在有限的资源约束下,运用系统的观点、方法和理论,对项目涉及的全部工作进行有效地管理。即从项目的投资决策开始到项目结束的全过程进行计划、组织、指挥、协调、控制和评价,以实现项目的目标。(来源:百度百科)

读起来头头是道,用词专业、文字简练。但是理解起来很有困难。

我觉得可以用大白话这么翻译,各位看一下对不对:“和一群人在有限的时间和资源下,完成一件目标明确的事情。”

二、核心工具

项目计划表

合格且规范项目会拥有一张项目计划表(如上图),项目经理按照预期设定的时间推进项目成员完成每阶段事宜。

本文这次介绍其中一个阶段:如何在研发阶段把控进度。

那如何做到项目进度的清晰把控?知道项目在开发阶段会不会存在延期风险。有人会说,会不会延期 开发不是很清楚吗?

这个时候需要纠正一下,当一个项目团队几十上百人的时候,每个人的分工和所负责的模块不同。他们基本不清楚所负责的模块对其他关联模块的影响有大多,所以这个时候如何管理就变得很重要。

三、核心能力

1. 拆解项目节点

2. 把控核心:任务—人—时间

根据项目整体维度,拆分成更细的维度更好把控。

  1. 任务:按模块分类(一级、二级模块),层及分类(前端、后台);
  2. 人员:拆解任务具体谁负责完成,根据项目程度是否需要加上直属领导;
  3. 时间:计划开发完成时间、实际开发完成时间、 联调进度、 联调完成时间、移交测试时间。

把上面这些节点字段组合在一起,就是完整开发进度管控表。可以就长这样:

3. 系统拆分

这个是什么意思,上面不是已经说得按模块分类了吗?

此模块更可以理解为系统。主要是用于一些大系统升级改造,拆分成多个子项目,这个时候就需要按照每个子系统去列。

4. 组织进度会议

PM对这种会议都不陌生(谁还没开过会啊,没组织过,也参加过)。

这种会议的特点:又短又快:短(会议间用时短,5~20分钟)、快(会议频率快,部分项目/关键节点天天开)。

5. 干系人进度同步

定期通过邮件同步项目进展,内容包括:

  1. 当前项目进度;
  2. 当前阻塞(如有);
  3. 待支持(如有);
  4. 待领导决策(如有)。

说明:干系人指提需求人员或项目Leader

其他

读到这里,是不是感觉好像本篇的内容已经讲完了。是不是有一种错觉项目管理其实挺简单的,不好意思,项目管理真这么简单的话,那不是人人都已做PMO了(毕竟这岗位薪酬还不低)

其实在我们正常的工作中,上面的那部分所占用的时间可能只有20%,我们更多的时间在与项目干系人、技术同事撕逼或被他们打脸。

  • H5前端A:微笑,你这个地方设计的不合理啊,我觉得按照用户操作行为应该这么设计。
  • IOS前端B:微笑,你这逻辑是不是有问题,感觉怪怪的。
  • JAVA后台C:微笑,你这样设计,我后台又要增加临时表,这表关联的好乱,后期没办法维护。能不能调整一下方案。
  • 设计师D:……
  • 某干系领导:……
  • 某干系运营:……

这才是实际项目管理的真实情况。而且项目过程中出的不确定性因素太多,所以很难去统一化、规范化。(核心点是不变:人-事-时)

列了一些常见的点:

  1. 需求调整:细节微调、方案微调
  2. 需求变更:流程变更、功能变更
  3. 其他:方案大调整、合作方跑路,急需备用方案

上面这些在项目管理过程中基本占据我们60%以上的时间,在处理这些问题的方式或者方法上可能大家的存在很大的差异,或者有部分初级PM在遇到棘手的问题,甚至不知如何处理。

问题的本质最后也会回归到人上面,出现问题就去解决它,解决不了问题,就解决提出问题的人(开玩笑啦)。

处理项目过程中遇到问题的方法步骤:

  1. 分析问题的真伪性(假需求,该怎么办你懂得);
  2. 及时提出解决方案;
  3. 与干系人确定修改后方案的合理性与可行性;
  4. 同步项目成员及干系人、领导方案结果。

可能读完还是没有太大感触。举个简单的例子:

lowB微笑在设计登录机制时采用账号密码登录,开开心心码完需求文档:注册包含大小写字母-密码不少于8位;

到需求评审的时候,前端/后台技术就开始展示他们的专业性(批斗产品的机会来了):

  • H5技术:微笑,你这注册机制是不是太low了哦,现在都采用手机号+验证码登录,方便用户登录(顺带还会提一下用户体验);
  • java后台:你需要考虑一下用户体系,如果一开始不考虑这个,后面再去搭建用户体系,针对系统改造很大,你可以考虑一下使用手机号+UID,这样……(os:大牛,讲的真好)
  • ios前端:……

再经过一番被教育后,觉得技术同事给的意见很在理,那么我就只能去修改,按照手机号+验证码的机制去设计。

在我修改完后怎么办?直接发给技术?NO!NO!

记住:在项目过程中,一定要保持信息同步,同步给项目成员及干系人。

同步信息时一定要想清楚,那些人是必须要知道的,那些人是需要知悉。同步方式根据自己公司的实际情况去同步:邮件、项目群或者二者同时使用。

例如我刚刚的那个例子,我会这么写:

{日期}需求变更:

  1. 登录机制由账号密码变更为手机号+验证码,同时支持第三方登录(微信、QQ)……需求,文档已更新,位置(4.3.2)
  2. 效果图已同步更新……

望各位熟知。

@具体负责开发的技术人员。

上面只是一个很简单的例子,项目过程中,有很多比这个复杂、繁琐、难以抉择、突发是事情发生。我们需要抓住管理的本质(人-事-时)去进行灵活的变通,这样才能更好的掌握项目管理的技巧而熟练运用。

最后祝各位PM正在负责的项目顺利上线,没有重大BUG,数据biu biu biu的撑爆服务器。

#相关阅读#

实战第一步:市场调研

实战第二步:如何做一份有针对性的竞品分析

实战第三步:从需求池到确认需求的全过程

实战第四步:新项目之十大输出产物

 

本文由 @微丶笑 原创发布于人人都是产品经理。未经许可,禁止转载

题图来自Unsplash,基于CC0协议

更多精彩内容,请关注人人都是产品经理微信公众号或下载App
评论
评论请登录
  1. 私人微信: weixin-lianggao1993

    回复