如何做到业务迭代和技术积累的平衡？｜线上分享
小欧有话说：
为了加深EGO会员之间的相互了解，同时也为更多的技术人提供相互学习交流的机会，EGO开展了每周四21:00的线上分享活动。本文根据杨剑锋7月7日线上分享内容整理而成。看看我们的老朋友“七米”是如何应对飞速发展的无线技术，在实践过程又有怎样的总结和思考吧！
大家好！先自我介绍下，我叫杨剑锋，在美丽联合集团（蘑菇街）花名叫七米，09年毕业，12年加入蘑菇街，主要技术背景在移动端和前端，缺人的时候服务端也写过，最近一年对IM也有了一些了解。
我之前比较长一段时间是负责蘑菇街无线事业部技术团队，最近几年蘑菇街移动端业务发展很快，自认为我们无线团队在技术积累方面做的还算合格，所以想分享下过程中我的思考和总结：
◆ ◆ ◆
业务和技术的关系
聊到业务迭代和技术积累平衡的时候，首先我们得理清楚业务和技术的关系。我有听到过很多种说法，有同学说技术是业务的基石，是来支撑业务的，这个肯定对，没有技术业务完全没办法跑起来；也有同学说技术是用来驱动业务的，技术不能只是简单的满足业务需求，需要有更长远的积累来推动业务的发展；还有同学说技术就是业务，这个就有点聊哲学了。我的看法是这些说法都对，但又不全对。
所以我把大家的说法综合了一下：业务产生需求推动技术往前发展，技术发展之后又提供了更多的业务可能，这是一个互相推动、循环发展的过程。
举个例子，蘑菇街做Web容器混合式开发，就是为了满足业务能够更快速迭代的需求。对业务方来说，2周一个版本对业务来说还是太慢了，等不了。做了Web容器之后我们又基于Chromium内核做了自己的Webview，替换掉了系统的Webview之后性能好了非常多，Android碎片化的兼容性也没太多问题了，之后我们跟业务同学说这样可以做这个动画、可以做那个效果，给活动的玩法提供了更多的可能性。我们App端做组件化、动态加载热更新等等都是这样的过程。
再举个小点的例子，Instagram大家都很熟悉，但是有个细节不知道大家有没有注意到，发布图片的时候会读取图片的Exif自动补上图片的拍摄位置。比如前几天在国外玩，拍了照片没有发布，今天回到家发布的时候还会带上是在哪里拍的，产品同学不一定能够提出一个这样的需求，这也是一个技术和业务互相促进互相推动比较典型的例子。
这里还有一个观点：技术一定要解决实际的业务问题，不能从技术角度出发给找业务场景。例如，3D试衣，很高大上的技术，但是菇凉们真的想看到自己真实身材穿上漂亮衣服的场景吗？我觉得不一定，这个跟大码女装的模特都不胖也是同样的道理。
◆ ◆ ◆
工程师的分类和平衡
不管是跟业务需求还是做偏基础性的技术事情，人都是最重要的因素，讲一个我之前踩过的坑：
在早期招聘面试的时候我会特别关注技术，面试者一定要有不错的技术积累、对技术要有热情、业余时间会去主动学习新的东西等等。当时这些同学也要去做业务开发，我发现这些同学有一个共性的特点就是技术能力都很不错，但是很少会去考虑业务问题。他们收到需求的第一直觉是想着怎么去实现，完全没有意识去考虑为什么要做这些需求、需求背后是要解决什么问题、有没有更好的方式去解决等等。最终的结果是不光系统弄的很复杂，业务支撑方面做的也不好，只能说是把业务需求实现了，然后并没有很好的解决业务和用户的问题。
后面我也花了很多时间尝试去改变这些同学的思维方式，效果不怎么好，当思维方式固定之后基本上很难被改变。因此，我知道了工程师也是有分类的，一定要让合适的人做合适的事情，才能发挥出更大的价值。
根据性格和兴趣，我把工程师简单分为两类：业务型工程师和技术型工程师。
偏业务型的同学会有不错的业务sense、善于沟通表达，不光在需求评估方面，在业务上线后也会一直关注业务数据，发现业务中的问题并想办法跟进解决。这些同学将技术视为解决问题的工具，够用就好。这类同学到后面也有一些转岗去做了产品。
偏技术型的同学就完全不一样，他们本身对技术有非常高的热情，他们不太会拒绝需求，更多的是想怎么去实现，想着对架构、性能和稳定性会带来什么影响，很多时候也比较闷骚不太善于跟人沟通。
当然业务和技术都做的不错的也有，但是真的非常少。
后面招聘就开始考虑两种类型同学在团队中的平衡，具体比例方面跟公司性质相关会有一些差异，蘑菇街无线团队经过几年的磨合和补充，现在业务型和技术型工程师大概在2:1的样子。
◆ ◆ ◆
时机很重要
作为团队主管，管理上除了让合适的人做合适的事情，还有一个非常重要的事情是什么时候应该做什么事情。
最早期无线事业部就几个技术同学，快速的业务迭代、产品试错是最重要的，说不定下个版本就推翻重做了，谈不上技术积累。随着团队的壮大、业务复杂度变高、产品也不光只有蘑菇街一个了，团队在业务和技术积累上的事项选择和优先级判断越来越难。
太偏业务缺少技术积累的话，业务迭代虽然很快，但是团队疲于应对各种需求，做完一个版本下一个版本又来了，团队和成员技术成长也非常慢，不利于长远发展。
太偏技术积累的话，团队短期的状态会很High，因为大家都喜欢做一些高大上的事情，但是经常的结果是技术提前太多，做了很多没有价值的无用功。比如说我这边在2013年底做过一个App端打点数据分析系统，设计的很完美，各种用户行为链路分析、能加的打点全都给加上、能自动化实现的全部自动化。然并卵，最终上线后大部分数据都没人看，没人深入关注分析的情况下数据准确性也有问题，浪费了很多资源。现在回想起来，在满足业务方特定打点需求基础上，做一定的抽象不用每次加打点都很麻烦就好。
所以我觉得最合适的做技术积累的时机是提前一步，仅仅一步就好，多了、少了都会有问题。
◆ ◆ ◆
目标和共识
技术和产品或多或少都会有一定的矛盾和偏见，我这里也不是分享怎么跟产品和运营闹矛盾。分歧的主要原因还是在于大家的立场不一样，了解到的信息不同步和看问题角度不一致造成的。要达成共识，技术团队首先得认清自己在公司中的价值，这是做所有事情决策的基础。
对我们公司来说，技术不是最核心的生产力，公司并不会因为技术做的好就很成功，但是技术没做好就肯定会拖后腿，这是我对我们技术团队的理解。在自我认知基础上，我们也对自己提了一些要求：
做业务的技术同学一定要深入业务、了解业务，能够从技术角度跟产品同学一起完善业务问题的解决方案，并且能够想办法去批量解决一些问题，工程师不只是完成业务的“资源”。
认清自己之后，达成共识的第二步是找到统一认可的目标。当大家一起聊的是如何提升业务转化率而不是这个需求能不能做的时候，如何让公司盘子更大大家手上的期权更值钱的时候，自然就没有了那么多矛盾和偏见了。
在蘑菇街，技术和业务并不是互相对立的存在，技术跟产品和运营达成共识也并没有那么难。我们也建立了一些共识：
1. 技术服务于业务，最终的技术努力一定要在业务上对用户产生价值；
2. 需求是永远都做不完的，不可能所有需求都做，也不是所有的需求都一定要做；
3. 工程师不是完成业务的“资源”，我们的责任是将如何解决单一问题，变成系统化解决一类问题。
技术管理公开课参与方式：
本文系EGO原创首发，请获取授权转载