Чи справді нам потрібно це будувати?

Функція роздуття – справжня проблема для всіх великих і маленьких стартапів. Залишатися зосередженим вимагає дисципліни, щоб знати, коли сказати “ні”, навіть коли повзучість функцій вважається абсолютно необхідною. При цьому існують обставини, коли нормально відходити від вашої дорожньої карти, і ось як ми про це думаємо.

Фокус – ключовий момент для всіх стартапів. Успіх нашого продукту зводиться до виконання нашої основної ціннісної пропозиції. У «Саймона» наше орієнтир, що будувати (а що не будувати), випливає з нашої дорожньої карти. Кожні два місяці ми ретельно перевіряємо існуючих клієнтів, що працювало, а що ні, і надаємо пріоритет розвитку для наступної ітерації.

Пункти з цього списку були ретельно розглянуті, визначені пріоритетами та добре визначені. Ми намагаємось сформулювати наш план так, щоб він був зосередженим і складався з набору цілей, досяжних у рамках майбутньої ітерації.

З нашого досвіду, найбільшою загрозою цілісності цієї дорожньої карти є роздуття функцій. Привабливість “лише кількох пікселів” або “кількох рядків коду” має довгострокові побічні ефекти та витрати, які охоплюють більше кількох годин часу на розробку. Вартість додавання цих сторонніх функцій реалізується у вигляді технічного обслуговування, яке проходить місяцями та роками.

Справжня вартість функціонального роздуття

До Саймона декілька з нас були в Etsy, який зазнав колосальних особливостей і технічного розпаду в перші дні. Проблема стала жахливою: існували десятки розрізнених процесів покупок (побудованих переважно за допомогою Flash), шарів проміжного програмного забезпечення, які нічого не допомагали, крім додавання складності, сервісів черги з мінімальними вимогами, які можна було б створити за допомогою наявних баз даних. Ця функція ускладнила використання виробу (і погіршила загальний досвід) за високі витрати на обслуговування.

Моя команда вбила функції. У нас був список пральні, який, на нашу думку, мало цінний. Раз на місяць ми визначали б наступного у нашому списку цілей. Він передбачав ретельне дослідження та тестування – хто його використовував, чому та які альтернативи можуть існувати, якщо він буде засуджений. Потім ми пройшли інженерні зусилля, необхідні для видалення цієї функції – переконавшись, що будь -які побічні ефекти та код спільної бібліотеки були добре зрозумілі та перевірені. Нарешті, ми оголосили про видалення спільноті, існуючим клієнтам та необхідній підтримці.

Хоча я не був у Etsy, коли було створено більшість цих функцій, я знаю, що час, необхідний для їх вбивства, зазвичай перевищував початковий час розробки.

Коли потрібні винятки

Постійний потік нових і несподіваних запитів на функції – це сильна напруга, через яку ми переживаємо кожен день. Ми не можемо сказати всім «так», але також не можемо сказати всім «ні». Пріоритетуючи функціональні можливості дорожньої карти, ми намагаємось повернутися до таких трьох принципів, які невід’ємно поєднані з успіхом бізнесу.

Задоволення існуючих клієнтів. Часто клієнти просять конкретного рішення, але вони намагаються вирішити проблему іншим рішенням, ніж ми зараз підтримуємо. Іноді виникають крайні випадки, проти яких нам потрібно протистояти, і ми пріоритетуємо їх залежно від терміновості. Гарне управління обліковим записом – це довгий шлях.

Залучення нових клієнтів, які будуть успішними. Завзяті клієнти запитують, чи ми можемо зробити A або B, або W або Q, деякі з яких можуть бути більш -менш пов’язані з нашою продукцією та дорожньою картою. Ми працюємо з великими клієнтами, тому тиск на укладення угод може бути великим. Іноді ми погоджуємося створити щось для нових клієнтів – але тільки після ретельного огляду інженерією та продажами.

Залишатися інноваційним. Однією з причин, чому ми любимо працювати на стартапі, є ненависть до корпоративного процесу. Інновації випливають із випадкових ідей та натхнення на обід, які починаються зі скромного підтвердження концепцій. Ми любимо невеликі експерименти – витратьте кілька годин на ідею, додайте її до нашої виробничої системи та ввімкніть лише для адміністраторів, щоб ми могли пограти всередині та побачити, як вона нам подобається. Більшість не потрапляє у функцію, орієнтовану на клієнта, але всі вони дають певне уявлення про наш продукт.

Коли надходять запити на нові функції, ми намагаємось узгодити їх із наведеними вище критеріями. У деяких випадках ми усвідомлюємо, що нам просто потрібно притулитися і побудувати несподіване. Однак, якщо запит не підпадає під жодне з цих трьох сегментів, ми задаємо собі питання: “Чи справді нам потрібно це будувати?” Після чого ми продовжуємо працювати пізніше, кидаємо його в морозильну камеру, чекаємо, поки ми зможемо ретельніше оцінити, а потім приступаємо до роботи.

Цей пост спочатку з’явився на веб-сайті http://engineering.simondata.com/do-we-really-need-to-build-that/.

Спочатку ця публікація була опублікована за адресою https://www.linkedin.com/pulse/do-we-really-need-build-jason-davis/.

Jason Davis люб’язно дозволив нам перекласти і опублікувати цю статтю.