使用者意識

真為基礎、善為核心、美為極致

承[Day24] Scrum失敗經驗談 – 壁壘分明的職務配置中提到的壁壘分明，或從其他篇文章中，也可嗅到一絲訊息，壁壘分明也存在於開發團隊與需求單位之間。新時代的工程師不論是身處在新創或大公司，「使用者意識」是一個讓工程結果更為傑出的重要思維，我相信厲害的工程師，以演算法或工程作品的角度，都能打造出不錯的成果，然而，就像前篇有提到的建立教堂的故事一樣，讓這個作品可以增添光亮的是，為使用作品的人帶來的意義與感受。創辦人那時來鼓勵工程團隊的時候，他分享了在工作上工程的「真善美」，從工程個人與使用者的角度定義了工程師追求的3種層次，「真」，意在打造能正確運行的功能，讓使用者使用時，不會問題百出，能實際解決使用者的痛點，「真」最入門也最基礎的第一件事，是一般工程師在工作上的基本要求；「善」，是以使用者為中心打造使用者良善且便利的功能，在「真」成為我們基礎能力後，能為使用者設想的心，會影響工程作品的效益，能打動使用者作品會觸動使用者發自內人的WOW；「美」，是追求工程領域的最大值，不論是以最短時間將程式完成、讓程式以最有效率的方式運行或發展出令人驚嘆的演算法，讓工程作品成為受過使用者滿意與工程的高技術認可的成就。在失敗經驗分享上，等到這一刻才分享這之間的斷層，主要的原因在於我們整個系列在分享如何打造一個企業內的軟體文化，擁有使用者意識無法很明確地被衡量，而且每個人對於具備使用者意識的程度不同，透過一個良好的機制與文化構築成橋樑，讓使用者和工程團隊有機會彼此暸解更為重要。

渴望知道使用者的為什麼

不強行讓使用者接受很炫的技術解方

身為一個產品經理，做為需求單位和工程團隊之間的夾心餅乾，可以很清楚感受到理解工程團隊的需求單位和渴望為需求單位解決問題的工程團隊的樣貌，我很幸運可以感受到不同的樣貌，先說需求單位，需求單位除非有工程背景，要一步想到一個可以和工程團隊可以溝通的需求或是想法，是不可能的，一個好的需求單位，我覺得絕對要具備2個重點：尊重工程團隊給予的評估與工作模式、對於自己的需求負起全責，如果不信任或不尊重工程團隊的評估與工作方式，基本上合作就是破局的，也同時是提出運用工程團隊的一方，需求的價值與資訊的提供要負起全責，其實也是尊重的一環。而工程團隊，要渴望知道使用者的為什麼，而非強行推銷很炫的工程解方給使用者，放棄技術的多元可能性，同樣為工程出身的我會和工程師這樣說，「我們共同所受的工程訓練，包含邏輯、程式技巧等，這些耗上我們多年的時間，即便現在，我們依舊覺得技術仍無止盡，更遑論要使用者單位提出我們理想中工程答案的需求」既然如此，身為團隊一份子的工程團隊，不就是最佳角色去引領使用者了解技術解方的最佳代言人嗎？不用教會他們資訊工程，只要以「一起解決問題」的同理心去體會使用者，因此，非工程出身的需求單位，需要的是能解決痛點方案，而非技術完美的工程技巧，簡單的一句：「都是需求單位需求開的不好」並不能改變任何事情，身為產品經理的我們，當然肩負起弭平斷層的責任，但相信我，工程師是否具備使用者意識，溝通的結果與所需耗費的成本，會截然不同，只有具備使用者意識的工程師，才能讓對話前進，找到一個好的結果(這裡補充一下，這裡是需求單位沒有其他特殊的大議題，如果有，就是另外一件要處理的事了)。