|
|
|
|
移动端

让开发人员直接对产品负责

《管理智慧:成功研发团队的18条管理启示》本书内容取自Lyft、腾讯、蚂蚁金服、用友、ThoughtWorks、平安科技、去哪儿网等17家国内外大型互联网企业的实践经历,分为工程文化、效率提升、团队组建、技术领导力4个板块,是覆盖技术型团队全生命周期管理的参考指南。 本节为大家介绍让开发人员直接对产品负责。

作者:麦思博(北京)软件技术有限公司来源:人民邮电出版社|2018-01-29 17:06

技术沙龙 | 邀您于8月25日与国美/AWS/转转三位专家共同探讨小程序电商实战

让开发人员直接对产品负责

首先来看关于“产品决定”(product decision)的谬误。上面提到了技术人员在得知企业版没能达到用户期望时的第一反应是“这是因为产品经理做的决定”。这就意味着技术人员把产品经理视为负责人,而他自己的工作只不过是把产品经理决定的功能实现。

恰好相反,团队需要一种文化:工程师对产品有强烈的主人翁意识,与此同时他们也应被赋予自主权去履行主人翁的职责。我们倡导工程师应对其开发软件的质量和用户接受度全权负责。如果产品的用户体验不好,无论代码多干净多漂亮,开发者依然需要为此承担责任。

当我们刚开始推行这样的理念时,组里的不少工程师都觉得不合理。他们的观点是:既然工程师不是做产品的,凭什么能在对产品的把控上做得比产品经理更好,为什么要扛起跟产品经理一样的责任呢?我们的解释是:其实没有人期待任何一个程序员或产品经理拍脑袋就能想出用户最需要、最喜欢的产品体验到底是什么,而是需要工程师们去尝试更新迭代,去不断摸索。

在寻找到符合用户需求的、能让用户喜欢用并一直用的产品之前,无论是产品还是研发,所有人都不能认为已经完成自己的工作了。作为技术人员,也需要为产品出谋划策,而不是在程序写完、编译完、测试完就撒手不管了,大家都在一条船上,每个人都应该把自己当作主人。

在很多公司,每当大大小小的产品发布的日子,哪怕是一个很小规模的新功能被推出的时候,产品经理也会发一封热情洋溢的感谢信,把公司上上下下谢个遍,真正参与开发的自然要感谢,还要感谢周边组的支持,更要感谢公司领导的指引。我们很讨厌这样的电子邮件。

Lyft的做法是让首席工程师发信,信的内容除了对功能或产品的简单描述,还必须包括初步统计数据。任何影响终端用户的产品改动都需要经过一个分阶段发布的过程,初步统计数据就是在这个过程中采集的。我们要求在宣布产品推向市场的时候,非常明确地说清楚成功标准和衡量的方法。换句话说,发布一个新产品本身不值得庆祝,值得庆祝的是产品使用率提高了,从而给公司带来更多的用户或更多的收入,这样的发布信由首席工程师来发也是为了明确技术团队的主导地位。


喜欢的朋友可以添加我们的微信账号:

51CTO读书频道二维码


51CTO读书频道活动讨论群:365934973

【责任编辑:book TEL:(010)68476606】

回书目   上一节   下一节
点赞 0
分享:
大家都在看
猜你喜欢

读 书 +更多

网管员必读—网络应用

本书是一本介绍当前主流计算机网络应用技术的工具图书,全面总结了当前最主流、最基础的计算机网络应用,包括局域网和互联网应用两方面。在...

订阅51CTO邮刊

点击这里查看样刊

订阅51CTO邮刊