在跨多团队协作时,项目管理能力更显重要,否则一地的鸡毛和相互扯皮让团队成员相互推诿和彼此抱怨。那么,我们又该如何做好一个项目管理呢?
当我们准备做一个项目时,经历了和业务方多番沟通,进行需求调研;冥思苦想,反复斟酌产品方案;和交互视觉沟通,给产品披上漂亮的外衣;最后再到和开发“撕逼”,拿到“被砍”之后的“受了伤”的功能。
你以为可以松口气了,其实这时候产品只是一个胚胎。如果做不好项目管理,极大可能会胎死腹中。项目管理,在产品日常工作中,也占了很大一部分分量。产品能力,往往通过项目管理外在显现。项目管理不够,项目团队很大概率会遇到一系列问题:
开发成本高于预期,产品不能如期交付;
项目成员对产品目标不明确,开发过程中插入其他优先级更低的需求;
项目成员对自己的任务最终交付水平和交付时间不明确,你以为他知道在什么时间节点交付什么交付物,等到那一天去问他,他是蒙的;
……
所有这些问题表面看各不相干,本质上是由于项目管理过程中的目标和风险管理不当所致。 在跨多团队协作时,项目管理能力更显重要,否则一地的鸡毛和相互扯皮让团队成员相互推诿和彼此抱怨。
那么,我们又该如何做好一个项目管理呢?
一、目标拆解
项目负责人根据项目总目标层层拆解到各个小团队,再从团队分解到个人,每个人都要给出明确的交付物和交付时间节点, 这份文档被称作WBS。
WBS(Work Breakdown Structure) ,工作分解结构。跟因数分解是一个原理,就是把一个项目,按一定的原则分解,项目分解成任务,任务再分解成一项项工作,再把一项项工作分配到每个人的日常活动中,直到分解不下去为止。
即:项目>任务>工作>日常活动。
任务必须被100%分解,颗粒度拆的越细,抗风险能力越高。分配到每个人身上的任务,每个人自己也要把任务再分解。 有时候,项目时间很赶,我们拿到任务后想尽快开工,自以为对自己负责的模块很了解,其实有些模块之间存在潜在的逻辑依赖或者时间依赖。当做到这一块时才发现需要别人支持,此时已晚,只能等着别人弄好才能继续,这无疑给项目延期又“贡献”了一份力量。
所以看似项目中遇到的不可抗力因素导致项目延期,很大程度上是项目启动前目标拆解不够,每个人对自己在什么时间节点应该交付什么东西不清楚,大家处于“应该知道”的状态下或者彼此对交付物理解不一致。
以下为WBS示例,仅供参考,其中风险点模块在第三部分再讲。
二、统一团队目标
WBS文档制定好以后,为了让项目成员清楚地看到自己在项目中的位置以及对项目总目标的贡献,也为了让项目组成员了解到什么事是对项目最重要的事,进而对自己手上的工作做出更精准的优先级判断,应该组织大家召开一次会议确认WBS文档里的内容,统一团队目标。
每个人都要做到心中有数,明确自己要在哪个时间前完成哪些工作以及需要哪些外部协助,确保团队每个成员心中的产品愿景高度一致,能仅仅围绕产品目标作战。
以下内容摘自《腾讯产品法》,很好的诠释了统一团队目标的意义。
凡有项目开发经验的人都知道,项目过程总伴随着各种问题,完全不出问题、产品还大获成功的“完美项目”根本不存在。 更重要的是, 如果团队成员无法从宏观、整体的角度去思考自己所负责的模块,必将引发内部的设计冲突。 因为很多问题从单模块视角出发得出的结论与整体视角出发得出的完全相反。
围绕目标作战的项目成员不会像这样各自为战,相反的,他们就像一个命运共同体,“ 每个成员都有站在产品总负责人位置思考问题的习惯和行为表现 ”。
任务被团队分解,但目标依旧完整。 在这样的团队里没有“我的想法”,只有“更棒的想法”,没有立场,只有理性判断 。他们也会就某个问题展开激烈辩论,但那只是为追求“更好的方案”,而不是为捍卫自己的观点。
这样的团队里也没有“你的问题”,只有“项目共同的问题” ,成员间彼此认可和信赖。他们相信各自能做好分内的事情,但也会在某环节遭遇瓶颈时积极贡献自己的力量,一起想办法解决问题。当内部模块间发生冲突时,他们也能及时跳出自己的角色去讨论,运用相对思维更全面地审视问题。
三、跟进和同步项目进度
每天的站立式晨会和项目周报是一个很好的掌控整个进度的工具,保障项目信息透明顺畅。
老板最怕不知道底下员工每天在做什么,项目负责人也最怕不知道团队成员每天在做什么,项目进行到哪个程度了。每天的晨会可以很有效的及时暴露问题,遇到问题,可以有效请求团队成员帮助。一旦发生风险点,记录在WBS文档中的风险管理模块,由指定人跟进和定期询问。
一周结束后,让项目组各成员帮忙协助完成项目周报,同步给上级和各业务方负责人,建立有效的沟通汇报机制,提高项目的对外透明度。
为避免周报内容太多或者领导太忙没来得及查看周报,最好额外再单独联系下领导,简单说明项目当前进度。向上管理及其重要,可能你做了很多事,但是领导浑然不知,
注意项目周报并不是项目负责人一个人的事,项目周报通常包含:当前项目进度、本周完成工作、下周工作计划、当前风险点几个模块。项目负责人填写的项目进度、工作计划等或者开发测试同事填写的计划一定要是大家认可之后切实可行的,具体到日期的。
核心还是项目过程中产生的所有文档,不管是WBS也好,还是项目周报也好,都应得到项目组成员每个人的认可,项目的整个过程,大家都要目标一致。
经过一个项目的蹂躏之后,总结以上三点,仅个人工作经历总结,不一定适用于每个人,但也希望能够给大家一些参考,共勉。