Чи замислювалися ви хоч раз над тим, навіщо розробники деяких веб-ресурсів пишуть слово «beta» в заголовках? Багато хто вважає, що це черговий маркетинговий хід Web 2.0 (нарівні з «лакованими» елементами інтерфейсу, великими шрифтами і підтримкою RSS).
Зізнаюся чесно, я сам так колись вважав.
Однак напис BETA - це все-таки більше ніж просто напис. Створення будь-якого веб-сервісу починається з ідеї. За ідеєю з'являється прототип, а на основі прототипу безпосередньо план реалізації проекту. Якщо розробників кілька (і вони досить професійні), то малюються UML-діаграми, карта сайту, створюється попередній HTML-макет і т. п. Так було і у нас: здавалося, що все зрозуміло і прозоро. Однак коли була готова альфа, у мене з'явилися цілком певні сумніви: «а чи цього ми хотіли в підсумку?» і найголовніше «а чи будуть цим користуватися люди?».
Найпростішим способом дізнатися відповіді - це запустити сервіс. У бету. Власне втрачати нічого, та й фраза «We call it» beta «because it's beta than nothin'» вселяла впевненість.
І ось тут почалося найцікавіше. Чим більше часу проходило з точки запуску «бети», тим все далі і далі йшли мої погляди на сервіс від тієї самої початкової концепції/ідеї.
(І це тільки потім я дізнався про слова Пола Грехама, про те, що через три місяці після початку розробок, стартапи змінюють свій напрямок на 70%, а деякі і на 100%)
Інтернет змінив не тільки поведінку користувачів, він ще й змінив сам підхід до розробки. Для того щоб випустити новий реліз, не треба робити інсталятор, штампувати диски, друкувати поліграфію, упаковувати в коробки і відправляти все це потім в магазини.
У нас є можливість робити релізи хоч кожен день, впроваджуючи нові функції і виправляючи помилки старих. Ми можемо постійно відстежувати поведінку користувачів, отримати фідбеки, і на їх основі визначати, в який бік розвивати проект. Саме тому пересічний користувач і стає членом команди розробки.
До речі, включення «замовника продукту» в команду є однією з основних практик методології розробки Scrum (Agile development). Якщо вести розробку по Scrum'y, то цикл розробки можна скоротити в рази (порівняно з розробкою десктопних додатків).
Через якийсь час ми прийшли до того, що середня тривалість циклу у нас становить 2-3 тижні (а іноді і менше). Користувачі постійно бачать якісь зміни на сайті і можуть впливати на те, в який бік розвивається проект.
Не можна зараз створювати інтернет-продукт півроку, потім півроку його ретельно тестувати, а потім викотити реліз, який, швидше за все, ринку і не потрібен буде.
У підсумку ми за допомогою користувачів зрозуміли, що концепція проекту досить серйозно зміниться в найближчий місяць-півтора. І варто лише сказати спасибі всім тим, хто терпить зараз всі баги, дає поради, і по суті разом з нами робить продукт, який дійсно буде потрібен людям.
Без такого підходу зробити успішний інтернет-додаток вкрай важко.
І наостанок скажу, що сервіс у стадії бети - це бета і в концепції і в коді. Короткі ітерації породжують ще й підвищений відсоток помилок (багів). Автоматизовані тести, звичайно, рятують ситуацію, проте людський фактор теж не можна виключати. І деякі баги можуть досить ґрунтовно підірвати репутацію сервісу. Наприклад, не так давно у нас стався збій в модулі e-mail повідомлень, і користувачі отримали від 20 до 60 листів, що призначалися не їм.
Не забувайте про те, що бета - це зовсім не альфа і якщо у вас все буде падати і відвалюватися через раз - це банальний прояв неповаги до своїх користувачів.
Помилки, звичайно, трапляються, але їх поява в браузерах користувачів треба зводити до мінімуму.
(Багато хто пам'ятає bobrdobr.ru і скріншоти з його ServletException-ами, хоча в кінці-кінців все закінчилося добре: сервіс росте і розвивається)
