Андрей Плахов: Всем привет. Мы сегодня впервые проводим митап руководителей IT-разработки в Яндексе. У нас получилось собрать представительный состав. Надеюсь, встреча будет полезной.

Меня зовут Андрей Плахов, я в Яндексе работаю руководителем отдела функциональности поиска, а вообще в индустрии я больше 15 лет и лет 10 чем-нибудь руководил.

Прежде чем перейти к основной теме встречи, сделаю важное вступление. IT-разработка очень разнообразна, и люди из разных её частей находятся в разных контекстах, обладают собственным сложившимся жаргоном, привыкли к разным вещам и живут в разных мирах. Традицию называть это разными мирами придумал Джойл Спольски в 2002 году. У самого Джойла миры были другие, но в 2018 году я выделил бы шесть следующих.

Бывает разработка В2В решений, решений по автоматизации процессов. Бывает В2С разработка веб-сервисов или программ для массовой аудитории. Бывает разработка внутренних инструментов для нужд одной организации. Бывают создатели видеоигр, создатели ПО для какого-то hardware, где совсем свои законы, и бывает наука и академия, где всё свое.

Согласно человеческой природе, люди из разных миров друг друга не просто не понимают, смотрят друг на друга свысока. То, чем занимаешься ты сам, кажется важным и сложным, а чем занимаются остальные – тривиальным или бессмысленной заумью. Такое бывает часто. Где-то человек, который пришел на работу не в костюме, выглядит как бунтарь, а где-то как бунтарь выглядит человек, который пришел на работу в костюме. Яндекс — скорее организация второго типа.

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

Я к тому, что хотел бы попросить всех осознать и преодолеть потенциальные предубеждения, понять, что все эксперты вокруг вас в своей области достигли многого. Это значит, что у каждого есть, чему поучиться. Если он выглядит не так, как вы привыкли или говорит что-то для вас неожиданное, это не потому, что это странный человек, а потому что его контекст совсем другой.

Это относится и к трактовке понятия team leader. В разных областях, от запуска ракет в космос до верстки интернет-магазинов, всё устроено по-разному, и тим-лидеры — разные люди. Но есть общие вопросы. Нам нужно управлять командой квалифицированных, обычно достаточно молодых сотрудников, у которых технический склад ума, которые совместно разрабатывают какое-то ПО с ограничением по времени и ресурсам, с высокой неопределенностью. Мы собрали здесь людей, которые де-юре или де-факто этим занимаются – руководят командами разработчиков.

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

Человек, который когда-то был хорошим разработчиком и за это его назначили на должность руководителя команды, часто находит себя совершенно в новом мире. Он понятия не имеет, что ему делать теперь, и, например, продолжает писать код 100% времени, а всё остальное считает бюрократией или болтовней.

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

Нам хочется научиться делиться этими методами, выработать терминологию и отраслевой стандарт.
Эта тема необъятна, поэтому тема сегодняшней встречи — работа с талантами, с многообещающими сотрудниками, обладающими своей неповторимой индивидуальностью.

Слово «талант» абстрактное, давайте попытаемся его сузить. Все знают, что в разработке бывают задачи рутинные, конвейерные, и бывают более сложные. И есть люди, которые более сложные задачи решают в десять или в миллион раз эффективнее других. Из известных мне соревнований по решению сложных задач самая представительная — международная математическая олимпиада. У нас работает несколько её победителей, я их бесконечно уважаю, но на их примере отчетливо понимаю, что сложность задачи тоже бывает разной. И не все навыки решения решения сложных задач определенного типа плохо транслируются на условия IT-разработки.

Здесь классно переформулировать и заменить слово «сложные» на «непонятные».

В ситуации, где проблема вроде бы всем понятна, но она не поддается полной формализации, или она просто технически сложная, и при этом нужно посмотреть на неё под каким-то особым углом. Не хочу говорить за всех, но большинство людей в частных беседах согласны, что люди делятся на два типа: на тех, кто умеет решать такие задачи и тех, кто не умеет. Это не значит, что вторые хуже, полезных конвейерных задач везде много, но есть задачи, которые умеют решать определенные люди, и я хотел бы определение талантливых сотрудников сузить до этого.

Это свойство не определяется только квалификацией, набором технологий, образованием или уровнем IQ. Начиная с какого-то порога IQ, квалификации и так далее этот навык зависит от чего-то другого. Это не голословное утверждение, за ним стоит некая статистика, с которой можно ознакомиться, например, в книге Гладова 2008 года.

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

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

Хочу рассказать типичную историю двух стажеров из своей практики. Несколько лет назад ко мне пришли работать два стажера, оба выпускники ШАД, одного возраста, со схожим бэкграундом, оба одинаково хорошо буквально с одинаковыми результатами прошли вступительные собеседования. И в первый год работы по своим результатам почти не отличались. Потом окрепли, получили квалификацию, я стал им подбрасывать более сложные, менее формально поставленные задачи, более хитрые. В этот момент между ними стала проявляться отчетливая разница: один из них охотно за такие задачи брался, подключал мозг, находил нетривиальные решения, в целом явно рос. Второй на такие задачи обижался, считал, что если задача ему не до конца понятна, это проблема, и проблема кого-то другого, например, меня или человека, из которого она исходит. В целом, чем дальше, тем больше разница достигаемых ими результатов стала все больше. В конце концов один стал руководить достаточно большим подразделением, а второй компанию покинул.

Это тривиальная история, которая может навести на размышления. Например, можно ли было узнать о такой разнице ещё на собеседовании? И если да, что с ней делать?

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

Андрей Плахов: Давайте обсудим для разминки вопрос, который был в анонсе на Хабре: все люди одинаково талантливы. Согласны ли вы с этим? Стоит ли на уровне процессов компании выделить меньшую часть сотрудников, объявить их талантами, подходить к ним с отдельными процедурами? Стоит ли сделать этот статус открытым, публичным, сказав, что это – наши звезды?

Алексей Шаграев: Совершенно случайно я являюсь автором этого поста, вы знаете мой ответ, он там написан. Да, я считаю, что все люди по-своему талантливы. И наша общая задача — помогать друг другу раскрываться и реализовывать свои таланты. Я не считаю, что в компании должна быть формальная сегрегация на этот счет.

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

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

Александр Горный: Мое мнение, что не все люди талантливы по-своему. В определениях, в которых мы работаем, мы видим, что кто-то лучше решает задачи, а значит, кто-то решает их хуже.

В обычном случае обычной организации, которая для меня где-то между Mail.ru и РБК, не надо делать формальных категорий, кто в каком классе. С одной стороны, это демотивирует, особенно класс В, в каком-то смысле демотивирует класс С, и непонятно, что оно сделает для класса А.

Ну назначили мы кого-то в зеленых штанах — и что?

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

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

Дмитрий Долгов: Человек, который продрался через таинства технического собеседования в компанию 1С, уже талантлив. Если говорить про работающие у нас команды, там все люди талантливы. Безусловно, каждый – в своей области, на разных задачах – по-разному.

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

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

Успешно справляется человек? Замечательно, его можно дальше развивать в этом направлении, давать все новых подчиненных, все более сложные задачи. Нет? Нужно искать новые пути развития для него, чтобы он мог развиваться и раскрываться.

Ирина Федулова: Если мы нашли людей, которые лучше, чем другие, справляются с задачами, то им нужно давать больше. Здесь есть аналогия с детьми, одаренными музыкально, которых отдают в музыкальную школу; способных к математике отдают в матшколу. Нужно помочь раскрыть талант. Надо иначе ставить процессы в компании, чтобы люди, талантливые в решении нечетко поставленных задач, получали больше таких задач. Так и будут раскрываться их таланты.

В одной из крупных компаний, где мне довелось работать, так и сделано. Есть некий тайный список людей, являющихся кадровым резервом; особенно это относится к лидерскому потенциалу, талантам в определении Андрея.

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

Конечно, тот факт, что человек в кадровом резерве, необязательно делать публичным, но этот человек потому туда и попал, что он top performer. Это публичный статус, и в компаниях принято это выносить, награждать и публично хвалить. Поэтому можно сделать вывод о том, кто находится в кадровом резерве, просто по статусу.

Андрей Плахов: Интересно: в отличие от предыдущих экспертов, у вас вывод совсем не тот, что top performers должны быть публично известны в этом качестве. И классно сказали, что это поддержано конкретной практикой, когда такой ресурс, как возможность обучения, тратится ровно на этих людей. Это лучше конкретизирует то, чем вообще можно заниматься.

Ирина Федулова: Это спецобучение, как матшкола или музыкальная школа. Нет смысла туда всех отдавать. Естественно, это будет менеджерское обучение.

Николай Суетин: Продолжу практику больших компаний. Продвижение, выделение — это система грейдов, она известна. Меритократический подход — все понимают, за что человек получил грейд.

Начиная с определенного грейда, например, с восьмого в Intel, есть как значок в Яндексе, fork. Человек выбирает: либо он продолжает техническую карьеру, либо менеджерскую. Талант по работе с талантами — это отдельный талант, поэтому менеджер, который может найти, построить, сделать из непонятной задачи несколько понятных — это специфическая работа. А человек, который хорошо может решать известные задачи, это другое.

Если кто-то помнит, чем отличается старший научный сотрудник от научного сотрудника, научный сотрудник — это человек, который может самостоятельно решать поставленную задачу. Старший научный сотрудник может самостоятельно поставить задачу. В этом разница.

Андрей Плахов: Вы считаете, это два разных таланта и их нужно разделять?

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

Сергей Бережной: Каждый человек талантлив по-своему, но не всегда этот талант актуален для нашей специализации и конкретной компании. И, помимо таланта, у человека есть ещё калибр, средняя мощность. Условно, он может быть талантлив в музыке, но глубина его потенциального раскрытия в этом таланте может быть несоразмерной со среднестатистической в этой компании. Когда мы нанимаем людей и смотрим за их развитием, sad but true, нам приходится кого-то в том числе увольнять, потому что степень раскрытия его таланта недостаточно глубокая, а человек – недостаточного калибра, чтобы оставаться в команде. Это достаточно очевидные соображения. В своей практике я стараюсь каждого человека пристроить в кладку из естественного камня, грани совмещать, чтобы внутри команды человек нашел свое естественное место. Но если получается так, что грань у него нужной формы, но он не занимает достаточный объем и не покрывает достаточную площадь в этой кладке, то адекватно было бы этого человека поменять на другого.

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

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

Андрей Плахов: Здесь по сути были высказаны две диаметрально противоположные точки зрения, по крайней мере, по одному вопросу. Кто-то сказал, что top performers должны знать все, это должен быть публичный статус, доска почета, где было бы написано, кто эти люди. Кто-то сказал, что таких статусов нам не надо и люди лучше сами пусть про себя думают. Интересно, это только наследие в соответствующих организациях, определяется корпоративной культурой или есть ситуации, где лучше работает одно, а где-то – другое. Почему у вас не происходит того, о чем сказал Серёжа?

Ирина Федулова: Поясню. Когда top performer — это публичный статус, это когда человек или даже группа людей очень успешно завершила что-то. В одном квартале может быть один top performer, и это публичный факт, его наградили, он получил, допустим, табличку на стол. В другом квартале это другой человек. Но если менеджер видит, что систематически Вася делает больше, чем другие, и всё время его хочется выставить top performer, но он этого не будет делать, чтобы не возникало лишнего напряжения в команде, то такой top performer попадает в кадровый резерв. Мы на него обращаем больше внимания, даем ему больше задач, и он начинает там расти.

Андрей Плахов: Это очень понятная мысль, которая у меня резонирует. То есть публичным должен быть не статус top performer, а статус достижения, на который можно указать независимо от статуса – не просто Вася хороший, а Вася сделал хорошо вот это.

Ирина Федулова: Верно, это конкретное достижение.

Вопрос: Мы здорово говорим про публичные или непубличные достижения, о том, нужно хвалить человека или нет. А давайте следующий вопрос зададим: чтобы что? Мы объявляем этого человека публичным перформером, вешаем на доску почета. Мы недавно были в одной компании, где, серьёзно, есть доска почета. И всем с этим окей, и это не проектный институт или что-нибудь убогое. Отличная компания, там доска почета, всем нравится. А зачем?

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

Ирина Федулова: Зачем нам публично рассказывать другим, что кто-то сделал что-то классное? Чтобы его похвалить, ему будет приятно, у него будет мотивация дальше стараться. Также будет мотивация у других людей, они тоже будут хотеть попасть на эту доску.

Вопрос: Есть в зале люди с психологическим образованием? Понятно. Мы не можем управлять мотивацией человека. Давайте перестанем называть это мотивацией и станем называть манипуляцией.

Дмитрий Долгов: Скажу как представитель второй стороны публичного поощрения: манипуляции, любые публичные объявления, награды, доски почета, рассылки, достижения и всё остальное требуют очень формальных признаков верификации. К сожалению, что касается разработки в нашей индустрии, методы верификации достижений очень абстрактные. Тут сильно может сработать человеческий фактор. И, делая публичные достижения, доски почета и все остальное, менеджеры или совет менеджеров могут допустить серьезный фейл.

Андрей Плахов: Я знаю специфику вашей индустрии и начал понимать, в чём разница вашего опыта. В разработке игр циклы разработки длинные, порядка лет, команда обычно неделима внутри проекта, пока он не запущен, и сложно выделить отдельное достижение. Скорее всего, у людей, которые выступают за формальную доску почета, возможны достижения, которые хорошо формализуемы и всеми принимаются как таковые. И при этом имеют более мелкую зернистость.

Дмитрий Долгов: Да, здесь есть этот момент. Чем мельче проекты, спринты или задачи, тем чётче результат разработки. Если есть формальные критерии, где можно выделить, кого наградить, это работает. На долгоиграющих крупных проектах с разношерстной командой публичное выделение лидеров — тут сильно человеческий фактор сыграет.

Александр Горный: Я правильно услышал, что сейчас все эксперты против разделения людей на сорта? Ни у кого нет публичного хотя бы списка хороших людей?

Андрей Плахов: А грейд должен быть открытым?

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

Александр Горный: Грейд — это почти должность.

Николай Суетин: Нет, это ваша квалификация.

Александр Горный: Нет, зарплата зависит от грейда, грейд — это само по себе что-то материальное.

Николай Суетин: Необязательно.

Александр Горный: Летать другим классом.

Николай Суетин: Это важно, но для многих важно получить следующую звездочку на погонах.

Вопрос: Насколько я понимаю, все эксперты сказали, что есть разные категории талантов. Ни в одной из перечисленных компаний категорий талантов нет, хотя их можно брать.

Андрей Плахов: Был озвучен вопрос существования кадрового резерва или секретного списка менеджера.

Вопрос: Он не категоризирован, это общая категория — кадровый резерв. Какие категории вы выделяете внутри компании?

Сергей Бережной: Я говорил, что формальные категории сковывают. У меня процесс такой: появляется вакантная должность, я понимаю, что является архетипом этой должности, какой человек там нужен, нужно ли ему хорошо понимать JS, CSS, находить общий язык с продуктовой командой, с дизайнером… Каждое конкретное место обладает своими особенностями, и поэтому всё, что нужно знать про каждого конкретного человека, это максимум информации. А дальше стыковка человека с реальной позицией осуществляется с помощью коллективного экспертного мнения руководителей этого человека, они принимают решение, подходит этот человек под эту должность и почему, или нет.

Андрей Плахов: Давайте поговорим о том, как вовремя выявлять таланты. Даже в системе с грейдами — я буду использовать абстрактные «грейды в вакууме», видимо, в разных компаниях они разное означают. У нас есть сотрудник 25-го грейда и мы предполагаем, что когда-нибудь он станет сотрудником 75-го грейда. Пока что он очень молодой, не всё умеет, но мы в нём нашли это зерно и собираемся его растить, включив режимам благоприятствования, до его заветного 75-го, подбирая задачи под него, обращая особое внимание и так далее. Как мы опознали его на 25-ом? И как дать ему понять, что он может реализовать свой потенциал в нашей организации, что ему есть, куда здесь расти, и чтобы стать, условно, крупным начальником или уважаемым человеком, он не должен искать новую работу, уезжать в Долину и что-то такое.

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

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

Андрей Плахов: Даже с президентами это не совсем так. Невозможно предполагать, кто им станет, но можно предполагать, что это будет человек, родившийся в США, что это человек, хорошо знающий язык – на уровне родного, отучившийся в хорошей школе, поступивший в известный институт, скорее всего, с юридическим образованием...

Сергей Бережной: Если продолжать аналогию, ты примерно описываешь процесс собеседования в компанию. Да, определённо, человек, который не может программировать, вряд ли станет руководителем группы и дойдет до 75 уровня, поэтому мы и провели первоначальный отбор на этапе собеседования.

Но дальше, применив фильтры, о которых ты говоришь, остается пул людей, которые подойдут одинаково.

Александр Горный: Я скажу почти то же самое. Кто такой талант? Тот, кто лучше умеет решать плохо определенные задачи. У меня появилось какое-то количество плохо определённых задач, я их всем равномерно раздал. Кто-то её решил лучше, и следующую такую задачу я с большей вероятностью дам именно ему. И пока он будет решать их хорошо, он будет получать их больше, и это будет работать автоматически. И у него все будет хорошо.

Дальше проблема тех, кто в начале немного ошибся. Я в голове поставил крест – решил, что он не умеет, а он умеет и хочет, но ему не попадает. Надо с ними разговаривать. Если он хочет, то давать второй шанс. Чего не хватает? Сложных задач? Возьми сложную задачу. Следующий раз не хватает сложных задач? Ну, ты же с той облажался. Наверное, надо что-то делать. Не сложилось.

Первый пункт: таланты пробиваются автоматически. Когда они показывают, что решают задачи, то автоматически получают следующие задачи. Это естественное поведение любого не сумасшедшего менеджера.

Второй пункт: если ему что-то помешало, какая-то случайность, неприятность. Её можно преодолеть за счет регулярных более-менее открытых разговоров с человеком о том, что он хочет, что ему нравится, что не нравится.

Был в Mail.ru программист, который сейчас успешный стартапер, у него большой проект, всё хорошо. И он говорит, что был так себе программистом, но всё изменилось в один день. Была жена, маленький ребенок, начало 2000-х, не очень сытое время, и у него случился голодный обморок на работе. И он понял, что так нельзя, надо идти вперед, развиваться, иначе все будет плохо. Вот твой второй стажер мог так же измениться.

Андрей Плахов: Это такой выход из зоны комфорта up to eleven.

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

Моя задача — показать им тот спектр возможностей, который существует. И я могу рассказать классный пример. В моем случае типичная ситуация такая: я прихожу в новую команду, она делает какое-то конкретное подмешивание источника в поисковую выдачу. Какой-то аспект запросов, условно – про помидоры, команда может улучшать. Она действует какими-то способами, которые много лет вырабатывались, она к этому привычна, в этих терминах думает и так далее.
Коль скоро я туда пришел, я туда пришел не просто так, а с какой-то миссией. В духе: «У этой команды плохо получается говорить про помидоры черри, надо бы с этим что-то сделать, она не справляется, пойди и разберись». Предположим, я вбрасываю в команду такую задачу и смотрю, кто как реагирует. В этот момент я их ограничил. Я так не хочу. Я хочу собрать людей, поговорить, что мы обрабатываем только один аспект этого качества. А что тут еще можно сделать? А можно ли посмотреть на это глазами пользователя? Можно ли подумать про интерфейс, ещё про что-нибудь, про элементы выдачи, которые вообще к нам не относятся, но сказываются на пользователях, которые здесь оказываются. Такой посев и затем проведенный по всем правилам брейншторм, чтобы выработать общее правило понимания этой конкретной группы на проблематику, способен породить намного больше вероятных продолжений движения этой команды, чем то, что я им доношу как руководитель или то, что через меня им спущено другими руководителями. Мне это кажется очень важным. Важно транслировать в команды весь доступный мне спектр того, чем можно заниматься, о чем можно думать, чтобы у них голова понимала: «Ага, так тоже можно было».

Мне это близко, я все время живу и обижаюсь на свою школу. Я многое не узнал вовремя. Сейчас я преподаю в институте, и когда мои студенты узнают, скажем, про олимпиадное программирование, говорят: «Ничего себе, так тоже можно было?». Они пробуют это, им это очень полезно, и потом говорят: как здорово, что узнали это, это нашу жизнь поменяло, мы поняли наше место в профессиональном сообществе и так далее.

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

Дмитрий Долгов: Я всё думаю про тему левелапа через голодные обмороки, надо поэкспериментировать на работе с этим.

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

Если попытаться это свести вместе к сферическому таланту в вакууме, то каковы основные критерии? Вот у нас есть новый сотрудник, мы про него не знаем почти ничего, кроме того, что узнали во время собеседования. Первые задачи, которые ему даются, достаточно чёткие и понятные. В них существуют какие-то недомолвки, какая-то вещь, которую человек может найти самостоятельно, прорешать самостоятельно, предложить какие-то решения или что-то еще. У нас часто возникает такая ситуация, когда первая задача дана с минимальными пробелами, можно посмотреть, как человек с ними справляется: вот здесь в задании, в спецификациях, ещё где-то отсутствует информация об этом, можно сделать так и так. Дальше, если человек с этим справляется, задачи становятся всё более общими. Финальная стадия роста такого человека: ты ему говоришь, что надо сделать хорошо, и дальше человек способен задачу полностью осмыслить, декомпозировать на задачи себе, исполнителям, подчинённым, если они у него появились, продумать разные corner cases, выполнить задачу в ожидаемый срок с ожидаемым уровнем качества.

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

Не вскарабкался — наверное, в этом направлении это его потолок. Это то, какого уровня задачи человек может решать автономно.

Ирина Федулова: Приведу из жизни пример, из одной компании, где я работала. Мне кажется, эксперты согласились, что талант можно выявить, когда мы даем людям новые задачи. Но не во всех компаниях и не во всех местах разработки бывает много таких задач.
У нас люди сами находили новые задачи, организовывали команды, по крупицам вытаскивали кусочки людей – каждый делает свою не очень интересную табуретку, но у них есть идея сделать какую-то крутую штуку, и они уже используют другие скиллы. На таких интересных самоорганизованных проектах выявляются таланты, которые так просто не видишь, потому что человек делает табуретку, просто пилит что-то квадратное и параллельное.

Николай Суетин: Может, я скажу парадоксальную вещь, но крупной устоявшейся компании таланты не нужны. Им нужны хорошие высококлассные исполнители. Устоявшийся процесс, всё идет. Таланты — это только возмущение существующих процессов.

Реальная жизнь такова, что человек с новым проектом никому не нужен, потому что уже есть нормальный cashflow, и никто не позволит рисковать достаточно сильно, те же акционеры. Я знаю много случаев, когда люди уходили из компании, делали спин-оффы — хорошая компания позволяет делать спин-офф, — и потом их обратно покупали. Талант — это человек, который может сформулировать свою задачу. Если она не принята компанией, он готов пойти на риск, уйти из компании, сделать следующий шаг, поднять эту задачу до решения и потом выйти на рынок как стартапер или вернуться в компанию в результате acquisition.

Андрей Плахов: Экспертами затронута интересная тема «а что, так можно было?». Откуда люди узнают, что так можно? Вот Алексей говорит, что у меня такая-то информация, что бы вы сделали на моём месте? А Александр приходит с задачами более-менее плохо поставленными, но время от времени спрашивает и людей, на которых он поставил крест, что им мешает. И если они скажут, что им не хватает ровно таких задач, то он дает им второй шанс. Откуда они узнают, что так можно было? Как человек узнает, что в этой организации можно так, а можно иначе? А где-то талант вообще не нужен и лучше сделать свой спин-офф – так тоже можно было.

Алексей Шаграев: Этот вопрос тесно связан с вопросом про то, зачем нам вообще какое-то публичное признание в любом виде. Не готов говорить про конкретный механизм, но ответ такой: компания должна давать обратную связь людям. Очевидно, у неё есть конкретные представления о том, что хорошо, что плохо, бизнес-показатели, социальные обязательства и так далее, она должна давать обратную связь, чтобы люди понимали, что здесь считается хорошим, а что – не очень. Она должна быть публичной, потому что нет смысла на примере какого-то опыта обучать только одного человека. Почему бы не сделать это более глобальным?

Как люди узнают, что так можно было? Они смотрят на людей рядом с собой. Те периодически что-то делают; на них смотрят и делают свои выводы, почти по Бэкону.

Андрей Плахов: Это хорошая теория, но она противоречит максиме, что хвалить нужно публично, а ругать приватно. В твоей парадигме и хвалить, и ругать надо публично.

Алексей Шаграев: Мне кажется, любой руководитель способен выработать правильный способ. Уверен, это можно соединить. Часто отсутствие похвалы — тоже какой-то сигнал. За хорошие вещи хвалят, а вот эти ребята сделали что-то и их не похвалили — всё понятно же.
Ответ простой: надо смотреть на других людей и максимально передавать поток опыта между людьми, только так это работает.

Андрей Плахов: Всё речь про то, как вышестоящие руководители выдают фидбек организации под собой и публично хвалят одного. Из этого остальные понимают, что надо действовать так же. Нужно ли и как настраивать обратный поток информации, когда люди ниже по организации в формате постмортема или еще как-то рассказывают своим смежникам или даже руководству, что им помешало или помогло проявить свои таланты?

Александр Горный: Отвечу не предыдущий вопрос. Чем больше люди общаются и видят, что происходит слева, справа, тем больше они видят, что можно, что нельзя, что работает хорошо, что плохо.

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

Андрей Плахов: Пара часов раз в три месяца на команду какого размере?

Александр Горный: 7-10 человек. Но предполагается, что тим-лид тоже вместе с ними работал, а не первый раз вместе со мной увидел этих людей.

Сергей Бережной: Присоединюсь к Александру. Очень хорошая практика, помимо регулярных встреч один на один руководителя со своими подчинёнными, регулярная встреча один со многими руководителя со всеми своими подчиненными, и ещё более верхнеуровневые встречи, когда и один на один руководитель более высокого уровня со своими подчиненными встречается, и один со многими руководитель встречается с поддеревом своих подчинённых. Типа когда я, будучи руководителем отдела, собираю весь отдел, включая все службы и группы, и у них есть возможность задать мне вопрос. Когда СТО собирает всю компанию и имеет возможность ответить на произвольные вопросы, а люди имеют возможность эти вопросы задать. Это самый естественный способ, который, как телеграф, в любой компании должен работать, донесение информации по иерархии, по дереву.

Вопрос: Мы тут разговариваем про выявление талантов, и есть разные талантливые люди, которые не факт, что нам в компании нужны. Мальчик с феерической памятью сейчас намочит первые три ряда, прекрасный талант у мальчика.

Есть разные таланты, которые попадают или не попадают в нашу компанию, некоторые нам нужны, некоторые нет.

Как понять, какие таланты нам нужны, и как под их конкретную формулу сделать машинку выявления этих талантов? Вопрос с продолжением.

Дмитрий Долгов: У человека может быть огромное количество талантов, невостребованных в работе. Может, он программист, а ещё замечательно играет на пианино и поёт. В каком-то виде, возможно, оно чуть-чуть применимо к работе, если он занимается озвучкой или чем-то ещё, но во всём остальном, пожалуйста, можно петь сколько угодно в свободное от работы время.

Необязательно у человека должны быть только рабочие таланты и необязательно все его таланты применять.

Андрей Плахов: Я знаю нескольких людей, которые изобрели такую машинку независимо друг от друга, и один из них – ты. Машинка эта выглядит как спецкурс в каком-то вузе. Свой спецкурс можно сделать ровно под выявление талантов, которые нужны.

Дмитрий Долгов: Что не отменяет того, что у меня работают певцы и музыканты.

Андрей Плахов: Безусловно. Мне кажется, ты являешься автором такой машинки. Надеюсь, это не секрет.

Дмитрий Долгов: У меня было замечание касательно обсуждения, что в компаниях, где процессы устаканены, не требуются таланты. Согласен с небольшим контрпримером. Если слесарь работает на станке, вытачивает одни и те же детали, в принципе, какие нужны таланты? Сиди да работай. С другой сторон, потом приходит Форд, смотрит на это и изобретает конвейер.

Андрей Плахов: Уходит из компании в свою.

Дмитрий Долгов: Но можно было бы это сделать и в компании. Даже когда процессы отлажены и все работает, как часы, существует возможность вносить новшества и инновации.

Ирина Федулова: Продолжу тему общения руководителей с подчинёнными. Есть ещё один уровень взаимодействия – горизонтальный – между техническими людьми. У меня была практика, когда организовывались что-то типа митапов, когда технические специалисты для сейлов рассказывали, какие они крутые штуки делали, сейлы говорили, что круто, есть потенциальный клиент, для него давайте запилим штуку. И под это организуется ad-hoc блиц-команда из кусочков людей, и в процессе выявляются таланты. Человек на самом деле писал что-то для мейнфрейма, а тут — бац, оказывается, он прекрасен в data science. Горизонтальные встречи технических специалистов друг с другом. Они рассказывают о том, чем занимаются. А другие рассказывают о том, что им нужно. Такие горизонтальные связи.

Николай Суетин: Есть ещё практика внутрикорпоративной мобильности, о чём Ирина упоминала. Очень полезно, когда человек на три месяца пошёл в сейлзы или маркетинг. Казалось бы, техническому человеку это по барабану, но в результате оказывается, что он узнаёт такие тонкости, о которых раньше не подозревал. И это сильно может даже поменять его карьеру. Эта практика must, не то, что «хочу — делаю, хочу — нет», должен три месяца в год где-то отработать. Начиная с некоторого грейда в некоторых командах рекомендуется.

Дмитрий Долгов: Что касается информационного обмена со встречами один на один, один ко многим, это, безусловно, задача и для выявления, и чтобы узнавать, что так можно было. Информационный обмен – это очень важная составляющая любой компании, любого процесса. По крайней мере, у нас на длительных сроках разработки проектов, когда мы шутим, что на этом проекте разработчики уже начали умирать от старости.

Бывает автобусный коэффициент, когда какого-то ключевого человека сбивает автобус, как сильно будет заторможена или остановлена работа. Бывают ситуации увольнения. Всё, что угодно, бывает. У нас даже были случаи полного расформирования команды и набора новой команды для продолжения работы.

Информационный обмен — не только устное общение. Обязательно нужно документировать всеми доступными способами, это необходимо банально для того, чтобы проект мог развиваться и жить в течение долгого времени. Думаю, это не только для игр актуально, наверняка и в долгоиграющих сервисах Яндекса это необходимо.

Касательно «а что, так можно было». У человека в любой задаче есть возможность вскочить на ступеньку выше, чем это описано в задаче. Вопрос «а что, так можно было?» можно переформулировать так: «разрешено все, что не запрещено». В любой разработке существуют некие ограничения. Грубо говоря, есть стартовая точка, где мы находимся, и мы хотим получить проект, который находится где-то выше. Наше идеальное продвижение к нему вперед: получили задание, сели работать, через два года выдали замечательный сервис или отличную игру.

По факту получается не так. Этот путь — сложная линия, которая приведет нас либо в эту точку, либо где-то рядом. Часто бывает, что во многих ситуациях разработки или действий отдельных людей, они нас не приближают к точке решения, а уводят далеко. Чтобы этого не происходило, существуют ограничения, которые надо ставить, чтобы не принимались неправильные плохие решения. Это может быть во всем: использование методологий, языков, middle ware, использование системы документооборота, контроля версий — что угодно, во всех этих случаях бывают ограничения. А дальше всё, что не запрещено, разрешено. Любые действия сотрудников, которые поднимают нас на ступеньку и приближают к решению проекта, являются однозначно полезными, должны быть обсуждены и зафиксированы как лучшие практики.

Вопрос: Здесь разговор больше об индивидуальных качествах разработчика. Но они же не по отдельности работают, а вместе. Что вы думаете о такой ситуации: есть три человека, они по отдельности работают плохо, а вместе – хорошо, или наоборот.

Сергей Бережной: Ровно это я имел в виду, когда говорил про искусственную кладку, что каждая ситуация уникальна и людей прежде всего мы подбираем гранями друг к другу. И конъюнктура того, что у нас открылось место тим-лида в какой-то команде, совсем не означает, что этот тим-лид должен обладать компетенциями руководителя и всё. Конъюнктура от команды к команде может отличаться. Там люди, условно, более инициативные и прокачанные в какой-то области, там менее. В зависимости от этого тим-лид, которого мы поставим на это место, должен обладать разными компетенциями. И дело не только в тим-лиде. Просто открылась вакансия в команде, и в зависимости от того, как распределены компетенции других участников команды, в чём они сильнее, в чем слабее, эту новую дырочку нужно занимать разным человеком. Как раз это я называю гибкостью и эффективностью. Если мы будем смотреть на эти вакансии как на абстрактные вещи, мы потеряем какой-то процент эффективности.

Вопрос: Как вы узнаете, сработаются они или нет?

Сергей Бережной: Интуитивным экспертным мнением. Подумаю, насколько они друг к другу подходят, на основе опыта подобных экспериментов, с кем раньше этот человек срабатывался, и с кем срабатывались те, к кому я его подселяю. Длительное наблюдение, история.

Александр Горный: Тут работает универсальный менеджерский тул — спросить. «Вася, тебе понравилось прошлый раз работать с Петей?» – «Да, было офигенно». И Петю спросить — «Было офигенно». Значит, сработались, результат был хороший. А если один говорит, что Петя все завалил, а я все делал, а тот на Васю валит — значит, не сработались. Всегда так. В лоб спрашиваешь, получаешь ответ. Конечно, бывают градации между идеальной сработанностью и несработанностью. Сравниваешь. Они же не скрывают. Это не тайна, которую надо узнать. Это надо спросить и узнать ответ.

Ирина Федулова: И в конце концов можно понаблюдать за происходящим. Ещё случай из практики, когда было четыре человека, над похожими проектами работали два и два. Мы видим, что-то не клеится, мы решили их переставить по-другому два на два, и сразу пошло. Просто понаблюдать.

Александр Горный: Не совсем согласен. Наблюдать надо очень внимательно. Ругающаяся пара может быть очень хорошо сработана. А молчащая может как понимать друг друга с полуслова, так и просто ненавидеть, поэтому не говорить.

Ирина Федулова: Я за результатом наблюдала.

Дмитрий Долгов: Снова эти секретные менеджерские списки, характеристики людей, информация о том, с кем и как успешно они работали в предыдущих задачах. Но все зависит от специфики задач. Ставить на рутинную задачу двухмесячной давности четырех лидов с ярко выраженными характеристиками склонностью к обучению, принципиально разными подходами к концепции архитектуры разработки софта — это смерти подобно, они скорее разбегутся через неделю с матами. С другой стороны, поставить на этот проект четырех слабых джуниоров – они не смогут склеить.

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

Алексей Шаграев: Тоже расскажу историю, хочется подсыпать дровишек в этот вопрос. Бывает ещё так, что люди поодиночке классные, а вместе вообще жесть какие классные. Есть у меня девлид бэкенда, девлид фронтенда, дизайнер и менеджер. Все они – замечательные люди, я вижу, они с открытой душой, любят слушать других и всё такое. Думаю, было бы классно, если бы они друг друга учили, общались, чтобы они всё время рассказывали, что делают, вырабатывали общие планы.

Это привело к тому, что дизайнер придумал, условно, JSON на фронтенд, тот реализует дизайн, с этим пользователи взаимодействуют… В итоге дизайнер придумал формат ответа бэкенда для фронтенда, чтобы как можно больше разных визуальных элементов мы могли запускать в продакшен, проверять в экспериментах, которые ложатся во множество возможных концепций. Переход позволил большое количество экспериментов запускать с бэкенда, это очень быстро, дизайнер в процессе это понял, придумал такой формат, который позволил все его идеи реализовать.

Андрей Плахов: А как такого результата достигли? Сидели в одной комнате, ходили вместе обедать? Что повлияло?

Алексей Шаграев: Люди разных специальностей и при этом все успешные, если их оставить в одной комнате, обязательно подерутся, каждый считает себя гением, и с ним сложно спорить. Поэтому начало было таким, что каждый из них всем другим рассказывал, что они делают и какое здесь обоснование, и в процессе нужно было, чтобы был авторитетный человек, который расскажет, что то, что те ребята говорят, это не ерунда, это разумно. И когда они проникаются пониманием, почему что-то делается конкретным образом, у них это взаимопроникновение происходит.

Вопрос: По поводу списка талантливых сотрудников. На каком уровне они работают? Если ты руководитель, у которого 70 человек в подчинении, и тебе нужно собрать команду из 7 человек, все списки у тебя хранятся, у тим-лидов собственные, у руководителей тим-лидов собственные, а потом только наверху эти списки скрещиваете.

И в каком именно формате эти списки хранят? Вася, 2007 год, работал с этим-то. Как ими пользоваться, когда у тебя 70 человек в подчинении, и информация о каждом растёт каждый месяц, кажется, это все неуправляемо.

Александр Горный: У меня максимум было 150 подчиненных. Информация о том, кто из них талантлив и в чём, у меня хранилась просто в голове в формате, что когда в задачу попадает Петя, то всё офигенно быстро делается, а когда попадает Вася, то всё делается офигенно быстро, но потом надо два раза переделывать.

У тим-лидов, конечно, была примерно та же информация, но более точная и качественная. И важно, какое решение надо было принять. Либо надо раздать новую задачу, тогда, если она рядовая, она до меня не доходит, а если не рядовая, у меня в голове есть несколько кандидатов, я их посажу с тим-лидами. Если надо кого-то поднять — то же самое. Никакого монстроидального Excel не было.

Алексей Шаграев: У меня нет таких списков, я верю во всех людей. Еще я считаю списки довольно опасной штукой, потому что бывает так, что люди зарабатывают какую-то репутацию и невозможно от неё отделаться. Бывает, что Петя плохо сделал проект Х, прошло пять лет, он делает совсем другое, а у меня засело в голове, как он мне тогда напортачил. Мой мозг должен быть свободен от этого. Мне важно, кем он является прямо сейчас. Поэтому хранить за 500 лет историю всех успехов и провалов сотрудников и предъявлять им, что они недостаточно талантливы и три года назад что-то не то делали… Не хочу такого.

Вопрос: Поскольку мне по роду занятий приходится вести интервью, мы в обязательном порядке разговариваем с кандидатами об их провалах. Good weather doesn’t make good sailor. Невозможно научиться чему-то, не ошибавшись. Каждый админ в обязательном порядке однажды грохнет продакшеновую базу. Нам нужен кто-то, кто уже грохнул.

Сергей Бережной: По иерархии поднимаешь. Количество подчиненных семь плюс-минус два и плюс-минус каждый руководитель про своих подчиненных в таких терминах должен знать очень подробно без всякого Excel. Ты можешь знать чуть менее подробно, как Саша сказал, и когда наступает момент принятия решения, вы собираетесь в комнате, озвучиваете задачу и принимаете решение. И если кому-то интересна моя рекомендация, сэкономьте свое время на составлении таких списков, они не помогут, они не позволят вам эффективно принимать решение, на мой взгляд.

Дмитрий Долгов: Поскольку я произнёс словосочетание «секретные списки», поясню, что это совершенно не означает записей в блокноте, в Excel под паролем или что-то такое. Это информация, которая может быть как-то классифицируема, начиная с грейда, хобби и основных скиллов человека, она может быть представлена в голове. Есть 70 человек, по ним хранить подробную информацию физически невозможно. Рекомендация семь плюс-минус два есть, но обычно получается, с кем можно работать более-менее эффективно, это максимум 15-20. Дальше идет сильное падение качества.

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

Ирина Федулова: 70 человек уже работают, чем-то заняты. Мы же не можем просто выдернуть семь человек.

Вопрос: Суперважный проект.

Ирина Федулова: И допустим, он временный. Нужно поднапрячься и вдобавок к своим обязанностям что-то сделать?

Вопрос: Найти семь человек, найти важный проект и потом их распустить.

Ирина Федулова: На это у нас был список, как раз который формировался из посетителей и участников этого коммьюнити, людей, которым интересно делать что-то дополнительное к своим обязанностям. Напротив фамилии стоял не цвет штанов, а просто скиллы, то, чем они умеют заниматься, и чем им хотелось бы заниматься, и мы матчили эти скиллы под задачу.

Андрей Плахов: Вы про это просто спрашивали людей время от времени?

Ирина Федулова: Да, в процессе внутренних митапов.

Дмитрий Долгов: У меня опыт ограничен игровой индустрией, но у нас ситуация, что есть суперсрочный проект, давайте на него сдёрнем семь талантливых людей, они за месяц это поправят и вернутся к прямым обязанностям. Это работает крайне отвратительно. Ситуация, когда человека на проекте сдергивают для решения других задач – само по себе большой стресс. А если ещё есть необходимость каким-то образом разбираться, погружаться в уже идущий, кем-то начатый проект, какой-то командой, которая не справляется – это скорее сильный демотиватор, чем помощь в разработке.

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

Андрей Плахов: Как растить человека вместе с задачами? Что делать, если прямо сейчас в организации нет подходящих задач на вырост для талантливого сотрудника, а он уже явно готов на себя взять больше? Или, наоборот, появилась новая задача, она явно сложная, и непонятно, кто из них с ней справится, и тем не менее все, кто дорос до этой задачи, заняты, и выдернуть их нельзя. Есть хорошие практики на эту тему у вас? Что вы думаете?

Николай Суетин: Бывает, что сдёргивают людей, в том числе топ-менеджеров, и сидят, кодят, каждый проверяет, такие случаи были. Поэтому если есть проблема, на которую у вас нет ответа — надо нанимать новых людей, соответствующих уровню.

Если у вас есть сильные ребята, которым, как вы понимаете, некуда расти, им надо честно об этом сказать, что пока для вас нет работы. И для них это некий сигнал. Вы говорили, чтобы не уезжали. Почему? Если мы играешь в хоккей во дворе, это ещё не значит, что хорошо будешь играть в НХЛ. Вот если в НХЛ хорошо играешь, это уже критерий. Так и тут. Если человек может зарекомендовать себя в Долине — это классно. Почему вы хотите его ограничивать? Нельзя свои личные интересы как менеджера ставить выше интересов людей, у которых есть потенциал развития. Считаю, надо честно сказать.

Александр Горный: Есть три разных ситуации. Есть отдел, который делает админку: каждый день новая страничка, новый запрос красиво вывести, работа обезьянья – доски в заборе. А рядом сидит отдел, который строит космический корабль, где всё очень круто, сложно и интересно. У человека в первом отделе нет интересных задач. Во всей моей практике и в теории так следует, что всем экономически целесообразно перетащить его во второй отдел, если он хочет и может, там он нужнее. А доски в заборе забивать — найдём. И проблемы нет, надо просто перетаскивать.

Другая ситуация, когда ни у кого нет больше интересных задач, все делают что-то неинтересное. Тогда надо увольняться и, скорее всего, именно вам – если у ваших подчиненных нет интересных задач, то что вы здесь делаете? Индустрия пока позволяет, можно найти что-то, где интересно.

В моей практике самая стандартная проблема, это когда задача есть, а решать её некому, так чаще. И надо давать её тому, кто не готов, но минимально не готов, в бою ему помогать, если ему интересно до ночи сидеть, он станет готов. Ничего другого не придумано. Ни разу не видел, чтобы какой-то глубокий тренинг сделал левелап. Работа до ночи — легко.

Андрей Плахов: Да, голодный обморок.

Александр Горный: Да, а тренинги – нет.

Дмитрий Долгов: Регулярно цейтнот в плане человеческих ресурсов. Задачи есть всегда, и задачи интересные. Если почему-то так получается, что для человека не существует интересных задач для роста, то – в геймдеве по крайней мере – почти всегда можно найти R&D задачи, которые, может, конкретно сейчас не нужны, но человек может уделить какое-то время исследовательским задачам и расти самостоятельно, показывать результаты, успех, в параллель с основной рутиной. Рутина — это всегда опасная вещь, она может любого человека вывести из себя. Талантливого – даже быстрее, чем рядового исполнителя, который тихо с утра до вечера сидит и закрывает тикеты.

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

Сергей Бережной: Идеальное решение проблемы, когда человек заперт в рутинных задачах, — попытаться сформулировать ему задачу избавления от рутины. Если он постоянно верстает маленькие лендинги, попросите его сделать конструктор этих лендингов, чтобы их не нужно было верстать, чтобы они либо менеджерами делались, либо вообще машинным обучением подбирались. Когда человек постоянно делает регулярную работу, озадачьте его изобретением конвейера – это самая лучшая next level задача.

Вопрос: Хотел бы вернуться к вопросу, когда есть сложная задача, но человека нет. Как поступить, если вы дали человеку сложную задачу, и вдруг у вас появляется внешний специалист, который может с ней справиться хорошо. Что тогда делать с тем, кому вы изначально ее дали? Возникает конфликтная ситуация. Как быть?

Александр Горный: У меня была старая история: мы запускали первую версию Mail.ru Агент и первый программист с задачей не сильно справлялся, мы отставали. Наняли с рынка второго, в два раза усилили разработку. Всё стало ещё хуже, они начали работать вместе. Всё

Я поговорил с первым программистом, мы решили, что это не его, и предложили ему заниматься сервером. С сервером у него стало получаться хорошо, он сейчас топ-менеджер Mail.ru, история закончилась хорошо – Mail.ru Агент запустили почти в срок.

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

Вопрос: На моём опыте больше проблема даже не в том, что нет человека, который будет исполнять задачу – люди есть, но люди заняты тоже важными и непонятными задачами. У вас после этого очень богатый выбор: либо человека сдернуть с этой непонятной задачи, либо отложить, либо забить. Я видел все три сценария, и все три к хорошему не приводят. Что делать?

Александр Горный: Ну мир вообще плох.

Николай Суетин: Аутсорсить не пробовали?

Сергей Бережной: Каждую программу можно сократить как минимум на один байт и там останется как минимум один баг. Так же каждая команда, если мы подразумеваем, что люди развиваемы и улучшаемы, может развиваться и улучшаться, быть эффективнее, срезать углы. И когда мы говорим, что все супер-заняты, мы постулируем, что у нас статическое положение, от которого мы никуда дальше не сдвинемся. Всё, на нас можно поставить крест, сколько они сейчас делают — больше они делать не могут.

Это неправда. Каждый человек может стать лучше, сдвинуться дальше, и вопрос менеджерский в том, чтобы эту разницу, где мы перешли на автоматический процесс, где-то человек стал с первого раз code review проходить, где-то ещё что-то, эту разницу нужно сложить. И уже из неё проинвестировать в новый проект, который появляется.

Понятно, очевидно, не всегда дебет с кредитом сходится. Поэтому я тоже всегда удивляюсь, как так, что нет задач? Задачи есть всегда. Но не надо думать, что ситуация статическая. Если все люди при деле сейчас, то ни у кого нет резерва. Кто-то готов проинвестировать в своё развитие и поработать по выходным, кто-то недавно начал разрабатывать штуку, которая позволит нам не делать какой-то работы вообще, закрасить какой-то модуль и перестать его поддерживать, и подобные вещи. Это основной резерв.

Дмитрий Долгов: Ситуация ещё плоха тем, что, если люди заняты работой на 100% и возможности поставить новую задачу нет, это значит, вы в уязвимом положении. У вас любая ситуация, которая возникает, любой баг, любой экстренный внешний реквест, когда что-то поломали, куда-то что-то заинжектили, что-то ещё случилось – это задача, которая требует немедленной реакции команды или отдельных её людей, и все текущие планы по разработке она просто порушит, у вас спринты начнут сдвигаться, задачи не выполняться, майлстоун не будет сдан и так далее. В любом планировании какой-то гап должен оставаться, должно быть свободное время.

Да, я чаще сталкиваюсь с ситуацией, что у нас катастрофически не хватает людей, а задач очень много. Приходится стараться утрамбовать всё, что можно, в объемы спринтов, максимально близко сдвинуть майлстоуны и так далее, но при этом все равно требуется время, чтобы периодически останавливаться, перевести дух, отрефакторить что-то. Улучшить процессы, посмотреть, на что тратилось так много времени в предыдущих спринтах, посмотреть, нельзя ли это улучшить.

Этот вопрос выходит за рамки сегодняшней встречи, но для меня достаточно неприятная и неприемлемая в команде разработки ситуация, когда какие-то схожие баги приходится из недели в неделю ловить и отлаживать, и на каждый уходит по 4-5 часов. Когда второй раз ситуация случилась, основная задача либо руководителя группы разработки или техдира – в зависимости от ситуации, в том, чтобы понять, почему так происходит, и предпринять все усилия, чтобы такая проблема больше не возникала. Либо, если она возникает, чтобы на её диагностику и отладку можно было потратить 5-10 минут максимум.

Моя любимая тема с расследованием авиакатастроф. Одна из вещей, которая там всегда делается – что нужно сделать, чтобы подобные аварии не происходили в будущем? У нас все-таки не самолеты, не космическая техника, крэши и ошибки в программах не так критичны, хотя всё бывает. Но эти подходы тоже должны работать. Команда должна постоянно совершенствоваться, чтобы работать эффективнее и быстрее.

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

Реплика из зала: Видимо, я представитель редкого здесь типа команд, у кого бывает недостаток в задачах. Хотел поделиться опытом. Уже говорили, что талантливые сотрудники умеют сами находить задачи, создавать стартапы, следует их отпускать или не следует. Когда у меня была такая ситуация, я пообщался на регулярных встречах с сотрудниками, какие у них есть домашние pet projects, и подумал, как их можно применить либо напрямую к бизнес-деятельности компании, либо косвенно, либо совсем косвенно – например, они могут опробовать какие-то технологии, которые потом можно использовать в бизнесе. Как пример, когда не было для верстальщика работы, он сделал прекрасную интерактивную карту офиса, он изучил JS, новейшие 3D-трансформации, которые смог применить как красивые эффекты в нашем пользовательском интерфейсе.

Андрей Плахов: Как поощрять талантливых сотрудников и как не поощрять? Есть сотрудник, на которого у нас в душе особые планы, и он сам подозревает, что он top performer, высокого о себе мнения. Нам хочется его поощрить, но так, чтобы он не стал окончательно звездой и не смотрел на всех свысока. Или наоборот, поругать так, чтобы он не воспринял это, что я такой исключительный, меня поругали, меня тут не ценят и где-то ещё меня будут ценить больше.

Дмитрий Долгов: Безусловно, есть люди, которые могут вообще критику не воспринимать, лично знаком с такими. Вопрос, как их ругать, очень актуален. Вообще, отсутствие ругани — уже поощрение.

Прежде чем ругать любого человека, нужно понять причины, которые нас в эту ситуацию привели. Если мы не рассматриваем ситуацию откровенного вредительства и саботажа со стороны сотрудника, то мне хочется верить, что большинство людей у нас в компаниях —люди, которым работа интересна, которые замотивированы делать проект вместе с нами, одной большой командой, и их действия направлены на то, чтобы сделать проект лучше и интереснее.

Если у человека это не получается настолько, что мы хотим его отругать, то основной вопрос: почему такая ситуация сложилась? Например, человеку была поставлена не очень четкая задача или он её понял абсолютно иначе, чем задание, которое мы ему сформулировали. Или человек, обладая недостаточными знаниями в смежных областях или о том, как работают другие проекты, отделы, принял неверное решение. Или мы дали ему очень большую свободу действий в рамках решения задачи, и он сделал шаг не туда, куда должен быть.

Во всех этих случаях, если мы исключаем саботаж, проблема ругани — это в первую очередь вина руководителя, а во вторую – сотрудника.

Чтобы этого избежать, я сегодня поднимал тему ограничений. Чтобы сотрудников меньше ругать и чтобы они меньше ошибались, необходима система ограничений, чтобы человек знал, что если он ступит сюда, это bad practice для компании, проекта, разработки, чего угодно. Если он этот шаг делает, то можно говорить, что ты нарушил 218 правило компании, глава 4, пункт 1.

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

В идеальном мире при правильно выстроенных ограничениях проблем возникать не должен. Если возникают — это в первую очередь проблема ваша, а не сотрудника.

Александр Горный: Мне кажется, сотрудников вообще не надо ругать. Вот сотрудник поделил на ноль и главный домен компании начал циклически падать. Случилось плохо, сервис не работает, два дня восстановления из бэкапов. Случилась катастрофа. Что ему можно сказать? В чём смысл ругани? Если он нормально относится к компании, он понимает, что был неправ, ему стыдно. Если ему пофиг, то, что бы я ни сказал, ему пофиг. Бить нельзя.

Андрей Плахов: Не согласен. Это предполагает, что серьёзное отношение к компании — это бинарный признак, серьёзный или несерьёзный. Но есть люди – может, не все – которые после «ругани» в каком-то смысле начинают к делу относиться более серьёзно. Я видел это собственными глазами. Человек, которого наругали – почти в классическом смысле этого слова, серьёзнее начинает относиться к какой-то части своей работы.

Александр Горный: Есть ситуации, когда сотрудник не знает что-то плохое. Он сделал таск, который вроде бы за три часа делается, за три недели. Он сделал, тесты прошли, в бой выкачено, вроде как всё хорошо. И ему надо сообщить, что три недели — это фигово. Это не тот случай, когда всё лежало и видно, что фигово, а он может не знать. Может, это совпадает с тем, что говорит Андрей: мы расскажем, что так делать не надо, поскольку он этого не знал, и в следующий раз он это сделает быстрее, зная ожидания.

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

Сергей Бережной: И хорошо бы это делать как можно раньше. Если он делал три недели то, что нужно делать два дня, то ему об этом неплохо было бы сказать где-то на пороге второго дня и продолжать повторять в течение трёх недель. Чтобы не было такого, что он, условно, полгода работал, а ты ему говоришь, что надо было бы сделать в 10 раз быстрее. Вопрос регулярности обратной связи. Это как способ подсластить пилюлю ругани — лучше выдавать её по чуть-чуть и регулярно, нежели одним большим скопом в конце сессии.

Андрей Плахов: Какая регулярность правильная?

Сергей Бережной: Чем раньше, тем лучше, в зависимости от масштаба проекта. Если говорить про наши скрамы, то раз в две недели. Это средняя длина спринта, люди проводят демо, подводят результаты, понимают что-то. Дальше есть другие интервалы – раз в месяц, раз в квартал, раз в семестр.

Дмитрий Долгов: Ситуация, когда у человека одна неделимая задача на две недели — это серьезный вопрос к РМ. Это вопрос декомпозиции. Если одна задача со сроком исполнения в две недели, то её нормально прочувствовать и оценить физически невозможно. На моём опыте, более-менее вменяемый уровень декомпозиции задач, когда они могут быть оценены нормально и решены с погрешностью плюс-минус хотя бы 30-50%, — максимум пара дней. Если у человека задача, он её взял в работу две недели назад, две недели без какого-то выхлопа по ней работает и через две недели сообщает, что ещё месяц надо на задачу — что-то пошло не так. Двухнедельная задача должна быть декомпозирована.

Очень может быть, что в итоге декомпозиции там окажется 50 задач по одному дню. Запросто, это регулярно бывает. Мы большую задачу думали, оценивали, а когда поглубже разобрались, оказалось, там работы на два месяца. Но двухнедельная гранулярность планирования недопустима.

Вспомнил историю про то, как ругать сотрудников. В одной из игровых компаний у нас было прекрасное правило: падение игры без ассерта — минус пять баксов от зарплаты.

Николай Суетин: Вернусь к мысли, что постмортем мероприятия очень важны, когда проект кончается. Тут можно и хвалить, и ругать, но по факту. К срокам, кто-то сделал, кто-то не сделал, почему. Все эти разборки уже можно делать, если это не личное отношение, не эмоция, а нечто, основанное на фактах, и все участвовали в этих проектах и понимали, кто когда опоздал или сделал некачественно, это воспринимается нормально. И даже человек не персонально был виноват, а так сложилось, он понимает, что претензии к нему обоснованы. И хвалить, естественно, тоже. Если все вовремя сделали, зарелизили, то все счастливы, причастны к успеху и те, кто below expectations.

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

Николай Суетин: Даже не ругань, а разбор полетов.

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

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

Андрей Плахов: Чаще — это сколько? Вот у вас семь подчиненных. Сколько времени надо тратить на общение с ними, а сколько – на что-то еще? Из зала предлагают 100%.

Ирина Федулова: Похоже на правду. У меня в жизни был длительный период, когда мой непосредственный руководитель был на другом конце земного шара. Мы все равно общались каждый день. Это было три строчки в чате, но это всегда было очень полезно и важно. Даже такого размера фидбек помогает избегать неправильных шагов, чтобы потом не приходить к ошибкам и не нарываться на негативный фидбек. И позитивный фидбек в тех же трёх строчках помогал.

Алексей Шаграев: У меня нет психологического образования, но в психологическом консультировании считается плохой манерой, антипаттерном, давать конкретные советы людям. Паттерн хороший — помогать человеку найти ответ, который он и так знает, но не может себе в этом признаться. Задавая правильные вопросы, мы можем позволить ему с этим справиться. Я правильно говорю?

Хочу толкнуть похожую мысль: вершина искусства — когда в процессе выдачи фидбека человек учится саморефлексии и сам отвечает на вопрос, что было не так, что он мог бы сделать лучше и чему ещё ему надо научиться. И если он периодически, благодаря вам или сам по себе, думает, как ему стать лучше и чего ему не хватает, он естественным образом не зазвездится, потому что он всё время видит потенциал. Человек, который зазвездился, говорит, что он самый лучший, что он свободен от критики, что ему ничего не надо говорить. Это точно человек, который не думает о том, как он может себя улучшить.

Правильно ругать ровно так: помочь человеку понять, в чём он был не прав, но чтобы он сам это сделал и сформулировал.

У меня был конкретный опыт с начинающим тим-лидом, который не умел делать простую декомпозицию на уровне: есть задача, мы составим буллет-стайл план, а потом будем следить, что он сходится. Он составлял план (даже не сам), потом заполнял первую строчку и бодро шёл к выполнению первой строчки. Потом приходил, говорил — да, я молодец, я всё сделал. А я говорю — послушай, а где же ещё несколько пунктов?

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

Андрей Плахов: Давайте поблагодарим наших докладчиков. Очень рад, что в таком высокоабстрактном сеттинге мы выудили из них много крупиц интересного опыта. Большое вам спасибо.