#рецепт
Аббревиатуры для умников. 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
#полезности
Второй турнир канбанистов
Добрый день, подписчик!
На следующей недели мы соберемся с канбан-практика и в очередной раз сразимся за звание
самого самого. В прошлый раз не было никого из СПб, пришлось играть за Бишкек)
Пройдет вот тогда:
19.06.21 (суббота) с 11 до 14 UTC +3
Второй турнир канбанистов
Добрый день, подписчик!
На следующей недели мы соберемся с канбан-практика и в очередной раз сразимся за звание
самого самого. В прошлый раз не было никого из СПб, пришлось играть за Бишкек)
Пройдет вот тогда:
19.06.21 (суббота) с 11 до 14 UTC +3
Forwarded from Алекс
Greetings,до II Международнго Турнира по игре KanbanBoardGame http://www.kanbanboardgame.com/ остается неделя. Проведем турнир 19 июня в 11:00 до 14:00 (GMT+3) . Продолжаем набор участников, кто готов побороться за звание "Величайший Русскоговорящий Канбан практик" Заявки на участие оставляйте сюда (Регистрация заканчивается в пятницу 18 июня в 16:00 (GMT+3)): https://forms.gle/HkNbTkuMzsYsRP2YA Продолжительность игры 90 минут, по истечении этого времени команда набравшая больше $ будет считаться победителем. будем формировать команды. Команда 3 - 6 человек. Как будет проходить игра ? В день игры в 11:00 по МСК мы соберемся в zoom. (все ссылки получите в письме) разбиваемся на сесионные залы в зависимости какой город вы представляете. Запускаем таймер на 90 минут и начинаем игру. В сесионных залах выбираете капитана (Шарит рабочий стол и расставляет фигурки). ВЫбираете режим STANDART. После подводим итоги кто победитель, делаем короткий дебриф.
#мнение #рецепт
Управляем ли мы проектом на самом деле?
Здравствуй, дорогой читатель. Давненько я не писал ничего заумного. Этот пост будет довольно провокационным, потому что затрагивает святую вещь - оценку.
Он написан под впечатление от книги "Статистическое управление процессами. Чамберс, Уилер" , ГОСТ Р ИСО 11462 и ГОСТ Р 51814. (Да, госты хорошие действительно круто раскрывается SPC).
Давай рассмотрим всего 2 шкалы для оценки - абсолютную шкалу в днях и относительную в сторипойнтах.
Оценка в часах не рассматривается, так лично я считаю ее бессмысленной. Объясню почему - типичный рабочий день - 8 ч, из них пиковая продуктивность 6 часов 7 минут. У большинства есть рабочие митинги/встречи, вычтем еще 1 ч времени + 1 ч обеда. Итого по божески исполнитель может в пике выдать 4 часа в день.
Вспомним еще о том, что есть эффект потока и переключение контекста, то есть 4 часа при условии что от 10 до 35% из них на погружение в задачу и выход на плато эффективности. Это еще при условии что вы не выдернете из состояния потока "Привет Миша, посмотри срочную задачу". Поэтому я не понимаю, когда оценивают задачу в часах, из разряда 2 часа на Consumer в Kafka.
С оценкой в днях все понятно - добываем реальную оценку (параметр, эксперт, историчка, аналог, бенч) и закладываем сверху буфер. Как-нибудь отдельно напишу, почему "волшебные коэффициенты", вроде оценка от исполнитель * 3 не работают. Тут есть про это подводка.
Получили оценки в днях, сложили, длительность проекта понятна.
С относительной оценкой в SP или например t-shirt (размеры футболок) все веселее.
1) Начало отсчета шкалы гуляет туда-сюда, нужно постоянно менять относительную задачу в 1 SP;
2) Из-за п. 1 оценка волатильна, т. е. 30 SP сейчас ! = 30 SP 4 недели назад, спокойно может быть и не меньший объем работы за те же деньги;
3) Относительные оценки не всегда обладают аддитивность, т.е. суммировать сторипойнты не всегда возможно.
При чем здесь SPC? Все просто - процесс не управляем статистически, положение процесса в терминах среднего ар. и разброс в терминах среднеквадратичного отклонения неконтролируемо меняется. Наш процесс разработки и доставки ценности конечному юзеру прыгает туда - сюда.
Вопросы которыми я задаюсь на данный момент: имеет ли смысл оценка, если процесс гуляет? Зачем мы прогнозируем время выполнения, если мы даже не уверены, что у процесса есть нижняя и верхняя границы? Имеем ли мы право давать точные оценки, если процесс не устойчив во времени?
Понять это как раз и помогает SPC, через философию которого красной нитью проходит идея - для того чтобы прогнозировать выход процесса, нужно привести его в управляемое состояние. Подробно про это рассказывал Паша Ахметчанов тут .
Как понять что процесс неуправляем? Это особенно легко сделать пользователям Jira или Kaiten, там есть замечательный отчет Control Chart. Также можно построить классическую ККШ, как это сделать в excel описано тут.
Ниже картинка на подумать. Фильтрами выбраны задачи, которые были завершены за 3 месяца и которые оценили в S размере. S предполагает 1-2 дня на выполнение.
P.S. В посте нет утверждения, что какие-то шкалы оценки хуже или лучше. Ключевая идея - есть ли смысл в оценке?
P.P.S. Утверждения про переключение контекста и продуктивность относятся к нематериальному труду - айтишечке, на стройке скорее всего работать не будет.
Управляем ли мы проектом на самом деле?
Здравствуй, дорогой читатель. Давненько я не писал ничего заумного. Этот пост будет довольно провокационным, потому что затрагивает святую вещь - оценку.
Он написан под впечатление от книги "Статистическое управление процессами. Чамберс, Уилер" , ГОСТ Р ИСО 11462 и ГОСТ Р 51814. (Да, госты хорошие действительно круто раскрывается SPC).
Давай рассмотрим всего 2 шкалы для оценки - абсолютную шкалу в днях и относительную в сторипойнтах.
Оценка в часах не рассматривается, так лично я считаю ее бессмысленной. Объясню почему - типичный рабочий день - 8 ч, из них пиковая продуктивность 6 часов 7 минут. У большинства есть рабочие митинги/встречи, вычтем еще 1 ч времени + 1 ч обеда. Итого по божески исполнитель может в пике выдать 4 часа в день.
Вспомним еще о том, что есть эффект потока и переключение контекста, то есть 4 часа при условии что от 10 до 35% из них на погружение в задачу и выход на плато эффективности. Это еще при условии что вы не выдернете из состояния потока "Привет Миша, посмотри срочную задачу". Поэтому я не понимаю, когда оценивают задачу в часах, из разряда 2 часа на Consumer в Kafka.
С оценкой в днях все понятно - добываем реальную оценку (параметр, эксперт, историчка, аналог, бенч) и закладываем сверху буфер. Как-нибудь отдельно напишу, почему "волшебные коэффициенты", вроде оценка от исполнитель * 3 не работают. Тут есть про это подводка.
Получили оценки в днях, сложили, длительность проекта понятна.
С относительной оценкой в SP или например t-shirt (размеры футболок) все веселее.
1) Начало отсчета шкалы гуляет туда-сюда, нужно постоянно менять относительную задачу в 1 SP;
2) Из-за п. 1 оценка волатильна, т. е. 30 SP сейчас ! = 30 SP 4 недели назад, спокойно может быть и не меньший объем работы за те же деньги;
3) Относительные оценки не всегда обладают аддитивность, т.е. суммировать сторипойнты не всегда возможно.
При чем здесь SPC? Все просто - процесс не управляем статистически, положение процесса в терминах среднего ар. и разброс в терминах среднеквадратичного отклонения неконтролируемо меняется. Наш процесс разработки и доставки ценности конечному юзеру прыгает туда - сюда.
Вопросы которыми я задаюсь на данный момент: имеет ли смысл оценка, если процесс гуляет? Зачем мы прогнозируем время выполнения, если мы даже не уверены, что у процесса есть нижняя и верхняя границы? Имеем ли мы право давать точные оценки, если процесс не устойчив во времени?
Понять это как раз и помогает SPC, через философию которого красной нитью проходит идея - для того чтобы прогнозировать выход процесса, нужно привести его в управляемое состояние. Подробно про это рассказывал Паша Ахметчанов тут .
Как понять что процесс неуправляем? Это особенно легко сделать пользователям Jira или Kaiten, там есть замечательный отчет Control Chart. Также можно построить классическую ККШ, как это сделать в excel описано тут.
Ниже картинка на подумать. Фильтрами выбраны задачи, которые были завершены за 3 месяца и которые оценили в S размере. S предполагает 1-2 дня на выполнение.
P.S. В посте нет утверждения, что какие-то шкалы оценки хуже или лучше. Ключевая идея - есть ли смысл в оценке?
P.P.S. Утверждения про переключение контекста и продуктивность относятся к нематериальному труду - айтишечке, на стройке скорее всего работать не будет.
#рецепт
Поясни за проект
Пост навеяла публикация у Сергея Колганова (https://t.me/psilonsk/1294). Я тоже использую этот подход при собеседовании. Препятствие для соискателя простое - ответить что такое проект.
Я не жду конкретный ответ, а прошу ответить своими словами, мне интересно исключительно рассуждение и ход мыслей. Вот как объяснял бы бабушке, на пальцах.
Логика такая: если соискатель не понимает что такое проект, то как он должен сориентироваться когда и какие инструменты применять? Где проект то в его менеджменте.
Большинство путает проект с продуктом, процессом и услугой и часто не в тему используют проектные практики. Это чисто мой пунктик, как заметить пробел в понимании кандидата, а не в знаниях/теории.
При этом на мой взгляд определение из PMBoK не самое лучшее "временно́е предприятие, направленное на создание уникального продукта, услуги или результата". Используя его не отличить проект от просто рабочей деятельности или продукта.
У меня свое определение, частично утащенное у @selihovkin:
"Инициатива с высокой неопределенностью, направленная на достижение цели в соответствии с заданными ограничениями (обычно деньги и сроки)".
Ключевое здесь ограничения и неопределенность (про это тут говорил).
P.S. Я бы вообще слово инициатива заменил на "дельце", больше отдает духом проекта.
Поясни за проект
Пост навеяла публикация у Сергея Колганова (https://t.me/psilonsk/1294). Я тоже использую этот подход при собеседовании. Препятствие для соискателя простое - ответить что такое проект.
Я не жду конкретный ответ, а прошу ответить своими словами, мне интересно исключительно рассуждение и ход мыслей. Вот как объяснял бы бабушке, на пальцах.
Логика такая: если соискатель не понимает что такое проект, то как он должен сориентироваться когда и какие инструменты применять? Где проект то в его менеджменте.
Большинство путает проект с продуктом, процессом и услугой и часто не в тему используют проектные практики. Это чисто мой пунктик, как заметить пробел в понимании кандидата, а не в знаниях/теории.
При этом на мой взгляд определение из PMBoK не самое лучшее "временно́е предприятие, направленное на создание уникального продукта, услуги или результата". Используя его не отличить проект от просто рабочей деятельности или продукта.
У меня свое определение, частично утащенное у @selihovkin:
"Инициатива с высокой неопределенностью, направленная на достижение цели в соответствии с заданными ограничениями (обычно деньги и сроки)".
Ключевое здесь ограничения и неопределенность (про это тут говорил).
P.S. Я бы вообще слово инициатива заменил на "дельце", больше отдает духом проекта.
👍2
#perl
Мем с попугаем и кощеем это конечно хорошо. Но вот этот шедевр сегодня.
P.S. Не знаю чей труд. Не злорадства ради, просто смешно.
Мем с попугаем и кощеем это конечно хорошо. Но вот этот шедевр сегодня.
P.S. Не знаю чей труд. Не злорадства ради, просто смешно.
😁2
#полезности
Короткая презентация про процессы
Случайно набрел на просторах SlideShare на одну презентацию про управление процессами.
https://www.slideshare.net/ScrumTrek/it-73959521 . В целом если пробежитесь по ней, то поймете майндсет автора канала и набор областей знаний.
Просматривая ее перед глазами в целом проносится дорожная карта развития, но только в обратном направлении. Я начинал с изучения scrum и перехожу к логистике и организации производства.
На мой взгляд это один из лучших и коротких опусов на тему проблем организаций, особенно аутсорсеров. Ну и просто забавная работа для подъема настроения.
Короткая презентация про процессы
Случайно набрел на просторах SlideShare на одну презентацию про управление процессами.
https://www.slideshare.net/ScrumTrek/it-73959521 . В целом если пробежитесь по ней, то поймете майндсет автора канала и набор областей знаний.
Просматривая ее перед глазами в целом проносится дорожная карта развития, но только в обратном направлении. Я начинал с изучения scrum и перехожу к логистике и организации производства.
На мой взгляд это один из лучших и коротких опусов на тему проблем организаций, особенно аутсорсеров. Ну и просто забавная работа для подъема настроения.
SlideShare
Владимир Завертайлов. Выравнивание нагрузки в IT-компании: впихнуть невпихуемое.
Документ обсуждает различные методологии управления проектами, включая Lean, TOC, Scrum и Канбан, и их применение в контексте управления потоками работы и потока единичных изделий в IT. Основное внимание уделяется устранению узких мест в процессе, приоритезации…
#мнение
Целых 500 человек
Всегда забавляли посты блогеров в стиле "наберется N подписчиков и сделаем неведомую дичь". Тоже попробую так сделать.
Я не буду делать розыгрышей или благодарственных постов, ведь, читатель, ты здесь не за этим. Просто приведу к пятнице в опрятный вид подборку книг и выложу файлы. Пусть будет совершено бесплатная подборка книг по проектному управлению. Надеюсь она будет самой большой и полезной в рунете.
P. S. Меня до сих пор несколько удивляет, что кто-то читает мысли начинающего руководителя проектов, джуна.
Целых 500 человек
Всегда забавляли посты блогеров в стиле "наберется N подписчиков и сделаем неведомую дичь". Тоже попробую так сделать.
Я не буду делать розыгрышей или благодарственных постов, ведь, читатель, ты здесь не за этим. Просто приведу к пятнице в опрятный вид подборку книг и выложу файлы. Пусть будет совершено бесплатная подборка книг по проектному управлению. Надеюсь она будет самой большой и полезной в рунете.
P. S. Меня до сих пор несколько удивляет, что кто-то читает мысли начинающего руководителя проектов, джуна.