#рецепт
Получаем сроки без насилия
Ранее уже приводил один интересный прием, для получения вилки сроков, а дальше для уточнения.
Этот прием, можно применять и к задачам и к проектам.
Суть его заключается в порождении сфокусированного мышления.
Нужно задать вопрос: "Успеем ли сделать [проект/фичу/задачу] к [такому-то] сроку?"
Получаем ответ: "Да/Нет"
В случае ответа "Нет", уточняем другой срок, или уменьшаем скоуп, и снова задаем вопрос.
В отличие от вопроса "Когда сделаем", описанный выше прием позволяет отвечающему привести свои предположения к простому ответу.
Это не значит, что вы получив ответ "Да", увидите сделанный [проект/фичу/задачу] в этот срок то, что хотите.
Это лишь способ ограничить вариативность размышления.
И периодически повторяя прием по ходу действия проекта, вы можете сужать вилку ваших сроков до более точного.
Честно утащил у @controlchart
Получаем сроки без насилия
Ранее уже приводил один интересный прием, для получения вилки сроков, а дальше для уточнения.
Этот прием, можно применять и к задачам и к проектам.
Суть его заключается в порождении сфокусированного мышления.
Нужно задать вопрос: "Успеем ли сделать [проект/фичу/задачу] к [такому-то] сроку?"
Получаем ответ: "Да/Нет"
В случае ответа "Нет", уточняем другой срок, или уменьшаем скоуп, и снова задаем вопрос.
В отличие от вопроса "Когда сделаем", описанный выше прием позволяет отвечающему привести свои предположения к простому ответу.
Это не значит, что вы получив ответ "Да", увидите сделанный [проект/фичу/задачу] в этот срок то, что хотите.
Это лишь способ ограничить вариативность размышления.
И периодически повторяя прием по ходу действия проекта, вы можете сужать вилку ваших сроков до более точного.
Честно утащил у @controlchart
👍4
#мнение
Какой таск-трекер лучше
Выбрать. Пост не про сравнение таск-трекеров и хвалебные оды фаворитам.
Скорее это размышления на тему того, как стоит подходить к выбору инструмента.
Я люблю рассказывать, как в одной студии за год работы сменил 9 таск-трекеров и хвастаться что команда меня еще не закопала.
Это реальная история, которая имеет в себе четкую мораль - инструмент должен закрывать потребности. Не нравится руководству, быть дешевым или с приятным интерфейсом.
В первую очередь таск-трекер это инструмент для отображения ваших бизнес-процессов. И лишь во вторую способ красиво организовать и построить работу.
Для выбора я руководствовался методикой "взвешенного геометрического показателя качества". Ее суть в том, что выбирается список показателей. Например, каждый трекер мы оцениваем по наличию свимлайнов. Все показатели должны быть количественные, поэтому выбираем относительную шкалу, я беру обычно от 1 до 10. Оцениваем все трекеры по этому критерию и прочим показателям, которые выбрали. Для каждого показателя устанавливаем коэффициент весомости. Сумма этих коэффициентом должна быть равна 1.
В итоге мы выбираем критерии оценки, устанавливаем важность каждого критерия для нас, оцениваем по ним каждый трекер. Все эти значения загоняются в формулу:
геом. показатель = сумма произведений оценки на коэффициент.
Вся хитрость в том чтобы выбрать критерии. Ниже список критериев, которые применял я в последний раз:
1. Открытое api
2. Быстрота загрузки
3. Фильтрация задач
4. Связи между задачами
5. Кастомизация полей
6. Кастомизация пространства (столбцы, свимлайны, доски и т.д.)
7. WiP лимиты
8. Быстрота настройки воркфлоу
9. Отчеты из под коробки
10. Таймтрекинг и таймшиты
11. Комментарии в задачах
12. Удобство создания службы поддержки (service desk)
13. Массовые действия с задачами
14. Отслеживание истории изменений
15. Представление таймлайна/роадмапа/ганта
16. Удобство визуализации
17. и т.д. их было под 30, все уже не вспомню
Для сбора этих критериев нужно пообщаться с командой и руководством. Можно например запереть их в комнате и не выпускать пока не напишут список. Либо есть более гуманный способ, например поднять тему на ретро и в формате lean coffee выбрать критерии с командой.
Как будут получены критерии не так важно. Главное чтобы их список нес все себе 2 ценности:
- удовлетворения потребностей (реальных потребностей команды, менеджера и стейкхолдеров)
- прозрачность процессов (возможность отразить то, что у вас есть сейчас на практике).
По такому списку мы серьезно выбирали Bitrix24, но потом пришли через 3 месяца к тому, что есть неудовлетворенность, обновили наш список и выбрали новый инструмент. Обновления происходили совершенно безболезненно, потому что исходили от команды.
P.S Выбирайте не только из мейнстримного. Вовсе не обязательно, что вам нужна jira, redmine или youtrack. Мы вполне серьезно пользовались 4 месяца гугл табличками и было очень даже удобно.
P.P.S Я сменил самописную CRM, jira, trello, redmine, google sheets, clickup, bitrix24, youtrack, kaiten.
Какой таск-трекер лучше
Выбрать. Пост не про сравнение таск-трекеров и хвалебные оды фаворитам.
Скорее это размышления на тему того, как стоит подходить к выбору инструмента.
Я люблю рассказывать, как в одной студии за год работы сменил 9 таск-трекеров и хвастаться что команда меня еще не закопала.
Это реальная история, которая имеет в себе четкую мораль - инструмент должен закрывать потребности. Не нравится руководству, быть дешевым или с приятным интерфейсом.
В первую очередь таск-трекер это инструмент для отображения ваших бизнес-процессов. И лишь во вторую способ красиво организовать и построить работу.
Для выбора я руководствовался методикой "взвешенного геометрического показателя качества". Ее суть в том, что выбирается список показателей. Например, каждый трекер мы оцениваем по наличию свимлайнов. Все показатели должны быть количественные, поэтому выбираем относительную шкалу, я беру обычно от 1 до 10. Оцениваем все трекеры по этому критерию и прочим показателям, которые выбрали. Для каждого показателя устанавливаем коэффициент весомости. Сумма этих коэффициентом должна быть равна 1.
В итоге мы выбираем критерии оценки, устанавливаем важность каждого критерия для нас, оцениваем по ним каждый трекер. Все эти значения загоняются в формулу:
геом. показатель = сумма произведений оценки на коэффициент.
Вся хитрость в том чтобы выбрать критерии. Ниже список критериев, которые применял я в последний раз:
1. Открытое api
2. Быстрота загрузки
3. Фильтрация задач
4. Связи между задачами
5. Кастомизация полей
6. Кастомизация пространства (столбцы, свимлайны, доски и т.д.)
7. WiP лимиты
8. Быстрота настройки воркфлоу
9. Отчеты из под коробки
10. Таймтрекинг и таймшиты
11. Комментарии в задачах
12. Удобство создания службы поддержки (service desk)
13. Массовые действия с задачами
14. Отслеживание истории изменений
15. Представление таймлайна/роадмапа/ганта
16. Удобство визуализации
17. и т.д. их было под 30, все уже не вспомню
Для сбора этих критериев нужно пообщаться с командой и руководством. Можно например запереть их в комнате и не выпускать пока не напишут список. Либо есть более гуманный способ, например поднять тему на ретро и в формате lean coffee выбрать критерии с командой.
Как будут получены критерии не так важно. Главное чтобы их список нес все себе 2 ценности:
- удовлетворения потребностей (реальных потребностей команды, менеджера и стейкхолдеров)
- прозрачность процессов (возможность отразить то, что у вас есть сейчас на практике).
По такому списку мы серьезно выбирали Bitrix24, но потом пришли через 3 месяца к тому, что есть неудовлетворенность, обновили наш список и выбрали новый инструмент. Обновления происходили совершенно безболезненно, потому что исходили от команды.
P.S Выбирайте не только из мейнстримного. Вовсе не обязательно, что вам нужна jira, redmine или youtrack. Мы вполне серьезно пользовались 4 месяца гугл табличками и было очень даже удобно.
P.P.S Я сменил самописную CRM, jira, trello, redmine, google sheets, clickup, bitrix24, youtrack, kaiten.
👍8🔥1
#рекомендация
Междусобойчик ПМов и не только
Дорогой подписчик, жду тебя на дискуссию в эту субботу. Не факт что мы нанесем тебе непоправимую пользу, но уверен, что будет интересно.
Попробуем новый интерфейс Telegram и узнаем достоин ли ответ Clubhouse. Будем разговаривать на ПМские темы в формате круглого стола и вести оживленную дискуссию.
Возможные темы:
- Как работать с руководством, которое принимает странные решения?
- Как начинать работу с новой командой?
- Как планировать ресурсы на несколько проектов из общего пула?
Соберемся 27 марта в 20.00 по Мск в чате @menya_slyshno и устроим ПМский междусобойчик.
P.S Зайдя заранее можно повлиять на выбор темы или предложить свою.
Междусобойчик ПМов и не только
Дорогой подписчик, жду тебя на дискуссию в эту субботу. Не факт что мы нанесем тебе непоправимую пользу, но уверен, что будет интересно.
Попробуем новый интерфейс Telegram и узнаем достоин ли ответ Clubhouse. Будем разговаривать на ПМские темы в формате круглого стола и вести оживленную дискуссию.
Возможные темы:
- Как работать с руководством, которое принимает странные решения?
- Как начинать работу с новой командой?
- Как планировать ресурсы на несколько проектов из общего пула?
Соберемся 27 марта в 20.00 по Мск в чате @menya_slyshno и устроим ПМский междусобойчик.
P.S Зайдя заранее можно повлиять на выбор темы или предложить свою.
#мнение
Коротко о сути проектного управления.
PMBoK 7 выйдет 1 августа. Хотели 30 марта. Урезали содержание издания.
Коротко о сути проектного управления.
PMBoK 7 выйдет 1 августа. Хотели 30 марта. Урезали содержание издания.
#мнение
Нашлась пропажа
Дорогой читатель. Как ты наверное заметил качество и частота постов немного упали.
Это связано с моей высокой загруженностью на работе, я перешёл в новую компанию юmoney ex Яндекс деньги. Примерно через неделю я оживу и напишу следующие посты:
1) В чем настоящая разница между scrum и kanban-методом.
2) Рецепт проджект менеджера за 3 месяца без вложений в домашних условиях
3) Команда - я ваш новый ПМ
Желаю тебе продуктивной пятницы и не менее занятных выходных!
Нашлась пропажа
Дорогой читатель. Как ты наверное заметил качество и частота постов немного упали.
Это связано с моей высокой загруженностью на работе, я перешёл в новую компанию юmoney ex Яндекс деньги. Примерно через неделю я оживу и напишу следующие посты:
1) В чем настоящая разница между scrum и kanban-методом.
2) Рецепт проджект менеджера за 3 месяца без вложений в домашних условиях
3) Команда - я ваш новый ПМ
Желаю тебе продуктивной пятницы и не менее занятных выходных!
Предыдущий пост снес, так как не ожидал такого шквала критики. Если вы по каким-то причинам считаете нормальным писать в ЛС матом и комментировать посты таким образом вплоть до угроз, то пожалуйста отпишитесь.
#perl
Настоящий проджект тот, кто учел в реестре рисков выходные с 1 по 10 мая.
Детерминирующие для некоторых проектов 😐
Настоящий проджект тот, кто учел в реестре рисков выходные с 1 по 10 мая.
Детерминирующие для некоторых проектов 😐
#рецепт
Аббревиатуры для умников. DoR, DoD, AC, CoS, SC, SMART, INVEST
Тот, кто знаком со мной знает, что я з###от и часто придираюсь к определениям. Поэтому в статье будет 2 ключевых идеи.
Операциональность.
Есть такая штука - операциональное определение. Оно отличается от данного в словаре тем, что кроме однозначности несет в себе концептуальную принадлежность процессу и обоснованность.
Другими словами, позволяет отличать явления и объекты реального мира друг от друга при работе с ними (понимать когда в терминах операций нужно одно, а когда другое).
Различительная способность
Умение человека отличать объекты друг от друга считывая их характеристики. Напрямую связано с качеством - совокупностью свойств продукции, обусловливающих её пригодность удовлетворять определённые потребности в соответствии с её назначением. (Да притянул качество продукции).
Люди отличают предметы и явления друг от друга по степени закрытия своих хотелок с помощью применения оных предметов.
Дорогой читатель, наверняка ты в легком недоумении.
Поясню, написанное выше нужно для того, чтобы задумался, а как мы понимаем когда нужен тот или иной инструмент.
Два описанных выше определения часто вступают в конфликт. Один человек говорит в терминах того, как он думает (теоретик), а другой в терминах того как он чувствует или на базе своего опыта (практик).
В итоге иногда гвозди забиваются микроскопами.
Например, это приводит к тому что проджектов заменяют на продактов, хотя новые специалисты выполняют работу предыдущих.
Вернемся к исходной повестке.
Теория:
INVEST - критерий правильности User story.
I - independent, независимость. Поставляем без влияния других историй.
N - negotiable, обсуждаемость. Сами решим как ее лучше сделать
V - valuable, ценность. Сделав ее нанесем ценность бизнесу
E - estimable, оцениваемость. Сможем дать оценку по сложности/срокам
S - small, компактность. Сделаем за одну итерацию.
T - testable, проверяемость. Понимаем как проверить или оттестировать.
Практика:
Позволяет проверить, хорошо ли сформулирована user story на старте.
Применяем чтобы user story были правильно написаны. Используем только при написании user story и не несем в цели, сбор требований, постановку инженерных задач и т.д.
Теория:
SMART - метод описания целей, для понимания конечного результата действий.
S - specific, конкретность. Делаем что-то определенное.
M - measurable, измеримость. Сможем измерить факты, подтверждающие достижение цели.
A - achievable, достижимость. Сможем ее достичь, так как цель реальная.
R - relevant, важность. Делаем не просто так, а в раках стратегии и приоритетности для бизнеса.
T - time bound, ограничение по времени. Знаем когда закончим выполнение цели
Практика:
Позволяет описать цель понятным для всех, кто будет участвовать в ее достижении, описывает "зачем, когда и что конкретно сделать, как это проверить".
Применяем, когда хотим сформулировать понятную цель на уровне тактики и сделать ее обоснованной, а не с потолка. Подходит только для целей.
Теория:
SC - показатель, который позволяет судить об успешности выполнения деятельности.
SC - Success Criteria, критерии успеха.
Практика:
Применяем чтобы выделить показатели, по которым потом мы сможем понять, что сделали правильно с точки зрения организации.
Пишем только для тех активностей, которые занимают продолжительное время и влияют на процессы или состояние бизнеса. Проект в этом плане идеальный кандидат.
Теория:
CoS - критерий приемки конечным потребителем результата.
CoS - Conditions of Satisfaction, тоже самое что AC - Acceptance Criteria.
Практика:
Применяем, когда хотим понять как будет приниматься конкретный результат работы. Например, сделали вы карту. Список действий, которые пользователь сделает, чтобы проверить что карта работает как ему надо и есть AC
Аббревиатуры для умников. DoR, DoD, AC, CoS, SC, SMART, INVEST
Тот, кто знаком со мной знает, что я з###от и часто придираюсь к определениям. Поэтому в статье будет 2 ключевых идеи.
Операциональность.
Есть такая штука - операциональное определение. Оно отличается от данного в словаре тем, что кроме однозначности несет в себе концептуальную принадлежность процессу и обоснованность.
Другими словами, позволяет отличать явления и объекты реального мира друг от друга при работе с ними (понимать когда в терминах операций нужно одно, а когда другое).
Различительная способность
Умение человека отличать объекты друг от друга считывая их характеристики. Напрямую связано с качеством - совокупностью свойств продукции, обусловливающих её пригодность удовлетворять определённые потребности в соответствии с её назначением. (Да притянул качество продукции).
Люди отличают предметы и явления друг от друга по степени закрытия своих хотелок с помощью применения оных предметов.
Дорогой читатель, наверняка ты в легком недоумении.
Поясню, написанное выше нужно для того, чтобы задумался, а как мы понимаем когда нужен тот или иной инструмент.
Два описанных выше определения часто вступают в конфликт. Один человек говорит в терминах того, как он думает (теоретик), а другой в терминах того как он чувствует или на базе своего опыта (практик).
В итоге иногда гвозди забиваются микроскопами.
Например, это приводит к тому что проджектов заменяют на продактов, хотя новые специалисты выполняют работу предыдущих.
Вернемся к исходной повестке.
Теория:
INVEST - критерий правильности User story.
I - independent, независимость. Поставляем без влияния других историй.
N - negotiable, обсуждаемость. Сами решим как ее лучше сделать
V - valuable, ценность. Сделав ее нанесем ценность бизнесу
E - estimable, оцениваемость. Сможем дать оценку по сложности/срокам
S - small, компактность. Сделаем за одну итерацию.
T - testable, проверяемость. Понимаем как проверить или оттестировать.
Практика:
Позволяет проверить, хорошо ли сформулирована user story на старте.
Применяем чтобы user story были правильно написаны. Используем только при написании user story и не несем в цели, сбор требований, постановку инженерных задач и т.д.
Теория:
SMART - метод описания целей, для понимания конечного результата действий.
S - specific, конкретность. Делаем что-то определенное.
M - measurable, измеримость. Сможем измерить факты, подтверждающие достижение цели.
A - achievable, достижимость. Сможем ее достичь, так как цель реальная.
R - relevant, важность. Делаем не просто так, а в раках стратегии и приоритетности для бизнеса.
T - time bound, ограничение по времени. Знаем когда закончим выполнение цели
Практика:
Позволяет описать цель понятным для всех, кто будет участвовать в ее достижении, описывает "зачем, когда и что конкретно сделать, как это проверить".
Применяем, когда хотим сформулировать понятную цель на уровне тактики и сделать ее обоснованной, а не с потолка. Подходит только для целей.
Теория:
SC - показатель, который позволяет судить об успешности выполнения деятельности.
SC - Success Criteria, критерии успеха.
Практика:
Применяем чтобы выделить показатели, по которым потом мы сможем понять, что сделали правильно с точки зрения организации.
Пишем только для тех активностей, которые занимают продолжительное время и влияют на процессы или состояние бизнеса. Проект в этом плане идеальный кандидат.
Теория:
CoS - критерий приемки конечным потребителем результата.
CoS - Conditions of Satisfaction, тоже самое что AC - Acceptance Criteria.
Практика:
Применяем, когда хотим понять как будет приниматься конкретный результат работы. Например, сделали вы карту. Список действий, которые пользователь сделает, чтобы проверить что карта работает как ему надо и есть AC
👍6
#рецепт
Теория:
DoD - критерий завершенности рабочего элемента/инкримента. Набор действий, которые необходимо совершить над задачей, чтобы ее можно было считать готовой.
DoD - Definition of Done.
Практика:
Применяем когда хотим обозначить, что является готовым результатом.
Идем к стейкхолдерам и договариваемся, что готовая задача, это та, где пройдены тесты, написана документация и зарелижено на прод.
Список таких действий для каждого типа задач и есть DoD. Он может отличатся для бага и user story.
Теория:
DoR - критерий подготовленности рабочего элемента/инкримента к выполнению работы конкретной командой/сервисом.
DoR - Definition of Ready.
Практика:
Применяем когда хотим обозначить условия, после которых команда может работать над задачей.
Идем к стейкхолдерам и говорим, что не будем делать задачу, пока по ней нет AC и тестировщики из другой команды и будут свободны.
Список таких действий и есть DoR.
Пост написан, чтобы у тебя сложилось представление об этих инструментах и ты смог применять их в нужной ситуации.
P.S. Написал пост после того, как коллега по пет-проекту попросил написать нормально AC по SMART к задаче.
P.P.S. Автор оставляет за собой право быть неправым и вы можете объяснить ему это в публичных комментариях.
Теория:
DoD - критерий завершенности рабочего элемента/инкримента. Набор действий, которые необходимо совершить над задачей, чтобы ее можно было считать готовой.
DoD - Definition of Done.
Практика:
Применяем когда хотим обозначить, что является готовым результатом.
Идем к стейкхолдерам и договариваемся, что готовая задача, это та, где пройдены тесты, написана документация и зарелижено на прод.
Список таких действий для каждого типа задач и есть DoD. Он может отличатся для бага и user story.
Теория:
DoR - критерий подготовленности рабочего элемента/инкримента к выполнению работы конкретной командой/сервисом.
DoR - Definition of Ready.
Практика:
Применяем когда хотим обозначить условия, после которых команда может работать над задачей.
Идем к стейкхолдерам и говорим, что не будем делать задачу, пока по ней нет AC и тестировщики из другой команды и будут свободны.
Список таких действий и есть DoR.
Пост написан, чтобы у тебя сложилось представление об этих инструментах и ты смог применять их в нужной ситуации.
P.S. Написал пост после того, как коллега по пет-проекту попросил написать нормально AC по SMART к задаче.
P.P.S. Автор оставляет за собой право быть неправым и вы можете объяснить ему это в публичных комментариях.
#рецепты
Как дела у проекта?
Недавно мне задали вопрос: «Какие есть инструменты отслеживания прогресса проекта?»
Я воспылал и решил написать свой арсенал. Некоторые из инструментов весьма экзотические, а другие являются классикой. Если у тебя есть что-то особенное, что не попало в список, то поделись эти в комментариях и я расширю подборку.
1) Метод контрольных точек – обвешиваешь проект ожидаемыми результатами работ и контролируешь их достижение. Также на помощь приходят правила 20/80 и любые другие, вроде 10/40/50;
2) Монте-Карло – вытаскиваешь исторические данные о сроках завершения задач (lead time/resolution time), например из Jira. Берешь статистически корректную выборку таких значений, берешь нужные тебе значения времени и скармливаешь алгоритму Монте-Карло. Сделать его можно даже в Excel, шаблонов полно. На выходе получаешь прогноз выполнения этих задач;
3) Fever chart (через буфер) – привет теории ограничений систем. В начале проекта ты должен был заложить буфер. Строишь график его расхода и отслеживаешь прогресс по нему, нет ничего проще;
4) План/фактный анализ- просто сравни полученную любым способом фактическую оценку продолжительности проекта с первоначальными планами. «Вася, сколько надо на проект? Еще 2 недели. А мы в начале планировали за 1 одну, ага»;
5) Визуальный анализ, например по Ганта – прожигаешь взглядом визуальное представление расписания проекта, например на диаграмме Ганта и прикидываешь сколько займет времени остаток проекта;
6) Метод освоенного объема – считаешь PV, AC, EV, считаешь по ним индексы и вариансы, строишь по ним графики. Визуально отслеживаешь по графикам точку завершения проекта. сравниваешь ее с первоначальным планом. Ну или просто учишься читать значения EVM и понимать почему SP>0 это значит проект обгоняет расписание;
7) Backlog health – метрик полно, объединены они следующим смыслом: по тренду изменения метрик мы можем предсказать срок «сгорания» текущего беклога. Например, посчитав age time, velocity, BMI и загнав их в формулу, можем получить 5 месяцев. Вот и оценка того, сколько с такими темпами работы осталось делать проект;
8) По вехам – смысл тот же, что и в контрольных точках;
9) Burn down – смотришь на тренд сгорания задач и прикидываешь сколько потребуется времени чтобы «сжечь» беклог такими темпами;
10) Контрольные карты Шухарта – для профессионалов (уже месяц потратил пытаясь понять как это делать.
P.S. Ссылки на то, как пользоваться не указал намеренно, так как считаю что главный навык менеджера - быстрый поиск информации. Но если ты очень ленив, то напиши мне, я поделюсь.
Как дела у проекта?
Недавно мне задали вопрос: «Какие есть инструменты отслеживания прогресса проекта?»
Я воспылал и решил написать свой арсенал. Некоторые из инструментов весьма экзотические, а другие являются классикой. Если у тебя есть что-то особенное, что не попало в список, то поделись эти в комментариях и я расширю подборку.
1) Метод контрольных точек – обвешиваешь проект ожидаемыми результатами работ и контролируешь их достижение. Также на помощь приходят правила 20/80 и любые другие, вроде 10/40/50;
2) Монте-Карло – вытаскиваешь исторические данные о сроках завершения задач (lead time/resolution time), например из Jira. Берешь статистически корректную выборку таких значений, берешь нужные тебе значения времени и скармливаешь алгоритму Монте-Карло. Сделать его можно даже в Excel, шаблонов полно. На выходе получаешь прогноз выполнения этих задач;
3) Fever chart (через буфер) – привет теории ограничений систем. В начале проекта ты должен был заложить буфер. Строишь график его расхода и отслеживаешь прогресс по нему, нет ничего проще;
4) План/фактный анализ- просто сравни полученную любым способом фактическую оценку продолжительности проекта с первоначальными планами. «Вася, сколько надо на проект? Еще 2 недели. А мы в начале планировали за 1 одну, ага»;
5) Визуальный анализ, например по Ганта – прожигаешь взглядом визуальное представление расписания проекта, например на диаграмме Ганта и прикидываешь сколько займет времени остаток проекта;
6) Метод освоенного объема – считаешь PV, AC, EV, считаешь по ним индексы и вариансы, строишь по ним графики. Визуально отслеживаешь по графикам точку завершения проекта. сравниваешь ее с первоначальным планом. Ну или просто учишься читать значения EVM и понимать почему SP>0 это значит проект обгоняет расписание;
7) Backlog health – метрик полно, объединены они следующим смыслом: по тренду изменения метрик мы можем предсказать срок «сгорания» текущего беклога. Например, посчитав age time, velocity, BMI и загнав их в формулу, можем получить 5 месяцев. Вот и оценка того, сколько с такими темпами работы осталось делать проект;
8) По вехам – смысл тот же, что и в контрольных точках;
9) Burn down – смотришь на тренд сгорания задач и прикидываешь сколько потребуется времени чтобы «сжечь» беклог такими темпами;
10) Контрольные карты Шухарта – для профессионалов (уже месяц потратил пытаясь понять как это делать.
P.S. Ссылки на то, как пользоваться не указал намеренно, так как считаю что главный навык менеджера - быстрый поиск информации. Но если ты очень ленив, то напиши мне, я поделюсь.
#артефакты
В чем сила?
Мой читатель, ты когда-нибудь задумывался, для чего нужны руководители проектов? Не вот эти лозунги: "достигать цели проекта", "укладываться в треугольник" и т.д. Нет в них смысла что ли, какие-то они бесполезные.
Недавно подслушал разговор мальчика с бабушкой. Немного карикатурный, прям как в анекдоте. Мальчик спрашивает: "А почему на небе облака? Ответ бомбичен: "Чтобы красиво было". Вот у меня такое же впечатление от лозунгов выше.
Небольшой экскурс в историю. Человечество тысячи лет возводило колоссальные сооружения, рыло каналы, строило колонии. А потребность в проектном управлении созрела в 1950-х. Пик пришелся на 70-е. Почему так? Истина зарыта как раз в развитии цивилизации - повысилась сложность, а вслед за ней и неопределенность.
А когда повестка рынка сменилась с рынка производителя на рынок потребителя произошел взрыв неопределенности. Тогда и потребовались люди, которые умеют работать в условиях неизвестности и при этом достигать поставленной цели. "Сделай это, черт знает как, но чтобы было через 3 месяца".
В этом и суть руководителя проекта - сводить неопределенность до управляемого состояния. Именно поэтому менеджер это своеобразный командир взвода, который должен уметь работать в условиях хаоса боя. Все инструменты проектного управления, от сетевой диаграмы и до управления стейкхолдерами заточены для этого. Особенно яркий представитель управление рисками.
Риск - вероятностное событие, наступление которого повлияет на ход проекта. Положительный риск поможет, отрицательный помешает. Изюминка неопределенности. Выявил, оценил, структурировал, спланировал, отслеживал и среагировал - должно отлетать от зубов при ночной побудке. Кстати хороший лайфхак. Хочешь проверить кого в проектном управлении - спроси как он работает с рисками.
Так вот. Сила в неопределенности.
P.S. На сладкое прикладываю реестр рисков, авось кому пригодится.
Ссылка на реестр рисков
В чем сила?
Мой читатель, ты когда-нибудь задумывался, для чего нужны руководители проектов? Не вот эти лозунги: "достигать цели проекта", "укладываться в треугольник" и т.д. Нет в них смысла что ли, какие-то они бесполезные.
Недавно подслушал разговор мальчика с бабушкой. Немного карикатурный, прям как в анекдоте. Мальчик спрашивает: "А почему на небе облака? Ответ бомбичен: "Чтобы красиво было". Вот у меня такое же впечатление от лозунгов выше.
Небольшой экскурс в историю. Человечество тысячи лет возводило колоссальные сооружения, рыло каналы, строило колонии. А потребность в проектном управлении созрела в 1950-х. Пик пришелся на 70-е. Почему так? Истина зарыта как раз в развитии цивилизации - повысилась сложность, а вслед за ней и неопределенность.
А когда повестка рынка сменилась с рынка производителя на рынок потребителя произошел взрыв неопределенности. Тогда и потребовались люди, которые умеют работать в условиях неизвестности и при этом достигать поставленной цели. "Сделай это, черт знает как, но чтобы было через 3 месяца".
В этом и суть руководителя проекта - сводить неопределенность до управляемого состояния. Именно поэтому менеджер это своеобразный командир взвода, который должен уметь работать в условиях хаоса боя. Все инструменты проектного управления, от сетевой диаграмы и до управления стейкхолдерами заточены для этого. Особенно яркий представитель управление рисками.
Риск - вероятностное событие, наступление которого повлияет на ход проекта. Положительный риск поможет, отрицательный помешает. Изюминка неопределенности. Выявил, оценил, структурировал, спланировал, отслеживал и среагировал - должно отлетать от зубов при ночной побудке. Кстати хороший лайфхак. Хочешь проверить кого в проектном управлении - спроси как он работает с рисками.
Так вот. Сила в неопределенности.
P.S. На сладкое прикладываю реестр рисков, авось кому пригодится.
Ссылка на реестр рисков
Google Docs
Реестр рисков шаблон
👍1
#полезности
Турнир канбанистов
Здравствуй, активный читатель!
Скоро пройдет турнир для настоящих канбаньеро. Поиграем в симуляцию getKanban и выясним какой город круче.
Буду рад тебя видеть на нем, если хочешь сразиться во славу Канбана.
Пройдет вот тогда:
22.05.21 (суббота) с 11 до 14 UTC +3
Регистрироваться тутъ:
https://forms.gle/9NLTQqFKm61ySTrr8
Турнир канбанистов
Здравствуй, активный читатель!
Скоро пройдет турнир для настоящих канбаньеро. Поиграем в симуляцию getKanban и выясним какой город круче.
Буду рад тебя видеть на нем, если хочешь сразиться во славу Канбана.
Пройдет вот тогда:
22.05.21 (суббота) с 11 до 14 UTC +3
Регистрироваться тутъ:
https://forms.gle/9NLTQqFKm61ySTrr8
Google Docs
Турнир Kanban board game
Заявка на участие в турнире
Forwarded from Алекс
P38A4049.jpg
289.6 KB
Друзья, нас в группе Русскоязычных канбан практиков уже порядка + 1300 человек и пора уже выяснить в каком городе бывших стран СНГ самые сильные Канбан практики.
Как мы узнаем ?
Проведем турнир 22 мая с 11:00 до 14:00 МСК по игре симуляции kanbanboardgame (http://www.kanbanboardgame.com) Продолжительность игры 2 часа, по истечении 2 часов команда набравшая больше $ будет считаться победителем. Заявки на участие оставляйте здесь: https://forms.gle/9NLTQqFKm61ySTrr8 будем формировать команды. Регистрация заканчивается в пятницу в 16:00 МСК Как будет проходить игра ? 22 мая в 11:00 по МСК мы соберемся в zoom. разбиваемся на команды в зависимости какой город вы представляете. Запускаем таймер на 2 часа и начинаем игру. После подводим итоги кто победитель, делаем короткий дебриф.
Как мы узнаем ?
Проведем турнир 22 мая с 11:00 до 14:00 МСК по игре симуляции kanbanboardgame (http://www.kanbanboardgame.com) Продолжительность игры 2 часа, по истечении 2 часов команда набравшая больше $ будет считаться победителем. Заявки на участие оставляйте здесь: https://forms.gle/9NLTQqFKm61ySTrr8 будем формировать команды. Регистрация заканчивается в пятницу в 16:00 МСК Как будет проходить игра ? 22 мая в 11:00 по МСК мы соберемся в zoom. разбиваемся на команды в зависимости какой город вы представляете. Запускаем таймер на 2 часа и начинаем игру. После подводим итоги кто победитель, делаем короткий дебриф.
#мнение #полезности
Ошибка перегруза
Одновременно с работой изучать описательную статистику, логистику, статистический контроль процессов и дата визуализацию оказалось ошибкой.
Обязательно растыкаюсь и напишу интересный пост завтра.
А пока из полезного порекомендую datalearn. У Димы из @rockyourdata очень классный курс и полностью бесплатный. А ещё очень кайфовое комьюнити (и нет, я не ангажирован, заказной рекламы тут точно не будет, просто сам прохожу).
Грамотной структурированный курс по аналитике данных и data engineering, уверен кому-то поможет
https://datalearn.ru/
Ошибка перегруза
Одновременно с работой изучать описательную статистику, логистику, статистический контроль процессов и дата визуализацию оказалось ошибкой.
Обязательно растыкаюсь и напишу интересный пост завтра.
А пока из полезного порекомендую datalearn. У Димы из @rockyourdata очень классный курс и полностью бесплатный. А ещё очень кайфовое комьюнити (и нет, я не ангажирован, заказной рекламы тут точно не будет, просто сам прохожу).
Грамотной структурированный курс по аналитике данных и data engineering, уверен кому-то поможет
https://datalearn.ru/
#рецепт
Бесполезный менеджер
Довольно часто слышу, что менеджеры бесполезны. А особенно проджект-менеджеры, ведь есть Agile. Да и это легко, транслировать слова заказчиков, встречи назначать. Кличка передаст появилась не зря.
Дорогой читатель, прошу прощения, но я снова ударю тебя по голове обухом теории. Я верю, повторение мать олигофренской педагогики.
Менеджер - лицо, которое назначено организацией руководить чем-либо. Для руководства у него есть четыре функции управления - планирование, организация, мотивация и контроль.
Они имеют две общих характеристики: требуют принятия решений, и для всех необходима коммуникация, обмен информацией, чтобы получить информацию для принятия правильного решения и сделать это решение понятным для других членов организации. Из-за этого, а также вследствие того, что эти две характеристики связывают все четыре управленческие функции, обеспечивая их взаимозависимость, коммуникации и принятие решений часто называют связующими процессами.
Как перестать быть бесполезным менеджером? Использовать эти четыре функции на полную во всем, что попадает в область влияния!
Простой пример. У тебя есть встреча с заказчиком. Снизить планку бесполезности поможет чеклист:
1. Завел конференцию в условном зуме;
2. Добавил встречу в календарь заказчика и себе;
3. Написал цель встречи и желательно результат;
4. Составил повестку и отправил заказчику(можно и тайминг, но это не всегда работает);
5. Напомнил о встрече за час до нее;
6. Вел встречу, управлял фокусом;
7. Фиксировал принятые решения/важные топики;
8. По результатам встречи выслал митингминотс.
В этих простых действиях выражаются все 4 функции. Рекомендую отрефлексировать, в чем из списка выражается каждая из функций. Такие активности имеют побочный эффект - они повышают комфорт от работы. Приятные мелочи.
Мораль следующая - будь мелочен, люди оценят.
Бесполезный менеджер
Довольно часто слышу, что менеджеры бесполезны. А особенно проджект-менеджеры, ведь есть Agile. Да и это легко, транслировать слова заказчиков, встречи назначать. Кличка передаст появилась не зря.
Дорогой читатель, прошу прощения, но я снова ударю тебя по голове обухом теории. Я верю, повторение мать олигофренской педагогики.
Менеджер - лицо, которое назначено организацией руководить чем-либо. Для руководства у него есть четыре функции управления - планирование, организация, мотивация и контроль.
Они имеют две общих характеристики: требуют принятия решений, и для всех необходима коммуникация, обмен информацией, чтобы получить информацию для принятия правильного решения и сделать это решение понятным для других членов организации. Из-за этого, а также вследствие того, что эти две характеристики связывают все четыре управленческие функции, обеспечивая их взаимозависимость, коммуникации и принятие решений часто называют связующими процессами.
Как перестать быть бесполезным менеджером? Использовать эти четыре функции на полную во всем, что попадает в область влияния!
Простой пример. У тебя есть встреча с заказчиком. Снизить планку бесполезности поможет чеклист:
1. Завел конференцию в условном зуме;
2. Добавил встречу в календарь заказчика и себе;
3. Написал цель встречи и желательно результат;
4. Составил повестку и отправил заказчику(можно и тайминг, но это не всегда работает);
5. Напомнил о встрече за час до нее;
6. Вел встречу, управлял фокусом;
7. Фиксировал принятые решения/важные топики;
8. По результатам встречи выслал митингминотс.
В этих простых действиях выражаются все 4 функции. Рекомендую отрефлексировать, в чем из списка выражается каждая из функций. Такие активности имеют побочный эффект - они повышают комфорт от работы. Приятные мелочи.
Мораль следующая - будь мелочен, люди оценят.
👍2
#полезности
Релиз книги по lean data science.
Короткий, но ёмкий гайд. Автор тот самый Асхат Уразбаев. Уверен, будет полезно тем, кто ковыряет проекты и продукты связанные с ML, DS и дата инжинирингом.
Релиз книги по lean data science.
Короткий, но ёмкий гайд. Автор тот самый Асхат Уразбаев. Уверен, будет полезно тем, кто ковыряет проекты и продукты связанные с ML, DS и дата инжинирингом.
Forwarded from LeanDS
НАКОНЕЦ-ТО‼️
Мы выпускаем книгу ‼️LEAN DATA SCIENCE: гибкое управление DS проектами и продуктами‼️. Это выжимка🥤 из всех практик управления Data Science без воды: 📃 61 страница лучших практик, 🤩квинтэссенция опыта крутейших DS команд, 📗набор готовых подходов, а не просто набор анекдотов из жизни, 🧠написана биологической нейросетью ☺️.
Скачивайте, читайте:
https://leands.ai/ru
Давайте обратную связь в нашем чате @leands_chat
Мы выпускаем книгу ‼️LEAN DATA SCIENCE: гибкое управление DS проектами и продуктами‼️. Это выжимка🥤 из всех практик управления Data Science без воды: 📃 61 страница лучших практик, 🤩квинтэссенция опыта крутейших DS команд, 📗набор готовых подходов, а не просто набор анекдотов из жизни, 🧠написана биологической нейросетью ☺️.
Скачивайте, читайте:
https://leands.ai/ru
Давайте обратную связь в нашем чате @leands_chat
#рецепт
Кто нас делает менеджерами
Дорогой читатель, ты наверняка заметил, что я состою в огромном количестве чатов телеграм и переодически в них мелькаю. Наверняка у тебя появилась мысль, что я безработный.
Это не совсем так. Постоянное общение необходимо не от скуки, а ради развития. Разговаривая с людьми человек развивается гораздо быстрее, чем от чтения книг и на порядок чем от просмотра видео. Даже просто текстовая переписка впечатывается сильнее, так уж устроена механо-социальная природа человека.
И самое важное, общаясь в профессиональных сообществах можно увидеть не информацию, но и способ мышления. Лично меня менеджером сделали не книги, опыт или курсы, а люди.
Ниже прилагаю кусочек пеписки из Канбан-толкс:
Sergey Gospodchikov
Все проблемы не в Скраме. Они в людях, в процессах, в ГОЛОВАХ. Это лишь прожектор, который все подсвечивает. Скрам не решает проблемы. Он лишь позволяет их увидеть при правильном подходе. Дальше все зависит от вас. Это лишь люди и процессы, как и везде
Sergey Gospodchikov
Скрам это лишь несколько петель обратной связи (события и Скрам-мастер), которые работают при условии прозрачности (которую Скрам-мастер и призван в том числе обеспечить). Они дают возможность инспекции, дают возможность увидеть проблемы. Больше там нет НИЧЕГО. Оболочка. Успешность зависит от того, решаешь ли ты выявленные проблемы или нет. Это адаптация. Что внутри всего этого - твой контекст. И он никак от самой оболочки не зависит. НИКАК. И да, никто не мешает использовать Канбан-метод (да и много чего еще) для улучшений внутри. Поймите это наконец. от НАС ВСЕ ЗАВИСИТ. Не от Скрама или Канбана. От нас. Личное мнение.
Примечание передаста:
Тут упоминается цикл I&A, на котором живет Скрам, но почему-то 90% забывают про него, даже просто факапят в механизме ретро. Собственно как и бизнесмены в PDCA.
Артем Летюшев
[В ответ на Sergey Gospodchikov]
Да я то понимаю это отношусь к нему как лопате. От лопаты же не зависит как окучил грядку и какая уродилась картошка.
Sergey Gospodchikov
[В ответ на Артем Летюшев]
Нет. Это не лопата. Это прожектор, который позволяет копать ночью лопатой (или вилами, или экскаватором) и видеть все корешки, которые нужно выбрать. Но если ты не будешь выбирать корешки, урожая не будет.
Aleksei Pimenov
[В ответ на Sergey Gospodchikov]
Хорошая метафора, но все равно можно находить разные критические моменты. Ибо не всегда позволяет и не в любую ночь и не все корешки освещает. Все очень контекстно. Но это не отменяет того, что инструмент хорош в правильном применении.
Мораль:
Найди сообщество профессионалов и задавай вопросы. Особенно глупые, в них особенно раскрываются пробелы, которые помогут залатать. Включись в разные сообщества, получай разные ответы и разные взгляды на решение проблем. Расти в общении.
Кто нас делает менеджерами
Дорогой читатель, ты наверняка заметил, что я состою в огромном количестве чатов телеграм и переодически в них мелькаю. Наверняка у тебя появилась мысль, что я безработный.
Это не совсем так. Постоянное общение необходимо не от скуки, а ради развития. Разговаривая с людьми человек развивается гораздо быстрее, чем от чтения книг и на порядок чем от просмотра видео. Даже просто текстовая переписка впечатывается сильнее, так уж устроена механо-социальная природа человека.
И самое важное, общаясь в профессиональных сообществах можно увидеть не информацию, но и способ мышления. Лично меня менеджером сделали не книги, опыт или курсы, а люди.
Ниже прилагаю кусочек пеписки из Канбан-толкс:
Sergey Gospodchikov
Все проблемы не в Скраме. Они в людях, в процессах, в ГОЛОВАХ. Это лишь прожектор, который все подсвечивает. Скрам не решает проблемы. Он лишь позволяет их увидеть при правильном подходе. Дальше все зависит от вас. Это лишь люди и процессы, как и везде
Sergey Gospodchikov
Скрам это лишь несколько петель обратной связи (события и Скрам-мастер), которые работают при условии прозрачности (которую Скрам-мастер и призван в том числе обеспечить). Они дают возможность инспекции, дают возможность увидеть проблемы. Больше там нет НИЧЕГО. Оболочка. Успешность зависит от того, решаешь ли ты выявленные проблемы или нет. Это адаптация. Что внутри всего этого - твой контекст. И он никак от самой оболочки не зависит. НИКАК. И да, никто не мешает использовать Канбан-метод (да и много чего еще) для улучшений внутри. Поймите это наконец. от НАС ВСЕ ЗАВИСИТ. Не от Скрама или Канбана. От нас. Личное мнение.
Примечание передаста:
Тут упоминается цикл I&A, на котором живет Скрам, но почему-то 90% забывают про него, даже просто факапят в механизме ретро. Собственно как и бизнесмены в PDCA.
Артем Летюшев
[В ответ на Sergey Gospodchikov]
Да я то понимаю это отношусь к нему как лопате. От лопаты же не зависит как окучил грядку и какая уродилась картошка.
Sergey Gospodchikov
[В ответ на Артем Летюшев]
Нет. Это не лопата. Это прожектор, который позволяет копать ночью лопатой (или вилами, или экскаватором) и видеть все корешки, которые нужно выбрать. Но если ты не будешь выбирать корешки, урожая не будет.
Aleksei Pimenov
[В ответ на Sergey Gospodchikov]
Хорошая метафора, но все равно можно находить разные критические моменты. Ибо не всегда позволяет и не в любую ночь и не все корешки освещает. Все очень контекстно. Но это не отменяет того, что инструмент хорош в правильном применении.
Мораль:
Найди сообщество профессионалов и задавай вопросы. Особенно глупые, в них особенно раскрываются пробелы, которые помогут залатать. Включись в разные сообщества, получай разные ответы и разные взгляды на решение проблем. Расти в общении.
#мнение
Рынок растет
С 2 квартала наблюдаю небывалый рост прайса "поддерживающих" специальностей в IT, таких как БА, СА, СМ и ПМ.
Верхний порог вилки сдвинулся на 12-18% , у сеньоров под 30%.
Год назад в РФ в принципе не было вакансий для стажёров/пре джунов за 60 к. Однако.
Рынок растет
С 2 квартала наблюдаю небывалый рост прайса "поддерживающих" специальностей в IT, таких как БА, СА, СМ и ПМ.
Верхний порог вилки сдвинулся на 12-18% , у сеньоров под 30%.
Год назад в РФ в принципе не было вакансий для стажёров/пре джунов за 60 к. Однако.
Forwarded from Management Jobs — вакансии и резюме
#вакансия #краснодар #удаленка
Вакансия: Junior Project manager
✅Локация: г. Краснодар или удаленка
✅Занятость: Полная
✅Опыт: от 6 мес. +
✅Зарплата: от 65 000 до 95 000 тыс. руб. gross
✅Компания: Plarium Krasnodar
Привет! На связи игровая студия Plarium Krasnodar, нас знают по проектам Vikings: War of Clans и Throne: Kingdom at War. Мы ищем Junior Project Manager. Вакансия подойдет тем, кто хочет попасть в геймдев без опыта в индустрии, смс и регистрации. 🚀
👨🏻💻Junior PM будет управлять командой: ставить задачи, контролировать срок их выполнения, помогать искать информацию и связываться с другими отделами.
🧩Нам нужен человек, который имеет небольшой опыт (6 мес. +) управления проектами в IT и/или знает, как разрабатывают игры. Также мы рассматриваем кандидатов без опыта работы на позиции РМ, после пройденных курсов или с высшим образованием в сфере менеджмента/управления (Intern).
💰Мы предлагаем: белое оформление, бесплатные курсы английского, ДМС, тренинги и прочие плюшки. С переездом в Краснодар мы поможем — или организуем удаленку.
Если хочешь отправить резюме или задать вопрос, пиши в TG мне @anyakorobkina или на почту hr.admin.krd@plarium.com.
—
👉 Обсуждение вакансии в чате @projects_jobs
Вакансия: Junior Project manager
✅Локация: г. Краснодар или удаленка
✅Занятость: Полная
✅Опыт: от 6 мес. +
✅Зарплата: от 65 000 до 95 000 тыс. руб. gross
✅Компания: Plarium Krasnodar
Привет! На связи игровая студия Plarium Krasnodar, нас знают по проектам Vikings: War of Clans и Throne: Kingdom at War. Мы ищем Junior Project Manager. Вакансия подойдет тем, кто хочет попасть в геймдев без опыта в индустрии, смс и регистрации. 🚀
👨🏻💻Junior PM будет управлять командой: ставить задачи, контролировать срок их выполнения, помогать искать информацию и связываться с другими отделами.
🧩Нам нужен человек, который имеет небольшой опыт (6 мес. +) управления проектами в IT и/или знает, как разрабатывают игры. Также мы рассматриваем кандидатов без опыта работы на позиции РМ, после пройденных курсов или с высшим образованием в сфере менеджмента/управления (Intern).
💰Мы предлагаем: белое оформление, бесплатные курсы английского, ДМС, тренинги и прочие плюшки. С переездом в Краснодар мы поможем — или организуем удаленку.
Если хочешь отправить резюме или задать вопрос, пиши в TG мне @anyakorobkina или на почту hr.admin.krd@plarium.com.
—
👉 Обсуждение вакансии в чате @projects_jobs