当你升到管理岗,项目管理和团队管理就成了你的“家常便饭”。关于项目管理与团队管理,你或许会有一些疑问:如何制定产品计划,才能合理有序地分配团队工作,高效地完成项目呢?怎么做项目管理才能使开发更敏捷呢?那么,以下就由笔者来为大家一一解答这些问题吧!团队中的产品经理最近提了几个问题,趁此机会做一下分享。 这是产品问答的第三篇:探讨提升管理岗位后的团队管理、项目管理。 问:在团队管理时,如何制定产品策略及计划?以及,如果我把原型制作工作交给别人做,但出来的效果是我不满意的——他现在能力不够,做不出我想要的效果,要怎么处理?(如何分配工作)?项目管理有没有什么方法让开发更敏捷? 答: 随着产品逐渐成熟,产品团队也会慢慢成型。产品团队的存在,说明产品工作已经细化拆分。原来一、两个人干的事,现在可以由不同分工的人来处理了。 因此,产品团队的管理,得先从产品工作的拆分说起。 一般来说,产品工作的层面可以分为:产品战略、产品结构、产品框架、产品设计和产品辅助等。
产品战略工作
就是我们在第一篇问答(如何系统思考产品需求)中提高的产品战略工作。 梳理和确认好产品战略,让未来产品工作建立在相同认知基础上,是产品工作中最宏观且最有价值的工作。产品结构工作
当我们确定了产品战略之后,从战略到具体的产品规划,需要进行信息的转化。 这种转化,就是将产品战略落地,转化为一条条产品线、一个个版本、一张张的功能清单,也就是产品的路线图(roadmap)。 有了清晰的路线图,接下来就可以进入正式的产品规划设计工作阶段了。产品框架工作
有了实现的路径,就需要按照优先级,分产品线分版本的逐步设计。 这时,我们首先把眼光聚焦在版本内部,我们对所有需要实现的功能进行分析,让他们成为有机结合的整体,让功能组成一个个相关的模块。 同时,也把模块内及模块之间的各个功能,可能的实现流程明确出来。让需要实现的目标功能,变成清晰的多维结构。我们需要使用UML、业务流程图、数据流程图、业务拓扑图等讲这些结构表达出来。 同时,当版本内的设计接近完成时,我们要把眼光切换到多版本上——考虑未来版本和功能的实现,需要当前产品结果预先作出哪些调整和伏笔。这些都完成之后,我们就可以开始按照版本来细化和设计产品了。产品设计工作
单个版本的产品结构设计完成,并经过各相关团队的评审和协调后,就要回归到产品部门内部进行设计了。 我们需要按照产品的版本结果,设计出前、中、后各端的模块、功能、流程、页面等,这里我们需要画原型、细化流程、设计页面、输出需求说明文档甚至高保真的交互稿。 设计好的产品结果,要宣讲并交付给开发团队,同时也会接受开发团队的各种挑战。 另外建议:在宣讲和交付产品结果的时候,最好能够把对象目标扩展到测试团队、运营团队、业务团队等各个相关业务团队,这样做的好处你试了就知道。产品辅助工作
除了上述四个产品规划层面的工作外,其他的如:竞品调研、数据采集汇总、项目跟进、Bug处理跟进、产品相关宣传说明配合等工作,都是产品辅助类工作。 这几个层面的工作,并不是每个层面都需要不同的人来负责。本身是可以互相渗透,根据团队的具体情况来身兼多职。1-3 层面
一般由产品总监、产品团队负责人或高级产品来负责。做到承上启下,配合高层确定产品战略并消化和转化,指导具体的产品规划工作。4-5 层面
一般由产品经理、产品线经理或产品专员等负责。做好基于产品路径的落地工作,保证产品设计的效率和质量。 拆分层面的意义在于:规范好的工作层面,可以让大家在工作时,明白各自的职责范围,更高效的互相承接和配合。 另外,你说团队成员的产品不符合你的要求,不知该如何处理。 我的建议是:就算从执行层岗位开始转变为管理岗位,也千万不要做甩手掌柜,很多执行方面的工作还是要有目的性的参与。 有目的的参与,可以体现在如下两个方面: 做为产品管理岗位,需要承担产品信息的向下传递——即承上启下的作用,你需要去处理产品战略、产品范围及产品框架等方面的设计工作。 同时,因为接下来要据此来进行具体的产品设计规划,最理解且最能依据产品框架来设计产品的人一定是你。你需要对各端的关键模块、关键页面进行设计,建立从上到下、完整一致的信息传递。 尤其是新产品或新产品线的初期版本或产品迭代中的重大版本,以你为中心和起点的产品设计,才是最高效、最能保证质量的。 有一个词叫“言传身教”,要团队产出符合标准的产品设计交付物,一定是以清晰合理的交付标准为前提的。 而对培训交付标准最好的方法,就是你要自己做出表率。通过对关键功能和页面的设计,以标准原型、标准文档的方式来建立基础,团队才能迅速熟悉和以交付标准为标的完成工作。 最后,关于项目管理方面。项目管理
我不是一个在项目管理方面,过度刻意进行控制和要求的人。 开发项目管理有很多方法论——瀑布开发、敏捷开发、螺旋开发等。 方法选择的核心,应该交给开发团队,让他们选择最熟悉最方便的就可以。同时,也不是所有的项目都适合敏捷开发,不同阶段的产品非要去做敏捷开发也不一定合适,这里就不展开说了。 我想抛开项目管理的方法论,从个人认为的项目管理更核心的角度来讲讲。 项目管理,我认为有三个要素:任务、执行者和结果。 好的项目管理是处理好这三个要素之间的关系。简单说就是,合适的任务量,有执行者运用合适的节奏,来产出满足要求的结果。任务量
合适的任务量,是决定项目成败的前提条件——在产品规划的交付物方面提高要求,不使交付物成为项目开发的障碍。- 不在一个版本内规划超过合理开发周期的任务量。
- 不把没有思考清楚或不完整的功能放入产品规划中。
- 做到“严于律己”,认真对待产品规划输出物,往往要比苛求开发团队实现不可能完成的任务更重要。
执行者
执行者就是项目的开发团队。 信任开发团队,比怀疑和苛求开发团队要来的划算,良好合作一定建立在互相信任的基础上。 相比去苛求开发团队完成不能完成的任务,不如反过来思考:如何根据需求的优先级来缩减任务量? 给予项目合理的任务时间,是保证项目质量的重要条件。 这里我更推荐“晨会+周期性项目演示”的方式:- 每天早上在开工前,拿出15分钟左右,让开发团队对当前进度进行简短说明。同时可以提出:目前出现可能影响原定进度的问题,在晨会后安排专门的时间,来进行专项讨论或提供尽可能的协助。晨会可以天为标尺,发现目前实际进度与原定计划的差距,也可以让问题得到最及时的解决;
- 每1-2周,固定时间对项目目前的进度进行整体说明,并准备可演示物进行演示,判断当前项目的进度和阶段产物是否符合要求。
- 功能层面:这部分工作可以交给专业的测试团队完成,但产品团队一定要在过程中积极参与及跟进;
- 实际使用层面:这部分则需要产品来独立完成。使用层面的检验——即产品团队模拟真实用户的各种使用场景,使用时的行为,输入信息要尽可能模拟真实情况。这种检验可以发现很多测试团队不容易发现,但被用户正式使用很快会遇到的问题。(这一点2B的业务类产品尤为重要)。
爱盈利-运营小咖秀(www.aiyingli.com) 始终坚持研究分享移动互联网App运营推广经验、策略、全案、渠道等纯干货知识内容;是广大App运营从业者的知识启蒙、成长指导、进阶学习的集聚平台;
想了解更多移动互联网干货知识,请关注微信公众号运营小咖秀(ID: yunyingshow)
【转载说明】  若上述素材出现侵权,请及时联系我们删除及进行处理:8088013@qq.com