关于教学行为的操作规范与SOP编制以及软件工程分析方法的关联思考
昨天下午开党务会，会上领导提出为进一步提高党员学习活动和日常教学管理工作的时效性和能动性，要求大家集思广益，出谋划策。洋洋洒洒提出了十个方面，要求就这十个方面进行建议，可谓面面俱到。其中教学管理方面让我想到如何强化日常教学行为的操作规范的问题。当前针对性地为广大年轻教师提供有益的教学辅导成为下学期教学管理中关键性的一步。针对教学行为编制合适的操作程序手册，这有些类似于企业管理中的SOP概念。
所谓SOP,是 Standard Operation Procedure三个单词中首字母的大写 ,即标准作业程序,就是将某一事件的标准操作步骤和要求以统一的格式描述出来,用来指导和规范日常的工作.SOP的精髓,就是将细节进行量化,用更通俗的话来说,SOP就是对某一程序中的关键控制点进行细化和量化.
作为软件开发人员，让我首先想到的是所谓标准作业程序，就是针对某一职业岗位角色的某项作业行为的准确细致的程序化描述。相对于软件工程学科而言，就是用例分析与用例建模的过程。软件工程UML中的几乎所有图形种类都可以在SOP编制过程中起到帮助。比如：
1、用例图的主要目的是帮助开发团队以一种可视化的方式理解系统的功能需求，包括基于基本流程的"角色"（actors，也就是与系统交互的其他实体）关系， 以及系统内用例之间的关系。用例图一般表示出用例的组织关系--要么是整个系统的全部用例，要么是完成具有功能（例如，所有教学过程相关的用例）的一组用例。
2、序列图显示具体用例（或者是用例的一部分）的详细流程。它几乎是自描述的，并且显示了流程中中不同对象之间的调用关系，同时还可以很详细地显示对不同对象的不同调用。
3、状态图表示某个类所处的不同状态和该类的状态转换信息。有人可能会争论说每个类都有状态，但不是每个类都应该有一个状态图。只对"感兴趣的"状态的类（也就是说，在系统活动期间具有三个或更多潜在状态的类）才进行状态图描述。
4、活动图表示在处理某个活动时，两个或者更多类对象之间的过程控制流。活动图可用于在业务单元的级别上对更高级别的业务过程进行建模，或者对低级别的内部类操作进行建模。
关于这些通过Google之后，竟然发现英雄所见略同啊，原来鼎鼎大名的台湾资深IT作家蔡学镛也有同样的简介和体会，不过大家执笔文采奕奕，抄列如下，以资学习：
甚至，日前警方查获的诈骗集团也有SOP，该集团将诈骗手法详细记载成为诈骗执行手册。当诈骗集团也懂得蓝海策略（诈骗手法推陈出新）、知道长尾效应（对准特定小众族群进行诈骗也能获利），并充分运用SOP时，或许也正代表我们社会相当进步，已经进入所谓的知识经济的时代吧。
一般公司内部的运作，处处仰赖SOP。有的公司虽小，但SOP累积多年之后也是厚厚一大本。一般来说，SOP会告诉人员，要怎么做一件工作、处理一件事情、调用公司的资源……等。
这一切，是不是让热爱程序的你有所联想？
把公司看成一个计算机系统，有许多的资源（设备、材料、人员、线程、I/O），每个员工都是一个线程，柜台和仓储是I/O，负责数据的进出，其中，SOP扮演程序的角色，以有效的方式协调、处理、运用这些资源，以达到特定的目的。
如果SOP是在公司内执行的程序，那么，写SOP其实就是写程序，写程序的方法自然也可以套用在SOP撰写上。写程序的经验，对于写SOP，其实是有帮助的。当你需要写SOP，却不知从何下手时，不妨往程序设计的方向来思考。
我认为SOP可以分成三大部分，第一部分是常规作业（Routine），第二部分是事件驱动（Event-Driven）作业，第三部分是例外处理（Exception Handling）。如果你了解程序设计，这三者该写些什么，你应该就会知道。
一个好的SOP应该具备哪些要素？从判断程序的准则来看，应该是：执行效率高且耗费资源少、容易理解、支持跨平台（在不同的分店一体适用）、方便修改维护。
既然SOP是一种程序，那么，也可以采用不同的编程思维（Paradigm），例如面向对象、命令式、逻辑式、函数式。许多时候，用文字叙述的SOP，往往不够清楚，如果能够改用写程序的方式来表达（不使用真正的编程语言，而是使用Pseudo Code），搭配批注，也会是不错的方式。
除了可以套用程序设计思维，写SOP时也可以套用软件工程的作法。或许SOP比较适合采用敏捷（Agile）与反复式（Iterative）的开发方式。因为SOP在执行之后才会发现缺失，就可以继续进行修正补强。别忘了每次的改变，记得要做好版本控制。
UML（Unified Modeling Language，统一塑模语言）支持许多种图，几乎每一种图都可以在SOP内派上用场。UML可以帮助SOP作者编写SOP，也可以帮助读者理解SOP。
和程序设计一样，写SOP不能光靠语言和逻辑，还需要特定专业领域的知识。
例如，写3D绘图的程序，必须先了解3D图学的许多知识。对于SOP来说，专业领域可能是会计、税务、法律……等。所以编写SOP时，最好与了解该领域的人一同合作。
OO的封装和继承也可以套用在SOP，利用封装将资源和动作集中在一起，利用继承将某些方法进行扩充或修改（例如「同A作业，但步骤3更改如下」）。但是OO的多型似乎不可能用在SOP上，所以还是得大量使用switch/case的语法。
另外，逻辑式编程的作法似乎相当适合用在SOP，因为大部分的人都有足够的逻辑能力，可以理解与判断。使用逻辑编程可以让SOP的编写较简洁。当一个资源许多人抢着用时，你就可以引进Concurrency编程的方法。
写程序时，我们要多使用变量，而不是将数据写死在程序代码中，写SOP也是一样，例如，你不应该在SOP内写「把这份数据交给陈水扁」，而是应该写「把这份数据交给总统」。毕竟，陈水扁总有下台的一天。
有许多程序工具可以帮助我们检查程序中的语法／语义错误、Dead Code，甚至Dead Lock、效能瓶颈。但是SOP却没有这样的检查工具，一切只能靠SOP编写者的经验。
所幸，人和程序不一样，人是有弹性的，许多SOP的缺失可能会因为人的介入，能视情况应变而不会发生问题。但是，好的SOP并不能保证公司营运不会出问题，许多公共安全意外发生的原因，是检修人员偷懒，没有确实按照SOP规定的步骤进行维修所造成。
因此，虽然写SOP与写程序相似，但两者终究不同，SOP的执行者是人，不是机器。所以写SOP时，一定要充分考虑到人的因素，纳入人的弹性，排除人的偷懒（或自作聪明），才会写出真正实用的SOP。
作者简介：
蔡学镛－技术顾问
清华大学资讯工程硕士，曾任华硕集团软件工程师、元智大学信息系讲师、美商欧莱礼出版社技术编辑、台湾微软特约专栏作家
没有评论:
发表评论