「先有後優」、「迭代式開發」的這種開發會對用戶造成傷害么？

01-21

現在這種開發方式似乎被許多應用和遊戲的開發者所使用，但這種把功能不全、bug多多的產品過早的拿出來會不會給初期用戶留下負面的感覺呢？

「先有後優」是不在獲得第一手用戶行為數據/反饋之前做過度的設計。目的是擺脫長期想當然的設想用戶需求，把時間浪費打磨在用戶不需要/不好用的功能上。這種打磨是產品功能和用戶體驗層面上的，並不代表帶著BUG上線。

「迭代式開發」是保證從「有」到「優」這一過程的。你就是拿到了用戶行為/反饋，還是有可能做錯。那麼小規模的改進保證你每次投入的成本不是太高，用戶對於線上細微的功能變化是可容忍的。這個過程保證你可以更大膽的嘗試實現需求的Idea，而一旦想法錯了，又不會錯得太遠。「灰度上線」和「A/B測試」也有這樣的作用。

綜上所述，這兩點其實是代表著用戶的利益：有人真心關心你需要什麼樣的的功能和體驗，並且時時刻刻想著為你改進。而不是拿了一大堆你不需要的功能來QJ你。

「迭代開發」與「帶著很多bug就上線」是風馬牛不相及的兩件事。

1，無論任何產品開發流程，對於bug都應該是零容忍的態度。bug修復永遠放在下次迭代開始之前。

2，迭代開發的第一版，是為了實現產品最核心的功能。（例如QQ第一版就是為了聊天，沒有郵箱、音樂之類）。對核心功能的定義要盡量精簡（砍到不能砍為止），以保證第一個版本快速上線。

3，即使第一輪迭代做完，也可以選擇不馬上上線，保守的話可以進行內部review，小規模用戶review。然後第二輪、第三輪迭代後的時候上線。

最後說一句，帶著bug上線的確對用戶造成很大傷害，但與迭代開發無關。

僅供參考：）

這種開發是開發階段的模式，而不是第一版demo就扔出去。

比如原來60天要出來完整的產品，現在改成6個迭代，每個10天，每個迭代都放出一個內部可用版本。這樣會大大減少需求變更帶來的影響，及早發現各種問題，而且緊湊的模式會提高各種效率。而發布產品同樣是60天後。後者的成功率和品質都優於前者。

簡單來說，如果要增添A功能，就把A功能做完整。從頭至尾，用戶閉環清晰且體驗好。如果不做，就完全的不做。

應用和WEB遊戲開始才流行這種方式，數據獲取更容易，修改更新更便捷，支持了這種方式的流行，以往的大客戶端不敢想像；

感覺某類產品初期的時候，用戶挺耐操的，只要主流程沒大問題，都OK；當同類產品多了，用戶欣賞水品高了，相對其他產品來說，前期功能少、BUG多可能就不可忍受了，因為有了對比；

難道還有別的方法？

「先有後優」、「迭代式開發」也要求對不同階段測試什麼信息，學習什麼市場反饋有一定的判斷和規劃。總體這是最近比較流行的創業思潮，成為MVP（Minimum Viable Product-最低要求有效的產品）

看用戶的需求，用戶覺得這個東西得有，而且得馬上有，那就先有後優唄，如果這個功能是錦上添花的，那就反覆測試後再上線。但是肯定的是:bug率高，用戶使用你這個已有的東西不爽，用戶忠誠度是肯定不高的。

先有後優，和迭代式開發，跟本就是兩馬事，請不要混為一談，謝謝！！

有的概念不是做一個到處bug的東西發布，而且砍掉全部不必要的功能，先推出實現核心功能的版本，隨後再去優化體驗和擴展功能

這是一個度的問題吧，bug多到什麼程度嚴重到什麼程度才會影響你的品牌形像？這個要具體分析吧，一般對於消費領域的電子產品來說，消費者還是很寬容的。如果這個產品還有很多人捧，那就說明還沒超過度，你超過了這個度，消費者自然而然會用腳投票離你而去。

如果把初期用戶當作測試員以及data生成器來看待的話，其實顧慮可以不用這麼多，但是bug多多會影響你獲取用戶數據

當用戶認為這是個垃圾的時候，後期需要花費多大的力氣才能挽回？