再次，规范是帮助团队的，这个帮助主要是体现在：提高团队沟通有效性、增强团队协作性、规范团队工作行为、规范工作边界，杜绝隐患发生，提前暴露风险等等，但绝对不是增加团队工作量的，增加团队工作复杂度的，搞个工作流程出来要简单有效，划分责任边界，加强沟通，提升效率，不是搞个流程出来把大家搞晕了，如果用几句话都讲不明白的规范制度，不要也罢。
最后，也最为重要，规范推行一定要慎重，可行可不行的就应该放弃，既然规范制定了就一定要执行下去，不能半途而废，这样极不利于后期的工作。即使规范不多，但有效，大家都可以执行就是好的，要知道规范是双刃剑，毕竟是有弊处的。
在此总结了一些常见的内容，因为做了尽可能的拆解，所以彼此没有太多的关联，仅供参考，希望对大家有所帮助。
1）、计划管理：可要可不要需要针对项目的具体情况来具体分析。但不需要计划管理，并不意味着不要计划了，明确这一点。如果采用工具，首推MS Project。
2）、工作日志：必要。无论项目大小都很重要。并且一定要将工作日志的内容与工作任务进行结合，以实现进度跟踪。针对突发性、临时性的任务，也可由工作日志提交，PM汇总从而得到最终的项目进度。如果采用工具，则还是建议使用projectserver来完成。工作日志一定要看，发现其中的问题，很多时候程序员都会通过工作日志来反映问题及风险，认真对待，不要马虎，你马虎，就代表了团队也会马虎的，也不要让你自己的不经意行为打击了团队的积极性。
3）、需求管理：必要，项目的质量就是需求来明确的。需求管理的方式很多，选择适合自己的，但一定要有，并且一定要考虑到后期需求维护占总工作任务的比重，不要因为后期的时间紧而放弃维护。如果采用工具，则建议使用RequisitePro，RequisitePro可以实现project的数据共享，但好像是单向的。
4）、版本控制：必要。如果采用微软的技术体系，建议使用微软的VSS，如果是其它技术体系，自由选择吧，CVS很不错。不建议采用并行开发，然后在合并代码。版本控制有时会很复杂，尤其是针对上线项目进行的二次开发，宁可多做点工作，不要搞出一个太复杂的流程，还是那句话，不要把团队搞晕了。
5）、变更控制：必要。不多说了，尤其项目到了后期，每次的变更都一定要做记录，且要认真分析。
6）、编码规范：必要。如果什么都没有，代码就是你的财富了，所以重视起来吧。
7）、风险控制：可要可不要，针对小且风险低的项目，建议变换方式，可以做一个技术问题风险清单，其它的可以放弃。如果觉得风险控制难度大，太抽象，则自己整理一个项目问题列表出来，包括项目中遇到的所有问题及解决方案。
8）、验收制度：必要。可以根据实际情况控制验收单位的颗粒度。但一定要有，确保有效工作成果的提交，不要走回头路，这是最后的可控环节。其中包括了测试管理。针对测试如何来做，是要依据团队能力及项目其它要素来制定的，不过一定要有，要做为验收的依据使用。
9）、沟通管理：可要可不要，视项目团队而定。没有沟通管理并不意味着没有沟通，这方面要靠PM主动。古人有句话“前人栽树后人乘凉”，项目管理亦是如此。PM不会跟着项目一直走下去，会交出项目的，同时你也会接受别人的项目，团队也是铁打的营盘流水的兵，所以，做好这些工作吧，于人于己都是有必要的，说的大一点，还可以为提升整个行业的规范性奉献自己的努力呢，何乐而不为呢？
推荐阅读：
更多内容进入：