前天才剛寫一篇對本專案主管的管理方式不滿文章，果不出所料，大夥已忍到臨界點，這兩天連續三位同事提出辭呈，表明要拉起拉鍊，不幹了。
早就料到會如此，只是沒想到會發生在這個節骨眼，這個禮拜業主已答應讓我們複驗，也準備計畫年底要並行上線，結果，重要成員紛紛散去，這個系統還能上嗎？唉，為何每次我做的專案都是曲終人散？ 這該不會是國內軟體專案開發的宿命吧。
國內軟體產業規模實在太小，使得資方不敢貿然自掏腰包養兵千日，只能以案養兵，所以，找的都是傭兵。 找傭兵既可以馬上派上用場，又可以趁機收編優秀的戰將，從中汲取寶貴的經驗，順勢建立自己的專業團隊，我相信每個雇主一開始都是這樣想的。
這個想法乍聽似乎是兩全其美，但實務上卻存在相當大的風險。 試想，一家製造廠在製程、生產線都尚未建立的情況下，他如何去規劃生產計畫，精算生產成本？且在沒有試產成功的情況下，客戶敢下單嗎？
然，在國內的軟體專案業裡，這種沒有生產線就可以競標、跟客戶打包票畫大餅的現象比比皆是。 在沒有精確的成本依據下，只能任由業務在僧多粥少的市場上競價廝殺，像這樣拿到的案子風險能不低麼。
那雇主可沒想這麼遠，他們太迷信傭兵團了，以為花大錢請幾個身經百戰的傭兵，再配上一群剛畢業的菜鳥，就可以高枕無憂搞定一切。等專案進行後，才恍然大悟，一群沒有默契的傭兵終究還是烏合之眾，需要相當一段時間磨合，以整合出團隊的默契。但，這段開發團隊的整合成本，雇主跟業主是不會認帳的，尤其是業主，對於這種沒有整合的團隊當然是無法認同，因而一開始就對開發團隊的能力打了問號，而雙方又不肯正視這個問題的情況下，問題就越滾越大，時間一久，業主也就不再信任開發團隊，專案發展至此，那註定就是悲劇收場了。
為何是悲劇？
因為一個不被業主與雇主信任的開發團隊，意味著日後專案所有的問題，都將由這個苦命的團隊承擔。 這些問題包括：
n 當初沒有成本依據所畫下的大餅開發團對都得買單。
n 在不瞭解開發團隊的產能下，一開始規劃的專案時程、人力配置所產生的修正成本，開發團隊需要加班彌補。
n 開發團隊一開始因為默契不夠、沒有整合好所衍生的後續問題，這些成本開發團隊當然得吸收。
n 國內企業軟體用戶對於軟體系統開發所應擔負的義務與責任認知不足，故在專案開發時業主所產生的問題也不少，但，這些問題將因開發團隊內部混亂無暇精確指出，而本身又不被業主信任，所以，最後也都只能啞巴吃黃連自己嚥了。
最不堪的是，開發團隊所做的這些額外的付出，都將不會得到業主與雇主的認同。 業主不認同的原因是整個開發過程凌亂，對所完成的系統品質堪慮。而雇主則認為傭兵團的表現跟預期差太多，讓專案的獲利大幅縮水，甚至虧損。 這一切傭兵們點滴在心頭，冷暖自知，與雇主難免有心結，日後當然難再有合作的機會。
於是，業主花大錢買到品質堪慮的系統，傭兵收拾行囊繼續漂泊，而雇主依舊是手下無兵，空殼一個。 這樣的結局，應該是悲劇吧。
說了這麼多，面對再次的悲劇，我自己倒也沒啥想法。 能怎樣呢？ 放眼望去到哪還不是一樣，都是不毛之地，好歹這裡的作息已經習慣，不需再重新調適，就先靜待其變吧。
在這裡先預祝已決定離職的同事，一帆風順，從此擺脫漂泊的宿命。 最重要的是，有好的雇主記得幫忙介紹啊，呵呵。
全站熱搜
留言列表
