需求分析应该具备的咨询意识

张靖笙

     需求决定企业信息化项目的成败，好的需求分析的重要性是毋庸置疑的；而同时需求分析也是一项比较困难的工作，我在工作中见过很多形形色色存在各种缺陷和问题的需求分析成果，看到过双方都面露的难色，两边都有朋友向我发出过类似的疑问，到底有没有行之有效的需求分析方法，可以让这些需求分析工作能更有成效？

     我们通过百度百科查“需求分析”的定义:“需求分析也称为软件需求分析、系统需求分析或需求分析工程等，是开发人员经过深入细致的调研和分析，准确理解用户和项目的功能、性能、可靠性等具体要求，将用户非形式的需求表述转化为完整的需求定义，从而确定系统必须做什么的过程。”笔者在近三十年前考计算机软件水平考试的时候学习《软件工程》就学习这个定义，根据这个定义，需求分析工作责任方在软件开发人员，我相信所有的软件从业者都是按照这个定义来开展工作的，而经过了近三十年了，为什么我们还看到需求分析工作这么多不如人意的地方？

     信息系统需求的场景是多种多样的，需求分析的方法当然也有很多的，每种方法都有其合理性，可惜也有其局限性，能跨越不同的场景和环境约束而包治百病的方法是没有的，而在方法之上，我认为更为普遍的缺憾，是缺乏更具普遍意义到底为什么要做好需求分析工作的意识。意识之于方法，可以类比做事情的思维之于手段，我们做事情，手段当然是要有的，而如果没有正确的思维来指导，很多时候要么不择手段、要么毫无手段，功利加浮躁心态的作用下，很可能让我们做需求分析工作缺乏必要的远见和格局，常见的需求分析工作缺乏良好意识的表现为：依葫芦画瓢的技术翻译型、头疼医头脚疼医脚的问题倒逼型、见招拆招得过且过的敷衍过关型、事不关己高高挂起的本位思考型、只见树木不见森林的一叶障目型等等，这样的需求分析工作方式下能输出的质量能高到哪里去呢?

      再来回头看看“需求分析”的定义，“经过深入细致的调研和分析，准确理解用户和项目的功能、性能、可靠性等具体要求，将用户非形式的需求表述转化为完整的需求定义”这样的表述就隐含了给软件项目实践带来巨大隐患和问题的假设------“用户要求的都是对的”，开发人员很多时候费老大劲也没搞清楚一个问题，用户讲出来的可能不是他们真的想要的，或者并不是他们真的需要的，当然很多时候这造成的后果也是用户自己埋单的，毕竟通过后面一系列的文档形式化和白纸黑字的签字形式，用户也只能自食其果，但明显这并不是双方都追求的理想结果。

      笔者也是从IT码农一步步成长为咨询顾问的，根据我多年从业经验的观察，开发人员其实并不缺乏有效的需求分析方法，而是脑子里缺了一条弦，就是很多时候影响用户比分析用户的需求沟通更加有效，甚至更加重要，这其实是一种咨询的意识，而非分析的技巧。所以，相比于需求分析的方法，我更愿意先谈谈做好需求分析工作所应该具备的咨询意识，或者换句话讲，我认为好的需求分析工作的意识，其实就是咨询。

       首先站在业主用户的角度，我认为在需求分析阶段，用户有时候更需要的是咨询，而非你问我答的被调研和被分析，好的需求表述有一个前提，就是用户对于未来系统的使用场景有非常清晰的认知，这个在常见的家居装修中是可以做得到的，毕竟家装的业主用户往往已经有很丰富的生活体验，当然能说得清楚他或者她的生活习惯和生活品味的要求，而软件的使用场景却大为不同，我们常常无法在项目早期仅从一些直白的用户界面(UI)想象中完整地勾勒出对用户将来工作方式带来的变革和影响，一些大规模的软件系统的实施还会带来组织结构的调整和制度变革等复杂的问题，我在近年来很多工作中看到的场景是，用户更希望开发人员先告诉他们同行的用户是怎么做的! 这明显就是咨询的要求，而非被调研和被分析，如果开发人员无法在需求分析阶段给出好的建议，勉强从用户口里挤出来的需求质量可想而知，后面的需求变更和开发返工就无法避免了。

       其次站在开发人员的角度，没有咨询的意识很容易导致“用户说什么就是什么”，所谓的调研和分析成为了依葫芦画瓢的技术翻译说明，往往的套路是输入界面-处理算法-输出界面(IPO)这样功能导向的需求描述，对于开发人员来说，需求就是将来的软件系统功能、性能、可靠性等具体要求，如何满足这些要求，就好像家居装修的施工队，往往在无须对业主用户的生活习惯和品味感同身受的情况下完成要求的装修工作，正是由于缺乏将心比心为用户体验操心的意识，当然也就无法输出超越业主用户体验需求的高品质成果。而正如前文所言及的，很容易成为专家的家装业主用户很容易解决这个问题，而缺乏IT专业技能的信息系统用户却无能为力，所以开发人员听到的用户需求很多时候并不是他们真正想要的。

      好了，如果大家认同笔者的观点，那么我可以分别对业主用户方和软件开发方给出一些策略上的建议。

      对于业主用户方，学习型组织是奠定良好需求的基本功，知识管理和善用行业前辈实践经验，不要做重新发明轮子的事情，无论你遇到什么问题，很可能某人在某地也曾经处理过类似的问题，知识既可以内部建构生成，也可以从外部获取，我们要首先把项目看成一个为了达到战略目标的组织学习和共识建立的过程，需求最重要的是达成广泛的共识，只有达成广泛共识的需求才是最有生命力和最能顺利落地的需求，除了可以在项目商务合同中对委托开发的公司提出明确的咨询要求，也可以根据项目的需要在一些关键环节引入外部专家深入参与需求的沟通和知识建构工作，即使像通用电气公司CEO杰克.韦尔奇这样的传奇人物，也随时从外部搜罗最佳实践经验，在解决棘手的商业和管理问题时，需要找到最合适的顾问人选，无论是来自内部还是外部，业主用户要清晰了解自己所提出需求的局限性，关键时刻依赖外部专家的知识和经验可以起到四两拨千斤的功效，否则只能用不良的项目实施后果来补交巨大的学费。

      对于软件开发方，有意识地通过培训和行动学习计划等推动专业团队的咨询能力提升，改变IT员工原来那种泥水匠施工队的思维习惯和工作方式，根据笔者多年IT工作体会，在IT员工内心深处普遍对于自己身份角色有很明显的技术倾向，对学习业务和管理知识抱有很强烈的漠视和消极思想。他们大部分的专业技能和注意力放在了单项技术，例如具体某一门编程语言上，也可能是网络、硬件设施、操作系统、数据库的配置和调试等专项技术；而对需要更高抽象和综合分析和架构设计、沟通、表达这些方面的技能却显得不够熟练，更进一步，由于不了解业务领域的知识，严重造成了在对用户需求的理解和认识上的片面和误差。如果不扭转这样认识和角色定位，和用户的沟通交流都很难顺畅，就更别说提供主动引导用户需求的咨询服务了。

      笔者认为，为了要帮助业主用户更好地实现IT和业务的融合，IT员工特别是和用户直接交流的开发人员更应该培养咨询意识和能力，从业务需求的角度帮助用户识别和界定业务问题，业务需求的形式包括：竞争需求、组织需求、财务需求和运营需求等，如果不能准确理解这些业务需求，也就不可能解决业务问题，而一旦明确了业务问题，就可以着手寻找解决方案，以事实为基础、以假设为导向的解决业务问题过程恰恰是最好的需求分析工作方式，从界定业务问题的范围开始，把问题细分成不同的内容，然后围绕这些细分的内容能够提出初步假设的解决方案，并在与用户沟通和汇报这些解决方案中表达自己的观点。围绕这样的思路来组织和管理项目的过程中的需求分析工作，强调的是技术对业务的适用性，作为IT解决方案，应该是植根在所服务的业务领域土壤上，综合运用领域知识、服务方法论和企业架构的知识，采用开发和中立的态度选择适合业主用户场景的IT技术。当然，对于目前大多数中国IT服务和系统集成商而言，这本身涉及到其企业业务的战略转型，一两个项目的实施经验是不够的，需要持之以恒地在众多项目实践中积累自身的行业知识、咨询能力和解决方案知识，笔者朋友里也有这样的成功案例，该公司从一个实施绩效考核系统的IT实施商成为行业内提供从规划咨询、系统实施到考核执行全流程服务的领域专家，给客户提供真正整套管家式服务，这离不开这个企业领导人在十多年前的战略部署，和超过二十多年在这个细分市场上的深耕细作。

      不管是业主用户还是开发团队，跳出自身的视野征求外部建议往往带来的是柳暗花明又一村，笔者的建议是，应寻求最恰当的咨询专家提供多方位的辅导和建议，创造条件让外部专家能细致把握参与机会，参与各项项目活动过程的共（同知）识建构过程，为了确保能充分利用现有的知识和最新的知识，最后这一条尤为重要。

（本稿完成于2018年10月4日，如需要引用，请注明出处，同时祝愿中国繁荣富强）