作者 | 鄒欣 責編 | 夢依丹

出品 | CSDN（ID：CSDNnews）

問題

CSDN 這個 “軟件” （網(wǎng)站，app，開發(fā)云、猿如意、插件、公眾號等）在過去的很多年中，有很多用戶使用，也有不少用戶喜歡，還有更少的用戶為之付錢。我們在商言商，怎么能讓更多的人付錢使用我們的產品呢？用戶的決定是怎么做的呢，我們有什么辦法來影響用戶的決定呢？搞軟件看似高大上，其實還是有很多規(guī)律的。我們知道：

• 程序 = 算法 數(shù)據(jù)結構

• 軟件 = 程序 軟件工程

• 軟件企業(yè) = 軟件 商業(yè)模式

在充分競爭的環(huán)境中，一個軟件企業(yè)要生存發(fā)展，和美食一條街的一個小飯館要生存發(fā)展類似，街上人流熙熙攘攘，他們對于一個小飯館的態(tài)度不外乎是下面這個區(qū)間之內：

給我錢我也不去吃 … 如果免費，可以嘗嘗 … 看價格和就餐環(huán)境 … 很信任的品牌，有需要就吃 … 即使排隊、漲價也要去吃

有人說 CSDN 比小飯館高大上多了，它是一個有無限可能的平臺！好，我們不妨用 “綜合商城” 來比喻，如何？

給我錢我也不去，那里壞人多 … 那里沒啥有意思的 … 免費逛逛，期待不要太高 … 有幾個有意思的店但是環(huán)境太差 … 以前去過，后來有其他更好的商城就不去了 … 交錢辦了會員，經常去那里的廣場跳舞，吃飯看電影，很多優(yōu)惠

大家在做這些決定的時候，是理性還是感性的呢？最近有一個做教育的團隊不得不改行網(wǎng)上賣貨了，結果買的人特別多，這些購買者，是做了理性還是感性的決定呢？

我的理解

在我的職業(yè)生涯中，我作為一個程序員，研發(fā)經理，到現(xiàn)在的 CSDN 職位，我越來越多的關注焦點，從具體的 “我的代碼能編譯”， “快速解決 bug”， 到 “軟件能按時上線”， 到 “用戶場景能滿足需求”， 到 “研發(fā)團隊的效率和成本“，到 “大量用戶愿意成為長期付費用戶”， 這些過程中，我和我的小伙伴們不斷地做各種決定，開發(fā)出產品和服務，然后希望用戶也做決定，成為我們的高興的用戶，能留存的用戶，直至長期付費用戶 … 每一步都有很多決定要做， 在這么多決定中，哪些是感性在主導，哪些是理性在主導呢？這篇博客，就談這個問題。講講我自己的經歷，和看過的別人的經歷 – 這篇博客應該是感性的。

這個問題并不是只有在軟件行業(yè)才存在， 經濟學中的 “行為經濟學” 也研究人在經濟活動中的決定是怎么做的。我最近聽了幾個 Podcast （FreakOnomics），談行為經濟學，剛好把我以前讀過的書和一些經歷串聯(lián)起來了，有些洞察和感想。這些感想我以前也有過，但是沒有寫下來，就淡忘了，后來又犯了同樣的錯誤。我覺得應該寫下文字，而且是公開的文字，讓自己加深印象。大家工作都很忙，哪有時間?。康?，我覺得，強迫自己 “閑下來寫筆記”，還是有更好的長期回報的。我的前一篇博客也提到了 “思考，快與慢”，下面再來一句雞湯：

閑是靈感的源泉，忙是思維的墳墓。

歡迎大家在評論區(qū)閑聊交流一下。

理性和感性

我們做軟件開發(fā)，軟件方面的創(chuàng)新，也有理性和感性的部分存在， 很多人以為，IT 界的創(chuàng)新和采用，大概率是理性的決定吧，其實也未必。

（一）美國硅谷有一個非常有名的研究院， Xerox Parc，1970-1980 年代，它一度孵化了很多顛覆性的 IT 技術，把這些技術集成起來，就是一個現(xiàn)代化的辦公自動化系統(tǒng) – PC，圖形界面，所見即所得的編輯器，局域網(wǎng)。但是，它向各大公司推廣這一套創(chuàng)新的時候，這些潛在的顧客并不買賬。雖然有很多數(shù)據(jù)顯示這一套系統(tǒng)能大大節(jié)約成本，顧客中做決定的人（公司里的大老板，負責 IT 采購的人，那時候還沒有流行 CIO 這個頭銜）事實上在做一個感性的決定：如果我冒險用了這個系統(tǒng)，而不是 IBM 系統(tǒng)，我會失去什么？結果，是這個感性的決定，讓這個先行者失去了很多顧客。事實上，XeroxParc 的母公司在東海岸的老板，也是用感性驅動做了決定（“這些西海岸的研究員在胡鬧什么？我不懂也不想讓他們再胡搞了”）。直到 IBM 推出了 IBM PC，PC 的浪潮才真正掀起。

（二）我在微軟公司的時候，曾經花了兩年的時間來推動一件事情 – 在最新的 Windows 系統(tǒng)中推出某個重要改進。這對于簡體中文版的 Windows 在用戶中的價值是很重要的。當然，在微軟這樣偉大的公司，要說服決策者做這樣的決定，還是需要很多工作，其中就有各種數(shù)據(jù)的支持。我們做了很多輪的實驗的設計和數(shù)據(jù)收集工作，總部還有另外的團隊獨立來中國收集數(shù)據(jù)。我們也做了很多代碼的改進，測試，等等。經過很多次小的討論，我們終于和決策者開會了！在會上我展示了很多數(shù)據(jù)，從各個角度展現(xiàn)，這個改動是有很好的短期和長期的收益的。

但是在我展示這些數(shù)據(jù)和理性推導的時候，總部的一個決策者提出：

哎，你這個方面的數(shù)據(jù)說有 20% 的提高，但是我認為你們做調查的方式不科學吧，數(shù)據(jù)可信么？

哦，這個方面的數(shù)據(jù)，說有總共 12% 的提高，那說明這個項目的收益并不高啊，我們一定要繼續(xù)推動么？

我正在想如何反駁 – 因為整個中國市場，12% 的提高也是很巨大的啊，怎么就是不高呢？難道Windows 在過去幾年中曾有達到 12% 提高的改進么？這時候，一個來自第三方團隊的資深的經理說話了：

當這個數(shù)據(jù)顯示改進很大的時候，你說數(shù)據(jù)不可信，當這個數(shù)據(jù)顯示改進并不是很大的時候，你就認為這個數(shù)據(jù)是可信的。你不就是鐵了心不想要通過這個項目么？

這兩位當時臉都漲紅了，會議也陷入了沉默。他的話，像皇帝的新裝里面的小男孩那樣，童言無忌，指出了決策者并沒有什么“理性決策”，而是一個感性的 “老子就是不愿讓這個項目落地！”

（三）在大廠的環(huán)境中工作，很多情況下，是要說服別人同意你去做某事，一次我們要說服某 VP 同意某個提案，在和總監(jiān)級別的大佬溝通的時候，他說， 你們的 PPT，擺事實，講道理，列數(shù)據(jù)，很干巴巴的，這樣的提案 VP 每天要讀好幾個，你們要把這個利害關系轉化為這個 VP 有 visceral 感受的點！

??？啥是 visceral？哦，原來他借用了 Don Norman 的設計的三個層次的術語。

就是要讓被別人感到一種 本能/visceral 的反應 – 我的內心直覺就需要這個，我也說不清！

類似的描述還有：眼前一亮，內心柔軟的部分被觸動了，等等…

（四）用數(shù)據(jù)驅動的方式來分析問題，提出假設，再快速驗證，這是很多人推崇的方法，特別是 Money Ball 這本書暢銷之后。我也接受過這樣的培訓，還帶隊參加了更多的培訓。我認為總的來看，這是有好處的，但是在具體的情況下，未必。

我們的一次實戰(zhàn)產品設計中，產品經理想出了一個自認為好的點子，做了很多準備，然后我們請了一批符合條件的目標用戶來接受訪談，幾個人在采訪室和用戶聊，幾個人通過閉路電視觀察。其中的一次采訪， 產品經理充滿激情地向受訪者描述了使用場景，最后問：你愿意用這個功能么？兩個受訪者都頻頻點頭。產品經理就筆記本上數(shù)據(jù)的那個格子中打了?，高興地離開了采訪室。我們幾個在閉路電視中看到，產品經理離開后，兩位用戶互相望了一眼，都搖了搖頭笑笑，也很快收拾東西離開了。

那么這個產品的點子，從理性的角度，得到了用戶明確的首肯，但是從用戶的肢體語言來看，用戶根本就不理解，在產品經理熱情的宣講下，出于禮貌，回應了感性的點頭，可能心想 – 快讓老子回家吧。我們仔細分析那個產品經理的提案，充滿了內部的術語，用戶很難理解他在說什么。

在上面的幾個例子中，理性地說服對方同意你的銷售（產品/提案），都不太成功，為什么呢？因為每個人在面對一個產品/提案的時候，他內心的核心問題是 — 我能從中得到什么？我會失去什么？

（一）在很長的時間里，美國的 IT 部門，購買 IBM 等少數(shù)幾個大廠的服務，才是安全的，我為何要冒險去支持一個第一代的顛覆式產品？

（二）這位決策者，在一年多前在日本推出了一個類似的改進，被當?shù)氐挠脩艉莺萃虏?，作為不懂日文，也不懂中文的決策者，他心里想什么？

（三）這位 VP 心里扛的是巨大的成本和收益的 KPI，我們的提案，講了很多技術方面的數(shù)據(jù)，微軟的產品缺技術么？他心里 visceral 層次上，什么能打動他？我們能直接表達出這個意思么？

（四）一個產品提案，在數(shù)據(jù)上獲得了 100% 用戶的同意，但是用戶是真的被說服了，還是出于感性的角度點了點頭？產品經理有工資，只要做了提案，不管最后如何，做了就好。被采訪的用戶，公司會給他們幾百塊錢的禮物前來接受采訪，只要點點頭，搖搖頭，就可以兌現(xiàn)禮物回家了。這個產品經理后來也把這個提案扔下不管了，那么，他和被采訪的目標用戶，誰是真的在乎這個使用場景么？

我參與了很多類似的產品提案討論會，有一次在一個類似的會議上，一位大佬問一個熱情播放PPT 的研究員：你真的相信你描述的這個未來么？如果你真的相信，你就去馬上去做，不必列很多理由的！

從感性的角度，我們可以把一個團隊的成員比作 “豬、雞、鸚鵡”，他們合作開早餐店，他們都有想把產品做好的感性愿望，但是每個人的具體投入是不一樣的：

豬：割自己身上的肉來做培根

雞：每天貢獻一個雞蛋

鸚鵡：把別處聽來的消息給團隊轉發(fā)一遍

你是一個決策者，你更重視誰的提案呢？

一個功能的成本

每一個功能，都是有成本的：

• 設計、實現(xiàn)成本

• 用戶教育、習慣培養(yǎng)成本、打擾用戶的成本

• 維護成本

• 以后要下線這個功能，還有很多其他成本

我以前在某研究院工作，和研究員一起做了一些創(chuàng)新性的圖像特征提取的嘗試，發(fā)現(xiàn)我們的提取的特征可以大大提高某種類型圖像搜索的準確性。于是我們和搜索引擎團隊聯(lián)系，看看怎么把這個激動人心的特征放在搜索引擎上。對方的工程告訴我們，這個特定領域的圖像搜索，雖然不是少數(shù)（不妨想象為搜索 “狗的類型”），但是和搜索引擎的主要圖像搜索類型相比，就小兩個數(shù)量級，和文字搜索相比，又小了一個數(shù)量級，因此，這個研究突破雖然很 excited，但是要放到產品上，“維護成本” 非常高。因為：

每天有海量的圖片 視頻進入搜索引擎，我們的工作流程是：

1. 我們的算法要快速處理這些圖片 視頻，抽取特征 （CPU intensive） –

2. 要把抽取出來的特征（一個向量，或者就是一些 100101010101011）放到內存中（memeoy intensive）-

3. 要保證搜索的檢索速度不會變慢（因為99% 的搜索和 “小狗類型” 無關）

4. 這樣，那些為數(shù)不少，但是占總量 （1%）的對“小狗類型” 感興趣對用戶會發(fā)現(xiàn)，這個搜索引擎太厲害了，太方便了，我要用它做默認的搜索工具！

在這個架構下，每天，公司在全球的機房中的一些CPU，內存就會分配來做上面的這些事情。后來我們的工程師花了大量的時間來改進抽取特征的速度，用更少的字節(jié)來表示抽取特征，直到我換到別的團隊，他們都還沒有能達到產品組的要求，后來似乎不了了之了。

這在大數(shù)據(jù)服務中，是比較常見的現(xiàn)象，我們當然要為高頻的服務優(yōu)化，谷歌也有 “牙刷（每天要用兩次）標準”， 要看這需求的使用頻率是否夠高，是否值得用各種成本（特別是維護成本）來支撐這個功能。如果類似的事情發(fā)生在 CSDN， 我們要花費很多維護成本來做一個低頻的功能 （例如用 OCR 掃描所有截屏，抽取其中代碼，給用戶使用），大家也會用數(shù)據(jù)分析用戶獲益/成本，我覺得這是非常理性的做法。

互聯(lián)網(wǎng)大數(shù)據(jù)服務型企業(yè)的競爭，拼到最后，就是拼算法，效率，成本。

但是，還有一些功能，就是在某頁面加一個鏈接，指向用戶可能使用的下一個功能，這并沒有什么成本，這個我們能快速上線么？還有一個辦法，直接問用戶他們的選擇。

80/20 規(guī)律能支持我們砍掉用得少的功能么？

在網(wǎng)上流傳一句非常廣的話 百分之八十的用戶只使用 Office 軟件的百分之二十的功能，這的確是如此。但是，這個 ”觀察到的現(xiàn)象“ 并不說明 因果關系， 不同的產品在競爭的不同階段，有不同的重點。在下圖的 “成長階段”， 大部分軟件都處于 “猛烈的功能軍備競賽” 的階段，大家不斷拓展軟件能解決問題的范圍，和易用性。

我用 MS Word 寫了 4 本書，其中的 3 本書，是我用 Word 手動輸入并修改的。我應該算是一個重度文字寫作的用戶，但是我的確在 80% 的時間里，只用其中的很少功能，可能 10%，但是我認為很有必要的一兩個功能，是別人很少用的，別的編輯器也沒有，只有 Word 有這些（而且以我習慣的方式）。所以，每個用戶長尾有自己的長尾需求，一個面向百萬用戶的 App 就要提供那些長尾功能，挑戰(zhàn)是要 “容易找到，確定性的交付” 這些體驗。

我加入 MS Office 團隊的時候 （1996），那個時候 Office 傳統(tǒng)的 App 如 Word，Excel 的確已經有很多功能了，那時候就有這個 80/20 的說法，我們內部也流傳自黑的各種笑話。還有進一步的數(shù)據(jù)說明，很多用戶向 Word/Excel 團隊提出的 “新功能建議” 大部分都是 Word/Excel 已經有的，深入分析發(fā)現(xiàn)，用戶的痛點在于，面對眾多的選擇，他不知道他想要的功能藏在那個菜單和子菜單下面?！叭菀装l(fā)現(xiàn)功能” 成為一個巨大的挑戰(zhàn)。那個時候 Office 就開始建立數(shù)據(jù)采集的平臺，根據(jù)數(shù)據(jù)， Office 還嘗試了一個創(chuàng)新 – 在顯示菜單的時候，先隱藏那些點擊率低的項目，過了兩秒鐘左右，再來一個動畫漸變，顯示全部菜單項目。當時的項目經理想，大部分時間用戶都是用那些最常用的，這樣就替用戶節(jié)約時間了。不料這個功能推出以后被罵死，因為

1）很多用戶期待的是一個確定性，“我知道那個菜單項就在第四個，你不要把它提前到第二個，過兩秒又改回到第四個！“

2）用戶想找不常用功能的時候，更迷惑了。

在UX 設計的時候，一個用戶場景 （scenario / story）的各個菜單，最好是達到 “don’t make me think” 的狀態(tài)， 就安靜地排列在那里，讓用戶習慣，這又怎么了？我們非要焦慮到每三個月改版一次，把 “blink” 改為 ”微社區(qū)“，然后又去掉 “微社區(qū)”，改回 “動態(tài)”， 位置從上挪到下方正中的圓圈，然后再挪到上面的另一個位置才顯得我們做了事情么？與此同時那些真正影響用戶體驗的各種問題，我們的研發(fā)，產品，運營每天用我們自己產品的時候（如果用自己的產品的話），注意到這些問題了么？用戶反饋讀嗎？轉成 Jira 了嗎？改正后告知用戶了么？產品經理、研發(fā)帶頭人寫這些bug 產生的模式分析么？

核心是讓那些不常用的功能以一種自然的方式容易找到，而不是把它們從 UI 中刪除。如果 Office 軟件把它菜單中 最不常用 的 20% 從老地方刪除，然后挪到 “Office” – “其他” – “不常用功能” – “這里”， 用戶會出現(xiàn)什么反應呢？

我非常支持系統(tǒng)化地收集數(shù)據(jù)，系統(tǒng)化地看如何優(yōu)化用戶體驗，改進質量，這里面有需要長期工作才能解決的，有短期工作就能解決的，有的并不太核心，有的可以做種實驗，有些 bug 也不是一定要連夜修復，但是 團隊的 “北極星” 指標還是對齊：CSDN 的 blink/動態(tài) 是讓用戶方便地隨時隨地交流 – 每天都有值得看的動態(tài)。

80/20 規(guī)律有時會給人帶來不一樣的思路， 有些是有趣的，有些對公司發(fā)展是有害的。我剛來 CSDN 的時候，聽到這樣的數(shù)據(jù)和觀點：80 % 的搜索都是命中了 CSDN 前幾年的博客，就是說，即使沒有這兩年的新博客，我們還能有 80% 的收入。我認為這是一個幻覺， 如果大家知道已經沒有人在 CSDN 寫博客了， 你看看用戶還會來 CSDN 么！當新的內容和內容創(chuàng)作者離開 CSDN 的時候，他們是一個一個離開的，這數(shù)量雖然少，但是是非常危險的信號。我們要不斷提高用戶體驗，讓 CSDN 的創(chuàng)作飛輪轉起來：

CSDN 有值得創(chuàng)作的話題 → 創(chuàng)作的工具很好用 → 創(chuàng)作后有真實的互動和流量 → 優(yōu)秀創(chuàng)作者獲得名和利的回報。

不正確的 KPI 對一個產品的影響

每個成員感性思考討論之后，大家的意見會凝聚為一個產品的 KPI，這是理性討論的結果。

從我自身的觀察，很多大型的產品的衰敗，是從使用率不高的功能的命運體現(xiàn)出來的。曾經一度 MSN messenger 和 Windows Live Space 是兩款很不錯的產品，一個是好友通信，一個是個人博客。它們一度有一個很好的功能：你的好友更新了他的space，那么他的MSN 聊天頭像旁邊就有一個小黃花出現(xiàn)，你點擊后就可以看到這個好友的最新博客或者照片了。挺好的一個小功能。但是在一次改版后，這個功能就沒有了。

我在微軟研究院的時候，和 MSN 的團隊打過幾次交道，livespace 的團隊倒沒有，但是從類似的經歷中，我可以想象出， livespace 的KPI 包括了 PV，如果有兩種方式：

a）用戶遍歷他的所有好友的頁面，看有沒有更新

b）用戶在另一個app上，只要看到了好友的更新，才來看網(wǎng)頁

哪個對 PV 的 KPI 有利呢？

很多小功能就是在一些大功能的接縫處，幫用戶節(jié)約時間和步驟，例如上面的那朵小黃花。但是，不正確的 KPI，往往統(tǒng)計的是 input metrics，或者過程性的metrics （頁面 PV，搜索次數(shù)），這些指標當然有價值，但未必是 “用戶滿意度”。就這樣，用戶喜歡的小功能都慢慢沒有了， 因為資源要投在 “大流量” 的地方， 用戶越不來，產品經理就用越露骨的方法來拉用戶，用戶的滿意度并沒有提高，后來，Windows livespace 和 MSN 都沒有了，當時微軟還提出，用戶可以多按幾個按鈕，轉移到 WordPress 和 Skype，我也轉移了，但是照片和很多聯(lián)系人都丟失了 … …

后來我和同事們閑聊，有兩個同事在不同的場合都說， 看到 MSN 的聯(lián)系人頭像旁浮現(xiàn)了小黃花，是我一天中最愉悅的時刻，微軟的產品經理腦子裝了什么，要把這種愉悅的體驗刪除呢？見不得用戶用軟件順手么？

網(wǎng)上也有評論：https://www.zhihu.com/question/299685950 一個公司要發(fā)展，當然要做各種決定，例如為了成本砍掉一些服務，停止維護一些服務，等。但是我們要考慮的是，后續(xù)的收益是什么？是為了滿足哪個 KPI 呢？

我們運營的是開發(fā)者的平臺，我們也有海量的內容，如果簡單的 ”海量內容“ 是我們的 KPI 的話，我們經常達到，有時還超額了。但是，用戶真正關心的是 “高質量，確定性，能解決問題的內容”。

如果追求錯誤的 KPI， 我們會短期達到這些 KPI，但是它們的負面影響很難消除。

我們過份把用戶 “物化” 為數(shù)據(jù)，把他們當作實現(xiàn)我們短期 KPI 的 “物料”， 用戶也會棄 CSDN 如敝履，在知乎，頭條上看看用戶對 CSDN 對評價，這可能是 20% 不滿的用戶發(fā)出的，可能是過去的印象， 甚至是別有用心的用戶發(fā)的，但是這些信息說明了很多問題。這是我們客服特地說明的這些已經糾正的 “老印象”， 理性地說，我們解決了這些問題，用戶應該馬上拋棄他們的舊印象，但是，感性地說，人并不是這樣思考和做決定的。這些壞印象，可能要花 10X 的努力和時間來消除。

一些小眾場景要修復么？一個軟件如何提高它的質量

一個軟件產品從小到大，從幾個用戶，到幾萬個，幾百萬個用戶，我們當然要看很多因素，當你有上百萬人都在有 PV，這個軟件應該很可以了吧？再出問題，再不爽，也是萬分之一，要重視么？要修復么？

大家覺得我們的App 直播連麥功能如何？早已經上線了，應該是 “足夠好”，對吧？我原來也是這么認為的。2021/11/25， 我開始第一次實際主持 1 小時的 “直達CSDN” 連麥活動，第一次連麥就出現(xiàn)幾個小 bug：

以后每周四晚上，我或者王路敏每次連麥都有新的 bug 出現(xiàn)，一次編輯部主持了一次和幾個專家的連麥，使用某種版本的安卓手機的專家干脆就說不了話，這是比較尷尬的。那么我們怎么熬過來的呢？

產品經理，研發(fā)組長，研發(fā)總監(jiān)每周四晚上出 bug 后都分析log，找到核心原因，快速解決，快速發(fā)版。（這里要鳴謝我們的 mobile 研發(fā)大牛：瑞瑞）

經過二十多個星期每次連麥 報bug 修復bug 上線，終于有一天晚上 9 點鐘，我們結束了一個小時的連麥后，意識到今天一個 bug 都沒有出現(xiàn)。這個 0-bug 時刻，就這樣達到了。

最近的連麥還有幾個小bug 出現(xiàn)，但是嚴重程度比最初已經輕很多了。這個時候，才是一種有信心的 “足夠好”。

blink 在它的發(fā)展過程中，也有用戶開始用它的 “使用率低“ 的功能， 有一次我們 top10 用戶說要在 blink 帖一個他做俯臥撐的視頻，搞了半天，就是貼不上。他的前一個帖子獲得了 700 個評論，但是自從這次視頻bug 之后，我看他就隱退了。有一次另一個重要用戶要親自在 blink 發(fā)帖子，慶祝一個重要日子，帖子帶幾個圖片，但是死活發(fā)不出，我們研發(fā)連夜 debug，終于解決了，但是這個日子也過去了，用戶也沒有發(fā)帖子。這些萬分之一的用戶不爽之后，即使她是 top 用戶，top 員工，要讓他們再回來，也是非常難的。這些人走了之后，他們再也不會出現(xiàn)在我們的數(shù)據(jù)報表中了，無論我們如何埋點，如何分析。

在我職業(yè)生涯中，我過得還是比較順的，最不順的一段時間是 2005 年，我在 Brian Harry 領導下要開發(fā)下一代的軟件項目管理系統(tǒng) （TFS，是VS online 的前身）。Brian Harry 早年開發(fā)了 Visual Source Safe，是一個比較簡單的源代碼管理軟件。類似 TFS 的項目做了一次，失敗了，這是第二次努力，而且是用全新的 .Net 框架來寫的， 我們當時用還是內測版的 C# 語言，內測版的 CLR 框架，內測版的 SQL Server，開發(fā)我們項目管理系統(tǒng)，不用說，bug 非常多。有一天 Brian 說，我們的產品可以跑了，我們就用這個版本來管理我們現(xiàn)在的項目。大家非常不滿，說我們知道現(xiàn)在 bug 多，速度慢，但是這些都會修復，我們目前用內部的老系統(tǒng)來管理不是很好么？他堅持。于是就出現(xiàn)了：

我用最新版本的 TFS 報 bug：「TFS 在保存帶附件的 bug 的時候崩潰」， 果不其然，在我填好數(shù)據(jù)，上傳了附件，要保存的時候，TFS 崩潰了。bug 也沒保存上。

怎么辦？只好連夜修復，第二天用新版。那一段時間我每天都加班到深夜，Brian 帶了部分團隊在遠程工作，他有時直接打電話來找人談 bug，態(tài)度也很嚴厲。團隊中有不少人都換組了， 因為微軟這個偉大的公司，壓力小而且管理友善的團隊多得很，大家都可以自由換組。Brian 解釋這樣做的原因：

1. 真正用我們的產品，我們的代碼要在實際使用中反復使用

2. 如果我們這幾十人，全球分布的團隊可以用 TFS 把我們的復雜項目管理好，我們才可以有信心把它賣給其他公司。

TFS 后來發(fā)布了，反響還不錯。我也離開那個團隊。微軟有系統(tǒng)化的員工反饋系統(tǒng)，一度每個員工都可以查任何經理的業(yè)務目標和團隊反饋數(shù)據(jù)。幾年后我查了一下 Brian 的數(shù)據(jù)，他的員工反饋有一條 “希望團隊文化更加包容 …”，我就笑了。

CSDN 要做一流的開發(fā)者的平臺，成就一億人，這一億人就會帶了很多 “小眾” 場景，我們的產品也很豐富，一億用戶的需求也多種多樣，我們自己也是 IT 人，我們平時用自己的產品么？寫博客用到所有博客編輯器的 20% 還是 80% 的功能么？它們好用么？每一個給我們發(fā)帖發(fā)微信反饋 bug 的用戶，他身后都有 100 個碰到同樣的 bug 但是懶得告訴 CSDN，逐漸不用我們產品的用戶，就像發(fā) blink 遇到 “小眾” 的 bug 的用戶那樣。我們對于這些紛紛擾擾，千頭萬緒的需求，bug，KPI，是如何設定優(yōu)先級，如何處理的呢？

CSDN 是一個公司，每個人對于這個公司的目標要投入多少，自然是不一樣的 （可以看豬、雞、鸚鵡的故事）。離我 2005 年加班的時間又過了 17 年，經歷了很多的項目和形形色色的人， 我自己也看了很多的埋點，數(shù)據(jù)，用戶體驗報告，和很多這樣的同事共事過。還也看了很多軟件工程、創(chuàng)業(yè)的書。我現(xiàn)在非常理解 Brian Harry 了。要把一件事請做成功，很重要的方面是要做 Hard 的選擇，堅持解決 Hard 的問題。太包容，善良，有時 hard 的問題就主動找上來，例如發(fā)工資的錢不夠了。

有些問題雖然表面上是小問題，但是這個小問題能出現(xiàn)，反映了團隊的大問題，我們一起分析和解決這些大大小小的 hard 的問題吧。感性和理性，都在不同的階段非常需要。

參考資料：

我以前讀過關于 XeroxParc 的兩本書：

• Dealers of Lightning: Xerox PARC and the Dawn of the Computer Age

• “玩閃電的牛人們” … 施樂公司PARC 研究院的故事，可歌可泣可嘆。1970

原文鏈接：https://blog.csdn.net/SoftwareTeacher/article/details/128638754