唱吧技術總監黃全能在由51CTO高招主辦的“CTO訓練營第五課管理的藝術”做了主題為“產品與技術的協奏曲”的分享。其內容主要介紹產品與技術之間的關系，以及如何解決二者之間的對立問題。

講師簡介

黃全能，唱吧技術總監，2005年從清華大學畢業后加入愛立信，五年后加入一個美國硅谷云計算公司擔任商業智能組負責人，2012年加入唱吧服務至今，現在是唱吧線上研發部門的技術負責人。再唱吧技術團隊從0到1的過程中，他以小而精的團隊管理理念，運用精英化、非預期性獎金的管理方法，是技術團隊以強大的內聚力而著稱。

 技術與產品之間是合作的關系。產品作為設計，技術去構建。但是產品和技術，一個是消費者，一個生產者，二者本身就是一個對立的關系。所以當生產出來了東西，消費跟不上，產品會覺得技術能力不夠大；當技術做出來東西，不好賣，不好用，技術會覺得產品設計的不好。這種對立現象經常會出現，產品設計的一些方案，技術上不好實現，產品會覺得技術能力太差，而技術說設計得本來就不合理。兩者中間有時候在需求上會取一個平衡。但是當遇到運營、市場活動的時候，產品和技術是互幫互助的關系。

黃全能認為產品與技術之間實現共同協助，有以下幾點：

技術需要理解產品方向

有些公司的產品，真的把技術當成一個外包團隊，類似施工團隊，產品指哪里，技術就要做哪里，但其實產品方向對員工的士氣才是重要。產品與技術之間不做任何溝通，不告訴技術方向的時候，技術根本看不出來產品的意義在哪兒。

其次，代碼的架構上。產品的方向是什么，可能其自身也沒有想好，在這個茫然的階段，技術根本就不知道下面的數據庫、接口、架構怎么去搭比較好。

***是技術儲備。很多時候產品不敢匆忙上線，是因為知道技術可能現在這個階段還未完成，技術儲備還沒做好。但是技術如果不理解產品方向的話，也會說產品還沒提需求，可以去做點兒小優化，而不是投入到更多前面的發展當中去。

技術很大的一部分職責是和產品溝通方向，給自己的技術規劃路線。技術的學習需要方向，所以了解產品方向非常重要。

技術應該理解產品細節

除了要理解方向，還應有一個文檔把產品與技術間的交互完整的記錄下來，也叫產品細節。作為技術，在一些小的細節上真的需要很好的把控，原因其實就在以下三點。

***個是架構的選擇。因為方向定下來了，雖然細節對架構面的影響會小一點，但是實際上也有可能會影響一些動畫的處理，包括一些圖層的展示。如果不關注細節，就不會猜到產品會往哪個方向改。包括API接口其實也一樣的，有些API，細節其實會影響到跟服務器的交互，服務器又會影響到怎么存儲，緩存之類的東西，都可能能處理掉。

第二個是產品的質量。IOS、安卓很多地方要交互，有時候遇到不一致，包括測試也是安卓的測安卓，IOS測IOS，如果沒有做加大測試的話，有的就會出現不一致。產品經理可能從大的功能去著手，可能在一些小的交互上或者體系上并沒有看到問題，這樣就會出現一些產品質量的小問題。技術如果不能理解細節的話，就沒有辦法幫產品打掩護，很有可能就蹦出一些小的、沒有處理過的問題，比如該彈出的錯誤提示就沒有彈出來，等等。

第三個是產品的bug。如果一開始不去理解產品細節的話，這個問題會經常出現，產品本身做得很復雜，產品經理對整個產品全局不是很熟悉的情況下，基本上會出現三種情況。***就是功能丟失，下個版本把上一個版本換了種做法，但是丟了一小塊兒功能，沒做全，要么就是頁面不一致，改了樣式去展現。還有一些邏輯矛盾的地方，比如封號后用戶還可以從別的地方把評論發出來，像這種產品的bug需要有人去維護。

技術應該理解產品困難

技術一定要去關注產品，要知道產品怎么想的，當技術覺得跟產品想法不一致或者產品對技術會造成困難，甚至對非技術的業務造成困難的時候，要及時地指出這些東西。唱吧的技術會直接挑戰產品的一些思路、設計，需求，包括為什么要這么做。雖然此時特別容易劍拔弩張，如何避免交火，其實是相互要做一些理解。其中一部分的理解就是技術要理解產品的一些困難。

產品和技術最不一樣的地方在于產品有很大的主觀性。不是所有產品都可以數字化驅動的；有些產品的判斷無法進行AB測試。所以意識上要理解產品的某些猜測，并減少無根據的挑釁。除了主觀性之外，另外就是一個試錯性，產品有時候自己也不知道主觀想象的東西到底好不好，應該允許產品的某種試錯性，并給出試錯周期。技術上給予配合，盡可能提供靈活的方案；一些想法可能早期有意義，但會迅速過時。

技術應該鞭策產品進步

在有些公司，產品是產品經理內部團隊之間去進行一種交流成果。技術要認識到產品哪些方面是可以去進行挑戰的。主觀性產品容易加入太多；產品會不斷地加這種試錯，浪費試錯成本；粗糙的設計會影響產品質量。試錯的成本其實試很大的，一個是用戶成本，如果方案不好，導致用戶流失，還有一個是機會成本，迭代時做別的事情，該涌進來的用戶沒有涌進來，該挽留的用戶也沒挽留住。然后是研發成本，大量的開發成本、維護成本都是很重要的，不能***地主觀，不能***地試錯。至于粗糙的設計會影響產品質量，這點一定要跟產品經理講清楚。很多產品覺得產品稍微粗糙一點沒有太多用戶在意，但其實產品設計的粗糙不禁影響架構，各種奇怪的狀態、各種hack展示、各種不必要的服務器壓力，而且會影響代碼風格。

技術應該監控產品問題

產品經理往往是孤獨的，這時候同一模塊的技術開發和測試，才是產品經理的同盟軍。

技術應該主動收集數據、添加統計、預埋日志。

建立技術與產品之間的信任

給雙方以機會，建立適合自己公司團隊實力的權力平衡?？梢杂羞@樣的兩個體系：產品經理的威信評價體系和技術伙伴的能力評價體系，分別針對產品與技術之間的情況進行打分。其實產品經理很難做KPI，因為產品經理的綜合評價很難量化的那么清晰，更多是看產品的迭代之后會是一個什么樣的情況.

打造具有產品觀的技術團隊

如果想建立有產品觀的技術的話，技術至少必須滿足三點。大局觀，為產品未來的可能做好準備；邏輯性，發現產品的bug，敢于質疑產品的方向；主動性，主動預留的一些功能，為產品填坑。還有一個加分項，美感，好的技術對美感有天然的評價和認識。好的技術追求代碼架構的干凈、完整以及擴展，同樣在產品上有自己的觀點。

建立健康的工作流程

 給產品以足夠的空間，建立合適的防火墻，但必須讓產品傳達其意圖，為技術解惑。

建立技術與產品的反饋機制

【編輯推薦】

1. CTO訓練營第5課：創業型公司技術團隊管理藝術
2. 軟件定義技術使SAN存儲性能擴展成為可能
3. WOT2016企業安全技術峰會即將開幕 大咖云集盡展***絕技
4. 阿里云云盾吳翰清：云上安全到底有何不同？- 網絡·安全技術周刊第250期
5. CTO訓練營左文建：創業公司如何建立技術團隊