规范的建立之路：
我曾经和一个UI、一个程序员三个人一起开发过，我给UI的需求从来不写细节，她出的页面也不会返工。甚至到程序的那个部分都是一路绿灯的。我想这样的开发速度是任何文档或者是规范都是不能比的。
但是后来人多了，我就不得不一遍一遍的告诉每一个UI，我的思路是什么，我习惯于怎样去设计，甚至包括我用了什么样的符号在设计文件上，那个是表示什么需求的。这样，容易被UI理解和记忆的被使用了。还有一些不能满足要求的，我不得不按照他们的意见去写自己的需求和设计文件。
这样规范就形成了，新来的产品经理，UI设计师，程序员都是按照这样的方式去作事情。
建立规范的目的是信息的有效传递：
先举个例子，同事去买烟； “哥们，帮我带瓶水回来。”结果这个新来的同事帮我带了瓶矿泉水回来。而如果是老同事的话，一定会给我带一瓶可口可乐回来。
事情的原因在于我没有清楚的说出，我要的是什么。可能规范的目的，就是避免这样理解错误的发生。
从最开始的一段就可以看出，如果只是为了快速的开发，那么最需要的是开发人员间的配合，而非规范。有些时候，这些规范反而会影响到开发人员个人的开发效率。
虽然在理想的状态下，规范可以帮助建立默契，但是规范往往是在第一代或者是某一代开发人员默契的配合下形成的，这个先后的关系在很大的程度上制约了规范在这个已经形成的团队中来发挥这个功能。
结合上两段表述的内容，规范真正要建立的不是本身开发人员中的默契和快速开发，而是为了建立一个传承。让后来的人能在应用种快速的和原来的队伍形成一种默契。
甚至可以有这样一种理解，如果一个规范被推出以后，而且比较合理，成为真正的规范，对于后来的人来说，按照这个规范来作事情，可以节省很多的思维时间。在这里，规范才真正体现了其快速开发的意义。
由此可说规范是必须的，在一定程度上，两个人之间传递的信息，往往会因为个人的习惯不同而产生不同理解，规范在很大程度规范了表达的方式，使得不同习惯的人之间的沟通的信息更加有效。当然，这如果扩展到了两个团队之间，一个团队的规范，可以帮助其他的团队按照这个团队之间的沟通方式快速的组建起来，这更是规范在宏观上的意义。
规范必须是细化的可执行的：
去年我们分管编辑部分的高层给下面一个操作规范，上面写的东西是，编辑要尽量多的添加该频道的资料，资料要尽量的于频道的核心有关系，资料要尽量的对用户有帮助。
看到这个规范，我的第一个反应是想痛打他一顿。
诚然，这些都没有错，但是确是完全没有办法执行的，因为所说的所有东西，每个人都有不同的理解；因此，这个东西只能是一个规则或者是原则，拿给编辑部的主管（当时没有）看看还成。但是拿个普通编辑就……。
一个成文的规范，必须是没有理解歧义，并且是完全的可以执行的规范，如果在任何一个角度，这个条目可以细化下去，那么必须将它细化下去，否则规范在给新人看的时候，他们依然会按照自己的理解去细化这个规范，理解上难免就会有所偏差，起不到传承的目的。
规范的建立是团队的作品：
现在建立规范的方法，往往是一个团队种某个领导人的思路，当然，这可以使得规范文件迅速的形成，但是副作用就是，这个规范文件很可能被尘封。
第一点原因是，建立规范的领导是往往是按照自己的习惯建立规范的，这个是不是符合多数人的习惯是一个问题。
第二点是按照正常的理解，领导的能力往往是比被领导的人是要强的，其建立规范的时候往往是很难考虑员工的理解能力和在这样条件下的发挥能力。
第三点也是最重要的一点是一个人建立的规范，就很难是完全合理的，虽然领导是比较有权利的，但是在这些不合理的地方存在的时候，员工们看待这样规范时的厌恶感情，要求领导必须时刻注意才能推广这样的规范，尤其是在新人进入的时候，而领导往往不是这么有时间来作这样的事情。
所以规范应该是一个公司第一代或者是某一代员工默契配合，工作总结的结果。而并不是什么人强制下去的结果。当然，在有一个合理规范的时候，对于后加入的员工，这个规范能很好的起到传承前一代员工思想和协作的工具。
以上几点只是个人的拙见，欢迎大家批评。
转载请注明出自UCDChina.com，谢谢。
