NB的人才為什么做不出偉大的產品？信息部做出來的東西為什么往往遭遇一種困境，這不是別人要的，或是產品出來大家看看就好，就不買了吧？青云QingCloud CEO黃允松認為，這都是產品管理結構出了問題。傳統軟件工程管理體系對于差別的管理和產品的預設壓根兒都是錯誤的，所以黃允松做了一些研發管理上的改變。

黃允松的核心觀點包括：

所有要求增加人手的請求都應該被拒絕。人多會有分歧和討論，會浪費時間。研發過程需要快速出錯和快速校正，從而形成快速迭代。

不應該有團隊領導者，每個人都應該是管理者，管理是一種責任，而不是一種角色。

no schedule！產品研發不應該排出日程表，項目延遲交付也沒關系，出問題也沒關系，研發 管理要看全局，不要太關注細節。

勇敢的去嘗試不一樣的東西，總能做到最好。

以下為黃允松演講全文，經編輯：
如果各位有關注過云計算IaaS層或者PaaS偏技術領域的項目、技術、框架或者服務、公司的話，大家多多少少對青云有些印象，最大印象應該是產品做的如此之好，如此漂亮，或者性能怎么那么高。大家會對我們如何進行研發這個事情有些興趣，所以，才有了“高效研發管理”這么一個話題。我自己一直寫代碼，今天也跟大家分享一下寫代碼的感知。

1管理架構的意義幾乎為零
“管理”這個詞是為什么而生的？我們組建一個研發團隊，做一個管理機構到底是為什么？是為了出來更好的產品？還是真的想有一個管理架構？這個事情想明白的話，你會發現管理架構的意義幾乎為零。我在前東家供職的時候，我團隊跟其他所有團隊運行模式都不一樣。我原來所在的公司非常大，幾十萬人，一級部門可能高達幾千人，又有二級部門、三級部門，每個部門獨立運行。這些人都是聰明能干的人，受過良好教育，畢業于赫赫有名的頂尖的和研究機構，但為什么給客戶的東西表現卻一般般？我在前一家單位供職時間非常長，后來建設自己團隊時候就思考所謂的管理是怎樣的。

后來，我自己有一些機會可以跟市場上的客戶直接溝通，這種溝通并不是做銷售工作，更多的還是偏產品、偏技術層面的溝通，我得到一些很強的感受，就是我們辛辛苦苦做出來的東西并不是別人需要的。我非常努力，做出來一個東西，我還歡欣鼓舞，客戶最后卻不要，到底哪里出了問題？寫代碼的人出問題了嗎？肯定不是。是產品、管理、結構出了問題。

在我這個領域，我發現所謂差別的管理和產品的預先設計都是錯誤的，為什么會是錯誤的呢？因為一直是閉門造車，沒有人知道出來的東西到底是怎樣的形態。后來，我嘗試做一些改變，包括創建青云項目。

2研發團隊不應該有leader
我嘗試做的第一個改變是什么呢？首先，不允許人多，不管美國公司，還是中國公司，一般需要差不多50-100人的團隊設計和開發出一個獨立功能或產品的話，在我的團隊里，只允許1-2人做，青云線上看得見、摸得著的東西已經突破20個了，背后更多后端的功能尤其是看不見的功能，總數加起來肯定突破50，而且都是很大的單體功能，但整個研發團隊迄今為止不超過30人，所有人都是一樣的角色，只有一個角色。

我是怎么評判這件事情的？這么多重大功能要做，人數要控制到這么少，各位可能覺得有點不可思議。實際上，嘗試出錯，這是非常關鍵的。任何一個產品，如果帶一個龐大的團隊，那就需要設立一個很重要的角色，這時候把滿腔希望放誰身上？當他掛掉的時候，損失不是一個人，是一百人乘以一年，我們稱之為一百人/年，你們花了多少錢？你們失去了多少機會？在我看來，應該盡量選擇快速出錯，人數一定要少，人數多了之后就會形成討論，討論就沒完沒了，溝通成本會非常高。

舉個例子，比如做關系數據庫，在云端運行，實際上是非常接近于所謂的PaaS層的東西，在我看來不是PaaS，PaaS更多帶有行業屬性才對，依然是IaaS延伸，擴張的過程。我會讓一個人做，他來自于豆瓣，以前有很好的數據庫經驗，在整個過程中，我不能接受任何需要增加人手的請求，為什么呢？因為我要看到他出錯，一般說來，不會讓我失望，肯定會出錯，每個人都會有這個過程，我們可以迅速矯正我們方案，漂亮東西一定是快速迭代，快速迭代的法寶一定是速度一定要快，核心點是相信你的工程師，他就是最杰出的產品設計者。我認為“管理”這個詞在底層技術領域是很虛的，整個團隊是點對點的結構。

3一個團隊不應該超過4個人
第二個體會，當你初步得到驗證之后，你應該如何看待迅速的長大？剛才我也講到了，其實我要做的功能，每個功能復雜度非常高，我做純底層技術，我需要快速迭代，這是互聯網時代，不能等待。今天晚上想好要改，明天早上就應該上測試線。當我驗證一個概念的時候，比如稱之為α，這時候需要快速長大，這個團隊不能再是一個人，一般會變成兩個人或者三個人，但一般不允許超過四個人。因為到四個人的時候，討論變的無章法，你要走A路徑，我可以同意你，因為可以做的通，但是，如果我說不太同意你的看法，可以走B路徑，是不是可以呢？實際上也可以，問題不太大，如果這個時候有個人說想走C路徑，方程式永遠都有多個解法。

我們要的是快速的結果、可靠的結果，這個時候人數不能太多，但我從一個人增長到三個人的時候，團隊的增長是300%，還不夠猛嗎？但是，當你是100個人的時候，增長300%就是300人，對于公司來說是不可承擔的，到了第二個階段，我們團隊里每一項作品出來的時候我都會去看，如果滿足了我的期待，我認為這個東西是可以加大投資的，主要為了快速的出東西。

4研發不應該有日程表
第三個小體驗，歡迎大家參加我們這個月月底的用戶大會。我們的方案失敗了四次，做的過程中，我們發現有很多設計最初是想錯的，最早的計劃是花大約6個月時間做出第一個版本，然后發送給我們的用戶，第二個版本給受邀用戶，后來再推遲，我應該生氣？No，絕對不能生氣，我們在做底層技術創新，不要生氣，因為沒有人做過，因為我們走的那條路是別人沒有走過的。

我們一定不要認為任何事情都可以排出日程表，沒有日程表是不是意味著你的項目會出現重大的交付延時等問題呢？對，出現就出現，有一百個功能，一兩個出了問題，問題很大嗎？難道你自己做工程的時候從來不犯錯誤嗎？我們要看到的是全局，不要太關注細節，這個很關鍵，要看到整個團隊的收益是不是好的，不用太糾結一些東西的推遲。

很多人在網絡上非常關心青云環北京城400GB骨干網什么時候出來，8月份應該差不多，其實出點問題也沒啥，大不了用別的方案對付一下，只要不影響客戶的應用就好了，要看開一點。

5Try to different，嘗試做不一樣的東西
所謂的不一樣，不是為了不一樣而不一樣，不知道大家有沒有見過我們的Web操作控制臺，青云的東西非常易用，超級漂亮，平滑，不管是顏色、布局，還是操作的動作、手勢等等，非常符合你的想象。在青云操作平臺上，幾分鐘能夠學會并且搞定所有事情，如果懂技術，你會做的非常非常快。

我們最早為什么要嘗試一些不一樣的東西呢？如果大家了解過我的背景，應該知道做青云是我做云計算的第四個項目，原來做過很多，每次做的時候，除了后端東西，可能有前端東西，就是Web操作臺，每次都會請超級懂技術的前端工程師做前端，因為我做IaaS和PaaS的，如果找不懂前端的工程師做就很悲催，我找的人必須懂前端開發，最或懂一點設計，而且一定懂IT技術，以前做的時候每次都這么做，但是，非常抱歉，我做出來跟美國做出來的一個水平，為什么呢？看不到差異性，一點不友好，IT行業難道真的注定這么復雜、這么丑陋和這么的不方便嗎？于是，我就想不一樣，青云整個前端就是一位姑娘，不少人見過她，她懂技術嗎？不懂，我說的是底層技術，她懂藝術，有很好的設計感，基本是文科生，但是你要給她足夠強大的機會去嘗試。

我們原來四個人在很便宜的平房里做設計的時候，她做第一個版本的設計，做的過程中很有意思，基本會逐個問你覺得這樣好不好、覺得這樣可以嗎？說實在話，我真的不知道好不好，因為我不懂藝術，我是理科生，我就是條件反射覺得不太好，一般說來，有一半的時候我會講這個地方不太好，但會有一個“但是”，她會迅速的學習，我相信她離開辦公室之后也一定打開百度百科看CPU、交換機、路由器等等，她一定會搜索思科公司出的拓撲圖的小圖標，他嘗試理解IT民工常常掛嘴邊那些詞是什么意思。

總結一點，對于底層技術創新而言，沒有管理就是最好的管理，小規模作戰、快速試錯、迅速轉變方向、迭代周期一定要短。