Нужно ли ставить программистам время в задачах?

Дебаты про тайм-трекинг не утихают в IT-сообществе с момента его возникновения. Жесткий контроль приводит к недовольству и текучке кадров. Отсутствие контроля - к снижению эффективности. Основатель KR Digital Сергей Ковалев размышляет о том, как найти золотую середину.

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

Нужно ли ставить программистам время в задачах?

О подходах к проблеме

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

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

Небольшие IT-команды без неограниченного финансирования пытаются найти свой путь где-то между этими полюсами. С одной стороны, им не подходит подсчет часов: подавляющее большинство разработчиков относится к контролю рабочего времени крайне негативно. С другой – они не могут себе позволить такой свободы в сроках, задачах и бюджетах, как корпорации. Приходится искать собственный рецепт, который позволит сочетать гибкость с эффективностью. В части компаний применяются финансовые бонусы - от опционов до разделения прибыли между всей командой. Где-то помогают выстроить работу ежедневные созвоны, где-то - хорошие личные отношения внутри команды.

Идеальное решение для всех трех случаев – когда удается создать мотивированную команду, которая горит своей работой. Но для того, чтобы такая команда сложилась, нужны человеческий фактор и банальная удача. Постройка "дримтим" потребует больших денежных и временных затрат; её фундамент – сильный и “заряженный” лидер. Лидера, который способен собрать и удержать команду придется долго подбирать (выращивать), удерживать большой зарплатой, а его потеря может стоить направления или целого бизнеса.

Время перемен

В нынешней ситуации, когда рынок испытывает потребность в IT-специалистах, разработчики могут себе позволить диктовать условия. Здесь помогла и пандемия, которая стала катализатором для “оцифровки” множества сфер – в итоге кадровый голод стал еще ощутимее.

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

Самые медийные примеры у всех на слуху: увольнение половины из 7500 сотрудников Twitter, увольнение 11 тысяч сотрудников в Meta, заморозки найма в Apple и Amazon. А есть ещё массовые сокращения в менее известных компаниях. Crunchbase насчитал 91 тысячу уволенных сотрудников в американском технологическом секторе в 2022 году. Ресурс Layoffs.fyi – более 152 тысяч.

Нужно ли ставить программистам время в задачах?

Российский рынок также испытывает рецессию: в 2022 году количество IT-вакансий уменьшилось на 25 %, многие компании урезают расходы на долгосрочные проекты, стартапы закрываются или релоцируются. Оптимизировать затраты приходится даже тем, кто традиционно ориентировался на качество без дедлайнов.

Мы в KR Digital часто работаем над автоматизацией бизнес-процессов и видим большой спрос на цифровизацию в среднем бизнесе. Руководство таких компаний хочет понимать, что происходит у них под носом, чтобы оптимизировать затраты. Но сейчас время оптимизации расходов наступает повсеместно: волна сокращений в “большом IT” тому подтверждение. И малый, и средний, и крупный бизнес – все ищут способ урезать расходы на IT-отдел, поэтому нужно искать новый подход, который учтет интересы всех сторон.

В чем корень бед?

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

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

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

Так может, ключ к эффективному взаимодействию бизнеса и IT-команды в том, чтобы повысить ответственность разработчиков за сроки и результат? Заменить постоянный контроль ответственностью?

Кто-то наверняка возразит: разработка - дело творческое, невозможно ничего спрогнозировать точно. Но здесь на ум сразу приходит пример советских инженеров: эти люди делали гораздо более сложные вещи без готовых фреймворков и GitHub, без возможности попросить помощи у кого-то. И делали в срок. Потому что была реальная ответственность.

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

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

Об этом мы и поговорим в следующей части статьи. Продолжение следует!

2828
83 комментария

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

14
Ответить

"Айтишники - они же тоже котики" никогда не видела сравнение милее)

2
Ответить

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

Ответить

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

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

Ответить

Комментарий недоступен

10
Ответить

Почитайте про команду программеров "Бурана".

1
Ответить

Ну я бы поспорил с тезисом про советских инженеров, бо я сам из такой семьи, и прекрасно знаю, как работали познесоветские НИИ (большинство их): без сроков, без ответственности, без денег.
В остальном, данная задача всегда решается таймтрекингом в тоже же джире.
Если разраб сам хронически не попадает в свои сроки, там это видно.
Для проверки качества есть КУА. Если разработчик косячит, нормальное куа это видит. Есди это доходит до потребителя - это плохое, негодное куа.

Ну и еще тезисну, что на моем опыте на плохое тз разработчики ссылаются, как правило, когда оно и правда плохое :)
Тз все таки должно быть хорошим, чтобы оценки были точными, а не +-50%

Но дальше мы попадаем на вопрос, а до какой степени должно детализироваться тз? :)

3
Ответить