Про деревообрабатывающую промышленность

Часто в работе сталкиваюсь с двумя типами программистов: лесорубы и плотники. Первые умеют махать топором, способны быстро “вырубить” приблизительный образ системы и грубыми взмахами получить как-то работающий результат. Вторые качественно полируют напильником и наждачкой код, пока он не будет работать стабильно.

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


В общем в самом начале лесоруб приходится как нельзя кстати. Накидать пару экранов в мобилке с точками на карте? Xamarin! Стук-стук-стук. Нужно оформлять заказ на сайте? Нет ничего проще: конструктор интернет-магазинов! Вжик-вжик-вжик.

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

Что происходит, когда первые пользователи начинают давать обратную связь и требовать чтобы сервак не ложился под натиском хотя бы десятка посетителей? Лесоруб будет менять пилу фреймворк, объясняя это тем, что вот этот новый подход уж точно поможет разрабатывать быстро, стабильно и без ошибок. База не справляется? Давайте хранить данные в xml-файлах. Под Ruby сложно найти себе помощника? Перепишем все под Erlang. И так далее. Лесорубы во всем пытаются получить быстрое решение здесь и сейчас, ничуть не волнуясь о том что будет потом. Иногда могут говорить про что-то из YAGNI в подтверждение своих слов. Построить что-нибудь из разряда highload под управлением лесоруба у вас вряд ли получится. Когда система будет переписана чуть более чем полностью в третий раз, будет уже слишком поздно для бизнеса.

А что же плотник? Такой приходит на проект со своим набором подходов и инструментов в бархатной коробочке. Он отлично в них разбирается. Он не раз применял их на практике и знает, что делает.

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

Конечно же нужно с самого начала придерживаться TDD и работать по общепринятым паттернам. Конечно же это требует дополнительного времени. “Конечно же здесь давайте применим вот этот фреймворк, потому что он уже не раз выручал”. Ширк-ширк-ширк напильником. “Ну и что, что нам придется вручную пробрасывать вызовы между серверными нодами. Зато это будет работать быстро, когда на сайт зайдут 100500 пользователей одновременно”. Фух-фух-фух наждачкой.

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

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

На самом старте, когда непонятно взлетит/не взлетит, обращайтесь за помощью к лесорубу. Таким образом вы проверите гипотезу очень быстро и не потеряете много денег и времени в случае чего. Если на ваш сайт начали приходить все более и более требовательные пользователи, приглашайте на проект плотника. Он доведет проект до более стабильного состояния.

Вопрос лесоруба и плотника нужно учитывать также при обсуждении опционов и других юридических вопросов. Если вы стартуете с лесорубом, скорее всего вам будет не по пути уже через год. В этом плане стартовать с плотником как-то надежнее. Только жестче договаривайтесь об MVP и сроках в таком случае.

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

В общем с кем начинать или продолжать проект - решать вам, а мне осталось только порекомендовать почитать про породы программистов в книге “Как пасти котов”.

Фото pixabay.com