咨询札记（壹）

咨询札记（壹）

Posted by: Phodal Huang Nov. 9, 2020, 7:58 p.m.

去年，因为答应了花仲马要来杭州，我从深圳 rebase 到了上海。因为公司的组织变革，外加市场因素导致的职业发展受限，区域性的组织结构里，找不到一个合适的角色适合我 —— 市场对于岗位的定义越来越明确，使得我这种天性喜欢各式各样开发的人，出现了各种不适应性。在大部分的组织（TW 受限于组织的需求）里， 已经不再需要多样性的选手，只需要一颗真正的组织里。

外加，既然来了上海，就意味是出差，那么出差就变得不可避免了。于是乎，在胡老师的帮助下，我转到了咨询团队。

在我短短几年的 TW 生涯里，我经历了多次的角色转换，经历了不同的地域，感觉了不同的文化氛围。

• 初始，我在西安，所在的团队是海外交付团队（即如今的袋鼠业务线），掌握了某种意义的好的敏捷实践。
• 期间，作为一个毕业生，我参加了位于印度的 ThoughtWorks University 培训，经受了一番『大-洗-脑』。
• 随后，因为花仲马毕业了，我 rebase 到了深圳，来到了国内业务线上，开始真正的接触客户，提升沟通技巧。
• 去年，rebase 到了上海，来到了华东业务线，虽然是短暂的经历，这才发现了国内软件开发的另外一种『精髓』（不好的），客户要的只是短、平、快，还有好处。
• 末了，我来到了咨询团队，接受炮与火的洗礼。

几次的转换下来，我发现这并不是一件容易的事。来到新的部门、新的地区，都不可避免地要重新经历各种考验：适应新的模式，重新理解组织。以前只在某一特定的小区域，我所理解的组织，都是一种盲人摸象式的推测。所以，到了今天，我越来越不确定真正的组织模式是怎样的？

适应新的组织盈利模式，并不是一件容易的事。我们在先前建立的一系列知识体系，在新的组织下，可能没有多少价值。不可避免的，因为有了经验，我们会受经验所累。好的一方面是：我们会尝试做好准备，不好的一方面是：我们可能并不想尝试。

好在，我到咨询团队接受到了 Lead Consultant 胡老师的指导，以及前公司 Principal Consultant（嗯 ，就是高我大两个级别的存在） 新哥的教诲。在经历了一番经验之后，我开始了我的咨询生涯。初到咨询的时候，原先的一个问题：如何胜任新的工作？变成了两个问题。外加一个，如何保持技术领先？

如何胜任新的工作？ 这是一个很自然而然的事情，了解现有的组织模式，然后活下来、适应，这就完成第一个阶段了。然后，在这的基础上，再去创造更大的价值。为了快速胜任，可以从经验学习，最快的是学习他/她人。

如何保持技术领先？ 并不是说我们比客户快，而是说如何依靠于行业，并引领整个行业。这个问题有点难呐！不过呢，也并非那么困难。对于这一点，我已经有了一些想法，剩下的就是花时间去验证它。

从公司层面上来说，我司的咨询分为两类，一类是管理咨询，另一类是技术咨询：

技术咨询(Technology Consulting)，一般是指咨询方根据委托方对某一技术课题的要求，利用自身的信息优势，为委托方提供技术选用的建议和解决方案。

简单来说，作为一个技术专家，需要有多领域的知识或者人脉，并且能在极短的时间内（几分钟、几小时、一两天）证明自身的技能能力。而后，客户才真正有愿意地把技术问题，交给我们解决。

所以本质上，我发现现在的工作，和我原来在各种项目里当 Tech Lead 的时候，没有太大的区别。小的区别还是蛮多的：

• 干的活还是相似的，只是更有趣、挑战一些。
• 工作上的代码时间少了一些。具体视项目即看，有的是技术攻关，反而远比原来多。但是，在我看来这是个优点，回酒店就有动力写代码了。
• 接触的人 level 高了许多。从底层写搬砖的，到顶层 CTO。也有各种感慨，再透明的世界里还是各种欺上瞒下、笑里藏刀。

别的话，还有一些非常长的话题，暂时懒得写，比如『KPI 论』 —— 论如何看清问题的本质。

成为代码专家

来到咨询团队时，我面临公司大佬提出的关于年龄和经验的考虑，即在某种意义上，对于咨询这个行业来讲，我『太年轻』了。在大佬的观点里，虽然胜任工作很容易，但是对于我们来说，自己的能力成长就是一种考虑。所以，在这个时候，我必须做的一件事情是，持续不断地编码。以确保自己汲取到足够多的知识，以及对应的代码能力。于是，我们就需要成为『代码上的专家』。至于，具体的定义我可能并非那么清楚。

大佬不仅会指出问题，还会给你指出一条明路。所以，我有了一个未来几年的 Todo List。按大佬地话说，就是平时写写这些打发打发时间，然后换换味道。随后，在那之后的近一年里，我在 GitHub 上有了 10，000 + 次提交，差不多是我在交付团队上的三倍（原来大概率就也 3000+）。主要得益于：

1. 年初受疫情影响，在家 beach 的时候，努力地写开源项目（差不多有 4.5 个月）。
2. 出差有了更更充足的代码时间。反正我宅

如果和过去的增长速度相比，我发现我这一年的技术成长可能是原来速度的两倍，大概率是 Todo List 太好了。另外一个则是原来写的是业务代码，成长不快，而现在则是纯纯的技术代码，还有大量的学习。

不过，我相信未来一年可能就不是这样的，疫情不常有， 哈哈哈。

工具箱思维

过去，我打造了一个又一个的开源工具，这些工具在应对大型组织时，需要采取某种方式有效地组织起来，才会成为一个更强大的工具。所以，我原先的工具思维在这一年里，已经进一步演化为工具箱思维。在某种程度上来说，大型组织所需要的是一个平台。但是，平台本身也是一种工具箱，只是经过定制的工具箱。

一个很好的例子就是，我和我的同事刘宇一起创建 Ledge DevOps 平台（ https://devops.phodal.com/ ）的时候，创建了首页的元素周期表。在 DevOps 元素周期表时，它包含了大部分组织在实施 DevOps 过程中，所需要的各种类型的工具，如源码管理、制品管理等。而对于一个组织来说，它们只挑选其中的某一个（当然，对于大型组织来说，它包含了一系列自我维护的小组织，它们又会有自己的选型。

于是乎，对于我来说，这意味着：

1. 继续打造顺手的工具。如遗留系统重构工具 Coca
2. 设计更有效的工具箱战略。即总结和抽象某一领域所需要的相关工具，并使它们能很好地结合到一起。
3. 扩大到组织层级。能力越大，那么我所能接触到的层级也就越大。所能设计的工具，也能以企业级作为受众。

快速深入领域

对于一个技术咨询而言，它的主要价值在于解决问题的思维方式，剩余的一些价值才是他/她现有的技术能力。换句话来说，就是我们要解决问题的道，还要有解决问题的术。在多数情况下，术并非那么重要，因为我们还可以快速学习。但是呢，考虑到道的通用性，我们还是要有快速深入某一领域的能力。

哪怕我们是相关技术栈的专家，但是对于客户的系统来说，我们是个新手。问题多数时候很少出自于框架本身，而是在某种特定的环境或者是技术栈结合下，出现的一些问题。

多数时候，我可以依托于 ThoughtWorks 这个智囊团（Hive Mind）我们能快速 GET 到各种领域的知识，我也可以靠着技术圈的各个 KOL 了解相关的知识。但是呢，对于个人来说，我们还是要：

• 高效学习。持续学习对于我来说，已经不是问题。下一步，便是如何高效的学习——因为时间总是有限的。
• 长期计划。尽管我已经养成关注 Next 的习惯，但是依旧时间上仍然不足，所以如何变成团队式的 Hive Mind 就是一个有意思的话题。
• 更好的学习方式。

所以，我在想是否存在某种方式，实施群体学习 —— 当然了一起写代码是一个不错的主意。

作为一个在技术领域写作颇多的开源软件作者，我通过不断的实践，提炼其背后的一些思想，总结出一系列的文章。但是，随着我在咨询领域的深入，我意思到我需要的不仅仅只是举一反三的能力，而是能否从：

一个逻辑学家能凭一滴水推测出大西洋或尼亚加拉大瀑布的存在，即使他并没亲眼见过。 —— 福尔摩斯。

同样是咨询行业，我们需要做到接近于福尔摩斯这样的能力。

我在过去做得并不是那么好，一个可能是受限于经验的原因，一个则是我并不知晓我应该这样去做。所以，我在过去的一年里，一直在做类似的一些尝试：

1. 只凭借一个小点的问题，推测到系统性的问题，而后再进行验证。如最近写的《临时方案传染性》，便是一个这样的例子。
2. 接触到某一系统时，尝试概括整个系统的架构和模式。如《编程语言的 IDE 支持》

当然了，这些依旧只是单一团队级，又或者是多个团队级别。下一步，可以尝试推理到整个系统的级别。

从其他/她人身上学习

让我再提及我觉得咨询这一个行业很不错的一点，接触到的人远比原来多。会看到各种各样优秀人才，看到人性的光辉（黑暗面我已经说过），看到其它公司程序员的出路。

总而言之，言而总之，从他/她们身上，总是能 GET 到一些独特的技能。

诸如于：虽然这个问题能难，但是可以不走常规途经，绕一绕就过去了。笑，有一些在我们看来，就是知乎上著名的『蒙古海军奇袭北京』的段子，但是 it works。但别说质量，人家啥要求都达到了时间上 OK、功能上 OK，就是实现不行。但是 who cares？

这么一些日子下来，我一直在思考我们所面临的一些考验，便有了一些想法需要去验证。

• 迷你团队的模式 or sponsor/sponsee模式？即围绕一共同模式展开的同一方面的研究
• 工作即旅行。既然，咨询是一份在轮子/飞机上的工作。那么，是否就可以当成是各种旅行？
• 更好的技术咨询。是否存在更好的技术咨询模式？

当然，我只是在 YY。