项目文档|需求解决方案

        早在2014年就接触《》，平台很好，主要是潜水看大家的作品，期间虽不固定写过一些有关自己生活的文章，但大都是无病呻吟；时间一点流失，转眼间，从大学毕业工作近5年；常言道，三年一小沟,五年一大沟，一下子都跨了一大沟，回头看看不知自己这5年软件实施工作都留下了什么。偶然的机会，看到颜小婧的文章，发现自己与人差距之大的原因，故，学着将自己近5年软件项目实施想法，一一记录。

---

1、什么是需求解决方案？

        小虫工作期间方案写过很多，但大都是沿用前辈们的模板；那何谓需求，魏武挥有一篇文章《解决方案与需求》里面有些话，我很认同；

洞察需求，其实就是分辨这样一句话“更快的马”中，究竟马是需求？还是更快是需求？

创新大致有两种，一种叫所谓的“微创新”，微创新干的事都是满足“解决方案”，比如说，用一种更好的方式来训练马，让它跑得更快。而颠覆式创新干的事是满足“需求”，比如说，发明一台汽车，让人们可以有更快的交通工具。

         而需求解决方案，我觉得可以按照两个阶段去划分，一个是售前阶段，另一个是实施阶段；有过项目经验的人可能都经历过这样的感慨，售前挖了很多“坑”，轮到实施人员，光填“坑”都够呛，投入人员是前仆后继，到头来是人仰马翻；这几乎成了现在软件行业的常态；其实说这些，并非吐槽售前挖的“坑”，而是认可，售前的方案确实需要一些“微创新”，没有一点创新，如何吸引客户，没有客户，哪里来的实施，而需求解决方案就是把这些“微创新”落地。而接下来，我提到的框架，主要还是针对实施阶段的需求解决方案；

---

2、解决方案的框架

2.1 整体框架

        借鉴前辈们的经验，小虫写需求解决方案，主要分为五个部分，重要的部分就是我们一直在谈的<解决方案>部分；

需求解决方案编写框架(整体)

2.2 项目背景

       一是为了介绍客户的基本信息；目的是标识出行业特性；

       二是梳理企业目前使用的软件情况，目的是了解清楚信息化现状，界定清楚企业信息化程度，以便后续不同的沟通方式；比如信息化水平弱的，现阶段都是用手工或者Excel，后续规划及培训讲解要“粗放”一下，别太细；

         三是明确导入范围；这点非常重要，从项目角度上来看，是界定范围的时刻，框定出“微创新”哪些部分，更方便后续交付落地；从整个文案的角度来看，是承上启下的关键段落；

需求解决方案框架(一)

2.3 解决方案

       整篇文章的重点，这部分划分四类：业务表单、数据底表、功能报表、标准应用。

A.业务表单，指的是企业管理中涉及到的关键业务，这部分会有相关操作流程；

B.数据底表，这是我现在的叫法，也可以称之为基础数据，而这部分不涉及流程，更多是维护资料，主要需要明确的是权限及数据字段，这涉及到后续业务表单及报表取数的问题；

C.功能报表，其实目前企业信息管理，最后呈现软件实施效果的很大部分在于报表的展现，所以明确报表的内容及数量，也是必不可少的；

D.标准应用，现行软件大都是产品化，总有些标准功能，这里明确在方案中，有助于后续系统搭建权限的分配和管理；

需求解决方案框架(二)

2.4 实施建议

        主要是提醒企业在整体项目实施需要注意什么，比如，资料的准备，权限的划分，制度的规范，系统的宣导等等；这部分可有可无，我们写方案的时候可以酌情使用，同时，这部分的内容，应该可以适用与之后其他项目的方案撰写，写好一次，也算是一劳永逸。

2.5 实施计划

        项目开始阶段，肯定有相关实施计划，比如常用的WBS计划，不过我现在不再用WBS计划，这个针对很多无项目经验的客户来说，查阅起来非常吃力，我一般都会按照项目阶段重新整理一份，明确各项目阶段的实施重点事项、实施天数及产出即可，不会太细。

2.6 实施确认

        到了最后，所谓实施确认，就是签字确认，这样一来是给客户，给我们自己一个交代；后续系统搭建，我们既有方向又有了底气。

后记：第一次将自己的工作想法，通过《》的方式记录下来，写的不清楚的地方，请各位看官随时吐槽，谢谢支持，期待各位不同的看法。