Blog

Blog

PHODAL

客户现场,三年

再三犹豫,终于在 rebase 到上海之后,还是决定写下这篇文章。三年多以前,我 rebase 到了深圳,开始了国内交付项目的旅途,我也几乎成为了待在该 account 下最长的 developer 没有之一。在那之前,我在 offshore 项目,混吃混喝混 session。

从 offshore 项目下来时,我不太适应客户现场——整个项目的人驻场开发,并需要在一定程度上遵循客户的规范。所以:

  • 没有每天的水果
  • 没有每天的运动
  • 没有很多 session(PS:相比于西安、成都 office)
  • 没有 people 关心(PS:还是有的)
  • 没有 workshop 和各种培训

要知道在 office,那可是早上 10 点有水果,下午 2:30 有水果,5:00 后有各种 session,还管饭。渐渐地,我远离了 office 的八卦,贴近了客户的八卦。(PS:所以,最后我 rebase 了,笑~。)

成长

对于每个刚进入一个新的公司,一个新的领域的人来说,成长是一个永恒的话题。而时代在变化,哪怕是退休的人呐,也都在学习怎么使用微信抢红包。

技艺

从技术的成长来说,只要有同等的学习时间,那么成长都是差不多的。所以,从某种程度上来说,我觉得不管是哪种类型的项目,靠的还是自己。不过,稍有区别的是,在 office 的项目,有更多的时间,也有机会接触到更多的机会:

  • 接触到新项目。这一点对于不擅长表达的同学来说,在客户现场就少去了很多机会。
  • 培训机会。office 也不大,一有风吹草动大家都知道了。
  • session 和 workshop。

从技术挑战上来说,国内项目周期相对较短,比较有机会接触到有技术挑战的项目;当然了,国内项目的交付压力和业务挑战,往往会比 offshore 项目要大。从生命周期来看,长期项目更有利于初级技术人员的成长——可以学习到先进的开发思想,培训出好的开发习惯。然而,国内交付项目的周期都比较短。值得注意的是,这里是从总体上来看的或者说叫平均值。因为一个优秀的 Tech Lead,会帮助大家更好的成长。

因此,这么一来看,国内项目比较适合中级开发人员的成长——需要不断平衡技术、业务、实践优先级。什么时候处理技术债?什么时候放弃一些技术实践?什么时候优先关注于业务开发。每个问题都很难,你总会遇到各种挑战。

应变能力

我第一次来到客户现场的时候,并没有任何相关培训,也缺少一些相关的经验。大抵是因为在当时,国内交付项目还不成规模。这就可能造成诸多的事故,反正我是见了不少,笑~。

事实上,第一个在客户现场的人都是半个真正的咨询师——尽管名义的 title 是咨询师,但是干的是普通开发的话。但是,从应对的挑战和职责来看,每一个人都是咨询师。所以,并非所有的入场员工,都会拥有相关的角色认知。

作为一个咨询师,你只需要比客户快半步即可。但是作为一个在客户现场的开发来说,你得比客户快一步。你每天都和客户一起工作,技术社区一有什么风吹草动,客户就知道了,诸如于 NPM 事故,React Native License 问题等等。外加一些无良的自媒体的捕风捉影,它们的错误言论,总会让客户对你的解释将信将疑。遇到的这样的每一个问题,都需要快速地做出响应。

如果比客户晚半步,那么还可以:『回去研究研究』;『建张卡做』。

沟通

于我而言,在这段期间里,与技术的提升相比,在沟通上的提升反而更大——毕竟从 10 分到 60 分,远到 60 分到 80 容易得多。

个体和互动 高于 流程和工具。 『敏捷宣言』

当你直接和客户一起工作的时候,快速的响应比什么都重要,而沟通是每时每刻都在做的事情——当然了,你得注意沟通的顺序:内部沟通,随后再与客户沟通。尤其是在遇到问题的时候,更考验相关的应变能力。记得先在内部把问题抛出来,再在内部去讨论怎么解决——或者与客户一起讨论,如果已经取得客户的信任。

而与 offshore 项目不同的是,每一个在客户现场的人都有机会参与到:一个需求从想法到上线的完整过程。这到是也蛮能提升开发者的各种能力,沟通、表达、快速响应。毕竟有的时候你要去截胡——将不可能实现的功能,扼杀在摇篮中。这样一来就不会出现那种奇怪的需求:根据手机壳的颜色来适配主题。

总之:实时沟通,注意言行

赋能 ta 人

作为一个 ThoughtWorks 的 developer,赋能 ta 人是你所需要具备的能力。你会经常分享一些相关的 session,又或者是手把手的结对编程,又或者是在 code review 的时候多提一些意见,还有针对于新人布置一些作业等等。

就当前而言,ThoughtWorks 引以为傲的是工程实践抽象复用——与国内的 ~~B~~AT T 相比,还是领先的。对于某一特别的领域和技术,如果它不能快速的复制应用到整个组织,那么它就缺乏竞争力。而哪怕能快速复制,还会遇到对方水平的问题。可归根到底,这些都依赖于有能力的个人,哈哈哈。

赋能客户。你会遇到的挑战,并非是把东西教给某个人,而是某些人不愿意学习,又或者是持相反意见。这就是你要面临的挑战,但是不妨着以让对方去尝试的角度来说服 ta 试用,万一真香呢?

赋能 TWer。在客户现场的时候,你也得去保护那些新的团队成员,或者是第一次来到客户现场工作的人。而取决于团队的规模,你可能无法保护所有人,只可能尽可能去分享其中的经验。而当你和新的 ThoughtWorker 一起工作的时候,你,你经常就会遇到一些挑战,诸如于:如何在赋能的同时,体现这个新 TWer 的挑战。尤其是对于 Tech Lead 来说,这种挑战更为严峻。所以,『这个卡交给 xxx,一天就能做完了』。

当你赋能到累、没有成长的时候,可以试着把这个工作分享出去。

四步曲

在之前的那篇《项目初期的最优技术实践》里,我抽象了现场开发的三个时间:

  • 技术准备期。进行一系列充分、不充分的技术工作,从搭建脚手架,到部署测试等等。
  • 业务回补期。填补第一个时期造成的业务落后问题,技术实践业务来证明技术的价值。
  • 成长优化期。持续地对项目的技术和业务进行优化,以实现开发及业务人员的诉求。

而对于客户现场来说,对应的则是四个步骤。:

  1. 糅合团队,应对挑战
  2. 保证交付进度
  3. 赋能客户
  4. 扩大影响力

嗯,大概就是这么简单。

1. 糅合团队,应对挑战

在第一阶段,你可能随时可能被 challege,原因有多种多样的:

  • 设计细节有些小问题
  • 和原有系统出现差异
  • 架构设计得很好,但是其它开发人员不一定能接住

尤其是,我们在项目初期的建立开发规范的时候,会遇到一系列的挑战。诸如于和客户原来的开发习惯不一致——多数时候,可能是一些不好的、落后的习惯,那么客户……。

不管怎样,妥协是最后的可行办法。不过,作为一个以咨询师 title 存在的开发,你所能做的事件是:说服客户采用

2. 保证交付进度

出现多种原因,会出现迭代 delay 的情况,如需求变化,预期的对应出现问题。其中的原因与我在《项目初期的最优技术实践》讲述的差不多。

不过,还要记得偿还你的技术债(务)。

3. 赋能客户

如上所述。

哪怕是客户有其它的 vendor,他/她们也可以成为你的朋友,帮助项目更好。

4. 扩大影响力

手疼,写不下去了。

总之,作为一个乙方要从长远来考虑问题,从 A 小组,到大组,再到整个部门。

交接(可选)

不同的客户有不同的利益,

演进(可选)

嗯,为未来做准备。

其它

保持你的幽默

当你是项目的 Tech Lead / Team Lead,适当地幽默气息,可以在困难的时候,看上去不会这么艰难。

……

TBC

关于我

Github: @phodal     微博:@phodal     知乎:@phodal    

微信公众号(Phodal)

围观我的Github Idea墙, 也许,你会遇到心仪的项目

QQ技术交流群: 321689806

新书《前端架构:从入门到微前端》

《前端架构:从入门到微前端》是一本围绕前端架构的实施手册,从基础的架构规范,到如何设计前端架构,再到采用微前端架构拆分复杂的前端应用。本书通过系统地介绍前端架构世界的方方面面,来帮助前端工程师更好地进行系统设计。

前端架构包含以下五部分内容:

  • 设计:讲述了架构设计的模式,以及设计和制定前端工作流。
  • 基础:通过深入构建系统、单页面应用原理、前端知识体系等,来构建出完整的前端应用架构体系。
  • 实施:通过与代码结构的方式,介绍如何在企业级应用中实施组件化架构、设计系统和前后端分离架构。
  • 微前端:引入6种微前端的概念,以及如何划分、设计微前端应用,并展示了如何实现这6种微前端架构。
  • 演进:提出更新、迁移、重构、重写、重新架构等架构演进方式,来帮助开发人员更好地设计演进式架构。
comment

Feeds

RSS / Atom

最近文章

关于作者

Phodal Huang

Developer, Consultant, Writer, Designer

ThoughtWorks 高级咨询师

工程师 / 咨询师 / 作家 / 设计学徒

开源深度爱好者

出版有《前端架构:从入门到微前端》、《自己动手设计物联网》、《全栈应用开发:精益实践》

联系我: h@phodal.com

微信公众号: 与我沟通

标签