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

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

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

More than two years ago my business partner and I discussed launching a hosted version of my ASP.NET invoicing software, DotNetInvoice.

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

We developed the plan and a task list, and estimated the effort at around 160 hours including development time needed to make DotNetInvoice a multi-tenant application. But given the heavy competition in the hosted invoicing software market and the level of effort of the task, it was continually placed on the back burner.

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

Until we figured out how to get to the same endpoint with 10 hours of work.

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

The Shearing

Стрижка

After our initial 160 hour estimate, every six months or so for the past two years we’ve revisited the idea of a hosted version until one day in November of last year. On this day we came to the realization that we didn’t need to make DotNetInvoice multi-tenant in order to have a hosted version. The other invoicing players are multi-tenant because they coded their invoicing services from scratch, but it’s not the only way to do it.

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

The more we thought about it we realized the benefits to keeping it a single-tenant application: the ease of migrating from our hosted version to a downloaded version, and keeping each customer’s data separated in its own database to name two.

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

The interesting thing is that once that large task was removed from the list, other things to started to fall off, as well. At this point we begin looking at the launch of Hosted DotNetInvoice as a market test; to see if we could build enough of a customer base to warrant a major investment in the hosted invoicing market space. With that in mind, things started flying off our “must-have” list.

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

The next largest piece was automating sign-up and provisioning of a new hosted installation. In an ideal world, when a customer wants a new hosted account they would fill out a web form with all of their information and their new hosted version would be ready in 30 seconds. But that amount of automation – given the fact that we have to create a new sub-domain, a new database, and copy physical files – would take a substantial amount of time to develop and QA. So we tossed it.

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

The final thing we threw out was the need for a custom purchase page. A page where someone enters their details to make the purchase. In a desperate attempt to bring this entire project down to less than two days work we simply utilized PayPal subscriptions. Not the most professional approach, but it works very well for testing out the idea before we invest another day into this project.

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

Iteration vs. Automation

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

Now as a developer, the features I mentioned above seem like a necessity from day. Not automating this process creates the ongoing repetitive work that computers are designed to handle. Aaaaah, manual work…this is what computers are supposed to save us from!

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

In essence, this approach does not scale infinitely, which tends to be the kind of scaling that developers default to (this includes me).

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

But by getting over the need to automate everything to infinite scale and putting myself in charge of manually creating new hosted accounts, the time investment to get this feature launched dropped from 160 hours of work to about 10 hours.

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

I can hear the cries of developers around the world as I write this: “You can’t launch a half-baked solution! You’ll never go back and fix it!”

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

Most of us have worked in corporate environments where you’re never allowed to go back and refactor code. This burns into our psyche that you don’t want to launch a semi-functioning solution because you’ll never have time to go back and fix it.

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

But the benefits of being my own boss and being a tiny software company, are that I can come back to this anytime. In fact, the more times I do it manually (since I’m handling it myself), the more motivation I will have to automate it. Add to that, the more I develop and streamline my manual process, the easier it is to automate it later using code. Having more experience with the process will actually mean I can code it faster.

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

And ideally, by the time I code it up, we’ll have many customers using the platform which means I’ll be working on a product I know is viable, and that’s paying for the time I’m spending to automate it.

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

Agile Development, meet Agile Business.

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

Know Where it Ends

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

Through a bit of manual labor, or better yet some delegation and outsourcing, you can get to market with less up-front expense and in dramatically less time than if you try to automate everything.

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

But the number one question you need to think about when going after this Agile Business approach:

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

At what point is it worth spending the time to truly automate this?

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

In other words: how many sales do you need to make in order to justify the time and effort to write the code to automate this process?

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

Without a number in mind you run the risk of never wanting to invest the time to automate, and becoming hostage to a bunch of half-baked manual processes. At some point you have to automate the process or kill the feature…know that point before you start.

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

The Best Code I Ever Wrote

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

Had we chosen to automate everything, the worst outcome would have been investing 160 hours of time (as a Micropreneur that’s a huge amount of time), and then scrapping the whole thing. When you’re working on such a small scale you can’t afford to throw away that much time.

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

But whether you’re working as a corporate developer or a Micropreneur:

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

The best code you’ve ever written is the code you never had to write

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