Перероблювати не можна залишити: 6 історій переписування коду

25 хв. читання

Новий погляд на одвічне питання: чи варто розробникам переписувати програми з нуля, чи це найгірша стратегічна помилка всіх часів? Неймовірно, але є більше ніж два шляхи взаємодії із завершеним кодом.

Код не іржавіє

Майже двадцять років тому Джоел Спольські у своєму знаменитому есе Things You Should Never Do насварив Netscape за переписування кодової бази.

Він дійшов висновку, що програму, яка працює, ніколи не потрібно переписувати з нуля. Аргументи було два:

  1. «Недосконалі» частини коду часто враховують незвичайні помилки і гострі кути — знання, добуті з часом і досвідом.
  2. Переписувати — це довго, за цей час можна було б удосконалити продукт, адже конкуренція працює проти вас.

Для багатьох висновок Джоела був беззаперечним. Та згодом з'явилися і прихильники протилежної думки. Вони стверджували, що інколи програми все ж треба переписувати з нуля, тому що:

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

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

1. Netscape

1-Cc-Ocjs6ob6xk3-Yc3-Bvaj-YQ

Катастрофічне переписування Netscape 5.0/6.0 — ідеальна ілюстрація гасла «ніколи не переписуйте код».

Netscape Navigator, вперше випущений у 1994 році, визначив перші роки комерційного інтернету. Менш ніж за два роки IPO компанії в 3 млрд доларів запустила еру дот-ком.

Першу серйозну конкуренцію Netscape склав Microsoft Internet Explorer, який вийшов у 1996 році.

На початку 1998 року Netscape все ще залишався провідним браузером, але його позиції дуже хитались. Для споживачів Netscape коштував 49$, а Microsoft поширювала IE задарма, плюс встановлювала його у Windows як браузер за замовчуванням.

1-x-K0-A1-Dvcc-TAfc-Lbpfjq-Ku-Q

Після четвертого випуску Netscape оголосила, що версія 5.0 буде безкоштовною, а створить її заснована компанією спільнота open source, названа Mozilla.

Такого тоді не робив ніхто, абсолютно безпрецедентний випадок. Netscape негайно отримала бажані овації і любов споживачів. Однак ніяка спільнота так і не розробила нову омріяну версію. Джейме Завінскі, один з перших розробників браузера, пояснює:

Правда в тому, що з до проекту Mozilla долучились близько ста постійних розробників Netscape. Окрім них було тридцять віддалених працівників з частковою зайнятістю, тож проект все ще повністю належав Netscape.

Сторонніх розробників не дуже цікавив новий відкритий проект, адже його попередня кодова база була невпорядкованою і хаотичною

Код був занадто складний для змін, люди не сприяли його... тому ми перейшли на новий механізм компонування. Теоретично, новостворену кодову базу люди мали б легше розуміти і доповнювати.

Початок з чистого аркуша

Тож через рік група вирішила не випускати версію 5.0, а з нуля створити 6.0.

Минуло два роки, коли Netscape 6.0 нарешті опублікували, і навіть тоді було зрозуміло, що він ще не готовий. В рецензії Нью-Йорк Таймс написали, що браузер запускався хвилину (!). Це при тому, що йому явно бракувало елементарних функцій, котрі були у попередніх версіях: наприклад адресний рядок не можна було виділити одним кліком, зникла функція попереднього перегляду тощо.

Та не те, щоб це вже мало якесь значення. За три роки простою Netscape його нішу успішно зайняв Internet Explorer.

1-2-

Після початку переписування Netscape швидко здав позиції Microsoft Internet Explorer. Через три роки новий браузер Netscape був глючним і повільними, а частка компанії на ринку за цей час дуже зменшилась.

У 1999 році, коли вже переписували браузер, AOL купила Netscape за 10 мільярдів доларів. Через два роки після випуску Netscape 6.0 команду Netscape в AOL повністю розформували.

Mozilla, створена Netscape спільнота розробників відкритого ПЗ, випустить браузер Firefox у 2002 році — після ще одного переписування. Firefox вдалося тоді відбити у Microsoft частку ринку.

Та як бізнес Netscape помер (а його рештки — інтелектуальна власність — перейшли до Microsoft внаслідок їх угоди з AOL у 2012 році, досить принизливий такий фінал).

Microsoft виграла битву і відмовилась від інвестицій у браузери. Internet Explorer 6.0 вийшов у 2001 році та не оновлювався протягом п'яти років (що, можливо, було частиною стратегії, призначеної захопленню мережі).

Урок №1

Є думка, що переписування браузера не було такою вже бідою, адже зрештою ми отримали Gecko і Firefox.

Але користувачам довелось пережити роки стагнації веб-технологій та нудну й довготривалу монополію IE6. До речі, останню знищив зовсім не Firefox, а Google Chrome.

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

Тож в цьому випадку — переписування програми стало катастрофою.

2. Basecamp

1-O4-z-INabn-PY7b-WJ3ez-X63

На початку нульових чиказьке агентство веб-дизайну 37signals зібрало прихильників навколо впливового та контроверсійного блогу. Засновниками проекту були Девід Генсон і Джейсон Фрід.

Взагалі компанія привернула увагу автора цієї статті своїм проектом 37better — перспективні, але так і не втілені в життя редизайни сторінок для Google, PayPal та інших. Як бачимо, їхня форма для поштової корпорації FedEx навіть тоді, майже 20 років тому, була краща за ту, що зараз.

fedex Ліворуч — нереалізований редизайн форми FedEx від 37signals, праворуч — те, що зараз

У 2004 році команда взяла свій внутрішній і власноруч розроблений інструмент для керування проектами й перетворила його на софт. Точніше на software-as-a-service product, який назвали Basecamp.

Це було в той час, коли підписка на програмне забезпечення була ще новинкою. Інструменти приходили у величезних коробках з чотиризначними цінниками та тяжкими посібниками про моделювання критичних шляхів і створення діаграм Ганта.

Basecamp продавався за 50 доларів на місяць і був ковтком свіжого повітря — простий та сфокусований на спілкуванні. Кілька років — і у Basecamp вже мільйон щасливих користувачів, їх чеки пливуть стабільною рікою. Тут засновники проекту починають непокоїтись.

Після того, що Девід називає «сім товстих і ситих років», вони опинилися у безвихідній ситуації. І це не мало ніякого стосунку до технічного боргу.

Золота клітка

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

Ідей, як зробити продукт кращим, було мільйон. Та коли сотні тисяч людей будують свої робочі процеси навколо Basecamp, кожна внесена зміна — це землетрус. Тож головною перепоною була не гнучкість кодової бази, а користувачі.

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

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

В компанії почали розглядати свій основний продукт як золоту клітку. Підхід був відповідний: переконатися, що користувачі щасливі, гроші приходять щомісяця, чудово. Далі треба просто зайти в золоті ґрати і сказати: «Блискуче, тепер я більше ніколи не буду змінювати своє ПЗ».

1-Sq-YBDomffz-Q2-Cl-JIs-QMi7-Q

Спойлер: Basecamp все ж переписали і вийшло супер. Це зайняло приблизно рік, після релізу Basecamp 2 кількість підписників зросла вдвічі. Тут автори проекту зробили дві цікаві речі, завдяки яким усе спрацювало.

По-перше, вони не відтворювали той самий продукт, що вже був. Розробники мали нові ідеї, як розв'язувати старі проблеми. І це слушно, адже те, що було актуальним у 2003, навряд спрацювало б і у 2011.

Вони представили Basecamp 2 як абсолютно новий продукт, без гарантій сумісності з Basecamp Classic. Щось зникло, щось додалося, щось докорінно змінилося. І це рішення дало певну свободу. Свобода мотивує, а вмотивовані люди роблять більше.

Захід сонця шкідливий для здоров'я

А як же ж всі ці сотні користувачів, для яких кожна зміна — це землетрус? Всі ті, яким було затишно і радісно зі стареньким добрим софтом? А це друга цікава річ, завдяки якій все склалось добре. Розробники створили новий продукт, а старий НЕ закривали.

Щодо цієї ситуації Генсон згадував поняття «захід сонця» у світі програм:

Хтось колись придумав цей чудовий евфемізм із заходом сонця… Давайте назвемо програму для вбивства «sunsetting». ... Всі користувачі зможуть сидіти на пляжі і дивитися, як вмирають усі їхні дані. Це буде прекрасно!

Звісно ж, будь-який користувач після видалення його даних не скаже: «О, це було так красиво, оце я розумію захід сонця». І ми, і Девід Генсон переконані, що думки користувача будуть менш поетичними.

Тому Генсон не зробив «найгіршу стратегічну помилку всіх часів», він не змусив користувачів вставати з насидженого місця і готуватися до змін. Люди не люблять ворушитись, тому можна просто лишити їм стару і затишну версію програми.

Девід порівнює Basecamp Classic із фотоапаратом Leica M3: його не виготовляють з 1967 року, але Leica продовжує підтримувати пристрої, поки вони працюють.

Тож Basecamp взяла на себе зобов'язання «шанувати свою спадщину» і продовжувати підтримувати Basecamp Classic протягом невизначеного терміну.

Іронія в тому, що через чотири роки, вони зробили це ж саме знову: Basecamp 3 був випущений в 2015 році і переписаний з нуля: щось зникло, щось додалося, а щось докорінно змінилося. І знову ж: переходити на нього ніхто не змушував. Хочете залишатись на Basecamp Classic чи Basecamp 2? Ніяких проблем. Ми шануємо свою спадщину.

Але...але... але хіба це не дорого? Хіба не надто складно? Як щодо безпеки? А застарілі кодові бази? Як щодо цього? А от як: турбота про клієнтів, навіть не зацікавлених в оновленні, це саме те, чим ми тут займаємось, — відповідали засновники.

Урок №2

По-перше, ця модель справді надихає. Кожен раз розробники могли переглянути свій підхід та створити кращий продукт. Для користувачів все теж склалося ідеально: хто не хоче змін, залишається зі старим і надійним ПЗ, а хто хоче — працює з оновленою, покращеною версією продукту.

Так, треба підтримувати старі версії. Але хто казав, що це безкоштовно? Ніхто не казав.

1-l0-XU-5-L7-LPojxf-H-HGt-LHg

3. Visual Studio & VS Code

1-e-KBCi-XHiv-YWRPtom9-Uq-ZUg

Microsoft зробила VS Code, щоб звернутися до розробників, які працюють на інших платформах. Згадайте, що довгий час робота у світі Microsoft — це був вибір між «всім або нічим». Якщо ви використовували Visual Studio, ви працювали в .NET і навпаки. Це розділило спільноту розробників на два великих табори — і нікому на користь це не пішло.

Круті діти — розквіт програми

Все почало змінюватися ще за часів Стіва Балмера — згадайте, скільки шуму було, коли команда ASP.NET вирішила не перевигадувати jQuery! Однією з пріоритетних задач Microsoft було звернутися до розробників з іншого боку паркану. Та, за словами віце-президента Visual Studio Джулії Ліусон запропонувати вони могли небагато:

У нас не було нічого для всього цього класу розробників — сучасних, орієнтованих на веб, Node, JavaScript. Нам не було, про що розмовляти з ними, й не було чим їх привабити, взагалі.

Тож VS хотів зруйнувати бар'єри та сказати: «Знаєте що? У нас все ж є дещо корисне для вас».

Visual Studio — важкий продукт в будь-якому сенсі: його встановлення може тривати півгодини. Він мусить підтримувати багато функцій, потрібних корпоративним клієнтам.

Тож видається беззмістовним орієнтування на VS тоді, коли Microsoft звертається до інших платформ і, власне, хоче додати ще функцій. А ідея створення версій Visual Studio для Mac і Linux, вочевидь, була не найвдалішою. Тож вони вирішили створити VS Code.

І Microsoft почала з нуля, без будь-яких гарантій щодо сумісності. Ну, як з нуля, насправді у Microsoft вже були деякі важливі елементи, як от внутрішньобраузерний редактор Monaco. А оскільки VS Code — це застосунок Node.js (написаний на Typescript і запущений в Electron), вони змогли скористатися перевагами багатої екосистеми JavaScript.

0-7ak-OMsn-PRw-Juj-PUh

VS Code став відкритим, легким, швидким, гнучким; і — що дивовижно для Microsoft — модним середовищем програмування серед крутих дітей.

Обидва продукти досі активно розвиваються і немає жодних ознак того, що Microsoft відмовиться від Visual Studio.

Урок №3

На відміну від Netscape, Microsoft вдалося побудувати активну спільноту open-source навколо VS Code. Ця спільнота помножила роботу рідної команди розробників. На GitHub серед усіх проектів з відкритим кодом Visual Studio Code посідає 13-те місце, а це лише трошки нижче за Linux.

Звісно, не всі можуть собі дозволити підтримувати повністю відкритий продукт. Та якщо відкритий код є у вашій стратегії розвитку, все ж ця історія може бути повчальною. Наприклад, в тому, що Microsoft дала VS Code надійну модель для розширювань, в результаті спільнота написала майже 10 000 розширень.

І останнє щодо історії VS Code: пам'ятайте, зараз простіше ніж будь-коли створювати прототипи і програмне забезпечення. Екосистема JavaScript нарешті перетворилась на довгоочікуваний рай для багаторазового модульного відкритого коду. В цьому плані ми живемо в історично безпрецедентну епоху.

4. Gmail & Inbox

1-e-RBm-c-Udu-NQy-Bzu-sp-Xh-Nw

Inbox для Gmail з самого початку представляли як спрощену альтернативу UX для Gmail, «сфокусовану на справді важливих речах». Він ніколи не повторював усі функції оригінального Gmail і мав відмінності, як от закріплені імейли, відкладені повідомлення тощо.
Деякі люди з ентузіазмом сприйняли Inbox та очікували, що це таке собі прев'ю до ще одного Gmail, просто треба почекати, поки усі функції Gmail перейдуть до Inbox.

Два інтерфейси, один сервіс

Inbox і Gmail використовували один і той самий сервер. Це були просто різні користувальницькі інтерфейси для тієї ж самої послуги, тож ви легко могли перемикатися між ними.

Тут були свої переваги та недоліки: якщо в Inbox не працювала якась функція (скажімо, немає автовідповідача про відпустку), завжди можна перемкнутися на Gmail. Та перемикатися кожен раз все одно було дивно.

Однак через деякий час Inbox перестали розвивати взагалі, Google більше не вкладав у нього ресурсів і оголосив про закриття Inbox.

1-HAJTdgg-R4-LBx2d-Xl-BOb6-Bw

Уважні користувачі могли помітити, що в останню версію Gmail перенесли багато функцій з Inbox: Smart Reply, дії з наведення курсору, вбудовані зображення тощо. Та не всі переваги Inbox знайшли друге життя у Gmail, і не всі користувачі залишились задоволеними.

Урок №4

Inbox дав команді Gmail можливість експериментувати з функціями. Однак рішення використовувати обидві версії в тому ж бекенді суттєво обмежило можливості інновацій для самого Gmail. Google багато критикували за закриття досить популярного сервісу. Звісно, це не вперше, пора вже звикнути, що Google постійно закриває свої продукти.

Та в цьому випадку користувачі повірили, що Inbox — це попередня версія майбутнього Gmail і почали до нього звикати. Тож така легка відмова багато кого засмутила. Можливо, було б краще дати Inbox розвинутися і подивитись, до чого це приведе, перед тим, як просто закрити проект.

foxbugz

5. FogBugz & Trello

https://i.postimg.cc/63vP10zL/1-u-H34if4-XA-ik-Udje-C5s3g.png

Це особливо цікавий випадок, оскільки FogBugz був продуктом Джоела Спольські: прихильника принципу «ніколи нічого не переписувати».

До появи Jira, до виникнення GitHub Issues був веб-інструмент для відстеження помилок і називався він FogBugz. Його випустила у 2000 році компанія Джоела Спольські та Майкла Прайора — Fog Creek Software.

FogBugz був основний їх продукт протягом десяти років. Спочатку його продавали лише як ПЗ для серверів, згодом зробили і версію з підпискою. Доволі популярна річ на той час.

FogBugz був написаний на класичному ASP, який працював на серверах Windows. Коли вийшов ASP.NET, Джоел не кинувся одразу оновлювати продукт. Щоб дати людям встановлювати FogBugz на серверах Linux, був написаний компілятор Thistle, що перетворював класичний ASP в PHP. До 2006 року Thistle став приватною внутрішньою мовою програмування Wasabi, скомпільованою для ASP, PHP і клієнтського JavaScript.

Дивна історія Wasabi

Навіть зараз розробка внутрішньої приватної мови програмування — це дещо ексцентричний крок. Тоді ж всі подумали, що Джоел жартує або просто з'їхав з глузду.

Спольські переконував, що це не так, він не збожеволів, а все продумав. Якщо врахувати технологічний контекст і вже готову кодову базу, то це рішення йому видавалось найрозумнішим.

Розробник Fog Creek Джейкоб Кралл згадував, що це було рішенням на перспективу: сьогодні воно вас, може і сповільнює, але завтра без нього ніяк. Та будь-які інвестиції в проект йшли зсередини компанії, за її основні доходи.

Всі нові співробітники мали довго вчити «Васабі», незалежно від їх попереднього досвіду. Всі інші мови в цей час теж не стояли на місці, а розвивалися. Тож розробники почали відчувати деяку обмеженість своїх можливостей у світі компанії.

Точка перетину

Зараз, через десять років після всього, FogBugz видається цілком зрілим і стабільним продуктом. Джоел разом з Джефом Антвудом створив Stack Overflow як його сторонній проект (і повернув собі репутацію людини зі здоровим глуздом).

FogBugz був продуктом свого часу, коли ринок баг трекерів ще був фрагментованим. А за кілька років виник Atlassian Jira, успішний проект, який стане програмою за замовчуванням, особливо для великих корпорацій.

Можливо, в цей момент Fog Creek варто було зібрати всі свої знання про розробку трекера помилок і випустити новий продукт. Та, певно, це складно, якщо засновник вважає переписування з нуля катастрофою.

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

Нова надія

Але сталося ось що: коли Fog Creek відзначила своє десятиліття, Джоел Спольські вирішив створити новий продукт. Він розділив співробітників на команди, які мали б вигадати прототип. Виграла команда, яка взяла за основу Kanban — дошку з наліпками, що допомагає планувати процес.

Так з'явився Trello.

Виявилося, з ним життя розробників стає легшим, веселішим, а робота — приємнішою. Trello покращив життя команді, тому що у нього одразу вмістили сторонні плагіни. Як казали розробники проекту:

API та плагінова архітектура тут в пріоритеті. Якщо фічу можна реалізувати за допомогою плагіну, значить там буде плагін

kanban

Звісно, програмісти одразу зрозуміли користь і зручність Trello. Та нічого специфічно програмістського там не було, тож інструмент стали використовувати для всього: планування весіль, організації харчування тощо.

FogBugz був вертикальним продуктом, розрахованим на певну категорію людей. Натомість Trello був горизонтальним — використовуй, хто завгодно і для чого завгодно. І, мабуть, це було правильно, принаймні, на думку Джоела:

Створити основний горизонтальний продукт, корисний для всіх сфер життя, — практично неможливе завдання. Ви не можете платити багато, тому що конкуруєте з іншими, більш популярними й успішними гравцями. Ризик великий, як і винагорода: для молодого стартапа це занадто, але якраз підійде для стабільної компанії з одним-двома випущеними продуктами. Як от Fog Creek.

Щоб набрати аудиторію Trello спочатку розповсюджувався безкоштовно. Платні пропозиції для бізнесу з'явились пізніше.

У 2014 році Trello став окремою компанією. Ще через три роки проект мав 17 млн користувачів і був проданий за 425 млн доларів. А купила його Atlassian, старий і запеклий ворог Fog Creek.

А тим часом…

Fog Creek працював над ще одним продуктом — середовищем для спільного програмування. Спочатку воно називалось HyperDev, потім GoMix і зрештою — Glitch. Керівництво вирішило займатися тільки цим продуктом і змінити назву компанії, так Fog Creek став теж називатися Glitch.

До речі, перший продукт компанії — FogBugz — теж перейменовували (на Manuscript), а кілька місяців тому його придбала DevFactory і повернула стару назву.

Урок № 5

Треба розуміти, що метою Fog Creek було не стільки відстежування помилок, скільки покращення життя програмістів (передовсім, його авторів):

Перш за все ми хотіли створити хороше місце роботи. Приватні офіси, польоти першим класом, робота по 40 годин на тиждень, обіди, найкращі стільці, комп'ютери тощо. Ми поділились зі світом нашою геніальною формулою: Чудові умови роботи → Чудові програмісти → Чудові програми → Профіт!

Отже, Fog Creek робила програмістів щасливими. Це позначилось і на продуктах компанії, і на її внутрішній «оперативній системі». Перший проект — трекер помилок — дав можливість запустити наступні, масштабніші й успішніші. Звісно, шкода, що для FogBugz все сталося саме так, але Stack Overflow, Trello і Glitch були варті того.

1-ufzu-Yj4q-IXXLDQMS7-Eq-Zq-Q

6. FreshBooks & BillSpring

image

Ця історія, можливо, вже трохи затягнулась, але обіцяємо, там далі буде поворот.

На початку нульових у Майка Макдермента було невеличке дизайн-агентство. Для виписок та рахунків Майкл використовував Word та Excel, тому що вважав бухгалтерське ПЗ невиправдано дорогим.

Система добре працювала, поки не перестала. І одного дня Майк вирішив написати те, що ляже в основу FreshBooks.

Він був дизайнером, а не програмістом, але йому і двом іншим співзасновникам вдалось створити достатньо хороший інструмент, за який люди платили по 10 доларів на місяць. Щоб повноцінно стати на ноги, новому бізнесу знадобилось чотири роки.

На свою десяту річницю (знайомо, еге ж?) FreshBooks був дуже прибутковим, мав 10 мільйонів користувачів і 300 залучених працівників.

Була тільки одна проблема. Коли керівники змогли найняти справжніх програмістів, у них вже були мільйони рядків готового коду. Коли сторонній аналітик поглянув на їх базу, то висновкував:

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

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

А от і поворот

Макдермент придумав створити «конкурента» для FreshBooks. І він створив абсолютно нову компанію BillSpring. Зі своїм брендом, логотипом і URL, а сторонній юрист розробив нові правила обслуговування.

Розробники керувалися книгою Lean UX: Designing Great Products with Agile Teams і запровадили Agile-практики, такі як скрам-команди й щотижневі ітерації, з оглядовими сесіями та реальними клієнтами.

Макдермент наполягав ставитись до проекту не як стартапери, а як венчурні капіталісти:

У вас є 4,5 місяці. Якщо за цей час ви вийдете на ринок, вам дадуть більше грошей. Якщо ні — нічого не буде

Команді вдалось представити MVP за кілька днів до дедлайну. Вони купили собі Google AdWords, щоб забезпечити новому сайту трафік. Запропонували безкоштовні версії на перший рік. Згодом прийшли справжні користувачі і команда взялась швидко шліфувати продукт.

Після першого безкоштовного року вони почали брати гроші з клієнтів. І в один момент подзвонив клієнт, щоб скасувати підписку на FreshBooks, тому що він переходить на продукт нової компанії. «Це був хороший день», — згадує Макдермент.

Незабаром команда розкрила карти й повідомила клієнтам BillSpring, що це був проект FreshBooks. А клієнтам FreshBooks Classic запропонували перейти на нову версію продукту (за бажанням можна було й далі використовувати стару).

1-Iuj-Ejn-Psn-JLwdga-Kh-jgog

Урок № 6

Цей таємний перезапис FreshBooks не обійшовся дешево: засновник вважає, що вони витратили близько 7 млн доларів на проект. За період більш ніж десятирічного зростання вони зібрали 30 млн венчурного капіталу; тож гроші у них були. Але так буває не з кожним.

За оцінками Forbes, FreshBooks отримали 20 млн доларів прибутку за 2013 рік. У 2017 році, після завершення оновлення, вони заробили 50 млн. Ми не знаємо, яка частка належить новому продукту, але, очевидно, що зростання компанії не сповільнилось.

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

FreshBooks пішли на все, щоб уникнути проблем, пов'язаних із переписуванням програми з нуля. Створення нового бренду не зашкодило б старому, та й розробники могли вільніше експериментувати. Найгірше, що могло б трапитись — це ще один глухий кут.

Замість висновку

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

А якщо ні?
А якщо ви хочете переосмислити функціонал? Розв'язувати проблеми у зовсім інший спосіб? Якщо старий продукт наштовхнув вас на абсолютно нові ідеї?

Наш висновок буде таким: якщо ви бачите прірву між наявним продуктом та ідеальним, то було б добре створити нову, найкращу версію поруч з попередньою і не викидати те, що у вас вже є.

Можливо, варто запитати себе: Чи варто мені створити свого ж конкурента? Якщо я маю FogBugz, що тоді моє Trello? Якщо я маю Visual Studio, який вигляд матиме VS Code? Пост Спольскі про Netscape і пост DHH про Basecamp нагадає вам: треба цінувати те, що ви створили. Хороша новина в тому, що не обов'язково руйнувати старе, аби побудувати щось нове.

Помітили помилку? Повідомте автору, для цього достатньо виділити текст з помилкою та натиснути Ctrl+Enter
Codeguida 6.3K
Приєднався: 7 місяців тому
Коментарі (0)

    Ще немає коментарів

Щоб залишити коментар необхідно авторизуватися.

Вхід / Реєстрація

Читайте також: php vs javascript, node vs php, php vs node