MI驱动的极客研发管理文化
做互联网研发管理这么多年,自以为积累了不少心得：）,今天打算把他们一一整理和分享出来，希望与大家共勉，如能帮助到大家，甚是欣慰。
今天谈第一个话题.MI驱动极客研发。
MI就是Mission Impossible 的缩写,看过汤姆·克鲁斯主演的电影《碟中谍》（Mission: Impossible）的都知道，汤姆哥完成的都是极度困难，极具挑战的几乎不可能完成的任务.所以,我给研发团队的MI任务的定义就是:主动完成的具有较高技术难度的，其结果对产品用户体验或口碑有普遍的可感知的改进的挑战性任务.
我用几个实际发生过的例子来解释下什么是MI标准的任务。我们的一个后端工程师在处理一个Excel报表导出的任务时，花了很多精力都没有办法把报表导出时间降到十分钟以下,最终放弃. 但是我心里明白，这个导出肯定可以很短时间完成，数据量不大且没有io方面挑战. 于是我向所有研发工程师宣布了一个MI任务：凡是能将报表导出时间降为1分钟以下的，获得1个MI；降到30秒以下，获得2个MI；20秒以下3个MI；10秒以下，4个MI。结果有一个工程师利用额外的时间加班把报表导出时间优化到20秒以下，获得了3个MI。我让他把经验分享出来额外再加一个MI，让其他人尤其是当初放弃优化的那个工程师明白这个当初他认为不可能完成的任务是如何一步步达成的。
再举另外一个例子，一个项目产品原本只需要输出H5 版本, 但实际上app版本体验更好。我就发布了MI任务，开完时间不变的情况下，使用html5+标准同时输出app和h6版本的可以获得MI。每个形态对应一个MI。最终，有位工程师一周时间同时完成了H5，android应用，ios应用三个终端的支持，且符合一套编码，同步更新的原则，获得了3个MI。当然，她也同时完成了对另外一个工程师这个技术的培训，使这个技术可以应用在更多的项目上。
类似获得MI例子很多，比如一个工程师在产品部门还没有需求实现定位需求的情况下先期完成了lbs相关的sdk植入和服务端接口对接,使后续开发更加从容。团队每周还有技术分享和集体代码审核的习惯，凡是新技术的主讲人可以获得一个MI，听讲人可以获得三分之一个MI（或许你猜到了，我用这个办法是为了鼓励所有人学习新技术，提高研发效率的）
说到这里，该说一下为什么大家会愿意主动挑战Mission Impossible 了。很简单，MI有很大的好处，比如：
一个MI可以免一次迟到后的水果惩罚,不错，我们团队的人每次迟到都要给大家买水果（我的经验证明，大约每次得花费100元）
所有公司级别的绩效考核，升职加薪我会参考MI
研发内部的月度突出贡献个人的标准里其中一条就是当月必须获得过MI。哪怕你什么bug也没出现，也必须完成至少一次不可能完成的任务才能过优秀的及格线。
其他的大家可以自行发挥哈
最后总结一下MI这个举措的关键点：
必须是技术方面的挑战，有时间限制，一般最多一周以内时间完成。比如是技术方面的创新，或者是解决了其他人无法解决的问题。技术负责人必须亲自验证结果。时间限制是为了确保工程师选用的技术方案将来的大面积推广实施成本足够低，具备普遍应用价值。
必须事后分享经验或者培训其他人，确保团队整体能力提升。
因为MI有诸多"好处"，所以负责人要保证团队所有人都有可能争取到MI的机会。比如后端工程师，web前端工程师，app工程师，甚至测试工程师也要照顾到他们不同的能力模型。比如我们的测试工程师之前手工测试较多，我的策略就是每完成一项自动化测试技术的实际应用,可以获得一个MI。
MI必须是主动挑战的额外的任务，不能影响既定的产品研发的排期。所以，工程师不会因为完不成MI而受到惩罚，只会因为完成MI得到激励。
MI有固定的有效期，我一般设定两个月。这是为了防止MI在手的工程师有"惰性"，进取意识还是不能放松的：）
鼓励设定团队型MI任务。此种任务必须团队全部给力，配合才能完成，任何一人出问题，都可能导致任务无法完成。完成后，每人都有MI。
实际应用中可以根据项目和团队情况灵活运用MI这一激励措施提高研发团队的主动性，攻关意识，整体技能以及凝聚性。
关于作者: Tom. 国家公派留学归国硕士，在外企，BAT,创业公司都经历过。现在走着旅行担任CTO。目前在招聘后端php工程师(分布式、消息队列、数据挖掘等方向)和前端web工程师(JS)，欢迎你通过 [email protected] 应聘。