我覺得這是一本寫給熱愛產品而非技術本位的工程師
工作了一段時間，歷經公司管理制度與文化的轉變，開始在思考怎麼樣的環境跟團隊才是適合自己，那完美的團隊又應該是怎樣的型態？
期間看過了 Netflix 體系的《給力》/《一千零一個點子之後》/《零規則》，強調人才密度 / 開放 / 下放權力等方式，但這些都比較是以人資 / 管理層角度出發
而《Clean Coder》是由專業工程師所撰寫，如何當一位堂堂正正的程式設計師，裡面糾正了自己很多壞習慣，但比較像教條/守則一般，少了點趣味與團隊的描述
而這本《創意競擇》，由曾經是 Apple 首席軟體工程師，參與過 Safari / iPhone 第一代鍵盤設計 / iPad 鍵盤設計，描述每一個專案經歷的過程與挫折，並收斂出作者認為為什麼 Apple 可以設計出頂尖產品的心法，並描繪出專業的產品團隊在決策/執行的過程，每一步的反思都發人深省，以下是整理過後的自我反思
演示(Demo) -> 蒐集反饋 -> 下一次演示
2005 年 Apple 啟動了 Purple 計畫，也就是 iPhone 的設計，在 2005 年 9月，整個工程團隊並召集要解決最棘手的問題 鍵盤，不同於黑莓機的實體鍵盤，iPhone 打算用多點觸控頻幕當做軟體鍵盤，但是因為第一代 iPhone 螢幕太小，所以鍵盤設計就至關重要，這是 iPhone 計畫遇到的一大難題
主管在測試第一代鍵盤時，發現連自己的姓名都打不出來，於是召集所有人，要大家停下手邊任務，全力攻克鍵盤問題，大家就各自發想，提出自己的解決方案
作者想到，如果把多個英文字母併入一個輸入格，透過字典自動校正猜出用戶要輸入的單字，就可以解決面積小 + 提升速度的問題，後來在展示過程中也成功擊敗其他提案，他也就成為 iPhone 主要負責鍵盤的程式設計師
但是這樣的鍵盤問題很多，例如只透過字典校正，那如果用戶輸入「Arrrr!」就打不出來了，所以就不斷的調整 -> 演示 -> 回饋，每個成員手上都帶著原型機，形影不離不斷的測試並給予反饋
這聽起來是 common sense，但是演示的細節才是關鍵
給予直接的回饋
演示的時候是不是能抓到重點，把力氣花在正確的位置上，更重要的是「有沒有人可以給出果斷的反饋」
作者提到賈伯斯可以的話會盡可能參與演示，並給予非常直接的回饋，例如說第一代 iPad 鍵盤其實有兩個鍵盤模式可以切換，但賈伯斯玩一玩就問作者「你覺得是不是只要一個就好？你喜歡哪一個？」
之後就拍板決定，只留一個簡化模式的鍵盤
工作久了覺得有一個果斷的決策至關重要，很多時候大家在會議上都不敢給予直接的反饋或決定，可以聽出大家對於背負責任的恐懼與排斥，或是猜不透掌權者的心思，這來回之間留下很多朦朧的空間，十分的可惜
演示很重要
另一點是工程師對於演示的心態與技巧，年前剛好與 CEO One on One，他提及工程師普遍不重視演示，不懂得如何用正確的方式讓大家 (包含 CEO 本人)了解技術的重要性，例如敝司有持續在研究低光源錄影的優化演算法，但是 Demo 時選擇在明亮的會議室，CEO 表示他很納悶為什麼不找一個合適的場景更凸顯技術上的突破呢？
站在科技與人文的交界點
在書中有提及品味，例如鍵盤就應該要讓用戶順暢的打出他所想要的字，所以作者不斷的優化自動校正功能，同時保留用戶輸入冷僻字的可能
品味聽起來虛無縹緲，作者的定義是
培養靈巧的判斷力，找到令人愉悅又完善的平衡點
這仰賴團隊中設計師與工程師不斷的溝通，以及管理者很明確的表達目標，例如開發 Safari 的時空背景是要取代原本 Mac OS 內建的 IE，那時候賈伯斯給予非常明確的指示「速度」，要用戶放棄 IE 跳槽到 Safari 速度就是最重要的用戶體驗指標
另外作者對於 A/B Test 提出質疑，最有名的就是 Google 測試 41 種藍色，從用戶給予的數據回饋作為依硅是「最顧客導向的做法」，但是作者表示這不會是 Apple 做事的態度，或許他們會採用數技分析，但他們有專業的設計師在為所有的設計把關，包含像設計師提出觸控螢幕應該要有長按拖動的設計，就像是在手按著紙在桌面拖動的感覺，這樣才有更沈浸的體驗；
滑動捲軸時持續滑動會加速，觸底會有小小的反彈回饋，都是 Apple 設計師所設計的
敝司近年也在導入數據驅動設計，但自己也在反思需求設計是不是真的完美？從用戶的數據不斷去打磨就能得到最棒的產品？
或許還是要回歸需求設計的本身，這樣的提案是不是有「品味」，才有後續的 AB Test 的價值
看到這一段也頗有感觸，在鍵盤專案中有專職的設計師，而作者身為軟體工程師卻不單單把自己擺在實作者的角色，而是把自己當作用戶不斷去優化鍵盤設計，在書中描述了五六代鍵盤的優化過程，像是從原本的多字一鍵改成一字一鍵，然後再改成 QWERTY 鍵盤，自動校正也從單純的字典比對變成輸入的位移向量差，可以看出作者想要把最棒的用戶體驗帶給所有的人，包含他自己
最困難的問題
因為 Safari 專案的成功，作者的主管希望作者把瀏覽器包成套件 Webkit 嵌入 Email 當中做文字編輯器，作者花了很多時間在解決滑鼠游標位置的問題，因為這涉及到文字排版 / 換行跳字等邏輯，遠比想像中複雜得多
作者在書中有描述他遇到的難題，以及他曾經嘗試過的解法，花了好幾週的時間都無法突破，最後向主管尋求幫助，從其他部門找來有經驗的工程師，最後就一起解決了問題
作者統整了幾個點
- 問問題之前必須自己先努力過
- 身為程式設計師必須拋開自己的尊嚴，有問題就要有誠意地去尋求協助
聽起來很一般，但仔細回想工作的經歷，可謂文人相輕，很多時候其實同事之間很少有切磋，也不知道是大家在藏招還是害羞，覺得實在很可惜，尤其是事後回想彼此都踩過一樣的坑，如果早點分享或是互相請教，就能避免這無謂的浪費
結語
自己在職涯發展的過程，也不斷思索自己的定位，一方面希望自己有足夠的技術實力，能夠挑公司而不是讓公司挑我；另一方面也希望自己能夠找到熱愛的產品，把自己的技術能力變成影響力
以前會覺得兩者有點衝突，畢竟產品開發有時候需要的不見得是技術能力，而是反覆的溝通以及更深入的理解用戶需求，投入產品越多會不會讓技術發展上的時間縮短 ?!
羅胖說過要做到 U盤化生存「自带信息，不装系统，随时插拔，自由协作。」
但慢慢地開始體會到，兩者有時候是相輔相成的，熱情這種東西是無形且容易被忽視的價值，如果上班對於產品有熱情，這可以延燒到對於技術專精的執著，讓解決問題可以從更根本的角度而不是嫌麻煩的負面心態去面對
講得有點籠統，自己可能也還沒想得很清楚，但是從這本書中看到另一條我覺得值得效法的職涯