Enlightening Talks

[EthanLin-TWer]

2017-06-02 与朱 P 聊

关于 TL 的个人成长

朱 P 说，分四步走。这中间可能需要3-5年的时间。随着你的成长，这中间工作的变化是，你思考的抽象层级变了，处理的基本元素不一样了，你加的杠杆越来越大了。所以，要承担的压力也会越来越大。必须有能力的支撑，否则就会承受不来，给别人带来损失。

这四步大概是这样一个过程：

1. 在一个有 TL 的项目中能把工作做好
2. 把工作做快，更快、质量更好地交付。从而省下了钱。快既省钱和多验证，这是唯快不破的真理
3. 多接触其他技术栈。能做到前端框架的技术选型、基本环境搭建的时候，就可以成长为一个前端项目的 TL 了
4. 接触后端的东西，加一些软技能。然后就可以变成一个项目的全端 TL 了

越往上走，你需要撬动的人和资源就越多。比如 TL，除了自己的8小时外，你需要利用别人的8小时，你选的型对整个团队的 billable 时间都是有影响的；比如 OP，除了自己的8小时外，你要负责的东西就更多，比如招聘，比如办公室人员的成长，这些更无形的东西产生的价值会更多，需要你有更多有效的模型。因此，需要扎实的能力。

价值的评断

你能产生的价值，本质上是由这个公式决定的：

价值 = (能撬动的资源 * 资源的有效价值产出) / 单位时间

也就是说，你产生的价值等于，单位时间内，你能撬动的资源被有效利用产出的价值。

那么问题来了，「资源的有效价值产出」，怎么能确保资源有效地产出了价值呢？答，你的「模型」。模型是你对事物的认知，是你在给定的资料源下，把它转换到价值一方所用的知识模型。模型 = 有效加工(原材料)。那么，问题又来了，如何保证：

• 优质的原材料输入
• 高效的加工

学习如何学习（Learning how to learn），尝试解决的就是这两个重要的问题：资料的有效输入、资料到模型的有效转化。

讲学习。说在不同的角色上，要思考的「基本元素」是不一样的。比如 dev 要思考的基本元素，可能是「如何写好一个类」，「如何测试」这样非常具象的问题；而作为 TL，他在思考的时候，必须根据他的实践经验，把这些具象的问题打包成更抽象的问题，比如「技术选型」，「微服务如何拆分」等，从而能撬动更大的价值；比如 OP，他要思考的可能是「如何确定办公室的招聘策略，并验证模型的有效性」等这样的问题。

打包（chunking），是人类大脑理解事物的方式。通过把底层的、具象的信息打包成一块更抽象、更浓缩的知识，能让你小小的大脑里能存储、处理更多的信息，提高信息密度和处理能力。

Dev 要做的，就是把如何做好软件这个问题域，打成一个个的 chunk，以实践填充之，让你这个模型能高效、有效解决软件构建领域的相关问题。

当你要往角色进化上走的时候，有可能会有不适，因为你要处理的基本元素变化了。你需要处理的问题可能更加抽象了，你需要重新找适用的模型，并且验证这个抽象模型的有效性。但要注意的是，这些抽象的模型必须是由底层扎扎实实的实践支撑的，否则你说的可能很大，看似信息密度容量很大，但经不起考验，全是吹牛逼。

ThoughtWorks 的长处与短处

短处是，没有产品基因，很难说在一个单一项目上深钻。长处是，有多个项目可以接触。

这多个项目，其实就是 dev 的「原材料输入」。多个项目的价值在于，它可以提供工程实践的多个「材料源」，如果你能在一个项目上用心总结其规律模式，形成你的「模型」，并在后面的项目中不断验证、校正这个模型，那么你在积累的，是一个「如何把项目做好」的「模型」。

前提是你必须用心总结。

Dev 的价值

我的困惑是，作为 dev 有时候并不知道自己的工作产生的价值在哪里。感觉不清楚整个软件行业是怎么运作的，dev 这一段产生的价值在什么位置，因为一个项目从谈到最后挣到钱，其实是经过了很多环节的，售前，inception，项目经理进场划定 scope，BA 把需求分成一个个小卡，最后才是 dev 把这些事情用代码实现。我说，感觉我看不到一整个 big picture，不知道 dev 产生的价值有多大，在哪里，相同价值是否可以由其他人、用其他方式取得？这个问题之所以重要，是因为我需要我知道产生的价值，方向对不对，如何衡量和判定我事情做的好不好。

讲到生产线。线上有许多环节，每个环节的「价值」，就是接受上游来的原材料，经过加工，向下游产生其所需要的「工件」。那你做为 dev，其实你有的原材料，就比如是你的 IDE、语言、这些别人看不懂乱七八糟的东西，你把上游来的「需求」，变成一个可交付的「软件」，让下游不需要去接触这些原料和细节，这就是你产生的价值。所以大熊之前说的一点其实很切中要害，这个阶段，你要注意的不是用什么技术，什么框架，什么实践，而是用这些原料，把项目交付好，做一个「项目到了你的手里就绝对不会做死」的 dev。

这就是 dev 的核心价值。把项目做成、做好、做快。在公司的这个模型下，你的上游就是需求，原材料就是你的工具、知识、模型，产出物即是可交付的软件，你的下游就是 PM。衡量工作做的好不好，就是你的 PM 觉得你做的好不好，有没有帮他解决了问题。「项目解决能力」，是 dev 胜任力的重要衡量。

这个软件行业的「生产线」本身，是什么？是：“用程序语言来在服务器上建立自动化的服务，可以自动地为客户去提供服务，比如搜索数据、展示数据、购买商品”。用程序去驱动服务器为全世界的用户提供服务。

软件行业 与 互联网转型

互联网/数字化给客户公司带来的价值是什么？搬到互联网上的这些东西、数据，其实企业原来就已经有了，而且搬到互联网、数字平台上，其实也需要耗费巨大的资本，那么好奇它究竟是如何为企业赚了钱的？它是节约了原来的什么成本？节约了多少？还是它创建了什么新的、没有互联网所创建不了的价值？

传统行业如何基于互联网设计商业模式.pdf

[JimmyLv]

太棒了！

[jkvim]

哇, 好赞的总结

PS：title 有个 typo 2016 -> 2017, 然后结尾的 PDF 是个假链接？

[EthanLin-TWer]

@jkvim 是个假链接哈哈，是个本地的 PDF 嘛，不知道怎么放进去。私聊找我要哈。