David Eastman 概述了 IT 顾问的工作内容，解释了为什么他们加入软件开发团队不一定是令人担忧的事。
译自 Oh No， the Software Consultants Are Coming!
IT顾问在行业中一直有着不受欢迎的印象。许多人对顾问工作的了解来源于Dilbert漫画，认为他们昂贵、傲慢，会威胁担心改变的员工。有人批评顾问提出建议却不负责任地执行和应对后果，承诺的范围也日益扩大。这种负面看法至今仍存在。
提到“顾问”，人们通常会想起大公司如麦肯锡的管理顾问。Mariana Mazzucato 的畅销书《The Big Con》正是批评咨询业“削弱企业、愚弄政府、扭曲经济”。在软件行业，顾问稍被谅解，因为他们大多曾是高级开发人员。对于读者来说可能也更为宽容，因为你自己可能也做过顾问。本文试图消除对顾问的一些负面成见。
新冠疫情强迫办公模式改变。大量外来人员进驻通风不良的办公场所仍令人不安，员工自己也不再经常到场。另一方面，从事顾问工作的人数似乎增加了，也许是长期静思或遭裁员的结果。
但顾问有不同类型和规模。入侵的高薪西装大军在IT界可能还存在，但也有许多只专门负责一个领域的人，如敏捷和质量保证等。有的组织欢迎顾问和承包商，不想账面有太多全职员工。有时顾问会外包工作给承包商，这只是语义游戏。如果你通过回答“如何做”获利，那就是在提供咨询。
现在许多员工队伍混合了各类人员：全职、兼职、承包商和跨职能的顾问。所以我认为旧的负面看法不再那么普遍。但以下是我从业内外听到的一些负面说法。
从技术上说，我去看牙医，他说我牙好但还收费，那就是浪费钱。专家的建议还是有价值的。
聘请一群顾问多年确实奇怪，但这反映不同团队或部门的资本/经营支出规定。公平说，厂商推荐的顾问不一定推荐最合适的工具。
顾问的实际工作是建议替代方案，指导如何改进现状或创建新系统。这可能包括编写定制软件后移交。从公司角度，他们的价值在于“在其他地方成功完成过类似项目”。专业知识和经验的快速注入不容易评估价值，但公司内部启动又失败的项目成本可以估算。员工可能有技能但缺经验说服管理风险可控。
相信我，问题自己找上顾问。想象有人在街上询问是否需要小修小补，起先人们会犹豫，然后想起一堆搁置的事。
当问题只是表象时，真正工作是找到可以有效改变的层面。这需要了解文化、历史，尤其是“为什么这样做”。产品负责人订交付日期前一天要看演示，延期交付问题往往是文化造成。敏捷后这种反模式减少了。现在延迟交付时有几个方面探究，症状可能不同——抛弃回顾，产品负责人不参会，缺检查说明等。顾问需要快速提交阶段报告，区分表象和根本，以解释为何需改变方法，避免仅罗列问题。
不幸的是，顾问有时被用来支持管理层已做出的决定，像鲨鱼围着故障船只让人不安。但大多数情况下，聘请顾问是为了解某领域表现不佳的原因。顾问可以告诉管理层他们才是问题所在，尽管这可能缩短服务期，但作为外部人员可以这么做。
更实际地说，顾问可能需向员工解释系统性变革如何改善公司前景，这暗示如果不改变会有何结果。当然，开发人员确实也会陷入困境，继续前进可能是最好选择，逃离预期失败的项目也不失为一种选择。
建议员工向顾问寻求职业建议，不仅免费，还不受背景或雇主偏见影响。
这很奇怪。人们不反感花钱找治疗师倾诉，却觉得谈论自己花大量时间从事的工作让人烦躁。大多数顾问都明智地同员工交谈以全面了解工作情况，尤其是当员工仅做自己的工作就与公司资源约束作斗争时。
如果你从裁判者角度出发，也许可以设计出更优系统。顾问确实需要了解企业文化，哪怕交谈超出员工舒适区也在所难免。但向他人讲述工作可以让你注意到长期存在但已不再关注的问题。
经常向未使用或误用敏捷方法的企业推广敏捷的咨询公司确实会这样做。但别忘了，敏捷是由开发人员发起的革命，即使十多年前被归咎于顾问:
许多组织采用了经修改的敏捷模式，经验丰富的外部人员可以检查这是否合理而不是简单墨守成规。
如果你自己也从事咨询行业，请放心，这个行业已经不再如过去那样鄙视顾问了。我希望下次你在公司看到顾问时可以友好一些，跟他们一起喝杯咖啡。当然，可以让他们付钱。