#полезности
Канал вместо избранного

Дорогой читатель, я завел канал https://t.me/pm_know_wh , чтобы складировать там все, что не успеваю читать. Почему именно для тебя? Возможно я никогда не прочту эти материалы и они просто останутся лежать до следующей очистки избранного, но тебе они могут быть полезны.

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

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

Есть 3 секретных шаблона:

Шаблон 1: управленческий поединок
Моя роль
На какой должности/роли ты работаешь?
Какие у тебя обязанности и полномочия?

Контекст
Какое направление у компании (FMCG, R&D ML или...)?
Кто вас окружает (какая корпоративная структура/иерархия)?

Проблема
В чем заключается текущая ситуация?
Кого она затрагивает?

Моя цель
Я хочу добиться X, потому что Y

Другие действующие лица
Каковы их роли?
Какие у них интересы/мотивы?

Шаблон 2: методика «ситуации-проблема-решение»
Ситуация
Что случилось, фактология, контекст

Проблема
К чему это привело, почему это проблема

Решение
Предложи какой-нибудь вариант решения, который, по твоему, поможет закрыть проблему (это пункт тоже желателен, потому что тут ты дашь ещё больше контекста + подумаешь «об чат»)

Шаблон 3: взгляд со стороны
Наблюдение
Я заметил что X, перечисление фактов

Ситуация
Это происходит в X, описание контекста ситуации и окружения

Следствие
'Из-за этого' + @наблюдение'+ 'произошло в' + @ситуации + 'и привело к' + @последствию/влиянию.

Главный вопрос
Открытый вопрос, который раскрывает чего вы хотите достичь в этом случае и почему.

P.S. Ни в коем случае не используй эти шаблоны, если не хочешь чтобы окружающие вас поняли и не завяливали множеством уточняющих вопросов. Доказано, что такие шаблоны сокращают время обсуждения в разы и делают его более продуктивными, не важно это обсуждение с руководителем, коллегой или в чатике телеграм. А это совершенно не то, чего ты хочешь, верно?)
2 шаблон от @@revealed_dave

#мнение
Как понять что человек руководитель

Нужно задать ему 2 вопроса:
1) Почему ты хочешь быть/оставаться руководителем?
2) За что ты получаешь/хочешь получать свою зарплату?

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

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

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

#иное
Бары и менеджеры
Тест гипотезы о потребности в сообществе исключительно для встреч менеджеров в барах.

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

#спонтанный_междусобойчик
Настроение на кутеж
Открытие канала надо отметить, поэтому собираемся @artemletya (Айти ПМ) и @Slava_na_velosipede (Стройка ПМ) в баре. Будем пить, есть и разговаривать о всяком менеджерском.

Место: г. Санкт-Петербург, Социалистическая, 21 "Рыжий рорри"
Время: в 20.45.

Обсуждение здесь

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

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

P.S. Управляю этим как проектом, есть даже устав и Ганта с бюджетом. Из интересного в целях масштабирование на другие города, использование ботов для анонсов и самоорганизации и договоренности с барами. Естественно совершенно неформально.

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

Тебе понравится встреча, если:
1) Ты работаешь управленцем или имеешь такой опыт;
2) Любишь общаться с коллегами;
3) Интересно узнать какую шутку можно повторить более 3000 раз.

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

Место: г. Санкт-Петербург, Чкаловский проспект, 50 "Арден"
Время: в 19.00 20 октября (среда)

Обсуждение здесь

#рецепт
Что делать если хочется что-то поменять?
Приветствую тебя, дорогой читатель!

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

Во-первых: полномочия на изменения есть далеко не всегда. Не каждый РП имеет полномочия на управление командой;

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

1) Выявить процесс.

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

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

2) Понять потребности.

Буквально. Нужно узнать кого затрагивает процесс из пункта 1 и кто на него может влиять (стейкхолдеров в общем). Вот у них узнаем а каковы их потребности в случае процесса 1. Должно получиться что-то вроде ("Васе нужна оценка задач для личного комфорта, чтобы была определенность");

3) Подтвердить проблему.

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

Если в результате информации из пункта 2 и общения окажется что проблема не подтвердилась, то не отчаивайся! У тебя всегда есть инструменты cause-effect диаграмма, FMEA анализ, casual-loop диаграмма, канбан-доска и т.д. За счет этого ты вполне можешь подтвердить что проблема есть и показать это окружающим.

Если же ни общение, ни анализ процесса тебе не помогли, что ж. Залезай на бронивичок и косплей Ленина с "доколе!".

Главное завалидировать с с участниками процесса — есть ли проблема и видят ли они через новое представление.

4) Получить добро на решение проблемы.

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

5) Применить менеджерские инструменты

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

​#рецепт
Продолжение поста про изменение процессов
6) Готовьтесь огрести

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

Люди могут:

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

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

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

P.S. Многое что есть группах людей (особенно в энтерпрайз компаниях) происходит вопреки, казалось бы, здравому смыслу. Все потому что есть люди и с ними сложно. Главная сила менеджера состоит в умении превращать оковы из людей в возможности
P.P.S. Часть 6 не моя, она от @pimenas Леши Пименова

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

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

Как только ты перестанешь путать это, можно топать в более тонкие материи вроде Fill Rate, Capacity/Velocity, Lead time, Time to Market, Tact time, Service Level (без A и E) и прочее прочее.

#полезности
Словарь джуна
Коллеги создали табличку с мудреными словами. Авось кому будет полезно.

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

https://docs.google.com/spreadsheets/d/1X1uYlGl9KA5GayIoYOwVKB-1XoBFkA97FqWXSkw73n8/edit?usp=sharing

P.S. Не мое, Автор @egormaryushko

#рецепт
Как включаться в работу на новом месте
Здравствуй, дорогой читатель. Этот пост будет слегка сумбурным и не подкрепленным какими-то прочитанными ресурсами или словами экспертов. Просто мое мнение в чистом виде. И что самое неприятное, так это то что это мнение основано на том, чего я не делал сразу или делал скверно.

Я хочу поговорить о следующем: ты прошел собес, оформился, начался твой первый день и поехал онбординг (если он есть, ха). Речь пойдет не об онбординге для менеджеров как таковом, где разъясняется как все устроено с маленькой буквы. А именно о "КАК все устроено".

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

Я пришел к следующему рецепту из 5 шагов:

1. Дневник людей;
2. Сделать работу каждого руками;
3. Дневник изменений;
4. Личный проект по онбордингу;
5. Регламенты работы менеджера.

Давай подробно разберем каждый из них.

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

- Настроение и поведение;
- Интересы и вещи которые раздражают;
- Привычки;
- Сильные стороны (это самое сложное).

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

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

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

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

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

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

Такие причинно-следственные связи нужны чтобы можно было видеть картину целиком. Ну и это открывает путь к ТОС, системного мышлению, cause&effect и т.п

#рецепт
Как включаться в работу на новом месте. Часть 2
Личный проект по онбордингу
Классический проект. С треугольником, только вместо бюджета 1 ресурс - ты сам.
Обязательные артефакты:
1. Устав. Бизнес-кейс, цели, критерии достижения целей, детерминирующие риски, допущения, поставки, ограничения. Такой устав кстати выступает хорошим "контрактом" на испытательный срок, так как описывает что нужно сделать чтобы его пройти с отличием;
2. Матрица требований. Описание того, что конкретно нужно сделать за испытательный срок или онбординг;
3. Реестр рисков. Что может помешать пройти всему как по маслу? Очень даже может быть злющий тимлид, который попросит на выход если ты ему не понравишься и откажется сотрудничать;
4. Матрица коммуникаций. В каждой компании есть набор встреч, созвонов и тд. Знать как они проходят и когда очень важно;
5. Календарный план. Нужно спланировать свое время, чтобы успеть все сделать и не перегрузится.

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

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

От таких заметок есть и еще несколько польз.:

1. Всегда можно подсмотреть как делается что-то;
2. Если нужно уйти в отпуск/заболеть, то так проще передавать дела.

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

P.S.S Нет пункта "сходить в бар с коллегами", потому что это маст-хев и по умолчанию.

#мнение
Story Points. Изобретение дьявола. Часть 1
Привет, искушенный читатель! Если ты вращаешься вокруг проектного управления и Agile, то наверняка слышал о таком понятии как сторипойнты. Для краткости их буду указывать по тексту как СП.

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

Миф 1. СП это из Scrum
СП придумал Рон Джеффрис году эдак в 2001 (точных дат нет), затем их популяризировал Майкл Кон в своей книге Agile: оценка и планирование проектов.

Что забавно, изначально в 1 версии гайда (в 2010 году) предполагалось планирование в идеальных человеко-днях.

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

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

Сами по себе СП не являются относительными изначально.

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

Казалось бы в чем разница между усилиями и трудозатратами?

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

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

Миф 4. Можно переводить СП в часы
Очень известный миф, каждый второй ПМ и СМ путаются так делать. Тут есть 3 момента, которые этому помешают:

- Логический. Если сторипойнты оценки усилий команды для реализации определенного скоупа, то часы это рабочее время, которая затратит команда на реализацию скоупа. Почему-то строится такое выражение: усилия == рабочее время команды;
- Математический. Есть два различных показателя. Мы не знаем есть ли между ними связь (например, линейная корреляция), поэтому переводить показатели из одного базиса в другой каким-то выдуманным коэффицентом бессмысленно. Даже если связь есть, то нужно найти формулу перевода, а она может не выражаться алгоритмически, просто нет аппроксимирующей кривой или что еще забавнее временные ряды этих показателей могут не сходиться;
- Смысловой. Был оценен хвост кота, насколько он пушистый и крепкий. А теперь давайте по хвосту найдем сколько еды ест в неделю такой кот. Перевод теплое в мягкое.

Если все таки очень хочется конвертировать. Выбери примерно 100 задач с оценкой в СП, посчитай сколько на каждую задачу ушло времени (не оцени, а именно посчитай, cycle time от старта работы и до конца). Затем посчитай линейный коэффициент Пирсона между оценкой и временем. Если он больше 0.5, построй кривую по оценке и попробуйте ее аппроксимировать другой кривой по методу наименьших квадратов. Это самый простой способ "в лоб".

Что забавно, изначально СП предполагались как идеальные дни, которые конвертировались в обычные умножение на коэффиент нагрузки, равный примерно 3

#мнение
Story Points. Изобретение дьявола. Часть 2
Миф 5. Емкость команды в СП выражает ее эффективность и можно по ней сравнивать команды
Каждая команда уникальна и имеет свой набор навыков. У каждой команды свой контекст и своя производственная среда. И дело не в том что они по разному оценивают, а в том что они просто работают по разному. Даже если стандартизировать их способ мышления при оценке и способ выполнения работы, то ничего не получится. СП применяют для нематериального производство, которое происходит в разумах людей. И как в поговорке "к сожалению к рукам сотрудника прилагается и остальной человек".

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

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

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

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

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

Миф 7. При декомпозиции задачи также декомпозируется ее оценка в СП
Вывод проистекает из мифа 5 и мифа 3. У каждой подзадачи будет свой набор рисков и своя сложность. Складывая 1 и 2 яблока ты получишь просто 3 яблока, а не одно большое.

Ну и плюс немного дополнительных умозаключений:

1. Нарезать истории на подзадачи никому кроме команды и не надо. Они сами себе её нарежут так, как им удобно. Декомпозиция нужна именно для увеличения знаний о задаче и удобства работы с ней. Не для оценки;
2. Оценивать подзадачи тоже не надо, никому не интересно, сколько будет делаться конкретная подзадача, всем интересен конечный результат - готовая задача.

Миф 8. СП можно складывать
Можно конечно попробовать складывать, но тут опять вылезает миф 3. Не складывается просто сложность и неопределенность.

Также можно посмотреть математически. Является ли базис СП линейным и обладает ли он свойством аддитивности? Можно ли сложить задачу в 3 СП и 2 СП? Полагаю в твоем случае тоже нет)

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

Миф 9. СП лучше часов. Штуки задач лучше СП. NoEstimates!!!
СП необходимы для оценки усилий и дальнейшего выбора в контейнер времени наиболее важных задач (часто такой контейнер называют спринтом).

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

А штуки нужны для управления потоком и нагрузки на команду. WIP limit, inflow и вот это все.

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

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

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

#мнение
Story Points. Изобретение дьявола. Часть 3
Также с точки зрения математики расчет среднего значения по несколькими спринтам есть довольно странное упражнение, которое называют велосити. По распределению скорее всего среднее находится левее медианы, так как подвержено выбросам. То есть вероятность велосити это даже меньше чем "50/50, или сделаем или нет".

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

​#perl
Я нашел почему ежедневно хочется рыдать на работе

#полезности
Как не прибивай гвоздями объем работ, обязательно что-нибудь поползет

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

📊 Как управлять IT-проектом: сроки, бюджет и скоуп (и чек-лист для проджекта!)

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

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

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

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

Статью написали вместе с Полиной Скалуновой, marketing project manager в Skyeng. Также вы найдете комментарии двух экспертов:

Елена Горопека, бизнес-аналитик и продакт-менеджер, поделилась советами по управлению скоупом.

Артем Летюшев, менеджер-аналитик Юмани, рассказал о способах управления сроками проекта.

#useful | @skillsetter x @harapeka x @junior_pm

#полезности
Спринты есть, у нас скрам!
Дорогой читатель, я восхитился этой статьей, оцени её и ты. Она о том как использовать модный фреймворк без самого фреймворка.

https://vladimirmerkushev.medium.com/scream-guide-%D0%BA%D0%B0%D0%BA-%D0%B1%D1%8B%D1%82%D1%8C-agile-%D0%B8-%D0%BD%D0%B5-%D0%BC%D0%B5%D0%BD%D1%8F%D1%82%D1%8C%D1%81%D1%8F-3ad19ce4ad1c

#полезности
Проект по скрам? Hold on my beer
Тоже замечательная статья про то как правильно использовать скрам и не париться.

https://antonshell.me/post/drunk-scrum