[DAY27] 功能型团队 VS 需求型团队

前面的篇章大部分着重 DDD 的战术设计，这篇来说说战略设计。

功能型团队

在导入 DDD 前，我们审视後发现，过去的开发项目并没有完全满足其他部门的需求，导致对於同一需求开发多次；然而，当初的规格都是按照其他部门的说明内容去开的，那怎麽还会这样呢？

举个例子，行销部门说"我想要在网站上加成就系统"，接着 PM 开始问细节，要有几个成就、页面长这样行不行等等，然後估时程、实作，实作完成後交付成果，最後行销部门说： "好像没有达到我们想要的目的"

这凸显出了，我们的团队其实是功能型团队，其他部门说什麽我们就做什麽，但有时其实他们也不甚清楚想要什麽，导致做出来的东西并不能解决问题。

需求型团队

假如连使用者都不清楚要甚麽了，开发团队要怎麽知道呢？(通灵、读心术)

以刚刚的例子，行销部门说： "我想要在网站上加成就系统"，这时候就可以追问为甚麽想要成就系统——是想要吸引新用户？还是想要让用户留在网站的时间长一点？那是不是可以透过其他方法达成目的，像是加强 SEO？

对於其他部门想要的开发不能照单全收，要抱着打破砂锅问到底的精神去了解背後的需求，而 DDD 的战略设计中就有许多好用的技巧可以达到这个目的，比如共通语言(Ubiquitous Language)可以让所有人在同一页上讨论、事件风暴(Event Storming)可以完成每个人对流程的共识等等。

下一篇会继续聊聊，关於改变开发流程，团队遇到的一些别扭事件。