辭職風波

首先、領導層對管理要給予相應的重視。就案例中的公司而言，現階段制定嚴謹的技術創新管理機制非常必要。企業應對所有相關的技術、資源和各級員工進行科學、合理的配置、排程和使用，最大化的發揮有限資源的整合效應。

1.對於專案開發，應該實行目標管理，對目標的實行步驟進行合理分解。像《辭》文中總公司制定的開發計劃本身存在很多的問題，如果公司對工作目標進行分解，則既能使每一個部門和每一個員工明確彼此的任務、職責和要求，使領導層和員工之間有充分溝通的機會，而且也有助於把握開發質量、時間進度和預算等幾個關鍵因素。

2.公司專案組對於緊急問題，諸如核心開發人員要辭職、市場或客戶的要求出現變化等等情況，要有一套妥善且充分的準備和應急方案。這樣就能減少甚至主動避免突發事件對於公司、專案造成的影響。

3.公司應該有一套相對細化的績效考核標準，使員工明確如何實現目標，應該達到怎樣的效果，這樣有助於使管理者和執行者明確彼此的職責，不會造成扯皮現象。

其次，相對於貨幣資本型企業和權力資本型企業而言，科技型企業的核心問題是如何有效培養、組織、激勵員工，說到底也就是人的問題。所以我們也能看到《辭》文中因李維的工作質量而引發的思考：科技型、開發型企業到底需要什麼樣素質的員工、應該向哪方面培養和培訓員工。像李維的粗心大意對軟體開發企業來講，是比較嚴重的，這可能有性格的原因也可能有是否敬業的原因。而作為企業領導，應該對它的重要員工有一個客觀且深入的認識和評價，嘗試探討如何幫助他們克服缺陷，與企業一同成長。

再次，企業一定要營造適合自己發展的企業文化。科技型企業是一個典型的學習型組織，因此一個寬鬆、容易溝通、緊密配合的管理環境的營建將是成長期科技企業的重要工作。《辭》文中反映出公司內部：總部與分部間、部門之間、領導和員工之間溝通不暢，根本原因還在於企業的核心領導層對這個問題沒有充分認識，所以無法根本解決問題。

另外，我覺得這家公司對辭職員工從不挽留的舉動，也值得商榷。如上所述，科技型企業的管理很重要的一個方面就是人本管理，誠如王強、劉英所言，公司培養一個合用的程式設計師很費時、費力。公司如果對於既有的成熟員工不做挽留，再重新招募、培訓員工，很浪費公司的人力成本。而且這樣的處理，體現的不僅是企業對待當事員工的態度，也體現了整個企業對待真正人才的態度。一旦處理不當，就會造成企業員工以及社會外部對企業的認同感大大減少，非常不利於企業的長久發展。所以這一點，希望該公司能夠慎重考慮。

專案沒有合適的組織結構，研發進度不合理，軟體質量存在問題是引起程式設計師辭職風波的直接原因，所以建議該公司對這三個方面進行調整，致力於建立一個積極溝通、互相尊重的專案團隊，以利於軟體開發，乃至公司的整體運營順利有效進行

戴遠明經濟師、MCSD(微軟認證軟體開發專家)深圳思捷達企業管理諮詢公司顧問

在XP(eXtreme Programming，近幾年廣為推崇的軟體開發模式)的經典著作《擁抱變化》中，XP的奠基人貝克講過另一個程式設計師辭職的故事：整個專案中我最自豪的時刻是Eddie(辭職離開)找到了一份離家更近的工作，再不用每天花兩小時乘車，這樣他就有更多時間和家人在一起。開發小組都很尊敬他，沒有人對他的離去表示異議，大家詢問的是有什麼能幫上忙的。

XP倡導的核心價值觀是“溝通、簡單、反饋、勇氣”，以及貝克認為重要到沒有人可以懷疑的“尊重”。就是這幾條看似簡單的準則，奠定了XP成功的基礎。筆者無意於在此推廣XP，這些價值觀在現在的中國是極其稀缺的資源，以此作為取得軟體開發成功的條件無異於緣木求魚。從理想回到現實，可以說，這個案例是中小企業軟體開發管理的典型，要想做全面的評估和討論，絕非一篇短文可以做到，我們只選擇其中比較明顯且有可能解決的問題來討論。

首先這個專案沒有合適的組織結構。可以推測，該專案沒有經過正式的啟動程式，也沒有明確的專案目標、可用資源、各人職責、可行計劃和策略，更沒有就這些問題在專案組內達成共識，草率的專案啟動往往為失敗埋下了根源。劉英的角色最像專案經理，但她既沒有軟體開發的經驗，又不能很好與開發人員溝通。所以如果專案有過慎重的策劃，她就不應該成為程式設計師的直接主管。必須認識到，開發過程不夠規範的企業(CMM一級)，專案經理的能力決定了專案成敗的一半。劉英更合適的角色是產品經理，負責產品從立項到售後服務的全過程，而原來的副總經理可以承擔軟體專案經理的角色。

第二個問題，所有人都同意專案開發時間不夠，壓力很大，卻沒有人想去解決這個問題。以我工作過和了解過的軟體專案，幾乎百分之九十的專案都存在時間太緊的問題。在這個案例中，六個月的專案時間，計劃中程式編寫只有一個月，可以想見成效不會很好。很多時候，管理人員都喜歡制定一個不可能完成的進度計劃，試圖以壓力來激發開發人員的潛能，而實際上這種策略對其他群體可能有效，對軟體開發專案來說卻是無效的。對大量開發人員所做的MBTI統計表明，80%的開發人員有理性傾向，這類人組成的團隊一眼就能看出進度計劃不可能完成，這樣整個團隊很容易就感覺工作索然無味，會有隨時放棄專案的想法。

第三個問題是軟體開發的質量問題，這是程式設計師辭職的直接原因。質量管理之父戴明告訴我們，絕大部分的質量問題是系統原因造成的，強調個人的責任只能事倍功半，而且會帶來其它負面影響。案例中的公司重視質量，並且把測試的負責人作為專案總負責，這種意識很好，但他們提高質量的方法有待改進。測試應該和開發並行，更早地進行文件評審、程式碼評審和單元測試比在系統完成後再做測試要有效得多，這樣，測試時間可以縮短，還能為開發騰出一個月甚至更多時間。必須認識到，在成熟的開發企業中，程式碼錯誤更多的應該是測試部門的責任，而不能歸咎於開發人員。

至於李維這樣的年輕程式設計師，只能祝福他，不管他會不會離職，我們希望他有一天能夠在XP式的'團隊環境中，成長為優秀、成熟的開發人員。

因為員工和管理者身兼“自然人”和“經濟人”兩重身份，所以要使個性迥異的他們團結在一個企業當中同心同力，為完成一個目標而奮鬥就必須強化並完善制度建設，並在此基礎上營造一個互相尊重、自由交流、鼓勵創新的企業文化

郝繼濤北京奧雷神州管理顧問公司專案經理

人的思想和行為是複雜的，因而人力資源管理是企業管理中最複雜的部分。每個人都是自然人，從這個案例來看，無論管理者，還是員工，都有自己的個性和習慣，例如馬虎、急躁、以偏概全、知己不知彼等等，這都很正常。但同時人又都有理性的一面，總按照自己的利益行事。這樣就必然發生碰撞，這是矛盾產生的根源。

針對本案例，我們希望人事主管能夠緩解危機，幫助雙方愉快的投入工作，使未盡專案得以繼續。但從根本上，我們提出以下建議：

一、強化和完善制度建設。人的管理不是人治，需要的恰恰是法治。制度是一個組織賴以生存的基礎。規範和成熟的規範制度能約束管理者和員工，使之照章辦事，只有這樣企業這部大機器也才能夠有條不紊地執行。本案例的公司，應該將程式完成時間、質量的規定和獎懲制度掛鉤。bug產生，影響了進度，就要負責任。但是，公司對這個一定要有自己的合理化制度，這樣對於員工才有約束力，員工做事才能有據可依。軟體設計是一個可以量化、注重結果的工作，實行起來應該說比較容易。

二、塑造能留住人才的，健康進取的，團結融洽的企業文化。有幾點需要

注意：

首先，要理解人，把人當成大寫的人，而不是擰來擰去的螺絲釘。現在社會上、企業裡，相互尊重這一基本原則有時被漠視，結果在此基礎上建立的工作關係也呈現畸形。其實企業選擇員工的時候，也是員工在選擇企業。所以要給人以尊嚴和關懷，相互尊重，才能有利於建立良好融洽的企業文化。

其次，要創造寬鬆的管理體制和組織結構，減少官僚作風。知識經濟要求傳統企業和所謂的新型企業(像我們案例中的軟體公司)打破等級森嚴。不可越雷池一步的管理體制和死板僵硬的企業組織已經不適合現代社會。現代企業中，員工會希望能夠自由交流溝通。在共同工作的過程中，員工也更樂於分享相互的知識和技能。案例中的管理者和程式設計師所熟悉的領域不同，如果他們多加強交流，增進了解，工作中的牴觸就會減少。

再有，企業應該建立創新機制。從案例的有限資訊來看，這似乎是一個創新能力不夠的企業，甚至無法跟蹤技術發展的潮流，而軟體業恰恰需要不斷的創新，因此阻礙了公司的自身發展。創新文化氛圍的建立，是留住人才並賦予其發展空間的關鍵。就該行業