功能与优化，请选择

如果你有约七个後端与资料库工程师，四个前端工程师，年资0到8年不等，大家合作从零开始打造这个产品，开发期一年半，已经线上运作两年，产品的市场反应状况还不错。你是整个团队的主管，怎麽面对前有市场期待的需求在排队，後有线上问题在放火的情况?

有产品在线上运作的状况，从上帝视角来看就有点像是线上游戏经营便利商店，客诉会让你扣分，等太久客人消费力会减少甚至客流量消失，新产品会让客人加分，好的动线就会有好的购物体验也会加分，如果上到爆款商品则让整个商店挤满人，然後在调整之前就进入了一个客诉的循环。

我的思维说出来可能我会发现我老板在我背後想炒了我。如果线上有可以持续创造收入的东西在线上，面对新需求与优化的需求，我会选择牺牲新需求优先处理优化的需求，让线上稳定。我会这样的选择是因为我认为要把人当人。线上出问题的时候需要燃烧大量肾上腺素，处理完後大概整天都是丧屍状态了。如果在还要在这样的状态下持续开发新功能，难保会不会在新功能中又埋下了新的BUG。所以在选择上我希望工作团队能保有最好的工作状态，以及信任团队夥伴能在好的工作状态下其实能提早把专案完成，其实最终还是会对产品是好的。

但是如果自己线上的产品才刚上线，可能还在打开知名度的过程，做法会不一样吗?我会说基本上看产品类型与看状况。产品才刚上线，通常会伴随着行销资源的投入，如果花钱把人导流到一个有问题的东西上，钱投入没有得到效益是一件事，品牌被流量嘲笑才是另外一个难以处理的问题，所以行销期还是乖乖优先修正BUG才是正途。但如果还在蛰伏的情况，或者东西并不是坏在一个很重要的地方，我建议判断功能使用率的数据来评估是否先完成手上新功能专案再花时间去修正或优化东西。

那如果是纯维护型的专案，时间会怎麽分配呢？赶快了解这些专案哪一个死掉会让你没工作(不管是政治面还是财务面)，赶紧把焦点放在上头吧。要花时间了解整个专案架构，使用资源与平常哪边容易坏掉，要能用自己的视角去把架构图画出来，常死掉的地方确定是否有足够的线索(log)，看看能不能做出警示的功能，帮自己先画出一条守备防线，在问题发生前尽可能作出应变。

但不管是哪一类型的专案，一定要提早把最重要的基础建设给搞定：部署流程。一般的工作团队应该会让大多数的工程师只碰得到git，也就是你程序码上git後，就会触发约定好的团队CI流程，以及最终让更新上线的CD流程。对我来说 CI 是工程师之间的良心，要怎麽跑都有每个团队的想法与不同状况，因此是另外一大块议题，但CD就不同了，他会是影响工程师更新过程与客户体验上的一个很重大的环节。例如後端API更新时，是否有可能会造成程序执行中断，导致个动作只执行一半难以修复问题？

在我那次美好的专案开发经验中，团队一样规划了让大部分工程师只要面对git即可，但後续不断的进行CD流程上的补强。例如不断压缩CD的时间，让该次更新结束git CI流程後，3分钟内就可以完成全部服务的更新；而因为是K8S的服务，我们也将开始部署与完成部署的通知，发到通讯软件中，让更新者知道更新进度，以便於後续第一时间检查。

因为有了这样的基础建设，不论在功能开发上或者BUG修正优化上缩短了等待时间，开发团队可以更有效率的工作。

而这样的CD环境建立，是在我们服务从零开始，还在开发需求的时候，拨出了两个较为资深的夥伴开始预备这样的工作流程，一直沿用到今天。

而回答我一开始的问题，怎麽面对前有市场期待的需求在排队，後有线上问题在放火的情况。小孩子才做选择，事前的需求范围管理，与开发中後期的测试做足，检测工具与模拟问题现实的处理SOP都做好，让这些工作都应该要算在需求开发期的时间内，自然比较少产生线上问题的临时状况。而这些传统开发工作以外的东西算进来会不会膨胀原本的需求开发时间？会，但只有初期大家不习惯这样思维的时候才会，但是当大家理解先把这类问题规划起来的时候，开发的品质无形当中就会进步，工程师就不会设计出不能维护或者资料修复的架构。

这就是堆叠每一个专案的经验，逐步累积，变成未来新专案的基础，如此循环，自然就会变成一个加速器，越来越好。

什麽？你现在时间真的不多抽不出时间？真正敏捷思维的人是不会讲出这句话的。