不足的丰富资源

未依团队性质配置的资源，会制造资源不足的假象

在IT团队最大的时候，有11人，分别是前端工程师3名、全端工程师2名、前端实习生1名、後端实习生1名、UIUX设计师1名、AI工程师2名和我，暂且先将职务内比较迥异的UIUX、AI工程师和我先忽略，7位工程师这样的职务配置方式，先不提Scrum，在BAU的任务安排上，就已经造成很大的限制：配置任务有绝对的分水岭，必须依据前/後端来进行安排，在我们的IT业务中，BAU中，属於前端的问题和属於後端处理的问题比例并不对等，发生时间点也不一样，造成闲置人力的可能性增加。那时候，对於职务配置并不敏锐的我，沿用着资深工程师的想像，配置了一组团队各功能员额，分出前後端、还要SDET，这样的配置并不适合需要高度协作、补位的新创团队，而造成「IT团队人力资源永远不够，而对整体事业体来说，IT已经是大单位」的现象。再者，从管理的角度来说，人力运转率应该是要一直被观察的指标，在安排实习生执行BAU上，虽然有划分前端与後端实习生，但前端实习生所取得的任务中，也涵盖後端实习生的部分任务，显示在职务配置的设计上有根本的问题，这样的讯号也被我忽略了。因此，光是从BAU的视角来看，我犯了两个错误：1. 以大公司的团队设计思维，套用在新创团队；2. 忽略管理指标的讯息，没有查找出根本原因。现在这样说有点马後炮，但是这是我们自己团队会说的，防线一路失守，该做好的环节没做好，到後面可以拯救的环节，也跟着也被放弃，保持高度警觉和不要太容易放过自己，希望不要都是用失败经验让自己深刻。

减少换位补位障碍

人人都可以做，资源弹性最大化，才能敏捷

为了将Scrum运作顺利，公司曾安排让我们徵询具有丰富导入Scrum经验的讲师，Scrum是种文化、一种心态的体现，这位讲师举手头足之间，都透露着Scrum已内化成他工作方式的一部分，当时的我，只能闻其形，但不明其意。在和他初步说明一下人员配置之後，他点了一下我，Scrum中的团队补位的精神，「在Scrum里每个人都有其擅长的事情，但是里面的任务，是每一个人都能做的」。基於此，所以在人员配置上，已经很不符合Scrum的精神了，对於执意继续进行Scrum的我，讲师可能心里觉得很无言。在我们这样的人员配置之下，Scrum的进行出现了2个障碍：

• 前後端无法相互支援
  前後端之间，存在必然的先後关系，这个先後可能是职务上设计的後端为先或前端为先的决定，也有可能是某端能力不足造成的先後，在Scrum运行时，如果发生问题，因为人力资源的弹性受限，最後只能两手一摊，落後的人觉得压力大，赶不出来，接棒的人也受影响，想到我竟然让这样的事发生，我真的是觉得害怕。
• 习惯性以功能分工
  因为用前後端分，所以整体团队思维也变成是如此，当有新的需求的时候，例如：QC，大家的第一个反应都是要直接切割一个个体去专门处理这件事，就像BAU一样，QC的性质又不同，不是同时可以排程的项目，又会在Scrum内拉出一条先後顺序的产线，越变越像瀑布式开发。

Reflection

我可以体会讲师并没有全力阻止我们硬要用这样方式运行Scrum，因为Scrum是一种文化，要如何被落地实现，依据不同团队，就会有不同的可能，然而，这一路新创走来，我知道所要面临的变动性与挑战实在是太多了，所以尽可能减少障碍，会是第一要务，不要硬要为自己「制造挑战」，所以，若要再来一次，我会选择都配置一种类型的职务，让彼此可以相互支援。