易保已走過十年，我們欣喜的看到他的茁壯成長。我相信，今天的成就，十年前已在莫總眼中，我也相信，莫總眼中的十年後，相比當下，一定無比輝煌。我同樣相信，莫總眼中的藍圖，已轉化為管理層眼中的藍圖。但是，這個藍圖是否在我們每一個員工的心中？我在易保一年半，我代表一個普通員工，下面，我從最近犯的兩個錯誤說起：

      我的過錯1： 在一新需求的設計、開發任務時，發現一個問題:“在校驗投保人年齡規則時，發現其中用到的一個引數【生日】，竟然用的是被保人的生日”，我不想給自己找任何理由，這個錯誤我當時沒有修改，也沒有就其中的不理解部分諮詢Product Rule相關比較熟悉的人，比如俺們專案（Fukoku）的Billy Li. 由於自己的疏忽，這個問題遺留下來了，直到後來測出這個規則中的其它問題，我才一併把這個問題修改了。這個問題是一期遺留的，可見測試難度大、隱藏之深（不是很嚴格的測試，很難測出來，因為大多數情況下投保人被保人都用同一個人，或者投保人被保人允許年齡範圍很接近）。這個錯誤在生產環境現在一直還沒有被發現（否則早提Bug過來了），如果不允許的年齡卻投保併成立了保單，到理賠時發現問題，可能會使保險公司或客戶產生糾紛，帶來經濟損失或更嚴重的後果。可見一個小小的Bug可能是致命的。就像冰河世紀中，一顆小小的松子可能導致整個冰山的毀滅。

      那是一顆邪惡的種子，我發現了卻任其發芽，其實相當於是我種下的，種在程式碼裡，也種在我心裡。我希望我們eBao的系統中邪惡的種子越來越少，我們eBao人的心中沒有邪惡的種子，只有我們心裡沒有，系統裡才會少有。

      我的過錯2：當TS測試我修改的某個規則時，所有的Case中沒有一個是產生業務異常的Case。我竟然武斷的回覆說TS的Case覆蓋面有問題，要求其重新設計。後來我的另一個同事（Taro兄）分析後，發現是程式碼的問題：我們的測試框架沒有正確匹配一個關鍵資料，而這個資料在真實的系統中是肯定有值的，規則認為沒有這個資料就不用校驗此規則，理解為校驗通過。

      武斷是一個程式設計師很可恥的意識和行徑，我們在編寫著一段一段的邏輯，這些邏輯是一環一環IF Else IF Else下來的，我們天天這樣嚴謹的在程式碼中使用這些邏輯。但是，在編碼之外，卻忘記了！任何事情都有因果，都有邏輯，在處理事情時也需要像在編碼時那樣，嚴謹的使用邏輯。

     本可以避免的錯誤卻發生了，自我檢討之餘，從中可以發現一些問題。我是一個普通的員工，我們公司有好幾百個我，我希望對我提出一些建議：

      1. 對自己負責

          編碼（測試等各工種）是一門手藝，我們靠軟體吃飯，手藝不精吃不飽飯。我們手藝要精，至少得讓自己滿意，我們才吃得香睡得好。我總有一個感覺，上班越累，下班越輕鬆；上班越輕鬆，下班越累。

          編碼是一門藝術，製造出美感是每一個藝術家的責任，也會讓我們心靈得到慰籍和昇華。心中不要邪惡的種子，開不出美麗的花。

          編碼也可以成為一種愛好。

      2. 對公司負責

          公司為員工付出的成本是遠大於員工收入的，公司是我們衣食父母，房子車子票子都得靠他。多為公司著想，其實就是為自己著想。         

      3. 對社會負責

         邪惡的種子會開除惡毒的花，危及生靈。我們不能種邪惡的種子，更不能看到邪惡的種子不扼殺。我們每一個字元都承載這那份社會責任，那也是我們與社會溝通的一座橋樑。

對管理者的建議:

       易保從幾個人變成了接近千人。公司的成長壯大，人少的時候，大家靠得是團結、信仰、凝聚力、目標一致。人多的時候呢，也一樣。但是難度會越來越大，我們公司在硬體管理上付出了很多：

       公司有通暢多樣的溝通途徑（moc、email、phone等），

       先進的管理工具（文件管理CC&SourceForge等、版本管理CQ、專案成本監控TimeSheet、測試過程管理平臺TestDirect等），

       先進的雲概念服務：虛擬機器應用，

       先進的員工考評模式：文件量程式碼量監控、單位時間內的bug數量、HOD和PM/TPM的評價、SAPE考評系統等，

       成熟的任務管理流程（以FUKOKU為例，從需求到設計到開發到測試到交付，都要經過層層Transfer、層層Review、層層測試等一系列流程），

       先進的工具很重要，毋庸置疑。但是，軟體最終是由程式設計師一個字元一個字元累加起來組成的，我認為程式設計師（可以延伸到各個工種）個人的態度、能力是決定性的。這裡有一個辯證關係：正是因為程式設計師個人的素養千差萬別，所以軟體行業需要更多的先進管理工具、流程來減少因為程式設計師個人的素養不同帶來的風險；但是這些管理工具、流程並不能從根本上提升程式設計師的個人素質（態度、能力、文化認同）。而恰恰，提升員工素質是公司管理上最最困難的一環，也是最最重要的一環，員工素養是基石。

       不可否認，在提升員工素養上，公司做了很多：公司週一到週五晚上都有免費的體育活動（籃球、羽毛球、網球、足球、乒乓等），可以免費在天行健健身，出遊（這個屬於我有人家也有），入職培訓，專案培訓（因專案而異，沒有形成統一的文化），免費英語外教教學（內容很好，只是安排在中午，中午不休息，下午犯困，影響工作效率呀，而且受眾面窄）。但是，我覺得，還不夠，相比於公司在其它方面付出的成本而言，在提升員工素養方面還不夠，還可以在很多方面有所做為。

        例如，新人進入專案後，一般都會安排一個老員工帶一下，但是這只是指導性的，老員工除了要多花一些額外時間、多交一個朋友外沒有太多收穫（哦，還有付出就是收穫），而新員工呢，因為怕耽誤太多老員工時間，通常也是一知半解、效率極低。據我估計，通常，在一個月左右，這個老員工和這個新員工的幫扶關係自動解除了。要知道對於新人來說，老員工滿腦子都是寶啊，在規則上將老員工的時間有嘗分配一些（比如30%，有償不是說要另給報酬，而是算入工作量）在幫扶上是必要的。

      小小建議：引入一帶一機制

           1）老員工對新人的工作成果負責，帶好了有獎勵（具體啥獎勵，我都說了，老大們不就沒事幹了嘛），帶差了沒有（懲罰就不要了吧）。

           2）幫扶關係始終維持（制度上半年或一年，人情上終生），長久下去會形成一種企業文化（比如以後介紹，嘿，誰誰誰是我入門師哥！俺帶了十八徒弟等等）。也只有形成那種類似真正意義上的師徒關係，師傅為了光耀門楣才用心教，徒弟為了不丟臉得用心學，徒弟的成長對師傅也會形成鞭策作用，雖說後浪推前浪，但也不能拍死沙灘上啊。

           3）因為是師徒關係，徒弟惹事了，師傅要負全責，比如整了一堆Bug，誰讓你是師傅呢。當然，徒弟屢教不改，師傅也可以申請逐出師門（少林寺還有方丈管著呢，師傅也不能自作主張啊）。徒弟也可以另謀門派，師傅難免也有冒牌的。

           4）師徒關係得記錄在冊，反正俺們公司管理系統多，也不多這一個。整合到staff portal上更好，一查就知道了。大家茶餘飯後還多了一主題，有利於增進人與人之間的感情。這裡談到感情我再廢話一句：有人的地方就有情感，公司是由人組成的，所以公司和人之間也有可能碰撞出火花；用工具、技術手段管人是下策，把人心聚起來最牢靠；咋聚啊，給好處啊，給員工more and more and more 好處，不光是錢還有more，也不能白給，得讓員工都知道那是好處，像父母對孩子那樣，真愛，別溺愛（當我公司傻啊）。（就一句號，還好~）

           我希望，公司對人心的管理也像在其他軟硬體設施，管理流程方法一樣，更加先進。也希望每個員工都能文化認同，有歸宿感，真愛易保。人心齊了，我們即使少一些流程，少一些規範，我們仍能做強做大；人心不齊，就算再規範的流程，再先進的工具也沒有用。千里之堤毀於蟻穴，居安思危，希望到eBao 1000 sites時，我們的基石更加牢靠！

            打擾大家，誠摯歉意，只因晚上睡覺吃飽撐著了，睡不著，胡思亂想。熟話說好記性不如爛筆頭，遂冒著被老婆批的風險，凌晨三點伏筆疾書，如有些許啟示，甚感欣慰，熬一宿都值了。老婆又在嘀咕，俺不在旁邊她睡不實，罪過罪過。