|
需求从业者的困惑 先说说很多软件需求从业者的问题或困惑 菜鸟： ▎一听到用户需求就想到对应系统功能设计 ▎一接到需求就陷入实现细节讨论 ▎头脑只有功能、页面、按钮、表、字段，搞得用户也学你变成半个IT，最后用户教你怎么做设计 普通： ▎听说过统一建模语言（UML）这类专业的需求分析工具，一看有13种图，明天再说吧 ▎接到需求，会先询问用户在什么场景遇到什么问题，再考虑方案——热心点的，往往成为用户的“好朋友”（尽力满足用户需求），但往往做了一堆低价值的功能 专业： ▎对市面上常见的分析工具都有过一定的学习，课听了，书、文章也看了不少，知道工具有什么用，但在实践中发挥不出其神力 ▎用户提需求时，从用户的言语间能抓住哪句是目的，哪句是他想到的手段，哪句话可能有其他忽略的价值或大坑——用户和你一聊，有出现聊嗨的，用户惊叹原来有这么多自己原来没想到的；有出现聊不下去的，用户甩出你按我说的做就好，哪有那么复杂（你驾驭不了场面） 问题出在哪？ 软件行业从业者，特别是开发团队，常常会陷入一种尴尬的境地：一个项目/产品做了一两年都还看不到边，什么时候是个尾？伴随而来的是今天推翻昨天的设计，明天改今天的代码。紧接着团队成员开始彼此有意见，甚至团队出走 据统计，大概只有30%的软件项目成功开发完并顺利上线。大家70%的努力都去哪了？ 从软件全生命周期管理来看，软件开发是一项包括需求捕捉，需求分析，设计，开发，项目管理和测试的系统工程。 我们可以一眼明了：需求捕捉，需求分析是龙头。前面一错，后面步步皆错。 在产品经理国际资格认证里对产品经理（需求从业者的另一种称呼）和项目经理的工作有个生动的比喻：产品经理是母亲，负责把产品这个孩子从怀孕-生产-养大成人；项目经理是助产士，负责产妇在生产环节帮助胎儿顺利落地。 大概有3个原因，导致软件需求精英缺乏 学校/社会教育薄弱 学校没有专门的软件需求专业。大学常见的专业是计算机科学，软件工程。职业教育类主要课程是各类语言开发，网络技能。 职场就业欠佳 小公司，往往老板就是第一需求负责人，老板掌握了全公司最多、全、有用的信息，按老板说的，再找一个懂技术落地的开发负责人，就搭伙开公司了。 小公司占了所有企业的大部分，需求从业者的需求量有限，得到锻炼的机会少了，诞生精英的几率也低了 入门到精通，可遇不可求 互联网创业热后，市面上催生不少产品经理。但就像俞军说的：P7级别及以上的仍然是一将难求。 高阶产品经理，从硬件条件来看，涉及多个学科/岗位知识：心理学基础、经济学基础、软件工程、设计、管理学基础、企业运营实务… 从软件条件来看，似乎更玄了：如果没有一定价值判断、偏执、自我纠偏能力，基本做不出什么有价值、创新的东西。 进入社会前，没有成熟的教育体制 进入社会后，一方面没有好的锻炼环境；另一方面从入门到精通，没有很硬性的衡量指标，更像人文艺术类，个人天赋、意愿、悟性占很大成份。 软件需求是不是玄学？ 上面这一分析，估计有人会更困惑：软件需求是不是玄学？ 如果要达到俞军说的P7以上的资格，有可能是玄学。 但一门学科之所以能成体系，就一定有相关教材，有学习的路径。如果我们以专业+级选手为对象，软件需求还真不是玄学 需求捕捉： 翻开各种调研工具的书，有非常多、详细的调研方法、流程。一开始我们可能只知道每个工具的优缺点，注意事项。随着在工作中实践，你还是能找到调研的套路 比如：多关注用户的目的；判断一个需求的影响度、发生频率；找出需求干系人，对其重要程度划分等。 需求分析： 分析是在准确捕捉需求后，进行需求的价值判断、投入产出比分析、业务到产品转化设计。 已被广为流传的有统一建模语言（UML），大众普及的有跨职能流程图，产品经理常用的有功能结构图、功能流程图、页面流程图。 既然有成体系的知识、方法，那么软件需求就是门实实在在的学问。不同人面对同个需求，虽具体落地设计可能有差异，但应该有趋近的解决方向。 铺垫到这，差不多了。进入今天的神作介绍 神作介绍 今天我要介绍的这本专业书籍
看完后，意犹未尽，马上又顺藤摸瓜去了解作者
以上可让有兴趣的朋友自行去获取想要的其他信息。 先说框架 下面放上我读完本书，整理的一张图（阅读顺序从上到下，从左到尾） 注：本书面向B端类需求分析
1、面对复杂的B端业务需求，第一件事要考虑对业务进行划分，作者在书中提出内部管理需求可按业务职能划分，外部服务需求可按产品/服务划分。 举了例子：一个体检医院管理系统，可分为体检业务、客服管理、物资管理、财务管理这几个子系统。 2、子系统间通过业务接口，实现服务提供和调用的关系。降低系统耦合度，实现互联互通。 3、信息系统的核心是支持管理，管理的核心是通过业务流程事前规避风险，通过规则和审批事中控制风险，通过数据分析做事后优化、迭代。由此引出了中间的功能、数据主线 4、数据是需求人员和技术人员的工作分水岭。一般来说，需求人员提供相关功能及页面设计需求；技术人员拿到需求后，分析完页面内容，就会进入数据库设计。 作者在书中提出通过类图来呈现数据。建议从业务角度读类图 如下图，可以这么介绍：一个客户可以下多个订单；每个订单有且只有一个收货人；订单由多个订单项组成；每个订单项代表一种产品；一个订单可能涉及多个供应商，因此需拆成多个送货单；每个送货单由对应供应商执行；每个供应商为网站提供多种产品。
有余力的需求人员可以通过类图助力开发完成数据库设计。 5、冰山以下是很多用户忽视的质量和运维需求，比如软硬件、网络要求，日常运维需支持的可配置项，监控运行要求等 很少看到有人能将UML的各种图放到各合适的阶段去运用，并能做到不为了讲工具而运用工具。 再举细节 1、方案级需求和问题级需求的区别 做好软件需求工作，业务驱动需求是核心。传统的需求分析是站在技术视角展开，关注的是“方案级需求”；业务驱动的需求是站在用户视角展开，关注的是“问题级需求” 领悟：理解这段话，你就能克制自己一下子就进入解决方案讨论的冲动。方案设计是需求人员的事，不要让用户代劳。 2、以用例之名，行功能分解之实 在实践中，经常出现“以用例之名，行功能分解之实”，用例的精髓在于用户视角，在于业务场景，要求你不再关注系统提供什么功能，而是用户在什么场景下需要系统提供支持。 用例就是一个用户的具体使用场景，一个相对独立、可暂停的场景。 比如你不会在搜索引擎输入关键字就离开，因此输入关键字不是一个用例。 领悟：我们看到很多方案中的用例，与后续的设计与开发脱节。好的用例图能指导后续的角色权限、角色系统动作等设计。用例图的读者是系统用户（他们对自己做什么最熟悉）。 3、质量需求中的假大空描述 “高扩展性、高弹性、无故障时间2756小时、所有查询均在7秒内相应”，这些词在技术要求中常出现，写的人是拷贝的，看的人是略过的。作者提出破解之道： 通过逆向思维、场景化描述，避开使用这些词被提问时的尴尬 如果真能读懂、运用好本书内容，应该就达到这里说的专业+级的水平。 今天信息量比较大，再次墙裂推荐对需求分析有困惑、感兴趣的朋友，值得买一本纸质书来逐字阅读。 就单单书里的例子，已经值回十倍书价。 更多好内容，干货请持续关注下图公众号 |
|
|
