产品问答 | 提岗管理后,如何进行团队管理及项目管理?

2 评论 11315 浏览 100 收藏 12 分钟

当你升到管理岗,项目管理和团队管理就成了你的“家常便饭”。关于项目管理与团队管理,你或许会有一些疑问:如何制定产品计划,才能合理有序地分配团队工作,高效地完成项目呢?怎么做项目管理才能使开发更敏捷呢?那么,以下就由笔者来为大家一一解答这些问题吧!

团队中的产品经理最近提了几个问题,趁此机会做一下分享。

这是产品问答的第三篇:探讨提升管理岗位后的团队管理、项目管理。

问:在团队管理时,如何制定产品策略及计划?以及,如果我把原型制作工作交给别人做,但出来的效果是我不满意的——他现在能力不够,做不出我想要的效果,要怎么处理?(如何分配工作)?项目管理有没有什么方法让开发更敏捷?

答:

随着产品逐渐成熟,产品团队也会慢慢成型。产品团队的存在,说明产品工作已经细化拆分。原来一、两个人干的事,现在可以由不同分工的人来处理了。

因此,产品团队的管理,得先从产品工作的拆分说起。

一般来说,产品工作的层面可以分为:产品战略、产品结构、产品框架、产品设计和产品辅助等。

产品战略工作

就是我们在第一篇问答(如何系统思考产品需求)中提高的产品战略工作。

梳理和确认好产品战略,让未来产品工作建立在相同认知基础上,是产品工作中最宏观且最有价值的工作。

产品结构工作

当我们确定了产品战略之后,从战略到具体的产品规划,需要进行信息的转化。

这种转化,就是将产品战略落地,转化为一条条产品线、一个个版本、一张张的功能清单,也就是产品的路线图(roadmap)。

有了清晰的路线图,接下来就可以进入正式的产品规划设计工作阶段了。

产品框架工作

有了实现的路径,就需要按照优先级,分产品线分版本的逐步设计。

这时,我们首先把眼光聚焦在版本内部,我们对所有需要实现的功能进行分析,让他们成为有机结合的整体,让功能组成一个个相关的模块。

同时,也把模块内及模块之间的各个功能,可能的实现流程明确出来。让需要实现的目标功能,变成清晰的多维结构。我们需要使用UML、业务流程图、数据流程图、业务拓扑图等讲这些结构表达出来。

同时,当版本内的设计接近完成时,我们要把眼光切换到多版本上——考虑未来版本和功能的实现,需要当前产品结果预先作出哪些调整和伏笔。这些都完成之后,我们就可以开始按照版本来细化和设计产品了。

产品设计工作

单个版本的产品结构设计完成,并经过各相关团队的评审和协调后,就要回归到产品部门内部进行设计了。

我们需要按照产品的版本结果,设计出前、中、后各端的模块、功能、流程、页面等,这里我们需要画原型、细化流程、设计页面、输出需求说明文档甚至高保真的交互稿。

设计好的产品结果,要宣讲并交付给开发团队,同时也会接受开发团队的各种挑战。

另外建议:在宣讲和交付产品结果的时候,最好能够把对象目标扩展到测试团队、运营团队、业务团队等各个相关业务团队,这样做的好处你试了就知道。

产品辅助工作

除了上述四个产品规划层面的工作外,其他的如:竞品调研、数据采集汇总、项目跟进、Bug处理跟进、产品相关宣传说明配合等工作,都是产品辅助类工作。

这几个层面的工作,并不是每个层面都需要不同的人来负责。本身是可以互相渗透,根据团队的具体情况来身兼多职

1-3 层面

一般由产品总监、产品团队负责人或高级产品来负责。做到承上启下,配合高层确定产品战略并消化和转化,指导具体的产品规划工作。

4-5 层面

一般由产品经理、产品线经理或产品专员等负责。做好基于产品路径的落地工作,保证产品设计的效率和质量。

拆分层面的意义在于:规范好的工作层面,可以让大家在工作时,明白各自的职责范围,更高效的互相承接和配合。

另外,你说团队成员的产品不符合你的要求,不知该如何处理。

我的建议是:就算从执行层岗位开始转变为管理岗位,也千万不要做甩手掌柜,很多执行方面的工作还是要有目的性的参与。

有目的的参与,可以体现在如下两个方面:

做为产品管理岗位,需要承担产品信息的向下传递——即承上启下的作用,你需要去处理产品战略、产品范围及产品框架等方面的设计工作。

同时,因为接下来要据此来进行具体的产品设计规划,最理解且最能依据产品框架来设计产品的人一定是你。你需要对各端的关键模块、关键页面进行设计,建立从上到下、完整一致的信息传递。

尤其是新产品或新产品线的初期版本或产品迭代中的重大版本,以你为中心和起点的产品设计,才是最高效、最能保证质量的。

有一个词叫“言传身教”,要团队产出符合标准的产品设计交付物,一定是以清晰合理的交付标准为前提的。

而对培训交付标准最好的方法,就是你要自己做出表率。通过对关键功能和页面的设计,以标准原型、标准文档的方式来建立基础,团队才能迅速熟悉和以交付标准为标的完成工作。

最后,关于项目管理方面。

项目管理

我不是一个在项目管理方面,过度刻意进行控制和要求的人。

开发项目管理有很多方法论——瀑布开发、敏捷开发、螺旋开发等。

方法选择的核心,应该交给开发团队,让他们选择最熟悉最方便的就可以。同时,也不是所有的项目都适合敏捷开发,不同阶段的产品非要去做敏捷开发也不一定合适,这里就不展开说了。

我想抛开项目管理的方法论,从个人认为的项目管理更核心的角度来讲讲。

项目管理,我认为有三个要素:任务、执行者和结果。

好的项目管理是处理好这三个要素之间的关系。简单说就是,合适的任务量,有执行者运用合适的节奏,来产出满足要求的结果。

任务量

合适的任务量,是决定项目成败的前提条件——在产品规划的交付物方面提高要求,不使交付物成为项目开发的障碍。

  • 不在一个版本内规划超过合理开发周期的任务量。
  • 不把没有思考清楚或不完整的功能放入产品规划中。
  • 做到“严于律己”,认真对待产品规划输出物,往往要比苛求开发团队实现不可能完成的任务更重要。

执行者

执行者就是项目的开发团队。

信任开发团队,比怀疑和苛求开发团队要来的划算,良好合作一定建立在互相信任的基础上。

相比去苛求开发团队完成不能完成的任务,不如反过来思考:如何根据需求的优先级来缩减任务量?

给予项目合理的任务时间,是保证项目质量的重要条件。

这里我更推荐“晨会+周期性项目演示”的方式:

  1. 每天早上在开工前,拿出15分钟左右,让开发团队对当前进度进行简短说明。同时可以提出:目前出现可能影响原定进度的问题,在晨会后安排专门的时间,来进行专项讨论或提供尽可能的协助。晨会可以天为标尺,发现目前实际进度与原定计划的差距,也可以让问题得到最及时的解决;
  2. 每1-2周,固定时间对项目目前的进度进行整体说明,并准备可演示物进行演示,判断当前项目的进度和阶段产物是否符合要求。

通过这样的方式,能够及早发现进度问题或影响进度的问题,从而提高对项目异常的反应速度。

结果项目最终的产出物,是验证项目成败的最终指标。仅仅在时间维度上去衡量项目成果,是没有任何意义的。没人愿意接受一个按时完成,但漏洞百出,无法提供使用的交付物。

所以,对结果交付物的验收,是项目管理的最终关卡。

要验证开发交付物,首先要做到,开发前提供的产品规划交付物是清晰明确的。

其次,还需要对交付物进行如下两个层面的检验:

  1. 功能层面:这部分工作可以交给专业的测试团队完成,但产品团队一定要在过程中积极参与及跟进;
  2. 实际使用层面:这部分则需要产品来独立完成。使用层面的检验——即产品团队模拟真实用户的各种使用场景,使用时的行为,输入信息要尽可能模拟真实情况。这种检验可以发现很多测试团队不容易发现,但被用户正式使用很快会遇到的问题。(这一点2B的业务类产品尤为重要)。

以上就是我对你提出的项目管理问题的解答。

 

作者:十八子杀,微信公众号:产品狗的思考(ID:PM-Doggy)。10年产品人,射手座,爱自由,喜摄影,好读书,涉猎广泛,望与同路人勉励前行。

本文由@十八子杀 原创发布于人人都是产品经理,未经许可,禁止转载。

题图来自@Unsplash, 基于CC0协议

更多精彩内容,请关注人人都是产品经理微信公众号或下载App
评论
评论请登录
  1. 莫非是SOUL的产品大佬

    来自广东 回复
  2. 赞👍

    回复