Отстаивать твои границы - это часть твоей роли.

Попадали когда-нибудь в такую ситуацию, что вы уже перегружены, а вам еще наваливают работы? Что чувствовали в этот момент?

У меня была история: я впервые занимал менеджерскую позицию, мне нужно было заниматься 3 отделами разработки, организовывать процессы и т.п. Было довольно много работы, по сути заведомо больше, чем можно сделать, когнитивное напряжение было достаточно сильным, часто было так, что я приходя с работы сразу засыпал на 1-2 часа.

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

Мои ощущения в тот момент:
1. "Дурацкий отчет"
2. "Я и так перегружен, а теперь еще и этим заниматься"
3. Неприязнь к этому запросу
4. Сильное раздражение

И я как-то резко ответил, что явно видно было, что я недоволен и не хочу этого делать.

И вот вопрос - кто в этой ситуации дурак?

Варианты ответов:
1. Тот, кто придумал "дурацкий отчет"
2. Техдир, который у меня его запрашивает
3. Мой менеджер, потому что на мне слишком много работы
4. Я сам, потому что на мне слишком много работы

Правильный ответ - номер 4.

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

- У вас есть смежные области знаний
- Рядом всегда "валяются" ничьи зоны ответственности
- Всегда можно сделать что-то лучше

Более того - ты не делаешь этим лучше окружающим!

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

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

Во-вторых, вообще-то никто кроме тебя не знает в точности весь объем того, чем ты занимаешься. В работе, опирающейся на знания - никогда.

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

Итак:

Если ты менеджер, то отстаивать твои границы - это часть твоей роли

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

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

Эволюция разработчика.

Слыхали такое, что разработчики должны быть инициативными, увлеченными, продуктивными, а еще желательно лояльными?

Много кому нужны такие. А что-то их мало. Почему вдруг?

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

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

Испытание вовлеченности

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

Испытание скромности

Приходит наш герой на вторую работу (пока еще не одновременно). Трудится, показывает класс, пилит фичи, приносит пользу, качает харды. Думает: буду хорошо работать - меня оценят. Про повышения не спрашивает. Что нужно сделать, чтобы получить больше денег - тоже. И как-то так странно выходит, что через время его зарплата уже сильно ниже рынка. Он думает - так, ну я тут уже имею экспертизу, работаю неплохо, всем всё нравится. Очевидно, я имею ценность гораздо выше для компании, чем какой-то новый человек с рынка. Получается, мне должны даже больше рынка платить? А у меня меньше. Пойду спрошу... А ответ - "давай подождем перформанс ревью, думаю на 20% получится поднять". И вот наш герой понимает, что оптимальный способ держаться в рынке - менять работу. Теперь он джоб-хоппер.

Испытание силы

Приходит наш герой на третью работу. Еще немного поработав, видит - да я же хорош. Я делаю в три раза больше соседа, шарю в продукте лучше, самые сложные задачи дают мне. А ну-ка я узнаю, какая у этого соседа зарплата. Такая же (или на 20% ниже). Опа... Возникают мысли - если я делаю х3, то почему я получаю не х3? Пообщаешься с руководителем - х3 или даже х2 не дадут. От силы процентов 30 накинут. И что-то как-то уже не очень хочется х3 выдавать. Зачем? Буду делать х1,5 - один фиг буду топ в команде, и еще хвалить будут. А куда половину времени девать - можно отдохнуть, поделать пет-проекты, заняться саморазвитием или фрилансом. Или найти вторую работу. Теперь он средний сеньор с рынка. Эволюция завершена.

А теперь, как говорится, кто в этой ситуации дурак? Что-то мне подсказывает, что не наш герой.

История о коррупции внутри коммерческих компаний

Коррупция начинается с чьего-то Желания. Страстишки.

В этом случае желание было - отказаться от 1С как части бэкенд-системы.

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

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

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

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

Что с этим можно сделать? Как правило - ничего. На собственника прямого выхода нет, для него ты просто ноунейм исполнитель. Будет твое слово против слова "архитектора", который уже присел на уши и имеет вес в глазах владельца компании, потому что реализует его Желание. А "слово против слова" это обычно плохой план. Репортишь своему руководителю, и на этом обычно всё.

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

Год идет, все планы ожидаемо едут. Год заканчивается - по факту не сделано практически ничего. Ближе к сроку челы из команды трансформации просто уходят в другие компании.

Новый год - угадайте что? Делается новый roadmap, почти такой же, как старый. Находятся другие люди, которые готовы начать эту песню с начала.

Спустя несколько лет мне стало любопытно, завершился ли проект "трансформации" в той компании - нет, его потом просто закрыли. Спалили пару сотен k баксов и норм.

Чему это учит? Давайте попробуем накинуть несколько вариантов:

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

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

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

➖надо понимать, что за вывеской "мы делаем общее дело" и "всё ради результатов" среди менеджмента кроется полно людей, которые играют в win-lose pvp игру, борются за ресурсы для себя (или себя и своей "бригады") в ущерб остальным, прикрываясь красивой риторикой

Вообще тема обширная, я думаю мы к ней еще не раз вернемся.

Выбор правильного решения на простом кейсе

Собесили тимлида backend. Только открыли найм - сразу попался один хороший кандидат (что редкость).

Прошел поведенческое интервью, прошел техническое, дополнительно провели архитектурное. Всё хорошо, его фидбек - тоже всё нравится. Согласовал деньги. Жду пока HR сделает оффер, уже радуюсь, что повезло долго не возиться.

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

Я сначала такой "что?..". Сначала просто удивился. Думаю - странная фигня какая-то. Поговорил сам с человеком. Потом немного подумал и первый вывод - "странный тип какой-то, может и лучше, что не взяли, вылезло бы что-то еще". Несколько чел внутри компании отреагировали так же. Думаю для большинства история здесь бы и закончилась %) Но я стал думать дальше.

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

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

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

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

Я прикинул и сделал вывод, что процесс собеседования существует ради всего двух целей:
1. отсеивание неподходящих людей
2. конкуренция с другими компаниями

Если этап не делает существенный вклад ни в одну из этих целей, значит этого этапа не должно быть.

Со вторым пунктом понятно - никакого вклада в конкуренцию с другими за кандидатов это не дает, скорее мешает.

Как это работает на отсев?
1. Сначала возьмем людей c хорошими намерениями - мы тут ничего не выясняем нового
2. Люди с плохими намерениями - если они не тупые - поймут что надо дать телефоны тех, кто не скажет про них что-то плохое. Например, контакты друзей
3. Что остается: люди с плохими намерениями и которым при этом либо вообще настолько пофиг на эту работу, что даже лень заморачиваться, либо они слишком тупые, чтобы дать контакты тех, кто скажет про них что-то критично плохое

Звучит как будто в 3 случае мы так и так на других этапах это должны заметить )

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

Встретились с Head of HR и рекрутером, единогласно решили убрать этап.

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

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

Почему делегирование - фундаментально всратая концепция

Почти каждый наверно слышал - "нужно делегировать". Этот банальный тейк гуляет везде много лет, но как будто бы не очень помогает людям. Куда ни посмотришь - везде легко найдешь кучу перегруженых лидов и других руководителей. Они что, не слышали, что нужно/можно делегировать? %))

Наверно, проблема тогда в чем-то другом. Да и вообще, тезис про "нужно делегировать" существует не последние несколько лет, он существовал и 50 лет назад, и больше.

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

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

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

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

Так и получается, что можно 50 лет говорить, что "нужно делегировать", а воз и ныне там. Думаете, что 50 лет назад меньше делегировали, чем сегодня? )

Ну а какая альтернатива тогда, типа как правильно?

Изи. Нужно наоборот ставить вопрос: пишешь все, что делаешь на своей роли (список), смотришь на него и задаешь себе вопрос: "что из этого могу делать не я?".

Получается какой-то список функций. И все это раздаешь в другие роли внутри своей команды.

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

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

Зафиксируем: частое делегирование - признак неверно спроектированных ролей в команде.

Давай на примере теперь.

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

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

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

Если для коллеги это что-то совершенно новое, менторишь по стандарту:
1. Делаешь сам, коллега смотрит, ты объясняешь логику своих действий
2. Коллега делает и объясняет, ты смотришь
3. Коллега делает без тебя, сообщает тебе о результате
4. Коллега делает сам автономно, сообщает только в случае возникновения проблем

(продолжение)

Для каких случаев остается делегирование:
1. Проверка гипотезы. Думая над изменением роли, 1-2 раза делегируешь кому-то какую-то работу для проверки.
2. Уходишь в отпуск - делегируешь на время своего отсутствия свою работу.
3. Разовые крупные активности (условно какой-то квартальный отчет), которые стоит сделать коллективно, но которые не стоят перекраивания ролей.

В инструкциях по безопасности самолета написано следующее:

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

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

Мотивация... или демотивация?

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

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

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

Давайте представим что есть некие условные единицы мотивации. Максимально заряженный человек - 100 единиц, "не хочу ничего делать" - 0 единиц.

Сравните стоимость в единицах мотивации:

➖Похвалили vs. оскорбили
➖Дали денег сверху vs. не дали то что обещали
➖Оказали уважение vs. выразили неуважение
➖Внимательно выслушали предложение vs. не стали слушать
➖Получаю сверх ожиданий vs. не получаю того что заслуживаю
➖Хорошее отношение ко мне vs. несправедливое отношение

Можно заметить (можно же?), что практически в каждом примере "стоимость" будет выше у демотивирующих действий в несколько раз.

Далее, есть мотивация внутренняя (основанная на ценностях человека и его собственных представлениях) и внешняя (обусловленная факторами среды).

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

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

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

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

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

Профессионалы или любители?

Руководство людьми часто сравнивают с шахматами. Я сегодня тоже хочу сравнить.

Вы наверно слышали, что практически все профессионалы в шахматах - это люди, которые начали играть с детства. Да и не каждый, кто начал с детства - может стать профессионалом.

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

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

А что важно, чтобы побеждать на любительском уровне? Две вещи:

1. Для начала изучить основы и общую идею, зачем тут что-то делается - правила, цель, стадии, борьба за центр, развитие фигур, атака на короля, вот это всё. Это придает твоим действиям осмысленность.
2. Не совершать грубых ошибок (blunder, он же "зевок")

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

А много ли таких? Да в общем, достаточно мало. На любом уровне, вплоть до топ-менеджмента.

Кто-то может сказать - "ну-ну, он слишком критичен". Давайте я вам расскажу одну историю.

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

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

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

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

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

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

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

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

Есть огромное количество вариантов и методов постановки задач, всякие там user story, SMART и т.д. В основном это не очень универсально, не ко всем задачам подходит. Для каких-то избыточно.

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

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

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

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

➖Первый - это контекст. Это обстоятельства возникновения и постановки этой задачи, отвечает на вопросы: зачем/почему?

➖Второй - это ожидаемый результат. По каким критериям заказчик поймет, что всё в порядке? Это еще называется acceptance criteria (критерии приемки).

(В комментах пример постановки от chatgpt)

Тестировщикам это хорошо известно - описывая баг, они пишут:

Зашел туда-то (контекст), тыкнул туда-то (контекст)
Ожидаемое поведение: (критерии приемки)
Фактическое поведение: (контекст)

Тут та же универсальная идея заложена, это не случайно.

Самое время открыть свой таск-трекер и посмотреть как там пишутся задачи😁

Забавный эпизод был на днях - ЧатГПТ внезапно начал задавать вопросы без спроса. В итоге получился довольно интересный диалог, которым захотелось поделиться.

Началось всё так - я посмотрел несколько кусков из мок-собеса (тренировочное собеседование) на проектного менеджера, ну и оставил такое сообщение про один из вопросов:

"Команда факапит 4 спринта, что будешь делать?"

я конечно понимаю, что на собесе ожидают услышать другое - а есть варик отменить спринты, если они все равно не работают? ) Такой вариант кто-то рассматривает?

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

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

https://chatgpt.com/share/67af8f17-6388-8013-b6e3-9f4ce6cfc0b3

Easy to learn, hard to master.

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

Помню, как меня удивило, как мало хард-скиллов лежат в основе айти-менеджмента. Буквально, вот весь список:

1. Почитать про Agile (манифест + пару статей, раскрывающих смысл)
2. Прочитать scrum guide (~30 страниц)
3. Посмотреть пару лекций Пименова про Канбан-метод
4. Прочитать курс Селиховкина про проектный менеджмент (2-3 десятка коротких статей)

Это осваивается за 1-2 недели. Это не шутка, это всё, что используется как основа для организации командной разработки. Вся остальная информация - на 95% производная из этой, а 100% вам никогда не понадобится. В дополнение еще некоторые общие вещи:
➖какие бывают должности, роли, отделы
➖иметь общее представление о структуре коммерческой компании
➖что такое вообще разработка и из каких она состоит этапов (идея, бизнес-анализ, системный анализ, проектирование, разработка, тестирование и т.п.)

Пусть еще ~2 недели.

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

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

1. Будь исполнительным. (но) Постоянно подвергай сомнению задачи руководства
2. Будь дружелюбным. (но) Будь жестким
3. Будь терпимым к недостаткам. (но) Будь требовательным
4. Иди навстречу коллегам. (но) Не соглашайся на всё подряд
5. Ориентируйся на лучшие практики. (но) Придумывай свои решения, которые подходят в конкретной ситуации
6. Применяй системные решения. (но) Эффективно используй "костыли" (workarounds)
7. Наводи порядок. (но) Не закручивай гайки

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

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

You can learn it, but you can't teach it - еще одна поговорка, она означает, что некоторые вещи можно понять через опыт (анализ своих и чужих кейсов), но их невозможно передать другому человеку, просто объяснив.

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

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

Негативный фидбек - давать/не давать, как давать?

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

Позиции были примерно следующие:
1. Всегда надо давать
2. Не всегда надо давать

Вторую отстаивал я.

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

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

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

Бывают ситуации встречных претензий. Например:

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

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

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

2. Это должно в теории принести какую-то пользу.

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

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

Я примерно следующий алгоритм использую при принятии решений о критике в форме негативного фидбека:

❓запрашивал ли человек фидбек прямо?
Если да - я в любом случае отвечу как есть.

Если не запрашивал, то я в первую очередь задаю себе вопрос:
❓по совокупности плюсов и минусов, приносит ли человек пользу команде?

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

❓является ли решаемая проблема действительно деструктивной для команды?

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

Допустим, нам по совокупности нравится, как кто-то делает работу. Тогда функция фидбека - сделать его работу лучше. Отсюда следующий вопрос:

❓похоже ли, что человек готов улучшать свою работу и ему нужна эта информация?

Если нет - скорее всего не стоит. Если да:

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

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

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

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

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

1. Эта концепция проще. Действуешь по алгоритму - не ошибешься в неоднозначных ситуациях (корнер-кейсах)

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

3. Она дисциплинирует. Если лень - то нет отговорок типа "а может быть не надо".

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

Выводы на ваше усмотрение )

Зачем быть менеджером?

Вопрос не праздный на самом деле.

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

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

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

1. "Мне это нужно как промежуточный этап на пути к другой цели" (свой бизнес или топ-позиции)
2. "Мне это нравится"

За 0,5 сойдет что-то типа "я хочу попробовать и понять, нравится ли мне это". Лучше, конечно, понимать заранее.

Теперь попробую описать то, что я считаю "плохими" причинами, и расскажу, почему:

1. "Мне предложили и я согласился(лась)"
2. "Было некуда расти дальше по грейдам, только на тимлида"
3. "Хочу доказать, что я это могу" (себе или другим)
4. "Хочу власти/говорить другим что делать"
5. "Хочу, чтобы меня больше ценили/хочу признания"

И так далее.

Эти "плохие" варианты, как и хорошие, можно сгруппировать на 2 типа - ради выгоды (первые два), и ради эмоций (3-5).

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

Если мы говорим про амбициозного человека, то ради выгоды в смысле прибавки в деньгах не стоит целиться в позицию тимлида (да и вообще менеджера среднего звена) как конечную. Она с точки зрения затрат/профита не сбалансированная. Ответственности и усилий требуется больше намного, а прирост в зарплате - примерно 20-30% по рынку, на конкретном месте может быть и меньше. Если цель - деньги, или деньги в пересчете на час работы или единицу стресса - чаще всего есть какой-то другой, более выгодный вариант потратить усилия (например, дальнейшая прокачка в ветке технологий и работа на международном рынке - для разраба, в отличие от менеджера, достаточно среднего английского)

Если мы говорим про людей родом из нашего региона (страны бывшего СССР), то выйти на какие-нибудь $6-8k net разрабом, на мой взгляд, куда проще, чем сделать то же самое менеджером. По той информации, что у меня в наличии, я могу судить, что менеджеров с такими зп очень мало, а разрабов достаточно:

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

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

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

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

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

В конце концов, у большинства людей на Земле нет такой роскоши - не тянуть лямку, а заниматься тем, что действительно нравится.

Скрининговые макропоказатели на канбан-доске

Слова-то какие, а? Внушительные.

Но в общем это довольно простая вещь.

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

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

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

Давайте представим, что у нас есть какая-то обычная кросс-функциональная команда разработки, человек 10, работаем по классике в потоковом режиме, в Jira, есть канбан-доска. На что можно обратить внимание в первую очередь (числа даю условно, но чтобы было примерно понятно):

➖Слишком много задач в работе
➖Слишком мало задач в работе
➖У конкретных людей нет задач в работе
➖Много задач с "красными кружочками" (застряли на много дней, в том числе 30+)
➖Больше 10 задач в ревью
➖На ревью задачи с "красными кружочками"
➖Больше 10-20 задач в очереди на QA
➖Больше 15-20 задач в очереди на деплой
➖Задач в очереди больше, чем пропускная способность на несколько месяцев вперед
➖Много (двузначные числа, а не единицы) блокеров
➖Слишком много (большинство или даже почти все) задач высокого приоритета

Это статические показатели.

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

Для остальных показателей (cycle time, lead time, эффективность потока и т.п.), скорее всего уже надо будет настраивать метрики и это решение надо принимать отдельно и осознанно, просто так это не нужно. Это отдельная тема.

Соответственно, каждый показатель может быть признаком, что что-то идет не так. Расписывать, что может скрываться за каждым поста не хватит (пишите в комменты, если есть конкретные вопросы), но в общем логика должна быть такая:

Мы смотрим макропоказатели, если видим аномалии - это не причина делать конкретные выводы, а повод провести углубленный анализ и разобраться. Если аномалий нет - значит health check прошел успешно и занимаемся другими делами дальше. В идеале это делается раз в 1-2 недели.

Если у вас доска проходит этот health check, вы красавчики )

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

Как я использую схемы для планирования модернизации

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

Итак, я сел думать: какая текущая ситуация и что нам нужно улучшить?

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

Потом я делю этот список на 3 группы:
1. Работает хорошо (здесь внимание нужно минимально)
2. Работает плохо (основное внимание требуется сюда)
3. Работает средне, можно улучшить (сюда по остаточному принципу)

Эти группы - области на схеме, в них я размещаю критерии из списка.

Далее я провожу еще одну классификацию, и делю по следующему принципу:
1. Это мы можем решить своими силами
2. Это зона ответственности продакта (тут может быть любая ближайшая смежная роль или подразделение)
3. Это частично решаемо
4. Это заблокировано внешними обстоятельствами

Эти группы я размечаю цветом блоков

Далее я прикрепляю к каждому критерию свою субъективную оценку (хорошо, плохо, нормально, отлично и т.п.)

И, наконец, в секциях "работает плохо" или "средне" я набрасываю какие-то блоки, которыми можно это решить.

Получается результат как на картинке.

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

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

Управленческий рак

Когда я только перешел из разработки в менеджмент - я впервые пошел на совещание топ-менеджеров. Это была пятница, на совещании было 11 человек, включая гендира, директора по безопасности, Head of Product, несколько продактов и т.д. Как-либо имеющих отношение к разработке было 2 человека - я и мой руководитель (Коля, привет!) - директор по разработке.

Как обычно, когда я попадаю в какую-то новую для себя среду - я сидел тихо, наблюдал и делал заметки. И в какой-то момент я поймал себя на мысли, что 11 человек на совещании 20 минут обсуждают, что должны в следующем "спринте" делать 2 бэкенд разработчика %)

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

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

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

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

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

В приведенном выше примере в команде было 2 бэкенд разработчика, 1 фронтэнд, 1 тимлид (тоже фронт), 1-2 QA и 2-3 продакта (!) + Head of Product (!!).

И при этом еще продакты не могли нормально ставить задачи, что закончилось "костыльным" решением ввести роль системного аналитика, чтобы нивелировать неспособность продактов написать вменяемые задачи.

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

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

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

"Надо сделать" - о навыке коммуникации на примере одного антипаттерна.

Помню, в детстве мне мама говорила - "надо сходить за хлебом" или, скажем, "надо попылесосить". Мне уже тогда не нравилась эта фраза (хотелось ответить что-то типа - "мне не надо"). Не только потому, что я сидел играл во что-то, и не хотел отвлекаться )

Я эту обезличенную форму обращения к мирозданию встречаю на протяжении всей своей коммерческой работы. Что с ней не так?

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

Варианты:
1. В этой задаче нужно было уточнить требования, но я забыл это сделать. Сделаю (решили блокер)
2. Можешь уточнить у продакта требования по этой задаче? (просьба к другому человеку)
3. Я собираюсь уточнить требования, просто еще не успел (статус)
4. Нужно уточнить требования, но я не знаю, кто и как должен это сделать (постановка проблемы)
5. Нужно уточнить требования, но мне это не интересно/меня не касается (слив с темы)

Вы будете снова и снова сталкиваться с тем, что такая постановка задачи (а "надо" - это задача) приводит к тому, что задача не делается, или делается несвоевременно.

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

Хорошая коммуникация о том, что что-то нужно сделать должна содержать следующее:
1. Действия, которые нужно совершить
2. Ответственного, который их должен сделать
(Если это что-то важное/срочное - в идеале еще временные рамки.)

То есть отвечать на вопросы - кто и что должен сделать.

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

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

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

Оценка времени на разработку

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

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

Этот пост - краткое введение в тему: какие оценки бывают, чем отличаются, как применяются.

Во-первых, есть оценки трудозатрат и оценки сроков. Второе часто вытекает из первого.

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

Оценки сроков - это когда мы пытаемся заранее угадать, когда задача будет завершена (например, поставлена в продакшен).
Например: "это задача будет на проде через 2 недели - в понедельник".
Область применения - от согласования деятельности разных отделов до анонса багфикса клиентам.

Во-вторых, бывают оченки в единицах времени и в "попугаях" (условных единицах).

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

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

Кроме условных оценок в числовых единицах еще есть упрощенные условные оценки - например, система "маек" - XL, L, M, S, XS - это отражает примерный размер задачи (допустим L - до недели разработки).

В-третьих, оценки делятся на прогностические и эмпирические.

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

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

В-четвертых, оценки делятся на индивидуальные и групповые.

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

Групповые могут понадобиться в двух случаях:

1. Работает команда, и надо учитывать и согласовывать работу разных людей
2. Есть цель сделать оценку менее зависимой от мнения 1 человека, поэтому несколько людей дают оценку одной и той же работе, а потом группа обсуждает эти мнения (например - в формате planning poker, об этом можно почитать отдельно).

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

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

Оценка чужой работы - инструмент, который может использоваться для контроля или проверки (в том числе постфактум). Например, тимлид сам делает оценку задач для своей команды или менеджер анализирует объем работы, выполненный за квартал кем-то из лоу-перформеров.