團隊的技術形象

文/Tim Yang

當一個 app 不好用時候，用戶會說團隊的產品不行；當系統可用性有問題時（比如訪問慢或頻繁宕機），用戶會說這個團隊技術不行。

發生頻繁宕機并不常見，宕機通常會由程序 bug 或者訪問壓力過大引起。bug 最終會被修復；在不過分在意成本的情況下，訪問壓力最終可以用硬件來扛住。另外系統升級及功能變更也會帶來可用性與穩定性的問題，但大多數系統會最終相對 穩定下來，大的變更會越來越少，系統也會趨于穩定。

技術成本的控制通常不是一個很緊迫的問題，一方面公司的業務模式也不是靠省服務器做出來的，其次技術團隊可以通過投入時間去優化改善來降低成本 (但大部分團隊更愿意將研發資源投入到新功能開發上去)。因而通常只要達到基本可用，則成本合理性問題不會得到充分關注。另外成本也很難直接對比，一個公 司比另外一個公司服務器少些，但是各自功能場景有差異，沒有直接可比性。因此較難從技術成本合理性角度衡量某個團隊技術好不好。只要系統基本可用，則認為 是一支有戰斗力的團隊；如果能達到一定體量（雖然不是技術團隊直接帶來的），那則會被視為超強的技術團隊。

軟件質量在大部分公司走不出測試或者“質量保證”部門，很少有團隊會認為步子不夠快是由于軟件質量問題造成。開發效率同樣沒有直接可比性，“努 力”有時候會掩蓋一切，朋友圈時常會看到這樣的總結，“雖然走了一些彎路，但兄弟們加班加點將進度追了回來，感動……”。比軟件質量問題更糟糕的是業務方 向的不確定性，方向不確定帶來的消耗比軟件質量的問題更大，走錯方向導致一兩個月努力泡湯的事情也很常見，因此不是最短板的軟件質量的重視通常就無從提起 了。

隔洋對岸則有一些技術主導的公司，Mark Zuckerberg 曾說過，非死book 在早期時，非技術崗位如 HR 及市場也招聘有技術背景的人擔任。這些公司盡量招聘最頂級的技術人才，這些人能夠在公司中享受技術的樂趣。但這也只有平臺級的公司才有可能。這些公司商業 模式的門檻足夠高，從而有持續的利潤來支持這一愿景。而剩下絕大多數公司，需要首先去考慮生存的問題，這也談不上不酷，頭部的公司如果失去壟斷地位，也馬 上沒有機會去維持純技術的 image。

技術行不行是一個很無力的目標，技術很強的團隊未必能改變世界，不強的團隊很多時候也生存得很好。業界很多業務模式短板并不在技術上，更混亂的 是，出現技術問題有時反而被當做 PR 事件及段子去炒作。當然，在技術較差的團隊，軟件質量及技術創新無從談起。處在風口的豬，也會遇到前文所說的重復踩進同一個坑的無力感。