=== 故事 ===
某日,老師在課堂上想考考學生們的智商,就問一個男孩: 「樹上有十隻鳥,開槍打死一隻,還剩幾隻?」
男孩反問:「是無聲手槍，還是其他沒有聲音的槍麼?」
「不是.」
「槍聲有多大?」
「80~100分貝.」
「那就是說會震的耳朵疼?」
「是.」
「在這個城市裡打鳥犯不犯法?」
『不犯.」
「您確定那隻鳥真的被打死啦?」
「確定.」老師已經不耐煩了,」拜託,你告訴我還剩幾隻就行了,OK?」
「OK.鳥裡有沒有聾子?」
「沒有.」
「有沒有鳥智力有問題，呆傻到聽到槍響不知道飛的？」
「沒有，智商都在200以上！」
「有沒有關在籠子裡的?」
「沒有.」
「邊上還有沒有其他的樹,樹上還有沒有其他鳥?」
「沒有.」 「方圓十里呢?」 「就這麼一棵樹!」
「有沒有殘疾或餓的飛不動的鳥?」
「沒有,都身體倍棒.」
「算不算懷孕肚子裡的小鳥?」
「都是公的.」
「都不可能懷孕?」
「………,決不可能.」
「打鳥的人眼裡有沒有花?保證是十隻?」
「沒有花,就十隻.」 老師腦門上的汗已經流下來了,
下課鈴響起,但男孩仍繼續問:「有沒有傻的不怕死的?」
「都怕死.」
「有沒有因為情侶被打中,自己留下來的?」
「笨蛋,之前不是說都是公的嘛!」
「同志可不可以啊!」
「………….,性取向都很正常!」
「會不會一槍打死兩隻?」
「不會.」
「一槍打死三隻呢?」
「不會.」
「四隻呢?」
「更不會!」
「五隻呢?」
「絕對不會!!!」
「那六隻總有可能吧?」
「除非你他媽的是豬生的才有可能!一槍只能打死一隻！」
「…好吧,那麼所有的鳥都可以自由活動麼?」
「完全可以.」
「它們受到驚嚇起飛時會不會驚慌失措而互相撞上?」
「不會,每隻鳥都裝有衛星導航系統,而且可以自動飛行.」
「嗯,如果您的回答沒有騙人,」學生滿懷信心的回答,「打死的鳥要是掛在樹上沒掉下來,那麼就剩一隻,如果掉下來,就一隻不剩.」
老師推推眼鏡，強忍著要昏倒的感覺，顫抖地說道：「你可以去當程序員了……」
=== 故事完 ===
這是個極誇張的故事，不過卻道出了程式師在分析需求時的應有心態。
提出需求的人有他自己的專業，與程式師的專業很有可能走在一條沒有交點的平衡線上，但程式師的專業之一就是把這些需求變成技術的設計要求；這是一個翻譯的過程，好比如作為火星人的程式師把金星語翻譯給其他同類聽，還要為此作出各種配置。
在這時要記著一點：「魔鬼都藏在細節裡」
需求就像一道陷阱式的IQ題，解題的重點不是自己的智識，而是補捉出題者的用神，只有理解出題者的思路才會有正確的答案。
最常見的陷阱是需求的標題與細節不符，又或者在需求A中沒有的細節，卻在需求B中出現。
不是說提出需求的人在騙你，而是因為專業的不同，對方不一定了解什麼資訊是程式師最是需要，對方可能覺得要求完美，但在技術的角度卻充滿破綻，一不留神就會墮入誤解的魔鬼陷阱。
最後在交貨時，對方質疑與要求不符，他們想要的是一道滿漢全席，但你卻提供了西洋大餐，那你會怎樣做？
A - 文件就是這樣寫，我不會修改的選A，大家之後不相往來；選B，很快又要再做一次。
B - 好，我改……
軟體工程是一件很奇妙的事，法例是不可能以立法原義去做裁決（所以香港也很奇怪），但當軟件交貨時卻可能會有這種聲音 － 「我才不是想要這種軟件！」
這不是傲嬌的台詞，你不會萌得起來，只會頭痛。(除非是這種客戶)
應付這種客人當然辛苦，但同時請捫心自問，技術人員有沒有為需求而與客戶溝通好呢？有沒有先找出細節中的魔鬼 － 可以引起誤會的地方？
其實只要在分析需求時把關好一點，很多問題都可以避免的。
用心跟客戶談需求，分析需求後，指出有些對方未有留意的細節，再因勢利道再提出建議的做法，這不但能減少日後的爭論，同時能建立自己的專業形像，更容易獲得對方的尊重，可以讓合作更容易進行。
最佳的做法是學故事中那學生，就像一位名偵探般懷疑一切的可能性，可是千萬別宣之於口，這會讓人覺得你相當之白目。而且記著你的身份不真的是偵探，別要去盤問客戶，而要以輕鬆的語氣試探，慢慢切入問題的中心 － 你認為最有可能因為需求理解錯誤而出錯的地方。
如果遇著對方有點迷糊時，不妨花點時間去解釋，雖然對方往往想知的僅是解決方案，不過這點解釋的時間讓對方感到被尊重而得到對方的信任。直至真的沒法構通才出最後的方案 － 在合約中列明不包括的事務，當然必需要跟對方解理一次。
當然像是採用像Agile/Scrum般經常快速交付的做法也是一種解決方法，不過那是另一種技巧了。
相關閱讀
沒有留言:
發佈留言