後面的問題，為什麼這麼簡單又直覺的邏輯和做事步驟，真的在project執行時卻很難做到呢？
先來看看幾個對話：
＜１＞
RD：VT測試發現的這個問題是因為之前interface沒有考慮好相容性的問題，現在要嘛把interface改得更完整，只是接口二邊的模塊也都要動到，schedule一定會受影響，不然就還是用舊的，新的功能就先disable，等以後接口改好了再enable。
PL：這不是給我找難題嗎？怎麼都測試一半了才發現這個問題，設計和實作時怎麼都沒發現功能有問題？而且這個功能是客戶指定要的，怎麼可以disable呢！要改，schedule會delay；不改，又要想辦法說服客戶project沒有這個功能。天啊～～
＜２＞
PL：這個功能一定要現在project後期加進來嗎？為了這個不重要的功能影響project進度，很不值得。
Sales/Boss：很多客戶都要，不在這次平台版本加進來，就要等下一次，那些客戶都等不及了，很可能會轉單到對手那邊去。
PL：這次版本release的主要目的就是給大客戶的，但是大客戶並不要這個功能，是不是可以先找人開發這個功能，但是等這個版本release後，再把功能整合進來以patch的方式release？這樣既不影響現在project的進行，也可以很快讓其他客戶有這個功能。
＜３＞
VT：拜託一下，不要project spec.改來改去的，尤其是已經開始測試之後！我們改test case也是需要時間的。
PL：不好意思，以我的立埸我也不想改規格啊。老闆說要改，而且schedule還是一樣不能delay，我也很頭大。
VT：我知道你也是不得已，但是每次都這樣搞，相關的功能都要重測過，現在平日已經加班在趕schedule了，我看這個星期假日要請大家也來加班才行了。
PL：太感謝了，測試這邊可以配合，那我就少擔一份心，現在還得去協調一下RD這邊的resource呢！
SW process難推展，其實不是只有PL的問題，也不是單一個人的問題，而是公司文化的問題。如果老闆、PM、RD、Sales、Market、FAE等等都站在自己立場想解決自己的問題，以為自己在做對的事，卻不小心或故意忽略、忽視對整體project的影響、成本和得失，那就是看小不看大，常常就這樣因小失大了。
公司文化是很大的題目，其實知道SW process卻很難做到SW process，我想原因可能還有下面幾個：
１、RD習慣做別人定好spec.
底層的工程師一般都只是做老闆交代的事，尤其是年輕的工程師更不太會去問為什麼需要做這個，為什麼要這樣做。工程師的養成已經習慣做別人定好的spec.，人家怎麼說，就怎麼做，大部份的人連去質疑或思考自己做的東西合不合理，有沒有必要，應不應該，是不是有另外的東西可以代替，有沒有可能更好等等。
沒有思考需求面的習慣自然就不會重視requirement。
２、RD不喜歡溝通、不擅長溝通
常常聽到RD抱怨：＜為什麼需求又改了？之前都白做了！＞其實如果你是RD的話，想一想有沒有可能一開始時就充分表達意見，做好溝通和確認requirement的動作，就不會發生後來需求更改的事了呢。
RD溝通的能力一般是比較弱的，也不喜歡溝通，尤其面對的是PM、Sales、Market這些較善於溝通的人時，還沒說話就先縮起來了。
有時RD也會有莫名的自信，看到AB，就以為客戶要的是ABC，而其實客戶要的是ABS，沒說清楚，就很容易產生這種誤會。
３、PL大部份是RD出身
承１、２，RD的養成問題，RD出身的PL很容易忽視requirement的重要性，即使他在RD時也曾抱怨過需求亂改。通常能升為PL的RD能力都很好，在當RD時面對需求改變時，因為範圍小常常也就是辛苦一點就應付過去了，但是當PL時，需求改變可能會牽扯很多人，範圍太大，不是PL自己一個人可以處理的了的，但是身為PL就必須概括承受所有的後果。
痛過才會記住，吃過requirement大虧的PL，就會知道必須要確認所有的requirement。沒痛過的就應該要痛一次嗎？當然也不是，不然我就不用寫這篇文章了。
４、缺少好的、有經驗的PM配合
好的、有經驗的PM會比較重視流程和文件，確定requirement是流程的一部份，產生requirement的文件是project的check list，自然PM就會要求做好requirement的管理。PL有PM的協助、提醒、要求，就比較會重視requirement。
不過有些公司不一定會有PM，或PM的角色弱化，那就只好靠PL自己來當PM了。
５、不認同SW process的流程概念
似乎RD和VT是較客易認同SW process的人，我想跟工作有直接關係應該是很大的原因。老闆、Sales、Market等跟較不接觸實作又很有影響力的人，就容易方便行事，認為SW process不夠彈性，機動性和反應會太慢。其實我想只要有人去整理過去projects因為所謂的＜方便、快速＞所付出的代價和成本（時間、人力、邊際效應），就知道＜方便並不方便＞、＜欲速則不達＞是什麼意思。
６、搶快，闖個紅燈又不一定會出車禍的僥倖心理
常出現，也常出車禍，只是出了車禍卻怪綠燈車輛啟動太早或開太快，決口不提闖紅燈的事。
７、討論requirement要花時間溝通，並沒有實際程式碼的產出，怕老闆看不見績效
RD怕老闆說他沒事幹，更怕老闆說寫文件不算產出，寫code才是王道。其實也不用怕，如果你可以花一天design，三天把code寫完，又何必選擇花一個星期在寫code改code呢！更不用說經過design的code，在測試debug上的時間可以省下多少了。
８、Requirement change是常態，即使一開始確定了，最後還是可能會改
Project難免會有因為老闆一句話、客戶一句話和市場突發狀況而必須修改spec.，project team和PL應該有隨時準備應變的心理準備，但是如果requirement change的常態其實是因為自己一開始沒有搞清楚requirements，導致後來改來改去，那就是自己的問題了。
９、老闆用力壓schedule，還是先做了再說
跟第七點一樣，只是＜老闆壓schedule＞成了光明正大省略確認requirement的藉口，然後等到後面才發現原來做錯了，只好重做一次。
公司文化的形成，還是要看老闆的取向，想推展SW process最重要的關鍵還是要老闆，讓老闆認識SW process，了解SW process之後，才會尊重SW process，認同SW process。
如果你是PL，你可以在你的project導入SW process，當你在公司內有SW process成功的project後，更可以比較與之前project的差異，有這些差異才更容易說服老闆和其他人認同SW process。公司文化也會因為你而有所改變。
沒有留言:
張貼留言