最近一直在推演医疗软件开发模式，到底怎么才能在符合体系的前提下应对没完没了的需求变更？
先讲讲中小企业医疗软件开发的现状和方案。
现状：
按照法规边写文件边写代码，不可能。因为在最后做认证申报的时候，一般都会有巨大的变更，所以，文件写的越多，留下不符合规范的案底就越多，会自己把自己坑得更彻底。
软件变更会发生在任何时候，想都想不到，提交注册前，注册中，注册后，都可能发生变更。因为软件的变更，只要界面不变，注册资料中是几乎没有证据的。
中小企业的软件开发模式绝对是“边做边改”模式，什么瀑布模式，什么敏捷开发，都是扯淡。
方案：
研发归研发，体系归体系。两组人，一组人做体系，专门做认证申报；一组人做研发，专门做需求实现。
研发组会有基本的需求测试文件输出，但绝不能和体系文件关联。这部分文件只对内，不对外。
体系组在申报之前，先推演整个项目的立项时间，再定每个阶段会对应什么文件什么版本，注意两点：svn，测试记录，验证方案+记录（包括开发过程中必要的工具验证，如禅道、SVN、VS2015）。
接下来讲研发过程中对需求的控制。
下面是中小企业的日常软件研发流程，请对号入坑：
研发过程中，通常会有这么几个角色存在，用户->产品->研发->测试。
- 用户：实际上，中小企业的第一个客户就是boss，所有的需求都出自他，不管合理不合理，都会推进。所以，用户需求部分最简单，boss说什么就是什么，整理记录即可。
- 产品：严格上讲，产品是要做产品原型的，互联网大都是产品当项目经理，从最前端推进项目。可医疗行业的产品经理不是那么好做，一般中小企业是招不到合适的产品。再说，中小企业的产品是不允许有自己的想法，不然用户会不爽。因此，中小企业的产品经理就是用户的需求记录员！不需要脑子，boss说什么，记下来，ok!
- 研发：这个角色最坑，由于产品不合格，写代码变成了一个恐怖的过程，没完没了的变更，心急火燎的更新，砖都不能好好搬了。别谈什么设计模式和软件架构，撸起袖子加油干！反正软件出了BUG，就是研发没做好，管TM别人什么事？！！！
- 测试：中小企业能有专人做这个职位就算不错了，好多都是研发兼任！！！就算是有专业的测试人员，那么，别想太多，就是黑盒，100%黑盒，其他什么都没有。那到新版本，按照流程点一遍，不炸就过！炸了呢，大喊一声研发，有BUG了。下班了。
现在分析软件研发模型。
上面说了，一共四个角色：用户->产品->研发->测试。研发模型的变化，区别就在于这几个角色谁来当项目经理！
- 用户当项目经理：技术型boss可能会这么干，这种情况还好。非技术型boss?强行当项目经理，这是企业的灾难，估计也快关门了。
- 产品当项目经理：按道理讲，产品?当项目经理，名正言顺。产品要负责整条产品线，不只是研发过程。只是在研发阶段盯研发，没毛病。但上面讲了，中小企业的产品就一个傻子，不能有自己想法，又没能力给研发细化需求。结果就是一团乱，软件做出来需求对不上。
- 研发当项目经理：研发最合适的角色是研发负责人，不能严格的说是项目经理，因为有几点不合适：研发和产品，研发和测试，本来就是矛盾角色，容易监守自盗，比如简化需求，比如拖延时间。理论上，专业的人做专业的事情，研发只关注怎么做，不关注做什么！！！研发是一个团队，团队又会划分各种角色，程序猿?，攻城狮?，这个以后细讲。
- 测试当项目经理：测试是软件的输出口。能不能升版，测试说了算！中小企业的测试，由于只存在黑盒测试，所以工作量并不够。工作量不够就没有责任和业绩，这也是导致测试岗位的上升通道只有离职或者跳槽这一条。。。各位测试?可以哭一会儿。
最后给出最新的软件研发模型：
在研发过程中继续加强测试的重要性，提升在整个过程中测试的存在感。加一步：用户->产品->测试->研发->测试。并且测试当项目经理。
整个研发模型闭环的实施过程如下：
- 用户提出需求
- 产品记录需求
- 将需求给测试
- 测试召集产品+研发分析需求，讨论需求可行性，可行留下，不可行打回产品
- 测试将可行的需求排序
- 研发给出开发时间
- 研发内部分配并完成任务，该过程中测试跟进并控制时间
- 将结果给测试
- 测试通不过则评审原因，需求问题给产品，开发问题给研发
- 测试通过则将结果给产品
- 产品将结果给用户
- 以上1-11这个闭环的周期不能超过10个工作日，目前5个
研发模型具体实施细节：
两条线路同步走，一条编码研发线，一条需求分析+测试线。两条线时间要岔开，需求分析线的进度要比编码研发线提前一个周期，约5个工作日。需求分析线提供文档，内容为本次的需求，本次更新的内容；编码研发线提供exe。