标签：项目经理 项目管理 死亡行军 项目经理是救火队长 代码之殇
在一些企业中经常会发生这样的事情，公司业务繁忙，项目堆积成山，开发团队总共也就六七个人，恨不得一个人当两个人使，行内话称：”女人当做男人使，男人当做牲口使“，急于改变现状的项目经理更是焦头烂额，满脑子的念头就是”怎么办？怎么办？？？“。好吧看来我需要参与进来了，于是挽起袖子开始了一次《速度与激情》的编程之旅。
那我问你，你的准备工作做好了吗？你是最初接触项目需求的人，可能在你的脑海里，你的笔记本上画满了各种各样的符号，图示，用例，你的电脑上有各种各样的UML，一切看起来都是那样的个性和专业，请问你有没有想过你明白的需求，你手下的员工有没有明白，你可能会鄙夷的的告诉我：“嗱，这不是都给他们了吗！“；好吧那我们现在就看看你给手下成员的”需求说明吧！“
非常不错，看来你对xmind用的非常熟练，上面总共分为七大功能块，每个功能块有对应的查询项目和数据编辑项目，除了满篇的删除操作外，我想我和其他员工一样从中只能获取这样的信息量，试问用户数据都是非常重要的，我能这样轻易地删除数据吗，第一个问题：这些数据要不要进行备份，备份的模式是什么移动到备份表还是在表中添加字段进行假删除操作？第二个问题：多个关键词的标签合并，有没有牵扯一些规则，还是说所有任意的几个关键词我可以随意进行合并？第三个问题：邮件发送可选，那么邮件发送的频率有没有限制，发送的时间有没有限制等等等等……
当这些问题接踵而至出现在基层开发人员脑中的时候，他们又会以何种方式去处理呢？经过我的经验大概有这样几个场景：
（1）、程序员A（思维明锐，善于交流型）：直接去找项目经理，这块的需求应该具体是什么样？然后项目经理开始了滔滔不绝的讲解。
（2）、程序员B（思维明锐，不善于交流型）：展示我能力的时候到了，既然是删除，这样的需求又不明确那我把假删除和数据备份的方式都做上吧。
（3）、程序员C（思维迟钝，不善于交流型）：删除就删除，功能看起来很简单，早就想把那些烦人的信息全部删除掉了，然后一个delete语句搞定。
（4）、滑头型（喜欢照猫画虎，钻空子）：这个功能先放一下先做其他的，等A,B,C做好了这些我随便问一下他们调个接口不就完事了吗，看我多聪明。
一个月后，客户怒气冲冲的打来电话，“张总，我只是点了一下按钮为什么我所有的客户数据都没有了，你们这样的产品我还敢用吗.. ….“。
看看吧，你还认为你的“需求文档“是这样的完美么？当一个项目这样走下去的话，那么不单单是项目的生命周期要截止了，我想连公司和老板的生命周期也要截止了吧，如果你老板心宽或许会躲过一劫。
通过上面的例子我们应该能够深刻的体会到一个详尽完善的需求说明，对于项目开发工作来说是多么重要的一件事情，建议一些团队在项目开发前让每个人都能对项目涉及的需求，功能有一个明确的认知，或者文档说明，或者立会学习，模拟探讨，鼓励员工了解业务。古语云：“磨刀不误砍柴工“，如果需求不明确即便是都遇到像A这样称职的程序员不厌其烦的奔波于你和他们的办公桌之间，我想整个团队的工作效率将大打折扣，事与愿违，得不偿失。
而相对一个项目的管理者，你的职责和本分是管理好项目，做好项目的整体控制，而不是挽起袖子去进行实际操作，你见过打仗的时候打仗元帅充当敢死队队员的例子吗？有时候不要浮于表面的努力，不要去时时刻刻充当救火队长的角色，如果遇到资源不够的情况，既然公司是为了赶时间盈利，就应该和老板去讨论进人的事宜，我想迫于你的专业性和压力应该能够说服老板，《代码之殇》中写的很好，死亡行军只会导致更糟糕的代码和质量，只会换取团队成员的萎靡不振，其他什么也做不到，个人觉得一个公司如果项目经理扑在编码上抽不开身，不能从全局把控团队的运作，那这个公司无论是管理还是运作一定非常混乱。
不知道大家是否也有同感，如有问题可以留言讨论，谢谢。
标签：项目经理 项目管理 死亡行军 项目经理是救火队长 代码之殇
原文地址：http://blog.csdn.net/qq355667166/article/details/24621015
