Другая сторона внешней разработки

«Имея в своём распоряжении 100 долларов, стремясь добиться успеха, сумел построить организацию с валовым доходом свыше двух миллиардов долларов» - из книги Н. Хилла. Возможно, каким-то способом, который лежит где-то там между первым и последним словом цитаты, компании занимающиеся разработкой на заказ тоже достигают внушительных оборотов с минимум вложений.

Они предоставляют команды, создающие вместе с клиентом продукты и по цене, как если просто платить разработчикам з.п. Это заманчиво, ни многочисленных собеседований, ни выплат КА за подбор, ни выстраивания сложных систем мотивации. Поработали и разошлись, или даже можно в любой момент отказаться от кого-то, а хоть даже и от всех сразу.

Если спросить прямо у такой компании, как у них выходит, держать столь интересные условия, то будут сказаны варианты, наподобие, что люди из абстрактного Брянска, где з.п. ниже Москвы, Питера, Пало-Альто и вот мы такие молодцы их берём. И не то чтобы это совсем не так.

Потом бывают вопросы вроде:

Почему после исправления багов в новом релизе все стало ещё хуже?

Как вышло, что ни кто не хочет поддерживать ваш код, говорят заново все писать надо?

На что потрачено столько денег и главное времени?

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

Модель 1.

Интенсивный путь развития.

Берём нужного разработчика, лучше синьора, хорошо, чтобы он был амбициозным и ставим его на несколько проектов. Один проект не приносит прибыли, с таким-то ценообразованием. Два уже что-то. Обычно дают 2-4 full-time проекта одновременно. Конечно заказчику говорят, что человек полностью работает на него, вот отчёты и прочее.

Такой человек пашет по 12 часов 6 дней в неделю в среднем на 3-ех проектах. На проект у него уходит 4 часа, вместо 8, т. е. в два раза меньше. Получает такой разработчик хорошую сумму, ну скажем вместо 200к получает 300к в месяц.

К чему это все приводит? Тут как бы ясно к чему. Работа идёт медленнее, разработчики уставшие, участвуют одновременно в многих проектах, до обеда один, после обеда другой, вечером третий или сразу одновременно. Все по Scrum Guide, который обычно чтут в таких организациях: «они самоуправляемы, то есть сами решают, кто, что, когда и как делает». Креатив, вовлеченность, ответственность падают, куда там, ведь ещё пара проектов, о них тоже нужно думать. Все еле движется. Заказчик пытается ускорить, но ускорять некуда, да и он не единственный пытается. И все таким образом как-то куда-то едет.

Модель 2.

«Купи дешевле, продай дороже» - распространённая идея бизнеса.

Чтобы бы такого купить на перегретом рынке труда, где хороших разработчиков «днём с огнём» не сыщешь?

Рынку нужны синьоры и по адекватным ценам. Собственно берут мидлов, делают из них синьоров. Мидлы то есть. И делают у них все, как у синьоров, кроме з.п. Более того, часто бывает им не говорят о такой подмене и они прибывают в счастливом неведенье, считая что оценили во всем, кроме денег, ну, наверное, жадные. Замечу лишь, что опыт на такой работе идёт хороший и со временем разработчики дорастают, а там и з.п. хотят соответствующую. Отличить синьора от мидла, без собеседования сложно, да можно сказать это условность все, в том или ином виде. Только в командах, где вы думаете, что все синьоры, а на деле мидлы (мы берём мягкий вариант), со временем возникают проблемы. Обычно это выражается в обилии задач спринта об исправлении очередного бага. Когда таких задач более 80% продукт развивать бесполезно и это становится видно даже самому далёкому от разработки заказчику.

Про жёсткий вариант, с Full-stack Senior Developer по $5 в час рассказывать не буду. Приведу один совет из другой, так сказать отрасли:

«Если, к примеру, пёс старый и седой, а вы хотите продать его за годовалого щенка или выдать такого дедушку за девятимесячного, то лучше всего купите ляпису, разведите и выкрасьте пса в чёрный цвет - будет выглядеть, как новый. Чтобы прибавилось в нем силы, кормите его мышьяком в лошадиных дозах, а зубы вычистите наждачной бумагой, какой чистят ржавые ножи.» - предприимчивый Й. Швейк.

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

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

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

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

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