Сучасна диджитал-освіта для дітей — безоплатне заняття в GoITeens ×
Mazda CX 30
×

Не разработчик и не менеджер. Что означает быть лидом

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

  • кто такой лид;
  • в чем заключается его работа;
  • как делать ее хорошо (ну как минимум не очень хреново).

Кто такой лид

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

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

Мой текущий проект — это миграция более чем 10-летней e-commerce-системы на React и GraphQL. Одна из моих основных обязанностей — синхронизировать работу front-end- и back-end-команд. Это означает, что в начале каждого модуля несколько недель почти полностью занимает скрупулезный анализ всего, что есть в дизайне, валидирование этого с back-end-командой, подготовка задач на интеграцию, обсуждение их с back-end-лидом и т. д.

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

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

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

Лид курильщика

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

Босс

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

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

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

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

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

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

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

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

Отличник

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

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

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

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

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

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

В итоге

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

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

Хоть я и работал над приложением с коллегой, всю эту фичу я решил вытянуть сам. Менеджер предлагал поделить нагрузку, чтобы отдать ее раньше и облегчить работу, но я просто не хотел доверять свое «детище» кому-либо еще. Я дизайнил, писал, переписывал, заново дизайнил... На 70% работы я почувствовал, что с трудом заставляю себя открыть редактор, чтобы закончить начатое... В итоге фича получилась очень похожей на знаменитый рисунок коня.

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

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

Лид здорового человека

Для начала обозначу мои критерии хорошего лида:

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

Можно было бы написать и больше, но даже если эти три пункта воплотятся в реальность, то ты уже молодец. Итак, как это сделать?

Нанимай нормальных людей

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

Человека надо брать, если:

  1. Человек может (скоро сможет) делать работу.*
  2. Человек хочет делать работу.*
  3. Ты хочешь вместе с этим человеком делать работу.

* Первые два пункта являются интеллектуальной собственностью Владимира Кожаева. Надеюсь, он не против цитирования.

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

Не требуй от людей лишнего

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

Не стану говорить за всех, скажу за себя: бывает, хочется что-то запретить. Чтобы и кофе на кухне не пили, и ленты в соцсетях не крутили, и в туалет пореже ходили. Такие мысли надо пресекать простыми вопросами: «На проекте все нормально? Задачи закрываются? Релизы релизятся?» Если да, тогда отстань ты от людей и делай свою работу.

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

Делегируй, но не эксплуатируй

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

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

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

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

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

ДелегированиеЭксплуатация
ДобровольноеПринудительная
Проходит под четким контролемОтдается на самотек
Ответственность возлагается на тебяОтветственность вешается на человека

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

Я набросал структуру компонентов, прикинул эстимейты, выделил реюзабельные блоки и отписал менеджеру (важный нюанс: менеджер была просто прокси между лидом, командой и заказчиком). Мы созвонились, завели таски по моим описаниям (некоторые из них относились к back-end), и я приступил к работе.

Через некоторое время мне пишет лид: «Кто дал тебе право создавать задачи, особенно для back-end?» Я ответил, что он сам просил не работать без заведенных задач (по ним биллились заказчики), а предварительно созданы они не были. Он покритиковал описания и суть моих задач и попросил больше так не делать. Страницы я в итоге сверстал, но осадок остался.

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

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

Расти вместе с командой

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

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

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

К примеру, недавно на 1-to-1 митингах некоторые разработчики из моей команды поделились заинтересованностью в роли лида и большей ответственности. Я подумал, как это можно реализовать с пользой для проекта и решил применить идею module ownership: каждый в команде получает возможность отвечать за определенный модуль или часть процесса. Это включает технические решения, поддержку, интеграцию, масштабирование — во все это они вовлекаются больше других, когда речь идет об их зоне ответственности.

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

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

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

Блиц-советы

  1. Не расслабляйся, если кажется, что все хорошо.
  2. Не пытайся сделать все идеально.
  3. Если чувствуешь, что кого-то надо уволить, увольняй.
  4. Если чувствуешь, что кого-то надо нанять, нанимай.
  5. Не забывай писать код.
  6. Признавай свои ошибки (в том числе публично).
  7. Кушай жидкое как минимум раз в неделю и не мочи манту.

Заключение

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

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

А пока жду вас в комментариях. Расскажите, что, по-вашему, должен делать лид, поделитесь историями о плохих лидах и расскажите о хороших.

Все про українське ІТ в телеграмі — підписуйтеся на канал DOU

👍ПодобаєтьсяСподобалось1
До обраногоВ обраному0
LinkedIn

Схожі статті




56 коментарів

Підписатись на коментаріВідписатись від коментарів Коментарі можуть залишати тільки користувачі з підтвердженими акаунтами.

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

Такі накодерки на пенсії пляшки збирають по смітниках...

Скажу за себя — самореализация и деньги. Думаю, что у других людей они могут отличаться.

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

Ну по поводу денег, мне накидывали +20-25%. Но времени не оставалось совершенно. Работая программером есть время заработать столько же или даже больше на аутсорсе (если есть желание конечно же).
По самореализации — тут видимо на любителя. Не каждому подойдёт, хотя ежели нравится, то почему бы и нет.

Можешь имигрировать по Л1 визе потому что тим лид считается менеджером. Так же легче потом перейти на должность архитектора

Отличная статья, спасибо

Как тим лид с 5 летним опытом в бою и 15 годами опыта вообще, тим лиду с 6 месячным опытом скажу что вся эта тема с «Построить правильно процессы», «обучить свою команду» может быть и работает в небольшой постоянной команде, но когда матричная структура управления, а она встречается чаще чем хотелось (это когда девы гуляют от программы в программу, заняты на разных проектах у разных лидов) сколько ты не планируй, не строй процессы, какой-то стейкхолдер либо заберет разработчиков, либо урежет сроки или бюджет или сменит требования. Но стремиться к совершенству надо. Я бы отметил важное качество лида: приспосабливаемость и легкоперестраиваемость. Под приспосабливаемостью я имею в виду работу с разными людьми, нравами, довольными и недовольными, толерантность к всевозможным ситуациям и хорошая стрессоустойчивость. Легкоперестраиваемость, скорее всего быстрый переход от Agile, AWS и всяких нежностей на проект кое-как задеплоеный на rackspace который постоянно падает потому что весь диск заполнен логами. В общем как можно дальше быть эмоционально от работы и относиться ко всему как к временному. cs8.pikabu.ru/...​7/1454673002113620376.jpg

В общем берешь прораба, обучаешь Джабе и получаешь лида. Я прав?

Ну разве что бухать с коллективом не обязательно.

Плюс-минус :) Прораб он и в айти прораб.

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

Спорное утверждение. Может и не обязательно но крайне желательно;) где ты ещё узнаешь желания своей команды:) а так да. Прораб он и есть прораб:)

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

Спасибо!

На самом деле, наша команда проходила долгий путь от forming до performing, спотыкаясь, но не сдаваясь :) Было и становление процесса как такового (с 0 до 2-3 уровня process maturity model), и формирование команды, и осмысление культуры — как работы, так и коммуникаций.

Просто решил делать акцент статьи не на этом. Возможно, напишу на эту тему в будущем.

Не расслабляйся, если кажется, что все хорошо.

да ладно! а смысл тогда «делать хорошо»? ))

Не пытайся сделать все идеально.

да ладно! а смысл тогда делать? )) но да тут надо понимать широту понятия «идеально»

Если чувствуешь, что кого-то надо уволить, увольняй.
Если чувствуешь, что кого-то надо нанять, нанимай.

тут +100500 с одним нюансом надо не «чувствовать» надо «знать» а то получается ты (здесь обобщение) _не_ делаешь всё идеально чтобы просто знать и делаешь это «неидеально» только потому чтобы «не расслабляться» ))

ну да прикольный психологический эффект «ощущения нужности» и «страха ненужности»

с манту вроде как уже разрешили мочить ))

ЗЫ: быть лидом несложно )) сложно быть лидом там где сложно быть лидом и скорее всего быть вообще ))

Я честно скажу, что, попробовав, не хочу снова становиться разработчиком.

ну это пожалуй самое интересное

а) почему?
б) а что ты вообще имеешь в виду «быть разработчиком» конкретно в твоём случае там где конкретно ты не хочешь им «снова становиться»?

ЗЫ: а ты вообще «был»? )) потому что это это как раз популярная история особенно в Родине ))

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

зачем!? !!! ???

твоя (здесь обобщение) задача чтобы работал твой собственный процесс уход приход людей как и хороших так и плохих просто должен быть поставлен как часть общего потока с вполне внятно формализованными операциями это просто люди сегодня их цели могут совпадать ну и ок работаем вместе (если они работают работу) а завтра цели не совпадают ну и ок скушали прощальный тортик за счёт компании и пожелали удачи на новом месте и обменялись профилями в линкедине всё

более того вся вот эта ерунда «1 на 1» и прочия это вообще не функция «лида» это функция таки «менеджера по людям» единственное что тут должно заботить «лида» «я могу ему дать делать работу» и «я не могу дать ему делать _эту_ работу» вот и всё

цимес «отечественной проблемы» именно в «смешении ролей» когда с одной стороны «лид» ничего не решает но с другой всяко пытается «влезть в голову чтобы узнать твои цели»

дык нет никакой «цели» есть только работа она либо работается либо нет и есть другая работа которая кем-то либо может работаться либо нет а если другой работы нет то какие могут быть «цели»?

Это показывает человеку, что тебе не все равно и что в компании ему есть куда расти.

ещё раз эта хитрая фишка очень простая да «тебе всё равно» )) в компании просто есть работа которую нужно кому-то работать вот и всё все «есть куда расти вместе с остальными и держаться за место» почти 146% сводятся к ситуации «7 насяльника 1 программист» просто потому что «насяльника» уже «выросли» а программиста взяли ну чтобы работал просто потому что кому-то и работу работать надо ))

опять же ж возвращаясь к срокам лично я на личном опыте крайне предубеждённо отношусь к людям просто чисто технически работавшим в 1-й компании много лет дальше уже начинаются нюансы особенно если он ещё и сделал карьеру а особенно если он ещё и сперва сделал карьеру 10 лет в одной компании а потом перешёл в другую просто потому что видно у меня так сложилось что все известные мне реально технически годные люди просто даже не «вырастали из места и компании» но «делали свою работу и шли дальше делать ещё работу» а вот то что человек якобы «рос» вот это как раз уже подозрительно и по опыту на то есть все основания

СТО рассказывающий причём совершенно серьёзно что он имел опыт с хтмл а на самом деле это было где-то в самом начале его «карьеры» в его компании когда он сделал домашнюю страницу компании и вот теперь он совершенно серьёзно записал у себя в резюме и своём понимании что он умеет и понимает хтмл (здесь обобщение но на основе реальных событий и реально хтмл) вот да человек рос рос и наконец вырос... )) «вырос» куда?

мораль проста не надо «бояться» людей приходят и уходят просто потому что это нормальный процесс нет там никаких «целей»

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

А люди, поработав в твоей dream team, все равно уходят. Почему это происходит?

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

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

можно сказать вариант реализации «ошибки выжившего» ))

Рано или поздно ты ошибешься

фишка тут в том что принимать это за «ошибку» нельзя просто потому что человеческая природа это не компьютеры надо именно изначально учитывать вероятность такой «ошибки» и просто иметь чёткий и достоверный и конкретный план на случай её реализации это не «твоя ошибка» это просто другой совсем чужой человек именно это надо воспринимать как данность не более того

тот же ж скрум априори полагает что команда состоит как раз из исключительно правильных людей просто собравшихся вместе для совместной реализации общих усилий и всё и именно потому скрум почти 146% не работает когда он таки не работает ))

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

да нет же ж это же ж и есть тот самый микроменеджмент аля «сделай сам но при этом ещё и сделай видимость работы команды» это никак не «делегирование»

работать должно так

№ 1 ты даёшь человеку сделать то
№ 2 он сам занимается выяснениями и прочими исчерпывающими информациями включая запрос на _конкретную_ помощь либо на те самые «точки принятия решений» при этом он сам должен понимать таковые а просто «делегировать в зад» обратно на лида сам процесс принятия решений в т.ч. «ок не суть» «ок делай так» «ок вообще не делай»
№ 3 человек даёт результат примерно аналогичный тому каким бы б ты сделал его сам иначе начинаются варианты

варианты уже то самое толстовское «каждый несчастный по-своему»

№ 1 на самом деле «исполнитель» «делегирует в зад» на «лида» всё «исполнение» так бывает ))
№ 2 «исполнитель» не хочет делать это а хочет делать своё не «по-своему» даже а именно «своё» это существенная разница
№ 3 «запрос на помощь» слишком тяжёл (варианты п.п. № 1)
№ 4 «исполнитель» на самом деле начиет заниматься «решениями» а не «исполнением» (варианты п.п. № 2)
№ 5 «исполнитель» тупо не способен это сделать (подпункты «не способен в объёме» или «не способен в сложности» или «не способен технически» или «не способен организационно» или...)
...

во всех этих случаях основное решение какое может принято это понижать уровень сложности / объёма задач вплоть до тогда когда сама по себе «роль исполнителя» уже вырождается

если «исполнитель» нормально к этому относится и просто делает хорошо на уровне ниже можно дальше повышать

если не делает решать на мороз снова же ж тут должен заниматься не «лид» а «менеджер по людям»

если «работа не сделана» но тут надо не «критиковать себя» а просто «не давать работу а давать тому кто делает» и всё нет никакой ложки есть только ты и работа которую надо сделать ))

Делегируй

ну просто потому что «лид» это не про «делегирование» ))

вот смотри простейшая же ж ситуация

Через некоторое время мне пишет лид: «Кто дал тебе право создавать задачи, особенно для back-end?» Я ответил, что он сам просил не работать без заведенных задач (по ним биллились заказчики), а предварительно созданы они не были. Он покритиковал описания и суть моих задач и попросил больше так не делать. Страницы я в итоге сверстал, но осадок остался.

почему «осадочек остался» у тебя? )) мыло того что ты полез сам создавать таски так ещё и ответил не на тот вопрос который тебя спрашивали т.е. конкретно «кто дал право создавать таски?» а не то что они вообще должны быть созданы вообще

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

просто потому что задачи делает вся команда вот взять тот же скум и оп-па формально в процессе никакого «лида» нет и быть не может потому что все равные (ну кроме продакт овнера ага) а вот когда есть «скрум» а нет продакт овнера который и должен выступать уже здесь точкой принятия решений вот снова ой ))

ведь команда тоже не «делегирует» задачи сама себе просто разобрали и делают «лиду» просто нечего «делегировать»

вот скажем там же ж чуть дальше «делегирование против эксплуатации» там где одно «под чётким контролем» а другое «на самотёк» а вот и нет! как раз «на самотёк» это и есть делегирование когда я отдаю реализацию и ожидаю просто конечный результат а детали оставляю на исполнителя

конечно это если я исполнителю доверяю и знаю что решение действительно будет и действительно будет достаточным «примерно таким каким сделал бы б я сам с мелкими несущественными нюансами» но если исполнитель так не может вот отсюда всё только начинается но это уже не совсем «делегирование» это уже как раз «управление» а это уже об другом

ответственность так вообще штука сложная фактически и формально виноват всегда командир но если в «команде» будут люди которым нельзя доверять то ответственность командира их из «команды» убрать и только потом снова возлагать на себя ответственность за «команду» иначе в этом смысла нет привет то самое «выгорание»

а вот «убиранием» как чисто техническим процессом и должны заниматься те самые «менеджеры по людям» а не сам «лид» командир

ну вот смотрите прямо тут про это же ж и написано ))

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

ну а нахиба тогда его «назначили лидом»? в чём смысл его «лидерства» именно как чисто роли на проекте?

фишка же ж не в «превосходстве» но в наличии «конечно точки принятия решений» это просто функция ничего такого особенного тут нет

но получается с одной стороны функцию назначили а с другой стороны тут же ж отобрали потому что нефих быть «уверенным в собственной правоте и превосходстве над коллегами» ))

но он же ж «лид»! это и есть его работа «делать собственную правоту и превосходство над остальными»

но ніт ))

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

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

вместе с тем в отечественной практике отсуствует культура «лидерства» именно с точки зрения «рядовых» вот у американцев всё просто «лидер» это просто чувак который принимает конечные решения в т.ч. закрывает споры как он сказал так и делать это просто чистая функция

но в отечественном варианте она не работает )) всегда найдутся как рядовые гребцы так и уже менеджеры которые «знают как лучше» и «требуют чтобы с ними считались»

это нонсенс именно в том месте что простите чуваки а нафига тогда я вообще нужен? зачем тогда меня ставить «лидом»?

или вот например одна из обобщённо классических ситуаций типа кучка мелких команд и в каждой по «лиду» на 1-2 разработчика по «лиду» нахиба он вообще нужен? что он будет «лидить»? почему тогда не сделать 1-го общего на всех?

но нет потому что «лид» в отечественной практике эта такая себе отечественная форма стрёмного цапа видбувайла и это по сути единственная его «функция» ))

Мне кажется вам надо свою версию этой статьи написать, а то у вас прям на каждую строчку есть свое противоположное мнение

я не могу у меня запятых нет ))

Тут есть редакторы, если они захотят, конечно)

и они осквернят мой высокий священный текст своими низкими мирскими запятыми

Статья супер по смыслу и стилю. Явный писательский талант.
Адаптированная цитата из Анны Карениной очень понравилась.

Спасибо! Очень приятно читать такие комментарии :)

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

+1

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

Невроз быстро приводит к тому, что лид
• или начинает ВСЁ ВСЕМ ВСЕГДА делегировать,
• или начинает делать всё сам, и НИЧЕГО НИКОМУ НИКОГДА не доверяет.

Это настолько типично, что обсуждать предложенные вами примеры «когда всё было сделано по-уму» очень сложно, бо в наших кругах обычного технаря и лидом назначают, и исполнителей ему назначают, и дедлайн ему назначают... и редко, вследствие нетехнологических интриг (а это приспособленчество) или ультиматумов (а это истерика) бедный началникэ может менять своих подчинённых, и, соответственно, доверять им. В этом окружении примеры «когда всё хорошо» выглядят как удивительное исключение из правил, или объясняются через «Ааа, ну это же сын ректора, всё понятно», а не «У парня был талант, он взялся за гуж, он молодец».

Вообще, власть надо давать тем, кого она тяготит. Но давать надо именно власть, а не её суррогат. А для этого надо или учиться всем этим делам ДО, а не экспериментировать во время разработки.

Вообще, власть надо давать тем, кого она тяготит. Но давать надо именно власть, а не её суррогат. А для этого надо или учиться всем этим делам ДО, а не экспериментировать во время разработки.

тут вся фишка в том что в Родине крайне важна цветовая дифференциация штанов а нет дифференциации нет и цели и соотв. в Родине «лид» это «власть» читай «насяльника» просто такой себе «младшой» а вовсе не чисто техническая функция и основная фишка с «лидами отечественными» как раз в том что они очень беспокоятся именно за свою «власть» как суть «лида» в их понимании просто потому что без этого без «власти» нет и «сути лида» вот так всё просто ))

и да чисто техническая функция должна обладать «властью» как суть есть формальной реализацией своей _функции_

обобщённая ситуация например все хотят чтобы с ними считались ну ок давайте понеслась и тут оп-па всё останавливается потому что «считались» это либо «а поговорить» либо «а поговорить про то что должны ©делать другие» а вовсе не про то «ок я возьму сделаю это» и чтобы хоть как-то двигалось приходится применять методики «теневой власти» )) что-то типа того

Спасибо за толковую статью, надеемся на скорое продолжение!

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

Я думаю, Александру Семёновичу не пришлось бы ничего специально показывать, если бы его студенты (что вы, что топикстартер) не стеснялись бы своего факта обучения в Криворожском Экономическом Институте.

А то невозможно же найти земляков в Линкедине ни по родному городу ни по альма-матер! Все лепят «КНЭУ» и указывают город «Киев», даже те, кто заканчивал институт в недолгую бытность КЭИ в составе Криворожского Национального. При том, что ну никакого отношения та прекрасная криворожская кафедра не имеет к аналогичным по сути (но не по духу) кафедрам из КНЭУ.

Стесняться? Вы ошибаетесь.

Насчет ВУЗа — я просто написал то, что у меня в дипломе.

А насчет кафедры и ее пед. состава — это те люди, которые дали мне образование и сделали из меня программиста (во всяком случае, начинающего). И я им действительно глубоко благодарен за человеческое отношение к студентам и искреннее желание научить. Это и Александр Семенович Зеленский, и Владимир Сергеевич Лысенко, и Сергей Владимирович Баран, и еще десятки прекрасных людей.

Надеюсь, во время моего следующего визита домой найду время проведать и сказать им это лично :)

Я с вами согласен полностью и стараюсь во всех кругах рассказывать об этом нашем замечательном вузе и кафедре. За 7 лет в отрасли я увидел самых разных выпускников из крупных городов Украины и мира и могу с уверенностью сказать, что наша кафедра не уступает крупнейшим украинским городам по качеству и разнообразию программы, интересной подаче материала. А отсутствие взяток — это вообще что-то из разряда фантастики (по меркам Одессы, конечно).

Но пару раз меня спрашивали: «а почему об этом ВУЗе почти ничего не известно? Ведь Кривой Рог — это город величиной со Львов! А о львовских вузах все наслышаны?» и я не находил что ответить... Мне кажется, что криворожане стесняются.

Я думаю, что лучшее, что мы можем сделать — это дать публичность этому криворожскому феномену в своих синьерских/лидских резюме и линкединах, а не закрываться от неудобных вопросов безликим КНЭУ. За карьеру мне раз 10 на собеседованиях задавали вопросы о том, «что это за ВУЗ такой», в т.ч. за границей и каждый раз я не ленился объяснять...

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

Лідерство — це не про «виконувати роботу». Це про натхнення інших на виконання роботи.

Лід не курця:

  1. Людина, яку поважають інші розробники та керівництво
  2. Завжди допомагає іншим розробникам в скрутних ситуаціях
  3. Є прикладом якості, швидкості, продуманості.
  4. Ніколи не вносить розбрат в команду, а тільки об’єднує її навколо себе
  5. Завжди вмотивований та не має права на хандру
  6. Прислуховується до думок та завжди чітко та аргументовано пояснює свою власну позицію
  7. Вміє насолоджуватися результатами роботи команди

Погоджуюсь с кожним пунктом. Хоча, з 5м у мене складніше — все ж таки я людина й усе людське мені не чуже :)

Тоді треба качати скіл артистизму ;)

На додачу до 5 і 6 пунктів — а ще вміє визнати коли неправий і підтримує в команді можливість критичного ставлення до всього що їм пропонують.

При сильному лідерстві та рівню як спеціаліста визнавати, що ти не правий, особливо не треба. Бо ти завжди правий. :D

Але все одне згодний, вміння визнавати свої помилки — сильна сторона не тільки лідера, а й просто людини.

а тільки об’єднує її навколо себе

так нада объеднувать не навколо сэбэ а навколо работы ))

та не має права на хандру

а Слава КПСС вообще не человек (к) (тм)

та завжди чітко та аргументовано пояснює свою власну позицію

ещё раз тут фишка такая что если «лиду» приходится «пояснять свою позицию» то либо это не «лид» с точки зрения команды процесса и всего либо с такой «командой» он далеко не уедет и вообще не уедет никуда

команда _должна_ понимать действия «лида» либо если отдельные рядовые не понимают то просто «принимать на веру» просто потому что это и есть роль и функция «лида» а разбираться уже потом уже в свободное личное время либо в свободное (!) личное (!) время лида а никак _не_ рабочее

это такая прикольная фишка «если ты в этой комнате самый умный значит это не твоя комната» и с «командой» та же ж история

Прислуховується до думок

и это опять же ж всё про то одно и то же ж либо он «лид» либо нет и тогда конечно таки да попоболь так бывает чаще чем хотелось бы б

Вміє насолоджуватися результатами роботи команди

см. п.п. «объеднувать не навколо сэбэ а навколо работы» нет никаких «результатов работы команды» есть «просто результаты» просто потому что это и есть _работа_

и бизнес как таковой

это не «дворовая команда» сегодня сыграли хорошо вчера не очень ну и ладно ничего страшного не на трусы играем )) это просто работа

как только «команда» стаёт «выше работы» так сразу «всё» и таки да и это тоже в свою очередь довольно популярная история

так нада объеднувать не навколо сэбэ а навколо работы

Тоді лідерство взагалі не потрібно. Як клас. Всі просто будуть виконувати свою роботу.

ещё раз тут фишка такая что если «лиду» приходится «пояснять свою позицию» то либо это не «лид» с точки зрения команды процесса и всего либо с такой «командой» он далеко не уедет и вообще не уедет никуда

Лідер != автократ. Лідер не мусить пригнічувати інших людей та відкидати їх думки як заздалегідь неправильні. Він мусить розвивати команду. А для цього їм треба давати можливість апелювати до ваших рішень та ставити під сумнів те, що ви їм кажете. Інакше завжди буде внутрішній конфлікт, а це вже не лідерство, а конкуренція.

команда _должна_ понимать действия «лида»

Це в теорії. Зазвичай лід може знаходитися в мільйонах роках еволюційного розвитку від команди, та його гарячі та палки промови можуть сприйматися як алієнське булькотіння. Для розуміння потрібний відповідний рівень знань та досвід. Якщо його немає, то прийдеться працювати з командою, щоб вона почала розуміти тебе та вгадувати хід твоїх думок.

это такая прикольная фишка «если ты в этой комнате самый умный значит это не твоя комната» и с «командой» та же ж история

Лід не може бути найтупішим в кімнаті. Інакше він вже не лід, а підлідок.

нет никаких «результатов работы команды»

Є. Просто ви не хочете ділитися власними результатами з іншими. Бо в вашому світі ви — крутий, а решта ні. Якщо працює команда, то є й результат роботи команди. Не окремих осіб, а саме команди. Лід може не написати жодного рядка коду, але приймати активну участь в роботі команди, слідкувати за якістю та повнотою результату роботи. Виходить, через те, що особисто він не написав жодного рядка, він нічого не зробив? Ні, він може легко привласнювати собі результати всіх членів команди та бізнес-успіхи продукту, що було створено за його участю.

есть «просто результаты» просто потому что это и есть _работа_

Та ще треба розділяти прямі та опосередковані бізнес-результати. Програміст, що пише інструменти для іншого програміста, який пише код продукту, що приносить гроші, так само впливає на бізнес результат. Тому команда має сукупний результат, а не особистості. Перевіряється доволі просто. Викиньте з рівняння другого програміста та подивіться на бізнес-результат.

Лідер != автократ. Лідер не мусить пригнічувати інших людей та відкидати їх думки як заздалегідь неправильні. Він мусить розвивати команду. А для цього їм треба давати можливість апелювати до ваших рішень та ставити під сумнів те, що ви їм кажете. Інакше завжди буде внутрішній конфлікт, а це вже не лідерство, а конкуренція.

я от не пригнічував, хоча мені казали інше ))
тут така ситуація — я несу відповідальність і тому я приймаю остаточне рішення.
Якщо я не правий, а я можу бути не правий, я вислухаю, по сперечаємось і може до чогось дійдемо, але все одно остаточне рішення приймаю я. Буде подобатись це комусь чи ні то вже інша ситуація.
З іншого боку я завжди казав — якщо ви бачите що хтось помиляється чи лід чи... і мовчите — це саботаж і зрадонька.

Це в теорії. Зазвичай лід може знаходитися в мільйонах роках еволюційного розвитку від команди, та його гарячі та палки промови можуть сприйматися як алієнське булькотіння. Для розуміння потрібний відповідний рівень знань та досвід. Якщо його немає, то прийдеться працювати з командою, щоб вона почала розуміти тебе та вгадувати хід твоїх думок.

я ще можу зрозуміти коли команда набрана спеціально для розвитку цієї самої команди, а не для розробки чогось реального, тоді велика різниця в еволюції ще якось виправдана. Хоча особисто такого не зустрічав.
Якщо розрив між лідом і командою настільки завеликий що голос одного нагадує щось богоподібне, а інших булькотіння недорозвинених племен, то це не робота буде а чорті шо

тут така ситуація — я несу відповідальність і тому я приймаю остаточне рішення.

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

для розвитку цієї самої команди, а не для розробки чогось реального

Інвестиція в команду завжди позитивно впливає на результат. Виснажувати людей та викидати їх на вулицю після перегорання це теж бізнес-модель, але вона працює тільки в короткостроковому періоді або коли бізнес-модель така, що продається тушка, а не результат її праці.

Якщо розрив між лідом і командою настільки завеликий що голос одного нагадує щось богоподібне, а інших булькотіння недорозвинених племен, то це не робота буде а чорті шо

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

Тоді лідерство взагалі не потрібно. Як клас. Всі просто будуть виконувати свою роботу.

дык. аб то же ж и речь ))

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

ну и классическая дифференциация штанов в качестве цели одни уже получили лычку и теперь думают что они другие и уже не хотят становиться обратно «простыми» другие ещё не получили лычку и думают что получив её они станут другими и уже не будут «простыми»

youtu.be/0UzIZhxKH94

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

Співчуваю...

Я уже полгода как мало пишу код, ....

- півроку — рановато. Нічого особистого. Навряд у вас вже є достатній досвід і системний підхід, щоб пояснювати іншим хто такий lead.

я прочитал статью — очень неплохой материал для полугидичного лида

Ви частково праві. Проте, я не намагався пояснювати чи нав’язувати іншим (тим паче лідам), як робити цю роботу. Моїм завданням було якось осмислити той справді невеликий досвід, що я отримав за ці 6 місяців, і поділитись ним — не у вигляді догми, а лише певних висновків, щодо яких можна дискутувати.

Мені здається, що цей матеріал більш цікавий не для лідів, а для розробників, які хочуть розвиватися в цьому напрямку — тому навіть базові для досвідчених лідів речі можуть бути корисними.

Дякую за поділ першими враженнями. Удачі в майбутньому.

я не намагався пояснювати чи нав’язувати іншим (тим паче лідам), як робити цю роботу

дык а это же ж и есть работа «лида» )) или что есть работа «лида»? ))

Ты депутат или журналист? © классик украинской риторики

Підписатись на коментарі