ＣＡＤ产品研发部　杨晓华

　　拓展运动结束了，我的思索却在继续。
　　与其说这是一次训练，不如说是对我们团队精神的培养。其实，活动中大多数任务通过团体的合作和努力都可以完成，但能在规定时间内完成 “美好愿景”这项任务的团队恐怕没有。
　　常常，成功地完成某项任务并不会让我们留下多深的回忆，而失败却可以成为我们收获经验和教训丰富的来源。毫无例外，我们这个团队在完成“美好愿 景”时，一开始就注定要失败：任务中有一道几何证明题，需要我们一开始就解出这道题，才能按照合理的流程来操作从而得到正确的结果。而在操作过程中，我们 并没想去寻找该问题的几何理论支持，只是理所当然地认为适当的操作流程可以使任务成功，结果可想而知，这是不能通过“验收”的。
　　回头想想，我们的失败在于前期没有认识到潜在的、关键的问题对整个任务流程和结果的影响，否则，即使我们没能找到问题的解决方案，也决不会盲目开 始，甚至以放弃任务为代价。虽然是放弃，它却可以带来潜在收益：没有浪费人力和时间。如果换作是一个项目的开发，那么还可以节省物力，从源头上杜绝了无用 的努力！
　　曾读过一篇题为《代码地震》的文章，其引用的案例是对一个系统的“微小”修改几乎导致了整个项目的失败，在危急关头，项目经理经过重新分析并采取 新的策略才挽救了局面，但是项目已远远超期。相信很多人都遇到过这类“美好愿景”式的开发经历：接受一个项目的时候，并未对其中每一个关键的、可能影响全 局的因素作细致、深入、全面的分析就开始了设计、编码，结果往往是设计、编码人员必须花大量时间来考虑很多本应由项目经理或系统分析人员在开发前期就应考 虑的问题，否则，他们的工作便没法继续，进而影响到整个项目的进程，甚至引起局部或全局的紊乱，导致项目失败。
　　更进一步想，这种问题的根源仍在于团队管理体制和开发体系的不完善上。一个团队要有序高效地运作，必须有一套权责分明的管理体制，否则，团队成员 之间权责不分，遇到问题互相推诿，有了成绩又争相邀功，无法对成员进行职责约束；开发体系的完善则主要依靠合理有效的开发规范，这是团队工作的指南，可以 引导团队成员进行有限但充分的开发工作。
　　我想，如果把“美好愿景”得到的启发也纳入我们规范的运作体系中来，那么我们就不会匆忙、盲目却又无所获了。公司的改革正在如火如荼的进行，我们的开发团队呢？是否也正在从管理和体系上进行探索和改革？
　　相信我们的美好愿景会在明天化为现实。