为咩运维管理系统1.0不好用？

写在最前

我看到运维管理系统的需求文档、原型图、以及做了一半的产品时是非常震惊的，当时的内心是酱紫的

咩？这什么鬼啊

因为该项目之前由一研负责，这也导致了我基于该项目对一研的开发能力评估有所偏颇，现在想想确实应该好好静下心来复盘下，既然要复盘就要把事情交代清楚，以下可能会唠叨蛮多的，要是事情多或者知道我这人话唠的现在就可以Alt＋F4／左上角返回。

背景资料

先把基础资料库列下吧，以下需求内网git权限才能访问：

• 运维管理系统的需求文档
• 运维管理系统的原型图
• 运维管理系统

我知道大家都很忙，以上链接都不会点的

呵呵

所以我大致贴下：

功能需求.png

功能需求.png

rp列表

来龙去脉

• 2016.10.15 该项目开启
• 2017.05.11 变更部分需求
• 2017.07.10 二研接手该项目
• 2017.08.14 提交第一轮测试
• 2017.08.31 完成v1.0发布
• 2017.09.22 完成v1.1发布

我知道大家都很忙，以上时间表是不会看的，那我就说重点了，开发历时约1个月

看下图

时间线上就是酱紫

产品开发

1. 收到产品需求后，我的理解是运维管理系统的核心中是工单，而目前市面上开源的、收费的工单管理系统一大堆，我挺纳闷为什么我们不用现成的，要花这么多人力做，所以我们花了点时间去比对：

主要任务点

2. 结果大家都看到了，后端基本没怎么改，还是用原来那套，至于原因嘛，因为太技术向了，就不在这唠嗑了。

3. 运维的主要时间是花在前端框架改版以及将原先一堆自己做的基础件换成更加稳定靠谱的第三发服务，顺便吐槽下之前的前端简直无法直视，代码我就不贴了，有兴趣的小伙伴可以翻svn记录。

4. 这是最重要的一点，原有方案居然想在QQ和微信上实现IM功能，这是我最崩溃的一点，有木有搞错啊！！！Pony和小龙会不会把我们砍了啊？！

请叫我Pony

5. MD，初来乍到，产品不但已经评审定稿而且还开发了一半，这时候改需求会不会被关小黑屋，但是IM的实现哪里是几个人的小团队可以完成的，之前怎么做得技术评估？真以为即时聊天就是收发消息调调websocket这么简单吗？可以有点技术前瞻性和对未来风险的预估意识不？嗯，这就是开篇我心里那头［咩］的草泥马的详细说明。于是，我做了个重要的决定...

6. 砍掉现有IM代码，换成网易云通讯（同一时间我们对比了4个方案，整个切换花了2周多的时间）

7. 后来的事大家就都知道了，在IM上做IM即使技术栈上过关了，体验上也很差

小结下，在运维管理系统的开发过程中我们一共做了这几件事

• 比对同类开源产品
• 抛弃已有前端，重写
• 升级已有方案中的技术，不自己造轮子
• 抛弃已有IM，替换成网易方案

就酱

反思

嗯，好像把锅甩的差不多了,可是为咩运维系统1.0不好用捏？

hello world

要回答这个问题其实很简单，可以运用经典的“把大象放进冰箱四步骤”来解答，详情如下

1. 首先，运维管理系统1.0真的不好用吗？

• 是的

2. 其次，运维管理系统1.0具体哪里不好用？

• 操作流程Coder思维明显，操作不方便
• 不支持跨部门协同，所有功能停留在［客服］层面
• 表单数据内容、常用字段、汇总信息的各项细节及表现形式不是用户要的
• 与火影无法实现数据互通，一件事要在2个系统各做一遍

3. 再次，为咩运维管理系统1.0会做成这样不好用的系统

• 我发现需求不合理、设计不合理、实现不合理时因为怕被关小黑屋没有大声说出来，没有体现一个Leader应有的担当
• 我没有在需求升级（SODC建立，客运研一体化）后第一时间跟进，导致产品与实际业务脱节，一个不能满足现有业务需求的产品怎么可能好用
• 如需求文档可信，则当初需求提出方与需求采集方沟通机制存在问题，我缺失在接手产品后对需求进行二次确认的操作；如需求文档不可信，那就真没办法了，低头背锅不说话
• 与火影相关的，以一研为准

4. 最后，怎样可以把运维管理系统做好

七代目火影