## 對技術服務的提醒 ### 得到認可 剛才在膽量里沒說的一點。我們經常會看到，一項新技術在公司內久久難以推行，因為業務主管百般阻撓。即使排除利益糾葛，仍然會發現一種發自心底的不信任存在。而這種不信任，又往往來源于對同事工作的不認可。 這個問題原因很多，也許沒有通用的解決方案，但我說一個例子。 我們最近開始使用Codis，就是@goroutine 和幾個家伙之前搞過的玩意兒。雖然他們最近已經獨立開搞像Google Spanner但擁有更高級特性的TiDB（就是太牛了的意思）。由于我對他們比較熟悉和認可，所以在Codis嘗試方面也多出很多底氣。這種信任并非完全來自于出問題之后的直接電話支持，而是真心覺得活兒好。 反過來，這對很多服務也是一個提醒，特別是云服務。也許只要你得到合作伙伴的認可，或者至少讓他們覺得，自己動手不會比你做得更好，你基本也就成功了。 對于大多數理性創業公司來講，他們還是更愿意把精力放在自己的主要業務上，不會希望所有的服務都自己做，因為這個年代，唯快不破，創業等不起一輩子。 ### 產品意識 回到開始那句話，“在對它不了解的情況下，僅通過google就能解決問題，不正說明它不難掌握有大量資料可查嗎，實在不行還能翻代碼。” 這話有些道理，然而卻存在一個問題，這個問題就是： 作為一個使用者，是否有能力解決遇到的問題，與是否有意愿去遇到并解決問題，是兩回事。 你有本CPU設計手冊，你可以說處理器很簡單，但我只想看個電影啊？給你Linux內核的源碼，你可以說內核設計不難掌握，但我只想跑個游戲啊？何況他們是否因此就變得不難了，也是值得懷疑的。 這其實反映了技術人的產品意識。 很多技術人員喜歡玩酷的東西，他們愿意去探索新的領域，把不可能的變為可能。但是很多時候，他們做出來的東西卻很難使用。 有的庫可以增加很多參數，參數之間卻有耦合，導致你在采用的時候需要寫很多設置代碼，而有點庫卻只需要一行代碼；有的服務功能眾多，卻需要用戶學習繁雜的步驟，而有的服務卻可以開箱即用；有的服務功能可以實現，卻會有很多不穩定甚至崩潰的情況出現，等等。 對于實現的工程師來講，可能最大的區別在于，你是否考慮從用戶的角度審視過自己的東西。即使這個服務也許只是為其他技術人員使用的。  **技術人員可以，也應該，讓技術人員更幸福。**