或网上看了无数博客文章、技术视频，或购买金装版本技术书籍，看过无数原理原则、各种各样经典方法论，真正在实际开发工作中，本能去遵守和执行的又留下多少呢。

        启动一个新系统时，我们可能还会去花些时间遵循这些原理原则，采用这些软件分析开发方法论，之后漫长的二次开发，一次次叠加新功能新特征，我们还会本能去执行吗？

        我们是不是特别反感主管或业务部门要我们给一个工时估算和发布计划，喜欢做到哪里是哪里，按时上下班，谁都别来催我们。

        年轻人靠聪明编程，随时想着技术；年长者靠经验编程，以前本能怎么干就怎么干；还有一部分想着下班编程和想着周末编程，心思基本不在编程上；我就喜欢想着周末编程，周末去野外风景区徒步，是一件多么开心的事情啊。

        言归正传，我在日常工作中喜欢用哪些方法来做需求分析呢，也就是有哪些本能使然的东西，而不是别人逼迫我做的东西呢。

        

        一般我们的需求都是经过产品人员整理的，写到一个任务单上，文字是大段大段的，未必很有逻辑，但确实比较详细，对哪些天生不喜欢看文字的人，是一个折磨，但是需求如果不详细形成文字，以后可能说不清楚。

        对这样的任务单，我总是不厌其烦地详细逐条阅读一遍，从中提取有用的信息，一遍不行就再阅读一遍，反复琢磨文字。

        如果有Axure或类似Axure软件设计出来的产品原型，我也会同时仔细分析产品原型图和备注文字，特别这些备注文字需要结合原型图来认真分析对应，把客户的意图搞清楚。

        总之，就是要认真仔细阅读分析，揣摩别人的意图，到底叫你做些什么。

        然后我喜欢简单采用敏捷方法论提出的需求管理方法：

        1）Epic-写出项目的愿景目标

        客户的业务目标到底是什么，他们想要怎样的一个东西，为什么要这个东西，有什么实际价值，解决了用户什么实际工作问题。

        最近，在技术会议上听到一个小青年说：他们叫我做什么，我就做什么。

        在平时二次开发过程中，客户提出一个需求，我们基本上也是几个人两周左右的工作量，其实都算不上一个小项目，但我喜欢用项目来称呼。

        2）Feature-写出功能特性

        这个所谓的项目，有多少个功能点，我们必须清晰地列出来，这些功能点都是同一个级别的一级功能点，不要从技术角度去看问题，要从用户角度去看问题。

        这些功能点列出来之后，这个项目的内容就可以用一句句话来描述清楚了，这也是我们对任务单里一堆或有逻辑或没逻辑的文字做提炼而得到的，这不正是我们中学语文里要求的阅读理解归档总结能力么。

        3）Story-写出一个个用户故事

        就是二级功能点，对一级功能点进一步细化，使用的分析方法还是一样，还是一样不要去从技术角度思考，多从业务角度思考有哪些功能点。

        4）Task-写出一个个具体任务

        二级功能点进一步细化，我们不叫功能点了，叫任务，任务的内容小到可以具体执行了，我们可以估算工时了，这种任务最好能在1天内完成。

        不是说敏捷管理方法提出4级，我们一定要死死按4级来执行分析，项目很小3级也可以，项目大一些可能需要5级，反正分析到最后形成具体任务，所估算的工时不能大，如果一个任务需要一个人好几天的开发工作量，说明这不是一个任务，还是一个用户故事。

        把一个大需求一步步细化，在细化过程中一步步加深对它的理解，直到最后形成很容易把控的具体任务，我们还对工时估算那么恐惧和痛苦吗？

        所谓大事化小，小事化了，对于一般企业软件开发，没有使用到什么高难度的技术，使用到了也是花钱卖来，总之都不会存在技术障碍，只要我们对需求分析做好了，开发实现工作基本是可控的。

        那么，在具体需求分析过程中，我喜欢采用哪些技术手段呢，先来图：

        

        1. 语文阅读理解：最最简单的就是我们中学语文老师要求的那一套，面对一大片需求文字，就是去搞阅读理解嘛，不需要什么高深方法，80%需求都分析清楚了。

        在对文字阅读分析过程中，一个重要工作就是发现隐藏的功能点，毕竟市场人员和产品人员的逻辑能力不是那么强，常常就溜掉了一些需求点。

        2.  头脑风暴：有时可以拉来几个相关人员，集思广益进行一通头脑风暴也是可以的，不过与会者要有那个心，常常很多人被通知来开会，都是朦朦胧胧来被动听一下的，真正参与积极讨论的有两三个就了不起了。

        3. 回访：如果我对任务单里的文字存疑，我喜欢直接去问市场人员，那个直接跟客户打交道的人，问他一个个问题，听听他真实的意图。有时我喜欢把自己理解讲给他们听一下，看看我讲的东西，他们是否听得懂。

        4. DDD:  DDD就是领域驱动设计，这一套讲得天花乱坠，对于我自己比较入脑的就是限界上下文分析手法，但是这个名字怪怪的，本质就是找边界，平时我们讲的要高内聚低耦合，不要把不相干的功能扯在一起。

        5. UML：我最喜欢用的就是UML来做需求分析，上面两幅图都是UseCase图，需求分析不用什么高大上的工具，用UseCase图来做就够了，文字描述清楚，层次界定清楚，一层层分析下去，一般的需求都能表达清楚。

        纸上来得终觉浅，绝知此事要躬行，逻辑严密的各种方法论如果不能在实际工作中本能地去执行，实际工作中一忙碌就不做任何需求分析，不做工时估算和工作计划，做到哪里是哪里，还不如保持一些不那么严密的方法，每次都能做到，而且很熟练，花费的时间很短，几乎不影响工作进度，不是很好么。