如何在管理太规范的公司中生存

标题的描述，心底里是贬意的。

比如：cmmi级别很高。一定要分清楚概要设计、详细设计、编码、系统测试等等环节。

设计文档后期总结补充，都是顶得牢的人，顶着干的。连把详细设计和编码作为一个过程来做，都是不允许的。


怎么样？

另：标题有盗....之版之嫌疑。

如果项目的特性确实需要这么搞
又或者公司确实有钱这么搞，不在乎成本
何乐而不为？

是啊，有成本允许的情况下下分清楚不是坏事啊，虽然很多同学天生抵触写文档

是管理的特性要求这样，而不是项目的特性。

应该不关成本什么事情。

不应该抵触写文档,写文档,一个是可以练习思维的严密程度,一个可以锻炼话语能力.
而且大部分抵触是因为不知道怎么写,能够引入文档编写训练的公司,估计也不多.多加练习是很重要的.最简单的练习就是在javaeye发帖的时候,尽量的把要发的内容写清楚,写明白,写的长点,多写出一些可以讨论的点. 别 一句话,两句话就搞定.  实在写不清楚的,采用 "抛弃xxx的爱" (抱歉,实在记不清楚全名了),来个,1,2,3,4,5,6,一条一条的写也好.

文档的写法很有讲究：
①明确文档的目的，读者是谁，是谁需要的。不同的读者，文档的形式和内容是不一样的。比如：读者的编码人员并且是指导编码的，那么文档最好是代码形式的，比如文档的读者评审人员，并且目的是评审的，那么...

②文档写作的时机，在什么时机写文档是合适的。我认为：除非项目特性规定了必须要写什么样的文档(比如客户需要)，那么总结性文档，是最有价值的文档，应该仅量在能够总结的时机来写这个文档。
③文档，本来就是抽象的。而且是需要理解的。我最烦就是长篇大论，无病呻吟。虽然我也经常需要写(是有需求)。

没有人抵触写文档，大家抵触的只是写被别人所约束的文档。比如别人叫你写的东西，你根本就不知道是啥；别人叫的写的东西，你根本就不知道在什么地方；别人叫你写的东西，你根本就看不出有啥意义；别人叫你写的东西，耽误你的时间；等等。其实错不在文档，也不在写文档的人，而在于那些让别人写文档的人。
javaeye3.0推出我，我会把我前些年做的文档写作课的内容放上来，供大家参考、讨论。

删除...

不写文档的人有两类：

一种是O6Z所说的，被约束的文档不写。只写自己喜欢的。

另一种是完全不知道文档写了之后有甚么用，完全不考虑给自己一个便查手册的人。也许这种人还不能算是一个真正的程序员。

有规范好办事。成功的企业大体都有相应的规范，就像号令整齐的军队才有战斗力一样。照着规范办事，比较有保障。