#рецепт
Проджекты хотят быть продактами
Сейчас есть мода на то, что руководители проектов не нужны. Давно уже идет массовых исход в продакты.
Сильный коллега (в плане скилза)
в чате @pmi_ru высказал ряд предложений как с этим быть:
1. Если люди не хотят вести проект, то их не удержишь, надо тюнить настройки стратегии проектного офиса. Это странно, когда РП не хочет вести проект. РП должен любить свое ремесло, это baseline;
2. Если РП сильнее продактов (обыгрывают по всем дисциплинам), то это вопрос позиционирования роли РП в команде и договоренностей с руководителем подразделения продактов (и самими продактами). Грамотный РП должен быть готов быть №2 в команде;
3. Надо накинуть кэш и сократить дистанцию в доходах между продактом и проджектом. Полступени между ролями должны быть и в деньгах полступенью;
4. Вести пропаганду, что первые без вторых, как машина без двигателя;
5. Продакт и проджект должны минимум 1 раз в неделю встречаться вдвоем и обсуждать задачи друг друга. Оба на равных обсуждать проблемы и задачи. Second opinion - важная часть движения вперед при реализации;
6. Требовать от РП цитирую дословно: "умение говорить с людьми, умение слушать и слышать их, умение найти ZOPA (zone of possible agreement) всех сторон и сделать так, чтоб люди приходили к нужным умозаключениям исключительно самостоятельно. Т.е. так, чтоб им казалось, что они сами это придумали, а значит безгранично верили в это. Ну а фактически это твоих тончайших манипуляций работа", т.е. РП должен заземлять продакта в процессе производства ИТ решения. Ученик не превзойдет учителя, если видит в нем образец, а не соперника;
7. Нанимать продактов с участием руководителя проектного офиса с правом принятия решения о найме кандидата;
8. При непреодолимом желании перехода на позицию PO/PdM проработать программу трансфера с прохождением квалификационного экзамена. Переход должен быть закреплен испытательным сроком и апгрейдом ЗП после его прохождения.
Текст Евгения @Eugean1980
Проджекты хотят быть продактами
Сейчас есть мода на то, что руководители проектов не нужны. Давно уже идет массовых исход в продакты.
Сильный коллега (в плане скилза)
в чате @pmi_ru высказал ряд предложений как с этим быть:
1. Если люди не хотят вести проект, то их не удержишь, надо тюнить настройки стратегии проектного офиса. Это странно, когда РП не хочет вести проект. РП должен любить свое ремесло, это baseline;
2. Если РП сильнее продактов (обыгрывают по всем дисциплинам), то это вопрос позиционирования роли РП в команде и договоренностей с руководителем подразделения продактов (и самими продактами). Грамотный РП должен быть готов быть №2 в команде;
3. Надо накинуть кэш и сократить дистанцию в доходах между продактом и проджектом. Полступени между ролями должны быть и в деньгах полступенью;
4. Вести пропаганду, что первые без вторых, как машина без двигателя;
5. Продакт и проджект должны минимум 1 раз в неделю встречаться вдвоем и обсуждать задачи друг друга. Оба на равных обсуждать проблемы и задачи. Second opinion - важная часть движения вперед при реализации;
6. Требовать от РП цитирую дословно: "умение говорить с людьми, умение слушать и слышать их, умение найти ZOPA (zone of possible agreement) всех сторон и сделать так, чтоб люди приходили к нужным умозаключениям исключительно самостоятельно. Т.е. так, чтоб им казалось, что они сами это придумали, а значит безгранично верили в это. Ну а фактически это твоих тончайших манипуляций работа", т.е. РП должен заземлять продакта в процессе производства ИТ решения. Ученик не превзойдет учителя, если видит в нем образец, а не соперника;
7. Нанимать продактов с участием руководителя проектного офиса с правом принятия решения о найме кандидата;
8. При непреодолимом желании перехода на позицию PO/PdM проработать программу трансфера с прохождением квалификационного экзамена. Переход должен быть закреплен испытательным сроком и апгрейдом ЗП после его прохождения.
Текст Евгения @Eugean1980
#почтовый_ящик
Ленивый менеджер
Дорогой читатель, как ты заметил последний действительно авторский пост выходил с месяц назад. Это связано с простой вещью - я не могу придумать тему. Вернее даже не придумать, а выбрать, так как поведать есть что.
Поэтому запускаю новый формат - почтовый ящик. Как это будет работать?
1) Напиши мне в личные сообщения интересующий тебя вопрос (ссылка в описании);
2) Я дам развернутый ответ в виде структурированного поста для развернутого ответа;
3) Появится отдельная ветка постов помеченных тегом #почтовый_ящик. Выходить они будут раз в неделю.
P.S. Я понимаю что формат не нов и содержит толику жеманности. Но у меня сейчас немного не хватает ресурса на полноценный блог, да и новый цикл Даннинга-Крюгера начался.
Ленивый менеджер
Дорогой читатель, как ты заметил последний действительно авторский пост выходил с месяц назад. Это связано с простой вещью - я не могу придумать тему. Вернее даже не придумать, а выбрать, так как поведать есть что.
Поэтому запускаю новый формат - почтовый ящик. Как это будет работать?
1) Напиши мне в личные сообщения интересующий тебя вопрос (ссылка в описании);
2) Я дам развернутый ответ в виде структурированного поста для развернутого ответа;
3) Появится отдельная ветка постов помеченных тегом #почтовый_ящик. Выходить они будут раз в неделю.
P.S. Я понимаю что формат не нов и содержит толику жеманности. Но у меня сейчас немного не хватает ресурса на полноценный блог, да и новый цикл Даннинга-Крюгера начался.
#мнение
Ретро не работает
Дорогой читатель, этот пост точно заставит тебя негодовать если ты не дочитаешь его до конца.
На своем опыте после практики 1.5 года такого механизма использования обратной связи как ретроспектива (не путать с ретро-анализом и пост-мортем) могу сказать что это один из самых трудоемких и опасных инструментов для любого менеджера.
Почему он опасен?
Ретроспектива убивает доверие к менеджеру/любому лицу, кто имплементирует "ретру". Также бонусом убивает доверие между членами команды. У этого есть 3 причины:
1) Участники не слышат друг друга. Обсуждаются не действительно важные вещи для команды, а индивидуально важные. Либо вообще просто идеации. Действия с ретро уходят в никуда и на следующей встрече вы анализируете выполнение того, что было не нужно.
Вам дарили, то, что вы терпеть не можете? Потому что вас не поняли или забыли про это?
Вот такие же впечатления у участников;
2) Участники не выполняют обещания. Раскрыли душу, обсудили насущные точки роста (проблемы/достижения), потратили на это время и запланировали изменения. К следующей встрече планы были не выполнены.
Конфликтовали с партнером из-за какой-то проблемы в отношениях? Разбирали проблему и договаривались как почините? А потом видели что на проблему забили и ничего не поменялось?
Схожие ощущения у участников;
3) Ретроспектива не к месту. Кто-то, у кого низкий уровень понимания вашего контекста или к кому у вас нет доверия и уважения пришел к вам и начал утверждать, что вы должны честно ему рассказать о ваших проблемах, чтобы их решить. И тут не понятно, почему участники должны: довериться что время будет потрачено не в пустую, довериться и рассказать о проблемах, довериться что проблемы будут решены.
Снова аналогия с отношениями. Вы только познакомились (или знакомы давно, но не очень близко), а партнер уже завет в постель.
Почему он трудоемкий?
Механизм ретроспективы требует не только выделения времени на саму встречу от открытия до закрытия. Также "ретра" требует выделения времени на:
1) Подготовку фасилитатора к встрече. Нужно применить фидбек по процессу организации самой встречи, обновить визуализацию, пройтись по сценарию, подумать как не дать скучать участникам (например, новый айсбрекер?), поднять статус экшен-планов и т.д.;
2) Подготовку участников (по хорошему). В некоторых случаях хорошо дать участникам подумать заранее над информацией, которой им хотелось бы поделиться. Причины у этого могут быть индивидуальны, от того что кто-то не умеет понятно выражать своим мысли, до того что кто-то не понимает себя или вообще вы с командой дошли до уровня тотального доверия, поэтому можно темы для обсуждения заранее написать;
3) Выполнение экшен-планов. Придумать идеи по улучшениям и сложить их в беклог дело благое, но бесполезное. Эти действия нужно выполнить к следующей "ретре". Тут легко упереться в ту же проблему, что и с техдолгом. Стейкхолдеры не видят в этом ценности, команда перегружена, времени на это нет;
4) Визуальные игры. Кроме самой собственно встречи и простого общения на человеческом языке есть вспомогательные инструменты - стикеры, визуализации вроде корабля и т.д. Легко от решения проблем уйти в "красивый и интересный" воркшоп;
5) Управление выполнением экшен-айтемов. Чтобы выполнить эти задачи с "ретры", нужно ведь также их спланировать. И тут все сложнее чем кажется. Приоритет у них чаще всего низкий, делаем по остаточному принципу. А еще задачи небольшие, поэтому переключаемся на них между делом.
Ты наверняка задался вопросом, зачем ты прочитал это?
Поясню - чтобы увидеть точки роста. Этот текст и есть своеобразная ретроспектива автора, он сам совершал эти ошибки и ломал ретроспективу.
Каждый из 8 пунктов это узкий момент, который легко превращается в проблему ведет к тому что ретро не работает.
Главный месседж - топливо ретро это доверие, без него это просто бесполезная формальная встреча.
Ретро не работает
Дорогой читатель, этот пост точно заставит тебя негодовать если ты не дочитаешь его до конца.
На своем опыте после практики 1.5 года такого механизма использования обратной связи как ретроспектива (не путать с ретро-анализом и пост-мортем) могу сказать что это один из самых трудоемких и опасных инструментов для любого менеджера.
Почему он опасен?
Ретроспектива убивает доверие к менеджеру/любому лицу, кто имплементирует "ретру". Также бонусом убивает доверие между членами команды. У этого есть 3 причины:
1) Участники не слышат друг друга. Обсуждаются не действительно важные вещи для команды, а индивидуально важные. Либо вообще просто идеации. Действия с ретро уходят в никуда и на следующей встрече вы анализируете выполнение того, что было не нужно.
Вам дарили, то, что вы терпеть не можете? Потому что вас не поняли или забыли про это?
Вот такие же впечатления у участников;
2) Участники не выполняют обещания. Раскрыли душу, обсудили насущные точки роста (проблемы/достижения), потратили на это время и запланировали изменения. К следующей встрече планы были не выполнены.
Конфликтовали с партнером из-за какой-то проблемы в отношениях? Разбирали проблему и договаривались как почините? А потом видели что на проблему забили и ничего не поменялось?
Схожие ощущения у участников;
3) Ретроспектива не к месту. Кто-то, у кого низкий уровень понимания вашего контекста или к кому у вас нет доверия и уважения пришел к вам и начал утверждать, что вы должны честно ему рассказать о ваших проблемах, чтобы их решить. И тут не понятно, почему участники должны: довериться что время будет потрачено не в пустую, довериться и рассказать о проблемах, довериться что проблемы будут решены.
Снова аналогия с отношениями. Вы только познакомились (или знакомы давно, но не очень близко), а партнер уже завет в постель.
Почему он трудоемкий?
Механизм ретроспективы требует не только выделения времени на саму встречу от открытия до закрытия. Также "ретра" требует выделения времени на:
1) Подготовку фасилитатора к встрече. Нужно применить фидбек по процессу организации самой встречи, обновить визуализацию, пройтись по сценарию, подумать как не дать скучать участникам (например, новый айсбрекер?), поднять статус экшен-планов и т.д.;
2) Подготовку участников (по хорошему). В некоторых случаях хорошо дать участникам подумать заранее над информацией, которой им хотелось бы поделиться. Причины у этого могут быть индивидуальны, от того что кто-то не умеет понятно выражать своим мысли, до того что кто-то не понимает себя или вообще вы с командой дошли до уровня тотального доверия, поэтому можно темы для обсуждения заранее написать;
3) Выполнение экшен-планов. Придумать идеи по улучшениям и сложить их в беклог дело благое, но бесполезное. Эти действия нужно выполнить к следующей "ретре". Тут легко упереться в ту же проблему, что и с техдолгом. Стейкхолдеры не видят в этом ценности, команда перегружена, времени на это нет;
4) Визуальные игры. Кроме самой собственно встречи и простого общения на человеческом языке есть вспомогательные инструменты - стикеры, визуализации вроде корабля и т.д. Легко от решения проблем уйти в "красивый и интересный" воркшоп;
5) Управление выполнением экшен-айтемов. Чтобы выполнить эти задачи с "ретры", нужно ведь также их спланировать. И тут все сложнее чем кажется. Приоритет у них чаще всего низкий, делаем по остаточному принципу. А еще задачи небольшие, поэтому переключаемся на них между делом.
Ты наверняка задался вопросом, зачем ты прочитал это?
Поясню - чтобы увидеть точки роста. Этот текст и есть своеобразная ретроспектива автора, он сам совершал эти ошибки и ломал ретроспективу.
Каждый из 8 пунктов это узкий момент, который легко превращается в проблему ведет к тому что ретро не работает.
Главный месседж - топливо ретро это доверие, без него это просто бесполезная формальная встреча.
#почтовый_ящик
Как повлиять ПМу у субподрядчика на ПМа заказчика, если 2 довольно мягкий и прогибается под любое мнение?
Довольно интересный кейс. Я в нем уже бывал, причем опыт был именно с ГОС проектом.
Я рекомендую использовать две вещи:
1) Механизм обратной связи. Есть всем известные 1-1 и типовые правила их проведения . Разумеется их можно применять не только для своих сотрудников.
Стоит завести первую встречу и в ней обсудить с фактами и отрешенностью от личности "пластичность" принятия решений и влияние 3 лиц. Разобрать конкретные случаи и описать ваш взгляд (как субподрядчика) о негативном влиянии принятых решений на цели проекта и критерии его достижимости. Я подобное переносил в полностью объективную плоскость и обсуждал с ПМом заказчика именно влияние на проект, а не на меня самого или мою компанию.
Тут есть одно большое НО, Это работает только если:
а) Целью вашего проекта является достижение цели проекта для заказчика. На самом деле у вас 2 разных проекта, один у ПМа подрядчика и другой у ПМа заказчика. Вполне возможна ситуация, когда они не подразумевают взаимного выполнения друг друга. Или вообще исключают. Такое особенно часто случается в аусторсе.
б) Проект важен ПМу заказчика и он разделяет цель проекта. Вполне может быть что проект ему не важен и это все объясняет.
2) Ченж реквести как интрига. Почему интрига - строится мини-заговор. Каждый раз когда происходит запрос на значительные изменения вы собираете встречу на двоих с ПМом заказчика и обсуждаете влияние на проект. Одна голова хорошо, а две лучше. Учитываются интересы обеих команд, обе цели и самое главное вы подставляете плечо коллеге и выстраиваете доверительные отношения.
Тут тоже есть одно большое НО, ПМ заказчика должен видеть в вас коллегу и доверять вам.
Так как же быть? А довольно просто:
1) Выясняете реальную цель своего проекта и реальную цель проекта заказчика;
2) Выясняете отношение ПМа заказчика к себе;
3) Строите доверительные или хотя бы уважительные отношения с ПМом заказчика;
4) Выбираете один из 2 инструментов: 1-1 или интригу;
5) PROFIT.
P.S. Если вы считаете, что такой вопрос решается по другому, то всегда можете написать об этом в комментарии.
Как повлиять ПМу у субподрядчика на ПМа заказчика, если 2 довольно мягкий и прогибается под любое мнение?
Довольно интересный кейс. Я в нем уже бывал, причем опыт был именно с ГОС проектом.
Я рекомендую использовать две вещи:
1) Механизм обратной связи. Есть всем известные 1-1 и типовые правила их проведения . Разумеется их можно применять не только для своих сотрудников.
Стоит завести первую встречу и в ней обсудить с фактами и отрешенностью от личности "пластичность" принятия решений и влияние 3 лиц. Разобрать конкретные случаи и описать ваш взгляд (как субподрядчика) о негативном влиянии принятых решений на цели проекта и критерии его достижимости. Я подобное переносил в полностью объективную плоскость и обсуждал с ПМом заказчика именно влияние на проект, а не на меня самого или мою компанию.
Тут есть одно большое НО, Это работает только если:
а) Целью вашего проекта является достижение цели проекта для заказчика. На самом деле у вас 2 разных проекта, один у ПМа подрядчика и другой у ПМа заказчика. Вполне возможна ситуация, когда они не подразумевают взаимного выполнения друг друга. Или вообще исключают. Такое особенно часто случается в аусторсе.
б) Проект важен ПМу заказчика и он разделяет цель проекта. Вполне может быть что проект ему не важен и это все объясняет.
2) Ченж реквести как интрига. Почему интрига - строится мини-заговор. Каждый раз когда происходит запрос на значительные изменения вы собираете встречу на двоих с ПМом заказчика и обсуждаете влияние на проект. Одна голова хорошо, а две лучше. Учитываются интересы обеих команд, обе цели и самое главное вы подставляете плечо коллеге и выстраиваете доверительные отношения.
Тут тоже есть одно большое НО, ПМ заказчика должен видеть в вас коллегу и доверять вам.
Так как же быть? А довольно просто:
1) Выясняете реальную цель своего проекта и реальную цель проекта заказчика;
2) Выясняете отношение ПМа заказчика к себе;
3) Строите доверительные или хотя бы уважительные отношения с ПМом заказчика;
4) Выбираете один из 2 инструментов: 1-1 или интригу;
5) PROFIT.
P.S. Если вы считаете, что такой вопрос решается по другому, то всегда можете написать об этом в комментарии.
#рецепт
Как стать IT PM вообще с нуля?
Дорогой читатель, это пост полон очень-очень субъективного мнения. Если ты с ним не согласен, то дай мне пожалуйста обратную связь об этом в комментариях, она будет для меня очень ценной.
Состоя в довольно большом количестве сообществ я заметил, что один вопрос мелькает с завидной регулярностью. "Как стать ПМом в IT с нуля?".
Ниже приведен небольшой алгоритм, который гарантированно поможет стать руководителем проектов за 6 месяцев бесплатно. Единственное что потребуется большая сила воли.
Чтобы стать ПМом нужно:
1) Подумать, почему вам все таки интересна эта область/домен, например IT. Узнать какие в ней есть поддомены. Ресерч проекты с ML и разработка CRM отличаются колоссально;
2) Если все таки выбрано IT, то узнать какие есть роли и специальности. Разобраться в том, какие типовые роли и специальности есть в IT, узнать их смысл (для чего они), области знаний и инструменты они используют. Составить для себя в голове понимание специфики каждого конкретного направления, от QA и до администратора баз данных;
3) Понять для себя: "а что мне интересно?". Только после того как появится критическая масса информации, можно принимать какие-то решения. И тут просто надо сматчить 2 вещи: "мне хочется X" и "специальность Y, которая может это закрыть";
Остановка
Зачем вообще пункты 1-3? Очень часто начинающие выбирают ПМ даже не разобравшись что это и идут потому что модно. Получается нелогичная ситуация, похожая на профориентацию в 11 классе. Я ничего не знаю про наноматериалы, но иду учиться на это направление. Часто тут появляется потеря мотивации.
4) В пункте 3 был выбран руководитель проектов. Выбрать специализацию для старта, чтобы получить необходимый опыт контекста. У вас уже появилось знания о специальностях в IT. Нужно выбрать на первое время ту, в которую порог входа проще всего для вас и устроится на работу;
5) Устроившись на работу по максимуму погружаться в контекст и потихоньку брать на себя инициативу;
6) После появления некоторого количества инициативы (например, пришли тестировщиком, но помогаете писать ТЗ проджекту) начать брать на себя принятие решений по этой инициативе, а следом уже и ответственность за принятые решения;
7) Качать теорию проектного управления. Для этого хорошо подойдет бесплатный курс PM 101 или книга Вани Селиховкина;
8) Поняв вершки теории проектного управления применять на практике в своей работе. Найти в своей рабочей деятельности проект и добиться роли его руководителя. Если такого нет, придумать его и создать. Например, устроились тестировщиком, возьмите проект по автоматизации тестирования или внедрению практик нагрузочного тестирования;
9) Начать поиск вакансии руководителя проектов. Тут 2 пути:
а) Пойти к руководителю в своей текущей компании и сказать о том, что вы хотите быть РП и доказать на фактах что вы уже получили такой опыт;
б) Пройти в другую организацию и устроится там с нуля РП.
Я сам прошел такой путь и множество моих коллег. При должной силе воли и мотивации этот путь можно пройти за пол-года.. Все в ваших руках. Развивайтесь!
Как стать IT PM вообще с нуля?
Дорогой читатель, это пост полон очень-очень субъективного мнения. Если ты с ним не согласен, то дай мне пожалуйста обратную связь об этом в комментариях, она будет для меня очень ценной.
Состоя в довольно большом количестве сообществ я заметил, что один вопрос мелькает с завидной регулярностью. "Как стать ПМом в IT с нуля?".
Ниже приведен небольшой алгоритм, который гарантированно поможет стать руководителем проектов за 6 месяцев бесплатно. Единственное что потребуется большая сила воли.
Чтобы стать ПМом нужно:
1) Подумать, почему вам все таки интересна эта область/домен, например IT. Узнать какие в ней есть поддомены. Ресерч проекты с ML и разработка CRM отличаются колоссально;
2) Если все таки выбрано IT, то узнать какие есть роли и специальности. Разобраться в том, какие типовые роли и специальности есть в IT, узнать их смысл (для чего они), области знаний и инструменты они используют. Составить для себя в голове понимание специфики каждого конкретного направления, от QA и до администратора баз данных;
3) Понять для себя: "а что мне интересно?". Только после того как появится критическая масса информации, можно принимать какие-то решения. И тут просто надо сматчить 2 вещи: "мне хочется X" и "специальность Y, которая может это закрыть";
Остановка
Зачем вообще пункты 1-3? Очень часто начинающие выбирают ПМ даже не разобравшись что это и идут потому что модно. Получается нелогичная ситуация, похожая на профориентацию в 11 классе. Я ничего не знаю про наноматериалы, но иду учиться на это направление. Часто тут появляется потеря мотивации.
4) В пункте 3 был выбран руководитель проектов. Выбрать специализацию для старта, чтобы получить необходимый опыт контекста. У вас уже появилось знания о специальностях в IT. Нужно выбрать на первое время ту, в которую порог входа проще всего для вас и устроится на работу;
5) Устроившись на работу по максимуму погружаться в контекст и потихоньку брать на себя инициативу;
6) После появления некоторого количества инициативы (например, пришли тестировщиком, но помогаете писать ТЗ проджекту) начать брать на себя принятие решений по этой инициативе, а следом уже и ответственность за принятые решения;
7) Качать теорию проектного управления. Для этого хорошо подойдет бесплатный курс PM 101 или книга Вани Селиховкина;
8) Поняв вершки теории проектного управления применять на практике в своей работе. Найти в своей рабочей деятельности проект и добиться роли его руководителя. Если такого нет, придумать его и создать. Например, устроились тестировщиком, возьмите проект по автоматизации тестирования или внедрению практик нагрузочного тестирования;
9) Начать поиск вакансии руководителя проектов. Тут 2 пути:
а) Пойти к руководителю в своей текущей компании и сказать о том, что вы хотите быть РП и доказать на фактах что вы уже получили такой опыт;
б) Пройти в другую организацию и устроится там с нуля РП.
Я сам прошел такой путь и множество моих коллег. При должной силе воли и мотивации этот путь можно пройти за пол-года.. Все в ваших руках. Развивайтесь!
#полезности
Хороший канал с авторским
Коллега ведёт очень приятный канал https://t.me/how_to_be_a_pm
Юля как ПМ с декабря 2020 года, разрабатывает образовательные продукты (сейчас в основном для школьников, но есть и для взрослых).
Пишет в основном про мотивацию: собственную, команды, построение мотивационной поддержки у обучающихся (на примере крупной торговой сети).
Также публично анализирует свой опыт, рассказывает о книгах и курсах, которые встречаю: что хорошо, что не очень, много внимания уделяет навыку коммуникации.
Настоятельно рекомендую почитать её посты, особенно https://t.me/how_to_be_a_pm/5
Хороший канал с авторским
Коллега ведёт очень приятный канал https://t.me/how_to_be_a_pm
Юля как ПМ с декабря 2020 года, разрабатывает образовательные продукты (сейчас в основном для школьников, но есть и для взрослых).
Пишет в основном про мотивацию: собственную, команды, построение мотивационной поддержки у обучающихся (на примере крупной торговой сети).
Также публично анализирует свой опыт, рассказывает о книгах и курсах, которые встречаю: что хорошо, что не очень, много внимания уделяет навыку коммуникации.
Настоятельно рекомендую почитать её посты, особенно https://t.me/how_to_be_a_pm/5
#мнение
Методология не методология?)
Здравствуй, дорогой читатель. Это будет крамольный пост. Надеюсь он заставит тебя порефлексировать. Никакой фрустрации!
Давай сперва начнем с простого вопроса. Какие ты знаешь методологии управления проектами?
Сразу хочется выдать стандартный перечень вроде "Waterfall, Scrum, Agile, Kanban, PMBOK, Prince2 и т.д." Но давай разберемся.
Waterfall - это нарицательное, которое ввел У. Ройс для обозначения предиктивного жизненного цикла разработки ПО. Получается waterfall это просто SDLC.
Scrum - фреймворк управления разработкой продукта.
Agile - набор ценностей и принципов, мировоззрение или философия.
Kanban - метод выявления, управления и развития сервисами нематериального производства.
PMBOK - свод знаний по управлению проектами.
Prince2 - метод по управлению проектами.
Этот список можно продолжать довольно далеко, но я уверен с 75% что ни одной методологии в вашем перечне окажется. Как так? Почему тогда во всех вакансиях пишут "знания методологий". В сердцах хочется воскликнуть, "Да что такое эта ваша методология?"
Давай так и сделаем, заодно разберемся. Похожий вопрос появился в одном чате, привожу ссылку на старт треда https://t.me/kanban_talks/39680
Методика - это конкретное инженерное решение, это делай раз, делай два, делай три - профит. Способ применения чего-то определенного и описанного четко.
Аналогия - чертеж табуретки.
Фрейморк - это структура из конкретных методик, логический способ классифицировать, сегментировать, классифицировать или поддерживать что-либо.
Аналогия - описанная процедура изготовления табуретки, где используется чертеж, пила и т.д.
Метод - это методика придумывания методик - это уровень чуть выше. Это способ придумывания способов решения проблем.
Аналогия - ящик с инструментами, с помощью которого можно сделать как табуретку, так и доску для серфинга.
Методология - это наука, это способ создания методов - еще более высокий уровень абстракции. Совокупность знаний из различных областей, которая позволяет придумывать методы и все иже с ним.
Аналогия - столярное дело. Знания о том, как применять ящики с инструментами, наполнять их, придумывать новые.
P.S. А теперь вернись к первому вопросу. Так что же у нас есть из методологий в арсенале?
Методология не методология?)
Здравствуй, дорогой читатель. Это будет крамольный пост. Надеюсь он заставит тебя порефлексировать. Никакой фрустрации!
Давай сперва начнем с простого вопроса. Какие ты знаешь методологии управления проектами?
Сразу хочется выдать стандартный перечень вроде "Waterfall, Scrum, Agile, Kanban, PMBOK, Prince2 и т.д." Но давай разберемся.
Waterfall - это нарицательное, которое ввел У. Ройс для обозначения предиктивного жизненного цикла разработки ПО. Получается waterfall это просто SDLC.
Scrum - фреймворк управления разработкой продукта.
Agile - набор ценностей и принципов, мировоззрение или философия.
Kanban - метод выявления, управления и развития сервисами нематериального производства.
PMBOK - свод знаний по управлению проектами.
Prince2 - метод по управлению проектами.
Этот список можно продолжать довольно далеко, но я уверен с 75% что ни одной методологии в вашем перечне окажется. Как так? Почему тогда во всех вакансиях пишут "знания методологий". В сердцах хочется воскликнуть, "Да что такое эта ваша методология?"
Давай так и сделаем, заодно разберемся. Похожий вопрос появился в одном чате, привожу ссылку на старт треда https://t.me/kanban_talks/39680
Методика - это конкретное инженерное решение, это делай раз, делай два, делай три - профит. Способ применения чего-то определенного и описанного четко.
Аналогия - чертеж табуретки.
Фрейморк - это структура из конкретных методик, логический способ классифицировать, сегментировать, классифицировать или поддерживать что-либо.
Аналогия - описанная процедура изготовления табуретки, где используется чертеж, пила и т.д.
Метод - это методика придумывания методик - это уровень чуть выше. Это способ придумывания способов решения проблем.
Аналогия - ящик с инструментами, с помощью которого можно сделать как табуретку, так и доску для серфинга.
Методология - это наука, это способ создания методов - еще более высокий уровень абстракции. Совокупность знаний из различных областей, которая позволяет придумывать методы и все иже с ним.
Аналогия - столярное дело. Знания о том, как применять ящики с инструментами, наполнять их, придумывать новые.
P.S. А теперь вернись к первому вопросу. Так что же у нас есть из методологий в арсенале?
👍1
#полезности
Обзор PMBOK 7
Святой Селиховкин сделал обзор нового гайда. Уверен, видео будет интересно и полезно руководителям проектов, которые очень хотят узнать что же изменилось и насколько перевернулся мир с новым изданием.
P.S. Ваню я так называю за глаза, за качество материалов и вклад в популяризацию проектного управления.
Обзор PMBOK 7
Святой Селиховкин сделал обзор нового гайда. Уверен, видео будет интересно и полезно руководителям проектов, которые очень хотят узнать что же изменилось и насколько перевернулся мир с новым изданием.
P.S. Ваню я так называю за глаза, за качество материалов и вклад в популяризацию проектного управления.
Forwarded from Селиховкин - не скучно о проектах
Экспресс-обзор PMBoK7:
- Предыдущая версия vs новая (и почему PMBoK 6 не устарел)
- Кратко о PMBoK 7: 12 принципах и 8 доменах - как я на них смотрю и как проще запомнить новую структуру?
- Тем кто планировал сдавать экзамен PMP - на что ориентироваться, нужно ли переучиваться?
1 час 35 минут: https://youtu.be/Y5oDQAYpWjI
- Предыдущая версия vs новая (и почему PMBoK 6 не устарел)
- Кратко о PMBoK 7: 12 принципах и 8 доменах - как я на них смотрю и как проще запомнить новую структуру?
- Тем кто планировал сдавать экзамен PMP - на что ориентироваться, нужно ли переучиваться?
1 час 35 минут: https://youtu.be/Y5oDQAYpWjI
#полезности
Полезные каналы и группы. Расширение
Это не продолжение, а именно развитие поста, что выкладывал ранее.
Телеграм давно стал больше чем мессенджером. В нем бурной жизнью живут множество экосистем различных комьюнити. Не является исключением комьюнити ПМов и ежели с ним. Прилагаю список групп и занятных каналов, откуда можно черпать знания, вдохновения и друзей:
Сообщества:
@agile_ru - Можно узнать как правильно имплементировать скрам и почему lean не до конца работает в IT;
@BA_PO_PM_PdM - сидят суровые менеджеры и аналитики, которые расскажут за кровавый энтерпрайз;
@kanban_talks - чат практиков канбан-метода, помогают и разъясняют;
@PM_lunch - сообщество менеджеров проектов преимущественно из СПб, регулярно собираются оффлайн и кушают еду;
@spbspm - более "серьезное" сообщество менеджеров IT проектов из СПб, проводящее регулярные мини-митапы
@pmin_ru - приверженцы PMBOK и акулы календарно-сетевого планирования;
@ru_scrum - сообщество скрам-мастеров и практиков скрама. Хейтерам не заходить;
@FrancisBaconClub - сообщество IT-шников про теорию систем, психология, теория вариаций и прочие жуткие вещи. Новичкам не рекомендуется;
@technicalexcellenceru - uруппа практиков инженерных навыков: TDD, Pair Programming, CI/CD, DevOps
@TeamLeadTalks - чат сообщества тимлидов с суровой культурой, не для слабонервных;
@OgileKambanScram - группа для разбора и объяснения неправильных статей и видео про agile и около него;
@pmclubvrn - клуб проектного управления преимущественно из Воронежа;
@Scrum_Community - сообщество скрам-мастеров вокруг Раффайзена.
Статьи:
@psilonsk
@pm_god
@managerjournal
@selihovkin
@pmdaily
@borisbutton
@beardpm
@ravingrabbid
@sn_hack
@how_to_be_a_pm
@pmclub
@myscrum
События:
@PM_Events
@agile_events
@it_drinkups
@kanban_events
@product_events
@agile_ru_webinars
Полезные каналы и группы. Расширение
Это не продолжение, а именно развитие поста, что выкладывал ранее.
Телеграм давно стал больше чем мессенджером. В нем бурной жизнью живут множество экосистем различных комьюнити. Не является исключением комьюнити ПМов и ежели с ним. Прилагаю список групп и занятных каналов, откуда можно черпать знания, вдохновения и друзей:
Сообщества:
@agile_ru - Можно узнать как правильно имплементировать скрам и почему lean не до конца работает в IT;
@BA_PO_PM_PdM - сидят суровые менеджеры и аналитики, которые расскажут за кровавый энтерпрайз;
@kanban_talks - чат практиков канбан-метода, помогают и разъясняют;
@PM_lunch - сообщество менеджеров проектов преимущественно из СПб, регулярно собираются оффлайн и кушают еду;
@spbspm - более "серьезное" сообщество менеджеров IT проектов из СПб, проводящее регулярные мини-митапы
@pmin_ru - приверженцы PMBOK и акулы календарно-сетевого планирования;
@ru_scrum - сообщество скрам-мастеров и практиков скрама. Хейтерам не заходить;
@FrancisBaconClub - сообщество IT-шников про теорию систем, психология, теория вариаций и прочие жуткие вещи. Новичкам не рекомендуется;
@technicalexcellenceru - uруппа практиков инженерных навыков: TDD, Pair Programming, CI/CD, DevOps
@TeamLeadTalks - чат сообщества тимлидов с суровой культурой, не для слабонервных;
@OgileKambanScram - группа для разбора и объяснения неправильных статей и видео про agile и около него;
@pmclubvrn - клуб проектного управления преимущественно из Воронежа;
@Scrum_Community - сообщество скрам-мастеров вокруг Раффайзена.
Статьи:
@psilonsk
@pm_god
@managerjournal
@selihovkin
@pmdaily
@borisbutton
@beardpm
@ravingrabbid
@sn_hack
@how_to_be_a_pm
@pmclub
@myscrum
События:
@PM_Events
@agile_events
@it_drinkups
@kanban_events
@product_events
@agile_ru_webinars
Канал временно на паузе на неделю, идет квартальное планирование и чувствую себя Грейджоем "То что мертво умереть не может".
#полезности
Занятная конфа от Тинькофф
22 октября приглашаем на Tinkoff Agile Conference. Обсудим лидерство, командообразование, инженерные подходы и практики управления. Тема этого года — «Масштабирование изменений от команд до организации».
Эксперты отрасли и agile-тренеры расскажут о менеджменте инноваций, инженерных подходах, практическом опыте построения компаний. Всего — 16 докладов от спикеров из Авито, Альфа-Банка, Тинькофф, Циана, Scrumtrek и других компаний. Будут воркшопы и, разумеется, афтепати.
Онлайн-трансляция главного зала бесплатна для всех, нужна только регистрация. Участие в конференции офлайн в Москве — пожертвование 2000 ₽ в Фонд борьбы с лейкемией. Регистрируйтесь и переходите по ссылке для оплаты в ответном письме. Очное участие возможно только с QR-кодом.
Подробная программа и регистрация по ссылке: https://v.tinkoff.ru/tac2021
P.S. Нет не продался, это дружественная реклама, организует ее знакомый.
Занятная конфа от Тинькофф
22 октября приглашаем на Tinkoff Agile Conference. Обсудим лидерство, командообразование, инженерные подходы и практики управления. Тема этого года — «Масштабирование изменений от команд до организации».
Эксперты отрасли и agile-тренеры расскажут о менеджменте инноваций, инженерных подходах, практическом опыте построения компаний. Всего — 16 докладов от спикеров из Авито, Альфа-Банка, Тинькофф, Циана, Scrumtrek и других компаний. Будут воркшопы и, разумеется, афтепати.
Онлайн-трансляция главного зала бесплатна для всех, нужна только регистрация. Участие в конференции офлайн в Москве — пожертвование 2000 ₽ в Фонд борьбы с лейкемией. Регистрируйтесь и переходите по ссылке для оплаты в ответном письме. Очное участие возможно только с QR-кодом.
Подробная программа и регистрация по ссылке: https://v.tinkoff.ru/tac2021
P.S. Нет не продался, это дружественная реклама, организует ее знакомый.
#полезности
Составим компанию PMBoK
Многие в проектном управлении слышали эти заветные слова ПМБОК, некоторые даже пролистывали его и преисполнялись. Но немногие знают что подобных сводов в целом довольно много.
Перечислим некоторые из них:
1) Project Management Body of Knowledge (PMBoK)
2) Business Analysis Body of Knowledge (BABoK)
3) Business Process Management Common Body of Knowledge (CBoK)
4) Data Management Body of Knowledge (DMBoK)
5) Software Engineering Body of Knowledge (SWBoK)
6) Systems Engineering Body of Knowledge (SEBoK)
7) Business Architecture Body of Knowledge (BIZBoK)
8) Information Technology Architecture Body of Knowledge (ITABoK)
9) The Digital Practitioner Body of Knowledge (DPBoK)
10) Automation Body of Knowledge (ABoK)
11) Body of Knowledge and Curriculum to Advance Systems Engineering (BoKCASE)
12) Enterprise Architecture Body of Knowledge (EABoK)
Как уже догадался искушенный читатель почти в любой области есть своды знаний, которые претендуют на звание стандартов.
Они все разные, от 30 страниц в своде по развитию систем и до 1100 в своде по разработке ПО, где то описаны всеобъемлющие подходы и модели, как в SEBoK, а где то только общие черты как в BIZBoK. Общее у них одно - они описывают выжимку хороших практик и структурируют знания в определенной области. Почти как ГОСТы и IEEE).
Правда есть одно большое НО - это BoK-и именно то чем они являются, они не международные или государственные стандарты (хотя PMBoK очень пытается) и делая что-то ровно по ним ним нельзя сделать правильно. Вести холивары за чтобы процессы анализа были как в условном BABoK и по Вигерсу! не имеет особого смысла. Поэтому просто используйте мудрость этих документов и опыт ваших предшественников. Ведь нельзя сказать, что опыт был неправильным, верно?)
Составим компанию PMBoK
Многие в проектном управлении слышали эти заветные слова ПМБОК, некоторые даже пролистывали его и преисполнялись. Но немногие знают что подобных сводов в целом довольно много.
Перечислим некоторые из них:
1) Project Management Body of Knowledge (PMBoK)
2) Business Analysis Body of Knowledge (BABoK)
3) Business Process Management Common Body of Knowledge (CBoK)
4) Data Management Body of Knowledge (DMBoK)
5) Software Engineering Body of Knowledge (SWBoK)
6) Systems Engineering Body of Knowledge (SEBoK)
7) Business Architecture Body of Knowledge (BIZBoK)
8) Information Technology Architecture Body of Knowledge (ITABoK)
9) The Digital Practitioner Body of Knowledge (DPBoK)
10) Automation Body of Knowledge (ABoK)
11) Body of Knowledge and Curriculum to Advance Systems Engineering (BoKCASE)
12) Enterprise Architecture Body of Knowledge (EABoK)
Как уже догадался искушенный читатель почти в любой области есть своды знаний, которые претендуют на звание стандартов.
Они все разные, от 30 страниц в своде по развитию систем и до 1100 в своде по разработке ПО, где то описаны всеобъемлющие подходы и модели, как в SEBoK, а где то только общие черты как в BIZBoK. Общее у них одно - они описывают выжимку хороших практик и структурируют знания в определенной области. Почти как ГОСТы и IEEE).
Правда есть одно большое НО - это BoK-и именно то чем они являются, они не международные или государственные стандарты (хотя PMBoK очень пытается) и делая что-то ровно по ним ним нельзя сделать правильно. Вести холивары за чтобы процессы анализа были как в условном BABoK и по Вигерсу! не имеет особого смысла. Поэтому просто используйте мудрость этих документов и опыт ваших предшественников. Ведь нельзя сказать, что опыт был неправильным, верно?)
hsbi.hse.ru
BABOK Guide - свод знаний по бизнес-аналитике
Что такое BABOK? Руководство BABOK Guide 3.0 "Введение в бизнес анализ" – свод знаний по бизнес-аналитике, составляемый Международным институтом бизнес-анализа IIBA.
#полезности
Канал вместо избранного
Дорогой читатель, я завел канал https://t.me/pm_know_wh , чтобы складировать там все, что не успеваю читать. Почему именно для тебя? Возможно я никогда не прочту эти материалы и они просто останутся лежать до следующей очистки избранного, но тебе они могут быть полезны.
P.S. Также я решил сделать это в качестве эксперимента, вдруг не у меня одного есть запрос на подобную штуку. Я был бы рад поделиться админкой к каналу еще с кем-то, чтобы он полнился полезной всячиной. Если тебя это заинтересовало, то напиши в комментариях.
Канал вместо избранного
Дорогой читатель, я завел канал https://t.me/pm_know_wh , чтобы складировать там все, что не успеваю читать. Почему именно для тебя? Возможно я никогда не прочту эти материалы и они просто останутся лежать до следующей очистки избранного, но тебе они могут быть полезны.
P.S. Также я решил сделать это в качестве эксперимента, вдруг не у меня одного есть запрос на подобную штуку. Я был бы рад поделиться админкой к каналу еще с кем-то, чтобы он полнился полезной всячиной. Если тебя это заинтересовало, то напиши в комментариях.
Telegram
Склад знаний по управлению проектами
Многие складывают полезные материалы чтобы прочесть их потом (никогда). Но возможно это будет полезно другим. Так появился этот канал.
На картинке Ф. Тейлор
На картинке Ф. Тейлор
#рецепт
Как заходить за помощью по кейсу
Здравствуй дорогой читатель, сегодня мы порассуждаем как же грамотно описывать проблемы/случаи, которые требуют неоднозначных управленческих решений и изрядно напрягают префронтальную кору головного мозга. В быту такие вещи называют "управленческие кейсы" и даже разыгрывают по ним целые управленческие поединки, вроде такого питерского .
Есть 3 секретных шаблона:
Шаблон 1: управленческий поединок
Моя роль
На какой должности/роли ты работаешь?
Какие у тебя обязанности и полномочия?
Контекст
Какое направление у компании (FMCG, R&D ML или...)?
Кто вас окружает (какая корпоративная структура/иерархия)?
Проблема
В чем заключается текущая ситуация?
Кого она затрагивает?
Моя цель
Я хочу добиться X, потому что Y
Другие действующие лица
Каковы их роли?
Какие у них интересы/мотивы?
Шаблон 2: методика «ситуации-проблема-решение»
Ситуация
Что случилось, фактология, контекст
Проблема
К чему это привело, почему это проблема
Решение
Предложи какой-нибудь вариант решения, который, по твоему, поможет закрыть проблему (это пункт тоже желателен, потому что тут ты дашь ещё больше контекста + подумаешь «об чат»)
Шаблон 3: взгляд со стороны
Наблюдение
Я заметил что X, перечисление фактов
Ситуация
Это происходит в X, описание контекста ситуации и окружения
Следствие
'Из-за этого' + @наблюдение'+ 'произошло в' + @ситуации + 'и привело к' + @последствию/влиянию.
Главный вопрос
Открытый вопрос, который раскрывает чего вы хотите достичь в этом случае и почему.
P.S. Ни в коем случае не используй эти шаблоны, если не хочешь чтобы окружающие вас поняли и не завяливали множеством уточняющих вопросов. Доказано, что такие шаблоны сокращают время обсуждения в разы и делают его более продуктивными, не важно это обсуждение с руководителем, коллегой или в чатике телеграм. А это совершенно не то, чего ты хочешь, верно?)
2 шаблон от @@revealed_dave
Как заходить за помощью по кейсу
Здравствуй дорогой читатель, сегодня мы порассуждаем как же грамотно описывать проблемы/случаи, которые требуют неоднозначных управленческих решений и изрядно напрягают префронтальную кору головного мозга. В быту такие вещи называют "управленческие кейсы" и даже разыгрывают по ним целые управленческие поединки, вроде такого питерского .
Есть 3 секретных шаблона:
Шаблон 1: управленческий поединок
Моя роль
На какой должности/роли ты работаешь?
Какие у тебя обязанности и полномочия?
Контекст
Какое направление у компании (FMCG, R&D ML или...)?
Кто вас окружает (какая корпоративная структура/иерархия)?
Проблема
В чем заключается текущая ситуация?
Кого она затрагивает?
Моя цель
Я хочу добиться X, потому что Y
Другие действующие лица
Каковы их роли?
Какие у них интересы/мотивы?
Шаблон 2: методика «ситуации-проблема-решение»
Ситуация
Что случилось, фактология, контекст
Проблема
К чему это привело, почему это проблема
Решение
Предложи какой-нибудь вариант решения, который, по твоему, поможет закрыть проблему (это пункт тоже желателен, потому что тут ты дашь ещё больше контекста + подумаешь «об чат»)
Шаблон 3: взгляд со стороны
Наблюдение
Я заметил что X, перечисление фактов
Ситуация
Это происходит в X, описание контекста ситуации и окружения
Следствие
'Из-за этого' + @наблюдение'+ 'произошло в' + @ситуации + 'и привело к' + @последствию/влиянию.
Главный вопрос
Открытый вопрос, который раскрывает чего вы хотите достичь в этом случае и почему.
P.S. Ни в коем случае не используй эти шаблоны, если не хочешь чтобы окружающие вас поняли и не завяливали множеством уточняющих вопросов. Доказано, что такие шаблоны сокращают время обсуждения в разы и делают его более продуктивными, не важно это обсуждение с руководителем, коллегой или в чатике телеграм. А это совершенно не то, чего ты хочешь, верно?)
2 шаблон от @@revealed_dave
👍1
#мнение
Как понять что человек руководитель
Нужно задать ему 2 вопроса:
1) Почему ты хочешь быть/оставаться руководителем?
2) За что ты получаешь/хочешь получать свою зарплату?
Ответы на них достаточно важны, так как позволяют отличать администратора от руководителя. Я не утверждаю что администратор это плохо, это хорошая и конкретная дифференциация труда, но она имеет свои ограничения, которые часто как раз должен преодолевать руководитель.
Корневая разница в том, что руководитель понимает что конкретно дает его участие и сфокусирован на том вкладе, который он делает в функции организации.
P.S. Кстати вопросы универсальны, подходят как для повышения, так и для собеседования и на них достаточно по разному отвечают джуны и стажеры.
Как понять что человек руководитель
Нужно задать ему 2 вопроса:
1) Почему ты хочешь быть/оставаться руководителем?
2) За что ты получаешь/хочешь получать свою зарплату?
Ответы на них достаточно важны, так как позволяют отличать администратора от руководителя. Я не утверждаю что администратор это плохо, это хорошая и конкретная дифференциация труда, но она имеет свои ограничения, которые часто как раз должен преодолевать руководитель.
Корневая разница в том, что руководитель понимает что конкретно дает его участие и сфокусирован на том вкладе, который он делает в функции организации.
P.S. Кстати вопросы универсальны, подходят как для повышения, так и для собеседования и на них достаточно по разному отвечают джуны и стажеры.
#иное
Бары и менеджеры
Тест гипотезы о потребности в сообществе исключительно для встреч менеджеров в барах.
Критерием достижимости будем считать количество выпитого сидра и интересных вечеров.
Бары и менеджеры
Тест гипотезы о потребности в сообществе исключительно для встреч менеджеров в барах.
Критерием достижимости будем считать количество выпитого сидра и интересных вечеров.
Forwarded from Manage Drink Up
#спонтанный_междусобойчик
Настроение на кутеж
Открытие канала надо отметить, поэтому собираемся @artemletya (Айти ПМ) и @Slava_na_velosipede (Стройка ПМ) в баре. Будем пить, есть и разговаривать о всяком менеджерском.
Место: г. Санкт-Петербург, Социалистическая, 21 "Рыжий рорри"
Время: в 20.45.
Обсуждение здесь
Настроение на кутеж
Открытие канала надо отметить, поэтому собираемся @artemletya (Айти ПМ) и @Slava_na_velosipede (Стройка ПМ) в баре. Будем пить, есть и разговаривать о всяком менеджерском.
Место: г. Санкт-Петербург, Социалистическая, 21 "Рыжий рорри"
Время: в 20.45.
Обсуждение здесь
#иное
Бары и менеджеры. Официально
Продолжение теста гипотезы о потребности в сообществе исключительно для встреч менеджеров в барах.
Критерием достижимости будем считать количество выпитого сидра и интересных вечеров.
P.S. Управляю этим как проектом, есть даже устав и Ганта с бюджетом. Из интересного в целях масштабирование на другие города, использование ботов для анонсов и самоорганизации и договоренности с барами. Естественно совершенно неформально.
Бары и менеджеры. Официально
Продолжение теста гипотезы о потребности в сообществе исключительно для встреч менеджеров в барах.
Критерием достижимости будем считать количество выпитого сидра и интересных вечеров.
P.S. Управляю этим как проектом, есть даже устав и Ганта с бюджетом. Из интересного в целях масштабирование на другие города, использование ботов для анонсов и самоорганизации и договоренности с барами. Естественно совершенно неформально.
Forwarded from Manage Drink Up
#официальный_междусобойчик #СПб
Первый дринкап менеджеров
Запустим площадку для встреч менеджеров в барах. Ключевой идеей является синергия атмосферы бара, суровых людей из менеджмента и юмора. Никогда такого не было и вот опять.
Тебе понравится встреча, если:
1) Ты работаешь управленцем или имеешь такой опыт;
2) Любишь общаться с коллегами;
3) Интересно узнать какую шутку можно повторить более 3000 раз.
Уважаем правило Вегаса, поэтому все что обсуждалось на встрече, там и останется.
Не проводим сегрегацию по ролям и будем одинаково рады как руководителю отдела продаж, так и аджайл коучу.
Место: г. Санкт-Петербург, Чкаловский проспект, 50 "Арден"
Время: в 19.00 20 октября (среда)
Обсуждение здесь
Первый дринкап менеджеров
Запустим площадку для встреч менеджеров в барах. Ключевой идеей является синергия атмосферы бара, суровых людей из менеджмента и юмора. Никогда такого не было и вот опять.
Тебе понравится встреча, если:
1) Ты работаешь управленцем или имеешь такой опыт;
2) Любишь общаться с коллегами;
3) Интересно узнать какую шутку можно повторить более 3000 раз.
Уважаем правило Вегаса, поэтому все что обсуждалось на встрече, там и останется.
Не проводим сегрегацию по ролям и будем одинаково рады как руководителю отдела продаж, так и аджайл коучу.
Место: г. Санкт-Петербург, Чкаловский проспект, 50 "Арден"
Время: в 19.00 20 октября (среда)
Обсуждение здесь
#рецепт
Что делать если хочется что-то поменять?
Приветствую тебя, дорогой читатель!
Давай немного поговорим о вот какой теме - как вести себя менеджеру, чтобы что-то поменять в рабочих процессах. Ты наверняка задашься вопросом "А зачем как-то себя вести по особенному? Берешь и делаешь, я же менеджер, полномочия мне дали."
Во-первых: полномочия на изменения есть далеко не всегда. Не каждый РП имеет полномочия на управление командой;
Во-вторых: многие работают в крупных организациях, где процессы спущены сверху и вот так просто их не поменяешь.
Так как же вести себя менеджеру, чтобы устранить проблему в процессах? Я бы даже предложил так:
1) Выявить процесс.
Не просто менять что-то абстрактное что не нравится, а конкретно сформулировать что будет объектом усилий и его границы "от сих до сих". Четко сформулировать что идет на вход, а что на выход.
Поздравляю, теперь ты знаешь хотя бы с чем будешь иметь дело и это поможет в пункте 2;
2) Понять потребности.
Буквально. Нужно узнать кого затрагивает процесс из пункта 1 и кто на него может влиять (стейкхолдеров в общем). Вот у них узнаем а каковы их потребности в случае процесса 1. Должно получиться что-то вроде ("Васе нужна оценка задач для личного комфорта, чтобы была определенность");
3) Подтвердить проблему.
Почти наверняка проблему тут видишь только ты. Если ты посмотришь на информацию из пункта 2, то возможно окажется что до этого мало кому есть дело и тебя не поддержат при решении проблемы, потому что ее не видят. Поэтому задайся вопросом "для кого это проблема, а для кого нет?" Также будет полезно непрямыми вопросами уточнить это у стейкхолдеров.
Если в результате информации из пункта 2 и общения окажется что проблема не подтвердилась, то не отчаивайся! У тебя всегда есть инструменты cause-effect диаграмма, FMEA анализ, casual-loop диаграмма, канбан-доска и т.д. За счет этого ты вполне можешь подтвердить что проблема есть и показать это окружающим.
Если же ни общение, ни анализ процесса тебе не помогли, что ж. Залезай на бронивичок и косплей Ленина с "доколе!".
Главное завалидировать с с участниками процесса — есть ли проблема и видят ли они через новое представление.
4) Получить добро на решение проблемы.
Даже если ты показал участникам проблему, они могут просто не признать что ее надо решать и решать именно тебе. Поэтому нужно сперва показать что вы получите от решения проблемы - "вижен лучшей жизни" или бенефиты (если решим проблему А, то станет лучше Б вот на столько). Ну и конечно получи явное добро либо от большинства группы, либо от самого влиятельного.
5) Применить менеджерские инструменты
Это может быть что угодно, от 5 шагов теории ограничений систем и до системного мышления и канбан-метода, тут скорее зависит от того в чем вы разобрались и понимание границ применимости. А еще лучше никому не говорите что конкретно вы применяете, чтобы не столкнутся с предубеждением относительно инструмента, с помощью которого вы чините, такой вот партизанский менеджмент.
Что делать если хочется что-то поменять?
Приветствую тебя, дорогой читатель!
Давай немного поговорим о вот какой теме - как вести себя менеджеру, чтобы что-то поменять в рабочих процессах. Ты наверняка задашься вопросом "А зачем как-то себя вести по особенному? Берешь и делаешь, я же менеджер, полномочия мне дали."
Во-первых: полномочия на изменения есть далеко не всегда. Не каждый РП имеет полномочия на управление командой;
Во-вторых: многие работают в крупных организациях, где процессы спущены сверху и вот так просто их не поменяешь.
Так как же вести себя менеджеру, чтобы устранить проблему в процессах? Я бы даже предложил так:
1) Выявить процесс.
Не просто менять что-то абстрактное что не нравится, а конкретно сформулировать что будет объектом усилий и его границы "от сих до сих". Четко сформулировать что идет на вход, а что на выход.
Поздравляю, теперь ты знаешь хотя бы с чем будешь иметь дело и это поможет в пункте 2;
2) Понять потребности.
Буквально. Нужно узнать кого затрагивает процесс из пункта 1 и кто на него может влиять (стейкхолдеров в общем). Вот у них узнаем а каковы их потребности в случае процесса 1. Должно получиться что-то вроде ("Васе нужна оценка задач для личного комфорта, чтобы была определенность");
3) Подтвердить проблему.
Почти наверняка проблему тут видишь только ты. Если ты посмотришь на информацию из пункта 2, то возможно окажется что до этого мало кому есть дело и тебя не поддержат при решении проблемы, потому что ее не видят. Поэтому задайся вопросом "для кого это проблема, а для кого нет?" Также будет полезно непрямыми вопросами уточнить это у стейкхолдеров.
Если в результате информации из пункта 2 и общения окажется что проблема не подтвердилась, то не отчаивайся! У тебя всегда есть инструменты cause-effect диаграмма, FMEA анализ, casual-loop диаграмма, канбан-доска и т.д. За счет этого ты вполне можешь подтвердить что проблема есть и показать это окружающим.
Если же ни общение, ни анализ процесса тебе не помогли, что ж. Залезай на бронивичок и косплей Ленина с "доколе!".
Главное завалидировать с с участниками процесса — есть ли проблема и видят ли они через новое представление.
4) Получить добро на решение проблемы.
Даже если ты показал участникам проблему, они могут просто не признать что ее надо решать и решать именно тебе. Поэтому нужно сперва показать что вы получите от решения проблемы - "вижен лучшей жизни" или бенефиты (если решим проблему А, то станет лучше Б вот на столько). Ну и конечно получи явное добро либо от большинства группы, либо от самого влиятельного.
5) Применить менеджерские инструменты
Это может быть что угодно, от 5 шагов теории ограничений систем и до системного мышления и канбан-метода, тут скорее зависит от того в чем вы разобрались и понимание границ применимости. А еще лучше никому не говорите что конкретно вы применяете, чтобы не столкнутся с предубеждением относительно инструмента, с помощью которого вы чините, такой вот партизанский менеджмент.