盲點之所以為盲點,就是指看不到的地方。而軟體工程中的盲點,卻往往不是真的看不到,而是選擇不去看到,或是主觀的接受一種特定的思考而刻意排斥其他方法。如何能跳脫既有的主觀見解,從其他角度來看同樣的事件,便成為一個很重要的能力。
很久以前有人出了一個有趣的題目給我,剛好符合這個主題。有九個點,排成如下圖的樣子,相鄰距離都相等,每個點是正田字的交點。而題目是要求受試者以一筆畫出四條連續的直線,貫穿這九個點。也就是一筆可以有三次轉彎的機會,但只能是直線。
應該有不少人在被問到這樣的問題時,會花上一段時間,才能找到答案。因為這個題目中,有個看不到的陷阱,侷限了受試者的思考邏輯。當然,並不是所有人都會被這個陷阱影響到,因為這跟每個人過去的經驗以及思考方法有關。
跳脫原有思考模式其實是非常困難的,但是如果能透過第三者的提醒就不一樣了。正所謂忠言逆耳,別人的提醒,若與自己的想法相左時,往往就不容易被採納。適度的在接收到某些負面資訊時,能夠多花一些時間,在拒絕之前,多深入了解,就可以排除很多自己原先看不到的缺點。每個人觀察一件事情的角度不同,會發現的或感到不妥的地方也不同。他人會提出不同的質疑或見解時,如果以找到這個不同意見發生的原因為出發點,就能更清楚判斷這個資訊是否有用。接下來我就列舉一些自己經驗裡看到的問題。希望對其他人能有一些幫助。
軟體工程
事情總是沒有絕對的對錯。市場上充斥著許多探討軟體工程流程的書籍以及研究,嚐試找到最好的軟體開發流程、軟體開發人員管理及訓練方法。然而,越多討論及研究的存在,往往表示一個問題非常有可能是沒有正確答案的。這些方法主要都是要解決軟體開發時的盲點以及可能發生的錯誤,而這與該團隊的人員素質及能力有關。極端一點,如果主導開發的人強到不會有設計盲點,初期設計的討論過程就是的沒有意義的。軟體開發人員,如果不會寫出 BUG ,就不會需要測試。如果人員的理解能力夠好,也不需要再規範什麼一致的coding style,程式整齊、拼字正確也就夠了。可是人員的能力素質往往很難正確的量化,以至於很難判斷對特定團隊,應該使用何種管理方式來達到最佳的效率。驗證流程
然而一些人迷信於某些流程,而不能考慮自己參與的團隊與開發軟體的狀況,往往導致反效果。對於大部分小型軟體公司,如果在開始設計軟體時,就耗費過多的成本來在開發流程上,搞不好產品還沒生出來,公司就準備收起來了。小公司賭的是創意與工程師的才能,在現在這樣發展迅速的環境,產品比的是面市的速度,花過多的時間在測試,解問題,產品搞定時,類似功能的產品可能都已經搶了大部分的市占率了。很多時候反而應該是讓產品先出去,再提供修正。一來可以提早面市時間,二來可以試試消費者對於特定功能產品的接受度。也能夠由使用者的回饋來調整軟體開發的方向。測試成本
另一個是成本問題,軟體開發時,開發者肯定是必須先做些初步的測試,以驗證自己是否完成。若公司設有測試人員,軟體開發者必須評估如何能夠利用測試人員的資源,來協助自己完成模組開發的驗證工作。若花上過多時間來保證自己開發的模組的正確性,反而是浪費成本的事情。自己驗證往往看不到真正的盲點,因為自己對問題的了解程度,引導自己開發出產品模組,若有問題,往往就是考慮不周全。而出現盲點時,很可能是對問題的了解程度不足,如此就更難自行測試出問題。研發人員的成本往往比測試人員高很多,若研發人員又不自知,花過多時間在證明自己沒有思考邏輯的漏洞,就是成本的浪費。開發模組的相依性
軟體開發在切割後,很容易就會有相依性問題要解決。A模組可能依賴B模組,而開發A模組的人員往往可能等待B模組的開發人員提供成品來讓自己能夠驗證成果。而這個等待就很容易造成人力成本的浪費。當然,程式開發者應盡力避免這樣的等待,不應需要等待其他模組,提早進行下一步軟體的開發。但是,實務上,軟體開發者並不具備這樣的能力。就像很多軟體工程師在程式開發時,會有編寫邊編譯邊跑看看的習慣。因為他們沒有足夠的信心確定自己所寫的每段程式是否正確。主導設計溝通介面的人,最好能盡早發現這樣的相依性,請被依賴的一方能提早提供雛型,或僅有介面沒有實際功能的模組,以利依賴者進行開發。專制才有效率
軟體開發有許多過程都有很多可有可無的設計,很多模稜兩可的邏輯。溝通與討論實際上可能只是浪費時間。A 說 X 方法好,B 說 Y 方法好,花了一堆時間討論與比較,從設計原理,到未來維護成本等。在很多時候這可能是浪費時間,因為這兩個方法的效益可能根本就差不多。主導開發者必須知道這樣的問題,提早決定某個方向,來避免過多不必要的時間浪費。開發的制度與流程也是如此,訂了就好,修改制度與流程必須評估其必要性與成本。軟體工程師對於制度與流程的改變是非常痛苦的。從員工的角度,若制度上你若有不滿,除非這樣的不滿是共識,否則你應該選擇接受,否則換個工作會比較快。智慧是沒辦法訓練的
或許應該說訓練的成本過高,高到你不應該嘗試。邏輯是個說服的過程,有些人的邏輯,或行事風格很特別。這樣的人,你就別花時間嘗試改變他。而應該適應他的邏輯與行事風格,讓事情能夠平順的進行。笨是沒有藥醫的,個性好,但是笨,你也不需要花時間在改變他的愚蠢。工作是要成本的,你應該換掉這個人。如果你的老闆還願意糾正你,在你不爽之前,你應該想想這個老闆至少還願意花時間來訓練你。以上分享是我看到的一些問題點,現在軟體開發產業變化非常迅速,台灣的軟體業也正在起飛。並非所有過往課程或書籍都能套在現在或台灣的環境。在看一個方法時,除了看他的優點,也應該看看他的缺點與適用的情境。人月神話是我還蠻建議的一本書。軟體開發仍然是商業,應回歸到成本管理上。
0 件のコメント:
コメントを投稿