PM会经常遇到半路接手的项目，此类项目如果规模不大，还算好办，如果遇到一个比较复杂且周期较长的项目，可能就会比较头疼。很多问题不知从何着手予以解决，也不知解决了此问题是否还会引发其它的问题，手头资料一大堆，真正有帮助的又不知道有哪些?项目的进展完全依赖于项目组的”老“同志，老人员的流失对项目而言将是”灭顶之灾“，很多内容需要重新发现、整理、解决。再加之如果项目有压力，那PM主要的工作就是在补洞了，被项目所牵制，而无法真正的主动地规划项目、推进项目。最终，也只能马虎上线，遇到问题再说吧。

　　其实，类似这种不规范的项目管理行为，对自身的项目也会造成很多影响，多数情况下是项目进展到一半的时候，问题就开始暴露了，如果再不加以重视，实际上最终的结果也会和前面描述的差不多了，可谓苦不堪言啊。

　　需要与很多人沟通过这个问题，大部分人都认为是管理所造成的，如果说建立规范的管理制度，100%的人员都赞同，但真正你去建立并推行之时，却又发现实际并非如此，阻力极大，困难重重，当初赞同的人也开始有了反对意见，仔细分析无非以下几点：

　　1、项目压力大，进度紧;

　　2、规范永远是对下不对上，所以最终”下面“的人也不规范了;

　　3、规范不合理，弊大于利，对正常工作造成了影响;

　　4、规范是好，但不切实际，应用难度大;

　　规范制度是一把双刃剑，用的好，获益匪浅，用的不好，无疑是给自己　3)、需求管理：必要，项目的质量就是需求来明确的。需求管理的方式很多，选择适合自己的，但一定要有，并且一定要考虑到后期需求维护占总工作任务的比重，不要因为后期的时间紧而放弃维护。如果采用工具，则建议使用 RequisitePro，RequisitePro可以实现project的数据共享，但好像是单向的。

　　4)、版本控制：必要。如果采用微软的技术体系，建议使用微软的VSS，如果是其它技术体系，自由选择吧，CVS很不错。不建议采用并行开发，然后在合并代码。版本控制有时会很复杂，尤其是针对上线项目进行的二次开发，宁可多做点工作，不要搞出一个太复杂的流程，还是那句话，不要把团队搞晕了。

　　5)、变更控制：必要。不多说了，尤其项目到了后期，每次的变更都一定要做记录，且要认真分析。

　　6)、编码规范：必要。如果什么都没有，代码就是你的财富了，所以重视起来吧。

　　7)、风险控制：可要可不要，针对小且风险低的项目，建议变换方式，可以做一个技术问题风险清单，其它的可以放弃。如果觉得风险控制难度大，太抽象，则自己整理一个项目问题列表出来，包括项目中遇到的所有问题及解决方案。

　　8)、验收制度：必要。可以根据实际情况控制验收单位的颗粒度。但一定要有，确保有效工作成果的提交，不要走回头路，这是最后的可控环节。其中包括了测试管理。针对测试如何来做，是要依据团队能力及项目其它要素来制定的，不过一定要有，要做为验收的依据使用。

　　9)、沟通管理：可要可不要，视项目团队而定。没有沟通管理并不意味着没有沟通，这方面要靠PM主动。古人有句话”前人栽树后人乘凉“，项目管理亦是如此。PM不会跟着项目一直走下去，会交出项目的，同时你也会接受别人的项目，团队也是铁打的营盘流水的兵，所以，做好这些工作吧，于人于己都是有必要的，说的大一点，还可以为提升整个行业的规范性奉献自己的努力呢，何乐而不为呢?

　　项目管理培训准备的带刃的剑。实际上，规范也好，制度也罢，都是服务于管理者与被管理者的，而且是要有效组织生产关系，提高生产力的。那么，对PM而言如何去制定一个适合自己团队的规范呢，哪些是必要的，哪些是可要可不要的，哪些又是累赘呢，简而言之可以从几点来考虑：

　　首先：切记，规范不是拿来主义，别人用的好的，到了你这里未必适合，一定要分析自己的项目规模、团队大小、团队组织结构、团队素质能力等等，才可确定到底该如何去制定规范。这里要明确说的就是团队素质问题，团队素质并非是指其专业能力，也并非指其人的素质能力，而是指其工作背景，是否具备此方面的工作经验和工作习惯，毕竟程序员的随意性和自我意识都是比较强的，突然给出一个框框，员工会很不适应的，造成的抵触影响也会很大。

　　其次，规范是否真的有效，还是就是走一个形式，每一种规范到底的目的是什么，是否能真的为我们带来什么好处呢?是否在制定一种规范前，都认真考虑过它呢?并且是从管理者和被管理者两个角度来考虑呢?工作日志，有助于帮助管理者跟踪工作进展，发现问题，对于被管理者有助于提升自己的工作效率，总结自

[1] [2] 下一页