数极客首页

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

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

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

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

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

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

答:

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

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

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

产品战略工作

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

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

产品结构工作

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

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

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

产品框架工作

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

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

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

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

产品设计工作

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

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

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

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

产品辅助工作

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

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

1-3 层面

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

4-5 层面

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

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

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

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

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

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

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

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

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

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

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

项目管理

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

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

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

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

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

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

任务量

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

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

执行者

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

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

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

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

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

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

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

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

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

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

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

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

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

 

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

本文由@十八子杀 原创发布,未经许可,禁止转载。

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

新一代大数据用户行为分析与数据智能平台:数极客(https://www.shujike.com),是支持无埋点、前端埋点、后端埋点、API导入四种混合数据采集方式,整合分析用户行为数据和业务数据,可以自动监测网站、APP、小程序等多种渠道推广效果分析,是增长黑客们必备的互联网数据分析软件。数极客支持实时多维分析、漏斗分析、留存分析、路径分析等十大数据分析方法以及APP数据分析网站统计网站分析小程序数据统计用户画像等应用场景,业内首创了六种提升转化率的数据分析模型,是数据分析软件领域首款应用定量分析与定性分析方法的数据分析产品

发表评论

评论已关闭。

相关文章