在上一篇文章《敏捷方法的成功密技（三）：Scrum如何擺脫「產品客戶不愛，團隊熱情不再」的窘境？》中，我們談到了Scrum架構可以協助「部份」解決溝通斷層的問題。若是想徹底一點改善溝通斷層的問題，則還需要把在更前端「產品定義階段的相關活動」也都納入Scrum的架構內來運作才行。
除了流程架構這個「外功」，還有一個更為重要的「內功」，那就是團隊成員的組成。不僅團隊成員的能力要夠多元，多元到團隊能夠獨立交付出產品或服務，團隊成員間的互動也需要緊密融合為一體。唯有具備這樣的「內功」，然後搭配Scrum的流程架構這個「外功」，團隊所建立的產品，才能最忠實地貼近客戶／用戶的需要，為客戶／用戶解決問題，並同時也為組織創造最大的價值。
接下來，我們就來看一下內外功該怎麼來融合運作。
理想：讓實作者直接面對客戶
請想像一下，如果「實際動手實作」出產品或功能的各類開發人員，包括研發、測試、架構師等，都可以直接和客戶／用戶「面對面」地對談討論需求，不清楚對方意思的時候，就在白板上塗鴉畫圖，然後大家看著圖，比手畫腳地說明彼此的想法，這裡補充一點，那邊改掉一點，漸漸地，你會發現到，白板上的圖跟最早的原始圖差異開始愈來愈大，也許一半以上都被翻盤掉了！這到底是好事還是壞事？
最後，因為時間的限制，在場的人一定都會同意，白板上的圖和補充的資料，即便不是「最完美」的解決方案，卻也已經是個「足夠好」的解決方案。然後，這張白板圖被翻拍成照片，做為會議紀錄的一部份，寄發給所有的與會者（當然還可同時知會其他相關人員），並再次限時確認一次。
這樣的在需求「提出者」與需求「實做者」之間「直接溝通互動」所形成的「共識」，您覺得還有可能會被實作者誤解、做錯，最後導致客戶不同意驗收嗎？我想大家應該都會同意，這樣的機率應該是微乎其微了吧！不過，事情真有這麼簡單美好嗎？
現實：人性的障礙
要讓上述的溝通模式能夠被落實，還需要解決「人」的「意願」和「能力」！我們就來看看，有哪些障礙需要先被突破。
首先是客戶的態度。客戶出錢將專案發包給你的公司，為什麼還得常常花費大量時間（甚至可能會超過50%的工時都得花在這個專案上）來陪你討論需求、釐清需求、甚至是設計方案？很多客戶（應該說窗口）並不想花這樣的effort，可是卻期望只透過幾次的文件討論，就能溝通好需求。這是標準的「既要馬兒好（需求被100%了解），又要馬兒不吃草（又不想花時間好好討論）」的狀況。
其次是實作的工程人員的態度。一般來說，工程師們比較習慣和電腦、儀器設備做溝通，要他們與客戶端做頻繁的溝通，他們往往會不太適應。最常聽到的就是「太浪費時間」，頻繁的溝通導致他們沒有足夠的時間去實作產品或服務的功能！
第三是需求規模的龐大。一個產品或服務往往包含許多的功能和實作細節，軟體產品尤其是如此。在這種狀況之下，想要每個功能都能讓「客戶／用戶」和「實作者」直接溝通討論清楚，似乎真的是非常耗時的一件事情。況且，也不可能有這麼多、這麼大的白板來讓我們一直畫畫下去。
Scrum的三種角色
Scrum的三種角色
既然「人性」是上述三個主要障礙中的兩大部分，尤其軟體產品或服務的品質，與人的素質和心態又是極度地緊密相關連，那麼，我們就先來看看，Scrum到底定義了哪些角色，來試圖「緩解」（注意我用這字眼，不是用解決）這些理想與現實之間的差距。
Scrum其實總共「只」明確定義了三種角色，就是所謂的Product Owner產品負責人、Scrum Master 大師，以及Development Team開發團隊，分別負責對外溝通、對內管理、以及實際實做和驗證。然而內外之間總得有交流互動，方可能進入實作，實作又得有規有矩，方能有效產出成果，於是簡單的角色定義，和實務上的複雜，開始出現衝突！這部分因篇幅過長，我們就待下篇文章來繼續探討囉！
待續...
圖片來源：www.inc.com
相關文章：