工作5年、4年项目管理经验,谈谈我对项目管理目标的几点理解

15 评论 88061 浏览 214 收藏 13 分钟

项目管理是确保产品高质量上线的必要的手段,我们的最终目标是做出高质量的产品。

知止而后有定,定而后能静,静而后能安,安而后能虑,虑而后能得。这是《大学》中解决问题的思路。

意思是在我们想要做一件事情之前,先要搞清楚要达到的目标,这样才能心里有定数,心里有了定数就会比较平静,心里平静了才能够比较心安,心安之后才能充分的思考,然后就会得到解决问题的方案。

从事工作5年中,有4年时间在与项目管理的工作打交道。从做程序员时在研发团队中做项目协调、接口人开始,到后来做专职PMO项目经理,后转岗产品经理,项目管理始终是我工作内容的一部分。我也有幸从产品研发的不同角度对IT项目管理有更为深刻的理解和认识。下面是我对于IT项目管理这一工作需要达到的目标的理解。

IT项目管理的最终目标:高质量、高产出

2017年1月份期间入职一个新的公司搭建公司的项目管理规范制度。公司属于零售行业的电子商务公司,规模1200+、研发中心约70人。公司刚引进新的项目管理工具Teambition,一个我之前没有用过的项目管理工具。相比之前项目管理的工作只包含事件、人员冲突协调,或者做专职项目经理的时候做协调的执行,这次真是要站在PMO经理的角度审视整个产品、测试、研发团队项目管理的问题。第一次面对这样的机会感觉还是比较焦虑的。

入职的第一个周末我在家摸清了Teambition这个项目管理工具所能提供的所有功能。但是最没考虑清楚的是这样一个问题:

IT的项目管理要达到一个什么样的目标?

只有彻底搞清楚这个问题,我们才能知道要做什么工作。我在本子上列出了产品研发各个环节项目管理的内容:

1. 项目管理要解决的问题:

  • 项目计划
  • 人事冲突
  • 项目协调
  • 风险管理
  • 跨团队协调

2. 作为产品经理负责产品线时,产品团队的项目管理内容:

  • 单产品线需求管理(需求池)
  • 单产品线版本规划
  • 多产品线管理

3. 研发团队项目管理的问题:

  • 项目研发工作排期及任务分配
  • 研发风险管理,主要包括下列风险:
  • 项目计划排期不当风险。
  • 棘手技术问题导致的延期风险
  • 跨团队协作时协作团队出现的延期风险引起的项目延期风险
  • 开发环境不稳定导致团队联调延期风险
  • 需求变更导致的项目计划变更风险
  • 线上紧急问题解决引起的当前研发产品的延期风险
  • 上线前上线工作准备不充分导致上线失败风险
  • 上线后线上测试不通过风险
  • 跨团队协调管理

4. 测试团队项目管理的问题:

项目测试工作排期,包括编写测试用例、及黑盒测试工作排期。

测试风险管理,主要包括:

  • 测试环境故障引起的测试工作阻塞风险
  • 需求变更导致的测试用例追加及测试工作变更风险
  • 研发提测产品质量低于预期,测试团队工作延期风险

然后,我发现项目管理在各个环节最关键的工作是计划和风险。一个计划是为了给一个有固定需求范围、人员的项目一个时间目标,很多的计划是为了保证在人力资源和时间范围有限的时候让产出的需求范围尽可能的大,也就是高产出。风险则是为了保证项目计划的目标能成功达到,同时又能保证产出项目的高质量。所以,IT项目管理的目标是高质量、高产出,至于更关注高产出还是高质量,在公司发展的不同阶段有着些许的优先级调整。

IT项目管理的制度目标:透明化

在得出项目管理的目标是:高质量、高产出。

后,还是不知道怎么落地。因为客观上来讲,这个目标是包含产品、研发、测试在内的整个团队的目标,特别是项目管理,在这里显得很无力,因为项目管理人员既不能帮产品梳理业务些PRD、也不能撸起袖子自己敲代码、也不能越俎代庖做测试,当然也没这个时间。那么项目管理人员能怎么去达到这个目标呢?或者能怎么发现当前团队的产出是否是高质量、高产出的呢?

似乎这个问题提到了点子上,接下来我需要搞清楚:

怎么发现当前团队的产出不是 高质量、高产出的呢?

于是我在本子上列出了IT产品研发所涉及的团队,和各个团队中会导致不能达到高质量、高产出的一些场景。

1. 产品经理

  • 研发当前迭代上线后,无后续产品规划。
  • 产品规划迭代内容长期处于优化、BUG修复等状态,对于业务的驱动没有更为强劲的驱动和支持。
  • 线上BUG不做梳理分级分类和汇总统计,线上产品长期处于低质量状态。
  • 版本规划不合理或需求梳理不明确,研发期间大量需求变更导致项目延期、长期不能上线或低质量上线。

2. 研发人员

  • 项目排期计划预估不当,研发人力资源发挥不充分(估长)或提测产品质量低于预期。
  • 项目研发期间遇到棘手技术问题和跨团队协作时间问题不能及时协调,最后产品上线延期或线上低质量。
  • 上线前后准备工作不充分,产品线上故障回撤,延期。

3. 测试人员

  • 测试计划排期不当,测试人员人力资源发挥不充分(估长)或产品匆忙上线,线上产品质量低下。
  • 测试时间不够充分,测试用例覆盖范围不够全面,线上产品质量低下。
  • 测试时间不够充分,回归测试的力度不够导致的线上产品质量低下等。

在梳理场景的过程当中我发现,提高IT产品研发产出和质量的过程其实就是为了避免这些场景的出现,或者说在这些场景出现后,项目经理能及时的发现并协调解决,避免影响恶化。

为了避免这些风险场景的出现,需要建立一系列明确公开透明的团队协作流程规范,来规范产品研发的过程。对于已出现的风险能否及时的发现,则取决于项目管理过程透明化的程度。透明化程度越高,产品规划、项目计划、人力资源安排、跨团队协作、延期等风险就能比较快速的展现到整个团队面前,项目经理就能尽早并且比较充分的时间来协调并将风险造成的影响控制到最小。

流程规范的透明化在于确保产品业务方需求接口人产品研发测试对流程规范有一致的理解,一套体系的流程规范的建立是为了确保各团队在工作过程中为高质量、高产出这样一个统一的目标服务。这样的流程需要各团队配合项目管理所做的工作要尽可能少,性价比要足够高。

Value1 = 各团队在项目管理中投入的时间资源价值。

Value2 = 流程规范推动产品研发产出和质量的提升的价值。

性价比= Value2 – Value1。

给予共赢的局面,参与项目的各个团队对流程规范有一致的理解并完全接受的。

项目管理过程的透明化

可以基于下面的模板来体现,一些常见的项目管理工具Scrum看板都可以做成包含下面属性的卡片,也能在计划时间的不同阶段有相应的提示预警,一个版本迭代的周期控制在1-2周左右,建议最长不要超过1个月。项目周期过长则建议调整产品规划方案。

【产品名称V1.0.0】当前迭代核心需求范围概述:

  1. 产品经理
  2. PRD开始时间
  3. PRD完成时间
  4. PRD评审时间
  5. UX设计人员
  6. UX设计完成时间
  7. 研发成员
  8. 研发完成时间
  9. 测试成员
  10. 测试完成时间

一个包含团队所有项目的Scrum看板,可以充分的展示团队处于各个阶段的项目,能反映出产品规划、研发测试进度健康状态,能反映出研发中心的现状和后续计划,能反映出人力资源的使用情况。从而能暴露出项目存在的问题和风险

IT项目管理的过程目标:及早暴露问题和风险

一个考过PMP或者一个对项目管理工作有所了解的人都知道项目管理需要做的工作内容。但是项目延期始终是各个领域司空见惯的现象。更多人对延期习以为常,或者觉得不延期不正常。因为项目管理的过程最难把控。

过程的把控是为了把过程中的问题和风险造成的影响通过及早协调解决的方式降到最低,而这及早协调解决的前提则是及早的暴露问题和风险。所以,项目管理过程中的目标是及早的暴露问题和风险

总结:

项目管理的目标在于高质量、高产出,项目管理过程的目标在于暴露问题和风险。从细节中暴露问题和风险需要流程规范和项目信息的透明化

基于以上的思考,我制定出了适合于被我总结为矩阵团队(多个产品线和多个研发团队交叉迭代)的项目流程规范。配合流程规范和团队协作情况,我制定出了三套基于Teambition这个项目管理工具的看板组织方式,和产品研发相关团队一一沟通选择最适合团队现状的看板组织方式(最后大家都选择了同一种看板,这个当然是我预期之中的)。将配合项目流程规范和看板组织方式的项目管理规范制度通过培训传达给所有的团队成员,1个月的时间,整个公司的项目管理就这样落实到位了。

项目管理是确保产品高质量上线的必要的手段,我们的最终目标是做出高质量的产品。

 

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

更多精彩内容,请关注人人都是产品经理微信公众号或下载App
评论
评论请登录
  1. 赞同您90以上的观点,但是作为一个开发人员,我建议您多和研发团队聊聊,高质量高产出,既需要能力,也需要薪水,还需要好的产品经理。任你规划再好,任务紧凑到认开发人员一刻不停歇,短时间尚可,时间久了,队伍就崩了

    回复
    1. 是的,您说的对,这是一个整体,一个环环相扣,相互影响的过程。

      来自上海 回复
  2. 很赞,学习了

    回复
  3. 那么对于IT项目,除了时间+质量,还有什么纬度可以作为衡量呢

    来自四川 回复
  4. 同意楼主文中的多数见解,但对于‘项目管理的目标是高质量、高产出’的观点有些不敢苟同。一般地说,所谓项目就是指在一定约束条件下,达成具有特定目标的一次性任务。这里的约束条件主要包括且不限于时间、资源和质量。依据个人8年多的项目和项目集管理工作经验,参照楼主总结方式,简单总结项目管理的目标是:按计划、可验收。即能够按计划完成的,且能够顺利被验收的项目,就是成功的项目,过度的追求进度和质量,只能造成项目成本的增加,在项目中管理粒度的粗细需要根据项目进展情况随时调整,有时也不能太理想化,毕竟项目追求的目标还是最终的利润。个人拙见,仅供参考。

    来自北京 回复
    1. 我觉得“按计划,可验收”很赞,只是更加偏向于是风险管理,过程管理。而IT这个高端人才领域中,项目管理更难的是人员的管理,这个领域1个人创造10个人的价值这种情况屡见不鲜,对宝一样的人才一定要特别对待。比如,在按计划进行的过程中,发现有个厉害的人工作很早的完成了,那么适当的调整当前的工作安排以及在后续的项目计划中适当的增加这个人的工作难度或量就是有必要的,这样优秀的人最终的绩效也会更好,对于个人和团队都是双赢的结果。我理解的“高质量,高产出”就是指,在人力和时间有限的情况下,尽可能合理的安排项目和计划,在产出质量有保证的前提下,让产出的量尽可能多。当然在激烈的竞争面前,相当于时间资源被压缩,这时候通过补充人力资源来完成结果目标是有必要的。对于范围一定,时间压缩的情况,扩展人力资源的时候,需要考虑任务能拆分并行研发的最小粒度,简单的总结就是“1个女人9个月生1个孩子;9个女人无法在1各月内生1个孩子,但可以生9个”。

      来自上海 回复
    2. “1个女人9个月生1个孩子;9个女人无法在1各月内生1个孩子,但可以生9个”改为“1个女人9个月生1个孩子;9个女人无法在1各月内生1个孩子,但可以在9个月内生9个”。抱歉装B过头了 ❗ 。这里的回复居然不能编辑也不能删除,这是“产品经理”社区?简直打脸

      来自上海 回复
  5. 感同身受。不过对一点提出疑虑,以高质量高产出的目标没毛病(当然是理想状况),作为PM更应该介入PRD梳理和确定,尤其是业务类需求具有不可推卸的责任。毕竟产品/项目首先是以产品/项目为基准,再是以人为本。

    回复
    1. 赞同,方向错了,走的越卖力只会偏的越远。

      来自上海 回复
  6. 楼主说的看板可以分享一下吗?

    来自广东 回复
    1. 看板确实是落地执行最后的成果,但是这个一方面依赖于所使用的项目管理工具会有所不同,另一方面针对产品、研发、测试团队的协作方式也会有所不同。我可以考虑后面在写一篇瀑布、敏捷、矩阵型协作团队中,产品、研发、测试人员Scrum看板组织方式相关的文章。感谢关注~

      来自上海 回复
  7. 很专业。我们公司目前是产品经理兼顾项目经理的职责,当然因为我们目前团队和项目都比较小,公司没有资源也暂时没有必要需要单独的一个项目经理的岗位。但在兼任项目管理的过程中,还是或多或少遇到了很多问题。能够系统性地看到文章里面列出来的各个点,非常有用。

    来自广东 回复
    1. 😉

      来自上海 回复
  8. 我想求作者联系方式,请教一些专业问题。有些冒昧,但很认真的提出了这个请求,邮箱都ok~拜托

    来自四川 回复
    1. 欢迎勾搭,微信:angelg0426。哈哈。

      回复