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

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

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

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

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

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

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

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

其次，规范是否真的有效，还是就是走一个形式，每一种规范到底的目的是什么，是否能真的为我们带来什么好处呢？是否在制定一种规范前，都认真考虑过它呢？并且是从管理者和被管理者两个角度来考虑呢？工作日志，有助于帮助管理者跟踪工作进展，发现问题，对于被管理者有助于提升自己的工作效率，总结自己的工作业绩，甚至在写自己的工作汇报时都可做为参考。那其它的规范呢？例会是很有必要的，那例会的议题和例会的周期确定了么？确定的合适么？曾经有个项目是以天为单位的例会，主要内容就是工作汇报，我个人觉得意义不大，因为划分工作任务的最小完成周期也是三天以上，基本上每天的例会都在重复昨天的内容，连说的都一样，浪费大家的时间。但为什么不去考虑改变呢？或者换种方式来进行。

再次，规范是帮助团队的，这个帮助主要是体现在：提高团队沟通有效性、增强团队协作性、规范团队工作行为、规范工作边界，杜绝隐患发生，提前暴露风险等等，但绝对不是增加团队工作量的，增加团队工作复杂度的，搞个工作流程出来要简单有效，划分责任边界，加强沟通，提升效率，不是搞个流程出来把大家搞晕了，如果用几句话都讲不明白的规范制度，不要也罢。

最后，也最为重要，规范推行一定要慎重，可行可不行的就应该放弃，既然规范制定了就一定要执行下去，不能半途而废，这样极不利于后期的工作。即使规范不多，但有效，大家都可以执行就是好的，要知道规范是双刃剑，毕竟是有弊处的。

在此总结了一些常见的内容，因为做了尽可能的拆解，所以彼此没有太多的关联，仅供参考，希望对大家有所帮助。

1) 、计划管理：可要可不要需要针对项目的具体情况来具体分析。但不需要计划管理，并不意味着不要计划了，明确这一点。如果采用工具，首推MS Project。

2) 、工作日志：必要。无论项目大小都很重要。并且一定要将工作日志的内容与工作任务进行结合，以实现进度跟踪。针对突发性、临时性的任务，也可由工作日志提交，PM汇总从而得到最终的项目进度。如果采用工具，则还是建议使用projectserver来完成。工作日志一定要看，发现其中的问题，很多时候程序员都会通过工作日志来反映问题及风险，认真对待，不要马虎，你马虎，就代表了团队也会马虎的，也不要让你自己的不经意行为打击了团队的积极性。

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

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

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

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

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

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

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

原文地址：http://www.amteam.org/k/PM/2008-12/615116.html