机制缺失的困惑与分析

机制缺失的困惑与分析

吴旻

泰岩网络工作室

 

我设计了一道问卷题，请周围的亲友回答：

中国的每个城市都有110、119、120、122等急救电话，现在假设110（或者119）取消了，请问你在遇到刑事案件（或火警）时，你会怎么做？

我收集到的答案大同小异，基本上是需要110却没有时会打119，需要119却没有时会打110。

我进一步提示说，其实119是解决不了110的问题的，消防人员有防毒面具，但毕竟没有防弹背心，水枪也无论如何不能制服恐怖分子的手枪；反之亦然，110手中的枪是救不了大火的。

我接着收集到的答案是：选择120、122更不靠谱！

我仔细分析了一下他们的潜意识：虽然110和119之间基本上没有可替代性，但人会本能性地去寻找一个更接近可能的选择：与120、122相比，110和119相似性还是要高一些的。

如果假设上述情况真的发生了，那么119的工作人员一定是叫苦不迭！人民群众遇到危难报警没有错， 119接警出警也没有错，但119干不好110该干的事情也是一定的！工作做不好，人民群众一定不会满意，没准还会将怨气出在119身上；而应该挺身而出的110，却反而没什么责任了。

 

事情有时候真的就是这么怪。比如有如下的开发场景，请软件开发人员进行开发设计：

某公司要实时监测生产线上工人的工作效率，展现在监控人员面前的显示终端上的数据是：

1、员工ID（int型数据，4字节）；

2、员工姓名（char型数组，8字节）；

3、工作效率（float型数据，4字节）；

一般情况下，我们会这样考虑：数据采集端根据员工ID采集到工作效率，然后将这两个字段（共8字节）上传到显示终端，显示终端再根据员工ID找到员工姓名，最后将三者一同在屏幕上显示更新。

现在的开发情况发生了一点变化，就是终端显示开发人员说，我们没有开发通过ID查找姓名这个功能（实际上是应有的机制缺失），数据采集开发人员能不能将员工姓名也一同上传过来（显然，数据采集端拥有这一查找机制）？说白了，就是将原来一次传8字节，改为上传16字节，以替代终端显示相关机制的缺失。

话说到这个份上，一般情况下，无论是开发人员还是技术主管，都会觉得改成一次上传16字节简单而又方便，但对无形中埋下的隐患，大家都倾向于视而不见：

1、通信量加大一倍。在数据量比较小时问题当然看不到，但当数据量大时，数据采集和监控终端又不在同一地理位置时，问题就马上变得不可调和了；

2、功能定位失当导致扩展开发困难。比如，客户觉得员工性别和年龄也是个重要参量，也要在终端显示时，这个查询工作谁来做？

3、责任不清导致管理混乱。出现问题时应该担责任的没责任，不该担责任的却被牵连。就像119干不了110的工作一样，硬性替代的结果只能是大多数人不满意。而且以后再出现类似问题时，由哪一方来解决更是让人头痛，吃亏的人不可能愿意老吃亏，占便宜的人得到甜头肯定还是愿意接着功能缺失。一个缺少公正从而导致互相推委的团队，是不负责任的团队，也是无法将工作越做越好的团队！

4、机制缺失是严重的功能性障碍问题。比如软、硬件问题的应急处理，如果出现不能工作的情况，如何处理？是让用户等到问题解决为止，还是马上启用一套备用方案，以满足用户的最基本需求？古人说，凡事预则立，不预则废，我们的相关负责人员，不妨多想一想。

 

我见过的最幽默的项目负责人，对我上面项目场景的回答是：遇到这种情况，我们一般是将数据压缩了以后再传出去，这样就没事了。

我当时听完这话以后，脑子都木了，这个答案太超乎我的想象力了！我半天才明白，他不知道16字节一组的压缩意味着什么，也不知道压缩算法给整个项目带来的复杂度是多少！或者在他眼中，只要能解决眼下问题的工作人员，都是能干的。

 

碰到这样的项目负责人，软件开发这件事，就真的不是人干的活了！

一笑。