“跟著毛委員，天天打勝仗！”，當我們回憶起井崗山革命斗爭的那段歷史，無不佩服毛澤東那無與倫比的軍事斗爭藝術(shù)，敢于打破權(quán)威思想，堅持理論聯(lián)系實際，他與黨內(nèi)一個又一個派來的“欽差大臣”們的爭論，“土”與“洋”的爭論，都非常精彩。后來毛澤東寫了一部哲學名著《矛盾論》系統(tǒng)的闡述了這一哲學思想。在和平時期的我們，如果把這一哲學思想運用到工作中，運用到軟件項目管理中，是不是也能“天天打勝仗”呢？
現(xiàn)實中一個軟件項目能夠“按時、按質(zhì)、按量”的完成，并且能夠讓客戶滿意是非常不容易的，為了提高軟件項目的成功率，很多公司制定了一系列的流程，引入諸如”CMMI”等流程標準，不時的變動組織架構(gòu)，的目標就是確保項目的成功，并且一直能成功下去，“從勝利走向勝利！”
流程制定當然是必須的，一個軍隊里也會有各種各樣的流程守則，比如士兵訓練守則，挖戰(zhàn)壕流程，沖鋒流程等等(猜想)。一個經(jīng)典例子的是戚繼光制定的《鴛鴦陣》，對于防守、攻擊；遠攻，近攻；平地、巷戰(zhàn)等等都有天才的設(shè)計。老板、項目經(jīng)理們夢寐以求的“寶典”也不外乎此類了。然而，幻想一個流程解決所有問題，起碼在軟件工程領(lǐng)域內(nèi)的項目中，還很不實際。軟件工程中變數(shù)太多，因素太多，基礎(chǔ)的工作都需要人來作出思考和判斷．這就需要更多的智慧和經(jīng)驗。在保證基本的流程運作順利基礎(chǔ)上，還對“將”的要求很高。如果說流程是“兵法”的話，項目經(jīng)理要懂得靈活運用，決不可以“紙上談兵，生搬硬套”。而要學會運用“矛盾論”。
基于對《矛盾論》的一些粗淺認識, 結(jié)合我的一些經(jīng)驗, 于是我有了下面的見解。
普遍性和特殊性。
之所以單純引入一套先進的流程不能解決問題，原因也就是事物的普遍性和特殊性。一套流程在A公司運作的好，未必就在B公司運作的好，蘇聯(lián)革命可以在城市中進行，在中國就必須要“農(nóng)村保衛(wèi)城市”。CMMI 所闡述的思想并不是針對某個特定的公司的，而是從一個普遍意義上的軟件項目考慮，把它們的共性提煉出來，得出理論上的推理。一個公司完全按照CMMI思想去制定一套流程，不一定就解決了所有的問題，很可能還會產(chǎn)生更多的問題。在引入CMMI的時候一定要結(jié)合公司現(xiàn)實，在不能洞察公司特殊性就全面實踐CMMI思想，一定會出問題的。
CMMI中有“Stage”和“continue”兩種描述方式，Continue是按照過程類來編排，Stage是按照成熟度來編排的，很多公司熱衷于Stage方式，CMMI –3, CMMI-5的評級，當然這樣有助于公司的宣傳，有助于項目的竟標，然而，對于一些公司來說，這種方式并不適合，這樣做反而會得不償失，Continue方式才是合適的選擇。比如有些公司的IT開發(fā)部門，他們和專業(yè)的軟件公司有很大的不同，只需要專心實踐有限的幾個過程域即可。
對于每一個項目的開發(fā)過程來說，也要對流程進行剪裁，以適合本項目的特殊性要求。A項目中開發(fā)人員能力欠缺，我就要對設(shè)計人員提出更高的要求，B項目需求多變，我就要先做模型開發(fā)，C項目技術(shù)相對成熟，我就可略過可行性分析評估．
有一個提法叫”光環(huán)效應”, 成功的企業(yè)憑著耀眼的光環(huán)輸出自己的管理思想, 然后眾人開始熱烈追捧, 無數(shù)的公司著手引入這些先進理念, 然而少有公司成功。 為什么? 《從優(yōu)秀到卓越》暢銷多年了, 能夠做到卓越的公司還是少之又少, 根本原因就是沒有認識到本公司的特殊性, 沒有切合實際, 和燒香拜佛的迷信活動并無本質(zhì)區(qū)別。
那些名將在戰(zhàn)場上可以一眼識別出戰(zhàn)爭的關(guān)鍵處，從而采取不同的策略。岳武穆曾曰”運用之秒,存乎一心”．可見，很多不能言傳的秘訣都有它的哲學根據(jù)。
主要矛盾和次要矛盾。
通常我們對項目經(jīng)理的認識是，他負責項目的定義、設(shè)計、構(gòu)建、測試全過程，日常就是分配任務(wù)啊，驗收任務(wù)啊，開會啊等，就像一個“當官的”。如果這種認識被固定在項目經(jīng)理心中，那會產(chǎn)生非常消極的后果。
一個好的項目經(jīng)理，他應該對項目有清晰的認識，知道當前的主要矛盾，并投入大部分的精力去解決，他沒有固定的工作范圍，他可以做任何他認為有必要做的工作。歷，有在后方運籌帷幄決勝千里的將軍，也有親臨前線沖鋒陷陣的將軍，將軍要不要甘當士卒，沖鋒陷陣，完全取決于戰(zhàn)場上的形式，也即是當時的主要矛盾，如果士氣高漲，士卒個個如狼似虎，將軍完全可以安坐于中軍大帳中。
對瞬息萬變的戰(zhàn)場情勢能夠洞若觀火的，才是名將之才，同樣，能夠?qū)椖棵總€時段主要矛盾的認識，也是項目經(jīng)理必修課。有的項目客戶看重的是UI，那么我就要重點監(jiān)督用戶界面的開發(fā)并及時拿去找客戶，有的項目主要矛盾是性能，那么我就要化大的力氣在優(yōu)化性能上，如果某個項目客戶很“刁”，那么項目經(jīng)理就要找點時間多和客戶搞搞關(guān)系。當然了，如果某個項目根本就不可行，而是老板為了其他政治目的立項的，那你就要為避免成為受害者而留個心眼。
我們經(jīng)常犯的一個錯誤就是化太多的時間和精力在次要矛盾上，并不是說處理次要矛盾本身錯了，而是它占有了大量的時間和資源，從而沒留下足夠的時間和資源來處理主要矛盾，這是一個非常頻繁并引起很多爭論的問題．一個典型的例子是一個項目的主要矛盾是需求變化頻繁，而且客戶的要求還必須做到，有些人就把大量的時間資源用到了需求管理的流程和文檔資料的完備，其實如果能做到良好的設(shè)計和代碼，來支持未來的變化，從而使未來處理需求變化所用的時間和資源更少，這樣或許更有效的降低此項目的總成本。
在分析和系統(tǒng)設(shè)計的時候, 有些設(shè)計者往往花更多的時間去使用工具畫圖, 而留給思考的時間并不多, 本來設(shè)計師在草稿或者畫板上工作愜意, 因為你可以根據(jù)自己的思路自由的去更改, 而一旦被工具所束縛, 除了花大量的時間去學習, 卻仍不容易做到準確, 而且早早的畫到了Rose上, 記住人都有惰性的, 頻繁的去*好不容易畫好的圖形可不容易做到。
當開發(fā)人員的代碼質(zhì)量不高時, 主要矛盾是代碼而不是測試, 如果你一味加強測試時間,將使開發(fā)者和測試者疲于奔命, 效果卻甚少改進. 一段代碼, 有經(jīng)驗的人細細審查, 找出可以改進之處并改之, 無數(shù)潛在Bug便消失了, 試想如果指望在測試階段發(fā)現(xiàn)這些問題, 要花多少力氣？
靜止與發(fā)展。
能夠正確地找到當前的主要矛盾，是很了不起的，我強調(diào)”當前”的意思是說明主要矛盾一直在變化，解決了一個矛盾，會有下一個矛盾等待你，過幾天，當前的次要矛盾就可能成為主要矛盾，一切事物都在變化．所有的變化都不應該引起你的驚訝，都需要你用智慧和技巧去應付。
需求不是靜止的，設(shè)計不是靜止的，代碼更不是靜止的，這個道理大家都懂，卻少有人能從心理接受，回想一下，開發(fā)者對不斷變更的設(shè)計是否很憤怒？你對客戶一會一個主意是否很反感？你是否認為完成一個功能的代碼就可以丟下不管了，除非出現(xiàn)Bug？
《重構(gòu)》是和《設(shè)計模式》齊名的一部書, 很多人熱衷于研究一個一個“模式”, 而對“重構(gòu)”卻缺少興趣. 在我看來, 《重構(gòu)》是更重要的一部書,具有更現(xiàn)實的指導意義, 因為它告訴了我們一個簡單的道理: 沒有人一開始就能做成優(yōu)良的軟件設(shè)計, 根據(jù)這個設(shè)計直接寫出代碼, 然后一切OK. 就算《設(shè)計模式》作者這樣的大師都沒這個能力, 相反, 書里面列出的設(shè)計模式無一不是在重構(gòu)的基礎(chǔ)上, 在大量實踐的基礎(chǔ)上不斷優(yōu)化和思考而來的!
迭代開發(fā)的思想也來源于此, 如果事物都是靜止的, 那就不用一遍又一遍的去修改或者重做你的工作了, 迭代開發(fā)讓人不適應, 因為我們習慣于開過評審會議后, 長長的舒一口氣, 終于可以放下了, 然而你我并不知道, 評審并不能做到全面和深入, 只有你自己心里有數(shù), 同一個工作, 也不可能一遍又一遍的開評審會議, 我們花不起那么多時間, 更多的要依靠工作者自己的責任心和對逐步求精思想的理解。
理論與實踐
“知行合一”是明代大哲學家王陽明先生提出的主張之一, 他本人也完全實踐了這一思想, 作為明代牛的人物(愚見), 王陽明是中國歷屈指可數(shù)的幾位既“立德”、“立言”又有“立功”的牛人之一。 雖然我對此的理解仍然膚淺, 毛主席的矛盾論也僅知皮毛, 不過還是覺得如果我們能夠把一些哲學思想用到自己的工作實踐中來, 而不糾纏于”屑小思想”的束縛, 一定能夠”從勝利走向勝利”!
現(xiàn)實中一個軟件項目能夠“按時、按質(zhì)、按量”的完成，并且能夠讓客戶滿意是非常不容易的，為了提高軟件項目的成功率，很多公司制定了一系列的流程，引入諸如”CMMI”等流程標準，不時的變動組織架構(gòu)，的目標就是確保項目的成功，并且一直能成功下去，“從勝利走向勝利！”
流程制定當然是必須的，一個軍隊里也會有各種各樣的流程守則，比如士兵訓練守則，挖戰(zhàn)壕流程，沖鋒流程等等(猜想)。一個經(jīng)典例子的是戚繼光制定的《鴛鴦陣》，對于防守、攻擊；遠攻，近攻；平地、巷戰(zhàn)等等都有天才的設(shè)計。老板、項目經(jīng)理們夢寐以求的“寶典”也不外乎此類了。然而，幻想一個流程解決所有問題，起碼在軟件工程領(lǐng)域內(nèi)的項目中，還很不實際。軟件工程中變數(shù)太多，因素太多，基礎(chǔ)的工作都需要人來作出思考和判斷．這就需要更多的智慧和經(jīng)驗。在保證基本的流程運作順利基礎(chǔ)上，還對“將”的要求很高。如果說流程是“兵法”的話，項目經(jīng)理要懂得靈活運用，決不可以“紙上談兵，生搬硬套”。而要學會運用“矛盾論”。
基于對《矛盾論》的一些粗淺認識, 結(jié)合我的一些經(jīng)驗, 于是我有了下面的見解。
普遍性和特殊性。
之所以單純引入一套先進的流程不能解決問題，原因也就是事物的普遍性和特殊性。一套流程在A公司運作的好，未必就在B公司運作的好，蘇聯(lián)革命可以在城市中進行，在中國就必須要“農(nóng)村保衛(wèi)城市”。CMMI 所闡述的思想并不是針對某個特定的公司的，而是從一個普遍意義上的軟件項目考慮，把它們的共性提煉出來，得出理論上的推理。一個公司完全按照CMMI思想去制定一套流程，不一定就解決了所有的問題，很可能還會產(chǎn)生更多的問題。在引入CMMI的時候一定要結(jié)合公司現(xiàn)實，在不能洞察公司特殊性就全面實踐CMMI思想，一定會出問題的。
CMMI中有“Stage”和“continue”兩種描述方式，Continue是按照過程類來編排，Stage是按照成熟度來編排的，很多公司熱衷于Stage方式，CMMI –3, CMMI-5的評級，當然這樣有助于公司的宣傳，有助于項目的竟標，然而，對于一些公司來說，這種方式并不適合，這樣做反而會得不償失，Continue方式才是合適的選擇。比如有些公司的IT開發(fā)部門，他們和專業(yè)的軟件公司有很大的不同，只需要專心實踐有限的幾個過程域即可。
對于每一個項目的開發(fā)過程來說，也要對流程進行剪裁，以適合本項目的特殊性要求。A項目中開發(fā)人員能力欠缺，我就要對設(shè)計人員提出更高的要求，B項目需求多變，我就要先做模型開發(fā)，C項目技術(shù)相對成熟，我就可略過可行性分析評估．
有一個提法叫”光環(huán)效應”, 成功的企業(yè)憑著耀眼的光環(huán)輸出自己的管理思想, 然后眾人開始熱烈追捧, 無數(shù)的公司著手引入這些先進理念, 然而少有公司成功。 為什么? 《從優(yōu)秀到卓越》暢銷多年了, 能夠做到卓越的公司還是少之又少, 根本原因就是沒有認識到本公司的特殊性, 沒有切合實際, 和燒香拜佛的迷信活動并無本質(zhì)區(qū)別。
那些名將在戰(zhàn)場上可以一眼識別出戰(zhàn)爭的關(guān)鍵處，從而采取不同的策略。岳武穆曾曰”運用之秒,存乎一心”．可見，很多不能言傳的秘訣都有它的哲學根據(jù)。
主要矛盾和次要矛盾。
通常我們對項目經(jīng)理的認識是，他負責項目的定義、設(shè)計、構(gòu)建、測試全過程，日常就是分配任務(wù)啊，驗收任務(wù)啊，開會啊等，就像一個“當官的”。如果這種認識被固定在項目經(jīng)理心中，那會產(chǎn)生非常消極的后果。
一個好的項目經(jīng)理，他應該對項目有清晰的認識，知道當前的主要矛盾，并投入大部分的精力去解決，他沒有固定的工作范圍，他可以做任何他認為有必要做的工作。歷，有在后方運籌帷幄決勝千里的將軍，也有親臨前線沖鋒陷陣的將軍，將軍要不要甘當士卒，沖鋒陷陣，完全取決于戰(zhàn)場上的形式，也即是當時的主要矛盾，如果士氣高漲，士卒個個如狼似虎，將軍完全可以安坐于中軍大帳中。
對瞬息萬變的戰(zhàn)場情勢能夠洞若觀火的，才是名將之才，同樣，能夠?qū)椖棵總€時段主要矛盾的認識，也是項目經(jīng)理必修課。有的項目客戶看重的是UI，那么我就要重點監(jiān)督用戶界面的開發(fā)并及時拿去找客戶，有的項目主要矛盾是性能，那么我就要化大的力氣在優(yōu)化性能上，如果某個項目客戶很“刁”，那么項目經(jīng)理就要找點時間多和客戶搞搞關(guān)系。當然了，如果某個項目根本就不可行，而是老板為了其他政治目的立項的，那你就要為避免成為受害者而留個心眼。
我們經(jīng)常犯的一個錯誤就是化太多的時間和精力在次要矛盾上，并不是說處理次要矛盾本身錯了，而是它占有了大量的時間和資源，從而沒留下足夠的時間和資源來處理主要矛盾，這是一個非常頻繁并引起很多爭論的問題．一個典型的例子是一個項目的主要矛盾是需求變化頻繁，而且客戶的要求還必須做到，有些人就把大量的時間資源用到了需求管理的流程和文檔資料的完備，其實如果能做到良好的設(shè)計和代碼，來支持未來的變化，從而使未來處理需求變化所用的時間和資源更少，這樣或許更有效的降低此項目的總成本。
在分析和系統(tǒng)設(shè)計的時候, 有些設(shè)計者往往花更多的時間去使用工具畫圖, 而留給思考的時間并不多, 本來設(shè)計師在草稿或者畫板上工作愜意, 因為你可以根據(jù)自己的思路自由的去更改, 而一旦被工具所束縛, 除了花大量的時間去學習, 卻仍不容易做到準確, 而且早早的畫到了Rose上, 記住人都有惰性的, 頻繁的去*好不容易畫好的圖形可不容易做到。
當開發(fā)人員的代碼質(zhì)量不高時, 主要矛盾是代碼而不是測試, 如果你一味加強測試時間,將使開發(fā)者和測試者疲于奔命, 效果卻甚少改進. 一段代碼, 有經(jīng)驗的人細細審查, 找出可以改進之處并改之, 無數(shù)潛在Bug便消失了, 試想如果指望在測試階段發(fā)現(xiàn)這些問題, 要花多少力氣？
靜止與發(fā)展。
能夠正確地找到當前的主要矛盾，是很了不起的，我強調(diào)”當前”的意思是說明主要矛盾一直在變化，解決了一個矛盾，會有下一個矛盾等待你，過幾天，當前的次要矛盾就可能成為主要矛盾，一切事物都在變化．所有的變化都不應該引起你的驚訝，都需要你用智慧和技巧去應付。
需求不是靜止的，設(shè)計不是靜止的，代碼更不是靜止的，這個道理大家都懂，卻少有人能從心理接受，回想一下，開發(fā)者對不斷變更的設(shè)計是否很憤怒？你對客戶一會一個主意是否很反感？你是否認為完成一個功能的代碼就可以丟下不管了，除非出現(xiàn)Bug？
《重構(gòu)》是和《設(shè)計模式》齊名的一部書, 很多人熱衷于研究一個一個“模式”, 而對“重構(gòu)”卻缺少興趣. 在我看來, 《重構(gòu)》是更重要的一部書,具有更現(xiàn)實的指導意義, 因為它告訴了我們一個簡單的道理: 沒有人一開始就能做成優(yōu)良的軟件設(shè)計, 根據(jù)這個設(shè)計直接寫出代碼, 然后一切OK. 就算《設(shè)計模式》作者這樣的大師都沒這個能力, 相反, 書里面列出的設(shè)計模式無一不是在重構(gòu)的基礎(chǔ)上, 在大量實踐的基礎(chǔ)上不斷優(yōu)化和思考而來的!
迭代開發(fā)的思想也來源于此, 如果事物都是靜止的, 那就不用一遍又一遍的去修改或者重做你的工作了, 迭代開發(fā)讓人不適應, 因為我們習慣于開過評審會議后, 長長的舒一口氣, 終于可以放下了, 然而你我并不知道, 評審并不能做到全面和深入, 只有你自己心里有數(shù), 同一個工作, 也不可能一遍又一遍的開評審會議, 我們花不起那么多時間, 更多的要依靠工作者自己的責任心和對逐步求精思想的理解。
理論與實踐
“知行合一”是明代大哲學家王陽明先生提出的主張之一, 他本人也完全實踐了這一思想, 作為明代牛的人物(愚見), 王陽明是中國歷屈指可數(shù)的幾位既“立德”、“立言”又有“立功”的牛人之一。 雖然我對此的理解仍然膚淺, 毛主席的矛盾論也僅知皮毛, 不過還是覺得如果我們能夠把一些哲學思想用到自己的工作實踐中來, 而不糾纏于”屑小思想”的束縛, 一定能夠”從勝利走向勝利”!