在大连订单管理软件开发的过程中，一些技术人员给他留下了深刻的印象。等到解决掉所谓的技术难点，项目进度已经开始有点滞后了。所以他要求项目成员加班加点追赶进度。不久，项目开发工作结束了，尽管有点延迟，但还算交代得过去。噩梦从测试阶段开始了。无数的bug冒了出来。他每天都疲于奔命，安排开发人员修改这些bug，项目最终延迟了两个月。

最后，在项目总结会议上，项目经理把这次不成功的实践归结为三点：第一点，这是一个时间很紧的项目；第二点，项目中的技术难点没有充分估计；第三点，部分软件开发人员质量意识太薄弱。项目经理的老板似乎看得稍远一些，他认为，项目中应该采用一些敏捷的软件开发方法。 会议结束后不久，新的项目又开始了，项目经理又开始制定新的计划，并重复着刚刚发生不久的故事。 小程序软件开发和订单管理软件开发在开发过程中有很多相同地方。

在上面的故事中，我们提到了大连订单管理软件开发项目管理的问题，在第9章中，我们会进一步展开这个话题。这里想问的是，谁应该对这一个项目负责呢？ 我们再来看一个故事。 两年前，公司开始研发新产品。研发部门成立了一个技术小组。这个技术小组有一个Leader，五个成员。每个成员都有自己的分工，例如，技术平台、领域模型、集成框架等。这种分工几乎是自然形成的，因为在进入技术小组前，这些成员就已经在从事相关的工作了。 研发项目启动后不久，Leader召集了一次会议，他希望每个成员可以定期介绍自己研发的阶段性成果。在成员A介绍自己的设计思路时，成员B表达了自己的看法，紧接着，成员C也临时产生了一些想法，他建议的设计方向获得了大多数与会人员的赞同。

只有成员A仍然在坚持自己的想法，会议渐渐演变为一场讨论和辩解。 Leader对会议的气氛感到非常满意，但是对于成员A的固执己见有些不满。他做了一个决定，要求成员A采用成员C的方案，并结合成员B的想法对自己的设计思路做出修改。经过这一次会议，Leader感到有必要更加频繁地召开类似的会议，希望借助于团队的力量获得最佳的方案。 两年后，新产品出炉了。但是在应用到大连订单管理软件开发项目时，发生了谁也没有预料到的问题，如性能问题。这个性能问题来自两年前成员C的想法。为此，研发部门成立了一个性能调优小组，并投入高额的维护成本。