Капитанский ответ - потому что таков рынок труда в IT. Минцифры в феврале 2021 года сообщили о нехватке от полумиллиона до миллиона IT-специалистов. Но это плохой ответ. Потому что он не дает пищи для размышлений на тему что делать?. Хороший ответ в том, что затраты на них - это капитальные, а не операционные затраты. Нет, я не призываю вас выгонять их из штата в договорные отношения, где они будут подписываться под возврат инвестиций. Пусть бухучет останется как есть. Вопрос в другом - в управлении.

Кто среди ваших сотрудников системно работает на то, чтобы повысить выручку и/или снизить издержки? Весьма вероятно, что это только вы сами. Остальных вы нанимали для того, чтобы было кому делать операционные задачи. По простому говоря - крутить бизнес. Даже руководители вплоть до ТОП-уровня. Их можно привлечь к инвестиционной деятельности, но это не будет их основной работой. Однако, разработчики (и в целом IT-шники), это пожалуй единственные люди, которые нанимались в первую очередь для того, чтобы повышать выручку и/или снижать издержки и/или увеличивать капитализацию бизнеса (далее по тексту кратко - бизнес-результат). Такие задачи можно назвать инвестиционными. Операционные задачи они иногда выполняют. Например, оказывают техподдержку. Но для них это явно второстепенная роль.

Почему же тогда у владельца часто возникают сомнения в том, что разработчики вообще выполняют свою основную роль? Стоимость у них, как у чугунного моста, а эффект никакой или низкий. И уволить нельзя. Даже если новых разработчиков аналогичной квалификации удастся найти (вспоминаем про рынок труда в IT), то есть риск, что они не смогут разобраться в коде и будут всё переписывать с нуля. Какая-то запутанная ситуация.

Один из предпринимателей у меня на контроле ценности после диагностики сказала: "У меня было ощущение запутанного клубка, внутри которого я нахожусь. И любое моё движение запутывает его ещё сильнее. Мне нужно было найти конец, чтобы начать его распутывать." Давайте разберемся, где конец у этого клубка?

Может быть надо тратить ещё больше, чтобы с гарантией нанимать лучших? Нет, не угадали. Можно встретить зарплату в 700 тыс руб на руки (!) у CTO небольшой команды, который не делает для бизнеса ровным счетом ничего. И уволить нельзя - заменить некем. С другой стороны у меня есть кейс, когда кросс-функциональная команда из вновь нанятых джунов за 3 месяца достаточно качественно запилила то, что за два года не могли сделать матерые мидлы с сеньорами.

Может быть внедрить один из модных Agile-фреймворков? Спринты, регулярные обзоры? Командная работа? Теплее. Но слишком абстрактно. Рискуете выкинуть много денег впустую. Дело не в том, как работают разработчики. И даже не в том, сколько они получают. Хотя конечно надо платить достойную зарплату. Главное - как вы воспринимаете результат их труда? За что вы им платите зарплату?

Один из моих знакомых предпринимателей, когда впервые пошел в IT, искренне считал, что если за месяц не написано ни одной строчки кода, то время потеряно зря. Он хотел платить за код. И есть такие разработчики, которые ненавидят всякие Agile-фреймворки. Они просто хотят писать код, и хотят чтобы им за это платили. Наберите в поисковике zed a shaw manifesto, и вы найдете их манифест. Позвольте пару цитат оттуда в перводе на русский. С цензурой, естественно.

Мы - сообщество ублюдочных программистов, которых годами унижали разными методологиями разработки программного обеспечения. Мы устали от XP, Scrum, Kanban и всего остального, что встает на пути программирования, (цензура). Мы устали выслушивать, что мы асоциальные идиоты, которыми приходится манипулировать, чтобы мы ишачили парным программированием, как в цепной банде (chain gang) без всякой передышки на творчество, потому что ни один из 10 менеджеров в проекте не может ... программировать, (цензура)! Мы должны уничтожить эти методологии, которые встают на пути ... программирования, (цензура)!

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

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

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

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

И это не трекер предпринимателей. Эти товарищи пошлют вас подальше с запросом помочь решить проблему в IT-разработке. Это не консультант по IT-разработке, потому что он непременно пойдет руководить вашими разработчиками. Это несколько IT-ролей в одном человеке:

И такие люди на рынке не только есть. Они даже имеют международно признанную сертификацию. И называется эта роль - Scrum-мастер. И его даже не обязательно звать в штат. Можно на время, проектно. А чтобы Scrum не стал карго-культом, как это чаще всего бывает, четко поставьте ему задачу. А именно - опишите желаемый бизнес-результат, на который он будет работать вместе с вами. И когда согласие будет достигнуто, то первое, что вы должны сделать: вдвоем сесть, и расписать ваши гипотезы причинно-следственных связей в операционке вашего бизнеса. А далее он вам поможет составить из них своего рода ТЗ (бэклог продукта) и затем уже наладит результативный процесс общения с разработчиками.

Главное - не ждите, что Scrum-мастер теперь за вас всё сделает. Его задача не в том, чтобы вас заменить. А в том, чтобы повысить эффективность затрат в разработку, в том числе за счет вашего более тесного вовлечениея в неё. Будьте готовы учиться новому. В конце концов, это ваш бизнес. И поэтому, эти изменения не нужны никому так сильно, как вам.

Успехов!