千里之行，始于足下，無論你有多么的豪情萬丈，總要從基礎(chǔ)的東西做起。

然而要做一個好的基層工作人員，并不是低頭認認真真寫好代碼可以的，其中可大有學(xué)問。

按照余世維所論，一個好的下屬應(yīng)該：

　　主動向上司匯報你的工作進度——讓上司知道！

　　對上司的詢問，有問必答，而且清楚——讓上司放心！

　　充實自己，努力學(xué)習，才能了解上司的言語——讓上司輕松！

　　接受批評，不犯兩次過錯——讓上司省事！

　　不忙的時候，主動幫助他人——讓上司有效!

　　毫無怨言的接受任務(wù)——讓上司圓滿!

　　對自己的業(yè)務(wù)，主動提出改善計劃——讓上司進步！

我也總結(jié)了如下幾點，歡迎大家補充。

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

　　當前的項目管理中，多是強調(diào)結(jié)果的，號稱結(jié)果導(dǎo)向或者結(jié)果驅(qū)動。

　　作為一個基層，做人重要，做事更重要，除了良好的溝通能力，能拿得出真金白銀的成果，更是每個項目經(jīng)理愿意看到的事情。

　　然而怎么叫好的結(jié)果呢？

　　一九五八年黨的八大二次會議上，提出多快好省的建設(shè)社會主義。多快好省四個字即體現(xiàn)了前輩革命家的理想壯志，也成為后來中國管理者心中的夢。所以我們時常聽到如下的話："這些功能下個月一定要出來"，"代碼質(zhì)量要高，要有詳細的注釋，測試用例，code review"，"好提前一周至少三天，可以準備demo"，"項目現(xiàn)在經(jīng)費相對比較緊張，希望大家克服一下"。

　　然而現(xiàn)代的項目管理給我們畫出了如下的三角形：

　　范圍，預(yù)算，時間三者相互制約，牽一發(fā)而動全身。欲范圍大(多)，應(yīng)該增加項目預(yù)算(不省)，如增加人手，增加資源，買第三方成品，或者應(yīng)該延長時間(不快)，如推遲release的時間等。欲按期完成(快)，則可以增加預(yù)算(不省)，或者減少功能(不多)。

　　然而現(xiàn)實中，老板可不這樣想，預(yù)算是早做好了的，時間也是確定了的，功能缺一不可，作為基層的程序員我們可以影響的是用加班換來更多的時間，當然還有中間的一個圓圈——項目的質(zhì)量。

　　到底是盡快的做出一個實現(xiàn)基本功能但設(shè)計稍有缺陷，測試不太完備，有少量的Bug的版本出來然后慢慢改進呢，還是經(jīng)過慢慢的精心設(shè)計，做出有完備的測試用例，經(jīng)過嚴格測試少有Bug的版本呢？

　　這個問題如果你問程序員，大部分人會選擇后者。尤其對于初涉職場，充滿激情的程序員們，往往滿腦設(shè)計模式，滿口軟件工程，幾乎見不得注釋中的錯別字和沒有覆蓋到的測試邊界，似乎一個不完美的方案有辱于軟件工程師的名號了，我們稱之"技術(shù)潔癖"。

　　如果你問項目經(jīng)理，也會告訴你后者，而且好以后者的形式用前者的時間(多少有些多快好省的味道)。然而很少有項目經(jīng)理會直接看你的代碼，更不關(guān)心你用的何種設(shè)計模式，也不會一個個看你的測試用例來思考是否覆蓋所有的邊界，更不會看你寫的注釋了。

　　所以很不幸，除了少數(shù)精通技術(shù)，熟悉細節(jié)，了解程序員苦衷的項目經(jīng)理外(這可是大多數(shù)程序員都翹首以待的領(lǐng)導(dǎo)啊)，大部分喜歡前者。

　　因為精心的設(shè)計，良好的文檔是需要大量的時間，完備的測試用例的代碼量幾倍于實現(xiàn)本身，功能測試，性能測試以及Bug的修改更是難以估計時間的，所以總的時間將幾倍于前者的時間，在此過程中，你獻給項目經(jīng)理的，除了等待，還是等待。

　　人是不喜歡等待的，尤其是很少反饋的等待，當我們用windows的時候，往往會出現(xiàn)估計時間相當不準確的進度條，然而我們還是喜歡看著進度條一直走到底，同樣項目經(jīng)理也是。

　　總是能夠很快的做出項目經(jīng)理能夠看到的版本，便容易給人一種能力很強的感覺，至少大部分人會這樣認為。

　　也許你會說：我做的版本Bug很少，后期維護成本低，QA一測不能夠看出孰優(yōu)孰劣來了嗎？

　　仍然很不幸，在大多數(shù)人看來，你一個月做了一個穩(wěn)定的版本被認為是做了一件事情，而別人兩個星期做了一個不穩(wěn)定的版本，后兩個星期改了三個Bug是做了四件事情，而且其每次的會議總有進度可以說，成績斐然。

　　而且一個人身上所掛著的Bug的個數(shù)，實在不是一件值得羞愧的事情，反而是一件令人感到榮耀的事情，這說明了你重擔在身，舉足輕重。

　　如果你做了一個模塊，用了一個月，后來半年都不曾出過Bug，而另一個人做一個模塊兩個星期，出過多個Bug，并且后來兼任其他模塊的時候還在改Bug，還是很不幸，你會被認為所做的模塊相對簡單，不容易出Bug，并隨著項目的進行而被淡忘，會被這樣提及："他在半年前做過一個項目"，而另一個人卻會被認為所做的很復(fù)雜，有很多疑難雜癥，而且后來會被認為身兼數(shù)職，會這樣被提及："隨著能力的提升，同時維護并負責多個模塊，有并行工作的能力，有很強的解決問題的能力"。

　　也許你覺得我說的太極端，那舉一個歷史上的例子吧，有興趣大家可以看李亞平的《前清秘史——入主中原之路》，其中是這樣描寫當時并稱“南戚北李”的兩位將軍的：

　　李成梁屢立大功，受封為伯爵，躋身于帝國貴族行列。在當時，他的地位、名望等，很有可能已在戚繼光之上。有一種看法，包括《明史》的作者們認為，恰恰因為戚繼光威名太盛，坐鎮(zhèn)薊門十六年，使敵人從來不敢來犯(沒有Bug啊)，于是轉(zhuǎn)道入侵遼東，才給了李成梁屢立戰(zhàn)功的機會。張居正死后，新政被廢，受到張居正支持重用的戚繼光被迅速邊緣化，在郁郁寡歡中死去(可能明朝認為薊門這個模塊不需要再維護了)。而李成梁，他同樣受到過張居正的支持和倚重，然而，可能由于下面的三個原因：其一，遠離京師，與張居正沒有過多的私人交往；其二，赫赫戰(zhàn)功給萬歷皇帝留下了深刻印象(每次總有進度可說)；其三，動蕩不安的遼東局勢離不開這位驍將(遼東模塊還需要維護啊)。從而，李成梁避免了池魚之災(zāi)。

　　當前社會中，不是如此嗎？是修了堅固的河堤的市長感動中國，還是和民眾一起抗洪搶險的市長感動中國呢？是治理的地方路不拾遺的公安局長應(yīng)該升職，還是讓黑社會猖狂十年然后一舉擊潰的公安局長會升職呢？

　　如果你覺得你的項目經(jīng)理英明過于歷史甚至當朝首輔，那么恭喜你。