【Day29】谈谈软件工程师 - 8 大战略角色及 7 大能力对应的 26 项指标 (3) 案例分享

30 天 redesign 心目中的 LINE 的章节已经结束罗，有兴趣的话可以点此看看总回顾，现在开始进入番外篇，分享从事软件业的经验与体悟～

在这留在公司加班等测试的此刻，似乎很适合编辑铁人赛的文章呢。

延续前两天的话题，今天来聊，在了解工程师特质後，如何将这些理解带到真实世界，提供相对应的安排与协助～

首先，我觉得自己很幸运的地方是，所接触的工程师年资幅度之大，从 0 年(刚毕业) ~ 20 年以上都有，所以算是有很丰富的素材可以观察与学习。

这边先分享一个心得是，以我自己的了解，工程师的年资、开发能力与管理能力，没有绝对的正向或负向关系，而与个人的个性特质及工作动机比较有关系～

当然不是每个人都生来会管理、带人，这些都是需要学习的。但是有些工程师，至少，我遇到几个厉害的工程师大大，如果可以选择～他们会比较喜欢单打独斗。这不是说他们排斥团队合作哦，如果新人遇到问题，去请教对方的话，基本都还是很愿意回答。只是就比较没办法不擅长手把手带领（守护者除外）。

再举例来说，如果今天要冲短期交付且不能 delay 的新功能，一般就会安排有数十倍战斗力的战士去处理。

其实我们都明白开发很难没有 bug，只是如何减少。那在快速交付（基本上是每周交付）、且系统越来越庞大的过程中，其实会累积很多技术债，有些技术债很可怕的地方在於，bug 会出现在你万万想不到的地方，而当那个地方是服务主流程，就很可怕了@@

这里可以举一个情境题。像这样专案人手不足，小 bug 满天飞（我们也被电得满天飞...）、除了需求规格书规范的项目，还会有其他介接相关的服务需要处理的情况下。

如果是你，会怎麽做？或是～会希望 PM 怎麽做呢？

• 要求战士重构程序码？
• 忽略技术债？
• 还是直接让其他工程师接手处理？

Image Credit: Unsplash

如果是我，在开始解题前，会先厘清...

• 当下的目标是什麽？
• 当前目标是优化，还是交付？
• 我们是否清楚客户期待值在哪里？
• 哪些属於一定要先完成的主流程，哪些是可以後续再持续优化的流程？

再去思考...

• 身为 PM，当 bug 已经不可控，这样的交付还是交付吗？
• 而又如果，让一天产值高於其他工程师数十倍的战士花时间重构，有符合成本效益吗？
• 这时如果直接安排其他工程师接手，会不会让战士有不舒服的感觉？
• 话说，真的多的人手可以协助处理吗？

当时的案子还有弓箭手、传道士与守护者在这个案子。先回顾一下......

1. 守护者：技术强，适合担任团队的技术专家（在此案例资历最深，与战士同样有高产值的表现）
2. 传道士：沟通强，性格及开发品质皆稳定（在此案例资历较年轻）
3. 弓箭手：态度正、重思考（在此案例资历较传道士轻一些些）

我们当时的做法是...在不影响原有交付项目为前提...

1. 安排弓箭手先发展技术服务相关工具，在工具出来前，由战士与传道士做掩护、由他们消耗外来的服务需求
2. 待工具发展完成，由传道士与战士沟通，了解战士原有的逻辑，再由传道士设计并进行重构。传道士重构时，换由战士与弓箭手掩护
3. 最後... 当然就是好的结果啦！详细也可回顾前面的文章为什麽优化工作流程，不只可以改善工作效率、还能做出更有价值的产品呢？

顺带一提，这也提到资源分配的哲学。那就是，从进度条来看，20 个完成度 65% 的待完成事项（功能繁复但还无法让 end-user 使用），比不上 5 个完成度 80% 以上的项目（功能精简但运作正常）

所以我们的做法，就是视情况集中火力、再偶尔各个击破、分头进行。

PS 感谢我的好导师，也就是我们的团队守护者。总放手让我尝试，但又能在需要的时候，在团队面前表达支持、并给予非常实用的建议，真的非常感谢：）

PPS 上述，不代表至此之後我们的专案就没有 bug 哦（I hate 测试），只是透过种种方式，有效降低同仁 23% 工作量、以及让曾经的主流程 bug 消失不见罢了 :D

今天就到这里罗，谢谢你的浏览～这次的铁人赛剩下明天最後 1 天！很开心这段时间有大家的陪伴。如果有任何指点与建议，也欢迎留言交流哦～～

我们明天见：）