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

Дебаты про тайм-трекинг не утихают в 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, без возможности попросить помощи у кого-то. И делали в срок. Потому что была реальная ответственность.

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

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

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