[全程建模]交換程式設計中的大鍋飯問題

關於大鍋飯的問題很多朋友有疑問，這裡進行了一些說明，同時與結對程式設計進行了對比分析。

發信人: muser (負盡千重罪，練就不死心), 信區: SoftEng
標  題: Re: 交換程式設計方法介紹
發信站: 水木社群 (Thu Mar 24 14:07:10 2011), 站內

現在的思路好象把程式設計師超頻至可以穩定的極限~~~

結對程式設計，一個人去拉粑，另外一個也許就得去尿尿。
最起碼，一個人在找獵頭打電話，就沒辦法向另外一個人交待。
兩男人坐一起，你想上個網灌個水，沒興趣。很多碼農是獨語者。

兩人的精神狀態得同相。

每天8小時抖擻精神幹下來...不讀幾次博士怕是培養不出這種素養。

交換...？工作業績怎麼衡量？搞不好成了吃大鍋飯的了。

回答：

這裡我先提一個問題：
大家平時做開發的時候，如果某個人就是在吃大鍋飯，始終拖延進展或者技能不足，你怎麼辦？
難道你要等著所有的模組都開發完，然後等待這個模組的開發進展麼？
這個時候，專案管理者或者負責人自然會對這個人提出疑問，要求他加快進度，或者不能承擔就改做其他模組，這裡就出現兩個分支：
1、這個人改做其它模組開發仍然無法完成。
如此多了，我不相信領導會不考慮處理問題，比如辭退，扣除獎金等等懲罰措施。
2、改做其他模組完成了，原有模組誰來承接？承接者怎麼辦？
承接者的績效如何衡量？難道不是一樣的進行衡量計算麼？——這裡暫時不討論目前的績效管理模式的不合理的地方（如果非要合理的，參看我的可度量績效管理模型中的一些建議，應該會有一些可操作的好一些的辦法）。
既然有新的承接者，自然就會形成接近交換程式設計/開發中的績效承接計算方式。
上面問題的另一個解決辦法：領導安排人指導這個人進行該模組的開發，指導者的績效如何計算？現有的績效管理模式中也必須提供一些辦法，哪怕是拍腦袋的方式進行的計算。
如此而來，交換程式設計/開發會形成大鍋飯模式的疑問是不是解釋清楚了？
其實，更多的人擔心的應該還是結對開發中的大鍋飯問題，因為兩個人是同一個任務，無法衡量兩個人在這個組合中各自的貢獻問題才對，而不是交換程式設計的績效問題。

不知道是否解釋清楚這個問題，大家可以繼續討論。
【 在 loafer (狒狒) 的大作中提到: 】
: muser只是提醒我們應該儘量考慮“非理想環境”下如何去經營軟體開發的管理，
: 不要理想化工作環境，或理想化參與開發的人員結構。
: 這本身是一種務實的態度，不對吧？
: ...................

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/257598/viewspace-690551/，如需轉載，請註明出處，否則將追究法律責任。