首先在开始阅章之前，想补充上一章我遗漏的一个问题。写代码应该如何开始？俗话说万事开头难，对于初级学编程的人来说更是如此。需求分析那一章提过一个方法，就是从理想到现实。这个方法也同样适用写代码，假设你现在已经拿到了一份关于“全院医技统一预约系统”的需求文档。那这份文档有特别多的规则，有特别多的情况要考虑。我们开始写代码的时候不需要把所有的情况考虑清楚以后再去写，这样你的脑子会负担过重。应该怎么办？我们先按照一个最理想的业务状态来写逻辑，回到那个万能的“宇宙医院”。那请你只写这样一段代码，医生开申请单，预约成功，返回一个成功标志。我相信这段代码每个人都会写，这是一个理想需求，你再把需求文档中的各种条件，各种情况再逐一的补充上去，回归到现实。

四、上线交付

产品上线只是开始，接下就要接受来自用户的灵魂拷问考验。继续上个章节讨论，我为什么建议你先开发最小可用的粗糙的软件，而不是一个完美的软件交付给用户上线，为什么？接下来我们一起探讨这个话题。一个软件系统开发完毕以后，经过测试，交付给用户上线。前两个内容我不和你展开讨论，因为软件开发和软件测试太专业了，不是一、二句话能说得清楚。我重点和你谈论一下交付上线，大概会经历几个阶段：

第一个阶段：上线磨合期（第一次迭代）

现在你终于有了第一版软件，协调各个科室人员召开了一个上线会议，用户需要熟悉这个系统，工作流程也要依附你的系统完成，上线当天信息科的电话堪比10086，可能会存在以下几个问题，1、用户操作不熟练；2、用户需求变掛；3、用户新需求；4、系统出现bug。我们针对每种情况做一下分析，1、用户操作不熟练，这个问题比较简单，就像你买了一台新的智能手机，刚开始用不惯很正常但用了几天基本就熟了；2、为什么会有用户需求变掛，因为我们进行需求分析的时候，基本只是纸上谈兵，棋盘推演，并没有真正经过实际业务的测试，用户原来提出那个合理需求好像变得不合理，需要按实际情况修改，你可能会说，我当时开发软件时候，我是根据你的需求来做的，当时确实签过字，但是始终胳膊拧不过大腿，他可以再提出需求出来给你，不合理的地方还要需要改，我在“需求分析”那一章也讲了，不要期望用户把需求一次性把搞清楚，用户也不是万能的，基于自己的认知提出需求出现偏差很正常；3、用户新需求，这个比较好理解，原来没有想到的问题，在使用的过程中暴露出来；4、系统出现bug，这个也比较好理解，软件有设计缺陷这是无法避免的。

    上线磨合期，我个人建议如果不是严重影响到系统使用的问题，不要急于马上叫人修改，而是先把问题和需求收集起来，整理一个xls文档，再由信息科分析需求是否合理，而不是简单当一个传声筒将问题生硬抛给合作伙伴。为什么？我有2个方面的原因：1、合作伙伴的开发资源是有限的，尽量缩减提问题的数量，集中资源统一处理问题才有效率。有人说了，我付钱了，我想提多什么需求就什么需求，理论上这样，但是实际情况，资源是有限的，你的合作伙伴往往面对很多家医院，有多个项目进度表，如果你发现一个问题就提，这个问题而且没有经过信息科过滤，很可能导致无效开发，人力资源岀现会浪费。索性你整理一批问题，然后叫合作伙伴安排时间集中处理你的问题，反而高效。2、用户提出很需求，有些不合理，有些自相矛盾，有些不切实际，都是有可能的，信息科学会分析过滤。

第二个阶段：用户超越阶段（第二次迭代，可选阶段）

    我实在想不到用什么名字来概括这个阶段，暂且先叫它用户超越，经过上线磨合期以后，软件系统逐步趋向稳定。如果你想提高一下满意度，就要用户超越，这个是可选阶段不一定要这样做。那什么是用户超越，首先我们回归到一个经典的对话，你对用户说“你有什么需求，你就提出来，看我能不能解决”，这个时候我们把它称之为“追随者模式”，也就是用户定目标，你来解决。打个比方，用户是乘客，你是滴滴司机，用户说要去花果山，你就载他去，用户说要去海南三亚，你就带他去。时间一长，你和用户很熟了，关系很好，有一天用户从后排坐椅坐在你的副驾上，用户说要去花果山，呃，我们去黄山，我觉得那里真美，用户说是的吗，是的不错，好吧，我们去黄山的。你和用户之间的关系变成了“并行者模式”，在“并行者模式”你代替用户提出需求，并与用户一起达成目标。

举例说明：以医技申请单为例，假设现在系统开发完成，B超申请单、CT申请单、X光申请单许多申请单样式，经过你认真分析发现每个申请单发现都可以抽象是成标题，患者信息，病史摘要，临床诊断，注意事项，执行地点，签名信息组成，设计数据库表存储，可以用一个统一样式的申请单从数据库读取相应的值表示，把原来本来要维护一大堆申请单样式，现在只要维护数据统一样式即可，你实现了这个功能可以理解为用户超越。

    一个软件系统，如果有1，2个用户超越的时刻，让你站用户旁边，你帮用户提出需求，与你的用户一起“并行”，我相信用户满意度会提高很多。

第三个阶段：系统短暂运行维护阶段（第三次迭代）

系统短暂运行维护阶段，主要相对一段时间之内，比如，一个月，一个星期，看系统是否运行稳定，没有大问题，上个章节提到先开发最小可用的粗糙的软件来上线，软件现在只有业务模块、基础数据维护块，报表统计模块可能还为空，要求合作伙伴补上该功能。软件系统“短暂运行维护阶段”主要是证明软件稳定的，为验收做准备。

第四个阶段：验收阶段

验收阶段，通常是一个项目的结束，你可以向医院交差，合作伙伴向公司交差。在验收阶段通常有一个误区，通常以解决所有问题为条件才能够验收。我个人建议大家的验收条件放在大部分的功能已经实现，没有重大问题，是允许有小部分的问题可以留在运维阶段解决的这样的条件。如果你运气好遇到一个技术能力强，服务又好的合作伙伴，即使他没有向你主动提出验收，你也要主动提出来帮他验收，好的供应商是需要你爱护“大熊猫”姿态来珍惜的。为什么这样子说，我们回顾一下一个经济学常识，你的支出就是别人的收入，所以保护好“大熊猫”就是保护好我们的未来。

第五个阶段：维护服务阶段

验收结束后，今年存在有一年的免费维护期，免费期过后一般与软件公司签个维护合同，公司有一个专门的售后部门为你提供维护服务，公司处理问题是否及时、有质量，那就看运维工程师的水平。