工具类软件项目需求与设计案例.docx
《工具类软件项目需求与设计案例.docx》由会员分享，可在线阅读，更多相关《工具类软件项目需求与设计案例.docx（63页珍藏版）》请在冰豆网上搜索。
工具类软件项目需求与设计案例
一、工具类软件项目需求与设计案例——计时工具系统
对于类似word之类的工具类软件，应该如何获取它的需求呢？
五维三级需求法应该如何应用呢？
该案例以一步一动的方式详细剖析了需求的过程......
（一）计时工具系统案例与需求方法简介
1）计时工具系统案例与需求方法简介
某软件公司的开发项目进度计划总是那么不准确，延期经常出现，更可恨的是项目团队甚至无法给出一个相对比较明确的延迟时间，这给市场的推广会带来很大的影响。
以下是公司领导之间的对话：
市场部经理：
研发部承诺本月实现的产品功能又没按期交付，这已经是第三回了。
这导致产品上市时间总是不确定，给我们市场和营销人员带来很大的麻烦，你们知道吗？
研发部经理：
针对这个问题我们花了很多时间来解决，但一直收效不好。
我也在积极想办法，我用过FP模型、WBS方法等....
总经理：
（打断研发经理的话）这问题靠我们自己闭门造车是不行了，看看能不能借助外脑？
我看这样吧，由你（研发经理）负责，请一个这方面的顾问，如果有必要还可以采用信息化手段，采购或研发个工具软件，帮助我们更好地解决该问题....
这就产生了一个项目机会，那么对于这类件项目，又该如何抓需求呢？
2）五维三级需求法
“五维三级需求法”即从广度（五维：
因、人、事、物、规）和深度（三级：
业务和用户需求、产品需求、功能需求）两个视角分解复杂问题，展开需求分析，获取高质量的需求结果。
1．分析软件的“因”。
任何信息系统项目建设的出发点一定是要解决业务中存在的问题，以期达到某种建设目标，所以应将“因”维（分析业务问题，确定项目目标）作为软件需求分析的起点。
2．分析软件的“人、事、物、规”。
围绕达成“因（项目目标）”的几个关键业务场景，通过“人”维了解组织结构、清晰岗位职责，通过“事”维区分业务场景、梳理业务流程，通过“物”维收集单证报表、获取数据求，通过“规”维分析软件相关系统、明确时间节点等限制条件。
3．形成软件的“业务和用户需求”。
在“因、人、事、物”分析的基础上，分别描述核心业务流程和收集用户需求。
（1）对于存在业务变革的项目，讨论重点在核心业务流程，主要关注业务现在具有怎样的组织、执行怎样的流程、传输怎样的单证，并探讨未来会怎么办。
为了保证需求效果，讨论可一次围绕一个特定业务场景展开，事先草拟好业务流程图当“靶子”，并尽量邀请高层参加。
对于如体制调整等一些短期内无法决策的问题，也应标识出几种可能的变化情况，为后续的系统架构设计指明应考虑适应的变化点。
（2）对于不存在业务变革的项目（如工具软件、局部技术改造类项目），重点在于收集用户提出的各类意见（常以解决方案的形式出现），并挖掘意见背后的真正问题，结合行业最佳实践协商解决方案，形成用户期待软件具有的特性列表。
4．形成软件的“产品（软件）需求”。
任何软件或产品都必须在“时间、成本”等约束下，对“质量和功能”进行折衷，业务和用户需求中的很多事并不一定都要纳入系统中去实现。
因此，在产品（软件）需求阶段重点是在“规”的约束下，协商确定现阶段产品的项目范围和开发任务，如现阶段“到底有哪些岗位使用该系统，用户能够使用系统完成哪些工作，系统怎样帮助用户完成这些工作（自动化程度有多高）？
”等等。
本阶段形成的文档名为《用户需求分析说明》，主要采用用例模型来描述。
5．形成软件的“功能需求（需求规格说明）”。
这阶段主要是对产品需求中的每个用例（即用户使用系统完成的一项工作），由系统开发者和具体用户协商，按用例优先级逐个确定其操作界面、操作步骤等，这层次的工作将为具体的物流信息系统开发提供完备的需求规格说明。
本阶段形成的文档名为《用户需求规格说明》，一般采用用例细化描述文档和补充规约（非功能性需求等）来表示。
注：
业务、用户、产品等需求的概念和区别参考推荐阅读1
6.需要特别说明两点：
一是为了化解需求复杂度，“五维三级需求法”可逐个业务场景的迭代应用。
比如，在应用时可针对一个业务场景，完成一次需求分析过程。
待完成该业务场景下的业务需求、产品需求和功能需求后，再着手另一个业务场景下的需求分析过程；
二是五维度中的核心是“因”。
只有准确把握好“因”，才能把握住“人、事、物、规”的变化趋势。
由于“因”常常由上一层次目标所决定，所以软件建设，需将建设目标纳入企业信息化顶层设计的背景中通盘考虑，才能准确到位。
（二）从“因”维确定用户痛点和协商解决方案
1）获取甲方用户需求时，首先应访谈谁？
怎么约？
怎么谈？
●首先约谁谈？
抓需求，第一个要约见的是甲方的项目负责人。
因为他负责这个项目，有责任和义务去和乙方交流，选择乙方。
至于甲方的其他人员，应该通过甲方项目负责人去协调约见，如果擅自约见，可能会遭到拒绝，并引起甲方的反感。
●约谈对方方式主要有电话、邮件、面谈三种
建议先提前一周发邮件约见，再提前半天打电话确认提醒，最后面谈。
一般应在邮件里包含：
公司优势和访谈提纲。
公司优势包括以往成功案例、对项目的初步认识等，有利于体现乙方的专业能力和认真态度，加深甲方的认识；
访谈提纲可以让甲方有更好地准备，比如在提纲中提到甲方业务规章制度，甲方访谈时就可以事先带一份过来，从而提高访谈的效率。
●访谈地点的选择
约甲方普通人员访谈，一般在其办公室即可。
但是约见甲方项目负责人，由于他往往工作很忙，在其办公室一般干扰会很多，如一会儿有人敲门开汇报事情，一会儿有电话打入，导致需求访谈效果不佳。
因此，和甲方项目负责人的访谈地点一般建议选择方便、而且干扰少的地点，如其楼下的咖啡厅或者公司的会议室。
可以开玩笑地和他说：
“领导办公室干扰太多了，领导能不能将约好的1小时时间完全给我，我们在楼下的咖啡厅坐坐？
”
●谈什么？
和甲方的项目负责人交谈，是一次体现乙方专业能力，树立甲方信心的极好机会，应该事先做好充足准备。
交流时应注意从甲方的业务视角出发，聚焦甲方业务问题和解决问题的业务模式，避免过于技术视角。
由于甲方项目负责人不可能了解所有业务细节，所以一般访谈时还会和甲方项目负责人协商确定再召开一次业务需求研讨会（多人同时参加的用户代表访谈），会上将各类用户代表召集在一起，讨论业务细节，明确项目范围。
所以，还需协商制定会议计划，明确会议的时间、地点和人员，并通过甲方项目负责人通知相关人员，做好会前准备工作。
2）计时工具系统的“因”维度需求分析
一、基本工作步骤
“因”维度需求分析一般分为三步骤：
1、通过同类方案（竞品）研究法成为领域专家；
2、约谈甲方的项目负责人，找到核心痛点，介绍行业内各类解决方案，并与之协商适合甲方的解决方案；
3、通过甲方的项目负责人，筹备多用户代表参加的集中访谈，确定会议时间、地点和参与人员。
二、以计时工具系统为例，详解“因”维度需求分析过程
（案例背景详见推荐阅读1）
1、通过同类方案（竞品）研究法成为领域专家
通过前面案例介绍我们知道，负责该项目的需求师必须是工作量预计领域的专家。
如果对于该领域不熟悉，一般采用同类方案（竞品）研究法（详见推荐阅读2）尽快了解业务、掌握行业术语，并对市场上已有解决方案（竞品）的各自特点和利弊展开分析。
2、约谈甲方的项目负责人
在该案例中，主要是约谈研发部门经理（为什么先约谈他？
详见推荐阅读3），开展用户代表访谈。
访谈目标主要是：
明确用户核心痛点，向他介绍行业各类解决方案，并协商该公司适合的解决方案。
以下是访谈的内容实录：
（以下对话目标：
明确用户核心痛点）
需求师：
能否介绍一下贵部门当前在工期预计中遇到的问题？
研发部经理：
我部门各个项目团队给出的项目进度计划总是不太准确，经常出现延期，更可恨的是项目团队甚至无法给出一个相对比较明确的延迟时间，这给市场的推广会带来很大的影响。
有什么好办法吗？
（以下对话目标：
围绕核心痛点，向用户介绍行业内常见解决方案）
需求师：
根据我们的研究，对于这类问题，目前业内做法主要是：
根据用例包、用例的方式来组织需求，然后将某个用例或子用例作为工作任务分配给开发人员，但在开发时间估计上主要有三种解决方案：
一是使用FP、COCOMO模型来估计工作量。
但是要想计算准确，需要很多历史经验值，并且要求前期需求做得非常精细，难度极大；
二是自上而下的估计法。
主要由领导或专家指定相应的完成时间。
但由于开发人员未参与时间预计，所以如果到了时间开发人员完成不了，他容易反过来抱怨是领导时间安排不合理；
三是自底向上的估计方法。
任务明确后让开发人员反馈工作量及所需的工作天数。
但开发人员容易将时间估计的偏长，而且还是有一些工作任务，由于开发人员经验不足，他反馈的工作量无法按期完成，甚至无法明确要延迟多少天。
（以下对话目标：
与用户协商该公司适合的解决方案）
研发部经理：
三种方法我部门好像都采用过，确实存在你说的问题。
我感觉估算的基础是经验数据，对于不同的开发人员而言其产能是不一致的，甚至对于相同的开发人员而言，不同的任务所需的时间也是不同的，因此关键在于缺乏这种经验数据。
需求师：
正是这样，所以我想向你推荐了PSP（个人软件开发过程）的方法来积累经验数据。
举个例子，我在编写技术书籍时，就采用这种思路，对所有的工作过程进行了时间的记录，在半年之后，就积累了许多相关的产能数据，现在给编辑的时间承诺总是能够比较的准确。
研发部经理：
哦，难怪你做的承诺都一般很少延误，这种经验能否适用于软件开发的管理呢？
需求师：
呵呵，这是当然。
PSP是个人软件开发过程，它本来就是为软件开发设计。
它是CMM的创始人提出的，PSP、TSP和CMM分别针对软件开发员、软件开发小组和软件开发组织。
通过PSP的贯彻，就一定能够提高软件开发人员的时间安排、时间估算的能力。
由于统计个人开发时间是件比较繁琐的事，所以需要开发个工具配合它。
研发部经理：
好！
那我们就开发这么一个工具！
3、通过甲方的项目负责人，筹备用户代表集中访谈会
（以下对话目标：
通过甲方项目负责人，筹备有更多其他用户代表参加的集中访谈会）
需求师：
太好了，这正是我要建议的！
但是由于这款软件涉及到的人员较多，有很多细节需要确认，我们能否在下周召开一次用户代表集中访谈会？
请您帮助召集更多的相关人员参加。
研发部经理：
当然可以！
那我们再商量下会议的时间、地点、主题和需要参加的人员......
这样，这次计时工具系统的“因”维度需求分析就大致完成了，回来后需求师还应该整理访谈记录，形成文档（文档模板参见附件1）！
（三）采用业务流程模型和特性列表描述业务需求和用户需求
1）一图说清业务需求、用户需求、产品（软件）需求和需求规格的关系
一、四者的关系如上图所示
1、业务需求和用户需求是软件项目需求的起点。
业务需求侧重于和高层探讨业务流程（特别是需要优化的流程，详见推荐阅读1），一般产出物是业务流程图；
用户需求侧重于和各类用户代表开展面对面的访谈，一般产出物是汇总访谈结果的需求特性列表；
2、这时不论是业务需求、还是用户需求都比较粗糙，需要经过分析处理后，形成软件（产品）需求，才能交付给开发团队使用。
其产出物一般是用例图，有时也会是经过处理的功能列表。
3、软件需求规格说明（功能需求），是对软件（产品）需求中的某一个用例或功能进一步细化，供程序员使用的文档。
其产出物一般是用例文档、界面原型、有时还有状态图、时序图等细化模型。
二、详细介绍业务需求和产品需求的不同点
业务需求是指业务上要做这件事，但做好这件事可能需要若干个处理过程。
所谓产品需求就是确定哪些处理过程需要由计算机帮它做，哪些处理过程干脆在线下由人来做，实质是确定软件自动化程度的高低。
以订餐系统中的“配送”为例，订餐业务中需要完成“配送”这件事，所以说“配送”是业务需求。
但是具体到订餐系统中到底要包含哪些功能来支持“配送”这件事，这个取决于系统交付时间的紧迫性、项目经费的充足性、使用用户IT水平的高低等因素。
如果项目时间紧、任务重、用户IT水平低，那么自动化程度最低的产品需求就是系统仅提供一个“打印配送单列表”的功能，其他功能都由人员线下完成。
如果项目时间、经费充足，那么自动化程度高的产品需求就可能是提供了“出车计划、行车路线计划、装箱计划”等功能。
这些功能的使用场景可能如下：
1、每天物流配送中心要汇总来至全市各个专卖店的配送订单，然后自动生成出车计划，确定当天该出几台车去配送，既满足要求又不浪费运力；
2、然后它要自动生成行车路线计划，分配几台车各自的运输路线，刚好将这些需供货的烟草专卖店串起来；
3、最后当车运到专卖店门口后打开柜门，这个专卖店门口需要的货刚好就在货柜的表面，而不必翻箱倒柜地去找，即要有个装箱计划。
所以说“业务需求”和“产品需求”是两回事！
其描述方法详见推荐阅读2，文中第二部分“用例模型的级别”有详细论述。
2）案例剖析：
计时工具系统的业务需求和用户需求
通过与甲方项目负责人面对面沟通，围绕“因”的维度，确定了计时工具软件需求中的核心问题和解决方案思路：
即为开发人员提供一个PSP工具，简化时间记录工作，同时提供数据使用的工具，帮助开发人提高估算能力。
（需求过程详见推荐阅读1）
接下来，需求师通过召开多用户代表的集中访谈会，从“人、事、物”三个维度，采用业务流程模型描绘核心业务流程，获得业务需求；采用敏捷需求收集卡，收集各类用户意见，形成软件特性列表，获得用户需求。
其需求沟通过程和要点如下：
一、采用业务流程模型描绘核心业务流程，获得业务需求
1、访谈内容
需求师：
贵公司一般项目计划工期估算的过程是怎样的？
能简单，介绍下吗？
研发经理：
我觉得我们单位的项目管理流程一般如下：
1）由研发经理创建项目；
2）由项目经理创建项目中的各任务；
3）开发人员在接到任务后进行估算填写时间计划；
4）项目经理对其进行确认；
需求师：
根据之前的讨论，如果未来需要开发人员自己统计开发时间，那就还要加上以下几步：
5）开发人员对自己完成某任务的开发时间进行记录；
6）研发经理及公司领导可以根据任务和相应的时间记录，来统计公司员工的产能数据。
研发经理：
是的，这6步就比较完整了！
2、整理成业务需求
需求师：
那好，我们可以采用业务流程模型，将该流程整理成如下图。
二、收集各类用户意见，形成软件特性列表，获得用户需求
1、访谈内容
开发人员甲：
我认为，开发人员自己应该能够通过这套系统来统计自己的产能数据。
我希望系统能够在让我们填写估算值时，可以查询历史数据，否则仍然没有意义。
开发人员丙：
查询历史数据时，还应该有类别吧！
这样我们才能够根据自己将要完成的任务情况找到有参考依据的统计数据。
开发人员乙：
还有就是时间记录一定要方便，另外像我们这样经常要在现场开发，如何完成时间记录？
研发经理：
可以考虑有一个离线版本的时间记录程序，等回公司连接服务器后再进行数据同步。
……
2、整理成用户需求
在访谈的过程中，需求师采用敏捷需求卡片，随时记录用户代表的用户需求如下图。
最终汇总用户需求列表如下
这样，聚焦上图的核心业务流程图和特性统计表，经过会议集中讨论，需求师就逐步完成了计时工具系统的业务和产品需求分析。
（四）采用用例模型描述计时工具的产品需求
1）常见需求模型之——用例模型
一、用例模型的要点
用例图很简单，一般就是三个符号：
一个小人（角色）、一个圈（用例）、一根连线，但是要绘制好用例图并不简单，需要注意以下问题：
1、如果本系统和外部系统有交互或接口，外部系统也是角色。
如ATM机系统中与银行系统的对接例子，如下图；
2、产品用例中的角色是实际使用系统的岗位名，如在代售点的火车订票系统，其用例图如下图；
3、角色间可以使用继承关系简化设计，但意义不同；下图左边表示三类用户点击的是同一按钮，看到的是同一界面，可以由同一个程序员开发的登录模块；下图右边表示的是三类用户点击的是不同的按钮，看到的是不同的界面，可以分给不同的程序员分别开发的登录模块；
4、用例中核心业务要详细突出，一页纸写不下的非核心业务可以合并，并在次级用例中展开；
5、用例应该能为角色带来业务价值，别把动作过程当作用例。
用例好比是主界面上的按钮，动作则相当于点击按钮后在弹出窗口中的一系列操作。
比如查询是用例，而设置查询条件和获得查询结果就是查询用例的两个动作。
6、采用用户的视角和术语命名用例，常为动名词，避免采用功能视角确定用例。
如下图处理设备缺陷项目，左侧是错误表达方式，右侧是推荐表达方式。
二、用例模型的级别
用例模型分为业务级、产品级和功能级三个级别，应在需求过程中逐步细化。
业务级用例是用于需求前期界定业务范围的，例子中表示配送人员业务上要干“配送”这件事；
产品级用例用于甲乙双方签合时明确工作量的，反映了软件产品为支持“配送”业务提供的功能。
注意如果自动化程度高的软件产品，还能提供“自动生成配送路线”、“自动生成装箱计划”等功能，但在例子中表示未来软件产品将只提供“打印配送单”和“登记配送结果”两功能，其他功能不提供；
功能级用例用于开发团队内部管理项目的，反映了各个功能之间的依赖关系。
例子中表示“打印配送单”和“登记配送结果”功能都用到了“查询配送信息”功能。
三、功能级用例的结构化关系
用例通过扩展、包含、泛化等关系作为对需求细化的手段，称之为用例的结构化。
比如下图所示，不同用例之间的关系如下：
包含（include）：
一个用例的实现使用另一个用例的实现。
例如，“预定房间”和“登记入住”都需要参与者核对房间的可用性、以及查询有没有可用的房间等，这可以增加一个“核对房间清单（CheckRoomDetails）”的包含用例。
扩展（extend）：
基本用例不需要了解扩展用例的如何细节，扩展用例在这些扩展点上增加新的行为。
例如，酒店管理系统中有一个功能“待分配房间的预订人等候名单”，如果没有房间，系统就会把客户放进这个“等候名单（Waitinglist）”，因此，这个“Waitinglist”就是“预订房间（ReserveRoom）”的扩展。
把扩展分离出来，可以使问题容易理解，这就不至于被过多的问题所纠缠。
泛化（generalization）：
一个用例的实现从另一个抽象的用例继承。
例如，酒店管理系统中“预定房间”用例就可以泛化为“预定设施”，这样，以后再有类似的“预定会议室”用例就可以直接从泛化的“预定设施”用例继承。
在细化确定需求规格说明时，如果存在以下情况，一般进行用例结构化，将子流或备选流提升为单独用例：
1、当一个子事件流被多个用例调用时；
2、备选事件流或子流开发量较大，需单独安排人员或时间时；
3、准备在下一版本完成备选事件流时。
2）计时工具产品需求
经过前期的需求工作，可获得用户需求和业务需求如下图，详见推荐阅读1！
然可采用下述步骤形成产品需求：
1、特性合并
将获得的用户需求列表按用户和特性类别进行合并，如下两图
2、采用用例模型描述产品需求
对上述列表进行模型化（详见推荐阅读2），形成产品用例，如下图
这样，就完成了计时工具系统的产品需求！
（五）采用用例文档和UML模型细化需求和设计
1）计时工具系统的详细需求规格说明和初步设计
可以采用以下步骤形成需求规格说明，并展开初步设计。
一、对产品需求进行优先级排序，如下图，排序方法参见推荐阅读3
二、细化描述核心产品需求
并不是所有需求都需要细化，一般重点将排序靠前的产品需求（20%~30%）细化。
1、采用用例文档细化描述
2、依据需求分析候选类，并采用领域建模描述（架构分析中的“结构思维”，详见推荐阅读4）
3、细化描述核心产品需求，并采用交互模型描述（架构分析中的“行为思维”，详见推荐阅读4）
4、采用界面原型描述需求
这样，计时工具系统的需求过程就全部完成了，并同时完成了设计工作，剩下的事交给一个初级程序员编码就OK了，这部分就累述了，呵呵！
二、常见需求模型
（一）什么样的项目要采用业务流程模型来描述业务级需求？
对于一些涉及业务变革、职能调整类的项目，尤其需要画出业务流程图，明确未来业务在组织结构、业务职能和业务信息共享要求等方面的变化情况，借助业务高层领导的支持，避免变革阻力向系统的传导。
举个例子，上海某家大型幼儿教育的培训机构，早期采用的是以销售为中心的业务模式。
由销售前往各幼儿园派发幼儿培训课程传单，传单上印着销售的名字和电话，家长对课程感兴趣就直接给销售打电话报名。
当报名人数达到一定数量，销售就自己外请老师，收培训费，并组织培训。
培训结束后，销售将一部分钱交给公司，剩下的钱就是自己的奖金提成。
这种以销售为中心的粗放型业务模式，导致很多资源掌握在销售手中。
很多销售干久了，就带着资源跳槽了，或自己出去开培训公司了，公司未来发展会面临很大的风险。
针对这一问题，公司老总提出未来业务应采用信息化手段进行精细化管理。
他喊来IT部门的负责人，对他详细描述了自己对未来业务系统的期望。
未来，还是由销售前往各幼儿园派发幼儿培训课程传单，但传单上印着的不是销售的电话，而是公司内部客服的电话，由客服将家长信息统一录入到系统中。
当报名人数达到一定数量，不能由销售自己外请老师，而应到系统内部的老师资源库中挑选老师，非库内的老师不得授课。
另外，培训经费也不是销售自己收，而是由专门的财务岗位用系统收费和登记。
当培训结束后，还有专门的QA岗位用系统对授课情况进行评估，只有通过评估、家长满意的课程，销售才能到财务领取奖金提成。
这一系统的需求由公司老总亲自提出，而且非常明确，IT部门非常重视，系统经过IT部门加班加点很快就开发出来了。
但是在上线试用的时候，由于这个系统限制了销售的权利，很多销售在使用时非常抵触。
加上系统刚开发出来，在很多细节问题上考虑不周，确实也存在瑕疵，所以销售态度非常强硬，撂下话：
“这个系统不改好，我们不用！
如果一定要我们用，出了问题你负责？
”结果这个系统反复改，销售反复挑毛病，迟迟用不起来。
后来，他们的IT部门采用业务流程改变了对这个项目的推进策略。
IT部门不着急开发系统了，而是将业务流程图画了出来（如图1），请公司老总召集销售开会确认。
一旦会议通过了，就要求公司先按新业务流程走起来，不急着上系统，先按纯手工的干起来。
这么一搞，销售提意见了，说：
“好多报表我得反复填，太麻烦了！
”这时，IT部门才发话：
“我来帮你了，这可以开发个功能，一按按钮就将上次的内容自动填报……!
”这样，再推进项目，阻力就小多了！
所以说业务流程图避免了业务变革压力向IT传导，让业务领导承担了他该承担的变革压力，对于业务变革类的项目是一种非常有用的辅助工具。
另外，在一些需要规范业务的IT项目中，该模型也大有用武之地。
例如某进出口局的免税审批业务，以往免税审批是要被审单位人员一趟趟往进出口局跑，经局内各个环节都审批通过了，才能拿到批文到海关申请免税。
该进出口局的局长上任伊始，提出要搞一个网上免税系统，实现便民服务。
接到这个项目需求，在需求调研时我们发现该局的免税审批业务流程随意性较大，例如负责审批的办事人员如果不在，他可以随意委托同事帮他办；或者跳过他，副局长批了也行；有些项目着急，局长先批了，事后再补流程；如果被审单位和办事人员关系好就快办、关系差拖着点办，等等。
现在要通过系统去管理审批了，就不能那么随意，必须将一些灰色地带的、谁办都可以的事说清楚，到底什么情况下该谁办？
所以我们一上来没着急开发系统，一开始先按我们的理解、参考同行的经验画出业务流程图初稿；再逐个岗位调研、征求修改意见，基本上每个岗位都在争夺审批权限，设置审批环节；最后，汇总到一起后，局长又提出：
“审批要便民，要精简”，不能设那么多环节，回过去再次修改，根据项目的金额再分级处理。
这么反复折腾了3个月，最后终于达成一致意见。
达成意见
升级会员 