第(2/3)頁

    在研發環節就搞內部競爭，這在87年絕對是罕見的，因為軟體業眼下還沒有形成壟斷的超級巨頭，光是外部其他公司的競爭，就足夠鞭策軟體開發者不斷前進了。

    后世內部競爭激烈的，主要是騰云這樣的公司，已經形成壟斷了，才自己搞自己。

    要不就是華為那種因為供應鏈安全問題，需要備胎計劃的，所以搞兩套，一套留著。

    但顧驁卻很有眼光，他知道他接手之后的第一代乃至第二代電腦，都還需要這個過程。

    因為一旦面臨微軟的開放式作業系統競爭后，如果封閉式作業系統品牌的生態還沒起來，來捧場的外部分包商可能不夠。這樣，指望自然競爭是不可能的，不引入左右互搏的內部競爭，就有可能把比較殘次的產品放到市場上去。

    當然了，顧驁也不會盲目持續競爭，那樣既會過度浪費資源，也會導致消費者選擇困難、不夠簡潔。

    試想一下，要是一群消費者，在官方的軟體銷售渠道里，同時看到一個office和bsp;            辦公的東西，簡潔統一最重要，這是工具，不是游戲，工具要的就是壟斷和標準化，而不是花里胡哨可玩性。

    所以，這種內部競爭，應該是只持續到小範圍試點投放結束后、分出優劣勝負，就立刻中止。

    然后all-in支援那款在小範圍試點內測時表現勝出的產品。

    這種思路，有點兒像后世互聯網時代的a/b測試和“儘快投放，快速迭代”研發思路。

    a/b測試這玩意兒，不是互聯網行業圈內人，或許不太了解，稍微幾句。

    這玩意兒主要是facebook的小劄用出名的。在21世紀初之前，軟體行業是比較講究理性設計的，早期研發完成后，后續的測試也是很嚴謹的，基本上項目經理怎么要求怎么來，跟設計不符的就是bug。

    但是隨著互聯網產品更多偏向娛樂消費和社交，偏向“體驗”之后，其實最初設計得太嚴密就不是好事兒了。因為100%項目經理前期論證的模式，只適合那些對錯分明的問題。

    可是體驗這玩意兒，是沒有對錯的。就像很多公司的測試部門，對著test-case的時候，你能出一個功能錯沒錯，但你不出一個功能漂亮不漂亮、舒服不舒服。

    這玩意兒太主觀太見仁見智了，你指望不了項目經理每次都跟主流審美站在一起，所以哪怕你希望你的人都跟騰云的工程師一樣，“每次都刻意站在小白的立場上換位思考”，也不一定奏效。

    這不是同理心的問題，而是精英是無法靠意淫來意淫出小白究竟是如何想得。

    后世大約06年前后，facebook流派開始擴散出來的a/b版測試，這時候就是一個比較好的工具了。它不需要項目經理再去設身處地把自己裝作小白，而是直接把好幾個各抒己見的外觀、ui更新內容，小範圍投放給幾千幾萬個用戶去用。
    第(2/3)頁