За десять лет в ИТ я видел разное. Застал времена, когда компании мерялись кофемашинами и свежестью печенья в переговорках, — и несколько кризисов, когда бюджеты замораживались за неделю, а команда при этом должна была продолжать выпускать релизы.
Запомнился один контраст. В компании с идеальной кухней, киндерами на столах и йогой по средам из команды за год ушло четверо ключевых разработчиков. В другой — с обычным чайником и серым офисом — люди работали годами и тащили проекты, которые, казалось, тащить невозможно. Разница была не в йоге. В первой компании люди делали то, что спускали сверху, и не понимали зачем. Во второй им доверяли решения и говорили правду.
Работаю в основном с государственными цифровыми проектами. Там мотивационный бюджет не предусмотрен по определению: в смету не заложишь ни тимбилдинг, ни премии «за красивые глаза», ни даже коробку конфет к дедлайну. Поначалу это раздражало. Потом оказалось полезным: когда у тебя нет денег на обёртку, очень быстро обнажается правда — люди работают не за латте.
Ниже — что из нематериальной мотивации реально работает в моих командах, а что я отправил на помойку собственных иллюзий.
Автономия — но не «делайте что хотите»
Про автономию написано много, и чаще всего её понимают как «отпустите людей, и всё случится само». Не случится. Свобода без рамок — это не мотивация, а тревога: человек не понимает, где его поле, за что отвечает и по каким правилам играют.
У меня схема простая. Жёстко фиксируем «что» и «зачем»: требования, сроки, границы. В моих проектах это ещё и нормативная база, и требования по защите информации — здесь свобода заканчивается быстро, и я это честно проговариваю. Зато «как» полностью отдаю команде.
На практике это выглядит так: перед стартом мы вместе договариваемся о периметре. Что на выходе, к какому сроку, какие интерфейсы и ограничения не обсуждаются. Внутри периметра человек — хозяин: сам выбирает подход, сам оценивает трудоёмкость, сам решает, когда показать промежуточный результат. Моя работа в этой схеме — охранять периметр снаружи: от спонтанных пожеланий заказчика, от срочных хотелок сверху, от перекраивания приоритетов в середине пути.
Пример. Нужно было выстроить обмен данными с внешней системой — старой, капризной, с документацией в виде вольного пересказа. Я мог прийти с готовым решением, опыт позволял. Вместо этого собрал троих разработчиков, обозначил ограничения и сказал: «Решение ваше. Если упрётесь — я рядом». Три дня они спорили, рисовали схемы на доске, переделывали друг за другом. Решение получилось не таким, каким сделал бы его я, — честно говоря, местами лучше. Но главное даже не это. Когда заказчик на приёмке начал этот механизм критиковать, ребята защищали его сами — аргументированно и жёстко. Моё решение они бы защищали вполсилы. Своё — до конца.
Два жёстких правила. Первое: если отдал решение команде — не переписывай его за спиной.. Второе: если решение команды отличается от того, как сделал бы ты сам, но не ломает проект, — подписывайся под ним перед заказчиком как под своим.
Вызов: задача чуть выше головы
Глаза разработчика загораются от задачи, которая чуть выше его текущего уровня. Не от объёма работы — от её сложности.
Был у меня мидл: год поддерживал один и тот же модуль, делал это хорошо, но я видел — гаснет. Короткие ответы, ноль инициативы, код «по обязанности». В какой-то момент в проекте нарисовалась задача по оптимизации поиска по большому объёму данных — неприятная, нетривиальная, без готового рецепта. Я отдал её ему и сказал прямо: «Не знаю, получится ли. Но из всех, кто есть, доверяю это тебе». Две недели он жил этой задачей, задавал вопросы по вечерам, выкинул два собственных варианта. Сделал. И, что важнее, — вернулся. Ожил.
Из этого я вынес два правила. Вызов — это не «завалить человека работой»: задача должна быть решаемой, хоть и с потугами. И рядом должен быть ты — не контролировать, а подстраховать. Разница между «бросили в воду» и «учим плавать» именно в этом.
Отдельно про рутину, потому что про неё обычно умалчивают. Рутина есть и будет: регламентные отчёты, правки по замечаниям, документация. Обманывать, будто её нет, — верный способ потерять доверие. Я говорю честно: «Это скучно, но это нужно, и это ненадолго». И стараюсь балансировать: после двух недель исправлений по протоколам замечаний человеку должна прийти задача, за которую можно взяться с интересом. Рутина, поданная честно и дозированно, переносится спокойно. Рутина, замаскированная под «вызов», демотивирует сильнее откровенной скуки.
Признание: конкретно и вовремя
«Молодец, так держать» — это не признание, это шум. Хуже только ежегодное «коллектив отмечает ваш труд» на корпоративе.
Работает конкретика. После демо заказчику, где всё прошло гладко, я говорю при команде: «Вот этот модуль, который сегодня всех впечатлил, — сделал Сергей. Он переписал механизм очередей, и документы перестали теряться». Не «команда молодец», а человек и его конкретный вклад. И своевременно — сегодня, а не на годовой аттестации, когда уже никто не помнит, что там было.
Ещё одна деталь, которую я понял не сразу: публичность — по желанию. Интроверту, который покраснел от похвалы на общем совещании, лучше сказать лично и спросить, можно ли упомянуть его при всех. Для одного публичное признание — крылья, для другого — стресс на неделю.
Психологическая безопасность: цена ошибки
Самый дорогой звук в проекте — тишина, когда человек обнаружил проблему и молчит, потому что боится. Я за такую тишину однажды заплатил двумя неделями сроков: инженер заметил ошибку в данных, не решился поднять тревогу, попытался починить незаметно — и не успел.
С тех пор разбираем инциденты без поиска виноватых. Был случай: накануне показа заказчику упал стенд. Выяснилось, что вечером туда ушло непроверенное обновление. Вместо вопроса «кто это сделал» задаём другие: почему обновление смогло уйти вечером накануне демо? Какой проверки не хватило? Вывод записали в процесс: заморозка изменений за сутки до показов, автоматическая проверка после обновления. Человек, который это обновление выкатил, сам принёс эти предложения. Он не «виноватый» — он автор улучшения.
Фраза, которую я говорю в таких ситуациях: «Это не ты провалил — это наш процесс позволил ошибке дойти слишком далеко». После пары таких разборов люди начинают сообщать о проблемах раньше. А ранняя информация о проблеме в большом проекте — это то, что дороже всего.
Люди важнее процессов
Много лет назад я был уверен, что хороший процесс вытянет любую команду. Теперь считаю наоборот: процессы существуют для людей, а не люди — для процессов.
Главным инструментом здесь стали личные разговоры. Раз в две-три недели, 30–40 минут с каждым — не только с «проблемными». Это не формальные one-to-one по чек-листу из HR-методички, а обычные разговоры: сесть рядом с кофе, позвонить вечером, выйти вместе за обедом. Без повестки, но с памятью о прошлом разговоре: если в прошлый раз человек рассказывал про переезд, в этот раз я спрошу, как обустроился. Я знаю, у кого из команды ребёнок пошёл в первый класс, кто платит ипотеку, у кого на этой неделе защита диплома. Это не «навыки эмпатии» из тренинга — это просто внимание к людям, с которыми ты проводишь по восемь часов в день.
Однажды я заметил, что один из лучших моих разработчиков потух: короткие ответы, задачи поплыли, на вопросы реагирует с раздражением. По процессу правильный ход — зафиксировать снижение производительности, поставить план, взять на контроль. Вместо этого я позвал его прогуляться. До работы мы добрались минут через двадцать: дома сложные обстоятельства, он неделями толком не спит. Мы перекинули часть его задач, я дал ему несколько спокойных дней и попросил об одном: предупреждай заранее, когда станет совсем тяжело. Через месяц он вернулся и работал лучше прежнего. Процесс измерил бы его падение. Разговор помог его остановить.
У этой практики есть цена — время. Разговоры не помещаются в таймшит, не отображаются в плане проекта и не дают результата завтра. Но именно они позволяют заметить проблему на стадии «что-то не так», а не на стадии заявления об увольнении. Самое дорогое в моей работе — не переработки и не форс-мажоры заказчика, а внезапное уведомление в мессенджере: «Нам надо поговорить». Пока разговоры регулярны, таких внезапностей почти не случается.
Овертаймы: только добровольно и только «в долг»
В госсекторе без штурмов не бывает: сдача этапа, комиссии, внедрение на площадке. Переработки случаются, и обманывать на этот счёт я не буду. Но у меня два железных правила.
Первое: овертайм — только по желанию. Перед штурмом я не объявляю «все остаются», а спрашиваю: «Кто может? У кого какие планы?» Если человек не может — это не предательство, это нормально: у людей есть жизнь. Как ни странно, добровольность работает лучше принуждения: те, кто остался по собственному решению, выкладываются по-настоящему. Оставленный приказом думает не о задаче, а о том, как его развели.
Второе: переработка — это долг, и долг я возвращаю. Все овертаймы фиксируются — не для контроля, а чтобы я сам не «забыл». Когда проектная активность позволяет, после тяжёлого этапа даю людям отдых: отгулы, короткие дни, спокойную неделю без планёрок и срочных задач. После трёх недель одной тяжёлой сдачи я отправил почти всю команду отдыхать вразнобой — на неделе затишья это ничего не стоило проекту, а вернулись люди живыми. Переработка по принуждению и без возврата — это кредит под очень большой процент: расплачиваешься выгоранием и увольнениями.
И ещё одно: я не делаю из овертаймов подвиг. Человек, который системно сидит по ночам, — это не герой, а симптом: либо я неправильно спланировал, либо ему нужна помощь, которую он не просит. Разбираюсь с причиной, а не вручаю медаль. Медали за переработки создают культуру, в которой уходить вовремя становится стыдно, — а это прямой путь к тому, что люди начнут имитировать занятость вместо работы.
Вместо вывода
Универсальных рецептов нет. Деньги должны быть справедливыми — ниже этого порога никакая автономия не поможет, и если ваша компания «компенсирует» зарплату печеньками, это диагноз, а не мотивационная программа. Но выше порога работают другие вещи: чтобы задача была интересной, решение — твоим собственным, вклад — замеченным, а ошибка — не приговором. И чтобы рядом был руководитель, который видит в тебе человека, а не ресурс в таск-трекере.
Всё это не требует бюджета. Это требует времени и внимания — а они, в отличие от бюджета, зависят только от нас самих.
Спорные тезисы готов защищать в комментариях.
