前公司最引以為傲的成功方程式就是＜以快打慢＞，在最賺錢的事業群的確是這樣，因為他們知道怎麼樣才是真的有效率的做法，但是在Ｍ事業群，＜快＞是口號，只是嘴巴喊的，卻不是手上做的。
舉個簡單的例子，平台版本要release，經常性的不是build一次就可以穩定出版，不是哪個bug沒解好，就是什麼出現什麼嚴重的side effect，有時更扯，開機隨便玩一下就當機。搞得PL/PM每次出版本都很緊張，而且已經都有加班到天亮的心理準備。出版本前bug解的很快、功能做的很快、schedule趕得很快，只是到了出版本時，delay、delay、再delay。這樣的劇情，一再地上映。然後版本delay，VT測試的時程受到影響，或VT測試一下就退回版本，一來一回，不儘時間浪費了，VT資源也浪費了，甚至排擠到其他project。
想快，卻愈慢！
＊、如果RD的能力沒有到位，如何期待工作能順利完成？
之前曾發生過以一個簡單的rules（porting guide、mapping rules），讓RD把舊平台的AP改成新平台的AP。RD只是照著rules做＜翻譯＞，但是其實不知道所翻譯的東西是什麼，這樣的SW可信任嗎？我曾經花了一個星期把其中一個AP做code review，就找了二百多個錯誤，其中很多是會造成當機的錯誤，在跟RD解釋過原本AP設計的概念之後，該RD才進入狀況，知道如何快速debug。
為了求快，不先培訓RD的能力，妄想以不嚴謹的rules就想處理複雜的AP，其實更慢了。
＊、如果bug沒解完或功能沒做完，build版本的意義是否只剩給老闆一個交代？
見過太多只是為了達到milestone，讓老闆覺得進度正常，即使project偷工減料或欺騙隱瞞重要問題也要出一個版本。然後想辦法再下一個版本補上或是再多一個版本導入之前未完成的部份，只不過一開始就錯了，往往下一個版本還是錯，愈錯就愈多。
我曾經接手一個可以delay超過一年以上的project，接手後才知道project體質有多虛弱，schedule都是用喊的。可悲的是，這還是老闆很重視的project，公司未來產品的希望，投入龐大的人力、時間和成本，到最後原本只是一場夢而已。
＊、如果晚上才發的bug，就期待RD馬上解完或熬夜解掉，是否合理？品質可以信任？
病急亂投醫，在schedule的壓力下，PL/PM也無計可施，只能把不合理的事情轉嫁到RD身上。如果是偶爾，RD還會併老命幫忙解bug，但是一旦成為常態，而且常常是在星期五晚上通知RD有必解的bug要解，RD已經彈性疲乏，必解已經成了不必解了。
這種常常是一開始就沒有做好計劃，或是一開始的schedule目標就是嚴重的不合理，導致PL/PM必須扭曲正常做事的方式和方法，如果當然schedule沒趕上，還賠上了大家正確做事的習慣。
到底是想快？還是想亂搞？能不謹慎嗎？
沒有留言:
張貼留言