PM与工程师·续_项目管理_非技术区_程序员俱乐部

中国优秀的程序员网站程序员频道CXYCLUB技术地图
热搜:
更多>>
 
您所在的位置: 程序员俱乐部 > 非技术区 > 项目管理 > PM与工程师·续

PM与工程师·续

 2022/9/15 14:41:39    程序员俱乐部  我要评论(0)
  • 摘要:不久前我写了篇日志《PM与工程师》,讲我的一点经验,PM如何与工程师协作。但是知易行难啊,最近我们的工程师也有点小抱怨,认为需求变动较多,太折腾了。我听到以后很警惕,查了一遍,发现变动的需求大部分还算合理。半年多来一直强调敏捷,敏捷,有什么想法就快速发布出来,再根据上线效果进行调整。因此“一步到位”的方案是不可能的,而快速调整是必须的。这时工程师就有意见了,觉得后续的修补太多,浪费时间,希望发布第一个版本的时候能够谨慎一些,周全一些。但这其实和&ldquo
  • 标签:

  不久前我写了篇日志《PM与工程师》,讲我的一点经验,PM如何与工程师协作。但是知易行难啊,最近我们的工程师也有点小抱怨,认为需求变动较多,太折腾了。我听到以后很警惕,查了一遍,发现变动的需求大部分还算合理。半年多来一直强调敏捷,敏捷,有什么想法就快速发布出来,再根据上线效果进行调整。因此“一步到位”的方案是不可能的,而快速调整是必须的。

  这时工程师就有意见了,觉得后续的修补太多,浪费时间,希望发布第一个版本的时候能够谨慎一些,周全一些。但这其实和“敏捷风格”是相悖的。

  我想了想,问题并不在于工程师不认可这个敏捷风格,而是不理解为什么要做这个,为什么要调整那个。我们的PM把设计案写得清晰完整,这是“提交任务”的环节,可是还漏了另一个环节,即“解释说服”的部分。

  去年看一篇介绍Facebook的文章,讲他们的PM权力很小,PM必须用自己的方案吸引住工程师,才能换得他们的投入,而工程师又必须去说动交互与视觉设计师,为这项开发提供支持。总之,如果不能说服配合你的人,在Facebook寸步难行。

  初看这篇文章时,觉得简直是PM的噩梦,后来细细一想,又大有道理。如果某个方案都不能说服自己的同伴,是否隐患多多呢?换个角度,即便方案最后被证实是错误的,当初支持过它的所有人都会共同承担责任——主要是精神上的自责,而不会互相埋怨造成内耗。

  只不过,Facebook这个管理文化还有两项大前提,轻易照搬不动。
  1、只聘请最优秀的工程师,有较高的产品素养
  2、每个员工都是自家产品的用户,感同身受,有不错的用研基础

  所以其他公司盲目学习Facebook这一套,必死无疑,但其中的道理是共通的。怎样让团队齐心协力呢?必要条件是对自己的任务有认同感。这个认同感不是靠升职加薪换来的,也不是靠请吃饭拉关系换来的,而是你必须说服他,做这个事情是有价值的,值得你花时间去弄。大到产品方向,小到交互优化,都不例外。

  每个月的月初,我会开一小时部门例会,滔滔不绝地讲近期的版本路线。每次花两三个小时来准备PPT。在我看来,在座的每一个人都是我的客户,我希望靠说服力(而不是权力)来打动他们,接受我的产品计划。在每周的策划运营例会上,在我跟策划组与运营组的单独沟通中,这种演说不断持续——虽然有点啰嗦,但可以保证沟通充分,不存在对任务的抵触情绪。

  PM与工程师的协作,也应该学习我这个态度。PM既不是请求工程师去做这个,更不是安排工程师去做那个,而是通过绘声绘色的说明,与工程师达成共识,我们下阶段就应该做这个做那个。

  因此,我在每周四下午安排了一场30-60分钟的会议,PM与工程师参加。PM这边有一份庞大的需求总表,大约涵盖了2-3个月的开发需求,随时增补修订。然后在会议上根据优先级,对工程师讲解与讨论接下来的开发计划,并确定下周的发布内容(紧急需求除外)。对这种讨论之前其实是有要求的,但如果不予以流程化,制度化,就容易荒废掉,口号永远只是一滩糖稀屎。“提单-接单”的传统协作形式必须被“讲解-倾听-讨论”所替代。

  上周我在新浪发了条微博,说产品协作的根本出路是让工程师加入设计讨论,共同确认方案,共同对结果负责。这条微博的回复很多。不少人提出,工程师哪里有这么多时间参与产品设计?又有人说,所有人都负责,相当于所有人不负责。这些都是误解。工程师只在几个关键节点(架构提出/方案确认/进度安排)参与进来,占用时间有限;而所谓“共同负责”,意思是当初你不出声反对,事后就得同甘共苦;当初你接受了这份开发计划,便不会指责PM拍脑袋瞎折腾。对产品负责到底的必然是PM,他同时还需要说服所有同伴接受自己的方案。

  在我这里,这个做法是可以被执行下去的。又有人留言说,第一,沟通能力足够强的PM比较少,没有能力说服别人;第二,对产品有感觉的工程师比较少,固执的工程师却很多。他说的也是常见情况。这属于团队建设的问题,团队经验与内部磨合都支撑不了协作上的民主,但换个角度来看,这样的团队是否也很难做好产品呢?与其独裁管理,不如多花心思在招聘与培训上。

  另外还有一种情况,在创业阶段,打算做点创新的事情。由于用户反馈很少,多半凭主观感觉去摸索,说服力有限,容易发生分歧。而创业最怕的就是内耗,一争执,一慢下来就完了。这时PM与工程师的合力很难形成,更不适合搞一言堂——摸索中的试错成本加重了内部矛盾。肿么办?所以牛逼的创业团队都是技术主导,带头大哥兼具工程师与PM的双重属性,自己想清楚了,挽起袖子就写代码,雌雄合体知行合一,非此不足以杀出血路。

  PM与工程师要相亲相爱。

  • 相关文章
发表评论
用户名: 匿名