Уже более 5 лет я занимаю руководящие позиции в области анализа данных. От синьора DS с двумя подчиненными до лида трех команд аналитиков и инженеров в Малом бизнесе Сбера. За это время я сформировал принципы, которые помогают мне в управлении творческими специалистами.
Не претендую на истину, да и не всему всегда получается следовать. Принципы не отражают всех задач менеджера, а относятся к конкретным вопросам. Делюсь с вами своим опытом, буду рад услышать ваше мнение.
Нужно ставить квартальные цели так, чтобы выполнять 60-70% из них
В современном бизнесе за 3 месяца может все быстро измениться. Трудоемкость задачи может оказаться совсем не такой, какой казалась на этапе оценки. Какие-то задачи отпадают, какие-то срочные появляются.
Понятно, что планирование целей бывает разное. В некоторых компаниях нужно выполнить 100% ваших целей, иначе вам поставят плохую оценку. Мне кажется, это плохая практика, т.к. люди начинают ставить неамбициозные или ненужные цели.
Но так или иначе, при постановке своих личных реальных целей я рекомендую ориентироваться именно на 60-70%. Когда-то давно прочитал это в статье про Google. В разработке продуктов это баланс между амбициями и выполнимостью.
Для технического специалиста нормально проводить время на кухне или в курилке
Разработчик тратит на написание кода порядка 20-30% времени. Большую часть времени он читает код и думает.
Мыслительный процесс наиболее эффективен, когда он проходит в бекграунде. На эту тему было много исследований.
Например, было следующее исследование, которое я прочитал в книге Курпатова (https://mybook.ru/author/andrej-kurpatov/krasnaya-tabletka-posmotri-pravde-v-glaza/citations/2832366/). Взяли 3 группы студентов и попросили выбрать их наилучшее предложение из списка съемных квартир по ряду параметров (цена, площадь, ремонт, местоположение и прочее). Первой группе дали время на размышление, вторую попросили дать ответ сразу. Третей группе показали список квартир, а затем вместо времени на размышление дали решать математические задачи, после чего попросили сразу выбрать лучшее предложение. О результате вы, конечно, уже догадались. Хуже всего отвечали студенты первой группы. Те, кто дал ответ сразу оказались на втором месте. А лучше всего справились те, кто вместо размышлений решали математические задачки.
Поэтому когда программист болтает на кухне с коллегами, в это время у него в подсознании идет сильнейший мыслительный процесс. Потом он сядет и начнет делать задачу, к которой до этого не знал как подступиться. Я хорошо знаю это по себе, и это позволяет мне не стрессовать, когда надо мной висит сложная задача дамокловым мечом.
Конечно, есть еще такое явление, как прокрастинация, когда человек откладывает неприятную задачу, занимаясь всем, только не тем, что нужно. Известна шутка про аспиранта, у которого всегда вымыта посуда и убрана квартира.
Во всем нужен баланс. В небольшом объеме прокрастинация - это нормально, как мне кажется.
Нужно давать сотрудникам возможность делать маленькие победы
Одна моя знакомая несколько лет проработала в Яндексе в очень сложных наукоемких проектах. Она обладает великолепными хард скиллами, да и софтами тоже. И в разговоре спрашивает: А есть ли у вас проблема с импактом? И рассказала историю, что многие ее задачи в виду их сложности так и не дошли до прода.
Ничто не убивает мотивацию, как долгострой без видимого результата. Поэтому я стараюсь декомпозировать задачи так, чтобы сотрудники регулярно видели результат. Иногда есть смысл приоритизировать не самую важную, но простую задачу, просто чтобы создать ощущение небольшого успеха.
Одна из главных задач менеджера - создавать у сотрудников ощущение защищенности и стабильности
Очень наглядно этот принцип объяснял Григорий Бакунов (aka bobuk) в лекции для Школы Менеджеров Яндекса (https://youtu.be/iYhaK_BpO8w). Разработчик сможет наилучшим образом сконцентрироваться на своих задачах, если у него будет меньше внешних раздражителей.
Самое лучшее, если менеджер всегда доступен, всегда на связи и может помочь в любой момент. Но, конечно, нельзя создавать ориентир, что нужно вкалывать круглые сутки, чтобы не вызывать у людей чувство вины и трудоголизм. На связи и вкалывать 24×7 — разные вещи
Забавная история Бобука была про его эксперимент, когда он купил 5 одинаковых рубашек, чтобы каждый день выглядеть одинаково, и смотрел, как это влияет на производительность команды. Правда через какое-то время ему сделали замечание, подумав, что он не стирает вещи. Пришлось объясняться =)
Практически все проблемы рано или поздно решатся
Отличие менеджера от специалиста в том, что у первого стоят гораздо более масштабные и долгие задачи (поэтому ему и нужна команда).
Быстрые победы не всегда можно получить. Возникает много проблем, авралов и иногда может возникнуть желание опустить руки. Более того, повсюду пишут про истории успеха, когда люди за полгода делают MVP и становятся единорогами.
Я придерживаюсь мнения, что легкого успеха статистически не бывает. Т.е. кому-то везет, но это исключения, а не правила. Чтобы достичь успеха, нужно быть готовым долго бить в одну точку. Когда над вами скапливаются проблемы, вспомните, сколько проблем у вас было в прошлом. Наверняка много. И что с ними стало? Они скорее всего решились. И эти тоже скорее всего решаться.
Это не значит, что нужно до последнего тащить убыточный проект. Этот принцип скорее про тактику, а не про стратегию. У менеджера постоянно происходит много проблем. Уходят сотрудники, никак не получается доделать какой-то проект, задача над которой вы долго работали теряет актуальность. Просто будьте к этому готовы и придерживайтесь вашего долгосрочного плана.
В 2016 году я год проработал в стартапе BostoneGene, который занимается созданием IT-системы для онкологов, используя данные генома для подбора лечения. Тогда компания только создалась, у нас работало много вчерашних и текущих студентов. Творился хаос. Мы несколько раз делали неудачные прототипы. Сложно было поверить, что компания сможет нащупать успешную бизнес-модель. Но основатель стартапа, Майкл Файнберг, был опытным бизнесменом. До этого он создал успешную компанию NetCracker. Он бил в одну точку и еще тогда говорил, что играет в долгую. И вот теперь компания успешно прошла второй раунд инвестиций и появилась на мониторе NASDAQ на Times Square.
Используйте линейный метод прогнозирования сроков и результатов
Например, есть у вас один "важный, но не срочный" проект. Но за полгода он не сдвинулся с мертвой точки. И вот на статусе вас спрашивают, когда вы его сделаете. Вы прикидываете оставшиеся задачи - это просто, это тоже вроде просто. Да сделаем за месяц! Но тут появляются другие срочные задачи и на статусе через месяц вы обнаруживаете, что находитесь на том же месте.
Или пример не по работе. Вы обычный человек, в зал ходите раз в месяц, едите в целом все подряд. И вот с лайф-коучем сидите обсуждаете ваши цели. Вроде хочется быть спортивным, скинуть лишний вес. И строите план, как поменяетесь за три месяца. Садитесь на диету, начинаете упорно тренироваться, получаете первые результаты. Но потом на работе запара и дома тоже срочные дела, и в итоге набираете вес больше, чем был.
Как data scientist могу сказать, что для прогнозирования подобных ситуаций можно обойтись без нейросетей и просто провести прямую по нескольким точкам. Нужно принять, что скорее всего дальше будет также, как было раньше. Изменить тренд очень непросто. Для этого нужны постоянные небольшие улучшения. Когда я работал в консалтинге в EY*, мы продавали это заказчикам под словом Кайдзен.
Поэтому когда вам нужно сделать прогноз по сроку или результату проекта и вам хочется дать оптимистичную оценку, всегда спрашивайте себя, а что такого поменяется в процессе, что мы успеем больше/быстрее?
Давайте сотрудникам больше свободы
Я придерживаюсь твердого убеждения, что до людей по возможности не нужно докапываться. Я всегда согласовывал все запросы на отпуск. Даю людям работать по графику, который им нравится, сходить ко врачу, посидеть со сборщиком мебели или уйти пораньше, когда нужно. Закрываю глаза на просроченное скучное обязательное обучение, пока не прижмут. Да и тогда стараюсь максимально отбрыкиваться от HR-ов (простите меня если вы это читаете =)) )
Я предлагаю два варианта работы. Если сотрудник горит работой и хорошо перформит - пусть работает как хочет. Лишь если к сотруднику есть вопросы, то тогда я ожидаю, что он будет работать по четкому графику и соблюдать правила. Но практически всегда люди с течением времени оказываются в первой группе. За свою карьеру мне пришлось уволить только одного человека по окончанию испытательного срока, и в целом решение было обоюдным. У меня есть примеры, когда люди сперва перформили ниже среднего, но потом находили себя и становились одними из лучших в команде.
В творческой работе количество часов не решает. За час можно сделать больше, чем за весь день. А люди, которые совсем не попадают в команду, скорее всего сами уйдут.
Подводя итог
В своем лонг риде я постарался описать накопившиеся личные наблюдения, не опираясь на традиционные книги по менеджменту. Какие-то мысли могут показаться очевидными, какие-то наоборот спорными. Не знаю, изменится ли мое мнение с течением времени. Будет любопытно перечитать через несколько лет =)
Если вы дочитали, до этого места, то предполагаю вам было интересно. Буду рад вашему фидбеку!
Какое-то время назад я завел телеграм-канал про лайф-стайл и немного про работу. Приглашаю всех кому интересно @ledovsky_blog
*- В личку был вопрос, что такое EY. EY - глобальная консалтинговая компания, в прошлом известная как Ernst and Young. Российская дочка после известных событий отделилась и стала называться Б1
Комментарии (9)
AndreyYu
07.08.2022 17:51+4"Ничто не убивает мотивацию, как долгострой без видимого результата." - прям флэшбэк к прошлой работе...
funca
07.08.2022 20:16+1рекомендую ориентироваться именно на 60-70%. Когда-то давно прочитал это в статье про Google
Лучше смотреть сразу первоисточник DSDM (многа букаф), раздел MoSCoW Prioritization: 60% Must, 20% Should, 20% Could, 0% Won't.
Anything higher than 60% Must Have effort poses a risk to the success and predictability of the project, unless the environment and any technology is well understood, the team is well established and the external risks minimal.
Ну то есть все что выше 60% обязательной работы ведёт к рискам, кроме как вы делаете уж совсем очевидные вещи. Ну или просто рисковый парень по жизни.
Как гласит история, метод приоритизации придумали в 1994 году, а мы узнаем лишь четверть века спустя. Это не критика, просто мысль вслух. Да это не ново, но все актуально.
Стандарты и методологии разработки проработаны в достаточной степени уже давно. Но они объемные как и сама область, поэтому требуют целенаправленного образования. Мы же упорно пытаемся обмануть систему, выбирая замену в виде каких-то клипов и статей уровня хабра.
aledovskiy Автор
07.08.2022 22:05+2Спасибо, теперь будет на что сослаться)
Правда если вчитаться, то в тексте по ссылке есть существенное отличие от того, о чем я хотел сказать.
MoSCoW предлагает поделить цели по принципу Парето, отделив условно must have от should have. Я писал про то, что в целом часто не получается сделать ровно те цели, которые ставишь.
Из 10 целей успешно выполняются 6-7, но ты заранее не знаешь какие. Не получается сделать 6 must have, потом взяться за should have.
Вроде бы цель must have, но в процессе выясняется, что ее трудоемкость гораздо выше, чем казалось с самого начала (по той или иной причине). Или ты не успеваешь закрыть предыдущую задачу и не можешь переключить разработчика на новую. А предыдущую на середине бросать тоже нельзя.
Конечно, есть какое-то количество жестких коммитов, где от тебя что-то очень ждут, или от тебя зависят другие команды. Но таких целей должно быть совсем немного, потому что на них нужно перезакладывать ресурсы.
funca
08.08.2022 00:42Вы наверное знаете про треугольник scope - cost - time. DSDM в целом это про минимизацию рисков для проектов типа fixed cost + fixed time - для смягчения сработавших рисков безболезненно варьировать можно scope. Но лишь в той части что не must (иначе какой же это тогда must?). Все must задачи лежат на critical path и между ними есть жёсткие зависимости. Если вы продалбывете в спринте must, то весь проект рискует вылететь за рамки и это повод для эскалации и принятия корректирующих мер уровня всего проекта.
Если must задачи получается переставлять местами, то возможно что-то упущенно на этапе планирования, либо у вас просто не хватает людей, чтобы не делать последовательно ту работу, которую можно параллелить. В общем MoSCoW это только часть метода, и чтобы понять логику там лучше читать все целиком.
gleb_l
08.08.2022 00:28Одна из главных задач менеджера - создавать у сотрудников ощущение защищенности и стабильности
Это истина! Хороший менеджер получает зарплату за то, что рассеивает в себе зиверты вредного излучения сверху, создавая внутри более благоприятную среду, чем снаружи. Иными словами - он продаёт свою способность абсорбции рисков, причём всех мастей.
saipr
И я из своих более 50 лет в программировании. более сорока лет считал, что я курю (а курил я не менее пары пачек "Беломора", а с конца 80-х "Явы", в день) только потому, что мне нужно что-то обмозговать и тем, что компьютер медленно транслирует и мне надо занять руки. Но в один прекрасный момент мне просто расхотелось курить. и вот у же скоро десять лет как я не курю. Но самое главное я нашёл чем заменить курение. которое я тратил на обдумывание. Вместо сидения в курилке. я теперь просто хожу:
Так что со всем в статье можно согласиться. кроме этого постулата.
aledovskiy Автор
Сложно поспорить)
PS. 50 лет в программировании - огонь!! Почитаю ваш блог)))
niksy12
Можно решать алгоритмические задачи в фоновом режиме (в уме или на бумаге). И скорость решения рабочих задач заметно ускорится через некоторое время