Кто все эти люди и почему у всех "менеджер" в подписи? (Часть 2)

Давайте разберёмся, кто же ещё играет в айти-менеджменте не последнюю роль.

9. Менеджер поставки продукта (Delivery Manager, DM)

Функционал:
- Отвечает за финальную доставку продукта клиенту.
- Убеждается, что всё работает не только "на тестах", но и в проде.
- Разруливает контракты, SLA и прочие юридические моменты с клиентами.

Отличие от PjM-а: формально PjM ведёт проект до релиза, DM - от релиза до счастливого клиента.

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

10. Технический менеджер (Engineering Manager, EM). Гибрид технаря и управленца (часто бывший senior dev).

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

Отличие от техлида: управляет людьми, а не принимает технические решения.

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

11. Программный менеджер (Program Manager, PgM)

Функционал:
- Управляет несколькими связанными проектами (программой).
- Следит, чтобы все проекты стыковались между собой.
- Координирует PM-ов, как дирижёр оркестра.

Отличие от PjM: PM ведёт 1 проект (по науке), а PgM - цепочку проектов (например, весь новый функционал банка).

Отличие от Portfolio Manager: у программного менеджера менее стратегическая роль и тематически/идеологически связанные проекты, а не весь портфель компании.

Аналог - продюсер сериала: следит, чтобы все серии были в одном стиле и выходили вовремя.

12. Менеджер релизов (Release Manager, RelM)

Функционал:
- Контролирует, чтобы новый код не сломал прод.
- Планирует даты релизов, откаты, хотфиксы.
- Кричит "Кто залил эту хрень в прод без тестов?!".

Т.о. RelM управляет процессом выкатки.

Аналог - диспетчер авиарейсов: решает, когда можно взлетать, а когда лучше подождать.

13. Менеджер по трансформации (Transformation Manager, TrM)

Функционал:
- Внедряет новые процессы и методологии (Agile, DevOps, цифровизацию).
- Убеждает консервативных сотрудников, что "теперь так надо, точно говорю".
- Измеряет эффективность изменений (и терпит неудачи).

Отличие от Scrum Master: Scrum Master работает в рамках одной команды, Transformation Manager - на уровне всей компании.

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

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

Story Points: когда SP лучше, чем часы и при чём тут Фибоначчи

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

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

Для всего остального существуют Story Points. Хотя не, преувеличиваю. SP чаще ассоциируются именно со Скрамом, при этом в теории их можно заюзать и в Канбане, и в SAFe, и в других гибких методологиях.

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

Предположим, команда решает, что эталонная задача весит 1 SP. Задача, которая примерно вдвое сложнее эталонной - 2 SP. Втрое сложнее - 3 SP. А дальше? 4, 5, 6..? Нет. Было бы всё линейно - не было бы смысла искать альтернативу часам. Суть в том, что чем задача объемней/сложней, тем менее точной может быть оценка, связанная с этой задачей. Это факт. Поэтому для оценки задач в SP используется не стандартный набор натуральных чисел, а, например, ряд Фибоначчи (напомню, в последовательности чисел Фибоначчи каждое следующее число является суммой двух предыдущих): 1, 2, 3, 5, 8, 13, 21, 34...

Сложную задачу трудно оценить относительно эталонной, поэтому команда может сказать, что, к примеру, 8 SP для нее является более вероятной оценкой, чем 5, поскольку разница между 8 и 5 более очевидна, чем между 6 и 5 (если бы это был стандартный ряд натуральных чисел).

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

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

1) потратить время на максимальную декомпозицию: разбить проект/задачу на атомы, оценить в человеко-часах и просуммировать, учесть риски и/или накинуть сверху классические 30% в качестве страховки;
2) попытаться натянуть сову на глобус и на основании исторических данных конкретно вашей команды, опираясь на velocity и logged hours в тасках, сопоставить SP и часы, затраченные на задачи. К примеру, если задача сложностью 3 SP выполняется в среднем 6 часов, то 1 SP примерно равен двум часам. Но это не самая лучшая практика - попытка сравнивать мягкое с теплым.

SMART: как заставить свои планы перестать врать

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

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

Разберём аббревиатуру.

S (Specific) - цель должна быть конкретной.

Не конкретная цель: "Хочу круто выглядеть".
Конкретная цель: "Хочу увеличить размер груди на будущей неделе".

Здесь вы даёте понять, за счёт чего конкретно вы будете круто выглядеть.

M (Measurable) - цель должна быть измеримой.

Не измеримая цель: "Научиться играть на гитаре".
Измеримая цель: "Научиться играть три блатных аккорда".

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

A (Achievable) - цель должна быть достижимой.

Не достижимая цель: "Выучить традиционный китайский за месяц".
Достижимая цель: "Достигнуть уровня B1 в традиционном китайском за 3 месяца".

Здесь вы ставите реалистичную цель в противовес наполеоновским планам.

R (Relevant) - цель должна быть релевантной вашим потребностям/ценностям и/или потребностям/ценностям вашей компании, должна соответствовать контексту.

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

Здесь вы осваиваете навык, полезный для деятельности в рамках вашей профессии.

T (Time-bound) - цель должна иметь временные рамки.

Цель без временных рамок: "Мы должны реализовать этот проект".
Цель с временными рамками: "Мы должны реализовать этот проект за 3 недели, начинаем завтра".

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

---

Почему это работает?

Потому что:

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

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

Письменная грамотность в IT: бонус, а не критерий

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

Язык - он как пила. Пилой нужно пилить доски - это её основная функция. Наслаждаться блеском её полотна тоже можно, но необязательно.

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

И да, работодатель не платит за правильно расставленные запятые. "Мы ищем Senior Java-developer с безупречным русским языком" - сказал никто и никогда.

Вас критикуют? Человек с гордым шильдиком "Grammar nazi" 90% поправок делает не для ясности, а для самоутверждения, при этом зачастую не может отличить REST от SOAP. Хотя практика показывает, что это уже почти вымерший вид.

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

Однако

Однако если у вас в резюме ошибка на ошибке, то вас нафиг никто не захочет нанимать (если вы, конечно, не Линус Торвальдс), ведь было же время всё поправить. Здесь уже дело не в спешке и перераспределении приоритетов, а в банальном наплевательском отношении к делу.
Кроме того, работая в IT, вы можете пилить презы для демо, переписываться с клиентом, генерить пользовательские гайды и т.д., т.е. заниматься вещами, где грамотная писанина значит решительно больше, чем может показаться с первого взгляда.

Бережливое производство: как выжимать максимум из любого процесса

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

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

Итогом дум и стенаний стал набор принципов и методик, который со временем лёг в основу той самой методологии. Если коротко, вот её основные аспекты:

- Работать следует над ценностью, а ценность - то, за что клиент платит деньги;
- при работе следует избегать потерь, потери - всё то, что не создаёт ценность: работа в стол, ожидания, переделки etc;
- ценность должна доставляться до клиента без остановок.

Лютая оптимизация, в общем.

Что же это такое в контексте айти-индустрии?

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

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

2) Старайтесь организовывать работу без пауз. У каждого разработчика/тестировщика/аналитика... в любой момент времени должна быть задача.

3) Ищите узкие места. Если, к примеру, тестирование традиционно тормозит весь процесс, посмотрите в сторону найма и/или автоматизации.

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

5) Автоматизируйте всё, что имеет св-во повторяться: билды, деплой, тесты, отчёты. Внедряйте ботов, напоминающих о ритуалах, регламентах и т.п.

6) Оптимизируйте любые коммуникации: чёткое обозначение темы, ограничение по времени.

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

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

Метод помидора: инструмент тайм-менеджмента от ленивого итальянского студента

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

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

А что после?

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

- 25 минут сосредоточенной работы без отвлечения даже на Слак и Телегу;
- 5 минут отдыха;

- 25 минут сосредоточенной работы без отвлечения даже на кофе;
- 5 минут отдыха;

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

- 25 минут сосредоточенной работы без отвлечения даже на зуд в заднице;
- 5 минут отдыха;

- перерыв 30-60 минут.

Итого: 4 помидора == 2 часа продуктивной работы. Кмк, неплохо. В таком темпе сложно отработать весь стандартный 8-часовой рабочий день, но 12-14 помидоров в течение дня вполне возможно окучить.

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

Как методология превращает хаос в результат: инструкция по подбору

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

Waterfall ("Водопад", каскадная модель)

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

Строго, скучно, старомодно, негибко (надо же), в реальности часто обрастает бюрократией.

Когда целесообразно применять:
▪️когда работаете в госсекторе и жестко облеплены индустриальными регламентами (например, военпром, медицина), как комарами в карельском лесу;
▪️когда бюджет, сроки и документация - железобетон, хоть ты тресни.

Scrum

Гибко на дистанции, но строго в рамках отдельно взятого спринта. Подразумевает наличие спринтов, ритуалов (планирование, дейлики, ретрики) и внутрикомандных ролей (PO, SM).

Когда целесообразно применять:
▪️когда требования периодически меняются;
▪️когда есть потребность регулярно обновлять продукт и тестировать гипотезы;
▪️когда нужно придать коллективу чуть больше тонуса и структурности (за счет жестко фиксированного объема работы в рамках спринта, четких ролей и некоторых ритуалов);
▪️когда нужно держать руку на пульсе, чувствовать ритм команды.

Исходя из сказанного выше: Скрам идеален для стартапчиков и/или команд с вышедшей из чата рабочей дисциплиной.

Kanban

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

Когда целесообразно применять:
▪️когда сложно спланировать поток работы: летят баги, делаются хотфиксы, возникают вопросы и задачи, требующие оперативного решения;
▪️когда поток задач в принципе непрерывен и нет смысла делить разработку на итерации, планируя уникальный набор фич и фиксов каждый раз;
▪️когда важно оставаться сверхгибкими, когда важно иметь возможность отвлекаться на внезапно возникающие задачи/проблемы;

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

Scrumban

Scrumban - гибрид Скрама и Канбана.

Целесообразно применять в командах, не готовых к закрученным по самое не хочу гайкам, как в Скраме, но, всё же, требующих определенного порядка и структуры. Грубо говоря: не тратим время на кучу ритуалов, оставляя только реально полезные, имеем условные спринты (релизимся раз в полмесяца-месяц) и размытое планирование, хаваем все типы тикетов в любое время: новые фичи, баги от QA-отдела и техподдержки.

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

Circleback.ai: твой AI-бро, который разгребает митинговый ад

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

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

Итак, шо оно умеет:

1) Делать качественные выжимки из любых "высокоэффективных" переговоров, не упуская ничего важного. Час трепа про релиз? Получите на выходе 3 строчечки:
▪️бюджет на 600К утверждён,
▪️розовый градиент для UI одобрен,
▪️дедлайн - вчера.

2) Генерить достойные транскрипты: ~95% точности, даже если ваш админ шпарит на смеси DevOps-овского и суржика. Тулза знает более 100 языков - от китайского до португальского.

3) Искать лучше Шерлока: забыл, кто предлагал прикрутить A/B-тесты? Спроси бота, он найдёт момент быстрее, чем ты делаешь глоток смузи.

4) Клепать экшн-айтемы на стероидах: сказал на планировании "Васян, задизайнь, плз, лендинг к среде" - Circleback запилил таск в Джире и пинганул Васяна в Слаке. Да, в наличии прямые интеграции с Notion, Slack, Гугл-календарём и прочими сервисами, а через посредников типа Zapier можно интегрировать еще +Х2 полезных инструментов.

В чем цимес?
Circleback тащит рутину, пока вы фокусируетесь на реальной работе. Больше времени на код, на тесты, на аналитику, на управление и т.д.

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

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

Такие дела.

И да, если вы созваниваетесь только по субботам и только с мамулей, оно вам нафик не надо.

Проектный треугольник, или как объяснить заказчику, что чудес не бывает

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

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

▪️Можно сделать быстро и дёшево, но это будет некачественно (потому что делает джун, который путает SQL и SSL);
▪️Можно сделать качественно и дёшево, но это будет очень долго (даже джун за это время научится и обеспечит приемлемое качество);
▪️Можно сделать быстро и качественно, но это будет дорого (нанимаем, например, парочку сеньоров или делегируем работу качественному подрядчику, отслюнявливая столько фантиков, сколько требуется).

Подкрепим эти аспекты примером из жизни: Ванька сел в телегу и повёз на сельский рынок яйца (куриные).

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

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

Реквием по офису или особенности работы с удалённой командой разрабов

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

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

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

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

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

▪️Внедрите простые и понятные регламенты: когда задачу брать в оборот, кому отдавать на ревью, когда ревью не нужно, как готовить задачу к тестированию и т.д. Не должно быть ситуации, когда разраб скажет вам: "Бро, я не знал, как дальше быть, поэтому ничего не делал".

▪️Обучите тех, кто нуждается, работе с PMS (Project Management System) и прочими инструментами, чтобы сделать процесс непрерывней и прозрачней: эстимейты на таски, трекинг времени, перевод задач в нужное время в нужные статусы etc.

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

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

▪️Опирайтесь на базовые метрики производительности команды и отдельных разработчиков. Прежде всего:
🔹соблюдение дедлайнов,
🔹неравнодушие не только к своим таскам, но и к продукту в целом,
🔹качество работы (кол-во и кач-во ошибок по результатам тестирования),
🔹Velocity (в случае работы по Скраму) или, например, Throughput (если рулит Канбан).

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

Из джунов в CTO, или эффект Даннинга-Крюгера

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

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

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

IT-команда против HR: битва за компетентных сотрудников

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

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

Что здесь не так?

▪️Рекрутеры технически не подкованы ни на йоту. Что делать: даже на первое вью готовить ряд глубоких технических вопросов, выдавать их рекрутеру и просить чётко фиксировать ответы кандидата.

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

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

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

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

P.S.: да, софт-скиллз, безусловно, тоже важны, но не для всех и не всегда, либо не в той степени.

Дейли-митинг: кто не успел - тот расскажет завтра

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

Но сначала немного истории
Сама идея коротких ежедневных планёрок для синхронизации команды родилась вовсе не в IT. Она была заимствована IT из производственной практики Бережливого производства (Lean), придуманной Toyota в бородатых 80-х. Частью фреймворка Scrum ритуал стал в начале 90-х, а в манифест Agile был включен только в 2001 году.

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

Формат:
▪️если офлайн, команда поднимает жопки с кресел и становится в круг (можно в овал, но ни в коем случае не в квадрат);
▪️если онлайн, то войти в конфу можно даже лёжа в кровати (не забудьте заклеить камеру изолентой от греха подальше).

Время:
15 минут на всю команду. Даже если в команде 30 человек, вы обязаны попытаться уложиться в 15 минут. Если команда небольшая, каждому участнику отводится не более 2-3 минут. Тчк.

О чём галдёж?
Каждый из участников синка (кроме тамады) отвечает на вопросы:
▪️Что он сделал вчера?
▪️Что он планирует сделать сегодня?
▪️С какими блокерами он столкнулся?

И ничего более! Никаких драм, лирики, демагогии и микроменеджмента!

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

Что по ролям?
ИТ-директор сказал, что у вас скрам, а Scrum-мастера не дал? Не беда. Команда может самоорганизоваться и провести митинг без участия тамады. В крайнем случае помогут PjM и/или Тимлид, хотя ведение ими митинга несколько противоречит духу Agile/Scrum.

Закон Литтла и его применение в IT-менеджменте

Закон Литтла (Little's Law) - это фундаментальный закон в теории массового обслуживания и теории очередей. Закон был доказан и формализован американским профессором Джоном Литтлом в 1961 году, хотя интуитивно применялся задолго до этого.

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

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

В большей или меньшей степени закон применим вообще для любой сферы бизнеса/производства, где актуален поток задач/заявок, но нас традиционно интересует айтишечка. Если чуточку пораскинуть мозгами, придем к выводу, что три наиболее популярных канбановских метрики - WIP, Throughput, Cycle Time - ни что иное, как три параметра обозначенной выше формулы.

Что за метрики:
Work in Progress (WIP) - количество задач, находящихся в работе одновременно (то, что на борде между столбцами "In progress" и "Done").
Throughput — пропускная способность команды (например, 5 задач в неделю).
Cycle Time — среднее время выполнения одной задачи, начиная с момента непосредственной работы над ней.

Итого, Закон Литтла в Канбане будет выглядеть так: WIP = Throughput * Cycle Time

В чем польза применения Закона Литтла здесь:
▪️возможность манипулировать одними параметрами, изменяя другие;
▪️возможность прогнозировать сроки, бюджеты, ресурсы;
▪️возможность фокусироваться на потоке, а не на утилизации задач: вместо того чтобы заставлять всех быть фултайм занятыми (это неизбежно приведет к росту WIP и росту времени выполнения каждой задачи), закон учит ценить быстрый поток задач от начала до конца.

Примеры применения:
▪️если ограничить количество одновременно выполняемых задач (WIP), то при стабильной пропускной способности (Throughput) среднее время выполнения задачи (Cycle Time) автоматически уменьшится.
▪️зная свою текущую пропускную способность и количество задач в бэклоге, можно предсказать, когда будет допилен проект.

Это основы Канбана.

А теперь пара слов о подводных камнях:

▪️Закон Литтла идеален для ситуаций, когда все задачи, проходящие через систему, имеют приблизительно одинаковый объем и сложность, однако это не про айти. В нашем с вами случае, т-щи, следует использовать, как вы уже догадались, Story Points или человеко-часы.

Оперируя, например, часами, получим:
WIP - это не "штуки", а сумма эстимейтов (в часах), находящихся в работе.
Throughput измеряется в человеко-часах, реализуемых за единицу времени (например, за неделю).
Cycle Time - время выполнения задачи в часах.

Скорректированная т.о. формула будет работать идеально в том случае, если ваши оценки достаточно точны, а производительность команды относительно стабильна. На практике так бывает нечасто, поэтому держим в уме возможность использования Story Points для оценки задач (если, конечно, заказчик не против такой затеи). Да, Story Points - это по ряду причин чаще скрамовская история, чем канбановская, но где наша не пропадала? Стабилизируйте команду и переходите обратно на часы.

▪️Надо помнить, что 9 женщин не способны родить ребенка за 1 месяц. Сам по себе Закон Литтла не учитывает этот аспект, но помогает его обнаружить. Он утверждает, что если ваша система устойчива и способна обрабатывать поступающую нагрузку, обозначенные три параметра будут связаны описанной формулой. При этом он не гарантирует, что вы можете бесконечно уменьшать Cycle Time, уменьшая WIP.

Проект не "на авось". Правила работы с рисками в IT

Наверное, у каждого был/есть приятель со слегка присвистывающей флягой, который любил бросать монетку на распутье, полагаясь на волю судьбы во всякой ситуации. Так себе история. Мы с вами не такие, коллеги (да ведь?)! Нам нужна аналитика, нам нужны обоснования, мы четко понимаем, что воля судьбы - это недостаточно надежный инструмент управления проектами.

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

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

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

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

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

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

Стратегии для работы с позитивными рисками (когда вдруг повезло)

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

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

3. Разделение
Пример: запартнёрились с другим стартапом: если проканает - вместе в Forbes (если нет - вместе на hh.ru).

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

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

Работайте с рисками, товарищи

PjMs в IT. Какие бывают архетипы?

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

Итак, коротенько о том, какие бывают крены:

PjM-аналитик
Такие товарищи ковыряются с проектными метриками (velocity, burndown), анализируют риски (SWOT, Monte Carlo), строят даши в Джире, прогнозируют bottlenecks, опираясь на историю и т.д. В результате заказчик получает минимум сюрпризов в вопросах планирования бюджетов и времени, но имеет риски просадок по другим направлениям, например, вполне может получить ушатанную и демотивированную после сдачи проекта команду.

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

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

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

PjM-фоллоу-аппер
Ежедневно пингует в Слаке по статусу задач, трекает прогресс на дейликах, эскалирует задержки стейкхолдерам, генерит daily-reports, обновляет борд в Джире. При нем проекты наверняка не потонут, однако команда чувствует себя под микроскопом. Подход дает буст в сложных условиях типа, например: распределенная команда + финтех + жесткие дедлайны.

PjM-аудитор
Проводит, как ни странно, аудиты процессов: чекает исполнение методологий, анализирует сбои и инциденты на проектах, выявляет места просадок, предлагает фикс-чеклисты и улучшения процессов. Фокус - на уроках из фейлов. Этот товарищ обычно страхует от повторяющихся ошибок, но часто замедляет темп проектов. Часто встречается в enterprise.

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

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

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

Масштабироваться, а не героически выгорать

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

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

Итак, когда стоит делегировать

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

К слову, привет из PMBOK и классики менеджмента: манагер отвечает за результат, но не обязан делать всё своими руками.

Отсюда проистекают и обратные правила - когда делегировать НЕ стоит

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

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

Опасности делегирования
▪️"Я же сказал сделать нормально" - нет, вы не сказали, вы подумали. Формулируйте задачу правильно.
▪️Микроменеджмент: делегировали - и погнали стоять над душой, в таком делегировании нет никакого смысла.
▪️Потеря контроля: не настроили чекпоинты - получили нежданчик к дедлайну.

Опасности НЕ делегировать
▪️Риск стать бутылочным горлышком всей команды/компании, как уже было сказано выше.
▪️Люди вокруг вас не растут (а потом вы жалуетесь, шо "нихто не тянет").
▪️Вы выгораете, биз тормозит: глупо и недолго.

Ну и какие правила выводим отсюда, т-щи
▪️Чётко формулируйте, что и как должно быть на выходе + как поймёте, что это именно то, что надо (SMART в помощь, к примеру).
▪️Давайте хотя бы кратко контекст, зачем это вообще нужно, иначе можете получить формально правильный результат, а по сути - хрень.
▪️Определите границы: где человек принимает решения сам, а где эскалирует (RACI в помощь).
▪️Зафиксируйте чекпойнты, не влезайте каждые 5 минут со своими ЦУ.
▪️Не забывайте про обратную связь после выполнения: в противном случае коллеги не научатся.
▪️Ответственность остаётся у вас. Всегда. Не нравится - не нужно менеджерить.

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