男性早孕-从软件与程序的区别说起

引言

       今日新闻《如此医院太荒唐大小伙子被查出“早孕”》，百度搜索结果如下：

 

看到这结果，大家啥感想？

 

按常理，医院粗心、医疗机构忽视患者权益、经济利益的恶性驱动等等言论，唾沫星子基本足以把肇事医院来个水漫金山。

 

但实际上，这可能真的是一个小小的技术失误。

当然，历史上小的技术失误导致严重情况的后果很多，本文的目的并非为医院开脱，只是单纯从技术角度分析下该问题出现的原因。

 

       以下文字，开篇扯的有点远，但很快大家会发现联系。

 

1-软件与程序

首先一个问题，软件和程序是否有区别？

本人能找到的最早回答此问题的人，是一代软件工程大师Frederick P. Brooks，在其圣经级著作《人月神话》的第一章，就给出了这样一个图：

*出自《人月神话》（清华大学出版社2007年第2版，ISBN: 9787302155676）

 

程序，图中左上角，Brooks定义：本身是完整的，可以由作者在所开发的系

统平台上运行。它通常是车库中产出的产品，以及作为单个程序员生产率的评估标准

编程系统产品，本人认为可以等价于“软件”，Brooks定义为：可以被任何人运行、测试、修复和扩展的程序。它可以运行在多种操作系统平台上，供多套数据使用。

    如何从程序变成产品，需要走的路，就是图中蓝色的两条：

横向：代表了大家熟知的技术完善方向，例如架构的规划、接口设计、系统集成等工作；

    纵向：似乎是一些不太技术化的内容，测试工作、文档准备等等；

    简单的说，横向的道路，是为了把软件做出来，纵向的道理，是要尽可能延长软件的生命周期；一个是从0到1，一个是从1到万。

   

    那么，下一步的问题就是：Brooks大师为何如此定义，这样的定义对我们有何意义。

 

2-认知模型

    任何一种定义，都和其产生的时代密不可分。结合上图及计算机发展的历史，基本可以看出，Brooks大师工作的时代，除了接口、系统集成之外，如测试、文档等诸多工作，大部分也需要软件开发者自主完成。

在这个过程中，其实两类工作的思考角度是有明显不同。

在软件的制作过程中，制作者要考虑的是系统的结构，分为哪些模块及哪些类（或函数）等，以及相互关系和程序控制方法。

在软件的产品化管理过程中，制作者则要考虑如何保证系统可用，如何让系统可以被更多的人维护，以延长其生命周期。

上述两类工作者，在工作过程中思考问题角度和思维过程的差异，即可认为是认知模型的不同。

 

    时至今日，软件行业已经从实验室和超大机房里走出，成为生机勃勃的产业，其中所涉及的职能角色及其认知模型，也发生了不少变化。

 

3-我们的工作基础

以医院内运行的软件为例，医院内所使用的软件系统，属于典型的行业信息化，严格的行业规范、高度专业的业务知识、复杂多变的需求，形成了目前此类软件系统的开发团队通常由业务分析者、设计开发者、测试、项目部署实施等角色共同构成的局面。

当然，广义的说，还要加上使用该系统的用户。

于是，问题来了：这些人都关心什么。

用户：系统是否符合规范，是否能避免规范中的禁忌，是否能更自动化完成工作，是否可以为管理等决策数据处理提供方便，等等；

开发团队：根据业务需求形成开发任务，保证代码质量，系统可测试，架构清晰，可维护，等等。

形象点说，用户眼里，软件产品是这么形成的：

    *用户认知模型

但在开发团队眼里，软件产品很可能是这么形成的：

*开发者的认知模型

显然，除了起点和终点，几乎没啥一样的，中间不出分歧，才是怪事，分歧大到一定程度，就会变成“焦油坑”（出自《人月神话》，描述的是IT项目由于诸多复杂的问题和影响因素的影响，导致项目陷入混乱的状态）。

举例：

（1）智能排序问题：某个输入框的选项，显示出来大约20项左右，可能出现的数据大约千项。

如果想要根据用户的使用频率，把常用的向前排，显然是个技术含量相对较高的做法。

但实际可能是，用户常用的是相对固定的几项，剩下的用拼音码检索就可以。

 

（2）红色标识：某个数字标签，在大于一定的数值后要标红，系统起初未开发此功能；后来增加，用户高度赞赏。

显然，（2）中所述的功能一般技术上不难，但获得的价值极高；而（1）则反之。

 

除此之外，一些编程阶段的不规范做法，给产品中埋下了若干地雷，比如一些变量未初始化，或简单初始化为0，而这个0对应着第一个选项；或者不可见区域的下拉框选择内容时错了一位，但后续又没有校验措施，都可能会闹出笑话，本文开头的例子，很可能就是软件中存在此类问题。

此类问题的修复在技术上一般也不太困难，但在业务上很可能给用户带来非常大的隐患，现今的医疗工作中，本身医患之间解释沟通的工作量就不少，再加上需要解释软件相关的一些问题，所引来的麻烦与沟通成本可想而知。

 

4-对组织的影响

    目前很多医疗软件公司，在技术团队的组织架构层面，融入了开发者认知模型，通常会将工作岗位划分为：业务分析者，开发者，测试人员，实施人员，数据库管理员等。

    而为了尽可能贴近用户的实际使用场景，提高产品可用性，即解决“用户认知模型”中的“更优化智能的流程”和“禁忌问题规避”两方面问题，某些公司参考了互联网领域的产品经理做法，但由于医疗行业当中智能点和禁忌点过多而且相对分散，尚需结合此类问题的特征，设计标准化模型后方可能有更好的成果。

 

5-回到最初

    个人认为：医疗行业传统的信息化分析与建模等软件工程方法更多的是解决如何将软件从无到有做出的问题。

    在这个过程中，工作的重心是要关注重点功能，并结合技术难度，大量的资源用于处理关键需求与高难度技术任务，以保证项目整体工期与质量最佳平衡。

下一步，各供应商的产品不断完善、技术积累日益丰富，从而会在一个比较长的时期，将软件从无到有做出来的速度有显著提高，但如何从正反两个方向提高产品可用性就会成为核心问题。

正方向：如何从局部到整体的优化流程，由于医疗行业规范严格且数量众多，目前可优化的空间较为有限。

反方向：风险问题分类，估算成本，以风险成本为核心驱动开发过程及分配技术资源。

 

结论：用户的认识模型和技术人员的认知模型有很大不同，在开发角度看起来的一些小问题，可能会给用户造成极大影响。

随着信息化技术的发展，可以考虑选择功能点如果出错，对用户的影响程度这个重要指标来进行需求分级与架构设计等工作。