小團隊産品優化的問題

小團隊做小産品，如果隻能追求bigger and bigger的名額，會對細節做很多關注；但如果小團隊做“大”産品，則隻能先和别人比拼功能的多少，而不能拿細節說事，否則階段性目标很難達成。

在開發過程中，這兩種團隊的相應指導思想肯定是不同的。代碼、技術、架構等方面，不同團隊也展現對應的特征。

為此，我還專門找過一些書籍來看，比如印象比較深刻的《執行個體化需求：團隊如何傳遞正确的軟體》。該書是在世界各地調查了多個團隊軟體傳遞過程後的經驗總結。書中介紹了這些團隊如何在很短的周期内說明需求、開發軟體，并傳遞正确的、無缺陷的産品；為團隊在實施執行個體化需求說明時使用的模式、想法和工件建立了一緻的語言；展示了案例中的團隊用來實作執行個體化需求說明原則的關鍵性實踐；并在案例分析部分展示了一些團隊實施執行個體化需求說明的曆程。适合于項目管理、開發、測試、傳遞有關的人員閱讀。

裡面就系統性的闡述了如何不走彎路，開發出“正确”的軟體給客戶使用。講得還是不錯的。

對于toB産品，我們也無法斷定先實作後優化的“快速疊代”方式是否正确。因為使用者量不夠大，使用者的回報還不夠，如果隻聽一家之言，又怕被帶偏。但優化是必定的，我們往往隻能先作出基本功能，然後在使用者體驗後，判斷是否與其實際場景比對，用起來是否順暢，甚至搞清楚最根本的問題“是否有用”。

我們現在這個團隊，說實話，也是屬于後者：代碼量大，功能多，技術方面不談，體驗方面更不忍直視。前面兩年，表面上是産品主導的，但由于toB的特征比較強，産品沒有相關經驗，無法對體驗作出準确的定義，做出來的東西确實沒有細節，再加上技術沉澱也少，隻能追求形式上的“快速疊代”。一旦慢下來，回頭去檢視原有功能體驗，就不是那個味兒了。