记蜂巢新版OMS项目失败的原因

---

1.团队士气不足

团队做项目，就和带兵打仗一样，士气不足一定是很难完成目标的。经历了2015年创业初期的疯狂和2016年快速发展带来的喜悦，同样经历了15和16年没有年终奖的现实。在公司的快速发展和自身薪资待遇方面的落差后，人都是会疲惫的。2017年同样又进入了业务发展的瓶颈期，新版的OMS系统已经经历了两次改版和设计，内部和外部矛盾都在不断加大。此时提出了需要再次完全打翻之前的OMS系统，要做一套新版的，面向客户的OMS系统来，并且在原有OMS系统的基础上增加了相当多的新有功能，需要整合原有WMS系统，以及增加新的TMS，PMS独立模块，SKU独立模块。每个人都没有必胜信心的前提下，是很难打赢胜仗了。

2.团队人数不够

提到需要做新版的OMS系统，附属还有PMS，TMS，WMS，SKU的改造。最后是怎么安排人数的呢，TMS系统一名开发负责，SKU系统一名开发负责，WMS系统和OMS系统，由四名开发（其中两位还需要处理现有OMS系统的需求与维护）与两位应届生负责。对应的测试有两位，在后来不够加到了三位。开发模式选择的是Scrum，测试内部使用重新开发的自动化测试。首先说开发这块，有些系统居然只由一名开发负责编码前后端，并且系统间还需要相互协作数据流转，并且有相当复杂的多层策略。测试在需求不明确，以及人数相当少的情况下，选择了从头开发自动化测试，也与Scrum模式的快速开发相违背，最后造成的结果就是大量sprint完成后没有办法及时测试，出现的问题修复后也很难做到及时测试和回归测试。

3.项目本身设计失败

一个中大型项目，是需要很严格的设计与把关的，在开发和测试人手不足的前提下，需求分析反而有五位，理论上应该可以提供一份相当详细和完美的需求说明书。然而因为别的同期并行项目以及之前提到的士气问题，并没有能全部投放到新项目的设计中来。开发使用的Scrum模式，需要的是快速开发，口头约定其实大于书面文档，但因为需求的频繁变动，口头约定并没有起到任何效果。在协作过程中，也没有做到非常流畅的沟通。多系统之间的交互也没有清晰的定义，造了大桥要合拢的时候发现完全合不上了。设计方没有能听进开发和测试的建议，也没有对整个中大型系统进行通盘的考虑，光执着于细节复杂功能的设计。

4.缺乏有效管理，流程管控不足

上文中提到，开发使用了Scrum模式，测试与开发对设计需求的一再改版已经相当疲惫等情况，也没有引起重视，没有及时的措施去补救。Scrum模式需要每日有一个进度分享以及困难说明的短会，也没有能够坚持下去，造成后期部分开发一周的任务即使遇到瓶颈也不提出，任务不停的延后到之后的Sprint中。每一个Sprint需要有一个最后阶段产品的展示，也因为需求的频繁变更，以及管理对阶段展示的不重视，导致缺失了这个关键步骤。最终开发，测试，需求都变成了“散养”状态，乐意做就做一点，不乐意就一直拖着不做。谁也催不动谁，谁也没有动力去催动谁了。

5.执行力低下

因为种种原因造成的执行力低下，其实是压死骆驼的最后一根稻草。其实一切问题，靠沟通和努力都是可以解决的，就怕大家的心累了，觉得没有希望所以也不去解决。内心都觉得这个系统做不起来，最后自然系统是做不起来的。其实本来可能是个比较小的改动，说一声也就改了，到后面就会变成。开发的时候，你先去找设计做需求，做完需求再来找我；部署的时候变成，你怎么又要部署了，好麻烦；测试的时候，这个没有文档我不测试；需求设计的时候，这个也要我设计吗，你们看看之前的逻辑不就知道了。最后什么也做不成也是很正常的事情了。雪崩的时候，没有一片雪花是无辜的。

写这篇总结，也不是要去责怪谁，也不是要去推卸责任，每个人都有自己没做好的那个部分，换了别人在当时的岗位上也不一定就能做的更好。希望在之后的工作中，能够以更积极的心态去面对每一天的工作。