From 160 Hours to 10: A Tale of Agile Business Practices | Rob Walling

От 160 часов до 10: история о гибких бизнес-практиках

Более двух лет назад мы с моим бизнес-партнёром обсуждали запуск хостинговой версии моего ASP.NET приложения для выставления счетов, DotNetInvoice.

Мы разработали план и список задач и оценили объём работ примерно в 160 часов, включая разработку, необходимую для того, чтобы превратить DotNetInvoice в мультитенантное приложение. Но из-за жёсткой конкуренции на рынке хостингового ПО для выставления счетов и трудоёмкости задачи проект постоянно откладывался в долгий ящик.

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

Стрижка

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

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

Интересно, что как только эта крупная задача исчезла из списка, следом начали отпадать и другие. На этом этапе мы начали рассматривать запуск Hosted DotNetInvoice как рыночный тест — чтобы проверить, сможем ли мы собрать достаточно большую клиентскую базу, чтобы оправдать серьёзные вложения в нишу хостингового ПО для счетов. С учётом этого пункты начали стремительно вылетать из нашего списка «обязательного».

Следующим по величине куском была автоматизация регистрации и провижининга новой хостинговой установки. В идеальном мире, когда клиент хочет новый хостинговый аккаунт, он заполняет веб-форму со всеми своими данными, и его новая хостинговая версия готова за 30 секунд. Но такой уровень автоматизации — учитывая, что нам нужно создать новый поддомен, новую базу данных и скопировать физические файлы — потребовал бы существенного времени на разработку и тестирование. Поэтому мы от него отказались.

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

Итерация против автоматизации

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

По сути, такой подход не масштабируется бесконечно — а именно к этому виду масштабирования разработчики и склонны по умолчанию (включая меня).

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

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

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

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

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

Agile-разработка, знакомься: Agile-бизнес.

Знай, где это заканчивается

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

Но вопрос номер один, о котором нужно подумать, выбирая этот подход Agile-бизнеса:

В какой момент действительно стоит потратить время на полноценную автоматизацию этого?

Иными словами: сколько продаж тебе нужно сделать, чтобы оправдать время и силы на написание кода, автоматизирующего этот процесс?

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

Лучший код, который я когда-либо писал

Если бы мы решили автоматизировать всё, худшим исходом было бы вложить 160 часов времени (а для микропренёра это огромное количество времени), а затем выбросить всё это на помойку. Когда работаешь в таком небольшом масштабе, ты не можешь позволить себе выбрасывать столько времени.

Но независимо от того, работаешь ли ты как корпоративный разработчик или как микропренёр:

Лучший код, который ты когда-либо писал, — это код, который тебе не пришлось писать