比起懂最新的知识，工程师更应该懂这些.......

有些公司永远在徵人（人员一直在流动），实际去应徵过後，会深刻理解到为什麽。

前几天提到GitHub时，有顺便说过「很多人（主管级、甚至是组织决策者）都有一种想法：凡有技术需求都找现成解决方案就好」。
所以我会花很多力气强调：绝大多数公司根本不做研发。因为他们都在追求「现成解决方案就好」。
不管这种想法是否合理、是否真实可行，但他们会认为「工程师在到职前就要懂各种需求的施工技巧去完成专案任务」。

就好像货运公司徵求货车司机时会要求「会开货车」一样。

但在资讯工程来说，任何技巧跟实际需求之间总是有段很大的鸿沟与落差，就好像「会开货车」跟「把货车从各种起点开到各种终点（还可能要在各种时段与路况下）」之间的鸿沟与落差一样。

所以如果货车司机会开车却不会认路？那自然一样无法把货送到。如果工程师懂的很多技巧，但却不懂的把这些技巧变化组合成需求的样子，那......
（这件事情复杂的程度远超越上面这样简单的文字，前面几天的文章也介绍过「光是专案的规模扩张就可以让程序在特定平台上变成无法预期的样子却又始终找不到原因去控制跟排除」。
所以......这篇文章不是要讲「工程师要懂的去解决技巧跟需求之间的落差」，因为那根本讲不完。

事实上，真的有些现成解决方案着重在如何弥补技术与需求之间的落差。
但这些现成解决方案如果是「已经被整合进Library」「已经有官方认证套件」「已经有GitHub使用者数百颗星认证」，那也就表示「这些方案没有特殊性」「以这些方案作为专案团队技术基础会造成专案团队的技术力没有竞争性（因为别人也会）」。

尤其，这类的元件通常都是用来完成UI/UX需求的。
这会回到之前讲「多媒体时代遗毒」的问题，但在这里用不同方式重新描述定义一下这个问题吧！

如果只是想要用美丽的UI/UX包装一项平凡无奇的东西，那这是终将被市场跟时代的产品，去负责完成这项产品的专案根本没有成功可言。（只是「完成、收钱」而已。）
如果客户不懂技术但又想追求技术，常见的策略就是经由专案团队提出的产品设计来评估「专案团队的技术能力」。如果能做的东西其实别人也能做，业务就只能藉由「低成本」「超快速」「团队随意消耗使唤」来当竞争卖点了.......

（知道为什麽有些团队永远在徵人了吗？）

但，如果团队管理者、业务主导者、企业经营者在思维上不懂「追求现成方案」长远来说注定的结果，那不是团队成员要担心的，团队成员只管「工作、领薪水、练功」就好了！（要人家帮忙烦恼这个问题，好歹先升迁、先加薪、先承诺会给对方相对权限改造组织吧！可能吗？）

既然说到练功...工程师应该要懂一个基本上跟技术几乎完全无关的能力，那就是「理解设计师」。

很多设计师的设计图只是按照客户在会议桌上提出的需求规划去按表把功能概念图一张一张画出来的结果。
为什麽？
比较正向的看法是：这样的图连客户也看得懂。
所以用工程思维去思考「这个APP的每个功能标题有个类似的框架，我现在要把这个框架画出来，」「这个APP的每个功能都有个类似的副选单，我现在要把这个副选单的轮廓与运作逻辑画下来，」可能对设计师来说就不是那麽有用的一种工作策略。（没人喜欢专案领导整天跑来找自己吵着要「可以拿去跟客户展示的工作成果」。）
所以这种工作变成要工程师在看到概念图後自行吸收完成了！

看到设计图时，工程师要能快速判断「这个设计师构思了某种会被重复大量运用的风格」，然後将它元件化模组化，好快速大量应用。

但，很多专案的常态是：根本需求还没完全敲定就要开始施工，已经施工完的功能又经常会被推翻，後期完成需求并进行规划出来的功能又经常跟前期的功能在风格与逻辑上完全不同。
这基本上无解，除非设计师愿意接受工程师的抗议後并收回设计图重做。（不要被我吓到，因为愿意这样做的设计师其实并不在少数。所以工程师们先别绝望，只是要能掌握到专案团队的运作模式，「发生这种事情工程师要尽快反应。」）

但这里藏了一个陷阱......（准备回头骂Google。明天吧。）