2022第一季尾端，我們團隊上線了一個產品
雖然說是產品，但感覺比較像是一個企業的新創團隊，所創造出的一個新的服務模式。對於我來說，我沒有經歷過市場調研、競品分析，從最初的願景落到User Story，再落成規格、可執行的、可驗收的成果。
也因為各種因素，包含溝通、時間、範疇等所有專案會遇到的難處，讓這個服務最終延遲了4個月上線。還好他還是上線了，也在上線的過程中學習到很多，把一些心得記錄在這裡，希望未來回來看的時候，我們可以更成長茁壯。
我們從未面對真的使用者，我們也絕非使用者
千萬別假裝是使用者，想想這個產品上線之前，礙於時間的關係，我們總是在最後才面對用戶。
上線後得到了很多真實的使用者心聲，且這次是一次上線三個平台，三種不同的用戶模樣。這三種用戶，和面對公司內的利害關係人，產品要做到的程度的拿捏，確實是一個考驗。
想想也是，那些我們關在辦公室裡幾個人討論出來的小貼心，和那些因為我們熟知流程而忽略了易用易懂的原則，而創造出需要「想一下」才懂的行為和動作，無形的建立了產品與使用者的距離。
而產品經理的角色，應該要堅持、爭取的去面對用戶，去理解、保持開放、和好奇心。
也希望不要再被時間困住了，創造出快的產品，但不是易用的產品，這個可能也不是大家想要的。
不符合預期，而什麼是預期？如何管理與預期之間的落差
而在這次上線的過程，得到的反饋則是負面評論大於讚美。跟ＸＸＸ比起來真的是很難用，不懂為什麼要做這個，有這樣的流程。
最常聽到的就是「ＸＸ功能本來救應該要….」，「你們是專業的工作者，但怎麼沒會想到這個…」。
通常在這樣的語句發生的同時，我們都已無法還原建置系統的當下的時空背景，無法替當時的自己回頭檢視「啊，原來當時的想法是這樣啊。」以以往的專案經驗，在面對如果是甲方的時候，乙方通常會習慣勤留紀錄，為確保彼此的共識，確保降低需求與系統的落差，做出如期如質的專案。
但在自己公司體系內呢？可能長官一句話、可能非做不可的時候，我想能做到的就會是很依賴於所有事前的溝通，拼命地達成共識。當然，還有一定的信任度問題了。
用淺顯易懂的方式溝通，將一切建立在客觀事實的基礎上，所有的決策都是有來源的，如果有數據就更好。
那關於比較，前面提到這是一個從0到1的產品，拿小蝦米去比大鯨魚本身就是不對等的事情，但有夢最美，一定會有個業務幾句。當我們眼前看著80分的東西，即便我們用了120分的努力在很短的時間內從0創造出60，老闆會在意的，就是為什麼不是80分，甚至更高。
但不是做不到的，對吧。最簡單的說法是需要時間。
相信只要有足夠的時間，這些用了120分的努力的我們，絕對是可以做出超過80分的。在這樣的情況下，需要去溝通的就是不段的取捨了。
所以如何管理預期上的落差就是非常重要的事情，在我的經驗中有以下幾個方法
- 每次的討論透過畫面、紙筆輔助，避免空口談流程
- 對每一件事多一點好奇，理解需求端的想法根本。例如：從哪裡看到這樣的想法的、在什麼情境下有了這樣的想法？是遇到了什麼問題想要解決嗎？
- 產出易懂清楚的規格文件，讓所有人對這個產品的理解在同一個水平線上。橫向溝通是必備的！多去跟各單位了解，雖然這樣可能會收很多需求回來，對焦預期值與現況更是重要的。
- 多溝通、多溝通、多溝通。
系統是人創造出來的，他沒有應該要有什麼。
最後，想說的是系統是人創造出來的，他是一個機器，一個運算機器。你沒有定義他的，他不會自己產生。
這個概念會給我們幾個想法，常聽到人們說：「業務流程就是這樣，所以系統也應該要這樣。」但系統不會懂業務流程，中間需要有好幾個角色、定義它、執行它，去符合所謂的業務流程。這也是我們平常在做的工作。
需求沒說的，系統不知道。也會在這樣的落差下，創造出所謂的「爛」系統。但系統沒有不對，是前面溝通的過程、人們所謂的應該，而產生的落差造成的結論。
反之，bug也因為這樣，一定有一個邏輯。他不會突然產生，總是會有跡可循。在解bug的過程中某種程度也是在考驗自己對系統的熟悉度。如果能重現、能有一個邏輯，那工程師就好解決了。
一點點心得分享給大家，這個文章也放在我的檔案夾裡好久了，希望有機會看到人，可以分享你的心得給我喔！
逛逛我其他的文章