代碼人生1002

文章太長沒人看，哈哈，繼續代碼人生1001的故事吧。本故事純屬虛構，如有雷同，純屬巧合，該不負責。想轉載的寫明出處即可。哈哈

作者：yi bbbian

鏈接：https://www.zhihu.com/question/50516672/answer/121917292

來源：知乎

著作權歸作者所有，轉載請聯繫作者獲得授權。

好了，還是啰嗦我的開發歷程吧。

在罈子縣的工作在年底勝利結束，這個項目比較牛的是，我們這個項目的收款是很快的，這是我參與額項目第一個拿到收款的項目（做項目的都知道回款是個多麼麻煩的事情）。元旦的時候，項目組整個殺向了深圳。具體的項目開發不說了，說發生的一些事情吧。

說之前必須介紹一個人，華不大明白，哈哈，是和我同屆的哥們，在一個研究室，也是罈子縣項目組的成員，當時他負責另外一個項目組的開發。做信息系統。但是他負責深圳機場的一個項目，而我負責的項目在深圳城裡。和本地的一個公司合作，只有我一個人去城裡，而項目組的其他成員都在機場。

A：被捕事件，當時的深圳是比較亂的，外來人口極多（幾乎都是外來人口），而且很多人是沒有身份證明的，於是遣返就成了公安的日常工作，一天晚上，華不大明白帶領團隊在外邊踢球，結果碰上了當地公安拉網，結果一群人都被圈裡邊去了，而哥幾個還都沒有帶身份證，於是被請上了運犯人的車，王二這個時候沒有犯二，說自己剛來，於是被放過，回去立刻找張老慫，後來的事情就簡單了，老慫拿上大家的身份證去營救出了大家，不過聽說，華不大明白當時很英勇，一定不坐犯人座位，而要坐前邊的副駕駛，理由是自己有證明，只不過忘帶了，不是遣返人員。估計人家也懶得和他折騰這個事情，就讓他坐了，

不明白回來後，仍然大義凜然的說，如果不是他在哪裡牽制了警察叔叔，王二一定跑不了，整個團隊就全軍覆沒了。

B：狗肉煲事件，不明白項目組有一個女生，是他項目組的一個主要開發人員，從罈子縣項目開始一直是不明白的骨幹，而且兩個人配合的比較好，一天下午，兩個人突然吵了起來，而且非常激烈。後來還是老慫介入，才平息了，不明白跟我說，之所以起衝突，是因為中午不明白請組員吃了狗肉煲，於是被傳染了，哈哈，當然這是一個玩笑，老慫事後給我分析這個事情，其實根本不是什麼狗肉的事情，其實是大家出差時間太長了，而且連續封閉開發，所以有點過勁了。這個時候大家的情緒和工作效果都極劇下降，還好，當時已經臨近春節，給項目團隊有了一個緩衝休息的時間。矛盾才得的了疏解。

我一直比較反對加班，特別是為了加班而加班，原因如下：

第一、人不是機器，就是機器還需要檢修呢，即使你再講情懷，也是有一個限度的，一旦超過研發人員的忍受限度，必然產生反作用，而開發人員的反彈是一個非常可怕的事情，而且開發人員的工作很難度量（這是腦力勞動勞動的一個很大的區別），即使你有kpi去做考核，但開發人員對付這些東西的手段一定比你多。所以我一般不反對主動加班（即使沒有開發代碼，而僅僅是看書學習），但不支持長期高強度的加班。

第二、加班的效果實際不好，碼農的工作無論怎麼說是個腦力勞動，如果讓他真的高強度工作8小時，實際是沒有精力去加班的，對於一般人，實際上是工作時間他們無法進入順流狀態，而造成還有精力去加班，那麼為什麼不給他們構造一個可以長時間處於順流的工作環境呢？其實，無論是封閉還發，還是出差的現場開發，以及戰鬥室，其本質都是讓開發人員有一個順流的工作環境，僅此而已，很多時候，我們不深究其理，而是簡單的看表面現象。現在開發人員流行的大通道開發環境實際是一個很不好的環境，開發人員正常工作時間很容易被打斷，那麼為什麼不給他們做成相對封閉的小工作間，說白了，還是管理人員太懶。（另外一個簡單的方法就是下午以後不許開會。開會的方法不掌握，也是一個極浪費資源的東東）。

第三，長期的高強度加班給身體和情緒上造成的損害極大。碼農這個群體天生的有一種情懷，所以我一直覺得開發隊伍是比較好帶的，但長期高強度對身體損害是很大的，而由此造成對家庭損害更大，這些東西都會影響開發人員的情緒，長期負面情緒的積累一旦爆發，就是一個大事情，而開發人員往往疏於注意對自己情緒的管理和疏解，所以一旦出現矛盾，就會比較激烈，而作為一個團隊的管理人員，注意開發人員的情緒的變化和疏解是一個重要的技能。

第四．長期的高強度的加班，實際是掩蓋領導的無能，領導不是好做的，特別是研發團隊的領導，在中國，開發團隊的領導不能有明顯的短板，這個要求其實是很高的，比如，如果你的計劃能力、估算能力差，會造成工作量和資源部匹配失衡，那你就加班吧。如果你的技術不行或者學習能力差，那你就加班吧。如果你無法把握需求以及變更控制，那你就加班吧，總之，需要長期加班的團隊，往往是其領導者，在一個或者幾個方面有短板，這個時候，其實需要領導者補齊自己的短板，而不是簡單的加班。

說一個段子吧，這是真事。我在做交通項目後，項目組也有加班，但相對比較少，而且項目成員以下班就先跑路回家快而著稱，哈哈。有一次開高層會，我們CTO說，我們強調技術研發，強調技術的領先，我們畢竟是技術公司，現在我們的開發人員下班就走，幾乎沒有人加班，這怎麼行。其他的互聯網公司都是要加班的，都是晚上11、12點才走人。而我們的很多項目組，下班就打卡走人，這怎麼行，我建議，研發人員一定要加班，加班可以給加班費嗎？比如晚上10點走的人，可以報一個餐費，20元，。。。。。。。所有的研發部門的項目經理都傻逼了，晚上10點，多干4個小時，給20元，你當開發人員是傻瓜呀，還好，公司老闆說了句話，開發人員加班幹什麼？於是這個世界安靜了，然後就沒有然後了，哈哈，老闆英明

C:什麼叫專家，哈哈，專家這個詞現在似乎成了貶義詞，還是叫專業人員吧，我在深圳的時候，是和北航的一個教授合作，教授是玩軟體的，帶我去做調研，我基本上是一個打下手的角色，調研的時候，我是拿本記錄內容，而教授卻直接畫出數據流圖，整個系統業務流、數據流隨著用戶講解的結束，就會直接呈現在用戶面前，而我需要將記錄的東西帶回去整理，第二次和用戶討論的時候才能出圖，這無形就浪費了很多時間。在我自己的技術生涯中遇到的絕大多數開發人員都無法做到像教授那樣，這並不可怕，可怕的是大家都認為畫不出設計圖是一種正常現象。關於專業人士說幾個例子。

中科院一般有兩個體系，就是研究體系和工程體系，研究體系就是助研》副研》正研。工程體系就是技術員》助工》副研極高工》正研級高工，這兩個體系不多說了，區別大家都知道，但其實，還有一個工匠體系。在我小時候，我母親單位的里有很多工匠，就像八級鉗工的概念，他們做什麼？是吹玻璃的，你想不到吧，單位做實驗的時候有很多玻璃器皿是特殊結構，當時在外邊買不到，所以只能自己生產，而一個好的吹玻璃的老工匠是可以吹出滿足研發人員的特殊試管的，而如果沒有這個東西，科研往往要耽誤，你就知道他的重要性了吧。

老於是我在中科院的另外一個頭，下一個項目我是跟他乾的，他的牛事，後邊講，這裡只說一個他的牛事，我們在跟他做項目的時候，都是用C，經常要調用BIOS中斷，BIOS中斷的資料很多，記得當時一本資料是16開的，大約5厘米厚，你想一下查這個資料要多長時間，當時最簡單的查詢方法不是查書，也不是找度娘（當年度娘還沒有出生呢），而是去問老於。開始，我以為老於是用的多，熟能生巧，所以也沒有在意，一次吃飯，大家吹牛打屁的時候，老於說他可以說出所有的中斷功能，這個有點過了，於是我們幾個小慫不服了，拿出資料一個一個問，功能是什麼，中斷號是什麼，AX，BX，CX，DX是什麼值，無論你正問還是反問，老於都是隨口而出，而且從來不錯，我的媽媽呀，那可是一本是16開的5cm厚的書呀。同樣的事情，老於後來還玩過一次，就是C類庫的結構圖，也是隨手畫出，不過我們那個時候已經沒有興趣去驗證圖的正確性了（太受打擊了）。問題是，老於說，我們研究室原來室主任叫孫玉芳（紅旗Linux負責人，英年早逝），人家是可以將Unix核心代碼隨便拿出一段就告訴你做什麼用的，為什麼這麼寫，甚至到每個變數是什麼值，代表什麼意思。我在中科院被被太多的牛人碾壓過，不可否則的是，他們的智力水平超過常人，但如果說僅僅是聰明成就了他們，卻也不對，其實每個牛事後邊都有一段痛苦的經歷，象孫玉芳和室老大他們每年的代碼閱讀量都是幾十萬行，（我當年是半年1萬8），代碼量就更多了，老於他們同樣，沒有幾十萬行代碼量的積累，是不可能真正理解軟體開發的（cv專家的200萬行不算代碼量）。

張老慫雖然很早離開了開發，但他的管理積累也同樣深厚，這同樣是長期帶領研發團隊的積累。現在的軟體行業經常糾結在是做技術還是做管理，哈哈，這個東西在我看來其實沒有必要太糾結，原因如下：

1管理的思維方式和科研的思維方式很多方面是一樣的。所以，一般科研做的好的，管理都是不錯的，管理和科研最大的區別是很多知識點的不同，對於一個善於學習的人，掌握知識點，應該不難。比如像室老大、張老慫他們都是技術出身，在有機會接觸管理後，其管理能力都提高很快。這個事情關鍵在於你的思維體系是否科學。通過科研還是管理實際都可以實現思維繫統的科學化，這個應該是深度問題，而至於是在管理上、還是科研上，甚至是市場方面都知識廣度問題，一般來說，深度難突破，廣度易突破。所以在剛參加工作有一點深入，形成突破這是很重要的事情，而如果多次轉換工作，則容易形成低水平循環。這是我的個人觀點。我也好，吳敵也好，還有畢小慫、費小慫都是普通人，我們實際都是走的這麼一條路。

2管理和技術在實際生活中不是對立的管理而是相互相成的關係，做技術的不能一點管理不懂，首先，現在的開發不是原來的西部牛仔時代的個人英雄主義時代，而是團隊、系統之間的對決，個人很難完成全部工作（成本也不合適），單人的高效率往往被總體的低效率所完敗。而管理不懂技術，那就成了外行管理內行，衝突和矛盾所消耗的資源也是令人吃驚的一個事情，而不懂技術的管理被技術欺玩這個事情也太常見了。所以，你要想做成一個事情，最好做一個技術型的管理人員或者具有管理思維的技術大拿。跑遠了，回溯，回溯。

D:在深圳的時候，還做了一件不知道算NB還是SB的事情，哈哈，事情是這樣的，當時整個團隊在機場做機場的一個系統，而我在深圳城裡做另外一個項目，整個項目是和我們公司在深圳的一個分公司合作（當時公司、分公司極多，而且亂）。在城裡呆了一段時間，項目沒有太多的事情，就經常和分公司的開發人員聊天。一天晚上，突發奇想，於是寫了一個整個分公司整體分析報告。報告的內容比較簡單，就是公司的人員組成，水平，項目情況等等。這個報告寫完後。交給了張老慫。當時提交的時候也是滿腔熱血的，但張老慫看完之後沒有說什麼，只是一句話，讓你去城裡不是干這個事情的。嗨，有一種熱臉貼涼屁股的感覺。再提到這個事情是幾年以後的事情，當時我已經離開了老慫組，一次幾個人吃飯的時候，老慫才告訴我，那份報告對他後來的決策有很大的作用（項目組在做完機場項目後，回北京發展了）。這個事情讓我想了很久。

首先，關注身邊的環境這點是沒有錯誤的，在一個機構中，機構中人的組成、做事方式對項目的成功以及你未來的發展都極為重要。

其次，要做好自己的事情，我參與的項目由於種種原因最後沒有成功，雖然原因不在我這裡，但容易給人，你是不務正業的感覺。

第三選擇時機和方式，你做的事情也許正確，但展現的方式和時機很重要，如果我是在吃飯的時候，或者其他相對輕鬆的環境下將這些內容說出來是否更好？

好了，說一下，我在張老慫組的最後的幾件事情吧

1在深圳，我參加的項目黃了，不是技術原因，是市場原因，那個時候，搞軟體開發沒有專門的市場人員，都是技術人員自己在做，畢竟不專業。所以就沒有然後了，在老慫組讓我體會最深的就是技術和市場的關係問題，中科院的技術應該說還是不錯的，但市場一直是個問題，主要問題是一個是開發人員不了解市場，於是閉門造車的現象比較嚴重，有時候一直追求技術上的高精尖，而不管市場是否適合，死得很快。第二市場需要什麼？也就是產品也好，項目也好，可以為顧客解決什麼問題，這個往往考慮的少，第三，就是思路問題，很多時候總所有問題都用所謂的技術去解決，結果陷入死胡同，其實有些問題是無法用技術來解決的，有時候，往往一支煙能解決的問題，你用再大的技術成本都無法解決。

2春節過後，老慫帶領團隊在深圳開發，我回北京做了一堆小項目。說幾個故事吧。

A：繡花打版，這個事情是我離開張老慫組做的最後一個項目，說實在的，當時自己只是一個研發，而不具備項目管理能力，當時是做繡花打版的一個軟體，我們單位是中國第一個做這個軟體的公司，而且產品已經開始實用化（當時國內紡織業開始興起），只是當時的體制問題，開發人員的貢獻和收入實在不成比例，而進入市場的開發人員的確很難利益的誘惑，再加上國營單位體制的問題，於是原來項目組的人員紛紛離開，而我和另外一個研究生就被迫接手這個項目，說是接手，其實是重新開發，因為那是人走光了，代碼也沒有（哈哈，別說什麼版本管理，當時沒有）。這個項目對我的有影響的幾個事情。

學藝在偷，當時沒有資料，你根本找不到任何資料，主要學習的方法就是去參加展示會看別人的設備如何操作，然後回來自己模仿，各種針的走法，從原來系統中學習，從別人展示的（賣的設備）設備上看，回來總結，然後實現。（說好聽的叫逆工程，不好聽的叫山寨）。書到用時方嫌少，由於涉及很多計算方面的問題，很多時候需要重新翻書，特別是數學方面的數據，真後悔當時學習的時候沒有認真。

介面是個大問題，這個東西是所有編寫C語言的人最厭惡的事情，做C的時候，最怕的就是介面變化，而引起介面變化的原因還特別多，而沒有一個良好的設計，往往會頻繁引起介面的變化，我和蘇sir編程的時候，他的介面很少變化，原因很簡單，他的經驗足夠，雖然沒有成型的文檔，但很多事情都能想到，留餘量，所以介面很少變化，而在繡花打版這個項目中，我的合作夥伴主負責，但因為經驗問題，幾乎是三、兩天就一變，更要命的是，有時候變了不和你說，於是經常出現，你好容易改完了，去和他聯調，卻發現介面變了，最後沒有辦法，於是乾脆什麼都不做，等他不變了，我再編程，你想這個項目會是什麼結果。在系統開發中，不變更是不可能的，但要注意的是，同一個模塊的功能不要頻繁和反覆的變更。說一點降低變更的方法。

需求是變更的第一原因，用戶需求和用戶實際需求是不一樣的，用戶需求往往是在做項目的時候，用戶在調研會議上提出的功能，但這個功能實際是什麼樣子，需要你去驗證的。舉一個例子，我在做交通後，做了公交調度系統，在和公交公司技術部門交流的時候，用戶往往要求我們按照發車時刻表進行調度，這個方法按照原來的路況是沒有問題，（原來路寬車少，公交車速度可以保證），但後來就不行了，原因很簡單，車多了，路堵了，後來和調度人員聊天的時候，調度人員告訴我，他們實際上是以發車時刻表為依據，根據每天的實際情況進行調度，而且基本採用車先回先走的方式。哈哈，第一種調度實際上就是我們說的用戶需求，而第二種方式是用戶實際需求，你不能不考慮用戶實際需求，同時也不能不管用戶的需求，否則項目結項的時候一定有麻煩，你說怎麼辦，簡單，你按照用戶實際需求開發，一定要滿足之，這樣，你的系統才能真正使用起來，而用戶需求呢，我採用的方法是原理性通過，也就是領導的時候，可以演示，但不精緻，bug多多，哈哈，實際情況是我們開發了四種發車方式，兩種是調度人員每天都要使用的，而另外兩種就屬於面子工程了，這樣基本達到了好吃不難看，而且工作量基本可控。

第二種，基本就是設計問題了，一個是個人經驗，第二個就是人犯懶。個人經驗這個東西不是太好說，每個人的效果都不一樣，但總體上是一個提高的過程，而犯懶實際上是設計的最大問題，為什麼這麼說，說一下我自己的觀點。你可以不寫文檔，但不能不設計。我總說自己是野獸派碼農，本意就是我也不願意寫文檔，哈哈，暴露了，但不寫完善的文檔，不代表不寫文檔，不代表不設計。我自己的經歷，所謂完善的文檔幾乎都是結項使用的，說句不好聽的，就是對付客戶的，但核心文檔一定要寫的，而且都要是乾貨，比如通信伺服器的通信協議，資料庫的結構設計，整體系統的整體架構。這些東西都是會影響整個系統的東東，不寫是不行的，另外就是做大型程序一定要有文檔，萬行以下的，不寫文檔估計還控制的住，5w的出問題極大，而如果是幾十萬行，無文檔基本就是一個死。另外就是不建議寫詳細設計文檔，（我們現在很多人將概要設計當成詳細文檔，具體概念見軟體工程的書），為什麼，一個是詳細設計文檔量大，第二是變化大，在時間緊張的情況下，根本來不及，所以我經常使用代碼註解來替代詳細設計，這樣效果比較好很多，而且開發人員容易接受。

文檔的作用是什麼，不說理論，說一點實際的東西，

第一：整理思路，很多東西在想的時候，或者討論的時候往往都沒有問題，但一落實到紙面就出問題。所以在做系統之前最好將主要的內容落實在紙面上。

第二：便於檢查，對於稍微大一點的系統都，一個人很難將全部的東西記得很清楚，而且在討論的時候經常出現前後矛盾的現象，而這個時候，文檔可以作為一個證據，進行驗證，否則容易出現開發人員的矛盾。在開發人員出現介面、資料庫結構、核心演算法有矛盾的時候，我採用的方法是，先看誰有文檔或者記錄（記錄實際也可以作為過程文檔），有文檔第一，記錄第二，誰有就作為當時的討論結果標準，都沒有，就各打五十大板，然後重新討論，討論後，會和主管人員做交流，一般來說主管人員承擔70%責任，下級30%，但要求大家以後有文檔，至少是有討論記錄。

第三：是傳承，開發人員因為種種原因流失或者調離都比較快，接手別人的程序是一個最麻煩的事情，用一周，甚至一個月接手，都會存在這樣或那樣的問題，而有文檔，則接手的速度和效果會好很多，這個事情，我一般在開發人員進入團隊的時候就交代好。而且組員在開發過程中，會進行適當的輪換，這樣，整個項目的任何一部分的開發盡量不依賴某一個人。

關於文檔如下寫：總結幾條吧

第一：廣度優先，不要深度優先，廣度優先還是深度優先，實際是一個思維方法的事情，一般來說，初級開發人員都是深入優先，而好的管理人員和技術大拿基本都是廣度優先。在寫文檔的時候，你可以觀察一下，初級人員寫的方式都是，標題1，標題1。1，標題1.1.1，標題1.1.1.1，標題1.1.1.1.1，而老鳥的寫的方法是標題1，標題2，標題3，標題4。。。。然後是，標題1.1，標題1.2，標題1.3.。。。。。。。看出規律了嗎。採用深度優先時候，問題是寫的全局容易亂，子標題的容易打架和衝突。在早期我採用深度優先的方法經常發生漏寫、衝突（前後矛盾），重複（前邊寫了，後邊又在一個地方寫了）。但採用廣度優先的方法基本沒有這些問題。採用廣度優先的方法還有一個好處，就是可以比較估算文檔工作量，而且有時候，項目緊張的時候，可以先提供簡版（供批判稿）提交給客戶或者領導，這樣，防止出現最後評審不過，抓瞎的事情發生。（領導通過簡版，可以看出你的思路，出問題可以快速調整，防止錯誤理解造成大量文檔工作浪費）。另外領導最怕什麼，工作失控，而如果有簡版，他對工作基本感覺是可控的，即使出問題，也便於即使調整，失控是領導和客戶最害怕的事情，失控是領導和客戶最害怕的事情，失控是領導和客戶最害怕的事情。重要的事情說三遍。而廣度優先的方法，是讓領導和客戶感覺項目在自己控制的最好方法。切切

第二．如何寫評審用的文檔，這個評審用的文檔是指在項目中間檢查和項目驗收使用的各種技術和管理文檔，而不是開發組內部使用的文檔，開發組內部使用的文檔要乾貨。而評審用的文檔水貨多。水貨多。如何水貨多，寫細節，類似的功能採用文檔複製，再修改的方法，哈哈，基本就是CV專家的幹活。用你們原理內部的技術文檔作為骨架，然後讓新參加的工作的研發人員寫這類文檔最好，一個是解決勞動成本，另外，新開發人員通過寫這類文檔熟悉系統，練習文檔的寫作方法，順手出用戶評審報告，一般在項目結項一個月左右的時間開始這個操作，基本可以滿足要求，這些需要說明一下，開發的乾貨文檔，基本上一個人日是6000字左右，基本上不會超過10頁，但評審用的文檔嗎，哈哈，一天搞個幾十頁上百也都是可能的，評審用的文檔一個是文檔個數不能少，乾貨齊備，注水嚴重，反正技術類型的按照500-1000頁寫是標準，再告訴你一個事實，評審文檔越多越沒有人看，你的項目通過的可能性越大，但記住一點，內部文檔要乾貨。

第三：內部文檔要如何寫，內部文檔要乾貨，不說了，在項目過程中，其實是無法按照軟體工程的要求編寫全部的文檔的，那麼那些文檔要寫，要控制呢？我自己的感覺，首先是公共資源的地方是一定要寫的，比如資料庫結構，其次是整體的架構，架構不要過多的細節，但總體結構一定要清晰，其次是介面一定要寫，否則矛盾多多，最後是核心的演算法和操作原則要寫。

好了，喜歡跑題的毛病又犯了，拉回來，

我離開張老慫組的一個最主要的原因是張老慫對我個人的希望和我自己對自己的規劃有矛盾，張老慫希望我搞管理，帶項目組，對於他來說，當時項目組正在一個上升期，急需帶團隊的開發者，而我在這一年的開發過程中，無疑是比較符合老慫需求的（在組內和其他人比較）。而我覺得自己的技術水平實在糟糕，如果現在就做管理，技術無法壓住別人，根本不可能管好開發組（當時的真實想法，哈哈），所以我想繼續提高技術。

這裡說一個事情，在考慮是做技術還是做管理的問題上，我和老娘討論過這個事情，老娘沒有說什麼，只是告訴我，當年文革的時候，凡是技術幹部在被打倒後，後來都能夠出來，恢復職務，繼續自己的工作，而政工類幹部基本就不行了（政工幹部可以認為是管理型幹部，在當年）。所以，這樣堅定了我先學技術，打牢基礎的決心。哈哈，，當然現在不一樣了，對於管理人員，一個是上升的渠道比純技術的快，而且即使你在一個單位呆不住的話，換一個公司吧，現在比當年選擇途徑多了很多。

下邊要說在其他項目組的工作了，將我在張老慫組的工作感受做一個總結吧。

第一：開發一定要為市場服務，或者說為公司的市場和銷售服務，再好的技術，如果不能推向市場，獲得利潤，都是沒有意義的，作為研發人員最忌諱的是看不起市場和銷售人員，而不和他們好好合作，一味強調技術是沒有意義的。

第二：技術不可能解決一切問題，特別是和管理和人工智慧有關的方面，切記不要用工具（軟體產品）解決管理的問題，那些說什麼你用了我的產品就可以解決你們公司管理的問題的東東都是胡說八道。

第三：和客戶保持友好的關係，這個不是說讓你採用回扣等手段，其實，有時候你真心的對待對方，不輕視對方，真誠對待所有客戶，不管是上層還是下層，很多時候，客戶給你幫很多忙。

第四：沒有說一切都準備好的時候才開始工作的，這個對於研發人員要特別注意，技術人員一般都比較保守，希望在做項目前可以解決所有技術問題，這個基本不可能，反正我自己做的項目，即使再熟悉的開發系統，都會出現這樣或者那樣的技術問題。所以，一般來說，在項目開始階段，有60%把握就可以做。

第四：注意開發組的工作強度，長期加班是不可取的，在加班的時候，項目經理有責任調節工作人員的狀態。在高強度開發狀態，一天有效工作時間也就是8-10小時，注意這裡是有效工作時間，而不是工作時間。

第五：項目經理盡量讓組員一致行動，我們出差的時候都是一起吃飯，一起出去玩，這是團隊建設的一個有效的方式，另外就是防止出現意外情況，一個團隊是否團結，從他們在出差的時候活動方式就可以看出來。

第六：項目經理的工資有10%要花在組員身上，哈哈，這是一個小日本的習慣，大家出去，領導花錢，說起來容易，做起來難，開始的時候，我也認為，我自己掙的錢，自己花，但做了項目經理後，發現，當你真把10%的錢花在組員身上，收益是很大的，哈哈。

張老慫還是很夠意思的，他知道我要走的時候（單位內部調動），問我要去哪裡，我說自己想學習技術，於是他建議我去了余大俠組。

於是新的開發生活開始了。好了，照例先說段子，再說感想吧。

A：小時報，做開發的寫過月報、周報吧，如果嚴格一點的寫過日報，哈哈我們這個組實行小時報，所謂小時報，是每天按照工作時間進行填寫工作內容，最可怕的是如果你和別人聯合調試，那麼你們兩個的小時報時間一定要一致。這個東西不是老余搞得，是項目管理部門，一個從德國回來的姐姐搞的（叫她德姐吧），開始的時候我們都比較反對，但人家是在從以嚴謹著稱的德國回來的軟體開發管理人員，拿我們做實驗，哈哈，於是我們一邊在瘋狂編碼，一邊還要湊小時報，對，是湊，我們每天最大的樂趣就是吃完晚飯，一邊聊天一邊湊當日的小時報，然後接著熬夜。這個小時報大約執行了3個月，後來無疾而終了。我們也解脫了，回想小時報，說實在的，還是比較有用的，第一，它強制對我們進行工作檢查，即使是湊報告，我們實際還是需要回想全天的工作，而自己也感覺代碼開發效率要高很多，可惜當時沒有做代碼行統計，只能說是自己的感覺。第二。小時報有一點計劃的含義在裡邊，我們那時做代碼沒有項目管理和計劃的概念，都是野獸派，德姐雖然沒有讓我們做計劃，但每天的檢查實際起到了小鞭子的作用，不斷抽打我們，快點，再快點，別人比你快了，就等你聯調了。第三，這些記錄雖然有偏差，但對很多問題的明確是有好處的，後邊的介面矛盾的時候，很多問題都是可以通過查報告發現問題的，（編寫繡花打版的那個哥們也在這個項目組），在繡花打版的時候，很多問題只能說，這個樣子檢查工作，老實人是很吃虧的，（你們懂的）。但現在這些東西都有記錄，哈哈，領導不是傻子，看記錄基本就明白怎麼回事了。關於開發人員之間的問題，我在做交通的時候會將，利用工作記錄玩的一個事情。（這個坑先留著）。總之，記錄工作是一個很重要的事情，切記。

小時報為什麼失敗？

小時報失敗從某種程度上講是一個必然。說一下原因吧。

第一：強推，這個是讓所有人最反感的事情，即使你是真正的好東西，也不要採用強推的方式。而德姐採用的強推，無疑是把我們變成了她的敵人。而老余採用了坐壁上觀的方法。

第二：沒有同甘共苦，在開發團隊中，是否同甘共苦是一個很重要的東西，我們每天都是9-12的工作法（將近15-16小時），而德姐是正常工作時間，所以，即使開始我們對德姐還尊重的話，三個月以後，我們已經採用無視的方法對待她。

第三：利益，你做管理沒有問題，但對我們開發人員有什麼好處，在這次做的時候，所謂的管理並沒有讓我們感受到好處（對工作的檢查的作用，我們當時無法體會），而只是裹亂，你想我們能支持你嗎？其實，如果德姐當時將我們的工作時間做一個統計，代碼量做一個統計，可以看出我們的開發效果是非常高的，如果在領導面前表揚一下我們，哈哈，我們也會認可很多，但她沒有做，不要指望別人可以在無利益的情況下，長期幫助你，這幾乎是不可能的事情。

第四：自身的能力問題，這個事情實際是壓垮我們對德姐信任的最後一棵稻草了，當時，我們和德姐的矛盾已經很大了，但最起碼，大家面子上還過得去，記得一次有客戶來，當時我們已經連續工作很長時間，前一天晚上7點了，德姐忽然向我們要用戶手冊，我們告訴她，還有代碼要寫，估計來不及，於是她說她來寫，讓我們給資料，我們花了2個小時給她準備資料，然後繼續編碼，12點回家，當時走的時候，還問過德姐是否有問題，德姐說沒有問題，但是，第二天沒有任何資料寫完，而且其他組的人告訴我們，我們一走，德姐也回家了，這個事情，大家都沒有說什麼，但從哪以後，德姐的話我們不聽了。打鐵需要自身硬，技術上的欠缺還好說，但。。。。。。，就失去我們的最後的信任，而開發人員一旦不信任你，搞死你的方法太多了，

管理的提升比技術的提升要難得多，技術往往可以靠一個人或者一個核心小組就可以了，但管理幾乎要涉及所有人，而一點沒有注意到，就會造成管理提升的失敗。那麼，可以怎麼做？還是說一點自己的後來工作中的體會吧。

1：了解環境，了解團隊，了解開發人員。當你空降到一個組織的時候，不是大張旗鼓的改革，而是觀察，觀察組織，觀察人，觀察工作方式，找到核心問題和可以快速見效的問題。

2：讓參與的人員享受到利益，這個利益不僅僅是錢，那就太狹隘了，比如成就感、比如機會、比如能力的提高，比如項目的成功，這些東西往往比金錢更重要，而隨之金錢的利益也會來，（如果不來，就說明公司有問題，趕緊跑，哈哈）

3：宣貫，這個東西可不是開兩次會，發一些資料，做幾次培訓就可以的，我自己的感受，研發人員有比較強烈的改進工作、獲取成功的動機，但同時他們也反感僵化的宣貫，所以宣貫的關鍵是你講的東西是否合理、科學，道理說否說的通，另外就是在日常生活總逐步宣貫，比如吃飯的時候，哈哈，別太僵硬，研發人員是很容易接受的。如果研發人員主動問你管理問題，那麼你就成功了。

4：以身作則：這個很重要，張老慫的很多方法都是身體力行，而德姐在這一點卻恰恰不行，張老慫則相反，比如他說你的工資有10%要花在部下身上，這招很好用，他自己也的確做到了，我自己以後的項目也基本按照這個方法去做，效果極好。其他的事情也一樣，比如加班，如果領導不加班，最好不要安排部下加班，否則很容易反彈。

B：掃不幹凈的煙頭，我們單位當時借住電子研究所，電子研究所因為要做實驗，所以樓層比較高，層高大約有4米多，我們的開發辦公室比較大，大概有兩個半教室的面積，這麼大屋子只有我們四個熊程序員，和一個女工作人員，四個熊程序員基本都抽煙，每天下班，女同胞下班了，我們就解放了，可以隨便抽煙，當年比價窮，加班就靠茶葉和煙，記得當年的抽煙的事情有兩個樂事，一個是有一天老於告訴我們顧客要來，讓我們打算衛生，（當年衛生都是自己打掃，沒有打掃的阿姨），我們幹了一天，但怎麼都無法將煙頭掃乾淨，每次你以為掃乾淨了，別人總可以從一個犄角旮旯找到新的煙頭，最後，連我們那個女同事都無奈的放棄了，我們也就只能相對苦笑了。另外一個事，在一天早晨，當時我們剛熬了一夜，早晨，我去上廁所，剛出來，看見我們那個女同事來上班，剛開門，一股濃煙從辦公室噴涌而出，直接將姐們推出了門外，姐們一邊揮手，一邊大喊，你們在燒火嗎？於是開窗，開門，通風放氣，當時是冬天，我們幾個一晚上最少幹掉了6包煙。整個屋子猶如仙境。哈哈，最後說一句，抽煙不是好事情，最好不抽煙，抽煙有害健康，切切。

C：聽音辨碼

老余是個神人，他是數學專業的（數學專業做軟體是很牛的。後來做交通的時候，我的一個核心開發也是數學專業的）。他是27歲開始做軟體，當時他們單位有一台PC沒有人用，他於是將機器搬到自己的宿舍。最開始用BASIC。這個東西玩熟悉了，他 不知道該玩什麼，一天，在一個計算機雜誌上看了一篇彙編的文章，於是開始自己用debug開始玩彙編，後來是C。他進中科院是30多歲了，在我來單位做畢設的時候，他在做操縱系統底層驅動，因為是玩底層的，所以老余同志就經常玩一些奇怪的事情，聽音辨碼是一個事情，哈哈，先說一下老余的其他的事情吧，

1解密：老余擅長彙編和C，所以解密對一個數學的人來說就成為了常態，經常有人找老余去解密，後來一次看老余的簡歷，這個傢伙解密近千個軟體，一個事情給我很深的印象，當時，中國某機構從德國買紡織機，5台，近千萬美元，當時，隨機有軟體，德國企業當時說要配5套，否則有問題，我們的採購員認為一個足夠，買5套，價格是500w美元，打折也是150w。廠家屢次勸說，不聽，回來一實驗，不行，再買軟體，500w，不打折。當時，某部人員都傻了，你知道當年因為國家主打紡織才能採購，百萬美元的損失在哪個年代都可以進監獄了，託人找到老余，一周時間，搞定，代價管吃管住一周，最後請了一頓大餐，好像沒有錢，（好笨的知識分子呀）。

2改庫函數：我們編寫系統的時候，系統速度很慢，老余看了我們代碼，認為沒有問題，想了半天認為是庫函數的問題，我們哥幾個都擅長玩C，而C的庫函數對字元串操作檢查是比較嚴格的，老余認為主要問題是庫函數檢驗太多，於是將庫函數帶走，第二天給我們，速度果然提高很多，問老余，他說，你們自己都嚴格字元檢驗，而系統函數也有，而且處理時間極多，於是老人家反編譯，去掉了所有的檢驗，速度自然提高，至於因為編程不規範出錯的事情，哈哈，是你們一幫小慫自己的事情，不過，好在已經練了好幾年，還真沒有問題。

3聽音辨碼：這個也是一個牛事，當時編寫小程式控制機的代碼，主要是調用程式控制機的API和C混編，但是API資料不全，最麻煩的是，有一部分函數的返回值不知道，當時，我是一籌莫展，深夜加班，老余幫我調試，突然，老余說，這個放回值應該是什麼。。。什麼。。。。老大，你是怎麼知道的？我很疑惑，沒有資料呀，你是神仙呀，你聽，程式控制機有聲音，這次是balbabala，上次是balalbala。。。。估計是這樣，實驗一下。於是我又去碼代碼，實驗通過，當時真是千萬匹草泥馬在飛奔，這是做軟體嗎？好吧，老余，你牛。

老余怎麼說呢，他不是張老慫那樣的管理牛人，也不是室主任那樣的代碼大牛，甚至不是軟體專業的，可也許就是因為不是專業出身，所以，對他來說沒有什麼不能做的，只要工作需要，就去學，從最早的BASIC，彙編、C、甚至後來的硬體編碼，電路設計。都是需要就去學。認真的學，在他那裡我從來沒有聽說過，我是某某專業的，所以這個東西我做不了的話。（這個特點在我的前輩那裡都有這個特點），我自己，後來也是這樣，但我的確沒有他們聰明，所以，我的專業還基本是軟體領域。

D：海參有殼：哈哈，這是我的糗事，當時做完系統，去大連安裝，客戶請客，海鮮，主菜上桌，有一個菜叫海大拌，都是不錯的海鮮，除了海參，其他的都不認識，於是想夾一個海參，一筷子下去，不對，海參怎麼有殼，但不能放下，夾回來吃了，沒有覺得有什麼特別的，當時還挺懊惱，吃個海參怎麼那麼難？飯畢，主人說本地習慣是最後的鮑魚要給付賬的人吃，找了半天沒有，奇怪了，難道飯店有問題，再一找，哈哈，在我的盤子旁邊，就是那個帶殼的海參，媽媽呀，我可真不知道呀，難道我成了二師兄，吃人蔘果不知其味道，當然，最後是主人付賬，畢竟，我還年輕，不知者不怪嗎。

E：如何提高效率，調優的小手段，緩存

說這個事情的時候就不能不說一下我們當時做的東西，哈哈，很簡單，當初，我們那個年代最普遍的就是尋呼機，這個東西現在已經是古董，看不見了，這個東西的作用就是，通過話務員將你的電話傳輸給尋呼機，也可以發送一些文字，這樣尋呼機主就可以找電話給你回電話了，這個系統裡邊有一個核心模塊就是編碼模塊，其實就是一塊編碼板，將話務員的手工數據的信息，經過編碼給發送機，然後發送給尋呼機。

老余當初玩的就是這個編碼卡，具體的內容記不清了，只記得當時編碼卡效率不是很好，當時，最牛的就是3M的，一個卡可以容納10萬個數字機，或者2萬個漢字（漢字機信息大）。當時最麻煩的就是數據丟失，因為信息在一天高峰時段會因為信息過多，無法編碼完成，結果丟失，當時老余看了幾個板子，對，就是看看，沒有看代碼，然後問了一下問題，於是開干，具體如何設計我記不清了，就記得當時用了三級緩存，前兩級是保證速度，最後一級是保證數據不丟失。後來我們做過實驗，數字機可以增加10%的容量，而且不丟失數據，至於因為緩存引起的數字傳輸延誤，哈哈，問題不大，一般都是秒級，最大也出現過分鐘級別的，但說實在的。對於當時來說晚幾分鐘真不是什麼太大的事情。

這個事情我的感受，第一，解決實際問題，你知道當時提高10%效率是什麼概念，那可是1萬個客戶，數字機全年的費用是900元，需要增加的是35個話務員，一個話務員的工資大約是2。4萬/年。全年84萬，而毛收入收入是900w。哈哈。

這個卡另外一個好處是不丟失數據，我們在大連的時候，有一個哥們打上尋呼公司來了，什麼事情，說來又去，這個哥們是一個司機，老闆是土豪，土豪專門給他配了尋呼機，方便找人，一天土豪老婆要用車，呼之不理，大怒。告知土豪，土豪一聽，急了，你小子牛呀，解聘。司機一看呼機，沒有消息呀，解釋不聽，你要知道，當時正值下崗潮，在東北，一個司機，找了一個土豪，是多麽的不容易呀。也難怪要打上門來，哥們，你做的系統可靠性有多重要，你可以看見了嗎？

這裡多說一個事情吧，想到了，就寫下來了，

很多開發人員都感覺客戶難伺候，不願意和客戶接觸。的確，和計算機打交道比和人打交道要容易很多。在和人打交道的時候，其實這主要是因為沒有掌握和別人打交道的方法，還是說一下自己的感覺吧，不一定對，僅供參考。

我自己感覺和人打交道，其實主要是一個利益的問題，哈哈，這個利益不僅僅是金錢。在和老余合作的這個項目中，我是第二次體會到了當你給客戶利益的時候，客戶是會給予你極大的支持和幫助的。上邊我們粗算過如果換一個編碼卡，會給客戶帶來什麼樣的經濟效益，這個經濟效益不會給予我們的直接的接觸人，而是會給他帶來其他利益，比如業績，比如成就感，我不否則直接的經濟利益會很有用，但這個手法我很少用，（許可權不夠，而且我的確也不善於搞這個事情），所以，我經常採用給予客戶其他的利用，比如，第一，我絕不讓客戶給我背責任，只是最起碼的標準。第二，給客戶業績，這個事情是很重要的事情，業績是對客戶來說是一個長期利益，第三，不要搶客戶飯碗，哈哈，你別不信，我們做軟體開發，經常是做搶別人飯碗的幹活，如何消除客戶的敵意是很重要的一個事情，這個事情需要在後邊說。

說一下第一點，我後來的項目中遇到一個老大哥，哈哈，也是77,78年那一批的本科，技術是桿桿的，（關於他的技術，後邊說交通10年的時候會介紹），有一次，要在調度室掛一個調度屏（電視機），開始他選了高度，結果他的客戶說，太低了，高一點，老哥沒有辦法，雖然很不願意，還是按照要求提高了高度，結果過幾天，客戶的領導來了，一看，大怒，你們搞那麼高，給誰看呀，低一點，一旦水平都沒有。老哥和客戶都在場，老哥一看，趕忙上去承認錯誤，於是又將屏幕放回了原來的地方，更難能可貴的是，老哥對客戶一句抱怨的話都沒有說，後來，客戶和他成為哥們後，問這個事情，老哥就一句話，我說了，除了讓你挨批還有什麼好處？哈哈，老哥是一個明白人，後來，老哥還做個一個事情，當時，是給客戶安裝設備，老哥做了方案。和專業的，可是他的老大不聽，瞎來，結果出狀況了，客戶怒了，在聯絡會上，一堆客戶狂批我們公司（當時他們頭也現場）。老哥一看情況不對，又挺身而出，一個客戶一個客戶去敬煙。老哥年齡很大，技術牛掰，人員也好（包括在客戶那裡），客戶也知道不是他的責任，看到老哥這個情況，總算鬆口了，讓我們去整改（給改錯的機會了），於是老哥帶團隊有玩命幹了1周，於是一切搞定。這裡說一下，老哥的老闆後來是完全給老哥授權，老闆很牛，但不可能在什麼事情上都是牛人，不過這個老大還是不錯的，老哥後來跟我說，不要讓你的客戶擔責任，不要讓的領導擔責任，也不要讓你的部下但過大的責任。這樣你的路會原來越寬。至於說的碼農的工作，第一是要盡最大努力實現用戶的需求，第二在和大家合作時，不要將工作分的太清楚，（其實是推卸責任，而且失去技術提高的機會），幫其他人解決問題，有時候是提高技術的一個捷徑。第三，在客戶那裡有時候承受一些誤會或者責難，有時候會給你帶來一些驚喜。

第二，給客戶業績。也許是我接觸的客戶少吧，直接索賄的少，而且一般回扣什麼的都是市場人員的事情，我接觸的比較少，我自己感覺客戶更在乎項目的成功，畢竟客戶是甲方的負責人，如果項目出問題了，他要擔責任的。如果好了，自然是一份功勞。我的方法一般就是將項目做好，一般很少直接拒絕客戶（拒絕客戶有竅門，一會兒講）。有時候的確很難受，但也逼得自己去思考，解決真正的用戶問題的系統才是好系統。你的客戶長臉，客戶就會給你更多的機會（公司會有連續項目）。

說說如何拒絕客戶的要求，哈哈，首先，客戶的前三個要求一定要滿足，一般來說，前三個問題是客戶的核心問題，不解決一般項目的結果不會好，也許你的項目可以結項，但系統後來估計就沒有人用了，成了死系統。後續項目就不要想了。而且一般前三個問題解決了，客戶就對你建立信任，最起碼是技術上信任你，我們和張老慫做罈子縣項目的時候，客戶開始對張老慫說，你怎麼帶了幾個小孩了，能做成嗎？幹完了，領導參觀了，撤縣建市了，領導高興了，手下也高興了，於是對張老慫說，你們不錯，不愧是中科院的，都是專家。

有些東西的確是無法實現的，這個時候要給客戶講明白，這個時候實際是非常考驗開發人員能力的時候，怎麼說呢，簡單說，如果你用淺顯的普通人理解的語言講明白一個計算機原理，說明你是真正理解這個原理了，而不是背誦原理。所以，我從來不會用用例圖是給客戶講系統，說句不好聽的，碼農有多少能畫出正確的用例圖，何況客戶。。。。