千里之行，始于足下，无论你有多么的豪情万丈，总要从最基础的东西做起。

　　然而要做一个好的基层工作人员，并不是低头认认真真写好代码就可以的，其中可大有学问。

　　按照余世维所论，一个好的下属应该：

　　主动向上司汇报你的工作进度——让上司知道！
　　对上司的询问，有问必答，而且清楚——让上司放心！
　　充实自己，努力学习，才能了解上司的言语——让上司轻松！
　　接受批评，不犯两次过错——让上司省事！
　　不忙的时候，主动帮助他人——让上司有效!
　　毫无怨言的接受任务——让上司圆满!
　　对自己的业务，主动提出改善计划——让上司进步！

　　我也总结了如下几点，欢迎大家补充。

　　(1) 做得快还是做得好？

　　当前的项目管理中，多是强调结果的，号称结果导向或者结果驱动。

　　作为一个基层，做人重要，做事更重要，除了良好的沟通能力，能拿得出真金白银的成果，更是每个项目经理愿意看到的事情。

　　然而怎么叫好的结果呢？

　　一九五八年党的八大二次会议上，提出多快好省的建设社会主义。多快好省四个字即体现了前辈革命家的理想壮志，也成为后来中国管理者心中的梦。所以我们时常听到如下的话："这些功能下个月一定要出来"，"代码质量要高，要有详细的注释，测试用例，code review"，"最好提前一周至少三天，可以准备demo"，"项目现在经费相对比较紧张，希望大家克服一下"。

　　然而现代的项目管理给我们画出了如下的三角形：

　　范围，预算，时间三者相互制约，牵一发而动全身。欲范围大(多)，就应该增加项目预算(不省)，如增加人手，增加资源，买第三方成品，或者应该延长时间(不快)，如推迟release的时间等。欲按期完成(快)，则可以增加预算(不省)，或者减少功能(不多)。

　　然而现实中，老板可不这样想，预算是早就做好了的，时间也是确定了的，功能缺一不可，作为基层的程序员我们唯一可以影响的就是用加班换来更多的时间，当然还有中间的一个圆圈——项目的质量。

　　到底是尽快的做出一个实现基本功能但设计稍有缺陷，测试不太完备，有少量的Bug的版本出来然后慢慢改进呢，还是经过慢慢的精心设计，做出有完备的测试用例，经过严格测试少有Bug的版本呢？

　　这个问题如果你问程序员，大部分人会选择后者。尤其对于初涉职场，充满激情的程序员们，往往满脑设计模式，满口软件工程，几乎见不得注释中的错别字和没有覆盖到的测试边界，似乎一个不完美的方案就有辱于软件工程师的名号了，我们称之"技术洁癖"。

　　如果你问项目经理，也会告诉你后者，而且最好以后者的形式用前者的时间(多少有些多快好省的味道)。然而很少有项目经理会直接看你的代码，更不关心你用的何种设计模式，也不会一个个看你的测试用例来思考是否覆盖所有的边界，更不会看你写的注释了。

　　所以很不幸，除了少数精通技术，熟悉细节，了解程序员苦衷的项目经理外(这可是大多数程序员都翘首以待的领导啊)，大部分喜欢前者。

　　因为精心的设计，良好的文档是需要大量的时间，完备的测试用例的代码量几倍于实现本身，功能测试，性能测试以及Bug的修改更是难以估计时间的，所以总的时间将几倍于前者的时间，在此过程中，你献给项目经理的，除了等待，还是等待。

　　人是不喜欢等待的，尤其是很少反馈的等待，当我们用windows的时候，往往会出现估计时间相当不准确的进度条，然而我们还是喜欢看着进度条一直走到底，同样项目经理也是。

　　总是能够很快的做出项目经理能够看到的版本，便容易给人一种能力很强的感觉，至少大部分人会这样认为。