技术头条 - 一个快速在微博传播文章的方式     搜索本站
您现在的位置首页 --> 设计思想 --> PM与工程师

PM与工程师

浏览:2872次  出处信息
    过节前看到一篇文章,讲产品项目就应该由工程师来主导,但国内让PM去驱动项目,搞得乱七八糟,很恼火,怎么可能做出一款好产品来呢?

    很显然,写这篇文章的是一位愤怒的工程师,Angry Engineer!我跟他至少有两点共鸣:

    1、国内的PM确实常常折腾工程师,甚至不乏“把工程师当工具对待”的情况。

    2、如果工程师有开阔的产品视野与全面的设计素养,知行合一,由工程师来驱动项目是一个完美的选择。

    可惜由于教育环境的问题,国内通才太少。一个优秀的工程师,同时又是一个优秀的PM,凤毛麟角,只能人任其长,各自做自己拿手的活儿。这时候更擅长需求分析与产品设计的PM来驱动项目,也是不得已的选择。

    说来惭愧。需求不靠谱,或是来来回回修改,折腾工程师的事儿我也做过不少,直到最近一年多才算是大有好转。我应该忏悔……虽然能做好PM的工程师极少,靠谱的PM其实也不算多,最后大家都得写周报对不对?

    在产品行业远远不够成熟的现阶段,痛苦的来回折腾难以避免。但最起码,PM应该把工程师作为伙伴而不是工具,想法设法地站到一条战壕里去,争取他们的理解。因此抛开难以鉴定的需求的对错,仅仅从协作流程的改进上,我积累了以下的经验。

    首先要得到工程师对整个项目的认同。每个月都有一场一小时的部门月会,对着PPT,我来讲下个月乃至下个阶段,我们的任务规划是什么,目标设置又是什么,详细解释制定规划与目标的原因,近景与远景分析,为咩做这件事情为咩这样去设计等等。希望工程师能认可他即将做的事情是有价值的,值得为之而努力的。为接下来PM与工程师的沟通做好铺垫。

    月会上还有一个环节,详细分析本月发生的所有数据,尤其是最近发布的新功能的数据。这个环节也是为工程师准备的,使他们了解自己的工作能产生多少实际效果。

    至于月会上送出的新功能礼品(以前讲过许多次),最开始是为工程师专设的彩蛋,再后来才将PM与运营包括了进来。我得承认自己对工程师偏心眼,因为有信心能激励PM与运营,却出于沟通深度不足,需要借助更多的手段来激励工程师投入项目。

    项目任务分两种,大版本与小模块。对于大版本,在基本框架定下来之后,PM提前向工程师讲解,听取技术视角对设计方向的建议。整个设计过程中还会反复讨论三五次,为技术上的合理性征求意见。小模块则在策划案基本敲定之后,与工程师共同确认一次,视觉稿出来后再通报一次。(所以PM与工程师坐得近是很有必要的)

    我曾经在部门月会上公开承诺说,任何一个需求,只要工程师认为是不合理的,都可以停下来不做。直到PM能说服工程师为止。如果死活谈不下来,才由我和技术经理出面来协调。强硬要求服从的情况在我这里基本上没有,被工程师说服倒是时有发生,按工程师提出的意见来改方案。我也常常跟PM讲,小分歧你们都听工程师的,没有必要坚持己见。你让他爽一点,开发速度就快一点,大家都获益。再说你多听听技术伙伴的意见有什么不好呢?帮助你转换思考的角度,共同找到提高开发效率的方法。

    最后方案定下来了,PM说OK,工程师也觉得方向大致没错,细节基本合理;进度方面则由工程师进行评估。PM觉得时间太长接受不了,再找到我和技术经理一起商量,看是分阶段砍需求呢,还是加把力加点班。除了极少数紧急修复任务外,不会由PM单方面确定开发时间安排。包括一系列任务的优先级安排,也由PM先提草案,工程师根据开发情况来调整顺序,再共同确认。

    在PM提出需求的整个流程里,始终在进行不断的协商,保证工程师对任务是理解并且接受的,不会出现抗拒,或者是麻木的心态。如果遇到突发性的需求变更,更加会向工程师反复解释,请求谅解,因为浪费了他们的工作成果而心存歉意。为此而花费的时间对比更高的开发效率,稳赚不赔。虽说具体协作时还有一些不到位的地方,但态度总归是好的,基本的效果也是有的。

    当然,这套流程的实施得具备两个前提。第一是有稳定的团队,如果变成提单协作,这个月一起干下个月分道扬镳,那就不可能实现共同的项目归属感。第二是工程师的个人素质基本靠谱,沟通顺畅;尤其是技术经理可以服众,协调好分歧而不护短。比如说一个功能能不能做,至少开发多久,我和PM都搞不掂,主要靠技术经理来做最终判断;如果出现开发过程中的失误,或是不按照约定好的方案进行开发,则由技术经理进行处罚。我对开发组更多作行政管理,全靠这位技术核心伙伴来负责业务管理,他也会更深入地参与到产品的结构设计,任务规划里来。

    这样做,也就撇开了把工程师当工具对待的嫌疑。我觉得把任何同事当工具都挺可耻。怎样才算是伙伴呢?比如交流必要的信息,理解对方;比如能站在对方立场去换位思考;比如多一点点鼓励与帮助。

    换个角度看,我这边曾经出现过由工程师来提出大致构思,PM认可并负责细节设计,再由这位工程师来实现的情况。结果皆大欢喜。我后来多次在月会或别的场合征求工程师的创意,换一换视角,引入新鲜的想法与灵感。即便想法不一致,也会非常温和地解释反对原因,绝不可能一口否决。唯恐工程师们默不出声闷头干活――听不到技术伙伴的意见是多大的损失啊。

    今上有敕云:“科学发展观的核心是和谐发展。”

建议继续学习:

  1. 开发与研发    (阅读:10631)
  2. 一个大二学生有关如何成为一名软件工程师的疑问及答复    (阅读:8244)
  3. 程序员和工程师有什么不一样?    (阅读:6543)
  4. facebook 的工程师文化    (阅读:6227)
  5. 2015中国程序员生存报告,请勿对号入座    (阅读:5032)
  6. 一个程序员的血泪史    (阅读:4907)
  7. 浅谈技术工程师的进步    (阅读:2594)
  8. 再说搜狐的 PM    (阅读:2467)
  9. 事关“工程师思维”    (阅读:2427)
  10. PM与工程师・续    (阅读:2414)
QQ技术交流群:445447336,欢迎加入!
扫一扫订阅我的微信号:IT技术博客大学习
后一篇:PM与工程师・续 >>
© 2009 - 2024 by blogread.cn 微博:@IT技术博客大学习

京ICP备15002552号-1