需求分析和变更管理

制造工厂内部的IT应用系统开发（一般的ERP项目）是否能成功很大程度上取决于“需求分析”的质量好不好。

在一个不是很IT的组织里就像我们制造工厂的IT部门，要想做好“需求分析”是很有挑战的，就像要“写出好的代码“一样有挑战性。

老板在催上线，老婆在家等吃饭！谁还管你，需求分析的好不好，代码质量高不高，总之先上线一版完成任务！

噼里啪啦一天天，回头一看全是坑啊！需求不顺，流程有点扭，代码里全是陷阱！夜黑风高夜，全是救火的干活！

被自己被别人坑了这么多年，坑里生死几多回，才明白，老板所关心的”业务要求“最终还是会落在软件的质量上，而软件的质量最终还是要依靠“做好需求，写好代码”来保证。

需求分析不是谁都能做的，不是想做好就能做好的，就像”写出好代码“一样需要任务的历练！

最初两年我做系统设计和程序编码做的很顺，因为前面需求分析做的很好，文档描述准确，流程合理、顺畅，系统边界定义很清晰，人员角色的定义符合业务要求，数据字典定义统一没有歧义，分析师可把握全局有原则知道什么需求在什么时候可以改，最终要不要改。

但是后来需求分析师做了我的老板，自己不干活了，招了个刚毕业的同学做需求分析，从此我们的苦日子来了，各种别扭，用户反映写出的程序不是他们所要的。

麻烦大了，才发现不是简单按照需求文档的格式写好文档，需求就能做好的。从此之后需求分析和系统设计的界限开始模糊我们直接和用户接触，自己做需求分析，系统设计和编码，新的需求分析师就做文档整理，程序更新和源代码版本管理。

于是我们就开始思考这样的一个问题，谁可以做需求分析？如何做好需求分析？

我们先来看看需求分析师面对的挑战：

从不同方言的业务人员口中，总结出全局统一的数据字典并合理编码。

接触不同的业务人员结合组织架构和岗位设置从中整理出合理的职位角色。

从纷繁复杂的利益纠葛中，梳理出清晰合理的流程。

从不同的业务表单中整理或者重新设计出符合“系统要求”的表单格式。

对关键流程关键业务功能点的前置条件和后置条件要清楚明了。

最后最重要的一点，要有原则，知道什么需求能改，该不该改，不能因为需求提出者位高权重或者美貌如花就丧失原则！

需求分析师不一定要会写代码但是“心中一定要有码”，要知道物料编码的通用原则，数据的一般类型和取值长度，知道如何使用编码来明确区分出唯一笔业务数据。要有全局概念，可以产出全局统一的数据字典，你不能弄出个同样的业务概念在不同的子系统里数据名字和格式不统一。比如订单管理系统里中的规格描述是长度1，长度2，到了仓库管理系统里就变成了长度min和长度max，这就是大错，严重的前后不统一。

了解了需求分析的主要工作，那么谁可以做需求分析，需求分析有哪些产出就不言而明了。

如何做需求分析是一个因人而异的问题，只
4000
要你擅长和人打交道，会根据需求产出的要求提出问题，引导用户回答问题，从用户的表述中提炼出有用的信息并得到用户肯定，这是一个很厉害的本领，只有靠经验积累，经历任务历练才成。

当新系统上线运作后，如何对管理好需求变更也是分析师的主要职责，可以参考我们的需求变更流程图。



总之要做好需求分析和变更管理就要求分析师一定要：

（1）有全局意识，了解统一的业务流程和组织、职位角色设置，全局的数据字典，唯一的数据编码观念等。

（2）善于和不同的人打交道，会提出关键问题，会分析和提炼信息，形成观点和概念。

（3）要有原则，知道什么可以改，什么不可以改，什么时候改，由谁来执行等。