77 lines
8.1 KiB
Markdown
77 lines
8.1 KiB
Markdown
|
||
|
||
因收到Google相关通知，网站将会择期关闭。相关通知内容
|
||
|
||
|
||
118 吴铭：成本评估是技术leader的关键素质
|
||
在互联网公司中，技术与业务的关系一直是焦点，我们对于技术与业务之间的矛盾也早已司空见惯，相信大家在工作中都看到过类似的场景：
|
||
业务问，“对手产品的某功能我们什么时候能上线？”
|
||
技术回答，“目前不行，这个版本我们需要做重构。”
|
||
业务问，“性能慢一点没关系，明天能不能发版？”
|
||
技术回答，“不行，我们要多花两三天时间将性能提高百分之百。”
|
||
业务抱怨，“我和别的公司谈妥了合作营销，技术却总是不给力。”
|
||
技术也抱怨道，“你们一个月提一百个需求，没几个有用的。”
|
||
|
||
诸如此类场景屡见不鲜，无论公司处在何种规模，只是争议的内容有所不同罢了。归根到底，业务体系与技术体系的矛盾主要集中这四方面：
|
||
1.对于资源的抢占；
|
||
2.对于成本的评估；
|
||
3.对外部目标的差异；
|
||
4.内部目标设定的合理度；
|
||
|
||
协调技术与业务的矛盾
|
||
|
||
资源抢占是表象，也是其他方面问题的体现，技术leader最需要关注的是对成本的评估，也需要时刻对此保持清醒的头脑。因为技术人天生对技术有追求，我们很难要求每个一线的技术人员都去了解业务背景、业务收益等情况。同理，我们也很难要求产品、市场、运营等人员去考虑技术方面成本与收益。
|
||
|
||
因此，当公司达到一定规模后，一名优秀的技术leader就必须在技术与业务的平衡和成本评估等方面花费更多的心思
|
||
|
||
我举两个例子，第一个例子是，曾经我们的技术人员提出一个需求，想用三天时间提升产品性能，使产品主页面的加载耗时缩减一半，同时机器成本也一半降低，这听起来确实不错。但同时，业务人员也提出了一个需求，想在做一个为期两天的红包活动，以此吸引大批用户与流量。
|
||
|
||
作为管理者，面对技术与业务同期而目标不同的需求，你将如何抉择，又如何做成本评估、价值评估呢？
|
||
|
||
第二个例子是，我们的技术团队想用机器学习算法重构产品中的酒店业务的排序模型，做到个性化推荐。模拟测试后，新模型的确要比原来的方式效果好一点。但业务团队不支持这个想法，在他们看来，酒店类业务并不是高频使用的场景，而且具有极强的地域性，之前的当地业务人员人工排序的方法效果不错，贸然改用技术排序，结果不一定好。
|
||
|
||
事实也确实如此，在这种样本量非常小的情况下，技术人员改进之后，短期内效果确有所提升，但是当一些特殊情况发生时，比如节假日、公务员考试等，业务情况就会产生很大的波动，而新的算法模型在早期没办法准确的覆盖这些因素，反而对业务造成了非常不利的影响。
|
||
|
||
但我们不能以此判别技术团队的改进方案是错误的，只是一线技术人员无法全面考虑到市场中的所有情况，因此，最理想的办法就是技术团队提出产品改进方案后，与业务团队一起进行可执行度评估、价值评估与成本核算。
|
||
|
||
我想强调一点，作为技术leader，我们做决策时要多以成本与收益为考量点，而不仅是基于个人的技术理想主义。我们常说“技术驱动世界，技术改变世界”，我当然认可技术的力量，但有时必须承认，公司依赖业务运转。可能在某阶段，公司更多的偏向技术驱动，但到了其他阶段，可能就是以产品驱动或运营驱动为主，但归根到底，公司必然是以业务为最终驱动的。所以，我们一定要清楚在当前的阶段和业务场景下，公司对技术有何要求与期望，避免过度技术驱动。
|
||
|
||
不同公司所处的阶段不同，对技术的定位不同，技术与业务之间的关系也就不同。有些公司对技术的定位是“救火”，解决紧急问题；有些公司对技术的定位是“搬运”，将线下产品或服务等搬运至线上；还有一些公司对技术的定位是“提升效率”；也有一些站在科技顶端的公司，对技术的定位是创新与突破。
|
||
|
||
所以，技术leader在协调技术与业务的关系时也需要考虑到公司当前所处的阶段 ，以及公司对技术定位，总结一下，可以归纳为以下四点：
|
||
1.清晰服务于公司短期目标，明确技术定位，明确技术驱动与技术创新在当前阶段的价值。
|
||
2.合理调配技术资源分配，包括协调沟通与资源评估。
|
||
3.组织领导成本及收益评估，需要掌握业务知识与成本核算。
|
||
4.预留中长期目标规划空间，做好技术规划与技术储备。
|
||
|
||
技术实施与规划
|
||
|
||
回到技术上，技术的实施与规划是技术leader工作的核心。先来看技术实施，技术实施的过程有三个关键点，即资源配比、技术选型和业务分析，更有两个绕不开的话题，即旧系统改造与新技术引入。
|
||
|
||
1.旧系统改造
|
||
|
||
每个公司基本上都会遇到旧系统改造问题，包括何时改造、重构还是改进、投入多长时间、投入多少资源以及价值评估等方方面面的问题。我用一句话总结这些问题：非必要的重构是没有业务价值的。
|
||
|
||
举个例子，我们之前有个由多个运营人员组成的离线分析团队，他们每天下午5点会看离线分析报表。由于这个报表需要几个小时才能生成，技术人员就投入两天时间去做改进，将几小时改进为耗时几分钟。
|
||
|
||
从技术层面讲，这件事非常值得鼓励与赞赏，但对于业务方面没有任何影响，运营人员仍然在每天下午5点看报表。如果当时技术团队没有其他高优先级的事情，那么做这件事是很有意义的，但假设当时同时还有个市场活动要做推广，那么技术资源就不该倾斜到这件事情上，因为技术资源永远是不够的，我们做技术改进时一定要结合业务进行成本核算、价值评估。
|
||
|
||
2.新技术引入
|
||
|
||
技术人员总有创新冲动，看到新的热点技术就想着能不能引进。对于新技术引入，我总结出以下5个思考点：一，引入的技术是否成熟；二，是否已做好相应储备；三，是否能承担相应人员培养成本；四，能够承担多大的风险；五；是否已经做好引入后的价值评估。
|
||
|
||
总而言之，对于新技术的引入，即使能够将性能提升一千倍，但这种性能提升对业务没有太大帮助，也就没有必要引进了。
|
||
|
||
我们要鼓励技术人员做微创新，但不论是微创新还是大改进，我们作为技术leader一定要考虑到成本评估与控制的问题
|
||
|
||
再来看技术规划，对技术leader来讲，技术规划时主要有三个思考点，即技术路线规划、技术栈储备与风险评估。
|
||
|
||
首先，我们一定要多去关注中长期的技术发展与趋势，但也不要太过超前。除了对那些技术依赖性强的公司，技术有引领、指导作用外，对于大部分的中型、中小型，或初创公司来讲，太超前的规划技术路线，做技术储备没有太大意义。
|
||
|
||
如今，新技术在很短的时间内就能被普及，我们所储备的新技术很有可能很快就会成为平民化、大众化的技术，大家都可以享受到这种技术福利，比如之前的自动化测试、自动化运维等，很快就变成了大部分公司的标配。另外，太超前的技术出本对成本也是一种消耗。
|
||
|
||
因此，技术储备的前提是对长期目标和长期收益的判断，只有当既定目标非常明确时，才好去做长期的技术储备，否则，就很有可能发现储备的技术对业务场景并没有太大的价值，变成一种资源的浪费。
|
||
|
||
|
||
|
||
|