Мы решили поговорить на тему, которая волнует и разработчиков, и менеджеров. Возможно ли учитывать время разработчика, зачем и как это делать? На нашем митапе выступили Михаил Цыкарев, старший тимлид проектного офиса ICL Services (GDC Fujitsu Russia) и Антон Назаров, iOS разработчик.
Зачем учитывать время?
Михаил: Когда я слышу вопрос о том, нужно ли учитывать время разработчиков, во мне включается проджект-менеджер.
Любой ресурс, тем более ценный и дорогой, учитывать нужно.
По первому образованию я сам разработчик. Но в какой-то момент я понял, что мне гораздо интереснее работать на стыке людей и технологий. Я работаю с внутренним продуктом нашей компании - системой, в которой мы храним информацию о навыках всех сотрудников нашей компании - мы называем её Skills management. Основная команда разработчиков, которыми мы управляем, — от 4 до 6 человек, 2 тестировщика, 2 аналитика, дополнительные специалисты. Команда разработки работает по SCRUM, но при этом финансирование и ключевые поставки мы согласовываем ежеквартально.
Мы — сервисная компания, которая фактически в разных моделях продаёт IT-специалистов и сервисы крупным западным заказчикам. Бизнес-модели разные: есть Fix Price, Time Material, есть продажи по головам, от которых мы стараемся уходить, есть консалтинг, когда мы продаём участие специалистов в проекте или команде. И вот, почему очень важно учитывать время специалистов - заказчики нам за него платят. При этом за время любых специалистов: от начинающих инженеров, до ведущих разработчиков и software-архитекторов очень высокого уровня.
Как мы учитываем время? Учёт поставлен унифицировано, достаточно качественно и с большим количеством вариаций. Это позволяет отслеживать, чем человек занимается, учесть, есть ли необходимость в каких-то отклонениях в конкретном проекте. Не отчитываться за своё время не получится. Можно, но недолго. А самое главное, что мы - руководители проектов и координаторы, менеджеры - обычно работаем на нескольких проектах или продуктах, и мы перед собой видим большое количество людей, которые отчитываются о своих работах и времени на них. Мы сами его учитываем, мы видим разработчиков, мы видим тестировщиков, инженеров, архитекторов. Так что мы быстро замечаем, как люди относятся ко времени.
Если говорить о времени с точки зрения жизни разработчика в проекте, то сейчас мы вышли на стабильную команду, в которой это примерно 1,5-2 года. При этом у нас нет непредвиденных выходов, мы примерно за полгода планируем привлечение новых людей в команду и выход людей из команды.
Антон: Разработчик — это бегущий хомячок, который слишком сильно раскрутил своё колёсико.
Невозможность оценить время работы разработчика стало уже мемом.
И скорость зависит только от него самого. Типичный менеджер всегда будет руководствоваться подходом “если ты успеваешь, нужно ускорить еще чуть-чуть”. Если ты не будешь сам себя останавливать, так и сдохнешь под гнётом задач. Доверчивому разработчику кажется, что это такая инвестиция в будущее. Но на самом деле твоё время — это подарок компании, который ей и не нужен.
Баланс и мотивация
Михаил: Что может привлекать в разработке? Любой человек, который работает в айти больше года-двух, получает хорошие деньги. Деньги, в числе прочего, — отличный маркер, который помогает понять, чего я стою. Еще привлекает узнавание нового, новые скиллы. Для меня очень полезно было разобраться в своей мотивации, понять, что меня драйвит больше, и во что это должно превращаться.
Нужно примерно понять, кто есть в команде и чего они хотят. Деньги хотят все. Но чтобы что? Попасть в более крутую команду, получить доступ к лучшему обучению, получить доступ к самым современным скиллам? Когда мы можем ответить на вопрос “что этим ребятам надо?”, тогда мы можем выстраивать историю из компонентов “что мы делаем” и “как сделать нашу жизнь более осмысленной”.
Я верю в то, что люди чувствуют себя хорошо, когда: есть нормальная команда, которая готова поддерживать и развивать; есть чувство, что ты делаешь что-то полезное и значимое; есть некоторый план, как мы движемся из точки А в точку Б. Мы все хотим развиваться, мы все хотим куда-то попасть. Я не могу решать, куда людям идти, но как тимлид, я могу создать атмосферу, в которой люди будут делиться тем, чего они хотят и куда они хотят попасть через какое-то время. Моя задача — создать атмосферу в команде, сделать адаптацию в команде такой, чтобы люди помогали друг другу разбираться в задачах, обеспечить достаточное количество обратной связи от пользователей, которые будут приходить и говорить, где хорошо, а где нет.
Антон: В начале своей карьеры я походил между компаниями и понял, что мне хочется больше денег. Процесс повышения зарплаты был очень прозрачен, можно было добиться 7 или 15% плюса. Меня это не устраивало. Тогда в блогах я нашёл другой тип разработчиков. Это люди, у которых есть ненужная и неосознанная амбициозность. Иными словами: они стремятся стать лучшими там, где это никому не нужно. Какой смысл брать больше задач и перерабатывать, если и через 10 лет ты будешь брать больше ответственности и перерабатывать.
Как всё успеть?
Михаил: Мы достаточно внимательно собеседуем разработчиков на входе, мы избегаем работы над очень крупными задачами. У меня ни разу не было истории, когда нужно было задать разработчику вопрос “а чем ты тут занимаешься?”. Следующее — это дейли. Мы работаем двухнедельными спринтами, соответственно, спринт-планинг. Каждую неделю — разработка бэклога: мы смотрим текущую динамику и текущие задачи. Соответственно, мы видим, с чем сталкиваемся и что происходит. Раз в две недели — демо, я организую дополнительное демо примерно раз в один-два месяца с заказчиками, когда приходят живые люди и говорят, что им нравится, а что нет. Дальше очень простая история: если разработчик выбивается из ритма, я это увижу как тимлид в течение 1-1,5 недель. Команда не такая большая, и я вижу, кто и с какой скоростью работает. Легко заметить человека, который выбивается из ритма.
У нас в команде получилось выстроить атмосферу, когда если у человека что-то происходит, он сам приходит и говорит об этом. Тогда в команде складывается атмосфера, что у нас есть результат, мы на него работаем, и мы нормально относимся к тому, что кто-то уходит вправо, кто-то уходит влево. Но мы вместе этого результата добиваемся.
Антон: Гонка с самим собой меня не устраивает, я хочу делать ровно столько, сколько нужно. Если никто не знает, сколько нужно делать, я не буду делать ничего.
Я решил работать настолько мало, насколько это вообще возможно, чтобы мой менеджер оставался удовлетворённым. Первый шаг — нащупать дно продуктивности. Дальше всё прозаично: я работал два месяца не больше 2 часов в день. Но два часа в день на проект — это идеал, который практически не достижим.
Признаки низкой планки продуктивности: удалёнка, большая команда/маленькая ответственность, сложные процесс или отсутствие процессов, исследовательская деятельность, не стартап, не Россия.
Моральная и юридическая сторона вопроса. Никто вокруг не знает, сколько я могу сделать за день, поэтому я могу поставить низкую планку. Стоит ли указывать в резюме, что вы работаете одновременно в нескольких местах? Во-первых, год работы на двух работах не считается за два. А еще это проверка на адекватность: если потенциальный работодатель отрицательно реагирует на несколько мест работы, стоит задуматься, а нужен ли он вообще. Насчёт трудоустройства: лучший вариант — это ИП, с некоторыми компаниями можно договориться на большую зарплату, потому что с ИП налог платите вы.
Советы, которые помогут прожить первые 3-6 месяцев работы по совместительству:
максимально экономь своё время и оптимизируй свой быт. Пересчитай зарплату на руб/час и поймёшь: вместо того, чтобы тратить время на уборку, лучше эти несколько часов поработать. А уборку пусть делает клинер. Этот совет подходит вообще всем, кстати.
Относись к этому, как к эксперименту. Если что-то пойдет не так, ты просто вернёшься к подходу с одной работой.
Проверяй пределы производительности и веди дневник. Короткие записи помогут устроить самому себе ретроспективу раз в месяц и вспомнить, что ты делал, что получалось, и какой был эффект. Так будет проще понять, можно ли продолжить в том же духе или что-то подкорректировать.
Научись казаться занятым, но отвечай на сообщения сразу. Если тебе ставят задачу, браться за неё в эту же минуту не обязательно, но ответить и поставить сроки нужно как можно скорее. Тогда ты кажешься сильным и уверенным, а доверие к тебе возрастает.
Плюсы: деньги, оптимизация быта, избавление от неосознанной амбициозности, опыт вдвойне, насмотренность компаний, относительная свобода, диверсификация усилий. Минусы: чувство тревоги, цинизм, лень.
Две работы — это не так просто, количественный подход имеет жёсткий лимит. И самое главное — жизненный опыт в этой ситуации гораздо полезнее денег.
Получается, что учитывать время разработчика важно для эффективной работы команды в одном ритме. Рекомендации Михаила: внимательное собеседование разработчика на входе, мелкие задачи, маленькая команда и созвоны, на которых можно обсудить результаты.
Если разработчик хочет избежать этого? Антон советует браться за сложные процессы в большой команде, не показывать свой максимум, уметь казаться занятым и делать ровно столько, сколько нужно.
*Наше мнение может не совпадать с мнением спикеров. С интересом почитаем ваши комментарии по теме митапа ;)
Об этой и других болях менеджеров, тимлидов и разработчиков поговорим на 18 февраля в Казани, где пройдёт первая IT-People Conf — конференция об управлении людьми и продуктами в IT. Новости и общение участников конференции в чате. Присоединяйтесь!
Партнеры конференции IT-People Conf - международная IT-компания ЕРАМ.Разработчики, тестировщики, бизнес-аналитики, проектные менеджеры, архитекторы решений и другие специалисты EPAM работают примерно на 3000 проектов и разрабатывают очень разные продукты – от онлайн-магазинов до VR игр для международных финансовых, торговых, медицинских, медиа- и других компаний.