退管系统总结
1 需求
做这个项目前，尽管我已经认识到需求的重要性，但是由于业务的不熟悉和第一次做需求的陌生，让我也走了很多弯路。
记得有个故事：某公司招聘一个市场营销人员，A和B竞争到最后一轮。面试官把他们叫到一个房间说：“我想吃桔子，你们到楼下东边市场看看，15分钟回来。”不到10分钟，A回来了说：“市场上有很多桔子！”，“那桔子多少钱一斤呢？”，“不知道”，“那桔子是从那里进货的？”“不知道”……“等B进来看看吧！”15分钟，B提着一些桔子推门进来了，对面试官说：“市场上有9家卖桔子的店铺，价格最高为2元/斤，最低为8毛/斤，桔子都是从市内最大的那个XX水果批发市场批发过来的……我带一些桔子回来了，你看看怎么样？”
做需求，也就要像营销人员B一样。
1.1 做需求的心态
做需求很难。因为需求做的不好会导致项目的失败，重工或延期。而需求开始阶段又是跟客户磨合的过程，磕磕碰碰是难免的，或许需求开始就是双方争取主动的阶段，这个阶段占主动一方对以后的工作会相当有利。当然对于我们做需求的，天生是被动的，但也应该能主动影响客户，朝有利项目的方面发展。
需求的后期就是和设计开发人员磨合的阶段。这时需要告诉设计开发人员该做些什么东西。这个时候也是很痛苦的，这个时候的设计开发人员就像你一开始对客户一样。这个不清楚，问一问，那个不知道，问一问。
所以整个需求阶段需要需求人员端正心态，积极主动。你可以抱怨客户不能告诉你他们想得到什么，但是不要忘记，收集需求信息是你的工作。你也可以抱怨设计人员没有设计出满足需求的方案，但是不要忘记，传达需求信息是你的工作。
1.2 问题域
我们这么辛苦的了解需求干什么？不就是为了解决客户的问题吗？那么了解客户的需求不就是了解客户的问题吗？需求等于问题吗？
当然问题不等于需求。问题只是需求的表象，换句话说就是：需求是问题的本质。要做需求，首先就要先知道什么是问题？
问题域，可以简单理解为问题的集合，问题的范围。做需求就是先确定问题域，搞清客户的问题是什么，再分析问题，形成客户的需求。
问题域：
整个问题域中我们做需求需要先搞明白的是问题的范围是什么？我们不能解决的问题有哪些？通过我们沟通能解决的问题有哪些？最后得出系统该解决的问题是什么？其实所有的工作都是为了最后一个问题：系统该解决的问题是什么？我们开始就要尽可能把这个范围搞清楚。
一个业务系统的需求，当转化为信息系统需求的时候是有特定的层次的，这个层次会决定你做的系统到底有多复杂，也就是最大的一个问题域。第一层是信息管理系统，对用户的基本资源进行描述，第二层是业务系统，对客户的业务流程进行控制，第三层是计划控制，第四层是决策支持，第五层是人工智能等等，低层和高层之间互相制约和依托。在你给用户做需求分析的时候就要考虑到系统本身的层次，如果目前用户只提到基本资源描述的需求（理解成对基本信息的增删改查），那么你要考虑为什么客户要这样做，这样做能解决他什么问题，到底给用户带来了什么利益，这些利益是否真正就是他需要的，是否他并没有考虑到信息系统可能给他带来的更多的问题和利益。
理解客户的问题就是需求分析的过程。怎么样从客户的问题从抽丝剥茧地把他们的需求挖出来？这个过程是个理解的过程，是个把握的过程。丈夫问正在看电视的妻子连续剧怎么还没放完，他的意思不是问为什么连续剧没放完，而是要妻子不要看电视去做饭了。
不要把客户描述解决问题的方法误认为是问题。客户有时会说该怎么怎么做？这个怎么怎么做不是客户的需求，而是他认为可以解决他的问题的一种方法。那么我们就要看他这个怎么怎么做的目的是什么，这个才是真正的需求。
1.3 原型的帮助
在需求初期，尽快根据已有的需求形成一个系统原型，可以很好的挖掘客户的需求。也可以更好让客户表达他的需求。
1.4 文档编写
1.4.1 清晰的文档结构
文档的编写需要一个清晰的结构，能够把客户的需求完整的描述出来。这个结构不但是门面工作，更是让客户体会你的素质，整个公司的规范要求。
1.4.2 适当的图例
好的图例能很好的表达文字不能描述的东西，当然图例要加适当的注释。初步接触，需求人员自己设计好简单Use Case，无需给客户看，他们也不一定看懂。这个过程有个结束目标，能让设计人员理解Use Case，并能基本确定系统的框架。
1.4.3 使用客户原话
文档的编写尽量使用客户的原话。因为如果你抽象了客户的话，写成文档，然后设计编码人员再一次抽象你写的文档。估计愿意就要走样了。
1.5 引用一些话
求其实很少改变，改变的是你对需求的理解
如果需求经常改动，很可能是你没有作好需求分析，并不是需求真的改变了。
需求真正改变的情况很少，但是没有做好需求分析工作的理由却很多。
2 设计
退管系统基本上是没有设计的。当时就直接从需求到编码，也让整个系统在后面变的结构混乱。对于设计，我认为基本目的是规范开发，提高重用。规范开发就是要求编码人员按照一定的结构和规范进行开发；提高重用就是管理好公共资源，提高代码重用性。
3 编码
3.1 Ctrl＋C/ V编码
先给那些“Ctrl+C/V”的编程下个定义，就叫“无聊的编程”，难道不是吗？大部分人的大部分的时间，都在进行着无聊的“Ctrl+C/V”，对一个功能的，一张表的增删改查；对另一个功能的，另一个表的增删改查。大部分模块完成同样的功能，只是不一样的form，不一样的表，反正是完成增删改查，反正是将一个模块的代码“Ctrl+C/V”到另一个模块。
上面不是说别人，而是说我在退管系统时的编程现象。这样编程的结果是引发很多问题：
1 代码结构不清晰。
2 调试难，出了问题必须跟踪每行代码才能定位。
3 重用性低。
3.2 重构意识
一段时间的代码编写完后，应该回顾并检查代码，优化代码，对代码进行重构。很多问题在当时写代码的时候没有发现，那么可以在检查代码时发现，并进行适当的优化。即使当时代码质量很好，但是经过后面业务的增加，需求的变更，导致代码质量下降，也可以在检查代码时进行重构。
重构是个返工检查的额外工作量，当时就要花一点时间去做，好像是一个得不偿失的事情。但是经过重构的代码能更健壮，更能适应需求的变更。重构不是一时的工作，而是一种编码意识，应随时根据需求进行。
4 实施
系统实施起着十分关键的作用，“三分系统，七分实施”说的就是这个道理。系统实施也是个琐碎的工作，特别到旧系统到新系统的数据导入。
对于退管系统的实施，有几个比较值得注意的地方：
4.1 保证实施基础条件
实施的基础条件包括硬件（网路）环境，软件环境和基础运行数据。对于退管系统，一开始只是在退管中心试用，没有估计到推广到整个区使用时硬件网络问题。结果在推广时由于退管中心和区信息中心之间无直接的网络环境，只好用VPN拨号来解决。但是VPN拨号存在速度慢和单帐号登陆的问题，导致给系统的推广和验收带来极大的不便。
所以在系统实施前一定要先摸清楚这个系统实施的环境，根据环境尽快作出相应的计划进行处理。
4.2 制定计划，注意反馈
整个系统的实施要制定计划，虽然计划经常给一些不可避免的事情打乱，但是没有计划，实施就会很盲目。计划是控制的保证，那么无论如何，实施计划一定要有，并且要同客户取得一致的意见，让客户知道怎么样配合我们一起实施整个系统。
实施情况反馈是很重要的。退管系统在实施间做了一个简单的业务人员使用情况一览表，通过这个一览表，客户也很清楚系统使用情况，同时也让我们实施人员知道哪些系统使用人员是重点培训对象，有针对性进行实施。
4.3 根据任务推广实施
退管系统开始在XX街试运行时，效果不是很明显。因为街道没有来自区上级部门的压力要求使用退管系统，所以使用系统对她们来说就是可有可无的事情。但是后来，上面使用系统来下发数据时，她们就不得不使用了，也就有积极性了，效果很好。
因此系统的实施要配合业务的节奏，搭上业务的便车，从上到下，业务先行，实施跟进。
