Netscape потеряла компанию, а FogBugz создала успешный Trello: шесть историй, когда пришлось переписать код с нуля

Перевод материала основателя компании-разработчика DevResults Херба Коудэлла.

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

Оказывается, существует больше двух способов работы с уже сложившейся кодовой базой.

Почти двадцать лет назад Джоэл Спольски написал знаменитую статью «Так делать не надо», в которой раскритиковал компанию Netscape за то, что она переписала свою кодовую базу.

Он пришёл к выводу, что работающее приложение ни при каких условиях не стоит переписывать с нуля. Спольски опирался на две идеи:

Для многих выводы Спольски стали своего рода догмой. В то время они оказали большое влияние и на меня.

Позже я ознакомился с противоположной точкой зрения — при определённых обстоятельствах больший смысл имеет переработать код с нуля.

Конечно, правильное решение этой проблемы сильно зависит от обстоятельств. Да, иногда имеет больше смысла проводить постепенный рефакторинг исходного кода. А иногда проще всё выкинуть и начать сначала.

Но есть ещё варианты. Давайте взглянем на шесть историй и посмотрим, какие уроки можно из них извлечь.

(Бонус — ASCII-рисунки с кратким пересказом каждой истории!)

Крайне неудачно переписанный код Netscape 5.0 и 6.0 благодаря Спольски стал олицетворением мантры «никогда не пиши заново».

Браузер Netscape Navigator, выпущенный в 1994 году, стал основой раннего интернета. Не прошло и двух лет с момента его выпуска, как IPO объёмом в $3 млрд запустило эру интернет-компаний.

Первым серьёзным конкурентом Netscape стал Internet Explorer от Microsoft, который вышел в 1996 году.

В начале 1998 года Netscape всё ещё был самым популярным браузером, но с небольшим отрывом. Розничная цена Netscape составляла $49, а Internet Explorer был бесплатным, и Microsoft поставляла его вместе с Windows в качестве браузера по умолчанию.

После выпуска версии Netscape 4.0 компания объявила, что версия 5.0 станет бесплатной и будет разработана с открытым кодом с помощью сообщества разработчиков, созданного и финансируемого компанией Mozilla.

Для того времени это было беспрецедентным решением, и таким бесстрашным ходом Netscape улучшила свою деловую репутацию. Однако Джейми Завински, один из первых разработчиков браузера, поясняет: «В состав проекта Mozilla входило около ста штатных и около тридцати сторонних разработчиков. Проект всё ещё полностью принадлежал Netscape».

Команда пришла к выводу, что одна из причин, почему разработчики не заинтересованы в проекте, — в существующей кодовой базе царила неразбериха.

Итак, спустя год компания решила отказаться от работы над версией 5.0 и её выпуска и начала разработку версии 6.0 с нуля.

Прошло ещё два года, и Netscape 6.0 наконец выпустили, но стало ясно, что браузер всё ещё не готов. По словам обозревателя газеты The New York Times Дэвида Поуга, браузер запускался целую минуту и занимал много памяти. К тому же в нём отсутствовали простые пользовательские функции, которые были у предыдущих поколений браузера.

Но всё это уже не имело значения. За те три года, что Netscape провёл в тишине, Internet Explorer занял долю его рынка.

В 1999 году, в разгар переписывания кода, компания AOL приобрела Netscape за $10 млрд.

А всего через два года после выпуска Netscape 6.0 всю команду Netscape, работавшую внутри AOL, распустили.

Сообщество разработчиков с открытым кодом Mozilla, которое создала Netscape, выпустило браузер Firefox в 2001 году — после очередной разработки кода с нуля. Firefox удалось забрать небольшую долю рынка у Microsoft.

Но Netscape как коммерческое предприятие прекратило своё существование (Microsoft получит остатки интеллектуальной собственности Netscape в результате сделки с AOL в 2012 году).

Выиграв эту битву, Microsoft перестала инвестировать в технологии браузеров. Internet Explorer 6.0 вышел в 2001 году и не обновлялся на протяжении ещё пяти лет, что, по мнению некоторых, было осознанной стратегией, направленной на то, чтобы остановить развитие интернета как платформы для приложений.

Некоторые утверждают, что в долгосрочной перспективе переписанный код не был катастрофой, так как в итоге он привёл к разработке движка Gecko и браузера Firefox.

Но нам пришлось пережить годы застоя веб-технологий под бесконечной, удушающей монополией IE6 в ожидании нового успешного браузера; и в конце концов, эре IE6 пришёл конец не благодаря Firefox, но благодаря Google Chrome.

В любом случае вопрос не в том, был ли переписанный код полезен интернету, а в том, было ли переписывание верным решением с точки зрения компании. Netscape оказался не у дел не только из-за кода — вердикт суда гласит, что Microsoft преднамеренно злоупотребила монопольным положением.

Но переписывание кода, несомненно, поспособствовало тому, что в итоге привело к уничтожению компании стоимостью в миллиарды долларов и нескольким тысячам увольнений. Так что здесь я соглашусь со Спольски — для интернета последствия переписывания кода оказались катастрофическими.

В начале 2000-х годов компания 37signals из Чикаго, занимавшаяся разработкой сайтов, набрала популярность за счёт влиятельного и зачастую провокационного блога её основателей Джейсона Фрида и Давида Хейнемейера Ханссона.

Когда я только начинал как веб-дизайнер, они привлекли моё внимание концептами дизайна таких сайтов, как Google и PayPal. Этот проект Фрид и Ханссон назвали 37better.

В 2004 году они взяли инструмент управления проектами, который сами разработали для внутреннего пользования, и выпустили его как облачную услугу под названием Basecamp.

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

Подписка на Basecamp стоила $50 в месяц, а простой интерфейс сервиса и упор на коммуникацию стали настоящим глотком свежего воздуха.

Проходит несколько лет, у Basecamp есть полмиллиона довольных пользователей, прибыль поступает каждый месяц, а Джейсону и Давиду не сидится на месте.

Я видел, как Давид рассказывал эту историю несколько лет назад на конференции Business of Software. Он сказал, что Джоэл Спольски убедил его в том, что полная переработка кода убьёт компанию. Основатель Basecamp, вдохновлённый методологией Agile, был излишне уверен в собственной правоте.

После, по его словам, «семи жирных лет», компания всё же оказалась в безвыходном положении — и дело было не в технических недоработках.

Всё началось с того, что основатели почувствовали отсутствие энтузиазма. Проблема состояла не только в том, что у них не было мотивации работать над своим ведущим продуктом, но они сами не пользовались им столько, сколько раньше.

У них было много вариантов, как сделать продукт намного лучше, но, когда от Basecamp зависит рабочий процесс сотен тысяч людей, каждое изменение оказало бы негативное влияние на большое количество пользователей. Оказалось, что препятствием для изменений была не чрезмерно сложная кодовая база, а пользователи.

Тот факт, что компания сосредоточила своё внимание на том, чтобы сохранять и удовлетворять существующую клиентскую базу, тормозило продукт и не давало возможности заинтересовать новую аудиторию. Проблема не требовала немедленного решения, но представляла собой угрозу в долгосрочной перспективе. Давиду это казалось похожим на попытку наполнить дырявое ведро.

Проблема частично состоит в том, что ты всегда получаешь отзывы от существующих потребителей, но не от потенциальных.

Разработчики начали относиться к своему продукту как к паре золотых наручников.

Спойлер: переписали Basecamp с нуля, и всё получилось. Весь процесс занял примерно год, и количество новых пользователей увеличилось в два раза сразу после выпуска Basecamp 2.

По моему мнению, у них всё получилось благодаря двум интересным решениям.

Во-первых, разработчики не пытались заново создать тот продукт, который уже есть, потому что были новые решения для проблем.

Так что они представили Basecamp 2 как полностью новый продукт, не обещая совместимости с предыдущей версией Basecamp Classic. Появилось много нового, некоторые функции исчезли, а что-то полностью изменилось.

Такое решение дало определённую свободу. Свобода мотивирует, а мотивированным людям проще достичь целей.

Отсутствие необходимости в поддержке каждого варианта использования оригинального продукта тоже дало больше времени. Например, первая версия Basecamp позволяла пользователям хранить документы на их собственном FTP-сервере.

Убрав эту функцию, как и другие, которые раньше были полезны с точки зрения бизнеса, но сейчас потеряли актуальность, компания потратила меньше времени на подготовку нового продукта к реализации.

Но что стало с сотнями тысяч активных пользователей? Здесь разработчики придумали второе интересное решение — они не свернули уже существующий продукт.

Дэвид некоторое время размышлял о «прикрытии» программ.

Ханссон обращает внимание на то, что с точки зрения стратегии нет ошибки хуже, чем заставить пользователей собраться и уйти — потому что все активные пользователи вынуждены задуматься, а хотят ли они и дальше пользоваться вашей программой или им нужно что-то другое.

Вместо закрытия сервис Basecamp решил «отдать должное наследию». Стартап сделал процесс обновления простым, но не обязательным. Помимо этого, пообещал бессрочно технически поддерживать и обеспечивать Basecamp Classic.

Самое интересное — компания проделала это ещё раз: в 2015 году вышел Basecamp 3, написанный с нуля. В обновлённом сервисе сервисе появились новые функции, исчезли или изменились старые.

Как и в прошлый раз, пользователи старых версий могли легко обновиться либо продолжать использовать Basecamp Classic или Basecamp 2 «до тех пор, пока существует интернет».

Лично меня такая модель очень вдохновляет.

Каждая переработка кода позволяла компании Basecamp возвращаться к проектным решениям и создавать продукт, который она хотела создать ранее.

Для пользователей это идеальная ситуация: те, кто не любит изменений, не будут устраивать бурю в стакане, а те, кто натыкается на ограниченную функциональность продукта, получают возможность работы с новым, улучшенным приложением.

Бессрочно поддерживать несколько версий продукта довольно затратно. Но как говорит Ханссон: «Это стоит денег. С чего бы этому быть бесплатным? Это ценно, поэтому, конечно, не бесплатно. Но этого того стоит».

Компания Microsoft создала редактор VS Code, чтобы наладить контакт с разработчиками, работающими на других платформах.

Следует помнить, что на протяжении долгого времени работа с Microsoft подразумевала отсутствие выбора. Если вы пользовались Visual Studio, то могли работать только на платформе .NET, и наоборот. Такой подход разделил сообщество программистов на два больших и по большей части полярных лагеря, что негативно отражалось на всех.

Всё начало меняться ещё во времена Стива Балмера — вспомните, какой переполох был, когда команда ASP.NET решила не обновлять jQuery!

Одной из главных задач, которые генеральный директор Сатья Наделла поставил перед Microsoft, стало прямое привлечение разработчиков, находящихся вне золотой клетки компании.

Но вот что говорит Джулия Люсон, вице-президент Visual Studio, в одном из эпизодов подкаста The Changelog.

Visual Studio — продукт тяжеловесный во всех смыслах этого слова: его установка может занимать до получаса. Он должен поддерживать широкий спектр сложных сценариев использования, на которые полагаются корпоративные клиенты. Так что стараться привлечь другие платформы, используя Visual Studio в качестве отправной точки и добавляя функции, для Microsoft не имело никакого смысла.

Поэтому Microsoft начала с нуля, без каких-либо гарантий совместимости с предыдущей версией.

Вернее, не совсем с нуля: некоторые важные части уже были у Microsoft, например, браузерный редактор Monaco. А так как VS Code — приложение Node.js (написанном на TypeScript и работающим на базе Electron), компания могла воспользоваться развитой инфраструктурой JavaScript.

У VS Code открытый исходный код, он мало весит, быстрый и позволяет подключать расширения; а также — что удивительно для продукта Microsoft — он стал средой разработки кода, которую выбирают популярные ребята.

Оба продукта всё ещё находятся в активной разработке, и ничто не указывает на то, что Microsoft собирается закрывать Visual Studio.

В отличие от Netscape, компании Microsoft удалось создать активное сообщество разработчиков с открытым кодом вокруг VS Code. Это сообщество приумножает результаты работы внутренней команды разработчиков.

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

Но если открытый код — часть стратегии развития, возможно, имеет смысл сравнить эти два примера, чтобы понять, какое из действий Microsoft привело к развитию такого сообщества.

Ещё одним положительным моментом является то, что Microsoft снабдила VS Code надёжной моделью для расширения, в результате чего сообществом было написано более десяти тысяч расширений.

Финальный вывод, который можно сделать из истории VS Code, — за последние несколько лет мир изменился таким образом, что сейчас проще, чем когда-либо, создавать как программное обеспечение, так и его модели.

Несмотря на причитания по поводу сложности настоящего пакета инструментов, нет сомнения в том, что за последние годы инфраструктура JavaScript превратилась в долгожданную Землю обетованную для открытого модульного кода, который можно использовать многократно. Это уникальное время.

Приложение Inbox для Gmail было изначально представлено в качестве упрощённой альтернативы пользовательского интерфейса Gmail, «созданного только для того, что действительно важно». Его функциональность отличалась от функциональности Gmail, предлагала новые инструменты — такие как объединение писем в папки, закрепление писем и возможность поставить повторное оповещение о входящем письме.

Некоторые, включая меня, с энтузиазмом восприняли создание Inbox. Я всегда полагал, что Inbox был моделью того, чем в будущем станет Gmail, и смирился с отсутствием у Inbox некоторых функций Gmail, ожидая, что они рано или поздно появятся и в Inbox.

И Inbox, и Gmail использовали одинаковый бэкенд. Это было одно и то же, но с разными интерфейсами, между которыми можно было переключаться. У этого были как плюсы, так и минусы: если у Inbox отсутствовала какая-либо функция (например, автоматический ответ на входящие письма, когда вы уходите в отпуск), всегда можно было зайти в Gmail и сделать это там. Но переключаться туда-обратно не очень удобно.

Однако через какое-то время Inbox перестал улучшаться, и стало понятно, что Google прекратила тратить на него ресурсы. И действительно, по прошествии четырёх лет с момента запуска Google объявила, что проект Inbox закрывается.

Сначала это меня очень разозлило, но когда я потратил немного времени на знакомство с последней версией Gmail, то обнаружил, что многие функции перекочевали из Inbox в исходный продукт: функция Smart Reply, действия при наведении и встроенные вложения и картинки. Несколько папок для входящих сообщений у Gmail стали достойной заменой объединению писем в папки в Inbox.

Но в Gmail переместились не все функции: функция повторения оповещения, к примеру, была очень важной для многих людей, которые спланировали своё использование почты с её помощью; закрытие Inbox оставило их у разбитого корыта.

Приложение Inbox дало команде Gmail возможность экспериментировать с функциональностью, не нарушая рабочие процессы подавляющего большинства пользователей, которые выбрали не переключаться на приложение.

Несмотря на это, сохранив обе версии и используя одинаковый бэкенд, Gmail ограничил собственную возможность привнести что-то новое.

На Google в очередной раз обрушился шквал критики за закрытие популярного сервиса. Но Google все время закрывает разные продукты, так что чего ещё мы могли ожидать.

Google заставила нас поверить, что нам представилась ранняя возможность посмотреть на будущее Gmail. Как сказал бы Давид Хейнемейер Ханссон, это не было «красивым закатом». Многим людям было крайне неудобно возвращаться к старому продукту и расставаться с прогрессивной организацией рабочего процесса в Inbox.

Я думаю, что недовольства было бы меньше, если бы Gmail полностью включил в себя функции Inbox перед его отключением.

FogBugz особенно интересен, так как это продукт Джоэла Спольски, и он даёт нам представление о том, как принцип «никогда не переписывай код» работает с реальным продуктом.

До Jira и GitHub Issues существовал веб-продукт для отслеживания ошибок под названием FogBugz. Выпущенный в 2000 году сервис стал первым продуктом компании Fog Creek Software, фирмы, которую Джоэл на тот момент недавно основал вместе с Майклом Прайором.

На протяжении более десятка лет этот продукт был флагманским. Первоначально он продавался в упаковке для установки на пользовательских серверах, но впоследствии выпустили облачную версию по подписке.

Продукт стал популярным, особенно в среде разработчиков, которые, как и я, читали блог Джоэла и прислушивались к его советам. Моя компания использовала его многие годы; для своего времени это был отличный продукт.

Изначально FogBugz был написан на основе ASP, который работал на серверах Windows. Когда вышел ASP.NET, Джоэл объяснил, почему не хочет торопиться с обновлением.

Чтобы позволить устанавливать FogBugz на сервера Linux, стажёр написал компилирующую программу Thistle для преобразования классического ASP в PHP. К 2000 году Thistle превратился в особый язык собственной разработки под названием Wasabi, который мог выполнять компиляцию в ASP, PHP и клиентский JavaScript.

В наше время разработка собственного языка программирования и компилятора — это странное решение. Так что позвольте мне небольшое лирическое отступление, чтобы всё объяснить.

Однажды Спольски как бы между прочим упомянул Wasabi в конце материала в блоге. Некоторые посчитали, что он пошутил, и тогда он пояснил, что нет, это не шутка. Это взволновало его коллегу-блоггера Джеффа Этвуда.

Тем не менее Спольски продолжал утверждать, что с точки зрения бизнеса это целесообразно: конечно, создавать свой язык не имеет смысла, если ты начинаешь с чистого листа. Но если посмотреть на каждое решение на пути создания продукта, учесть технологический контекст на тот момент и кодовую базу, которая у компании уже была, становится понятно, как она пришла к такому решению.

В своей статье под названием «Технический долг и путь против ветра» бывший инженер Fog Creek Тед Унангст сравнивает этот процесс с попыткой пройти неизвестный путь без карты.

Как бы то ни было, Джейкоб Кролл, ещё один бывший разработчик Fog Creek, объясняет, что это решение принято против скорости работы разработчика сегодня и в пользу лёгкости в сопровождении программы завтра, что является определением технологического долга. И к 2010 году настало время оплатить счёт за эту задолженность.

По прошествии десятилетия FogBugz был зрелым и стабильным продуктом. Спольски также создал Stack Overflow вместе с Джеффом Этвудом (смею предположить, что к тому времени взорвавшийся мозг Этвуда восстановился).

FogBugz постепенно начал устаревать. Хотя рынок систем для отслеживания ошибок всё ещё был разбит на отдельные сегменты, Jira от компании Atlassian, вышедшая через пару лет после FogBugz, стала выбором по умолчанию, в особенности у крупных корпоративных пользователей.

Мне очень интересен этот переломный момент в истории компании Fog Creek. Как и в случае с Basecamp, у компании имелся зрелый продукт, который приносил прибыль, но больше не был в новинку, и с ним не было интересно работать. Как бы то ни было, он воплощал в себе годы технологических сдвигов и эволюцию возможных решений конкретной проблемной области.

Возможным решением было бы поступить так, как поступила Basecamp: взять всё, что компания Fog Creek узнала об отслеживании ошибок, и изобрести FogBugz заново, начиная с чистого листа.

Я полагаю, что эта идея успеха не возымела — «то, что делать нельзя», «худшая стратегическая ошибка» и так далее, и тому подобное.

Недавно я натолкнулся на статью 2009 года, которую Спольски написал, когда вёл ежемесячную колонку в журнале Inc. Magazine. Стиль его статьи «Медленный рост — это медленная смерть?» отличается от его обычной самоуверенной бравады — он более интроспективный, осторожный, полон сомнений.

Он переживает из-за быстрого роста компании Atlassian, размышляя над тем, неужели на рынке программ для отслеживания ошибок есть место только для одного продукта.

В итоге он решает сделать две вещи. Во-первых, добавить все возможные функции в FogBugz.

Во-вторых, нанять специалистов по корпоративным продажам. Спольски признаёт, что в этой области он не силён и заниматься продажами ему претит.

Я не знаю, что вышло из этого плана. Последняя запись о FogBugz в его блоге — поверхностное упоминание о промежуточной версии, сделанное несколько месяцев спустя.

Вот что произошло.

Так что разработчики разделились на команды по два человека в каждой, и эти команды начали работать над идеей и прототипом нового продукта.

Идея, одержавшая победу, была вдохновлена канбан-доской — приспособлением, которое часто используется в разработке программного обеспечения, обычно состоящее из белой доски, разделённой на колонки, в каждой из которых размещаются самоклеящиеся листочки.

Спольски представил её как улучшенную по сравнению с FogBugz программу для организации работы.

Создавая Trello, разработчики компании Fog Creek получили возможность работать с современными технологиями.

Ещё Trello дал больше власти командам с собственными разработками, с самого начала разрешив внедрение сторонних плагинов.

Программистам Trello сразу же пришёлся по душе; но в продукте не было ничего, специально созданного для разработки программного обеспечения. Спольски говорил, что сервис будет полезен для любой работы, требующей создания списка списков для большого количества людей. Trello начали использовать для организации всего: от ужинов и свадеб до работы приюта для животных.

В отличие от FogBugz, который создавали для узкоспециализированного рынка, Trello может использовать кто угодно для чего угодно. Спольски утверждает, что такая смена курса была правильным решением на этом этапе развития компании.

Чтобы быстро набрать большое количество пользователей, сначала Trello был бесплатным. Позже появилась возможность подключить платный премиум-аккаунт.

В 2014 году из Trello создали отдельную компанию. Три года спустя количество пользователей перевалило за 17 миллионов, и Trello продали за $425 млн. По иронии судьбы покупателем оказалась Atlassian, старинный враг Fog Creek.

Компания Fog Creek создала систему для совместной разработки, которая сначала называлась HyperDev, потом GoMix, а затем Glitch.

А FogBugz в это время прозябал в забвении. В 2017 году кто-то решил, что FogBugz — дурацкое название, и сменил его на Manuscript, проведя вместе с тем технические работы и ребрендинг. Год спустя, всего несколько месяцев назад, Fog Creek продал своё детище небольшой компании под названием DevFactory, которая первым делом вернула название FogBugz.

Под началом генерального директора Анила Дэша Fog Creek стала поддерживать только один продукт и сменила своё название на Glitch.

На меня эта история произвела сильное эмоциональное впечатление.

Ключевой момент здесь — что компания Fog Creek хотела не столько помогать отслеживать ошибки, сколько поддержать программистов, в первую очередь своих.

Пользуясь этой «формулой», история становится более последовательной и вдохновляющей: бизнес Fog Creek ориентировался на удовлетворение потребностей разработчиков. Это было заметно и в продуктах компании, и во внутренней системе управления. Первый продукт, программа для отслеживания ошибок, стал основой для нового, который решает похожие проблемы, но в гораздо больших сферах деятельности.

Если посмотреть на ту историю создания Trello, которую рассказывает Спольски, то становится понятно, что он не просто искал перспективы развития бизнеса, а скорее хотел сохранить энтузиазм и мотивацию разработчиков Fog Creek. По счастливой случайности получился продукт стоимостью в полмиллиарда долларов.

Но меня всё равно расстраивает судьба FogBugz. Не думаю, что разработчики были очень довольны, став свидетелями последних дней продукта в их компании.

Конечно, у всех были дела поважнее: Stack Overflow, Trello и Glitch оказались намного более полезными и ценными, чем FogBugz; да и нельзя успеть всё сразу. Поэтому в потере интереса к FogBugz, его двадцатилетней кодовой базе и маленькому, но конкурентному рынку сбыта некого винить. Да и преданным пользователям не пришлось переживать «закат», они получили новый хороший продукт!

Однако романтик во мне хотел бы, чтобы «сохранению наследия» всех людей, которые работали над этим продуктом и пользовались им столько лет, уделили больше внимания.

Эта статья уже и так намного длиннее, чем я планировал, но я не могу не рассказать эту историю. Не отвлекайтесь, вас ждёт неожиданный сюжетный поворот.

В начале 2000-х годов у Майка МакДермента была небольшая дизайнерская компания. Он делал счета на оплату при помощи Word и Excel, полагая, что программы для бухгалтерского учёта слишком сложные для его запросов.

Такой способ работал, пока не перестал.

Майк был дизайнером, а не программистом, но вместе с двумя соучредителями он смог собрать вполне неплохую программу, за использование которой несколько человек были готовы платить $10 в месяц. Только по прошествии четырёх лет бизнес начал приносить достаточно прибыли, чтоб Майк смог съехать от родителей.

Когда компании исполнилось десять лет (знакомо звучит?), FreshBooks приносила стабильную прибыль, имела свыше десяти миллионов пользователей и триста сотрудников.

Оставалась одна проблема: когда она смогла позволить себе нанять программистов-профессионалов, у компании был миллион строк кода, написанного основателями. Приглашённый аналитик изучил кодовую базу и сделал следующий вывод.

Что ещё более важно, разработчики хотели претворить в жизнь новые идеи, которые существующий продукт не потянул бы.

МакДермент придерживался общепринятого мнения по поводу переписывания кода с нуля.

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

В итоге МакДермент принял решение тайно создать «конкурента» FreshBooks.

Он зарегистрировал новую компанию под названием BillSpring в Делавере. У новой компании были свой сайт, свой бренд и логотип. Чтобы ничто не связывало две компании, он попросил внештатного юриста составить новое пользовательское соглашение.

В качестве руководства команда разработчиков воспользовалась книгой Джеффа Готелфа и Джоша Сайдена «Метод Lean-UX: как создать хороший продукт с помощью Agile-команды» и внедрила методы Agile, такие как Scrum-команды, еженедельные спринты с обзорными совещаниями вместе с реальными пользователями. МакДермент сказал сотрудникам относиться к себе как к стартапу, а к нему как к венчурному инвестору.

Команда успела закончить создание продукта с минимальной функциональностью за несколько дней до дедлайна. Купила Google AdWords, чтобы привлечь трафик на новый сайт. На первый год предоставила бесплатные аккаунты. Прошло немного времени — и у команды появились реальные пользователи, и она начала доводить продукт до совершенства.

После года работы подписка на BillSpring стала платной. Однажды стартап неожиданно убедился в эффективности продукта.

Вскоре разработчики приоткрыли завесу тайны: объяснили пользователям BillSprings, что этот продукт стал заменой FreshBooks, а пользователям FreshBooks скоро станет доступна новая версия.

Клиентам FreshBooks начали приходить предложения попробовать обновление. Но оно было необязательным: если не понравится, можно вернуться к прежней версии.

Тайное переписывание кода обошлось FreshBooks недёшево: МакДермент утверждает, что компания потратила на проект $7 млн. После десяти лет последовательного роста она заработала $30 млн предпринимательского капитала, так что средства на это были. Но не все могут позволить себе такие расходы.

По оценкам Forbes, выручка FreshBooks за 2013 год составила $20 млн. В 2017 году, после обновления, она составила $50 млн. В компании не раскрывают, какой процент от выручки пришёлся на новый продукт, но разработка точно не замедлила рост.

МакДермент добавляет, что теперь разработчики могут быстрее и проще добавлять новые функции. Ещё более важно то, что в будущем продукт сможет воплотить лучшие идеи.

Помимо целей, которых они добились, сотрудники заметили, что этот опыт привёл к позитивным изменениям в корпоративной культуре компании. То время, которое они «притворялись» стартапом, заставило относиться к компании как к стартапу. Lean-методика распространилась на всю техническую команду. Теперь пользователи максимально вовлечены в разработку новых функций.

FreshBooks сделала всё возможное, чтобы оградить себя от негативных последствий переработки кода: привнося инновации в новую компанию, разработчики не боялись придумывать новые вещи и идти на большие риски. Худшее, что могло случиться, — они зайдут в тупик, но не повредят уже существующему продукту.

Возможно, такой подход кажется слишком радикальным, а на самом деле нет необходимости заходить так далеко. Но он показывает, как высоки ставки.

Большинство компаний считает, что полной переработки кода стоит избегать, вместо этого лучше понемногу последовательно вносить улучшения.

В целом я согласен с этой точкой зрения.

Однако она подразумевает, что конечная цель — сохранение оригинального продукта с добавлением в него нескольких новых функций.

Но что, если вы хотите убрать функции? Или создать другой сценарий использования? А если благодаря опыту взаимодействия с продуктом вам пришла в голову идея совершенно нового подхода?

Из всех этих историй я извлёк вот что: когда вы поняли, что между той версией продукта, которая сейчас у вас на руках, и потенциальной лучшей версией продукта есть отличия, тогда правильным подходом будет не замена программы её новой версией, а создание другого продукта на её фоне, не избавляясь от того, что у вас уже есть.

Итак, вместо того чтобы размышлять над тем, стоит переписывать код или нет, посмотрите на свой продукт и спросите себя: «Может, лучше создать себе конкурента? Если мой продукт — FogBugz, то где мой Trello? Если мой продукт — Visual Studio, как бы выглядел мой VS Code?».

Если вы прочитаете материал Спольски про Netscape, а затем — текст Давида Хейнемейера Ханссона про Basecamp, вы увидите, что в одном их мнения сходятся — то, что вы создали, обладает ценностью.

Хорошие новости: вам не надо избавляться от этой ценности, чтобы привнести в продукт что-то новое.

#netscape #basecamp #microsoft #trello