12
0在讲需求的事情之前，先说一个事
今天早上过早，我和娃去吃面。后面来了一个女的，声音嘛就很严肃像班主任吵架似的。
老板说吃点什么啊？
她就开始跟老板说需求了，“两碗粉，一碗要那种长的宽的，一碗要那个粗的圆的，粗的圆的那碗要多煮一会，煮软一点，多煮个半分钟。然后长的宽的那碗，要一勺半的辣，圆的粗的那碗要半勺辣……”
大概叨叨叨了有一两分钟，粉都已经好了。
老板往桌上一放，
“我们这里的调料是自己加的，在调料台上。辣椒，葱花香菜都有，自己加。”
我当时在旁边听的时候就感觉，我是绝对记不住需求的，卖粉的大姐记性也不好，不像能记住的样子。
有这么一个段子：一个人去吃牛肉面，跟老板说“我要一碗牛肉面，细面，肉多点，面少点，面要煮得软一些，少辣椒，别放醋，汤多一点”，老板说好的，回头给后厨喊“一个牛肉面！”
职场的话，场景应该是这样的。
产品经理说了一大堆要求之后。
程序员回答：你写个详细的需求文档过来，我们照着做。不用跟我在这说了。
结果就是，没有个体和互动，全是流程和工具。其实这样也不符合程序员的利益，我读一万多字也是成本呐。干点有意义的事情不好么。
老魏说，也不是这类人故意使坏，而是收到的培训/工作环境告诉他： 产品/设计/开发/测试是严格瀑布的，每个阶段要产出“高质量”的本阶段交付物。而且倾向的协作方式也不是交互，而是你产出我验证和使用。
兰斯说，绝对不要也不行，讨论有些是没想好的，落笔更确定一些
老邓就是理性的科学派，不用说那么多，就是你是否认可：可工作的软件重于面面俱到的文档 这个价值观。
我们都知道软件开发，很多时候，需求就是很复杂，就是需要讲半天，并不是一句话能说得清楚，如果写文档，也不一定写得清楚，又搞得文档一大堆。
那么这种复杂需求的情况下，到底该如何处理呢？
我来使用解构的方法，看看都有哪些模式，我们团队可以选择适合自己的模式来处理。
解构需求沟通：
所以，当需求本身就非常复杂的时候，
模式一：我要当面仔仔细细地给你说清楚，你得记好，我可是跟你说过的呀！
模式二：别说了，详细的文档写过来。我们按文档的做。文档错了就是你的锅，没按文档是我的锅。
模式三：分层细化
模式四：使用工具：建模、ER 图、架构图、用户故事地图等
模式五：边做边改
模式六：来来来，你这么会说，你来做！
模式七：这个需求太复杂了，不做
模式八：我们先做个简单的，告诉我能不能用
模式九：来来来，你坐在我旁边，我们结对一起做。
这么多种模式，总有一种适合你的团队。
但我们往往不是只采用一种模式，有的时候经历是这样的：
需求来了，
首先是 7 ，能不能不做呢？回答说不得不做。好吧，你讲讲
然后 1，等等我已经被说晕了，要不写个文档吧？
然后 2，文档太复杂了……这么多
然后 3，先说说最核心是干啥
然后 4，我们用工具试试分析一下，画个图。
然后 5，好大概懂了，我们边做变改哈
然后 6，没耐心了，你这 tm 成天改，你这么会改你来做
然后 7，这么复杂，要不算了吧
然后 8，不能算，要不做个丐版的？万一可以呢？
然后 9，最后几天了！没时间了！要死人啦！你别跑，我们一起搞！要死一起死
虽然是玩笑和段子，但也是经常发生的。
老方说：我们总想以一种完备的状态完成工作。敏捷告诉我们要实时反馈与调整。但是落实的时候，又因为一些主观、客观因素导致协作失败。最终就开始自我保护模式。
其实的确，敏捷所说的，个体和交互大于流程和工具。原则上是非常正确的，落地的时候需要打补丁，也就是通过很多实践来纠偏。
其实很多敏捷教练就应该做这些打补丁的活，但是很多敏捷教练不认为敏捷需要打补丁，或者说很多敏捷教练没有能力打补丁，导致了很多敏捷团队交付的问题。
风诰说，所以敏捷教练 = 补锅匠么？
我说，敏捷教练就是那个把窟窿抠大的那个人，然后你就不得不去认真补这个窟窿了。
