方向在前，流程靠后

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

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

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

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

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

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