|
|
51CTO旗下网站
|
|
移动端

团队成员的发展:塑造T型人才

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

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

不受限的研发团队

团队成员的发展:塑造T型人才

和硅谷内众多的互联网企业一样,Lyft用目标和关键结果(objective and key result,OKR)管理体系进行季度规划。这个体系在1954年被首次提出,随后英特尔把它付诸实践,Google在21世纪初真正地把它发扬光大并随后被许多的公司效仿。

OKR管理法可用于对公司、团队甚至个人每季度的工作进行规划、追踪和衡量。OKR框架中的目标通常是长期性的,但对同样的目标每季度会有新的需要达到的关键结果。每个团队在季度初做出规划,并在季度末的时候针对每个关键结果进行评分,所以这些关键结果都必须是可衡量的。

在我们做Lyft外部平台的时候,旗下所有团队也都各自制订OKR,并且连续多个季度近乎完美地达到了预期的结果。从工程到产品、到销售、再到商务,每个部门貌似都交出了无可挑剔的答卷,然而当我们回过头看最核心的数据,比如月活跃企业版打车单量的增长曲线并不令人满意,不像OKR打分那么光鲜。

于是我们做了总结,同时也向企业版客户征求反馈,归根结底发现增长不给力的原因十分简单。就是企业版的某些功能太复杂、流程太冗长,需要企业客户进行大量的数据及账户迁移工作,客户不是懒得弄就是弄错。另外一些潜在合作公司有些独特的功能需求,但是发现我们的产品不支持。遇到这些情况,很多公司往往认为还是使用传统的出租车或专车公司来得有保障。

这一现象暴露了两个问题:一是我们明明在开发之前就已经了解了所有的产品需求,但是为了保证在预计的时间内推出,团队不得不放弃部分功能;二是既然产品的用户体验不好,为什么我们OKR的打分都如此之高呢?

这里先讨论一下产品开发过程中因为时间压力而减去部分功能的问题。这样的现象在科技行业内司空见惯,比如每次人们为新一代iPhone的神奇功能惊叹时,背后不为人知的是苹果有更多更厉害的功能没有做完,也就是说因为他们程序员的拖沓导致了购买者可能在一年之后需要再花几千块钱去买新的机型。

遇到这些情况,工程师往往要让产品经理负责,因为很多时候为了更快地推出所谓的MVP产品(minimal viable product,也就是最简单化的可以推出市场的产品雏形),产品组会拿主意砍去他们认为不必要的东西。而排除的功能是不是客户接纳追捧一款产品的关键,是需要进行可用性研究和A/B测试的。

但这时候技术团队又会说:A/B测试没时间做,因为界面设计太慢了。设计组拖了很久,因为他们有很多优先级更高的项目要做。与其说这是技术团队在推卸责任,倒不妨更客观地把这些问题看成是部门之间合作的必然产物。如果想治标,那就让某个产品经理或是设计师改进,或者是给企业版和外部平台提供更多的资源。

但管理人员应该想的是如何从根本上杜绝类似情况的发生。一个高速发展的公司在面对巨大的市场竞争的时候,资源短缺、时间紧迫都是常态。在任意时刻,如果拥有完全充足的资源,可能就意味着资源浪费。所以当我们接受了资源有限这个事实后,开始思考怎样从技术团队着手,依靠优化工程师文化来提高团队效率,寻找让工程师可控的解决方案,即塑造T型人才。


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

51CTO读书频道二维码


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

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

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

读 书 +更多

Java程序设计教程

本书对第1版的某些章节作了合理的调整,增加了部分实用的程序,并在每一章的最后加了适量的练习题,以巩固前面所学的知识,更加有利于等级考试...

订阅51CTO邮刊

点击这里查看样刊

订阅51CTO邮刊