- Люди меняются медленно. Ты делаешь лучшее из возможного с теми, кто есть, или увольняешь, или даже увольняешься. Первое требует самообучения.
- Люди развиваются неравномерно. Кто-то качает код, кто-то разговоры, кто-то английский. Идеала не будет — ни у тебя, ни у сотрудников, ни у твоих детей.
- Найм подходящих — это твоя задача, а не рекрутеров. Они могут помочь, но не более.
- И программисты, и бизнес любят связь в своём формате: «С меня код, с вас деньги и уважение» и «С меня список задач и деньги, с вас работающая программа». Люди неосознанно избегают общения сверх этого. Чем выше человек в иерархии, тем проще ему оградить себя от тревожных сигналов и тем вреднее это для компании.
- Программисты не знают, насколько хорошо они работают (нет связи от менеджеров) — от этого нервы и выгорание/пофигизм/увольнения. Бизнес не понимает, над чем работают сотрудники — от этого страх обмана и дурные KPI. Плохая обратная связь — самая частая проблема в известных мне компаниях.
- Менять процесс нужно только в том случае, если результат кого-то не устраивает и этот кто-то готов за это заплатить. Желание должно быть не «Ну ладно, давайте попробуем», а «Мы косячим в <…>, это проявляется в <узнаваемые всеми ситуации>, я готов к сложностям времени внедрения».
- Конфликты будут всегда, и это хорошо.
- Учи на крови. Пока у тебя на руках есть горячий провал, и всё чувствуют, как это больно — тут и можно внедрить изменения. На крови гораздо проще перейти с программистами от мутного «Мы будем внимательнее» к «Любой код ревьювится», а с бизнесом от «Мы им деньги платим, пусть работают» к «Они люди. И не всегда предсказуемы, нужно вкладываться в мотивацию, отдых, резервирование критичных знаний»
Это самое важное из моего личного опыта управления проектами. Большую часть я выкладывал у себя на Facebook, сюда выношу выжимку. В этой статье — мои субъективные наблюдения и гипотезы. Я не социолог и не проводил развернутых исследований. Есть что дополнить, особенно в реальных примерах, — пишите в комментах. Я убрал всю воду, а её больше всего было на стыках.
О найме
«Пришлите пример вашего кода» — нужно спрашивать перед собеседованием. Кто пришлет код с коммерческого проекта — тех не брать на проекты с важным NDA. Кто пришлет код с публичного гитхаба — смотреть частоту коммитов и задавать вопросы про рабочий график и скорость переключения с проекта на проект.
Такой вопрос — дурная практика, не нужно спрашивать. Я вообще пока не видел ни одного хорошего способа эффективного собеседования миддл+.
Хороший vs Плохой. Все менеджеры знают, чем хороший программист отличается от плохого. Причем это знание не совпадает между менеджерами. Мне сейчас удобно определение: «Джун — приносит хоть какую-то пользу компании выше своей зарплаты, синьор — может написать проект от и до, а что не сумеет (например, дизайн или тексты) — сможет поставить ТЗ».
Навыки. Можно требовать от опытного программиста умение классно оценивать задачу. А заодно свободно говорить по-английски, понимать и уточнять мутное ТЗ, быть активным и всегда работоспособным, готовым, если надо, выйти на работу в любое время, говорить только по делу и коротко, разбираться в бизнес-области, кибербезопасности, разработке архитектуры, классно тестировать хотя бы свой код и т.д.
Только если ты ищешь нового программиста два месяца, сроки горят, бюджет ограничен, то ты наймешь любого, кто может писать хороший код на нужной технологии. И даже оплатишь время на доучивание незнакомых ему библиотек. Если надо — добавишь бизнес-аналитика для общения с заказчиком. Наверняка — добавишь время менеджера.
Программист должен писать код. Это самое главное. Неумение разобраться в ТЗ, плохой английский, конфликтность — снижают ценность и зарплату, но при нехватке программистов на рынке труда не будут стопором.
Note: если сбудутся мечты работодателей, и кандидатов станет больше, чем вакансий — всё поменяется. Если за одно место будут бороться пять синьор-джавистов, то рекрутеры начнут перебирать, вплоть до: «Фи, он свою поэму на английском не проверил спеллчекером, а внимательность — важный признак для нашего сотрудника».
Фрилансеры и удаленщики. Самые лучшие и самые худшие сотрудники мне попадались именно на фрилансе/удаленке.
«С++ за 21 день», «HTML за месяц» и другие сказочные курсы. После IT-курсов только от 5% до 20% поступивших находят работу. Остальные зря тратят время. Хотя вот буквально на днях слышал о результате в 60% — буду смотреть детальнее.
По моему опыту, на обучение с нуля до уровня «может приносить пользу работодателю» уходит от 400 до 900 качественных часов. Редко кто вытягивает больше 10 качественных часов в неделю на обучение без отрыва от основной работы. Больше 30 не вытягивает даже с отрывом. «Качественный час» — это когда таймтрекер останавливается при проверке почты/новостей/чай заварить, то есть любых прерываниях. У каждого есть свой предел «сколько я могу выучить/сделать для себя нового за день», при приближении к этому пределу КПД падает — и дальше есть смысл сидеть только для однотипной хорошо известной работы. Ну и бэкап заранее сделать.
Трудоустройство с нуля. Затраты на джуна — это не столько его зарплата, сколько время менеджера + рабочее место. И не важно, джун попросит 300 или 400 долларов. Фирме он будет стоить, к примеру 600 или 700. Не так уж и существенная разница, в общем-то.
О деньгах
Зарплата. Зарплата зависит от рынка труда куда больше, чем от кандидата. При растущем рынке наибольшей прирост ставки можно получить при смене работодателя. При падающем рынке — можно дольше удерживаться у старого работодателя. Примеры падающего рынка — кризис 2008-го и застывший сейчас рынок IT-труда в России.
Работодатель с удовольствием введет грейды, KPI и любую систему оценок, но… Зарплата по-прежнему будет зависеть от рынка, а не от KPI.
Прокрустово ложе аутсорсера. За $100 в час можно взять американца, который будет ходить в офис, жить по времени заказчика, говорить на отличном английском и понимать массу непонятных нам нюансов. Нас чаще выбирают не за суперзнания, превосходящие выпускников MIT, а за цену. Это очень важно для стартаперов, например.
Украинским аутсорсерам удается продавать сотрудников пусть за классные $40. Выше уже заказчики начинают крутить носом и смотреть на Индию — там уровень программистов здорово подрос за последние годы, а цены куда ниже наших.
Экономика аутсорсера. Разница между внешним и внутренним рейтом обычно в два раза. Но при этом прибыльность аутсорс-компании — 10-15%. Остальное уходит на офис, отпуска, праздники, больничные, бенч, найм, менеджмент, железо, софт и еще десяток мелких пунктов.
Числа проверены из трех независимых источников. Владелец небольшой фирмы запросто получает меньше своих топовых сотрудников и несет больше рисков.
Я видел довольно много бизнесменов-аутсорсеров, которые рассматривают свой бизнес как разгонный блок для продукта. Для старта продукта нужно много денег, которые проще получить с аутсорса.
Мотивация
Мне говорят — мы тебе наняли дорогих сотрудников, почему вы в срок не укладываетесь? А я ни на зарплату особо не влияю, ни уволить не могу.
© частая жалоба хорошего программиста и начинающего менеджера в одном лице
Тема заезжена вдоль и поперек, пошла и баяниста, как анекдоты про Ржевского. Но если собрать десяток тимлидов и PM-ов и спросить: «Что болит?», то мотивация — самый частый ответ.
Свой/чужой. Большинство программистов ассоциирует себя с программистами. Поэтому при описании любого конфликта между программистами и бизнесом, угадайте, какую сторону выбирают программисты? :) Это нормально, это естественно, эффект «защиты своих» нужно учитывать при любых действиях, которые могут выглядеть как наезд.
Топ-менеджеры и бизнес тоже друг на друга равняются.
Привыкание. Люди привыкают быстро к хорошему, а от сильно плохого быстро увольняются. Никакой мотиватор не обеспечивает постоянного эффекта. Успех — только в балансе и непрерывной комбинации мотиваторов с отслеживанием результата.
Diff. Люди ведут себя по-разному. Кто-то ноет с самого начала, кто-то молча работает, кто-то прибегает с вопросом два раза в день. Не так важно, как они себя ведут, важно, если поведение меняется. Тут стоит придумать две-три гипотезы, почему так:
— Раньше ныл, теперь перестал? Может, что-то отрефакторил втихаря, а может, тупо забил и ходит по собеседованиям?
— Раньше молча работал, а теперь начал говорить на отвлеченные темы? Стал доверять? А может, хочет поделиться наболевшим, но не знает, как начать?
— Бегал с вопросами два раза в день, а теперь — раз в два дня? Либо научился, либо поставил на себе крест.
Следующий вопрос — что с этой гипотезой делать и как обрабатывать возможные последствия. Но начинается всё с отслеживания изменений.
Похвала. Нужно хвалить. Если не за что хвалить, то зачем такой сотрудник? Без похвалы за конкретные действия мотивации нет. А любое порицание воспринимается как ужас-ужас-ужас. Гуглить «Линию Лосадо».
Две смертельных ошибки менеджеров. Желание нравится всем и перфекционизм — два самых частых греха начинающего IT-менеджера.
Менеджер-хамелеон принимает ту точку зрения, которая сейчас популярна среди собравшихся. Всем кажется, что он их поддерживает, и всё идёт хорошо. Поначалу.
В результате желание менеджера всем нравится приводит к тому, что заказчик легко продавливает сверхоптимистичные эстимейты в начале, новые фичи без изменения эстимейтов в середине, доделки потом. Подчиненные при этом тоже садятся на шею. Всё идет ок, пока заметенный под ковер конфликт не вылазит срывом сроков, нагоняем и овертаймами.
Кстати, и перфекционизм, и желание радовать других часто являются базовыми сценариями поведения человека, можно даже сказать — основой личности. Обычно такие вещи не получается поменять простым «не делай так больше».
Перфекционизм программистов. Перфекционизм у сотрудников поганит жизнь менеджеру:
— Бесконечные доделки;
— Перфекциониста на смежную задачу не перекинешь;
— Нытье: «Аааа, мне опять не дали отрефакторить нормально!»;
— Выгорание и увольнение.
Перфекционизм самому носителю тоже мешает жить. Когда кругом есть только серое «нормальное качество» и обычное черно-депрессивное «полное Г», то радоваться жизни как-то не от чего. Кроме того:
— Вечно задач больше, чем времени;
— Нифига не успеваешь;
— Окружающие делают всё не так, приходится проверять.
Ценности. Программисты ценят хороший код, заказчик ценит бизнес-пользу и прибыль. Ни программисты, ни менеджеры не хотят вникать в ценности второй стороны. Балансируй, объясняй, стыкуй ценности.
Прерывания. Одно прерывание человеку обходится в 20-40 минут рабочего времени. И не важно — вы отвлекли человека на 30 секунд, либо на один час — вспоминать задачу и разгоняться он будет всё равно примерно полчаса. Более подробно можно почитать тут — «Не будите программиста».
Если в команде пять человек, и каждый отвлечет каждого по одному разу в день — процентов 30 производительности уже на этом потеряете. Используйте чаты без нотификаций и ежедневные планерки для сбора всех прерываний в один кластер.
У меня получается либо писать код, либо менеджить в один момент времени.
Эмоции и логика. Программисты часто уверены, что почти всегда поступают разумно и не испытывают лишних эмоций. Менеджеры также уверены, что для донесения мысли достаточно логики.
Специалисты по людям и общению говорят, что люди испытывают эмоции непрерывно, хотя многие и стараются этого не показывать. Но при сильных эмоциях логика не работает. То есть сначала нужно помочь выйти на конструктивные эмоции, а уже потом применять логику.
Кстати, подавленный гнев часто вылазит в сарказм и насмешки.
Вместо выводов
Управление проектами и людьми идёт примерно из пещерных времен и непрерывно эволюционирует. Я думаю, что в обозримом будущем эта эволюция продолжится. Люди учатся, меняются, решают квартирный вопрос, строят и ломают методологию разработки, собирают лучшие практики в кучки корпоративной культуры — тут еще очень много чего можно написать, и это уже будет во второй части.
