Yi-ning

從開始撰寫部落格文章到現在也有兩年時間，顯然自己的發文速度從一週一篇降低至已經長達一年，沒、有、認、真寫文章了，原因是，從行銷企劃轉到品牌美術設計的這段路實在是忙到焦頭爛額，有一陣子甚至中斷自己每天讀書的習慣。

睽違一年半，友人介紹我閱讀產品專案管理全書，作者為Marty Cagan畢業於加州大學聖克魯斯分校，擁有電腦科學和應用經濟學雙學士學位及史丹佛大學企經學院碩士學位。創辦矽谷產品團隊公司SVPG，為當前科技類專案管理方面公認的意見領袖。

我非常推薦和我同齡（大概出社會五、六年的青壯年一起閱讀本書，雖然目前筆者就任的職位是品牌美術設計，但從這本書從失敗到轉型成功的案例中，可以認識到很多職場環境、文化，優秀的產品團隊如何共同建立出全新的工作流程，並過關斬將解決問題的方法，相信日後在任何一間公司和上司、同事討論的時候，都更能快速、精準、深入的傾聽與解決所有消費者的問題。

備註：以下讀書心得為筆者的讀後心得紀錄與感受，以下將摘錄筆者在品牌美術設計這個職位上，體悟到最深的五大點與本書給我有所啟發並嘗試開始解決的內容作分享。

一、執行完的案子，大部份時候只有雷聲大、雨點小

在台灣傳產的品牌，幸運的話發展順利，隨便開發一個線上landingpage就有好幾百個人參加，不幸運的話頂多就是跟某個案子合作以後草草結束。

第六章節所探討的產品失敗的根本原因，正好給我有了很大的反思：作者在本章節中提到一個在職場上最常見的情況：產品開發最後才找設計師，完全不懂用戶體驗感受，最後才塗抹表面掩飾亂象。

其實我也有發現，每次專案deadline快到的時候，身上背負過多設計稿件的設計師才開始認真地詢問，所以這張圖、這個專案，是這樣？那樣嗎？

然而，在一開始合作的時候，多數行銷負責人會告訴你：嗯，我還在規劃中，等我想好了再跟你說。

在本書第七章節精實與敏捷之外的方法 中產品是大家合作定義及設計出來的，不是按照順序開發的，相信市面上有關產品經理的相關書籍或是雜刊裡面都有提到近年來很有名的《敏捷式開發法》，是的，傳統的瀑布式工作法，會讓我們趕不上產品上市的時間（這個我將在第二及第三點的讀後心得與大家分享。），我想一開始就讓所有團隊相關的人一同參與會議，深入了解整個專案過程，才可以在一開始就先處理風險，而不是留到最後才處理，其中包含：

*價值風險:顧客會不會買

*易用性風險: 用戶能不能搞懂怎麼使用

*實行性風險: 工程師能不能運用我們僅有的時間、技能、技術，來打造我們需要的東西

*商業可行性: 這個方案對事業的諸多面向：業務、行銷、財務、法務等等是否可行

*在易用性風險中，專業的產品設計師可以先評估並回饋產品經理可想的專案有沒有辦法很流暢的交給使用者；而在實用性風險中，產品設計師及產品經理可以從工程師一開始就評估的風險中掌握整個專案可呈現的方式，才不會常常出現以下情況：

1.設計師做完了才發現這在公司目前的程式端技術根本寫不出來。

2.設計師做到一半才發現這個產品專案原本規劃的使用者體驗有問題。

3.設計師已經做完了，產品經理在切版的前一刻又發現整個內容是有問題的。

書中提到的一大項重點：產品是大家合作定義及設計出來的，不是按照順序開發的，優秀的團隊應該要找到共識，互相讓步妥協，得出顧客喜愛及適合公司推出的方案！

當然，要找到共同的解決案也要知道錨點在哪，因此共同評估出所謂的商業績效business results（重點是解決問題，而不是實現功能）是很重要的。

一開始沒搞懂整個案型，也就完全不懂用戶體驗感受，最後才塗抹表面掩飾亂象，表面掩飾的亂象，將會帶給消費者很糟糕的體驗感受，以致於往往很多案子只是做了，而沒有帶來效益。

二、稿件來回改好幾次，難道只是這個案子本身就很急促？

在所有的合作關係裡，每次的溝通失誤，都應該是雙方要共同承擔的。本書是以產品經理的角度去寫的，而身為設計師的我在本書中對於作者提到優秀的團隊需要的是傳教士，而不是僱傭兵這點特別有感覺。

產品團隊是把一群專業技能和職責不同的人匯集在一起，讓他們真實擁有產品主導權(ownership)，或至少可以主導產品的大部分。所謂的傳教士團隊即是「願景」的信徒，致力為顧客解決問題，在本書裡面有詳細講解「產品願景」對於一個專案的團隊來說到底有多重要，而我也以此深信：設計師絕不可能只是草率地把產品經理提供的wireframe填空題塞滿品牌的圖、文字就結束的。

在這本書裡面的許多工作方法與建議，我認為皆可以學以致用，增加高效率且有質量的會議：

1.「兩個披薩原則 two-pizza rule」：小團隊 比大團隊更有效率，所以開會人數不超過2份披薩為原則。

2. 團隊協作：產品設計及工程人才聯合提出解決方案

3. 團隊範疇：驅動技術堆疊technology stack，不同類型的工程專業。

4. 團隊自主性：團隊要有被授權的感覺，不代表它們可以做任何事，但確實可以用自己最合適的方式，去解決公司指派的任務。

雖然團隊的劃分沒有完美的方法，但是了解產品願景、運用好的工作方式，都可以改善後續很多不必要的麻煩，畢竟很多時機錯過了沒有把握就要用更多的時間去彌補，有時候甚至連彌補的機會都沒有。

三、高誠信原則 high-intergrity commitment

在前面一、二點中已經說明了凡設計師都很緊張沒有在答應的交付時間內完成，是件很焦慮頭痛的事情。

優秀的團隊不是產出，而是需要交付商業結果。產品組織中多數的浪費及開發失敗都是典型的產品路徑圖導致的。有在讀工作相關工具書的我，在讀了這本書才恍然大悟，很有可能團隊自以為走在高端的敏捷式開發法上，但其實透過這本書會讓你知道：你並沒有完全掌握方法，所以每次案件來的時候都做不到「高誠信原則」，我特別喜歡高誠信原則的定義，因為他說到了不只是職場上的現象，所有在人際關係裡的相處也是如此，「讓主管知道你不輕易承諾，但你承諾了就一定做得到。」

四、勇敢面對他人的挑戰與質疑

站在創新面前，我們往往會害怕別人的挑戰與質疑而畏縮，日復一日的告訴自己：「反正這樣過也可以，為什麼要改變？」

我很喜歡第四篇裡第31章的章節裡面提到的內容，如果你和我是技術職，光是提及想要新增一些過去可能沒使用過的新技術也需要通盤考量到「是否全部的同仁都可以順利學會這項技能」「日後是否真的能為公司帶來創新」等等問題，但是本書有很多方式可以帶你離開這些恐懼，突破這些問題，先檢視一下自己的表達方式，例如：別擔心顛覆自我，因為你不下手，別人也會下手。

其中，我覺得透過作者的視角，也可以幫助大家在這條路上不斷修正方向：如何堅守願景，但靈活看待細節：

願景轉型：轉型的時候，可能只是遇到問題，就提早放棄產品願景 vision pivot

但是話說回來，看待細節卻也要靈活運用，所以作者也反面提出探索轉型：需要調整方向才能抵達目的地 discovery pivot。

五、認識自己，認清什麼是強大的產品文化

知己知彼，百戰不殆。成功的團隊在於它們可以因應這些真相方式不同。

強大的產品團隊了解上述的麻煩真相，並積極面對真相，而不是否認真相。他們很擅長迅速處理風險，無論那個創意概念來自哪裡，也能夠迅速反覆開發出有效的解決方案。

本書第五篇主題為適合的文化，我們很容易糾結在如何迅速提出值得打造及交付給顧客的產品所使用的技術等等，但真正重要的事，為成功營造合適的產品文化。

第五篇的每一章節會讓人更清晰地判別現在努力熬過的每一天，這條路是否值得，試著將未來每一個工作天的開始讓自己反覆思索書籍裡提到的要點，當你面臨到工作的挑戰時，我不敢保證你會完全沒有質疑（恩，以創新來說，有點質疑是正確的），但我保證：你將不會輕易退卻。

擔任品牌美術設計的我這一年半以來也很明白：即便你會隨著年歲的流逝，工作的累積，通透第了解現在公司的文化都將越來越飽和越來越擴大，但是所有的穩定背後潛藏著危機，如何和優秀的團隊夥伴們使用正確的方式繼續迎向全新的奮戰，找出創新的方式，在這個章節裡將能讓你重新審視。

六、領悟，改變力

來到了結論，如果你和我一樣是設計師，我非常推薦那個正在職場上迷路的你，或是已經走到路上卻還卡關的你。書裡面有一個章節提到與產品經理合作的產品設計師是這樣說明的：在如今的強大團隊中，設計對功能的影響至少跟功能對設計的影響一樣大，這是很重要的概念。

需要讓設計師成為產品團隊中的關鍵成員。

雖然全書主要講述的角度主要以產品經理切入去看每一個合作的角色，諸如產品工程師、產品設計師等等，透過這個視角，將會讓你更深切明白與你合作的產品經理遇到什麼樣的風險，面臨了多少多重的挑戰，這時候，從旁協力與他討論出共同的解決方案，技術人員扮演了很重要的角色。

當然：即便是同一本書，會因為不同的個體而帶給你的啟發與領悟不盡相同，於我而言：勇敢地與產品經理提出疑慮也是我會害怕的地方，因為提出疑慮就必須承擔責任。出社會久了以後，大家往往都很怕改變舊有的工作模式，進而失去了創新的機會，其實這些都有方法克服的，透過書中分享的技術，我也更明白：承擔責任最好的辦法就是去通透了解在職場環境中的所有利害關係和改變、創新的這條路上會遇到什麼風險，在這本書裡面作者也會提到為什麼無法說服你的團隊一起去改變的這個盲點，有時候並不是妳的點子特別不好，而是我們往往沒有說到點上。

本篇網誌獻給那些和我ㄧ樣正在技術職涯裡迷茫的你我，

如果你和我一樣是團隊中的技術人員，從本書中你可以了解到自己為何為誰而戰。

其他參考書籍：

Jeff Patton, 楊仁和 , 使用者故事對照 (User Story Mapping: Discover the Whole Story, Build the Right Product), 2016 。