把生命浪费在美好事物上

产品产品产品

358篇博客

方向在前,流程靠后

在项目里,我发现“流程”是个神奇的词。这个词,项目经理先说,很容易招致反感和抗拒,但由项目组其他成员提出来,却很容易得到响应和支持。因为在后面这种情境下,往往是团队中相当一部分成员已经看到了问题或有改进的需求,此时项目经理再顺势推动过程改进,就会顺利很多。但如果真的等到了问题爆发,项目的风险管理又一定是多多少少出了问题。


两全的办法是项目经理能够提早洞察风险,有明确的改进方向,并开始采取现阶段能降低风险的初步措施,保障项目的平稳运行,待到团队其他成员有刺痛感,表达出过程改进的期望时,再将流程明确、固化,彻底干掉这个风险。


我所在的项目,之前是典型的技术主导的后端服务型项目,技术leader即产品经理,基本不跟交互、视觉、运营等职能团队打交道,跟前端开发也是召之即来式的合作模式。现在进行产品化转型,原先的后端研发团队,突然要面对需求、策划、交互、视觉、前后端、运营等全链路产品团队,表现出各种不适应。而作为一个初出茅庐的项目经理,对全链路的研发过程,依样画瓢定一个流程我也是可以的,但看着我自己画出来的流程规范,我已经可以看到这里有很多与项目实际情况不相适应的地方,也可以预见到执行的难度,同时,我担心把这个宏图摊到团队面前时,他们会吓到。


于是我默默收起了流程图,只跟团队强调,现在是新的目标,有新的要求,我们都缺乏经验,只能紧密合作不断前进,并反复鼓励每个团队成员对合作模式、研发过程提出建议。同时,针对各环节的关键节点,我分别直接给出了实践建议,例如后端需求要跟交互同学一起确定、交互视觉方案要跟前端同学一起确认、各环节都要有估算和承诺、状态及时同步、全过程中的变动都要知会需求方和测试同学、研发后期的需求变更务必明确优先级等。在提出这些建议时,我几乎不使用任何专业术语,避免触动敏感神经,只强调做法和要达到的效果,但团队做着做着,就自然地形成了需求沟通会、交互评审会、功能排期、功能团队站会、变更通知和审核制度等,团队也很自然地使用着这些名词。而且随着实践的深入,团队的共识越来越多,这些流程被自觉地细致、丰富起来。这时候我开始将这些流程逐个固化,明确实施标准,并要求团队严格执行,团队没有任何人觉得突兀,并不感觉自己的固有习惯受到了挑战,都淡定地接受了这种流程设定。如此把几个关键流程明确下来后,我对于全链路的蓝图已经有了更多把握,最初被雪藏的流程图改了又改后终于展开在团队面前,细节更充实,要点更明确,即便实际上已经完全颠覆了产品化之前的项目流程,团队也顺理成章地接受了,因为在意识到这是流程要求之前,大部分环节的实践已经成了他们的行为日常。同时不难发现,由于团队受益于流程的感受先于对流程变化的本能抵触,以这种方式推进的流程会得到更多认同,也更容易被持续、规范地执行下去。


当然,这种过程改进模式的副作用也很明显,团队时常会有“现在流程好乱项目经理要管起来等诸如此类的吐槽,即便是出现这样的声音之后项目经理很快就做出响应,时间久了也会给团队“项目经理不给力,被团队推着走”的印象。这时就需要项目经理有强大的内心,只要是真正对项目、团队好的,不必为虚名所累。但也要注意到,这种印象会给项目经理以后的工作开展埋下隐患,所以还是应当有所应对。建议对于这个改进过程,事先、进行中、事后都能跟团队leader有充分沟通,他们通常清楚过程改进的必要性,重视成效,也会赞同尽量降低团队反弹的执行方式。同时,尽早给团队一个明确的改进方向,能够让他们感受到项目经理是有规划的;过程改进之后及时和团队总结,回顾整个过程,也能体现出项目经理有始有终的掌控感。


项目经理在过程改进中,保持思虑在项目之先,明确方向在前,笃定初衷不改是必须的。但在面对诸多不确定因素、受限于自身专业经验或团队阻力时,不妨实践先行,平滑、淡定地引入一些有益的新做法,把流程固化的步骤稍靠后放,给团队接受引导、自主成长的时间和空间。


网易云新用户大礼包:https://www.163yun.com/gift

本文来自网易实践者社区,经作者甘辰希授权发布。