Как методология превращает хаос в результат: инструкция по подбору
Макро-методологий и фреймворков, применяемых в IT для управления процессом разработки, чуть меньше, чем дофига. Гибких, негибких и гибридных. Разбирать каждую - писать пост до пенсии, поэтому сегодня пробежимся по четырём самым популярным ин зе ворлд. Это пост о том, как и в зависимости от каких обстоятельств подбирать методологию под тот или иной проект.
Waterfall ("Водопад", каскадная модель)
Классический последовательный процесс, подразумевающий следующий набор этапов:
1) сбор и формирование требований;
2) проектирование;
3) реализация;
4) тестирование;
5) внедрение и сопровождение.
Строго, скучно, старомодно, негибко (надо же), в реальности часто обрастает бюрократией.
Когда целесообразно применять:
▪️когда работаете в госсекторе и жестко облеплены индустриальными регламентами (например, военпром, медицина), как комарами в карельском лесу;
▪️когда бюджет, сроки и документация - железобетон, хоть ты тресни.
Scrum
Гибко на дистанции, но строго в рамках отдельно взятого спринта. Подразумевает наличие спринтов, ритуалов (планирование, дейлики, ретрики) и внутрикомандных ролей (PO, SM).
Когда целесообразно применять:
▪️когда требования периодически меняются;
▪️когда есть потребность регулярно обновлять продукт и тестировать гипотезы;
▪️когда нужно придать коллективу чуть больше тонуса и структурности (за счет жестко фиксированного объема работы в рамках спринта, четких ролей и некоторых ритуалов);
▪️когда нужно держать руку на пульсе, чувствовать ритм команды.
Исходя из сказанного выше: Скрам идеален для стартапчиков и/или команд с вышедшей из чата рабочей дисциплиной.
Kanban
Непрерывный поток задач без истерик и страха не закрыть спринт, минимум митингов, акцентированная работа с доской задач.
Когда целесообразно применять:
▪️когда сложно спланировать поток работы: летят баги, делаются хотфиксы, возникают вопросы и задачи, требующие оперативного решения;
▪️когда поток задач в принципе непрерывен и нет смысла делить разработку на итерации, планируя уникальный набор фич и фиксов каждый раз;
▪️когда важно оставаться сверхгибкими, когда важно иметь возможность отвлекаться на внезапно возникающие задачи/проблемы;
Исходя из сказанного выше: Канбан чаще подходит для поддержания уже действующих продуктов, пребывающих в КЭ, а также для зрелых и сыгранных команд.
Scrumban
Scrumban - гибрид Скрама и Канбана.
Целесообразно применять в командах, не готовых к закрученным по самое не хочу гайкам, как в Скраме, но, всё же, требующих определенного порядка и структуры. Грубо говоря: не тратим время на кучу ритуалов, оставляя только реально полезные, имеем условные спринты (релизимся раз в полмесяца-месяц) и размытое планирование, хаваем все типы тикетов в любое время: новые фичи, баги от QA-отдела и техподдержки.
Скрамбан чаще подходит для поддержания уже действующих, но всё еще активно развивающихся и видоизменяющихся продуктов.
Макро-методологий и фреймворков, применяемых в IT для управления процессом разработки, чуть меньше, чем дофига. Гибких, негибких и гибридных. Разбирать каждую - писать пост до пенсии, поэтому сегодня пробежимся по четырём самым популярным ин зе ворлд. Это пост о том, как и в зависимости от каких обстоятельств подбирать методологию под тот или иной проект.
Waterfall ("Водопад", каскадная модель)
Классический последовательный процесс, подразумевающий следующий набор этапов:
1) сбор и формирование требований;
2) проектирование;
3) реализация;
4) тестирование;
5) внедрение и сопровождение.
Строго, скучно, старомодно, негибко (надо же), в реальности часто обрастает бюрократией.
Когда целесообразно применять:
▪️когда работаете в госсекторе и жестко облеплены индустриальными регламентами (например, военпром, медицина), как комарами в карельском лесу;
▪️когда бюджет, сроки и документация - железобетон, хоть ты тресни.
Scrum
Гибко на дистанции, но строго в рамках отдельно взятого спринта. Подразумевает наличие спринтов, ритуалов (планирование, дейлики, ретрики) и внутрикомандных ролей (PO, SM).
Когда целесообразно применять:
▪️когда требования периодически меняются;
▪️когда есть потребность регулярно обновлять продукт и тестировать гипотезы;
▪️когда нужно придать коллективу чуть больше тонуса и структурности (за счет жестко фиксированного объема работы в рамках спринта, четких ролей и некоторых ритуалов);
▪️когда нужно держать руку на пульсе, чувствовать ритм команды.
Исходя из сказанного выше: Скрам идеален для стартапчиков и/или команд с вышедшей из чата рабочей дисциплиной.
Kanban
Непрерывный поток задач без истерик и страха не закрыть спринт, минимум митингов, акцентированная работа с доской задач.
Когда целесообразно применять:
▪️когда сложно спланировать поток работы: летят баги, делаются хотфиксы, возникают вопросы и задачи, требующие оперативного решения;
▪️когда поток задач в принципе непрерывен и нет смысла делить разработку на итерации, планируя уникальный набор фич и фиксов каждый раз;
▪️когда важно оставаться сверхгибкими, когда важно иметь возможность отвлекаться на внезапно возникающие задачи/проблемы;
Исходя из сказанного выше: Канбан чаще подходит для поддержания уже действующих продуктов, пребывающих в КЭ, а также для зрелых и сыгранных команд.
Scrumban
Scrumban - гибрид Скрама и Канбана.
Целесообразно применять в командах, не готовых к закрученным по самое не хочу гайкам, как в Скраме, но, всё же, требующих определенного порядка и структуры. Грубо говоря: не тратим время на кучу ритуалов, оставляя только реально полезные, имеем условные спринты (релизимся раз в полмесяца-месяц) и размытое планирование, хаваем все типы тикетов в любое время: новые фичи, баги от QA-отдела и техподдержки.
Скрамбан чаще подходит для поддержания уже действующих, но всё еще активно развивающихся и видоизменяющихся продуктов.
✍3❤2⚡1👍1💯1
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/мес за юзера - слегка кусачий ценник для обывателя. Однако уверен, большинство работодателей с удовольствием покроют эти расходы, лишь бы польза была.
▪️Кастомайз под сложные процессы пока не идеален.
Такие дела.
И да, если вы созваниваетесь только по субботам и только с мамулей, оно вам нафик не надо.
Ну что, т-щи яжпрограммисты и прочие белые воротнички из айтишечки, пришло время выключать ваши диктофоны и прекращать судорожное конспектирование созвонов, ибо прогресс - он прёт, его не остановить. Сегодня речь пойдёт о 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/мес за юзера - слегка кусачий ценник для обывателя. Однако уверен, большинство работодателей с удовольствием покроют эти расходы, лишь бы польза была.
▪️Кастомайз под сложные процессы пока не идеален.
Такие дела.
И да, если вы созваниваетесь только по субботам и только с мамулей, оно вам нафик не надо.
👍10✍3
Проектный треугольник, или как объяснить заказчику, что чудес не бывает
Время, бюджет, качество - три столпа, три ключевые метрики любого проекта вашей компании, да чоужтам, три ключевые метрики вообще любой вашей жизненной активности, включая поход в уборную или ковыряние в носу.
Суть: любой проект нельзя сделать одновременно быстро, качественно и дёшево. В лучшем случае придётся выбрать два пункта из этих трёх. На пальцах:
▪️Можно сделать быстро и дёшево, но это будет некачественно (потому что делает джун, который путает SQL и SSL);
▪️Можно сделать качественно и дёшево, но это будет очень долго (даже джун за это время научится и обеспечит приемлемое качество);
▪️Можно сделать быстро и качественно, но это будет дорого (нанимаем, например, парочку сеньоров или делегируем работу качественному подрядчику, отслюнявливая столько фантиков, сколько требуется).
Подкрепим эти аспекты примером из жизни: Ванька сел в телегу и повёз на сельский рынок яйца (куриные).
▪️Ванька запряг всего одну лошадку (дёшево) и поехал по короткой ухабистой дороге (быстро), итог - половина яиц по дороге выпала из телеги (низкое качество);
▪️Ванька запряг всего одну лошадку (дёшево) и поехал по длинной асфальтированной дороге (медленно), итог - приехал с целыми яйцами (качественно), но, правда, уже тогда, когда все, кто хотел купить яйца, купили их у конкурентов;
▪️Ванька запряг три лошадки (дорого) и поехал по длинной асфальтированной дороге (с тремя лошадками - быстро), итог - сохранил яйца целыми (качественно), да ещё и приехал раньше конкурентов.
** Дабы не диссонировало: любая работа по умолчанию должна выполняться быстро и с приемлемым для бизнеса качеством, но скорость и качество при этом всегда будут адекватны имеющимся в распоряжении ресурсам. Сложности возникают именно тогда, когда заказчик требует быстрее и/или качественнее, и/или дешевле, чем позволяют существующие ресурсы.
Время, бюджет, качество - три столпа, три ключевые метрики любого проекта вашей компании, да чоужтам, три ключевые метрики вообще любой вашей жизненной активности, включая поход в уборную или ковыряние в носу.
Суть: любой проект нельзя сделать одновременно быстро, качественно и дёшево. В лучшем случае придётся выбрать два пункта из этих трёх. На пальцах:
▪️Можно сделать быстро и дёшево, но это будет некачественно (потому что делает джун, который путает SQL и SSL);
▪️Можно сделать качественно и дёшево, но это будет очень долго (даже джун за это время научится и обеспечит приемлемое качество);
▪️Можно сделать быстро и качественно, но это будет дорого (нанимаем, например, парочку сеньоров или делегируем работу качественному подрядчику, отслюнявливая столько фантиков, сколько требуется).
Подкрепим эти аспекты примером из жизни: Ванька сел в телегу и повёз на сельский рынок яйца (куриные).
▪️Ванька запряг всего одну лошадку (дёшево) и поехал по короткой ухабистой дороге (быстро), итог - половина яиц по дороге выпала из телеги (низкое качество);
▪️Ванька запряг всего одну лошадку (дёшево) и поехал по длинной асфальтированной дороге (медленно), итог - приехал с целыми яйцами (качественно), но, правда, уже тогда, когда все, кто хотел купить яйца, купили их у конкурентов;
▪️Ванька запряг три лошадки (дорого) и поехал по длинной асфальтированной дороге (с тремя лошадками - быстро), итог - сохранил яйца целыми (качественно), да ещё и приехал раньше конкурентов.
** Дабы не диссонировало: любая работа по умолчанию должна выполняться быстро и с приемлемым для бизнеса качеством, но скорость и качество при этом всегда будут адекватны имеющимся в распоряжении ресурсам. Сложности возникают именно тогда, когда заказчик требует быстрее и/или качественнее, и/или дешевле, чем позволяют существующие ресурсы.
👍4💯2
Реквием по офису или особенности работы с удалённой командой разрабов
Вы, находясь, скажем, в Москве, встаёте с кровати, идёте в душ, съедаете свой привычный омлет и садитесь за станок, в это время вашему техлиду Васе из Лиссабона всё ещё снятся розовые слоники и голубые зайчики, а тестер Петя из Новосиба оттарабанил уже практически половину рабочего дня. Что происходит? Ничего особенного: люди работают удалённо, да еще и разбросаны географически по всему миру - таковы современные реалии жизни многих айти-компаний. Как в подобной ситуации должна себя вести IT-команда в целом и менеджер в частности?
Удалёнка в IT - это всегда вызов для пиэма, который должен дирижировать распределенным оркестром в онлайне. Личные разговоры у кофе-машины ушли в прошлое, теперь всё в Джирах, Слаках и Гуглмитах. Не видя людей за рабочим столом, бывает сложно заметить, что кто-то закопался в задаче или просто теряет интерес ко всему происходящему. Сроки растягиваются, бюджет увеличивается, недопонимание между коллегами растет, следствием всего этого могут стать неудовлетворительные или даже плачевные результаты по проекту.
Пара слов о базовых аспектах, которые позволят избежать всего этого срама. К слову, большинство из них в той или иной степени актуальны и для офлайн-формата.
▪️Постарайтесь организовать работу т.о., чтобы бОльшая часть команды пересекалась по времени хотя бы на 2-4 часа в течение дня. На это время можно планировать совместные синки с целью обсуждения задач или проведения ритуалов.
▪️Никогда не оставляйте исполнителей без задач. Каждый должен знать, что пилить, даже если вас сию секунду нет рядом. Более того, каждый должен знать, что пилить в первую очередь, что во вторую, а что в третью. Если позволяет ситуация, выстраивайте для колег очередь из тасков с четким ранжированием по приоритетам.
▪️Внедрите простые и понятные регламенты: когда задачу брать в оборот, кому отдавать на ревью, когда ревью не нужно, как готовить задачу к тестированию и т.д. Не должно быть ситуации, когда разраб скажет вам: "Бро, я не знал, как дальше быть, поэтому ничего не делал".
▪️Обучите тех, кто нуждается, работе с PMS (Project Management System) и прочими инструментами, чтобы сделать процесс непрерывней и прозрачней: эстимейты на таски, трекинг времени, перевод задач в нужное время в нужные статусы etc.
▪️Не следите за каждым шагом каждого дева, невозможно писать код, когда у тебя над душой кто-то все время торчит, да еще и каверзные вопросы задает. При этом обозначьте границы допустимого. Например, не отвечать 2 часа в телегу - недопустимо. Полдня пытаться решить вопрос самому вместо того, чтобы обратиться к техлиду и моментально снять блокер - недопустимо. Молчать о том, что закончились таски - недопустимо. И т.д.
▪️Делайте время от времени синки 1 на 1 с каждым членом команды - это позволит держать руку на пульсе относительно настроения, собирать положительный и отрицательный фидбек касательно работы и всего на свете.
▪️Опирайтесь на базовые метрики производительности команды и отдельных разработчиков. Прежде всего:
🔹соблюдение дедлайнов,
🔹неравнодушие не только к своим таскам, но и к продукту в целом,
🔹качество работы (кол-во и кач-во ошибок по результатам тестирования),
🔹Velocity (в случае работы по Скраму) или, например, Throughput (если рулит Канбан).
▪️Будьте помощником, а не начальником. Ваша цель - не загонять кого-то под шконку, штрафовать, пугать, обкладывать санкциями (привет, Бидон) или увольнять, вы должны создавать комфортные условия для работы команды и непрерывно бустить проект. При этом, конечно, как указывалось выше, должны быть обозначены границы допустимого, введены простые и понятные регламенты и налажен контакт между любыми участниками команды, здесь часть вопросов помогают решить методологии, фреймворки и инструменты управления, не пренебрегайте ими.
Вы, находясь, скажем, в Москве, встаёте с кровати, идёте в душ, съедаете свой привычный омлет и садитесь за станок, в это время вашему техлиду Васе из Лиссабона всё ещё снятся розовые слоники и голубые зайчики, а тестер Петя из Новосиба оттарабанил уже практически половину рабочего дня. Что происходит? Ничего особенного: люди работают удалённо, да еще и разбросаны географически по всему миру - таковы современные реалии жизни многих айти-компаний. Как в подобной ситуации должна себя вести IT-команда в целом и менеджер в частности?
Удалёнка в IT - это всегда вызов для пиэма, который должен дирижировать распределенным оркестром в онлайне. Личные разговоры у кофе-машины ушли в прошлое, теперь всё в Джирах, Слаках и Гуглмитах. Не видя людей за рабочим столом, бывает сложно заметить, что кто-то закопался в задаче или просто теряет интерес ко всему происходящему. Сроки растягиваются, бюджет увеличивается, недопонимание между коллегами растет, следствием всего этого могут стать неудовлетворительные или даже плачевные результаты по проекту.
Пара слов о базовых аспектах, которые позволят избежать всего этого срама. К слову, большинство из них в той или иной степени актуальны и для офлайн-формата.
▪️Постарайтесь организовать работу т.о., чтобы бОльшая часть команды пересекалась по времени хотя бы на 2-4 часа в течение дня. На это время можно планировать совместные синки с целью обсуждения задач или проведения ритуалов.
▪️Никогда не оставляйте исполнителей без задач. Каждый должен знать, что пилить, даже если вас сию секунду нет рядом. Более того, каждый должен знать, что пилить в первую очередь, что во вторую, а что в третью. Если позволяет ситуация, выстраивайте для колег очередь из тасков с четким ранжированием по приоритетам.
▪️Внедрите простые и понятные регламенты: когда задачу брать в оборот, кому отдавать на ревью, когда ревью не нужно, как готовить задачу к тестированию и т.д. Не должно быть ситуации, когда разраб скажет вам: "Бро, я не знал, как дальше быть, поэтому ничего не делал".
▪️Обучите тех, кто нуждается, работе с PMS (Project Management System) и прочими инструментами, чтобы сделать процесс непрерывней и прозрачней: эстимейты на таски, трекинг времени, перевод задач в нужное время в нужные статусы etc.
▪️Не следите за каждым шагом каждого дева, невозможно писать код, когда у тебя над душой кто-то все время торчит, да еще и каверзные вопросы задает. При этом обозначьте границы допустимого. Например, не отвечать 2 часа в телегу - недопустимо. Полдня пытаться решить вопрос самому вместо того, чтобы обратиться к техлиду и моментально снять блокер - недопустимо. Молчать о том, что закончились таски - недопустимо. И т.д.
▪️Делайте время от времени синки 1 на 1 с каждым членом команды - это позволит держать руку на пульсе относительно настроения, собирать положительный и отрицательный фидбек касательно работы и всего на свете.
▪️Опирайтесь на базовые метрики производительности команды и отдельных разработчиков. Прежде всего:
🔹соблюдение дедлайнов,
🔹неравнодушие не только к своим таскам, но и к продукту в целом,
🔹качество работы (кол-во и кач-во ошибок по результатам тестирования),
🔹Velocity (в случае работы по Скраму) или, например, Throughput (если рулит Канбан).
▪️Будьте помощником, а не начальником. Ваша цель - не загонять кого-то под шконку, штрафовать, пугать, обкладывать санкциями (привет, Бидон) или увольнять, вы должны создавать комфортные условия для работы команды и непрерывно бустить проект. При этом, конечно, как указывалось выше, должны быть обозначены границы допустимого, введены простые и понятные регламенты и налажен контакт между любыми участниками команды, здесь часть вопросов помогают решить методологии, фреймворки и инструменты управления, не пренебрегайте ими.
👍5💯1
Из джунов в CTO, или эффект Даннинга-Крюгера
Комрады, пока вы, будучи профессионалами своего дела, рефлексируете на тему проделанной работы, вполне возможно, кто-то из ваших коллег, не имея семи пядей во лбу, но обладая харизмой 146-го уровня и подвешенным языком, стремительно карабкается по карьерной лестнице, не до конца понимая при этом, что творит. В IT это не то чтобы норма, но вполне себе регулярное явление.
Психологи Корнельского университета описали это явление в 1999 году и назвали его эффектом Даннинга-Крюгера.
Феномен объясняет, почему некомпетентные люди часто оказываются выше своих более квалифицированных коллег.
А суть феномена проста: недостаточно опытные люди зачастую склонны переоценивать свои знания и способности в силу этой самой своей неопытности. Такие персонажи часто принимают ошибочные решения, пускают под откос проекты, отталкивают коллег и клиентов, но, будучи некомпетентными, не видят ошибок и, как следствие, не проводят над ними работу и не совершенствуются.
А гуру, напротив, обладая большим опытом и высоким уровнем знаний, понимают (как тот самый Сократ), что не знают еще много чего, поэтому часто склонны недооценивать свои способности. Скромности им, как правило, не занимать.
А делать-то что с этими умниками? Суть проста: не надо, шоб подгорало, не рубите с плеча, не конфликтуйте, не увольняйте и не увольняйтесь, ведь это беда вашего коллеги, а не вина, дайте ему шанс. Старайтесь помочь и направить, определите метрики компетентности, время от времени доказывайте на практике, что коллега ошибается, давайте понять, что уверенность и мастерство - разные явления.
Комрады, пока вы, будучи профессионалами своего дела, рефлексируете на тему проделанной работы, вполне возможно, кто-то из ваших коллег, не имея семи пядей во лбу, но обладая харизмой 146-го уровня и подвешенным языком, стремительно карабкается по карьерной лестнице, не до конца понимая при этом, что творит. В IT это не то чтобы норма, но вполне себе регулярное явление.
Психологи Корнельского университета описали это явление в 1999 году и назвали его эффектом Даннинга-Крюгера.
Феномен объясняет, почему некомпетентные люди часто оказываются выше своих более квалифицированных коллег.
А суть феномена проста: недостаточно опытные люди зачастую склонны переоценивать свои знания и способности в силу этой самой своей неопытности. Такие персонажи часто принимают ошибочные решения, пускают под откос проекты, отталкивают коллег и клиентов, но, будучи некомпетентными, не видят ошибок и, как следствие, не проводят над ними работу и не совершенствуются.
А гуру, напротив, обладая большим опытом и высоким уровнем знаний, понимают (как тот самый Сократ), что не знают еще много чего, поэтому часто склонны недооценивать свои способности. Скромности им, как правило, не занимать.
А делать-то что с этими умниками? Суть проста: не надо, шоб подгорало, не рубите с плеча, не конфликтуйте, не увольняйте и не увольняйтесь, ведь это беда вашего коллеги, а не вина, дайте ему шанс. Старайтесь помочь и направить, определите метрики компетентности, время от времени доказывайте на практике, что коллега ошибается, давайте понять, что уверенность и мастерство - разные явления.
👍5💯1🎃1
IT-команда против HR: битва за компетентных сотрудников
Рекрутеры бывают разные: черные, белые, красные, но всем одинаково хочется на что-нибудь заморочиться. Некоторые, более современные и прогрессивные, заморачиваются на правильных вещах, но есть и другие, о них сегодня и пойдёт речь.
Поиск спеца продолжается непозволительно долго, на техническое интервью попадают "трепачи", а не таланты, пиэм с тимлидом нервничают, а зашивающиеся девы, давно ожидающие подмоги, матерятся, потому что им в помощь приводят рака, который на безрыбье рыба. Но тётя Клава из отдела кадров выполнила свою задачу, удовлетворена и ждет с нетерпением корпоратива. Проблема стара как мир.
Что здесь не так?
▪️Рекрутеры технически не подкованы ни на йоту. Что делать: даже на первое вью готовить ряд глубоких технических вопросов, выдавать их рекрутеру и просить чётко фиксировать ответы кандидата.
▪️Фильтрация кандидатов на старте не по тем критериям. Таланты пролетают мимо, например, потому что в резюме недостаточно ключевых слов или оно недостаточно заточено под позицию в принципе, или т-щи сами по себе недостаточно многословны. До технического интервью зачастую доходят гуттаперчевые болтуны. Что делать: опять же - задавать правильные технические вопросы уже на скрининге и чуть проще относиться к прочим критериям.
▪️Отсутствие уважения к кандидатам: игнор откликов, отсутствие фидбека после вью, поверхностные ответы на важные для соискателя вопросы и т.п. Что делать: просить рекрутера быть человечней или подыскать ему замену.
▪️Пытаются сэкономить бюджет компании в тех случаях, когда в этом нет никакой необходимости. В итоге сильный кандидат уходит к конкуренту, потому что там ему дали на 20 тыщ больше.
▪️Закостенелость: к примеру, обязательное требование к кандидату - резюме в ворде, именно в ворде, мать твою. Конечно, это крайний случай, но и такое случается. Что делать: вряд ли вы что-то сделаете, тут уже слишком поздно что-то делать. Но если этот рекрутер по каким-то причинам вам дорог, объясните ему, что портфель на Гитхабе может быть значительно ценней резюме в ворде.
P.S.: да, софт-скиллз, безусловно, тоже важны, но не для всех и не всегда, либо не в той степени.
Рекрутеры бывают разные: черные, белые, красные, но всем одинаково хочется на что-нибудь заморочиться. Некоторые, более современные и прогрессивные, заморачиваются на правильных вещах, но есть и другие, о них сегодня и пойдёт речь.
Поиск спеца продолжается непозволительно долго, на техническое интервью попадают "трепачи", а не таланты, пиэм с тимлидом нервничают, а зашивающиеся девы, давно ожидающие подмоги, матерятся, потому что им в помощь приводят рака, который на безрыбье рыба. Но тётя Клава из отдела кадров выполнила свою задачу, удовлетворена и ждет с нетерпением корпоратива. Проблема стара как мир.
Что здесь не так?
▪️Рекрутеры технически не подкованы ни на йоту. Что делать: даже на первое вью готовить ряд глубоких технических вопросов, выдавать их рекрутеру и просить чётко фиксировать ответы кандидата.
▪️Фильтрация кандидатов на старте не по тем критериям. Таланты пролетают мимо, например, потому что в резюме недостаточно ключевых слов или оно недостаточно заточено под позицию в принципе, или т-щи сами по себе недостаточно многословны. До технического интервью зачастую доходят гуттаперчевые болтуны. Что делать: опять же - задавать правильные технические вопросы уже на скрининге и чуть проще относиться к прочим критериям.
▪️Отсутствие уважения к кандидатам: игнор откликов, отсутствие фидбека после вью, поверхностные ответы на важные для соискателя вопросы и т.п. Что делать: просить рекрутера быть человечней или подыскать ему замену.
▪️Пытаются сэкономить бюджет компании в тех случаях, когда в этом нет никакой необходимости. В итоге сильный кандидат уходит к конкуренту, потому что там ему дали на 20 тыщ больше.
▪️Закостенелость: к примеру, обязательное требование к кандидату - резюме в ворде, именно в ворде, мать твою. Конечно, это крайний случай, но и такое случается. Что делать: вряд ли вы что-то сделаете, тут уже слишком поздно что-то делать. Но если этот рекрутер по каким-то причинам вам дорог, объясните ему, что портфель на Гитхабе может быть значительно ценней резюме в ворде.
P.S.: да, софт-скиллз, безусловно, тоже важны, но не для всех и не всегда, либо не в той степени.
👍5💯4❤2
Дейли-митинг: кто не успел - тот расскажет завтра
Друзья, если вы имеете прямое или косвенное отношение к айти, то не можете не знать о том, что такое дейлики и каково их предназначение. Но, держу пари, у многих из вас этот ритуал настолько адаптирован под существующие в вашей команде/проекте реалии, что вовсе дейликом и не является. Почему? Потому что у настоящего дейлика есть достаточно чёткий регламент, созданный для достижения строго определенных целей.
Но сначала немного истории
Сама идея коротких ежедневных планёрок для синхронизации команды родилась вовсе не в IT. Она была заимствована IT из производственной практики Бережливого производства (Lean), придуманной Toyota в бородатых 80-х. Частью фреймворка Scrum ритуал стал в начале 90-х, а в манифест Agile был включен только в 2001 году.
Цель синка предельно практична: избежать длительных и неэффективных совещаний, обеспечить быструю синхронизацию команды. Каждый должен понимать свои приоритеты и знать, чем занимается сосед. Каждый должен понимать, в каком направлении движется команда.
Формат:
▪️если офлайн, команда поднимает жопки с кресел и становится в круг (можно в овал, но ни в коем случае не в квадрат);
▪️если онлайн, то войти в конфу можно даже лёжа в кровати (не забудьте заклеить камеру изолентой от греха подальше).
Время:
15 минут на всю команду. Даже если в команде 30 человек, вы обязаны попытаться уложиться в 15 минут. Если команда небольшая, каждому участнику отводится не более 2-3 минут. Тчк.
О чём галдёж?
Каждый из участников синка (кроме тамады) отвечает на вопросы:
▪️Что он сделал вчера?
▪️Что он планирует сделать сегодня?
▪️С какими блокерами он столкнулся?
И ничего более! Никаких драм, лирики, демагогии и микроменеджмента!
Блокеры онли озвучиваются. Их детальное обсуждение происходит после стендапа с участием только заинтересованных лиц, 2-3 участника не должны тратить время всей команды!
Что по ролям?
ИТ-директор сказал, что у вас скрам, а Scrum-мастера не дал? Не беда. Команда может самоорганизоваться и провести митинг без участия тамады. В крайнем случае помогут PjM и/или Тимлид, хотя ведение ими митинга несколько противоречит духу Agile/Scrum.
Друзья, если вы имеете прямое или косвенное отношение к айти, то не можете не знать о том, что такое дейлики и каково их предназначение. Но, держу пари, у многих из вас этот ритуал настолько адаптирован под существующие в вашей команде/проекте реалии, что вовсе дейликом и не является. Почему? Потому что у настоящего дейлика есть достаточно чёткий регламент, созданный для достижения строго определенных целей.
Но сначала немного истории
Сама идея коротких ежедневных планёрок для синхронизации команды родилась вовсе не в IT. Она была заимствована IT из производственной практики Бережливого производства (Lean), придуманной Toyota в бородатых 80-х. Частью фреймворка Scrum ритуал стал в начале 90-х, а в манифест Agile был включен только в 2001 году.
Цель синка предельно практична: избежать длительных и неэффективных совещаний, обеспечить быструю синхронизацию команды. Каждый должен понимать свои приоритеты и знать, чем занимается сосед. Каждый должен понимать, в каком направлении движется команда.
Формат:
▪️если офлайн, команда поднимает жопки с кресел и становится в круг (можно в овал, но ни в коем случае не в квадрат);
▪️если онлайн, то войти в конфу можно даже лёжа в кровати (не забудьте заклеить камеру изолентой от греха подальше).
Время:
15 минут на всю команду. Даже если в команде 30 человек, вы обязаны попытаться уложиться в 15 минут. Если команда небольшая, каждому участнику отводится не более 2-3 минут. Тчк.
О чём галдёж?
Каждый из участников синка (кроме тамады) отвечает на вопросы:
▪️Что он сделал вчера?
▪️Что он планирует сделать сегодня?
▪️С какими блокерами он столкнулся?
И ничего более! Никаких драм, лирики, демагогии и микроменеджмента!
Блокеры онли озвучиваются. Их детальное обсуждение происходит после стендапа с участием только заинтересованных лиц, 2-3 участника не должны тратить время всей команды!
Что по ролям?
ИТ-директор сказал, что у вас скрам, а Scrum-мастера не дал? Не беда. Команда может самоорганизоваться и провести митинг без участия тамады. В крайнем случае помогут PjM и/или Тимлид, хотя ведение ими митинга несколько противоречит духу Agile/Scrum.
👍4✍3❤1
Закон Литтла и его применение в IT-менеджменте
Закон Литтла (Little's Law) - это фундаментальный закон в теории массового обслуживания и теории очередей. Закон был доказан и формализован американским профессором Джоном Литтлом в 1961 году, хотя интуитивно применялся задолго до этого.
В чем его суть: среднее число задач внутри системы равно произведению средней интенсивности входящего в систему потока этих задач на среднее время нахождения задачи в системе.
В чем его гениальность: он устанавливает простую, но мощную взаимосвязь между тремя ключевыми метриками любой системы, работающей с потоками.
В большей или меньшей степени закон применим вообще для любой сферы бизнеса/производства, где актуален поток задач/заявок, но нас традиционно интересует айтишечка. Если чуточку пораскинуть мозгами, придем к выводу, что три наиболее популярных канбановских метрики - WIP, Throughput, Cycle Time - ни что иное, как три параметра обозначенной выше формулы.
Что за метрики:
Итого, Закон Литтла в Канбане будет выглядеть так:
В чем польза применения Закона Литтла здесь:
▪️возможность манипулировать одними параметрами, изменяя другие;
▪️возможность прогнозировать сроки, бюджеты, ресурсы;
▪️возможность фокусироваться на потоке, а не на утилизации задач: вместо того чтобы заставлять всех быть фултайм занятыми (это неизбежно приведет к росту WIP и росту времени выполнения каждой задачи), закон учит ценить быстрый поток задач от начала до конца.
Примеры применения:
▪️если ограничить количество одновременно выполняемых задач (WIP), то при стабильной пропускной способности (Throughput) среднее время выполнения задачи (Cycle Time) автоматически уменьшится.
▪️зная свою текущую пропускную способность и количество задач в бэклоге, можно предсказать, когда будет допилен проект.
Это основы Канбана.
А теперь пара слов о подводных камнях:
▪️Закон Литтла идеален для ситуаций, когда все задачи, проходящие через систему, имеют приблизительно одинаковый объем и сложность, однако это не про айти. В нашем с вами случае, т-щи, следует использовать, как вы уже догадались, Story Points или человеко-часы.
Оперируя, например, часами, получим:
WIP - это не "штуки", а сумма эстимейтов (в часах), находящихся в работе.
Throughput измеряется в человеко-часах, реализуемых за единицу времени (например, за неделю).
Cycle Time - время выполнения задачи в часах.
Скорректированная т.о. формула будет работать идеально в том случае, если ваши оценки достаточно точны, а производительность команды относительно стабильна. На практике так бывает нечасто, поэтому держим в уме возможность использования Story Points для оценки задач (если, конечно, заказчик не против такой затеи). Да, Story Points - это по ряду причин чаще скрамовская история, чем канбановская, но где наша не пропадала? Стабилизируйте команду и переходите обратно на часы.
▪️Надо помнить, что 9 женщин не способны родить ребенка за 1 месяц. Сам по себе Закон Литтла не учитывает этот аспект, но помогает его обнаружить. Он утверждает, что если ваша система устойчива и способна обрабатывать поступающую нагрузку, обозначенные три параметра будут связаны описанной формулой. При этом он не гарантирует, что вы можете бесконечно уменьшать Cycle Time, уменьшая WIP.
Закон Литтла (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.
👍14🙏3✍1❤1🗿1
Проект не "на авось". Правила работы с рисками в IT
Наверное, у каждого был/есть приятель со слегка присвистывающей флягой, который любил бросать монетку на распутье, полагаясь на волю судьбы во всякой ситуации. Так себе история. Мы с вами не такие, коллеги (да ведь?)! Нам нужна аналитика, нам нужны обоснования, мы четко понимаем, что воля судьбы - это недостаточно надежный инструмент управления проектами.
Сегодня немношк пробежимся по школьной программе, вспомним о том, что в любом проекте, как и в жизни, нас окружают определенные риски - большие и маленькие, хорошие и плохие. Некоторые умные книжки (в т.ч., кстати, PMBOK) говорят нам, что в айтишечке существует восемь стратегий управления рисками - 4 из них относятся к позитивным рискам и 4 - к негативным.
Стратегии для работы с негативными рисками (когда всё идёт, как обычно)
1. Избегание
Пример: подумали и решили не внедрять свежую библиотеку, потому что выяснили, что ее автору 16 лет и он год не заходил на Гитхаб, выбрали более надежное решение. Риск устранён, избежали.
2. Смягчение
Пример: пообщались с заказчиком и взяли неделю запаса под тесты, потому что разработчик Кирилл последний месяц не спал и много пил. Не были уверены - подстелили соломку.
3. Делегирование
Пример: смекнули, что по времени не укладываемся до следующего вторника, а по бюджету запас имеется - передали разработку одного из модулей знакомому подрядчику, чтобы запараллелить процессы.
4. Принятие
Пример: прикинули, что риск того, что разработчик не успеет к дедлайну, меньше, чем риск того, что подрядчик не успеет к дедлайну, поскольку подрядчика предстояло еще погрузить в проект. Решили не делегировать работу подрядчику, приняли риск, связанный с действующим разработчиком.
Стратегии для работы с позитивными рисками (когда вдруг повезло)
1. Использование
Пример: приметили халявный опенсорс-API, сразу прикрутили - клиент в восторге, работает, да еще и шагаем с опережением графика. Использовали появившуюся возможность.
2. Усиление
Пример: параллельно с реализацией проекта проапгрейдили мониторинг и аналитику, теперь быстрее будем находить баги и определять новые возможности для развития. Планово усилили позитивный риск.
3. Разделение
Пример: запартнёрились с другим стартапом: если проканает - вместе в Forbes (если нет - вместе на hh.ru).
4. Принятие
Пример: если тестовая реклама даст хороший CTR - масштабируем кампанию. Возможность фиксируется, но никаких вложений до подтверждения успеха не делается.
Да, бывает ещё Эскалация - это когда риск настолько крупный, что ты делаешь вид, будто это не твоя зона ответственности, и пушишь его "вверх". Классическая управленческая дзен-практика.
Работайте с рисками, товарищи
Наверное, у каждого был/есть приятель со слегка присвистывающей флягой, который любил бросать монетку на распутье, полагаясь на волю судьбы во всякой ситуации. Так себе история. Мы с вами не такие, коллеги (да ведь?)! Нам нужна аналитика, нам нужны обоснования, мы четко понимаем, что воля судьбы - это недостаточно надежный инструмент управления проектами.
Сегодня немношк пробежимся по школьной программе, вспомним о том, что в любом проекте, как и в жизни, нас окружают определенные риски - большие и маленькие, хорошие и плохие. Некоторые умные книжки (в т.ч., кстати, PMBOK) говорят нам, что в айтишечке существует восемь стратегий управления рисками - 4 из них относятся к позитивным рискам и 4 - к негативным.
Стратегии для работы с негативными рисками (когда всё идёт, как обычно)
1. Избегание
Пример: подумали и решили не внедрять свежую библиотеку, потому что выяснили, что ее автору 16 лет и он год не заходил на Гитхаб, выбрали более надежное решение. Риск устранён, избежали.
2. Смягчение
Пример: пообщались с заказчиком и взяли неделю запаса под тесты, потому что разработчик Кирилл последний месяц не спал и много пил. Не были уверены - подстелили соломку.
3. Делегирование
Пример: смекнули, что по времени не укладываемся до следующего вторника, а по бюджету запас имеется - передали разработку одного из модулей знакомому подрядчику, чтобы запараллелить процессы.
4. Принятие
Пример: прикинули, что риск того, что разработчик не успеет к дедлайну, меньше, чем риск того, что подрядчик не успеет к дедлайну, поскольку подрядчика предстояло еще погрузить в проект. Решили не делегировать работу подрядчику, приняли риск, связанный с действующим разработчиком.
Стратегии для работы с позитивными рисками (когда вдруг повезло)
1. Использование
Пример: приметили халявный опенсорс-API, сразу прикрутили - клиент в восторге, работает, да еще и шагаем с опережением графика. Использовали появившуюся возможность.
2. Усиление
Пример: параллельно с реализацией проекта проапгрейдили мониторинг и аналитику, теперь быстрее будем находить баги и определять новые возможности для развития. Планово усилили позитивный риск.
3. Разделение
Пример: запартнёрились с другим стартапом: если проканает - вместе в Forbes (если нет - вместе на hh.ru).
4. Принятие
Пример: если тестовая реклама даст хороший CTR - масштабируем кампанию. Возможность фиксируется, но никаких вложений до подтверждения успеха не делается.
Да, бывает ещё Эскалация - это когда риск настолько крупный, что ты делаешь вид, будто это не твоя зона ответственности, и пушишь его "вверх". Классическая управленческая дзен-практика.
Работайте с рисками, товарищи
👍6❤3✍1
PjMs в IT. Какие бывают архетипы?
Пиэм пиэму - рознь. Функционал пиэма могут определять особенности проекта, желания или прихоти заказчика, качества и количество присутствующих/отсутствующих в команде ролей, а также опыт, таланты и мотивация самого пиэма. В результате человека кренит в той или иной степени в ту или иную сторону - он получает определенный, достаточно конкретный для его ситуации набор обязанностей, который только отчасти бьется с классическим представлением того, чем должен заниматься пиэм.
Итак, коротенько о том, какие бывают крены:
PjM-аналитик
Такие товарищи ковыряются с проектными метриками (velocity, burndown), анализируют риски (SWOT, Monte Carlo), строят даши в Джире, прогнозируют bottlenecks, опираясь на историю и т.д. В результате заказчик получает минимум сюрпризов в вопросах планирования бюджетов и времени, но имеет риски просадок по другим направлениям, например, вполне может получить ушатанную и демотивированную после сдачи проекта команду.
PjM-практик
Опирается на свой опыт, адаптирует методологии и фреймворки управления под реальность, корректирует план на лету по фидбеку с ретро. Такие кадры обычно быстро и эффективно решают нестандартные вопросы в хаосе стартапа, однако их решения зачастую субъективны, "я так делал в прошлом проекте" - и не канает.
PjM-мотиватор
Организует мотивационные стендапы, проводит тимбилдинги, разрешает конфликты. Следит за состоянием команды через анонимные опросы, определяет вовлеченность команды в проект, страхует от выгораний. Такие кадры могут принести наибольшую пользу в геймдеве или дизайнерских тимах, где требуется максимально деликатный подход в силу тонкости душевных конструкций исполнителей. Это не всегда про дисциплину и строгое соблюдение дедлайнов.
PjM-делегатор
Раскидывает задачи по исполнителям оптимальным образом, ставит дедлайны, но даёт разрабам автономию по чекпоинтам, работает на уровне эпиков, имеет стратегический взгляд на происходящее. Этот подход требует наличия в команде качественных кадров (казалось бы: качественные кадры должны быть по умолчанию), иначе будет бардак.
PjM-фоллоу-аппер
Ежедневно пингует в Слаке по статусу задач, трекает прогресс на дейликах, эскалирует задержки стейкхолдерам, генерит daily-reports, обновляет борд в Джире. При нем проекты наверняка не потонут, однако команда чувствует себя под микроскопом. Подход дает буст в сложных условиях типа, например: распределенная команда + финтех + жесткие дедлайны.
PjM-аудитор
Проводит, как ни странно, аудиты процессов: чекает исполнение методологий, анализирует сбои и инциденты на проектах, выявляет места просадок, предлагает фикс-чеклисты и улучшения процессов. Фокус - на уроках из фейлов. Этот товарищ обычно страхует от повторяющихся ошибок, но часто замедляет темп проектов. Часто встречается в enterprise.
PjM-педант
Обеспечивает тотальный контроль и ведение проектных доков/отчетности, мониторит соблюдение методологических ритуалов, следит за бюджетом и даже напоминает разрабам о необходимости код-ревью. Надежно, но всегда попахивает бюрократией, которая непременно душит креатив. Подходит для масштабных проектов с кучей стейкхолдеров.
PjM-помогатор
Помогает с операционкой: ведет задачи в Джире, готовит доки на подписание, фильтрует фид от клиента, ускоряет онборд новичков, разрешает лайт-задачки, чтобы не отрывать девов от сложных. Обычно обеспечивает комфортную работу всей команде, но часто пасует перед сложностями или новыми вызовами, потому что джун.
PjM-Мама-утка
Защищает команду от внешнего прессинга (клиент орёт - крики слышит только пиэм) - спасает от токсичных и слишком требовательных заказчиков, фасилитирует внутрикомандные синки, создает непринужденную атмосферу. В результате получает лояльность со стороны команды, но из-за излишней опеки может страдать инициатива.
Пиэм пиэму - рознь. Функционал пиэма могут определять особенности проекта, желания или прихоти заказчика, качества и количество присутствующих/отсутствующих в команде ролей, а также опыт, таланты и мотивация самого пиэма. В результате человека кренит в той или иной степени в ту или иную сторону - он получает определенный, достаточно конкретный для его ситуации набор обязанностей, который только отчасти бьется с классическим представлением того, чем должен заниматься пиэм.
Итак, коротенько о том, какие бывают крены:
PjM-аналитик
Такие товарищи ковыряются с проектными метриками (velocity, burndown), анализируют риски (SWOT, Monte Carlo), строят даши в Джире, прогнозируют bottlenecks, опираясь на историю и т.д. В результате заказчик получает минимум сюрпризов в вопросах планирования бюджетов и времени, но имеет риски просадок по другим направлениям, например, вполне может получить ушатанную и демотивированную после сдачи проекта команду.
PjM-практик
Опирается на свой опыт, адаптирует методологии и фреймворки управления под реальность, корректирует план на лету по фидбеку с ретро. Такие кадры обычно быстро и эффективно решают нестандартные вопросы в хаосе стартапа, однако их решения зачастую субъективны, "я так делал в прошлом проекте" - и не канает.
PjM-мотиватор
Организует мотивационные стендапы, проводит тимбилдинги, разрешает конфликты. Следит за состоянием команды через анонимные опросы, определяет вовлеченность команды в проект, страхует от выгораний. Такие кадры могут принести наибольшую пользу в геймдеве или дизайнерских тимах, где требуется максимально деликатный подход в силу тонкости душевных конструкций исполнителей. Это не всегда про дисциплину и строгое соблюдение дедлайнов.
PjM-делегатор
Раскидывает задачи по исполнителям оптимальным образом, ставит дедлайны, но даёт разрабам автономию по чекпоинтам, работает на уровне эпиков, имеет стратегический взгляд на происходящее. Этот подход требует наличия в команде качественных кадров (казалось бы: качественные кадры должны быть по умолчанию), иначе будет бардак.
PjM-фоллоу-аппер
Ежедневно пингует в Слаке по статусу задач, трекает прогресс на дейликах, эскалирует задержки стейкхолдерам, генерит daily-reports, обновляет борд в Джире. При нем проекты наверняка не потонут, однако команда чувствует себя под микроскопом. Подход дает буст в сложных условиях типа, например: распределенная команда + финтех + жесткие дедлайны.
PjM-аудитор
Проводит, как ни странно, аудиты процессов: чекает исполнение методологий, анализирует сбои и инциденты на проектах, выявляет места просадок, предлагает фикс-чеклисты и улучшения процессов. Фокус - на уроках из фейлов. Этот товарищ обычно страхует от повторяющихся ошибок, но часто замедляет темп проектов. Часто встречается в enterprise.
PjM-педант
Обеспечивает тотальный контроль и ведение проектных доков/отчетности, мониторит соблюдение методологических ритуалов, следит за бюджетом и даже напоминает разрабам о необходимости код-ревью. Надежно, но всегда попахивает бюрократией, которая непременно душит креатив. Подходит для масштабных проектов с кучей стейкхолдеров.
PjM-помогатор
Помогает с операционкой: ведет задачи в Джире, готовит доки на подписание, фильтрует фид от клиента, ускоряет онборд новичков, разрешает лайт-задачки, чтобы не отрывать девов от сложных. Обычно обеспечивает комфортную работу всей команде, но часто пасует перед сложностями или новыми вызовами, потому что джун.
PjM-Мама-утка
Защищает команду от внешнего прессинга (клиент орёт - крики слышит только пиэм) - спасает от токсичных и слишком требовательных заказчиков, фасилитирует внутрикомандные синки, создает непринужденную атмосферу. В результате получает лояльность со стороны команды, но из-за излишней опеки может страдать инициатива.
👍8❤1🤨1
Масштабироваться, а не героически выгорать
Салют! Это пост про делегирование. Если вы так или иначе связаны с менеджментом, а количество работы, относящейся к вашей зоне ответственности, неуклонно растёт, вам придётся учиться делегировать задачи своим коллегам.
Делегирование - это не "скинул таску и пошёл в смузи пузыри пускать". Это управляемый риск. Вроде деплоя в прод в пятницу: можно, но потом не нойте, есличо.
Итак, когда стоит делегировать
▪️Когда задача не требует лично вашей экспертизы уровня "бог".
▪️Когда вы - узкое горлышко (гг, т.е. почти всегда).
▪️Когда велик шанс, что другой сделает достаточно хорошо (смиритесь, шо не так идеально, как вы).
К слову, привет из PMBOK и классики менеджмента: манагер отвечает за результат, но не обязан делать всё своими руками.
Отсюда проистекают и обратные правила - когда делегировать НЕ стоит
▪️Когда задача критична, а у команды нет нужной компетенции (потенциальный риск явно превосходит выгоду).
▪️Когда вы сами ещё не до конца поняли, что нужно получить на выходе (делегировать абстракцию - получить хаотичную ебалду по итогу).
▪️Когда дешевле и быстрее сделать своими руками, чем объяснять.
На кого делегировать
▪️На того, у кого есть минимально достаточная компетенция + потенциал роста.
▪️Не всегда на самого скиллового, иначе он станет кладбищем всех задач.
▪️На того, кто перманентно не перегружен своими дефолтными задачами.
Опасности делегирования
▪️"Я же сказал сделать нормально" - нет, вы не сказали, вы подумали. Формулируйте задачу правильно.
▪️Микроменеджмент: делегировали - и погнали стоять над душой, в таком делегировании нет никакого смысла.
▪️Потеря контроля: не настроили чекпоинты - получили нежданчик к дедлайну.
Опасности НЕ делегировать
▪️Риск стать бутылочным горлышком всей команды/компании, как уже было сказано выше.
▪️Люди вокруг вас не растут (а потом вы жалуетесь, шо "нихто не тянет").
▪️Вы выгораете, биз тормозит: глупо и недолго.
Ну и какие правила выводим отсюда, т-щи
▪️Чётко формулируйте, что и как должно быть на выходе + как поймёте, что это именно то, что надо (SMART в помощь, к примеру).
▪️Давайте хотя бы кратко контекст, зачем это вообще нужно, иначе можете получить формально правильный результат, а по сути - хрень.
▪️Определите границы: где человек принимает решения сам, а где эскалирует (RACI в помощь).
▪️Зафиксируйте чекпойнты, не влезайте каждые 5 минут со своими ЦУ.
▪️Не забывайте про обратную связь после выполнения: в противном случае коллеги не научатся.
▪️Ответственность остаётся у вас. Всегда. Не нравится - не нужно менеджерить.
И главное: делегирование - это не про разгрузить себя, это про выстраивание системы, где не всё держится на ваших героических плечах. Герои, как известно, долго не живут, в т.ч. в айтишечке.
Салют! Это пост про делегирование. Если вы так или иначе связаны с менеджментом, а количество работы, относящейся к вашей зоне ответственности, неуклонно растёт, вам придётся учиться делегировать задачи своим коллегам.
Делегирование - это не "скинул таску и пошёл в смузи пузыри пускать". Это управляемый риск. Вроде деплоя в прод в пятницу: можно, но потом не нойте, есличо.
Итак, когда стоит делегировать
▪️Когда задача не требует лично вашей экспертизы уровня "бог".
▪️Когда вы - узкое горлышко (гг, т.е. почти всегда).
▪️Когда велик шанс, что другой сделает достаточно хорошо (смиритесь, шо не так идеально, как вы).
К слову, привет из PMBOK и классики менеджмента: манагер отвечает за результат, но не обязан делать всё своими руками.
Отсюда проистекают и обратные правила - когда делегировать НЕ стоит
▪️Когда задача критична, а у команды нет нужной компетенции (потенциальный риск явно превосходит выгоду).
▪️Когда вы сами ещё не до конца поняли, что нужно получить на выходе (делегировать абстракцию - получить хаотичную ебалду по итогу).
▪️Когда дешевле и быстрее сделать своими руками, чем объяснять.
На кого делегировать
▪️На того, у кого есть минимально достаточная компетенция + потенциал роста.
▪️Не всегда на самого скиллового, иначе он станет кладбищем всех задач.
▪️На того, кто перманентно не перегружен своими дефолтными задачами.
Опасности делегирования
▪️"Я же сказал сделать нормально" - нет, вы не сказали, вы подумали. Формулируйте задачу правильно.
▪️Микроменеджмент: делегировали - и погнали стоять над душой, в таком делегировании нет никакого смысла.
▪️Потеря контроля: не настроили чекпоинты - получили нежданчик к дедлайну.
Опасности НЕ делегировать
▪️Риск стать бутылочным горлышком всей команды/компании, как уже было сказано выше.
▪️Люди вокруг вас не растут (а потом вы жалуетесь, шо "нихто не тянет").
▪️Вы выгораете, биз тормозит: глупо и недолго.
Ну и какие правила выводим отсюда, т-щи
▪️Чётко формулируйте, что и как должно быть на выходе + как поймёте, что это именно то, что надо (SMART в помощь, к примеру).
▪️Давайте хотя бы кратко контекст, зачем это вообще нужно, иначе можете получить формально правильный результат, а по сути - хрень.
▪️Определите границы: где человек принимает решения сам, а где эскалирует (RACI в помощь).
▪️Зафиксируйте чекпойнты, не влезайте каждые 5 минут со своими ЦУ.
▪️Не забывайте про обратную связь после выполнения: в противном случае коллеги не научатся.
▪️Ответственность остаётся у вас. Всегда. Не нравится - не нужно менеджерить.
И главное: делегирование - это не про разгрузить себя, это про выстраивание системы, где не всё держится на ваших героических плечах. Герои, как известно, долго не живут, в т.ч. в айтишечке.
👍7✍2❤1