看似合理的跨部門協作討論
周一傍晚下班前，有位別的部門的夥伴詢問我有無時間，想來找我討論。
碰面後，同事說上週五剛好參加了我們的專案進度分享，注意到我們團隊針對某份資料做了一些彙整，而這部分正好與他們近期要進行的項目高度重疊。於是他問我：「我們原本有規劃要處理這個資料源，但你們好像已經在進行？是不是由你們這邊統一處理就好，才不會重工？畢竟都是同一家公司。」
這樣的提議，乍聽之下非常合理。
在大公司裡，本來就應該避免資源重複投入造成浪費的情形。
出於關心，我進一步詢問他們專案進度，與預計的解題思路，但在夥伴進一步分享相關做法後，我開始感覺到，有些疑問。
當MVP變成了「技術先行」
他告訴我，針對問題，他們打算用 MVP（最小可行性產品）的概念，目標是用「相關資訊產生自動化」為原則，希望透過技術來解決大量人工建檔的問題。所以他在分享會中聽到我們有在處理，就想說後續直接接我們處理的資料使用。
聽到這裡，我感覺我自己對這件事的認知與他不同，有必要進行一些說明——
我現階段專案出發點，其實是因為公司內目前沒有相關資料，但它是我們專案使用者真正需要的，所以我們選擇初期用人工彙整的人肉AI，我想先讓使用者能開始使用、有感，再來評估是否投入資源進行後續的資訊解決方案。
我剛表達完，夥伴立刻回應：「如果你們已經做了開發，我們這邊就先不進行，後續再跟你們對接。」
就在當下，我覺得我與對方處於平行時空，為了避免自己的認知盲點，我提出以下問題，並在白板上簡單寫出數字：
「你們的專案思考，假設我們要解決一個資料蒐集的問題，經過我們用心研究後初步結論如下:
屬於使用者需要>>可以自動化的占15%、不能自動化的占35%
不屬於使用者需求>>可以自動化的占18%、不能自動化的占32%
那你們所謂的MVP，指的是屬於使用者需求50%(15%+35%)，還是優先處理可以自動化的33%(15%+18%)?
他想了一下，回答我：「我們目前團隊的方向，屬於後者33%的部分。」
自動化與MVP變成「技術自嗨」
這樣的回應，做實了我的猜測。
這位夥伴是原本後端工程背景出身，這幾年轉換角色擔任PM一職。我先前在SaaS產業做飯店系統創業時，身旁有許多類似的工程師專，我對這樣的語境並不陌生。
當一個人技術越強、越習慣靠自己熟悉的能力解題時，就越容易把焦點放在「技術可不可以」，而不是「事情值不值得」上。
就像那句話說的：「手裡拿著槌子，看什麼都是釘子。」
MVP 的本意，是用最小的資源、最快的速度去「驗證使用者需求」，就像大陸微信的馬化騰提出騰訊的方法論「小步快跑、試錯迭代」概念一樣。
但當MVP變成只挑「技術能解」的來做，而不是優先解決「使用者真的需要」的問題，這樣的 MVP，充其量只是個技術可實現MVP，並不會對使用者產生價值。
別忘了最重要的，永遠是「為何」
我不否認，自動化是解決效率問題的重要工具。但使用者需求，才是所有產品與服務真正的起點。
技術只是手段，不是目的。
我試著跟他說明這點，但我不確定他最後能否理解。畢竟在大型組織中，類似的狀況非常普遍。
當上層層峰人士下達一個「明確」指令，在組織分工的傳統架構下，夥伴們常常會拿著聖旨開始拼命往下解題。解著解著，往往早已忘了自己是為了誰、為了什麼問題而努力。
久而久之，專案越規劃越深，卻越偏離真正該解的核心議題。
抬起頭，看見那個「為什麼」
我想透過這篇文章，提醒那些在大型組織中扮演專業角色的夥伴們：
無論你是PM、工程師、行銷廣告投手、法律專業人士、財務專家.....
別讓技術成為你屏蔽本質問題的藉口，否則技術將不再是祝福，且一步步淪為陷阱。
你可以很專業，但更需要不斷提醒自己：
「我現在做的這件事，真的解決了使用者的什麼問題？」
「如果它沒有被使用，再厲害的技術都是浪費。」
做任何事都必須要有次序觀：先確立實質需求，再思考技術手段。
當失去了「為什麼而戰」的起點，即便花再多時間、投入再多資源，最後也可能只是——看似努力，卻徒勞無功。
讓自己，不只是完成任務的人
我知道，大型組織待久了，常常會有一種無力感。
你可能會說：
「我也沒辦法，這是上層的指令。」
「我又不是決策者，我只能照做。」
「我也提過了，但最後還是要照原計畫走。」
這些話我都懂，但也想提醒你：
如果你願意深刻理解問題、提出洞察與驗證，你就慢慢跳脫「只能執行」的標籤定格。
進而成為願意看見問題、提出價值、改變流程的人。
這樣的你，才是團隊真正的資產。
也才會在未來的某一天，從被動接任務的人，成為那個主導改變的人。
如果你也曾經在專業角色與決策邏輯之間卡住過，歡迎留言跟我分享。
你現在在哪一個階段？你又是從哪一個問題開始重新思考？ 很期待聽見你的故事。
