與領導相處：你直言百句不如讓他犯錯一次

　　當你與領導就某一問題發生分歧時，你跟他直言你心中的看法，有時既使你再有道理，領導也未必會接受，哪怕他指不出你的問題在哪，他的好在哪，畢竟領導就是領導；這時候還不如充不懂，索性按領導的來，哪怕明知道是錯的，有些彎路還是要走的，有些學費還是交的，這樣印象才深刻。
   
　　以上是我從公司年初時開始做的一個產品，到七月底已成無底洞，最後不得不叫停的經曆中得到的心得體會。
   
　　今年年初2月份，落到小組的身上開發工作單位有兩個公司的產品，其中一個比較小，估計1個半月左右可以完成，而另一個則相對難一些（關於生產製造方面的），估計要4個月（單單開發，不含測試）；當時小組共有人員5人，這是我初步對開發時間的估算。

在開發前的討論會上，負責開發部的頭頭倒是沒什麼意見，畢竟大家都是搞開發的，都知根知底；可是負責市場的一位領導（下文稱市場老A，比較牛的意思）明確表示反對，他最主要是覺得我估算的時間過長，而我當然是不太服氣羅，又是擺資料，又是說事實。把我們組前一年開發進度資料，現在要開發的產品有哪些業務痛點，哪些地方採用了新技術，一一分析給他聽；可人家就是不買單。那人家心裡的時間是多少呀？1，2個月搞定，聽得我頭都大。

　　照理說我估算的時間還是有那麼點道理可依的，可人家為什麼就是不接受呢，是沒有說服力，還是？我百思不得其解，在跟好朋友聊天時說起這個事，結論就是：軟體公司中也是講政治的，得罪領導了！那好吧，下面我作一下檢草，希望大家不要再犯，免得吃悶聲虧。

 

1，領導的光輝事迹要表示崇拜，不要持懷疑態度。
 　　想當年市場老A也是做開發的，聽說還是帶隊的；有一次，他跟大夥吹噓當年帶領一支鐵打的Team Dev，能夠上刀山、下火海、幹活幹到人吐血（這是原話，我沒多加一字），最猛時他小組一連通宵加班一周多，兩人直接送醫院，三個月裡面做一套很牛的系統。聽到這裡，我就暗罵，NND，無數開發人員就是被這樣玩殘的，丫的還把這當成光輝事迹了。再說了晚上弄通宵，明天怎麼也得休息一個上午或下午吧，算一算時間，不是差不多的嗎，小學數學有問題？再說做的系統那麼牛，大家當然要領教下羅，一看VB做的，50來個資料庫表，千篇一律的添加、刪除、修改，搜尋條；一個函數一寫就是一大段，老長老長的，模組複用少，隨處可見SQL語句，雖說在四五年前還過得去，但也不至於說的那麼牛吧！當時我也老實，實話實說，說很一般，不怎麼樣！“正確做法”：當時我應該表現為握緊雙手，仰視市場老A，表示崇拜，並後悔不能早生幾年參加他的團隊而抱憾終生。

 

2，做事要按照領導的喜好來。
 　　市場老A在工作上的喜好招數精神勝利法+打雞血，具體表現為不管三七二十一，訂個很牛的目標且要去做到，在銷售上行得通，畢竟銷售要忽悠客戶，要敢於把話說大點，讓人覺得你有料（銷售這方面我是外行，沒發言權）；但他把這招強加給開發組，那就讓人受不了了。具體表現在開發時間的估算上，在他眼裡再難的系統上限也就一個月，你說破嘴皮，他頂多給你打針雞血，抓抓緊，加加班！在開發延時則是繼續打雞血，延長時間最多為一周，不過最好延長一天。這樣豈不是把開發的都玩殘了，還好他有個毛病，你可以無限次延，但你一下跟他說清楚要延長N周，他就要開罵了。這被很多組開發的人把握了，接他的需求做產品，他說多長就多長，後面不行就延時，曾經有個小組的開發延了3次3天，2次一天，4個一周才脫離苦海；有次跟他算開發時間，他照例給我一個月，我沒吱聲，當著大夥的面算時間，一天按24小時算，一個月都做不完；還有次開發延時，我申請15天，被他狂罵，無耐又是當著大家的面算，最後領導都覺得15天少了，他才同意（我笨呀，不會延時兩次一周嗎？豬）。“正確做法”：做事要按照領導的喜好來，錯的也是對的，反之，對的也是錯的。
 
3，領導說的都是對的，不要反駁。
　　 記得有一次大家一起吃飯，市場老A聊起他為什麼從開發轉向做銷售、做市場；原因是做開發沒前途，做不過30歲......末了他還提起網上《程式員與妓女區別》那遍文章，並強調說什麼現在看來程式員還不如妓女，妓女都能做過30歲。當時我一聽火就不打一處來，會不會尊重人呀？，真想上去抽他，當即反唇相譏，“在那支鐵一樣的團隊，我搞兩年就頂不住了，工資不夠進醫院。”他一聽一下就無語了，而且臉色難看，當時我還暗爽，現在想想，我又錯了，“正確做法”：吃飯的時候應該多吃飯，多吃菜，多喝湯；你說什麼話呀，不務正業。

　　不過看來我是很難做到了，做人太直很難改的,不過盡量改吧。下面回到開發的正題上來。

　　

　　在軟體公司一般平級的市場與開發人員，市場的要高出開發的半級（誰讓錢都是從人家那裡進來的呀），即然市場頭頭表示反對，我的頭頭也不好說什麼了，當時<市場老A>表示能否把小組分成兩小波人，我帶其中-波做那個小產品，另外一波人做大的那個產品；做大產品那波人反映比較有難度，市場老A當即表示，推薦幾個實習生來，突擊培訓兩三天，快速上手，加入小組快速開發，（我差點雷倒，還真把我們當民工了，隨便拉兩個人加進來，就能快速開發，你還以為是搬石頭呢？！）最後，從我小組中抽三個人+兩個實習生組成一組開發新產品，其中一人任組長，由他負責，我和另外一人做那個小產品（差點成光杆40）；

 　　雖然是開發不同的產品，但名義上還是一個組，日常在同一個地方工作，每周還是照樣坐到一起開個總結的例會。當時自己也沒想那麼多，還對他們的開發存在的問題提了一些意見，一個項目做壞了，是有因可找的，下面是我的分析。

 
 1,設計沒有做好，過早地開始編碼就是做負功。
  　　一般情況下市場老A只給一個月的時間，可這次卻破天荒給了兩個月，讓我的組其中一個組員充當臨時的組長進行設計，說這個系統比較難，其中一部分就是業務比較繞，花了一周多熟悉業務，一周來設計資料庫，業務沒有熟透的情況下就開始設計資料庫，自然設計不完，有些核心的功能沒弄，加上時間緊，他們就決定開始編碼了；當時我表示反對，理由如上；臨時的組長的理由是系統是基於模組設計的，核心功能屬於其中一個模組，可以先把其它的模組做好，然後再做這個模組（這個模組比較難），模組化設計是這樣理解的嗎？當時市場老A沒出聲，意思就是贊同，所以設計就這樣算完成了。

 

2,驗證設計要嚴謹
  　　做完設計之後，要檢查一下設計是否合理，因為做的是B/S的資訊系統，設計完了之後形成資料庫，個人比較喜歡的方法就是類比填一遍資料，自己想像一下介面，心裡考慮資料在程式中的流轉處理，一步步地填入資料庫，有沒有少業務欄位，要不要加輔助程式設計的欄位，設計一目瞭解。當時我也是這樣建議，可人家認為這樣很費事，我也承認這樣是費事，且看上去大夥都是在那想，偶爾錄錄資料；遠不如狂敲代碼來得爽，可這是狂敲代碼的基礎呀；因為沒做這一步，後面的開發出現了不少的問題，寫著寫著代碼，居然探索資料庫裡面少欄位，或者編程時才發現設計不合理，那也就只有回去改了，這樣反覆修改的所費的時間會更多，所以說古語“磨刀不誤砍柴功還是很有道理”的。

 

3,邊設計邊開發要不得
 　　前面要做的是基礎功能模組，就算再怎麼設計不做好，多改改，多花點時間還算做得差不多了；這時候已經超出原定時間了，可是核心的模組還沒做設計呢，好了，現在就動手，在設計的時候才發現前面做的基礎模組有些地方跟核心模組接不上，滿足不了要求，那隻好改羅；注意了，這是初步設計核心模組是發現對不上，一句話改；隨著對核心模組設計的深入，發現前面做的東西很多地方滿足不了要求，改了的還要改，那頭才大呢。
　　當時我的想法是，停止編碼的開發，只做設計，把設計完全做好了之後，要改的再改。剛開始市場老A覺得會浪費人手，因為停止編碼工作，也就是說有人暫時沒事做，看起來挺可惜的。於是還是堅持了一段時間邊設計邊開發的搞法。

 　　最後連負責開發的人自己得覺得搞不下去了，前面設計的東西沒有考慮好，後面設計時發現已經做好的東西要改，而且這要改東西不是一般的多；再加上後面邊設計邊開發，說得嚴重一點就是早上改了，明天設計時居然發現不行，還要改，這不是要人命嗎？在七月底的時候，公司看不到產品成功的希望，將開發叫停。

 

在後來的失敗總結會上也頗有趣味
 1,領導是對的。
       照理來說團隊開發軟體失敗，負責人怎麼都應該是第一責任人吧，可這次人家壓根不是搞實際開發，是鍛煉新人去了，當成練兵項目了！
  
 2,領導栽你贓，你要認。
       幾個月白做功，怎麼也要有人被批評處罰吧，直接帶隊開發的組長（我組一個組員）讓領導比較失望（他也冤呀，沒帶隊經驗，硬拉著搞這塊硬骨頭，而且外行人負責指揮）......然後我也被小點了下名，原因是實習生沒事做，你這個組長怎麼不分配點事？（邊設計邊開發階段，沒有抄代碼的任務，實習生只能在那無所事事，我當時和另一組員在開發小產品，我能跨組拉人幹活嗎？），不過這次我總算有點進步了，不出聲，預設了。

 　　

　　不過經過這次之後，市場老A對開發的幹涉就少很多了，這也算是一個好的結果吧！

　　

　　補充：

　　前段時間剛把今年的第二個任務完成了（也是公司的一個產品），所以才有空寫寫心得，早上起來發現有人留言說我發牢騷，其實不是，是有點氣憤，程式員素有把程式當成自己的孩子之稱，試問因為別人的原因把自己的孩子弄殘了，你能不氣憤嗎？不過話又說回來，這其實不是我的孩子，當時我小組已經分成兩組，我只負責小產品，另外一波人弄大產品，我的小產品於60天后完成（還是延時了一段時間），可是大產品最終失敗，我從未參加裡面的開發。但是在小組例會中（名義上還是一個組），我每次都給出了自己的意見，上面說的那幾點我都是在開發過程中就提出來了，可未被採納，最終大產品完全失敗。我也不是那種事後說風涼話的人。

　　項目失敗後，小組再次合并成一個，我們下一個任務就是接手上面的爛尾項目的開發，或者幾個月之後我可以寫一篇如何接手爛尾項目的隨筆了，呵呵！

　　還有我文章中還想表達是現在國內開發時，外行人員（銷售、市場）對開發中的本應由開發負責人拍板決定的問題橫加幹涉（比如開發時間的估算，人員的使用、配置），這是開發過程中經常遇到的問題，給開發添加了很多不必要的麻煩，有時甚至直接倒至開發失敗。