最近带头做一个项目的需求。带的是两个参加工作半年的小朋友，他们之前一直在写代码，处理一些项目上的功能修改、日常维护的工作。
这次的项目是基于一个旧系统，采用新的开发工具完成新版开发。
一、对旧系统的功能分析
这个系统的业务是这个团队所不熟悉的，由于开发团队是异地的，旧系统在企业内网，异地的开发团队不能访问，因此需求分析团队决定采用原型工具将旧系统的功能扒一遍。因为旧系统也不能提供任何文档。
这件事情就交给两位小朋友去干。中间过程让他们把自己的成果进行演示讲解。要求他们在讲解的时候要带入角色、应用场景，而不只是说这里有个xx功能。
经过两次练习，后来他们在讲解的时候都能够说出每个功能是什么角色去使用，但是对于一些功能在什么场景下应用，这个功能的意义还是说不清楚。
但总体来说，通过他们连续三天的工作，将旧系统的功能和使用场景分析得基本到位了。
二、新系统功能设计前的准备
用户写过一份需求文档，对功能有些概要性的描述。从文档来看，并不是照搬旧系统。之所以要去对旧系统做一次完整的分析，是因为我们在阅读新系统的需求文档时，发现只能建立一个大概的脉络，并不能建起整个系统比较真切的功能架构来，感觉就是悬浮在空中。如果没有旧系统，那就会是找到用户，讨论各个业务流程、功能的详细含义、数据项等等。
现在发现通过对旧系统的分析，已经能够建立起一个全景的故事地图了。
上午跟两位小朋友说，今天下班前我们要完成一次讨论，开展新系统的功能设计。为了完成这次讨论，我试图提前梳理下系统脉络。
但最近几天一直有种心慌的感觉，总是静不下心来，尝试用流程图、线框图，却都画不下去。最后发现采用“用例”的形式，居然很快速的将核心业务的用例描述了出来。所以需求分析也不一定非得是“用户故事”不可，用例图仍然是一种有效的方式。
三、用户故事工作坊
4：30，开启用户故事工作坊之旅。
找了些即时贴，白板笔，开始吧。
跟两位小朋友简单讲了下，要把想到的“故事”写到即时贴上，贴到自己认为的位置。
但因为大家都没有经验，还是有点手足无措。
我只能自己动手，然后两位小朋友也开始动手。但他们可能还是不太习惯，经常是嘴上提出一些想法，可能在没有得到“领导”确定之前还是会迟疑要不要贴上去吧——我也算他们的领导。
但总之，我们不再是坐在工位上，只对着屏幕或空气讨论了。我们更多的是站着，有时候在白板上画一画草图。两位小朋友也能提出有见地的意见。
经过两个小时的讨论，我们梳理出了新系统的核心骨架。
然后让两位小朋友基于这个核心骨架和旧系统的数据属性，去继续完成新系统每个功能的原型设计。
