老翅寒暑

項目管理沙龍第六次聚會紀(jì)要--模式“蘋果酒屋”

《項目百態(tài)》模式36名字叫“蘋果酒屋”。大意是說，蘋果酒屋是工人們下班之后的聚會場所，他們經(jīng)常在吃完飯之后，一起爬到房頂上去乘涼，喝啤酒。于是女主管就制訂了蘋果酒屋規(guī)則，基本上就是“不許爬到房頂上”，“不許喧鬧”等諸如之類的規(guī)定。可想而知，這種“蘋果酒屋規(guī)則”不會有人遵守的。因為規(guī)則的制定者從來不會在蘋果酒屋住宿，也當(dāng)然不會知道屋頂上是那里唯一涼快的地方。

這種“局外人”制定規(guī)則的情況在企業(yè)內(nèi)部非常常見，最終的結(jié)局也都和“蘋果酒屋規(guī)則”差不多。會上列舉了幾種常見的推廣場景，一種是“強推法”。比如“空降”到項目組或公司的能人，經(jīng)常會不顧公司的現(xiàn)狀，強行給他的下屬制定各種規(guī)則，試圖將做出改變。這種強推的手法，經(jīng)常會導(dǎo)致項目組的動蕩，進(jìn)而引發(fā)人員的非正常變動。但是強推并不總是壞的，當(dāng)年華為從IBM引進(jìn)并推行制度的時候，也是一樣是強推，并且任正非還特意強調(diào)幾年之內(nèi)不許改。一種是“循序漸進(jìn)”推進(jìn)法，一點一點地讓“局內(nèi)人”去體驗，逐步獲取經(jīng)驗，然后加入更多的規(guī)則，最后所有的規(guī)則都生效。這種做法需要耗費很長的時間，并且還需要專人進(jìn)行跟蹤和分析；一種是“自制規(guī)則”，這個也是《項目百態(tài)》的作者推薦的方法，即由游戲者自己來指定規(guī)則。這樣無論是規(guī)則的接受程度，還是實施的效果，都會非常的好。但是這種方法容易走彎路；另一種是“專家法”，即通過利用具有專家身份的人，來向大家推行新規(guī)則，并且在規(guī)則的實施過程中不斷地解答游戲者提出的問題。專家可以讓游戲者快速地形成共識，并且朝正確的方向前進(jìn)，但是同樣需要在實施過程中進(jìn)行跟蹤和監(jiān)督，及時對方向調(diào)整。

這些做法都各有利弊，歸納起來，無非就是時間、空間和效果上的折衷和平衡。談到這里，有人從自身的經(jīng)歷，談到了程序員做了一段時間的測試之后，再回去寫代碼的話，代碼質(zhì)量會變得很好，很容易測試。這種角色的互換，比推行任何一種“測試要求”/“測試標(biāo)準(zhǔn)”的效果都要好。這時，有人舉出了DT網(wǎng)項目的例子，因為第一期已經(jīng)進(jìn)入了維護(hù)階段，所以該項目的下一階段的開發(fā)項目就明顯開始注重質(zhì)量了。

相比這種通過“自身實踐”得到的改變，讓專家對工作進(jìn)行總結(jié)，得到“最佳實踐”方法之后，在全公司推廣并評估效果，這種效率就會高很多。其實這么做也就回到了我們剛才講的“專家法”的推廣了。

因為剛才談到了“測試”問題，所以話題繼續(xù)圍繞測試展開。有人談到了測試人員的水平問題。現(xiàn)在很多公司里，程序員的薪資水平要比測試人員要高很多，也就是程序員的編程水平通常比測試人員要高。可是引出了一個問題，就是水平最高的那個程序員的代碼，誰有能力測？這個問題的答案并不簡單，首先要看公司處于什么樣的市場地位，處于領(lǐng)先地位的公司更考慮質(zhì)量一些，處于追趕地位的公司更偏重功能，所以前者的測試要求會比后者高一些。其次要看公司的價值導(dǎo)向，眼光長遠(yuǎn)的公司對質(zhì)量及測試的要求就高，急躁一點的公司對測試的關(guān)注度就小一些。還有就是要看項目的類型，對于產(chǎn)品型的項目，質(zhì)量要求就會高，而對于一次性的定制項目，質(zhì)量要求就低一些。其他還有很多的因素，包括公司的大小、技術(shù)能力等，都會影響到對測試的編制、地位和安排。

雖然如此，但是測試人員的水平大于開發(fā)人員的假設(shè)也并不一定成立。因為測試所需要的并不只是個人能力，和開發(fā)相比，測試有更多的流程，更多的工具，也有更多的有成效的方法來彌補與開發(fā)人員的技術(shù)水平差異。從某種程度上來說，產(chǎn)品的測試并不是依賴測試人員，而是開發(fā)者自己來進(jìn)行的。因為所有的測試類型中，“單元測試”是最重要的測試，而單元測試的主要編寫者恰恰是程序員自己。可是我們發(fā)現(xiàn)大部分的中國程序員都十分痛恨單元測試。我們一位與會者給大家解釋了一大堆的“單元測試”概念，比如測試覆蓋率，條件測試，邊界值測試等等，以及單元測試的重要性又是如何如何。這些話從公司管理人員、項目經(jīng)理、測試人員、客戶以及維護(hù)人員，都非常消受，可是從程序員的角度聽來，則是非常刺耳。雖然從實踐中來看，有適當(dāng)?shù)膯卧獪y試覆蓋的產(chǎn)品和沒有單元測試的產(chǎn)品相比，后期的BUG量可以減少六至八成，但是這么重要的一種編程行為，即單元測試對于程序員的意義，哪怕是TDD都沒有明確地強調(diào)出來：
 
“單元測試可以極大地降低調(diào)試的難度，加快開發(fā)的速度！！！”

這個其實也是我們沙龍要對所有程序員發(fā)出的強調(diào)。實際上，程序員的水平越高，對于測試也就越重視。當(dāng)然，除了提高人員的自覺性之外，要推廣單元測試還需要流程和制度的安排，比如結(jié)對測試。另外，測試的獨立性也很重要，現(xiàn)在的測試都是被開發(fā)牽著鼻子跑，這種情況嚴(yán)重降低了測試的效率。

在討論中，有人提到了一種反面現(xiàn)象，就是如果片面強調(diào)單元測試覆蓋率的話，會有人只寫出測試“永遠(yuǎn)正確”的單元測試來（顯然這是中國式應(yīng)試教育的變種）。經(jīng)過討論，大家認(rèn)為這種情況并不嚴(yán)重：通過培訓(xùn)，可以提高程序員們對測試的能力；通過引導(dǎo)，可以讓程序員們意識到1到2年的開發(fā)時間和10年為單位的運行維護(hù)時間相比，眼光應(yīng)該更多落在持續(xù)的維護(hù)和升級上，避免一些短期行為對產(chǎn)品質(zhì)量的影響。

最后，大家總結(jié)出來了一種“代碼show”的方法，就是項目組不定期地召開“代碼秀”，讓項目組每個成員都找出自己寫的最好的代碼和最差的代碼，展示并解釋給大家，并集體討論和分析，甚至還可以請專家點評。會議不做記錄不批評更不做考評，讓與會者可以沒有后顧之憂。通過這種方式，我們覺得是有助于提高大家編碼能力的。

嗯，這樣算是“專家推廣法”么？哈哈！