{"id":14275,"url":"\/distributions\/14275\/click?bit=1&hash=bccbaeb320d3784aa2d1badbee38ca8d11406e8938daaca7e74be177682eb28b","title":"\u041d\u0430 \u0447\u0451\u043c \u0437\u0430\u0440\u0430\u0431\u0430\u0442\u044b\u0432\u0430\u044e\u0442 \u043f\u0440\u043e\u0444\u0435\u0441\u0441\u0438\u043e\u043d\u0430\u043b\u044c\u043d\u044b\u0435 \u043f\u0440\u043e\u0434\u0430\u0432\u0446\u044b \u0430\u0432\u0442\u043e?","buttonText":"\u0423\u0437\u043d\u0430\u0442\u044c","imageUuid":"f72066c6-8459-501b-aea6-770cd3ac60a6"}

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

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

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

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

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

0
83 комментария
Написать комментарий...
дмитрий шаповал

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

Ответить
Развернуть ветку
Милая Мила

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

Ответить
Развернуть ветку
1 комментарий
Богдан В.

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

Ответить
Развернуть ветку
KR Digital
Автор

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

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

Ответить
Развернуть ветку
Аккаунт удален

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

Ответить
Развернуть ветку
Иван Петров

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

Ответить
Развернуть ветку
2 комментария
Петр Жарков

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

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

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

Ответить
Развернуть ветку
Богдан В.

Про ответственность - хорошо сказано. Современные ИТ-котики умеют думать только о том, где лучше, и совершенно не смущаясь на багрепорты от пользователей говорить: «я у себя проверил и у меня все работает».

Ответить
Развернуть ветку
Alexander

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

Ответить
Развернуть ветку
Бинарный Ёж

Я немного работал по такой схеме на Upwork. Пришёл к выводу, что если делать задачу качественно как требуют того в компаниях — то оплата едва покрывает затраты на еду, съеденную за время работы. Зато если писать сложный говнокод без документации — то к тебе приходят заново как к обладателю сакрального знания, и ты диктуешь цену по $100 за багфикс в 1 строчку и час работы.

Т.е. проблема в том, что в "acceptance criteria" не пропишешь "добавленный техдолг". Одну и ту же задачу можно "решить" за 2 часа и +100 попугаев техдолга (которые потом всплывут как 10 новых задач), а можно за 20 часов и -100 попугаев техдолга (попутно закрыв класс ещё не всплывших проблем). И в долгосрочной перспективе, когда релиз не горит — выгоднее идти по п.2, согласуя это с грамотным менеджером.

Ответить
Развернуть ветку
7 комментариев
Sergei Timofeyev

Издержки будут расти. Да и вам нужно прокачивать скилл, чтобы проводить ревью согласно стандарту.

Ответить
Развернуть ветку
17 комментариев
СлавалС

тогда нет смысла делать задачи качественно, выгоднее найти нового работодателя.

Ответить
Развернуть ветку
4 комментария
Eduard Kozlov

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

Ответить
Развернуть ветку
Make Luv

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

Ответить
Развернуть ветку
18 комментариев
дмитрий шаповал
Ответить
Развернуть ветку
Arima B.

Тушеночная невеста нас всех разоблачила

Ответить
Развернуть ветку
Петр Жарков

Вы для начала откажитесь от смартфона.
От онлайн оплат.
От госуслуг еще откажитесь, чтобы снова ходить по госорганам (потому что зачем нам СМЭВ).
Вспомните очереди в сбербанк и "вы где карту получали, туда и обращайтесь".
Попробовали?
Вам нравится так?
Окей, вам айти не надо.
Остальному миру надо будет все равно

Ответить
Развернуть ветку
Eduard Kozlov

Нет, извините, не первой пойдет под нож. Первой под нож пойдет туристическая сфера, ИТ подготовиться.

Ответить
Развернуть ветку
1 комментарий
Аккаунт удален

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

Ответить
Развернуть ветку
Аккаунт удален

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

Ответить
Развернуть ветку
Ратмир Исламов

Давно пора! Пятилетку за три года, как говорится ;))

Ответить
Развернуть ветку
Denis Kostin

они натуры тонкие, к ним другой подход нужен

Ответить
Развернуть ветку
Undefined

Так нужно или не нужно?

Ответить
Развернуть ветку
Рамиль

Да никто не знает, а если бы и знал то не рассказал бы.

Ответить
Развернуть ветку
Вася Пражкин

Конечно нужно. Желательно - минимальное, чтоб разработчик в слезах просил его увеличить и ты такой:

Ответить
Развернуть ветку
KR Digital
Автор

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

Ответить
Развернуть ветку
Levon

Так ит это же не только разработка, есть аналитика тест документирование и т.п. и это очень часто может в разы превышать как затраты в дензнаках так и в трудозатратах

Ответить
Развернуть ветку
Петр Жарков

Нек. Разработчики самые дорогие в структуре почти любого проекта

Ответить
Развернуть ветку
3 комментария
0xA10 BMF

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

Ответить
Развернуть ветку
0xA10 BMF

Гинеколог занимается травматолог ей иммунолог херургией ... И все ведь врачи со скидками в анатомии. Время взлёта бездарей.

Ответить
Развернуть ветку
80 комментариев
Раскрывать всегда