Русский
Русский
English
Статистика
Реклама

Лидерство

10 полезных книг для менеджера и лидера в IT секторе

26.12.2020 20:23:24 | Автор: admin


Я работаю много лет в индустрии разработки программного обеспечения и последние несколько лет я активно вовлечен в консалтинг и pre-sales фазы. И я заметил, чтобы быть успешным лидером как для менеджера проектов, представляющего бизнес-сторону, так и для архитектора технического представителя необходимо совмещать в себе технические и лидерские качества.
Для меня наиболее полезным и эффективным источником обучения являются книги. И я бы хотел поделиться с вами топ 10, по моему мнению, книг полезных для начинающих и не только лидеров в разработке программного обеспечения. Эти книги помогут развить и улучшить лидерские качества необходимые в данной индустрии. Я не буду перечислять знаменитые менеджерские бестселлеры такие как Laws of Leadership или Good to Great. Я порекомендую более целевые книги, которые будут, несомненно, полезны именно лидерам в индустрии разработки программного обеспечения.
Название всех книг будут указаны на языке оригинала, но вы без труда сможете найти многие из них и в переводе.

Mythical Man-Month, The: Essays on Software Engineering




Mythical Man-Month, The: Essays on Software Engineering, Anniversary Edition

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

Death March




Death March (2nd Edition)

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

Consulting Outbreak: Manager and Software Architect Could be Friends




Consulting Outbreak: Manager and Software Architect Could be Friends

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

The Deadline: A Novel About Project Management




The Deadline: A Novel About Project Management

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

Waltzing With Bears: Managing Risk on Software Projects




Waltzing With Bears: Managing Risk on Software Projects

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

Herding Cats: A Primer for Programmers Who Lead Programmers




Herding Cats: A Primer for Programmers Who Lead Programmers

Эта книга будет полезна разработчикам, которые хотят развить лидерские качества. Если вы уже начали этот путь, то сможете улучшить и расширить свои знания. Автор очень последователен и точен. Он помнит, что вы еще разработчик и общается с вами как с разработчиком, в то же время улучшая ваши менеджерские и лидерские качества. Структура этой книги очень точная. В начале объясняется как примерять на себя роль лидера, а только потом рассказывается о правильном общении с командой и менеджерами высшего звена.

The Art of Project Management




The Art of Project Management (Theory in Practice (OReilly))

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

The Inmates Are Running the Asylum: Why High Tech Products Drive Us Crazy and How to Restore the Sanity




The Inmates Are Running the Asylum: Why High Tech Products Drive Us Crazy and How to Restore the Sanity (2nd Edition)

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

Crossing the Chasm: Marketing and Selling High-Tech Products to Mainstream Customers




Crossing the Chasm: Marketing and Selling High-Tech Products to Mainstream Customers

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

Inspired: How To Create Products Customers Love




Inspired: How To Create Products Customers Love

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

Перевод Как проводить эффективные личные встречи

01.02.2021 10:05:55 | Автор: admin

Практическое руководство для руководителей и подчиненных.

Насколько эффективны личные встречи, которые вы проводите?

Большинство руководителей скажут, что эффективность просто отличная. Однако исследование показало, что после личных встреч сотрудники часто остаются менее мотивированными, чем руководители. И меня это беспокоит.

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

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

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

Участвовать должны обе стороны

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

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

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

Советы подчиненным

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

1. Проясните свои цели и придерживайтесь их

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

Цели можно разделить на три категории:

  1. Деловые цели. Чего вы пытаетесь достичь в нынешней должности и каким образом вы будете измерять успех? Обычно для структурирования деловых целей используют OKR (цели и ключевые результаты).

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

  3. Личные цели. Есть ли другие важные для вас цели, не входящие в указанные категории? Например, важно ли вам повышение по службе? Смена должности? Хорошая физическая форма?

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

Деловые цели обычно обновляются каждые 6-12недель, однако поведенческие и личные цели также необходимо регулярно обновлять. Я рекомендую каждые несколько месяцев проводить личные встречи, пересматривать и обновлять свои цели.

Помните: достижение целей это ваша ответственность, а по сути даже ваша работа. Руководитель может помочь, но мотивация и принятие мер на вас. Если цели не определены на 100%, уделите время тому, чтобы прояснить их, и обсудите эту тему на следующей личной встрече.

2. Подготовьте отчет за период с предыдущей встречи

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

Полезная информация, которую нужно включить в отчет:

  • Текущее положение по метрикам и ключевым проектам. Если вы уже готовите что-то к собранию с отчетом для команды у вас эта информация уже будет.

  • Сводка о том, на что вы тратили время на прошлой неделе. Уделите полминуты: пролистайте календарь и посмотрите, на что ушло время вы можете удивиться.

  • Отчет по действиям, предпринятым с момента последней встречи. Ответственность ключевой момент, но подробно мы остановимся на этом позже.

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

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

Повестка дня личной встречи это два-три вопроса, которые вы хотите проработать с руководителем. Как правильно выбрать темы для обсуждения? Я рекомендую пройтись по следующим трем пунктам:

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

  • Описание эмоционального состояния в произвольной форме, начинающееся со слов Я чувствую, что Часто настоящие проблемы не появляются в отчете, потому что они сидят в голове. Перенеся чувства на бумагу, вы сможете прояснить, что (или кто) действительно вызывает у вас трудности.

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

При личных встречах обычно поднимаются следующие темы:

  • Обсуждение недавних трудностей по работе.

  • Нагрузочное тестирование какого-либо плана.

  • Лучшее понимание бизнес-стратегии.

  • Управление проблемными взаимоотношениями.

  • Обдумывание сложностей в коммуникации.

  • Работа с изолированностью и неуверенностью в себе.

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

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

4. Примите установку на рост

Руководитель хочет, чтобы вы добились успеха, это явная цель личных встреч, поэтому я рекомендую принять установку на рост.

Вы должны быть открыты и активно искать новые возможности совершенствоваться. Спросите себя: Как стать лучше в этой сфере?

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

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

5. Попросите дать обратную связь в смысле, совет

Большинство из нас не склонны к конфликтам и по возможности избегают обратной связи. Даже директора иногда избегают давать обратную связь некоторым своим руководителям (поверьте мне я знаю).

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

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

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

Советы руководителям

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

1. Обеспечьте психологическую безопасность

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

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

  • Признание. Что в отношении подчиненного вызывает у вас желание поблагодарить его?

  • Любопытство. Как себя чувствует ваш сотрудник?

  • Учет мнения. Что для подчиненного важно?

  • Уязвимость. Какие собственные слабые стороны вы пытаетесь исправить?

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

  • Над чем бы вы хотели поработать вместе?

  • Какие темы полезнее всего было бы обсудить сегодня?

  • Как провести это время с наибольшей пользой для вас?

2. Будьте готовы к роли коуча

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

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

  • Задавать вопросы. Так вы наделяете сотрудника ответственностью, а не берете всё на себя.

  • Внимательно слушать. Слушайте, что и как вам говорят и что остается невысказанным.

  • Синтезировать. Сжато обобщайте и проговаривайте услышанное.

  • Напоминать сотруднику о его целях. Мы все постоянно сами забываем о собственных целях.

  • Давайте сложные задачи. Так вы сможете вывести подчиненного из зоны комфорта.

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

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

3. Оставьте место для эмоций

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

Когда кто-то приходит к вам со своими проблемами, можно с уверенностью предположить, что этот человек много о них думал. Однако вполне вероятно, что он не проработал сопутствующие эмоции.

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

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

4. Наделяйте ответственностью

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

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

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

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

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

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

5. Попросите дать обратную связь в смысле, тоже совет

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

Можно спросить,

  • что, по мнению сотрудника, вам следует делать иначе,

  • что бы он сделал на вашем месте,

  • что позволит вам стать лучше как руководителю (коучу)?

Ваш успех как руководителя определяется успехом команды а значит, и успехом личных встреч с сотрудниками.

Как изменить поход к личным встречам

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

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

Любое изменение подхода хорошая возможность перестроить личные отношения. Я делаю это, задавая три вопроса:

  1. Разрешаете ли вы мне по-прежнему быть вашем коучем?

  2. Сможете ли вы рассказывать на личных встречах о самых больших трудностях?

  3. Согласившись предпринять оговоренное действие, обязуетесь ли вы выполнить его?

Пару слов о продолжительных беседах

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

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

Не знаю, стоит ли поднимать этот вопрос, но

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

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

Хорошие вопросы залог хороших ответов

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

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

Дэйв, у меня было озарение, сказал он. Я постоянно думал о вопросе, который вы задали. И через пару дней ответ пришел ко мне, пока я мылся в душе. Проблема решена!

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

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

Об авторе

Привет, я Дэйв. Я занимаюсь коучингом директоров технических компаний, находящихся на первоначальном этапе финансирования и до выхода на IPO. Также я веду подкаст The Founder Coach Podcast, личный Substack и программу коучинга под названием Clarity, которая помогает основателям компаний улучшить коммуникативные навыки. До этого я был сооснователем трех компаний, получивших финансирование от венчурного капитала, и два года проработал в венчурном бизнесе. Подробнее на моем сайте Dave-Bailey.com.


О переводчике

Перевод статьи выполнен в Alconost.

Alconost занимается локализацией игр, приложений и сайтов на 70 языков. Переводчики-носители языка, лингвистическое тестирование, облачная платформа с API, непрерывная локализация, менеджеры проектов 24/7, любые форматы строковых ресурсов.

Мы также делаем рекламные и обучающие видеоролики для сайтов, продающие, имиджевые, рекламные, обучающие, тизеры, эксплейнеры, трейлеры для Google Play и App Store.

Подробнее..

Как компании отказаться от роли тимлидов

02.02.2021 10:16:21 | Автор: admin

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

В PropellerAds решили пойти по принципу нет человека нет проблемы и отказались от роли тимлидов. Как компании удалось это провернуть, не только не потеряв ни одного руководителя, но и успешно привлекая тимлидов из других компаний, в своем докладе на конференции TeamLead Conf 2020 рассказал глава продуктового отдела PropellerAds Яков Беккер.

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

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

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

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

Что еще, кроме предоставления статуса и спуска распоряжений вниз, хочет от тимлида руководство?

Ожидание: функции тимлида

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

Руководство надеется, что тимлид будет управлять процессами в команде, и станет выполнять роль менеджера продукта или проекта. Хотят, чтобы он понимал domain.

Кроме того, тимлид должен отвечать за качество. Багов быть не должно, особенно в продакшен. Руководитель не хочет, чтобы его разбудили в 3 часа ночи, чтобы уведомить, что все упало и не работает. Очень удобно, когда есть человек, который отвечает за такие вещи и знает, как все оперативно исправить.

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

Кого же нужно найти?

Руководители ищут некого сказочного единорога мира кода, который должен уметь делать все. Но в реальности его не существует.

Реальность: проблемы в работе тимлида

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

  • Вся ответственность ТОЛЬКО на тимлиде;

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

  • Отсутствие делегирования;

Часто тимлид перестает делегировать, потому что боится за качество и результат. Или он не умеет делегировать и не понимает, как делать это правильно. Многие думают, например, что делегирование это просто спускание тасков вниз.

  • Mикроменеджмент;

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

  • Слабое руководство вызывает недовольство команды;

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

Вся команда только и говорит о том, как плох тимлид.

  • Тимлид выгорает;

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

  • Проблемы при уходе тимлида из компании;

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

  • 25% лучших разработчиков не пишут код.

Представьте, что у вас были звезды разработки. Они писали код, а теперь его не пишут. Это ситуация 25% лучших разработчиков не пишут код должна приводить в ужас любого CTO.

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

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

И есть другая команда:

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

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

Но в PropellerAds структура управления устроена по-другому, и это работает.

Решение: самоорганизующиеся команды

В PropellerAds есть продуктовые команды, которые стоят в центре системы компании. В них входят:

  • Владелец продукта (Product Owner) это человек, который разбирается в продукте, работает с бизнесом, строит бэклог, менеджерит риски, пишет User Story и прочее;

  • Разработчики, scrum-мастер;

  • Тестировщики;

  • DevOps.

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

Где же руководители? Они есть у каждой функциональной группы (PO, разработчиков, тестировщиков, DevOps).

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

Функциональные менеджеры в курсе всего происходящего в компании, и они в итоге несут ультимативную ответственность за успех. Но их цель не раздавать указания о том, что нужно делать, и даже не планировать. Их задача помочь. Например, скоординировать, какие команды должны быть вместе, донести стратегию компании.

Распределение обязанностей в команде

Кто занимается разработкой кодом, дизайном, архитектурой?

Разработчики.

Кто занимается продуктом?

В продуктовой компании это очень важный вопрос. Например, стоит задача создать кабинет для рекламодателя. Нужно разговаривать с заказчиками каждый день. В PropellerAds PO этого направления ездит на профильные конференции, общается с рекламодателями, делает Customer Development, проводит вебинары.

Кто занимается управлением процессами в команде?

В PropellerAds нет выделенной роли scrum-мастера. Эту роль чаще всего играет не senior-разработчик, а тот, кому это интересно. Например, QA, DevOps или middle-разработчик (junior не может). Это должен быть человек, которому интересно этим заниматься.

Кто управляет инцидентами?

Логично выделить для этого DevOps-инженера.

Что с единой точкой входа?

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

Кто занимается наймом, ростом и мотивацией людей?

Эти вопросы полностью лежат на функциональных менеджерах. В компании существует оценка удовлетворенности функциональным менеджментом, и сейчас она 9,6. Это почти предел, и непонятно, как она может стать выше.

Почему все так здорово? Функциональные менеджеры целыми днями ведут планы персонального развития, делают one-on-one, правильно проводят квартальные ревью, никого не обижают. Они видят свою роль в том, чтобы их команде было хорошо, а отдельным людям было приятно работать в PropellerAds, чтобы специалисты развивались и через 3 года стали лучшими инженерами. Это одна из самых важных целей функционального менеджера.

Их задача заключается в развитии людей и в продвижении по эффективности.

Из-за того, что есть роли (PO ответственен за продукт, QA за инциденты и пр.) может показаться, что ответственность лежит на определенных людях. На самом деле, это не так, ее несет вся команда.

В компании используют Slack. как вы думаете, кого кастуют в случае инцидента? Чаще всего не конкретного человека, а всю команду. Например, кастуют команду Core, и отвечают три человека: PO, разработчики и QA каждый по своим вопросам. То есть точкой входа становится не конкретный человек, а команда.

Структура управлением бизнеса

Как в PropellerAds управляют бизнесом? Есть руководитель направления, например, определенного формата рекламы. У него в подчинении маркетинг, продажа и оптимизация. И этому руководителю выделяются 1-2 продуктовых команды, чтобы они выполняли 90-95% его тасков, и ему не пришлось искать помощь на стороне.

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

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

Структура управления технологией

В PropellerAds есть функциональный менеджер разработки R&D-менеджер.

Он организовал четыре направления и нашел тех, кто согласился их вести. Во главе направлений встали senior, каждый из них лидер. Кто-то ведет ротацию, кто-то данные, кто-то фронтенд, кто-то back office.

R&D-менеджер собирается с командами, строит технологическую стратегию, презентует ее на стратегической сессии и т.д.

Решение: все проблемы устранены

Что получила компания в итоге:

  • Ответственность всех членов команды от нее стало очень сложно спрятаться;

  • Несколько человек в команде являются точкой входа;

  • Командная работа вместо микроменеджмента;

  • Команды довольны руководством;

  • Лидеры не выгорают;Выгорают обычно от того, что человек занимается нелюбимым делом, или не способен сделать то, что от него требуют.

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

  • 25% лучших разработчиков снова ПИШУТ код.И это просто вау!

Проблемы

Выше нарисована, казалось бы, идеальная картина. И все же в PropellerAds есть определенные проблемы.

Проблема командной ответственности

Бывает, в одной из десяти команд, коллективную ответственность воспринимают так, будто ответственности не несет никто. И вот кастуешь команду из восьми человек по какому-то вопросу, а ответа нет. Пропустили Sprint Goal и это никого не волнует. Раньше по этому поводу нервничал бы хотя бы тимлид.

Управлять тимлидом легче, чем целой командой: его можно мотивировать, или поменять.

Эта проблема решается просто: в команде должно быть 2-3 лидера.

Обычно PO лидер по определению. Он строит продукт: как же он может не быть лидером? Остаются еще два: например, QA и разработчик. То есть должны быть ребята, которые тащат команду на себе, не потому что им сказали это делать, а оттого, что им самим это нравится они чувствуют азарт. В большинстве команд так и происходит.

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

Проблема управления матричной структурой

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

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

  • Доверие;

Очень важно доверять друг другу, потому что иначе команда не сможет функционировать.

  • Независимость;

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

  • Пассивный контроль.

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

Проблемы карьерного роста

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

Давайте задумаемся, чего хочет человек, который мечтает стать тимлидом:

  • Иметь авторитет и, как результат, получить влияние и независимость;

  • Саморазвиваться;

  • Зарабатывать больше денег.

Чтобы получить все это, можно построить карьеру внутри компании.

Карьера разработчика в PropellerAds

С тимлидами в компании было бы движение по иерархической лестнице. У них не было бы другого пути: хотели они или нет, но должны были бы превратиться в мифического единорога. И чем лучшими тимлидами они могли стать, тем дальше могли продвинуться по карьерной лестнице. И если CTO уволится, то получится получить его место! Но часто ли вы видели увольняющегося CTO?

Сейчас в PropellerAds можно стать функциональным менеджером. У СТО есть команда из шести человек: Head of Analytics, R&D менеджер, Head of QA и люди, которых можно назвать руководителями высшего звена.

Можно стать техлидером, или product-менеджером, они всегда нужны: каждый квартал что-то происходит. Как этого добиться? Поинтересуйтесь продуктом, domain, клиентами, сходите на курс, предложите себя.

Если вы middle-девелопер, можно стать scrum-мастером, или коучем.

Кроме того, можно вырасти в business owner.

Все в руках сотрудников.

Изменение структуры

Легко ли создать структуру, которая сложилась в PropellerAds? Относительно тяжело. Гораздо проще организовать иерархию тимлидов.

Описанная система гораздо сложнее, в ней много противоречий. Но в PropellerAds без тимлидов достигли гораздо большей эффективности, чем раньше. И с гораздо более счастливыми людьми.

TeamLead Осень 2020 пройдет 29 и 30 апреля 2021 года. Приобретайте билеты и становитесь частью единственной профессиональной конференции только для тимлидов.

А программный комитет Saint TeamLead Conf 2021 ждет вашидоклады.

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

Подробнее..

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

04.06.2021 08:06:10 | Автор: admin

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

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

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

Содержание.

Что изучить еще до выхода на работу

Блог Уилла Ларсона

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

Книга Первые 90 дней Майкла Уоткинса

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

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

Также я изучал отзывы на книгу, и нередко они сводятся к мысли: за первые 90 дней нужно показать успех любой ценой. Лично я такого посыла не увидел, но, даже если он есть, вот две статьи Уилла Ларсона для баланса:

  • The rush to "show value" поясняет, как не наломать дров в стремлении быстро показать результат.

  • Your first 90 days as CTO or VP Engineering статья для лидеров уровнем выше, но полезна как карта куда направить внимание в первую очередь.

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

На старте. Собираем контекст и ожидания

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

Ниже я опишу, как на старте собирал контекст и устанавливал нужные коммуникации.

Сразу зарезервируйте время на обучение

Когда-то давно я прочитал про такое явление как спираль сделанной работы (к сожалению, не помню, где читал). Смысл этой спирали в том, что чем больше работы вы делаете, тем больше работы вам придется делать в дальнейшем.

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

Если мы не следим за балансом обязательств и копим незавершенку, то мы становимся все больше должны. Спираль может закрутиться до состояния, когда без нас уже ничего не может быть сделано, и мы вынуждены крутиться, как белка в колесе, чтобы поддержать хотя бы текущие обязательства. Еще это печальное состояние известно как bus factor = 1.

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

Понаблюдайте, как идет работа в компании

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

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

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

Daily sync с командой

Классический stand up meeting. Здесь я понял текущие боли проекта, настроение команды, кто в чем профи, есть ли тлеющие или явные конфликты.

Также этот митинг отличное время, чтобы легализовать себя в команде. Расскажите о своем прошлом опыте, чем вы увлекаетесь в жизни, как планируете действовать.Например, я рассказал, что не намерен крушить и строить заново, что сначала буду просто наблюдать. Что постепенно поговорю с каждым на 1-to-1, но только когда наберусь контекста, чтобы разговор был предметным.

Lead sync

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

Статус-митинг с PM и вице-президентом

Это митинг уже конкретно по нашему проекту как идут дела сейчас, и какие планы на ближайшие недели.Здесь я узнал про текущие вызовы проекта, "протокол" взаимодействия с топ-менеджментом, принятую степень открытости в обсуждении проблем. Открытость оказалась максимальной, и это очень помогло в дальнейшем действовать уверенно.

Meet & Greet

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

Хорошо. Мы понаблюдали, изначальное представление о происходящем составили. Что дальше?

Проведите несколько встреч сами

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

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

По ходу каждой встречи делайте заметки и поделитесь ими с собеседником, попросите проверить, что вы ничего не исказили. Потом извлеките из заметок действия, которые вам (возможно) предстоит сделать. Также проанализруйте заметки со всех встреч на предмет противоречий взглядов или потерь информации между разными сторонами. С этим тоже предстоит поработать.

Вот какие я провел встречи и что мы на них обсуждали.

1-to-1 с PM проекта

Эту встречу я провел в конце первой недели. Мы проверили мои первые предположения об основных вызовах на проекте и восполнили пробелы в моем понимании ситуации. Также советую обсудить с PM, кто из вас чем занимается в повседневной работе. Это поможет избежать двух ситуаций:

  • Вы оба не сделали что-то, ожидая, что это сделает другой.

  • Вы залезли на чужую территорию без спроса. Люди болезненно реагируют на такие ситуации. Особенно если вы станете менять или критиковать то, над чем ваш коллега уже давно и кропотливо работает.

Список вопросов, с которыми я пришел на встречу с PM.
  • Каков общий ландшафт проекта и ключевые ценности для бизнеса?

  • Какие главные боли бизнеса в связи с проектом? Над чем явно стоит поработать в первую очередь?

  • Какие компоненты системы критичны, и кто их стейкхолдер?

  • Могу ли я понаблюдать за работой конечных пользователей?

  • Какие у команды есть обряды? Синки, ретроспективы, планирование, backlog triage? Как проходят эти встречи, и есть ли замечания к их эффективности?

  • Почему выбрали именно kanban (scrum, lean, любую другую методологию)? Какие плюсы уже ощутили? Какие ожидали, но не получили?

  • Ключевые эпики, roadmap на год, интересы стейкхолдеров.

  • Какая сейчас температура в команде, на проекте, в отношениях со стейкхолдерами?

  • Какие с точки зрения PM планы по техдолгу, багам, внепроектным активностям?

  • Стоит ли нам общаться 1-to-1 регулярно или хватит рабочих встреч?

1-to-1 с непосредственным руководителем

Эту встречу мы провели в начале второй недели.

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

Подход тот же: заранее подготовить вопросы, проверить гипотезы, пополнить контекст. После встречи извлечь список возможных действий.

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

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

  • Как менялась динамика команды и ее отношения с бизнесом со сменой тимлидов в прошлом? Как давно это происходило?

  • Мой подход в целом, как планирую действовать в ближайшее время.

  • Какие планы у компании на этот год и глобальные планы?

  • Какие трансформации хочется провести в компании?

  • Есть ли подводные камни, о которых мне нужно знать?

  • Есть ли элементы культуры, которые стоит убрать? Что, наоборот, нельзя трогать?

  • Есть ли избыточные митинги или просадки в коммуникациях?

  • Какие основные риски в адаптации лида снаружи на твой взгляд?

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

Также очень рекомендую статью Уилла Ларсона Partnering with your manager. Она поможет построить с руководителем продуктивные отношения, а не просто приносить ему проблемы, с которыми он должен будет вам помогать.

1-to-1 с каждым участником команды

В отличие от предыдущих 1-to-1, с этими встречами торопиться не стоит. Вы будете иметь дело не только с проектными, но и с личными вопросами, поэтому важно приходить с максимумом контекста и минимумом домыслов и предвзятостей.

В моем случае предстояло провести девять встреч, и на них ушло полтора месяца.

Вот советы по подготовке к 1-to-1:

  • Прочитайте (или перечитайте) раздел про 1-to-1 в Team Lead Road Map.

  • Не стройте из себя супермена на встрече. Расскажите о своих прошлых провалах, не стесняйтесь говорить, что вам нужна помощь сейчас.

  • Записывайте любые положительные отзывы о коллегах. На 1-to-1 поделитесь с коллегой, что о нем говорит команда.

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

  • До общения с коллегой не читайте его HR-карточку и историю решения сложных вопросов. Фрейминг существует и это штука очень сильная. Даже если вам кого-то представили как low performer-а, сначала поговорите с ним лично и разберитесь с его мотивацией.

  • На первый 1-to-1 заложите часа два и оставьте свободным календарь после. Мало что будет хуже, чем в разгар личной беседы убежать на другой митинг.

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

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

Список вопросов, которые я задавал

Конечно, список неполный, поскольку каждый 1-to-1 включал ряд личных вопросов.

  • Хочешь ли что-то обсудить прежде, чем мы перейдем к моим вопросам?

  • Каким ты видишь общий ландшафт проекта, ключевые ценности для бизнеса?

  • В каких частях проекта ориентируешься отлично? В каких хотел бы подкачаться?

  • Чем бы хотел заниматься? Хотел бы забрать на себя целиком какое-то направление? Какого плана задачи интересны (например, менторство)?

  • Как по-твоему идут дела на проекте?

  • Какие главные боли проекта?

  • Есть ли что-то, что мешает в работе лично тебе?

  • С кем тяжело работать в команде? А с кем хотел бы работать чаще?

  • Опиши идеального следующего кандидата в нашу команду?

  • Какие самые большие и интересные штуки стоит сделать? Что нужно сделать уже в этом году?

  • Есть ли у тебя долгосрочное видение себя? Хочешь составить план роста вместе? Что изменить, чтобы работа больше способствовала твоим целям?

  • Восхищаешься ли ты кем-то в компании?

  • Как чувствуешь себя на удаленке?

  • Что можно поменять в митингах?

  • Чувствуешь ли ты перегруз? Недогруз?

  • Что ты думаешь о фидбеке и его количестве? Как часто будем проводить 1-to-1 в будущем?

  • Хочешь ли что-то узнать обо мне?

  • Как настроение после беседы?

Итог по проведенным 1-to-1

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

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

Записи с митингов сохраните, они помогут вспомнить детали в будущем. Детали точно вывалятся из головы, ведь на испытательном сроке новой информации много. Также записи помогут отслеживать прогресс и начинать каждый следующий 1-to-1 предметно.

Что полезного сделать, пока вы собираете контекст

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

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

Запишите, как проходил ваш найм

Комфортны ли были интервалы между собеседованиями и их количество? Было ли по ходу собеседований понятно, какой и когда следующий шаг? Получили ли вы оффер в виде красивого брендированного письма или это был просто неформатированный текст? Легко ли было найти офис и кабинет HR в первый день?

Запишите все, что было неудобно или вызвало вопросы. Оформите список идей и поделитесь в виде фидбека с HR и руководителем. Но именно в виде фидбека, а не критики. Не касайтесь личностей. Вместо что плохо, опишите как можно сделать хорошо.

Запишите, как проходили первые дни в компании

Был ли у вас buddy? Достаточно ли было информации о компании на старте? Может, слишком много информации, и голова пухла? Как быстро вы получили технику? Был ли полезен корпоративный мерч, который вам выдали в первый день? Запишите все, за что зацепился ваш мозг, каждую мелочь.

Моя адаптация была очень комфортной, но через три недели я отправил коллегам из HR список из 30 небольших идей. Большинство они воплотили в жизнь, а позже, на Новый Год, подарили мне крутой рюкзак :)

Автоматизируйте/задокументируйте первые шаги на проекте

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

Составьте видимый план себя как лидера

Я решил сделать это в виде mindmap в miro, который базируется на Team Lead Road Map, но дополнен следующими моментами:

  • Моим опытом тимлида и пониманием, что важно в этой роли.

  • Ссылками на любимые статьи, курсы, книги.

  • Ссылками на документы и инструкции компании, релевантные роли тимлида.

  • Какие обязанности я забрал с предыдущего лида, а что еще предстоит забрать.

  • Какие из лидерских активностей я делегировал.

  • Какие активности относятся к категории muda, и я их постепенно истребляю.

Далее я поделился этим mindmap со всеми тимлидами, с нашим тим-коучем (да, у нас есть такой человек) и с вице-президентом. Также я делюсь им со всеми, кому интересна прокачка в тимлида, как инструкцией: что есть тимлид, что можно прокачать и где взять информацию для прокачки.

Приступаем к действиям

Итак, прошли первые недели. Теперь у нас есть некоторое понимание проекта, список ожиданий от нас, противоречия сторон в понимании проекта и вашей роли.

Это уже хорошие ориентиры для дальнейших действий. Вот еще парочка:

  • Статья Work on what matters поможет определить, куда направить свои усилия после того, как вы снимете все низко висящие фрукты. Как избежать жевания чипсов, то есть выполнения легкой и видимой, но не особо полезной работы.

  • Статья Good process is evolved, not designed в паре со статьей Managing technical quality in a codebase помогают постепенно вывести оптимальный процесс для команды и проекта, вместо декларирования с завтрашнего дня мы Agile и затевания революций.

И еще один совет. Чтобы помочь самому себе в будущем, систематизируйте весь получаемый сейчас опыт. Записывайте, что сработало, а что нет. Как вы внедряли изменения, с каким сопротивлением сталкивались. Например, можно вести brag document. Вот чем он будет полезен:

  • Систематизация полученного опыта

  • Если вдруг загрустили перечитаете и вспомните, сколько всего вы уже сделали

  • Можно найти темы для статей или докладов из своего же опыта - эта статья так и родилась.

  • Поможет при пересмотре зарплаты это готовый список ваших достижений

  • Поможет в подготовке резюме в следующий раз

В общем, практика полезная и непыльная.

А мы переходим к списку того, что я делал в первые месяцы.

Станьте клеем

Метафора с клеем, на мой взгляд, очень удачна и выражает собой 90% ценности лидера в команде и компании. Очень рекомендую посмотреть доклад Tanya Reilly на эту тему. Здесь же приведу примеры того, что можно и нужно склеить, придя в новую команду.

Склейте развалившиеся коммуникации

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

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

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

Сформулируйте единое понимание, зачем существует ваш проект

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

Позже мы с командой сформулировали нашу ценность следующим образом:

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

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

Отдайте процедурные долги

Тут примеры простые:

  • Согласуйте закупки железа или лицензий, которые давно нужны.

  • Обновите зарплаты тем, кому их давно не обновляли.

  • Согласуйте найм специалистов, которых не хватает в команде.

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

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

Выгоните призраков

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

Такие призраки есть в любой компании. Не стесняйтесь спрашивать "почему так?". Возможно это застарелая и ненужная привычка, бесполезность которой уже никто не замечает, а вы ее видите пока вы новенький.

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

Нам нужно лучше оценивать задачи

Это самый частый призрак, которого мне доводилось встречать. Тема оценок бесконечна. Да, потому что мы часто с ними ошибаемся.

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

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

Бизнес не дает нам заниматься техдолгом, мы постоянно загружены задачами

Еще один классический призрак.

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

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

На момент моего прихода команда была в очевидном перегрузе, и мы начали с поиска границы наших возможностей (см. раздел Визуализация загрузки команды ниже).

Определив наш WIP limit и показав его топ-менеджменту, я получил очень прямой и честный ответ Вы сами следите за своей нагрузкой. И вы не можете, а должны заниматься техническим долгом. Довод про перегрузку бизнес-задачами это просто нелепая отмазка. Если задач больше, чем вы можете сделать за раз, просто сообщайте об этом, и будем договариваться.

Так мы изгнали призрака бизнес плохой, и не дает нам делать работу хорошо.

Устраните болевые точки и незавершенку

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

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

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

Это было болью, поскольку мы теряли данные, и это ставило под угрозу основную цель существования нашего проекта консистентные данные в режиме 24x7.

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

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

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

Создайте общедоступные артефакты

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

Проект с высоты птичьего полета

Какое место мы занимаем в бизнесе компании, в чем наше назначение, какие у нас основные челленджи. Мы сделали это в формате презентации, Miro так умеет. С этой презентацией я рассказывал про проект нашему CEO и ее же показываю новым сотрудникам при онбординге.

Высокоуровневая архитектура проекта

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

Хорошую помощь в построении понятных и простых диаграмм может оказать нотация C4 Model, статья Thinking Like An Architect Part 5 и опыт в прохождении system design interview.

Технический роадмап проекта

По сути это временная шкала, отражающая что мы уже сделали, что в фокусе прямо сейчас, что планируем следующим шагом. Отдельным "облаком" - что будем делать дальше, но еще не проработали в деталях (unshaped).Мы не планируем дальше пары шагов вперем, не тратим время на декомпозицю и проработку архитектуры далекого будущего - это наша реализация принципа defer commitment. Засчет этого мы всегда сфокусированы на том, что делаем сейчас и действительно заканчиваем большие задачи, а не попеременно хватаем и бросаем самые горячие картошки.

Визуализация стратегических задач (эпиков)

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

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

С помощью этих визуализаций мы проводим синки и внутри, и вне команды.

Визуализация загрузки команды

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

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

  • Зеленый задачи долгосрочного технического развития. Снижение/предотвращение рисков, снижение operational costs, прокачка observability, testability и прочих ...ility

  • Желтый бизнес-задачи со стандартным приоритетом.

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

  • Красный авария, например, падение на проде. Мы не берем ничего, пока не разберемся с текущей ситуацией.

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

Впрочем, не факт, что другие команды и стейкхолдеры будут смотреть сюда. Но формирование новых коллективных привычек это тема отдельной статьи. А артефакты в любом случае помогут вам и команде.

Что шло не по плану

Я все еще не пишу код

На эту тему я переживал еще на этапе собеседования. Я привык работать, не отрывая руки от кода. Тут же выглядело так, что будет не до кода, поскольку много высокоуровневых задач и people management да еще и новый стек надо освоить.

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

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

Однако со временем это становится проблемой команде трудно видеть лидера в человеке, который принимает лишь отстраненные решения и не в состоянии впрягаться в решение проблем вместе со всеми (могу поделиться на эту тему интересным исследованием).

Сейчас я близок к тому, чтобы взяться за код. Вот что я могу посоветовать здесь:

  • Устраняйте муду, которая пожирает ваше время. Заменяйте митинги на общедоступные артефакты. Устраняйте ручные действия, вызванные несовершенством процессов и инструментов. Очень много работы можно просто взять и выбросить.

  • Делегируйте. Например, найм, онбординг, коммуникации со стейкхолдерами. Многое из того, что для вас рутина, для вашего коллеги будет точкой роста.

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

Мою систему работы с задачами разнесло в щепки

Да, это был момент настоящей паники

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

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

  • Джедайские техники Максима Дорофеева. Эту книгу я читал и раньше, но перечитать оказалось совсем не лишним.

  • "Антитайм-менеджмент" Николая Додонова. На эту книгу очень много отсылок в Джедайских техниках, и эта книга двано была у меня в списке на чтение. Но я прокрастинировал, пока не "прижало". Прочтя могу сказать, что это отличная книга, которая раскрывает, как работает наш мозг в условиях перегрузки, и как построить постоянный продуктивный ритм работы.

  • Getting Things Done Дэвида Аллена. Еще одна книга, чтение которой я откладывал несколько лет. Исчерпывающее, хотя и сухое, руководство о том, как быть готовым к любой нагрузке. Вероятно, большинству система покажется слишком изощренной, но эта книга больше всего помогла справиться с нагрузкой. А со временем некоторые куски этой системы начали отваливаться сами собой, когда наплыв задач уменьшился. Некоторые практики становятся ненужными, когда вместо вороха дел у вас появляется долгосрочный горизонт и понимание, что важно. Эта книга помогает их найти.

  • То, как мы работаем не работает Тони Шварца. Книга про базовую гигиену труда и отдыха. Рекомендую прочитать ее всем, кто чувствует перегруз на работе и всем, у кого есть подчиненные.

По мере чтения книг я перестраивал систему, пока она не дошла до нужной отказоустойчивости. Но больше всего помогла смена отношения к задачам, в чем помогли "Антитайм-менеджмент" и То, как мы работаем не работает.

Выводы

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

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

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

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

Статья получилась огромной, но надеюсь она поможет лидерам в адаптации на новой работе, потому что это дело не такое уж простое. Успехов вам!

Список материалов

Подробнее..

Советы по управлению командой для Project-Managerов от М.Ю. Лермонтова

02.11.2020 14:14:45 | Автор: admin

Читая поэму М.Ю. Лермонтова "Измаил-Бей", наткнулся на отрывок, который даже в настоящее время дает отличные советы по управлению командой проекта. Подробнее - под катом.

Итак, отрывок:

Легко народом править, если он

Одною общей страстью увлечен;

Не должно только слишком завлекаться,

Пред ним гордиться или с ним равняться;

Не должно мыслей открывать своих

Иль спрашивать у подданных совета.

И забывать, что лучше гор златых

Иному ласка и слова привета!

Старайся первым быть везде, всегда;

Не забывайся, будь в пирах умерен,

Не трогай суеверий никогда

И сам с толпой умей быть суеверен;

Страшись сначала много успевать,

Страшись народ к победам приучать,

Чтоб в слабости своей он признавался,

Чтоб каждый миг в спасителе нуждался,

Чтоб он тебя не сравнивал ни с кем

И почитал нуждою принужденья;

Умей отважно пользоваться всем

И не проси никак вознагражденья!

Народ ребенок: он не хочет дать,

Не покушайся вырвать - но украдь!

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


Легко народом править, если он

Одною общей страстью увлечен;

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


Не должно только слишком завлекаться,

Пред ним гордиться или с ним равняться;

Лидерство. Советы о том, как вести себя с командой.


И забывать, что лучше гор златых

Иному ласка и слова привета!

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


Старайся первым быть везде, всегда;

Не забывайся, будь в пирах умерен,

Не трогай суеверий никогда

И сам с толпой умей быть суеверен;

Все еще думаете, как быть лидером в команде проекта?


Страшись сначала много успевать,

Страшись народ к победам приучать,

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


Умей отважно пользоваться всем

И не проси никак вознагражденья!

Очевидно описываются важные качества Project'а: Умение находить решения везде, используя все возможные инструменты и увлеченность проектом, а не деньгами.


Народ ребенок: он не хочет дать,

Не покушайся вырвать - но украдь!

Что Михаил Юрьевич хотел сказать для Project'ов здесь, я до конца не понял. Есть у кого идеи?

Подробнее..

Категории

Последние комментарии

  • Имя: Макс
    24.08.2022 | 11:28
    Я разраб в IT компании, работаю на арбитражную команду. Мы работаем с приламы и сайтами, при работе замечаются постоянные баны и лаги. Пацаны посоветовали сервис по анализу исходного кода,https://app Подробнее..
  • Имя: 9055410337
    20.08.2022 | 17:41
    поможем пишите в телеграм Подробнее..
  • Имя: sabbat
    17.08.2022 | 20:42
    Охренеть.. это просто шикарная статья, феноменально круто. Большое спасибо за разбор! Надеюсь как-нибудь с тобой связаться для обсуждений чего-либо) Подробнее..
  • Имя: Мария
    09.08.2022 | 14:44
    Добрый день. Если обладаете такой информацией, то подскажите, пожалуйста, где можно найти много-много материала по Yggdrasil и его уязвимостях для написания диплома? Благодарю. Подробнее..
© 2006-2024, personeltest.ru