Никита Соболев: У нас нет привычной системы мотивации, мы просто хорошо платим

У нас в компании нет системы мотивации, и я считаю, что если нужно людей каким‑то образом мотивировать, то что‑то работает не так.

Когда я работаю с другими компаниями в качестве консультанта или подрядчика, я все глубже убеждаюсь в тезисе «стандартная система организации процессов не дает стабильного результата». Мы все знаем вытекающие проблемы: сроки часто затягиваются, проекты проваливаются, появляется бюрократия и нескончаемая рутина.

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

Корень проблемы в неумении делегировать и плохой организации процессов.

Руководитель должен поставить задачу и установить срок. Может ли руководитель точно определить срок? Конечно нет. Чаще всего дедлайн ставят на глаз, умножают на десять и прибавляют две недели. Руководители не умеют оценивать сроки. Но и исполнители не могут нормально оценить свою задачу. В программировании это может привести к тому, что человек затянет выполнение или отложит задачу в долгий ящик. Люди не смогут написать хороший код и соблюсти дедлайн, если не создать условия.

Корень проблемы в неумении делегировать и плохой организации процессов.

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

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

Мы пошли другим путем и полностью отказались от такой сломанной системы.

Формат микротасков

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

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

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

Как все устроено

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

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

Ключевой показатель эффективности человека — количество заработанных денег за решенные задачи.

Я часто слышу от своих клиентов фразу: «Наши разработчики не хотят писать тесты и/или документацию». Как вы понимаете, такой проблемы у нас нет. Люди понимают, что им не заплатят, пока они не сделают так, как нам нужно. И они будут тратить свое время на исправление решения. Все быстро приходят к мысли: лучше сразу делать хорошо.

На задачу выделяется от 30 минут до 4 часов в зависимости от ее сложности. Время фиксируется. На задачу не нужно тратить больше времени, ведь дополнительно оно не оплачивается.

Если человек взял задачу, а потом отвлекся и не выполнил, то после дедлайна бот пришлет ему напоминание и задаст вопрос с такими вариантами ответа:

• Что происходит?
• Ты отошел?
• Задача сложная?
• Или ты доделываешь и пришлешь в ближайшее время?

Если не отреагировать на запрос бота, то через три часа бот пришлет еще одно уведомление: «Ситуация накаляется, что происходит?» Последнее напоминание от бота приходит через 4 часа после просрочки дедлайна, и если сотрудник никак не отреагировал, то бот снимает с него задачу и передает ее другому человеку.

Цель бота не угнетение сотрудника, а решение поставленной задачи. Главное — отреагировать на его запрос и дать фидбек о состоянии задачи, это тоже важный момент коммуникации. Мы моментально узнаем о возникших технических трудностях. Или, например, если задача сложная и ты понимаешь, что не справишься за 4 часа и потребуется гораздо больше времени.

Какие есть форматы решения задачи:

• Срезать угол. Человек понимает, что не успеет сделать всю задачу полностью за отведенное время и делает ее в ограниченном варианте. После этого он создает следующую задачу: описывает, что он не успел сделать, предлагает свое видение — куда двигать проект, какие будут сложности и почему это сложно. Таким образом, он создает цепочку микрозадач, мы называем их task chains.

• Решение о нерешаемости задачи — это тоже решение. Но тут должны быть не просто слова о том, что задачу решить нельзя, а объяснение и исследование задачи. И кусочек документации, который зафиксирует это исследование.

• Выполнить задачу полностью или запросить помощь, если нужна дополнительная информация. Как? Конечно, через pull request. Присылаешь свой код — другие получают задачу сделать код-ревью. Твой коллега проведет ревью, поможет советом, за что тоже получит деньги.

• Отказ от задачи. От любой задачи можно отказаться без объяснений, никаких штрафов и наказаний за это не будет.

Про грейды и стоимость задач

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

По статистике, 80% проектов проваливаются из‑за проблем в коммуникациях. Если уменьшить количество коммуникаций до минимума, то ими гораздо проще управлять.

Сейчас максимальный грейд — 5000 рублей в час. Мы хотим автоматизировать изменение грейда, чтобы он рос или падал в зависимости от результативности программистов. Единственная сложность — придумать оптимальную формулу для вычисления.

Как мы управляем коммуникациями в команде

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

Если кто‑то в команде хочет уйти в отпуск, он нажимает в программе кнопку «не работаю» и со спокойной совестью едет отдыхать.

По статистике, 80% проектов проваливаются из‑за проблем в коммуникациях. Если уменьшить количество коммуникаций до минимума, то ими гораздо проще управлять. Многие люди говорят нам: «Если я не буду общаться по работе, то буду скучать!» Мы отвечаем: «На работе занимайся работой, общайся с друзьями и семьей в свободное время». Нажал кнопку — ушел общаться.

Если кто‑то в команде хочет уйти в отпуск, он нажимает в программе кнопку «не работаю» и со спокойной совестью едет отдыхать. Вернулся из отпуска — нажал кнопку «работаю», и тебе прилетает ближайшая свободная задача. Согласовывать отпуск ни с кем не надо.

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

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

• В комментариях к задачам. Вопросы по делу, обратная связь, ревью и обсуждения.
• Через код. Пишешь понятный и читабельный код — люди тебя понимают.
• Через документацию. Принял решение? Расписал его. Упал прод? Написал, что сделал, чтобы такого больше не произошло. Придумал хитрую архитектуру — сделал диаграмму.

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

Как начать работать с нами

У нас на сайте висит ссылка на публичную форму, в ней есть вопросы об опыте кандидата, теоретические вопросы о программировании, которые он должен знать (например, «Назови команды в линуксе из трех букв»), и ссылка на тестовое задание. Кандидат заполняет форму, делает тестовое задание и после этого мы с ним связываемся.

Нам совершенно плевать на резюме человека, мы не смотрим на пол, возраст, опыт, софт-скиллз. Нас интересует только его способность выполнять задачи.

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

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

Нам совершенно плевать на резюме человека, мы не смотрим на пол, возраст, опыт, софт-скиллз. Нас интересует только его способность выполнять задачи.

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

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

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

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

Про борьбу с выгоранием и отсутствие ограничений

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

Мы не тратим деньги клиентов на обучение сотрудников, не отправляем никого на конференции, не проводим корпоративы, не поздравляем с днем рождения.

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

Мы снимаем эти искусственные ограничения с помощью бота, который просто присылает задачи. Например, человек думает, что он не девопс, но ему прилетает задача поправить настройки сервера, он ее берет и делает. Если он чего‑то не знает, то учится в процессе. Сам. Без принуждения.

Кто контролирует качество

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

Нематериальная мотивация не нужна

Мы не публичная компания, мы скорее сервис или биржа. Мы не тратим деньги клиентов на обучение сотрудников, не отправляем никого на конференции, не проводим корпоративы, не поздравляем с днем рождения.

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

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

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

Про открытость

Наша задача — рассказать людям о другом способе работы, который может значительно повысить продуктивность и качество. Мы стараемся выкладывать все материалы в публичный доступ, делать все продукты open source по умолчанию. Релиз нашего бота для публичного использования тоже не за горами. Я очень хочу, чтобы подобный формат работы стал распространен. Ведь он делает жизнь заказчика и разработчика лучше.