О важности доменных знаний и странном рекрутинге.
В одном из немногих пока предыдущих постов, я вкратце рассказал о PMI Talent Triangle. Одним из его измерений является Strategic & Business Management - знания, навыки и поведение, относящиеся к индустрии/организации, помогающие направлять команду для лучшей доставки бизнес-ценности. Иначе говоря, доменные знания.
Представим себе модель менеджера с выраженной бизнес-экспертизой и низкими показателями TPM и Лидерства. Я уверен, вы все его встречали - менеджер-технарь. До сих пор многие бизнесы поощряют лояльность своих сотрудников, “повышая” до проектных руководителей специалистов других сфер - разработчиков, аналитиков, дизайнеров и т.п. В таком случае, вместо сеньорного сотрудника на выходе получаем абсолютно никакого проектного руководителя, потому что нужно около года времени, чтобы освоить базу ТРМ, и еще год-два для шлифовки этой базы (как пример, берем минимум для допуска к отраслевому экзамену PMP - 4500 часов работы проектным руководителем). Мой опыт говорит о том, что доменные знания проще получать, потому что вы применяете lean принципы - получаете то, что нужно именно сейчас и именно в нужных количествах. В случае ТРМ есть необходимый минимум для старта, и получить эти знания кусочно не представляется ни полезным, ни возможным. В течение своей карьеры я сталкивался со многими такими менеджерами на стороне заказчика (и не только, чего уж там), и это всегда было увлекательным мероприятием, особенно, если они уверены, что владеют предметом.
Усугубляют ситуацию компании и рекрутеры, которые ищут менеджеров и коучей с "preferred N years in DOMAIN NAME". Я никогда не признавал таких запросов, и вся моя карьера с успехом показывает, что Н лет в управлении (чем более разнообразном, тем лучше) и меньшее количество доменного опыта гораздо более предпочтительно, чем обратная ситуация. Но до сегодня у меня были только мои личные данные.
Пока я не нашел отличную статью, в которой на цифрах показано, что прибыльность компании зависит от ее индустрии - на 9-19% (в зависимости от исследований). А вот от специфики организации самой компании - уже 32-47%. Иными словами, гораздо важнее в пропорции понять и втянуться в работу организации как таковой, чем в индустрию, в которой эта организация оперирует. Я считаю, что это подтверждает мои эмпирические наблюдения о том, что хороший менеджер - он и в Африке хороший менеджер.
Но это я о индустрии, а вот об организациях, тех самых 32-47% влияния на прибыльность, поговорим в другой раз.
#beardthink #карьера
В одном из немногих пока предыдущих постов, я вкратце рассказал о PMI Talent Triangle. Одним из его измерений является Strategic & Business Management - знания, навыки и поведение, относящиеся к индустрии/организации, помогающие направлять команду для лучшей доставки бизнес-ценности. Иначе говоря, доменные знания.
Представим себе модель менеджера с выраженной бизнес-экспертизой и низкими показателями TPM и Лидерства. Я уверен, вы все его встречали - менеджер-технарь. До сих пор многие бизнесы поощряют лояльность своих сотрудников, “повышая” до проектных руководителей специалистов других сфер - разработчиков, аналитиков, дизайнеров и т.п. В таком случае, вместо сеньорного сотрудника на выходе получаем абсолютно никакого проектного руководителя, потому что нужно около года времени, чтобы освоить базу ТРМ, и еще год-два для шлифовки этой базы (как пример, берем минимум для допуска к отраслевому экзамену PMP - 4500 часов работы проектным руководителем). Мой опыт говорит о том, что доменные знания проще получать, потому что вы применяете lean принципы - получаете то, что нужно именно сейчас и именно в нужных количествах. В случае ТРМ есть необходимый минимум для старта, и получить эти знания кусочно не представляется ни полезным, ни возможным. В течение своей карьеры я сталкивался со многими такими менеджерами на стороне заказчика (и не только, чего уж там), и это всегда было увлекательным мероприятием, особенно, если они уверены, что владеют предметом.
Усугубляют ситуацию компании и рекрутеры, которые ищут менеджеров и коучей с "preferred N years in DOMAIN NAME". Я никогда не признавал таких запросов, и вся моя карьера с успехом показывает, что Н лет в управлении (чем более разнообразном, тем лучше) и меньшее количество доменного опыта гораздо более предпочтительно, чем обратная ситуация. Но до сегодня у меня были только мои личные данные.
Пока я не нашел отличную статью, в которой на цифрах показано, что прибыльность компании зависит от ее индустрии - на 9-19% (в зависимости от исследований). А вот от специфики организации самой компании - уже 32-47%. Иными словами, гораздо важнее в пропорции понять и втянуться в работу организации как таковой, чем в индустрию, в которой эта организация оперирует. Я считаю, что это подтверждает мои эмпирические наблюдения о том, что хороший менеджер - он и в Африке хороший менеджер.
Но это я о индустрии, а вот об организациях, тех самых 32-47% влияния на прибыльность, поговорим в другой раз.
#beardthink #карьера
О водопаде и вечной борьбе.
Просто оставлю это здесь:
...Every semester I cover systems development theories that include the guiding principles supporting repeatable systems development methods framed by the Systems Development Lifecycle. Like clockwork, early in the semester, there will be at least one student that will ask if I plan to teach the “Waterfall” model.
As an IT professional and academic for about 40+ years I have heard many myths about the IT industry. So the student’s use of the word “waterfall” wasn’t a surprise and it certainly wasn’t the first time I heard the word used in the systems development context. But what continues to surprise me is why the word “waterfall” is still being used to describe a systems methodology that doesn’t exist and why the creators of systems development methods use it as a source of comparison.
Ну и первоисточник, а также его толкование на русском, разумеется, прикреплены тут же.
#beardthink #модели
Просто оставлю это здесь:
...Every semester I cover systems development theories that include the guiding principles supporting repeatable systems development methods framed by the Systems Development Lifecycle. Like clockwork, early in the semester, there will be at least one student that will ask if I plan to teach the “Waterfall” model.
As an IT professional and academic for about 40+ years I have heard many myths about the IT industry. So the student’s use of the word “waterfall” wasn’t a surprise and it certainly wasn’t the first time I heard the word used in the systems development context. But what continues to surprise me is why the word “waterfall” is still being used to describe a systems methodology that doesn’t exist and why the creators of systems development methods use it as a source of comparison.
Ну и первоисточник, а также его толкование на русском, разумеется, прикреплены тут же.
#beardthink #модели
О жизненных циклах и управлении ими.
Итак, в предыдущем посте мы разобрались с тем, что понятия "waterfall" как выстроенной системы управления проектом не существует. Как же тогда отличить Agile от всего-вот-этого остального? На помощь приходит концепция жизненных циклов.
Жизненный цикл проекта - это набор фаз, которые проект проходит от начала до закрытия. Ни больше, ни меньше. Количество этих фаз, их названия и характеристики зависят от руководителя проектов, а точнее, того, как будет организована работа в проекте. Как говорил один из моих тренеров, универсальные фазы для любого проекта - это "фаза 1", "фаза 2" и так далее =).
И вот уже внутри этого жизненного цикла проекта, существуют фазы, непосредственно связанные с разработкой нового продукта или услуги. Эти фазы (одна или несколько) формируют жизненный цикл разработки. А моделей такого жизненного цикла 5:
1️⃣Предиктивная модель. Именно ее имеют ввиду, когда говорят о waterfall, да-да. В фазах, подчиненных этой модели, ограничения определяются на ранних этапах, в дальнейшем изменения в базовые планы внимательно отслеживаются и управляются.
Ключевая фраза - "пообещали - сделаем".
Пример проекта или фазы - прототипирование. Когда мы имеем проблему и четкое понимание усилий для ее проработки, нет ничего зазорного спланировать разработку прототипа загодя. Из моей практики, подобные timeboxed фазы являются отличным началом любого большого проекта.
2️⃣Итеративная модель. Несмотря на то, что конечная цель ясна на ранних этапах, точные затраты по времени и деньга могут пересматриваться через определенные промежутки времени. Именно по этой модели работает множество команд, уверенных в собственном Скраме, тогда как они просто работают над годичным проектом месячными итерациями.
Ключевая фраза - Мы не стремимся сделать все идеально с первой попытки.
Пример проекта или фазы - миграция. К примеру, ваша компания мигрирует с одной СRM на другую. Если представить себе, что разные отделы или филиалы переходят на новую систему не в один присест, потому что это очень рискованно, то мы и получим ситуацию, когда содержание проекта известно достаточно заранее, но исполнение проекта разбивается на итерации.
3️⃣Инкрементальная модель. Ключевым отличием от итеративной модели является обязательное наличие инкремента - полностью готового фрагмента функциональности, который встраивается в существующий продукт.
Ключевая фраза - Мы не стремимся сделать все за один раз.
Пример проекта или фазы - обновление продукта. Переход, положим, от версии 1.1 к 1.2 продукта означает создание рабочей "надстройки" над предыдущей версией. Таким образом, мы не просто итерируем во времени, но и создаем рабочую функциональность end-to-end.
4️⃣Адаптивная модель, или Agile подход. Эта модель совмещает в себе ключевые выгоды итеративного и инкрементального подходов. Детали ограничений и обязательств обсуждаются и фиксируются на итерацию или несколько, допуская не только изменения в требованиях, но и гибкость высокоуровневых стратегий и видения финального результата. Ключевые факторы успеха - частые инкрементные поставки и плотное вовлечение заинтересованных лиц.
Ключевая фраза - Мы делаем лучшее из возможного на данный момент.
Пример проекта или фазы - первая версия нового продукта. В ситуации наличия гипотез, которые необходимо проверять как можно скорее, собирая обратную связь и адаптируя планы по развитию продукта на ходу, любая другая модель разработки чревата лишней работой без каких-либо выгод.
5️⃣Гибридная модель. Интересно, что в реальной жизни гораздо чаще встречаются гибридные комбинации первых четырех моделей. Пример такого подхода я приведу в одном из следующих постов более детально.
Надеюсь, эта информация поможет вам планировать ваши проекты более осознанно.
#beardthink #модели
Итак, в предыдущем посте мы разобрались с тем, что понятия "waterfall" как выстроенной системы управления проектом не существует. Как же тогда отличить Agile от всего-вот-этого остального? На помощь приходит концепция жизненных циклов.
Жизненный цикл проекта - это набор фаз, которые проект проходит от начала до закрытия. Ни больше, ни меньше. Количество этих фаз, их названия и характеристики зависят от руководителя проектов, а точнее, того, как будет организована работа в проекте. Как говорил один из моих тренеров, универсальные фазы для любого проекта - это "фаза 1", "фаза 2" и так далее =).
И вот уже внутри этого жизненного цикла проекта, существуют фазы, непосредственно связанные с разработкой нового продукта или услуги. Эти фазы (одна или несколько) формируют жизненный цикл разработки. А моделей такого жизненного цикла 5:
1️⃣Предиктивная модель. Именно ее имеют ввиду, когда говорят о waterfall, да-да. В фазах, подчиненных этой модели, ограничения определяются на ранних этапах, в дальнейшем изменения в базовые планы внимательно отслеживаются и управляются.
Ключевая фраза - "пообещали - сделаем".
Пример проекта или фазы - прототипирование. Когда мы имеем проблему и четкое понимание усилий для ее проработки, нет ничего зазорного спланировать разработку прототипа загодя. Из моей практики, подобные timeboxed фазы являются отличным началом любого большого проекта.
2️⃣Итеративная модель. Несмотря на то, что конечная цель ясна на ранних этапах, точные затраты по времени и деньга могут пересматриваться через определенные промежутки времени. Именно по этой модели работает множество команд, уверенных в собственном Скраме, тогда как они просто работают над годичным проектом месячными итерациями.
Ключевая фраза - Мы не стремимся сделать все идеально с первой попытки.
Пример проекта или фазы - миграция. К примеру, ваша компания мигрирует с одной СRM на другую. Если представить себе, что разные отделы или филиалы переходят на новую систему не в один присест, потому что это очень рискованно, то мы и получим ситуацию, когда содержание проекта известно достаточно заранее, но исполнение проекта разбивается на итерации.
3️⃣Инкрементальная модель. Ключевым отличием от итеративной модели является обязательное наличие инкремента - полностью готового фрагмента функциональности, который встраивается в существующий продукт.
Ключевая фраза - Мы не стремимся сделать все за один раз.
Пример проекта или фазы - обновление продукта. Переход, положим, от версии 1.1 к 1.2 продукта означает создание рабочей "надстройки" над предыдущей версией. Таким образом, мы не просто итерируем во времени, но и создаем рабочую функциональность end-to-end.
4️⃣Адаптивная модель, или Agile подход. Эта модель совмещает в себе ключевые выгоды итеративного и инкрементального подходов. Детали ограничений и обязательств обсуждаются и фиксируются на итерацию или несколько, допуская не только изменения в требованиях, но и гибкость высокоуровневых стратегий и видения финального результата. Ключевые факторы успеха - частые инкрементные поставки и плотное вовлечение заинтересованных лиц.
Ключевая фраза - Мы делаем лучшее из возможного на данный момент.
Пример проекта или фазы - первая версия нового продукта. В ситуации наличия гипотез, которые необходимо проверять как можно скорее, собирая обратную связь и адаптируя планы по развитию продукта на ходу, любая другая модель разработки чревата лишней работой без каких-либо выгод.
5️⃣Гибридная модель. Интересно, что в реальной жизни гораздо чаще встречаются гибридные комбинации первых четырех моделей. Пример такого подхода я приведу в одном из следующих постов более детально.
Надеюсь, эта информация поможет вам планировать ваши проекты более осознанно.
#beardthink #модели
👍1
О контролируемых инновациях и гибридном жизненном цикле разработки.
Чтобы было понятнее, как применять гибридную модель для работы в вашем проекте, я расскажу вкратце один из практических кейсов.
Клиентом является отдел инноваций компании в индустрии maritime, непосредственный спонсор программы это их CIO. Одной из ключевых особенностей этого сектора является высокая задокументированность, поэтому большинство инновационных решений для них - это оптимизация внутренних бизнес-процессов путем цифровизации, улучшения обработки данных и т.п. При этом, стейкхолдеры довольно консервативны и не готовы просто разбрасываться деньгами. Методом проб и ошибок, мы выстроили фреймворк двухфазных проектов, который негласно именуем "контролируемыми инновациями":
1️⃣ фаза проекта называется "research". Входом к началу фазы является бизнес-кейс от клиента с описанием некоторой проблемы и возможных гипотез о ее решении. В этой фазе мы работаем в agile режиме, с недельными спринтами. Команда состоит из сервис-дизайнеров, им ассистируют ux/ui дизайнеры и разработчики. Затраты проекта зафиксированы поспринтово.
Целью этой фазы является обоснование проблемы, подтверждение возможностей ее решения. Нередко, эту фазу мы заканчиваем дизайн-спринтом. Воротами фазы является Project Charter следующей фазы, в который мы включаем оценку трудозатрат и все остальные детали более точного планирования решения проблемы. Иногда, вторая фаза отменяется, если заранее понятно, к примеру, что проблема не стоит инвестиций или на текущий момент ее можно решить другими способами.
2️⃣ фазу мы называем "implementation" и она подчинена предиктивной модели. Мы берем на себя обязательства по решению проблемы на основании результатов исследований, проведенных в предыдущей фазе. Мы следуем Firm Fixed Price модели в составлении затрат на эту фазу. Целью этой фазы является разработка и внедрение решения бизнес-проблемы клиента.
Этот короткий пример показывает, как, анализируя поведение стейкхолдеров и характер их бизнеса, можно выстроить гибридную модель жизненного цикла разработки, которая совмещает в себе плюсы разных методов. В нашем случае, мы имеем необходимую гибкость для исследования проблемы и путей решения (я уверен, особо внимательные читатели увидели влияние Дизайн Мышления), а клиент доволен тем, что затраты находятся под четким контролем. На данный момент, по этой программе мы имеем уровень удовлетворенности клиента не менее 8/10 за проект.
Стоит добавить, что разработку подобных подходов имеет смысл ожидать от проектных руководителей Middle+ уровня.
#beardthink #модели
Чтобы было понятнее, как применять гибридную модель для работы в вашем проекте, я расскажу вкратце один из практических кейсов.
Клиентом является отдел инноваций компании в индустрии maritime, непосредственный спонсор программы это их CIO. Одной из ключевых особенностей этого сектора является высокая задокументированность, поэтому большинство инновационных решений для них - это оптимизация внутренних бизнес-процессов путем цифровизации, улучшения обработки данных и т.п. При этом, стейкхолдеры довольно консервативны и не готовы просто разбрасываться деньгами. Методом проб и ошибок, мы выстроили фреймворк двухфазных проектов, который негласно именуем "контролируемыми инновациями":
1️⃣ фаза проекта называется "research". Входом к началу фазы является бизнес-кейс от клиента с описанием некоторой проблемы и возможных гипотез о ее решении. В этой фазе мы работаем в agile режиме, с недельными спринтами. Команда состоит из сервис-дизайнеров, им ассистируют ux/ui дизайнеры и разработчики. Затраты проекта зафиксированы поспринтово.
Целью этой фазы является обоснование проблемы, подтверждение возможностей ее решения. Нередко, эту фазу мы заканчиваем дизайн-спринтом. Воротами фазы является Project Charter следующей фазы, в который мы включаем оценку трудозатрат и все остальные детали более точного планирования решения проблемы. Иногда, вторая фаза отменяется, если заранее понятно, к примеру, что проблема не стоит инвестиций или на текущий момент ее можно решить другими способами.
2️⃣ фазу мы называем "implementation" и она подчинена предиктивной модели. Мы берем на себя обязательства по решению проблемы на основании результатов исследований, проведенных в предыдущей фазе. Мы следуем Firm Fixed Price модели в составлении затрат на эту фазу. Целью этой фазы является разработка и внедрение решения бизнес-проблемы клиента.
Этот короткий пример показывает, как, анализируя поведение стейкхолдеров и характер их бизнеса, можно выстроить гибридную модель жизненного цикла разработки, которая совмещает в себе плюсы разных методов. В нашем случае, мы имеем необходимую гибкость для исследования проблемы и путей решения (я уверен, особо внимательные читатели увидели влияние Дизайн Мышления), а клиент доволен тем, что затраты находятся под четким контролем. На данный момент, по этой программе мы имеем уровень удовлетворенности клиента не менее 8/10 за проект.
Стоит добавить, что разработку подобных подходов имеет смысл ожидать от проектных руководителей Middle+ уровня.
#beardthink #модели
👍3❤1
О философии и глупости.
Я очень люблю использовать разного рода шуточные (и не очень) эмпирические принципы, трюизмы и "законы" в повседневной жизни. Кто из нас не знает о "законе Мерфи" и множестве следствий из него. Все опытные проектные руководители также полагаются на "закон Паркинсона" или "синдром студента", который гласит, что любая работа занимает все отведенное на нее время, а иногда и больше.
Во время недавней встречи, один из членов команды проекта сетовал на то, что клиент - огромная бюрократизированная организация - очень сильно тормозит предоставление доступов к своим системам. Действительно, получить доступ к их VPN это дело пары недель, никак не меньше. Впечатлительный парень сказал: "Мне кажется, они просто саботируют работу и хотят нашего провала". Чтобы успокоить панику, я использовал один из моих любимых эмпирических законов, который называется "бритва Хенлона". Он гласит:
Никогда не приписывайте злому умыслу то, что вполне можно объяснить глупостью.
И действительно, при поисках причин неприятностей рассматривайте прежде всего человеческие ошибки, и лишь после этого - сознательные злонамеренные действия. Сэкономите много нервных клеток!
А наш 1-1 закончился весело и с огоньком. Чего и вам желаю.
#beardthink
Я очень люблю использовать разного рода шуточные (и не очень) эмпирические принципы, трюизмы и "законы" в повседневной жизни. Кто из нас не знает о "законе Мерфи" и множестве следствий из него. Все опытные проектные руководители также полагаются на "закон Паркинсона" или "синдром студента", который гласит, что любая работа занимает все отведенное на нее время, а иногда и больше.
Во время недавней встречи, один из членов команды проекта сетовал на то, что клиент - огромная бюрократизированная организация - очень сильно тормозит предоставление доступов к своим системам. Действительно, получить доступ к их VPN это дело пары недель, никак не меньше. Впечатлительный парень сказал: "Мне кажется, они просто саботируют работу и хотят нашего провала". Чтобы успокоить панику, я использовал один из моих любимых эмпирических законов, который называется "бритва Хенлона". Он гласит:
Никогда не приписывайте злому умыслу то, что вполне можно объяснить глупостью.
И действительно, при поисках причин неприятностей рассматривайте прежде всего человеческие ошибки, и лишь после этого - сознательные злонамеренные действия. Сэкономите много нервных клеток!
А наш 1-1 закончился весело и с огоньком. Чего и вам желаю.
#beardthink
О самоконтроле и визуализации.
На одной из менторских сессий обсуждали интересную ситуацию. Коллега говорил о том, что он настолько переживает за проект, что любая встреча или разговор, связанный с этим проектом, является ситуацией, в которую он вкладывается на 100%. Как следствие - усталость и предпосылки к выгоранию. Что же делать?
Я переживал подобное. В любой дискуссии, на проектных встречах, я вкладывал всю свою энергию и силы. Как следствие, эти силы заканчивались к середине рабочего дня, и все оставшееся время я перемещался по офису, как выжатый лимон. И тогда я открыл для себя интересную технику.
Перед, скажем так, взаимодействием с людьми, я представляю себе тахометр с разметкой от 1 до 10, с красной зоной на 8-10. Потом я задаю себе вопрос - что за встреча мне предстоит? Битва за бюджет на следующий квартал или рефлексия с дружественным коллегой? Фасилитация ретроспективы или 1-1 за чашкой кофе? Я выставляю себе предельное эмоциональное вовлечение на встречу или общение. Если во время самого события я чувствую, что завожусь, я на мгновение закрываю глаза и отвечаю себе на вопрос - на сколько "оборотов" я сейчас в беседе и почему? Таким образом, я контролирую как свои эмоции, так и уровень "инвестиций" в диалог или дискуссию.
Звучит громоздко, но после небольшой практики, занимает считанные секунды на весь процесс. Этот подход позволяет мне выдерживать загрузку встречами до 7 часов в день. Главная идея в том, что не все проектные встречи требуют одинакового уровня вовлечения.
Инвестируйте свои силы с умом.
#beardthink #практика
На одной из менторских сессий обсуждали интересную ситуацию. Коллега говорил о том, что он настолько переживает за проект, что любая встреча или разговор, связанный с этим проектом, является ситуацией, в которую он вкладывается на 100%. Как следствие - усталость и предпосылки к выгоранию. Что же делать?
Я переживал подобное. В любой дискуссии, на проектных встречах, я вкладывал всю свою энергию и силы. Как следствие, эти силы заканчивались к середине рабочего дня, и все оставшееся время я перемещался по офису, как выжатый лимон. И тогда я открыл для себя интересную технику.
Перед, скажем так, взаимодействием с людьми, я представляю себе тахометр с разметкой от 1 до 10, с красной зоной на 8-10. Потом я задаю себе вопрос - что за встреча мне предстоит? Битва за бюджет на следующий квартал или рефлексия с дружественным коллегой? Фасилитация ретроспективы или 1-1 за чашкой кофе? Я выставляю себе предельное эмоциональное вовлечение на встречу или общение. Если во время самого события я чувствую, что завожусь, я на мгновение закрываю глаза и отвечаю себе на вопрос - на сколько "оборотов" я сейчас в беседе и почему? Таким образом, я контролирую как свои эмоции, так и уровень "инвестиций" в диалог или дискуссию.
Звучит громоздко, но после небольшой практики, занимает считанные секунды на весь процесс. Этот подход позволяет мне выдерживать загрузку встречами до 7 часов в день. Главная идея в том, что не все проектные встречи требуют одинакового уровня вовлечения.
Инвестируйте свои силы с умом.
#beardthink #практика
fedoruk.works via @vote
Навеяно некоторыми ситуациями и интересно для дальнейших материалов. Пользуешься ли ты Уставами проектов (Project Charter)?
anonymous poll
Иногда, если размер проекта кажется годным. – 36
👍👍👍👍👍👍👍 40%
А что такое устав проекта? – 34
👍👍👍👍👍👍👍 38%
Конечно, на каждом проекте! – 10
👍👍 11%
Нет, это порождение тьмы в царстве agile! – 9
👍👍 10%
👥 89 people voted so far.
anonymous poll
Иногда, если размер проекта кажется годным. – 36
👍👍👍👍👍👍👍 40%
А что такое устав проекта? – 34
👍👍👍👍👍👍👍 38%
Конечно, на каждом проекте! – 10
👍👍 11%
Нет, это порождение тьмы в царстве agile! – 9
👍👍 10%
👥 89 people voted so far.
fedoruk.works pinned «Навеяно некоторыми ситуациями и интересно для дальнейших материалов. Пользуешься ли ты Уставами проектов (Project Charter)? anonymous poll Иногда, если размер проекта кажется годным. – 36 👍👍👍👍👍👍👍 40% А что такое устав проекта? – 34 👍👍👍👍👍👍👍 38% Конечно,…»
О решениях проблем и контрольных вопросах.
Как часто ты слышишь о проблемах с проектом или компанией от сотрудников и коллег? Я думаю, как и все мы, довольно часто (ну или постоянно).
Для меня, главный вопрос всегда один - стоит ли мне приоритезировать этот запрос или мне нужно поработать с человеком персонально?
Для того, чтобы отличить важное замечание от вентилирования или даже токсичного поведения, я предлагаю задать как минимум один из двух вопросов в ответ на жалобу:
❓Каким ты видишь идеальное развитие ситуации/идеальное течение процесса?
❓Что мы вместе/я как менеджер могу сделать прямо сейчас, чтобы улучшить ситуацию?
Практика показывает, что неспособность ответить на один из этих вопросов является индикатором необходимости провентилировать ситуацию, либо признаком токсичного поведения.
✅ Если такое поведение является единичным случаем, то мы рассматриваем ситуацию с вентилированием и организовываем беседу 1-1 в спокойной обстановке. На ней мы попытаемся выявить корневые причины. Поверь, они могут быть очень неожиданными (к примеру, разлад в семье).
✅ Если такое поведение является повторяющимся паттерном, мы имеем дело с токсичным поведением в команде. В основе, у вас как у менеджера будет два пути - Heal or Kill. С освобождением человека из команды все понятно, а по поводу стратегии Heal мы поговорим в другой раз.
Важное замечание! Если по позиции и роли ты являешься просто руководителем проектов, да еще и в организациях слабых матриц - скорее всего ресурсов на применение Heal у тебя не будет. В таких случаях лучше эскалировать на функционального руководителя этого сотрудника.
Всем конструктивных дискуссий!
#beardthink #практика
Как часто ты слышишь о проблемах с проектом или компанией от сотрудников и коллег? Я думаю, как и все мы, довольно часто (ну или постоянно).
Для меня, главный вопрос всегда один - стоит ли мне приоритезировать этот запрос или мне нужно поработать с человеком персонально?
Для того, чтобы отличить важное замечание от вентилирования или даже токсичного поведения, я предлагаю задать как минимум один из двух вопросов в ответ на жалобу:
❓Каким ты видишь идеальное развитие ситуации/идеальное течение процесса?
❓Что мы вместе/я как менеджер могу сделать прямо сейчас, чтобы улучшить ситуацию?
Практика показывает, что неспособность ответить на один из этих вопросов является индикатором необходимости провентилировать ситуацию, либо признаком токсичного поведения.
✅ Если такое поведение является единичным случаем, то мы рассматриваем ситуацию с вентилированием и организовываем беседу 1-1 в спокойной обстановке. На ней мы попытаемся выявить корневые причины. Поверь, они могут быть очень неожиданными (к примеру, разлад в семье).
✅ Если такое поведение является повторяющимся паттерном, мы имеем дело с токсичным поведением в команде. В основе, у вас как у менеджера будет два пути - Heal or Kill. С освобождением человека из команды все понятно, а по поводу стратегии Heal мы поговорим в другой раз.
Важное замечание! Если по позиции и роли ты являешься просто руководителем проектов, да еще и в организациях слабых матриц - скорее всего ресурсов на применение Heal у тебя не будет. В таких случаях лучше эскалировать на функционального руководителя этого сотрудника.
Всем конструктивных дискуссий!
#beardthink #практика
Про книги для мировоззрения и обзоры.
Если кто не видел, на ДОУ вышла моя подборка книг для осенних вечеров. В нее вошли:
1️⃣ The Art of Action: How Leaders Close the Gaps Between Plans, Actions, and Results by Stephen Bungay
2️⃣ The Fifth Discipline: The Art & Practice of The Learning Organization by Peter Senge
3️⃣ Crucial Conversations: Tools for Talking When Stakes Are High, Second Edition by Kerry Patterson, Joseph Grenny, Ron McMillan, Al Switzler
4️⃣ Great Boss Dead Boss by Ray Immelman
5️⃣ Full Dark, No Stars by Stephen King
В статье сможете найти ссылки на оригиналы или переводы.
C какой книги хотели бы начать?
#beardread
Если кто не видел, на ДОУ вышла моя подборка книг для осенних вечеров. В нее вошли:
1️⃣ The Art of Action: How Leaders Close the Gaps Between Plans, Actions, and Results by Stephen Bungay
2️⃣ The Fifth Discipline: The Art & Practice of The Learning Organization by Peter Senge
3️⃣ Crucial Conversations: Tools for Talking When Stakes Are High, Second Edition by Kerry Patterson, Joseph Grenny, Ron McMillan, Al Switzler
4️⃣ Great Boss Dead Boss by Ray Immelman
5️⃣ Full Dark, No Stars by Stephen King
В статье сможете найти ссылки на оригиналы или переводы.
C какой книги хотели бы начать?
#beardread
О демократии и образовании.
В качестве развлечения выходного дня, предлагаю тебе короткое видео о том, что такое демократия и как она должна была выглядеть (подсказка - меритократически).
Почему я думаю, что это имеет смысл для менеджеров? Я вижу, как организации и руководители стремятся к инклюзивности, упрощению и демократичности, часто забывая, что состояние "все решают" не должно быть самоцелью.
Некоторым нужно убить своего Сократа, чтобы это понять.
#beardthink
В качестве развлечения выходного дня, предлагаю тебе короткое видео о том, что такое демократия и как она должна была выглядеть (подсказка - меритократически).
Почему я думаю, что это имеет смысл для менеджеров? Я вижу, как организации и руководители стремятся к инклюзивности, упрощению и демократичности, часто забывая, что состояние "все решают" не должно быть самоцелью.
Некоторым нужно убить своего Сократа, чтобы это понять.
#beardthink
YouTube
Why Socrates Hated Democracy
We’re used to thinking hugely well of democracy. But interestingly, one of the wisest people who ever lived, Socrates, had deep suspicions of it.
If you enjoy our videos, get full access to all our audio content, videos, and thousands of thought-provoking…
If you enjoy our videos, get full access to all our audio content, videos, and thousands of thought-provoking…
Об уставе проекта и больничных процедурах.
Начнем небольшой цикл бесед о таком проектном артефакте, как Устав проекта (он же - Project Charter).
Формально выражаясь, Устав проекта является документом, подтверждающим существование проекта в организации и обозначающий проектного руководителя как лицо, ответственное за успех этого проекта. Информация в этом документе собрана таким образом, чтобы все заинтересованные стороны проекта понимали его детали одинаково.
Чтобы объяснить важность этого артефакта, я использую следующую метафору. Представьте себе полевой госпиталь. Полная палатка больных и раненых разной степени тяжести. В палату входит врач с очередным обходом, и он должен быстро и однозначно отличать этих больных и принимать по ним решения. А их количество с последнего обхода могло измениться количественно и качественно. Поэтому, на каждой кровати в ногах висит карточка больного - имя, фамилия, история попадания в госпиталь, диагноз, план лечения, ответственные врачи и медсестры, предварительный прогноз и т.п. Без этой карточки, врач будет путаться и терять пациентов, их лечение выйдет из-под контроля. Именно этой "карточкой" для проекта в организации и является Устав.
Из метафоры несложно извлечь основные составные части Устава:
❇️История запуска проекта;
❇️Цель проекта;
❇️Измеримые критерии успешности проекта;
❇️Общее описание ограничений проекта, основных результатов поставок;
❇️Общая информация о рисках, расписании, бюджете, людях, требованиях и т.п.
Устав проекта формируют на этапе его запуска, поэтому этот документ - не про детали, а про выравнивание ожиданий участников процесса.
Каким образом его строят:
✅Анализ бизнес-кейса - смотрим, какую проблему и кому будет решать исполнение проекта;
✅Работа с заинтересованными сторонами - семинары, митинги, интервью;
✅Анализ факторов среды предприятия - внутренние политики и правила, в условиях которых будет реализовываться проект
✅Проверка активов процессов организации - какими документами, подходами мы будем руководствоваться при реализации проекта.
Шаблонов Устава существует огромное количество. Если кому нужен стартовый пинок, мой вариант прикреплен к посту. Это тот шаблон, который работает в моих условиях последний год.
И небольшой блиц важных моментов:
🈯️При написании Устава, выстраивайте четкую цепочку Бизнес-кейс -> Цели проекта -> Содержание -> Результаты -> Критерии приемки и выхода. Это поможет контролировать ценность, которую несет проект для заинтересованных сторон;
🈯️Изменение Устава влечет за собой изменение всего проекта - пожалуй, единственный документ, который в идеальных условиях не должен изменяться по ходу проекта или фазы;
🈯️Устав, по определению, документ короткий.
Учитывая вышесказанное, как вы думаете, какими будут ответы на остальные пункты опросника? =)
#beardthink #практика
Начнем небольшой цикл бесед о таком проектном артефакте, как Устав проекта (он же - Project Charter).
Формально выражаясь, Устав проекта является документом, подтверждающим существование проекта в организации и обозначающий проектного руководителя как лицо, ответственное за успех этого проекта. Информация в этом документе собрана таким образом, чтобы все заинтересованные стороны проекта понимали его детали одинаково.
Чтобы объяснить важность этого артефакта, я использую следующую метафору. Представьте себе полевой госпиталь. Полная палатка больных и раненых разной степени тяжести. В палату входит врач с очередным обходом, и он должен быстро и однозначно отличать этих больных и принимать по ним решения. А их количество с последнего обхода могло измениться количественно и качественно. Поэтому, на каждой кровати в ногах висит карточка больного - имя, фамилия, история попадания в госпиталь, диагноз, план лечения, ответственные врачи и медсестры, предварительный прогноз и т.п. Без этой карточки, врач будет путаться и терять пациентов, их лечение выйдет из-под контроля. Именно этой "карточкой" для проекта в организации и является Устав.
Из метафоры несложно извлечь основные составные части Устава:
❇️История запуска проекта;
❇️Цель проекта;
❇️Измеримые критерии успешности проекта;
❇️Общее описание ограничений проекта, основных результатов поставок;
❇️Общая информация о рисках, расписании, бюджете, людях, требованиях и т.п.
Устав проекта формируют на этапе его запуска, поэтому этот документ - не про детали, а про выравнивание ожиданий участников процесса.
Каким образом его строят:
✅Анализ бизнес-кейса - смотрим, какую проблему и кому будет решать исполнение проекта;
✅Работа с заинтересованными сторонами - семинары, митинги, интервью;
✅Анализ факторов среды предприятия - внутренние политики и правила, в условиях которых будет реализовываться проект
✅Проверка активов процессов организации - какими документами, подходами мы будем руководствоваться при реализации проекта.
Шаблонов Устава существует огромное количество. Если кому нужен стартовый пинок, мой вариант прикреплен к посту. Это тот шаблон, который работает в моих условиях последний год.
И небольшой блиц важных моментов:
🈯️При написании Устава, выстраивайте четкую цепочку Бизнес-кейс -> Цели проекта -> Содержание -> Результаты -> Критерии приемки и выхода. Это поможет контролировать ценность, которую несет проект для заинтересованных сторон;
🈯️Изменение Устава влечет за собой изменение всего проекта - пожалуй, единственный документ, который в идеальных условиях не должен изменяться по ходу проекта или фазы;
🈯️Устав, по определению, документ короткий.
Учитывая вышесказанное, как вы думаете, какими будут ответы на остальные пункты опросника? =)
#beardthink #практика
О грубости и слабом менеджменте.
Давно не секрет, что одной из ролей, которые выполняет менеджмент в организации, является т.н. "поощрение-наказание". Это не означает порку, но в любой доступной форме менеджмент должен демонстрировать, какое поведение является приемлемым, а какое нет.
Точно так же не секрет, что менеджмент как прослойка страдает от разного рода искажений и откровенного членовредительства - от коррупции до некомпетентности. Эти явления напрямую влияют на возникновение перекосов в системе "поощрение-наказание", а значит, ведут к целому букету организационных проблем.
И сегодня мне попалась статья, которая, признаюсь, испортила мне настроение. Речь идет о грубости на работе. По оценкам, 98% сотрудников получали грубое отношение на работе в течение последнего года! Исследователи задались вопросом - если грубость на работе влечет за собой массу проблем (падение мотивации, проблемы со здоровьем, потерю ключевых людей), то, очевидно, здравомыслящий менеджмент принимает адекватные меры?
Как бы не так! Вот какие данные получили авторы из разных исследований:
🉐Сотрудники, которые сообщали о грубости в свой адрес, в большинстве своем воспринимались менеджментом как зачинщики, даже если доказано не совершали ничего плохого.
🉐Сотрудники, которые демонстрировали грубость к другим менеджментом как грубияны не воспринимались, под одним из двух условий: тесные отношения с боссом или топ-перформеры.
🉐Жертвы грубости воспринимаются менеджментом как сравнительно хуже работающие независимо от конкретных метрик производительности.
Как же уберечься от такой вопиющей предосудительности? Авторы исследования предлагают менеджерам проходить тренинги, схожие с тренингами судей и присяжных. А что вы можете сделать прямо сейчас:
❇️Сознательно разделяйте релевантную и нерелевантную информацию;
❇️Инвестируйте столько времени, сколько потребуется;
❇️Распознавайте и осознавайте влияние контекста и личных искажений на принятие решений;
❇️Проактивно изучайте когнитивные ловушки, в которые мы попадаем. Предупрежден - значит вооружен.
Сознательного вам управления.
#beardthink #практика
Давно не секрет, что одной из ролей, которые выполняет менеджмент в организации, является т.н. "поощрение-наказание". Это не означает порку, но в любой доступной форме менеджмент должен демонстрировать, какое поведение является приемлемым, а какое нет.
Точно так же не секрет, что менеджмент как прослойка страдает от разного рода искажений и откровенного членовредительства - от коррупции до некомпетентности. Эти явления напрямую влияют на возникновение перекосов в системе "поощрение-наказание", а значит, ведут к целому букету организационных проблем.
И сегодня мне попалась статья, которая, признаюсь, испортила мне настроение. Речь идет о грубости на работе. По оценкам, 98% сотрудников получали грубое отношение на работе в течение последнего года! Исследователи задались вопросом - если грубость на работе влечет за собой массу проблем (падение мотивации, проблемы со здоровьем, потерю ключевых людей), то, очевидно, здравомыслящий менеджмент принимает адекватные меры?
Как бы не так! Вот какие данные получили авторы из разных исследований:
🉐Сотрудники, которые сообщали о грубости в свой адрес, в большинстве своем воспринимались менеджментом как зачинщики, даже если доказано не совершали ничего плохого.
🉐Сотрудники, которые демонстрировали грубость к другим менеджментом как грубияны не воспринимались, под одним из двух условий: тесные отношения с боссом или топ-перформеры.
🉐Жертвы грубости воспринимаются менеджментом как сравнительно хуже работающие независимо от конкретных метрик производительности.
Как же уберечься от такой вопиющей предосудительности? Авторы исследования предлагают менеджерам проходить тренинги, схожие с тренингами судей и присяжных. А что вы можете сделать прямо сейчас:
❇️Сознательно разделяйте релевантную и нерелевантную информацию;
❇️Инвестируйте столько времени, сколько потребуется;
❇️Распознавайте и осознавайте влияние контекста и личных искажений на принятие решений;
❇️Проактивно изучайте когнитивные ловушки, в которые мы попадаем. Предупрежден - значит вооружен.
Сознательного вам управления.
#beardthink #практика
Harvard Business Review
Why People Get Away with Being Rude at Work
People who experience workplace rudeness report lower engagement, suffer more mental and physical health problems, and are more likely to burn out and quit their jobs. But while some research has indicated leaders take reports of bad behavior seriously, get…
О итерациях и практиках.
Для всех любителей интересных практик, и чтобы поменьше теории - открытая библиотека практик на разные этапы вашей итеративной модели. Все, что нужно, чтобы разнообразить серые будни. Кликабельно и фильтруемо.
Всем гибкости!
#beardthink #практика #agile
Для всех любителей интересных практик, и чтобы поменьше теории - открытая библиотека практик на разные этапы вашей итеративной модели. Все, что нужно, чтобы разнообразить серые будни. Кликабельно и фильтруемо.
Всем гибкости!
#beardthink #практика #agile
Open Practice Library
Practices that empower teams to collaborate and deliver iteratively
Об обязательности устава и говорящих пациентах.
Итак, в одном из предыдущих постов мы ликвидировали конфликт определений и разобрались с тем, что же такое Устав проекта. Следующим в повестке дня стоит вопрос его обязательности на проектах.
Вернемся к метафоре госпиталя и представим себе, как в палату заходит врач. Он видит в ней двух пациентов. Один, веселый парень с выбитым зубом, задорно грызет яблоко и готов любому желающему рассказать, где же он этот зуб потерял. На соседней койке лежит непонятной формы тело, из которого торчат пяток трубок и проводов, подключенных к батарее устройств вокруг. Разумеется, этот пациент в ближайшее время не сможет ничего рассказать, и требует максимум внимания и ухода. А теперь вопрос - будет ли у любого из этих пациентов отсутствовать история болезни?
Разумеется, нет! История необходима для того, чтобы понять, с каким диагнозом поступил, как проходит лечение, какие прогнозы или изменения его состояния происходят. Пройдет какое-то время, и пациенты покинут палату, а врачам предстоит отчет об эффективности и результативности лечения, а также обучение молодых интернов на базе этой документации. Исходя из этого, я могу назвать четыре артефакта, которые считаю обязательными в абсолютно всех проектах:
🈯️ Устав проекта (Project Charter);
🈯️ Данные о ходе работ (Work Performance Data);
🈯️ Журнал изменений (Change Log);
🈯️ Выученные уроки (Lessons Learned).
Вопрос только в том, какой "толщины" будет "история болезни" у вашего пациента.
#beardthink #практика
Итак, в одном из предыдущих постов мы ликвидировали конфликт определений и разобрались с тем, что же такое Устав проекта. Следующим в повестке дня стоит вопрос его обязательности на проектах.
Вернемся к метафоре госпиталя и представим себе, как в палату заходит врач. Он видит в ней двух пациентов. Один, веселый парень с выбитым зубом, задорно грызет яблоко и готов любому желающему рассказать, где же он этот зуб потерял. На соседней койке лежит непонятной формы тело, из которого торчат пяток трубок и проводов, подключенных к батарее устройств вокруг. Разумеется, этот пациент в ближайшее время не сможет ничего рассказать, и требует максимум внимания и ухода. А теперь вопрос - будет ли у любого из этих пациентов отсутствовать история болезни?
Разумеется, нет! История необходима для того, чтобы понять, с каким диагнозом поступил, как проходит лечение, какие прогнозы или изменения его состояния происходят. Пройдет какое-то время, и пациенты покинут палату, а врачам предстоит отчет об эффективности и результативности лечения, а также обучение молодых интернов на базе этой документации. Исходя из этого, я могу назвать четыре артефакта, которые считаю обязательными в абсолютно всех проектах:
🈯️ Устав проекта (Project Charter);
🈯️ Данные о ходе работ (Work Performance Data);
🈯️ Журнал изменений (Change Log);
🈯️ Выученные уроки (Lessons Learned).
Вопрос только в том, какой "толщины" будет "история болезни" у вашего пациента.
#beardthink #практика
О конференциях и стабильности.
Пришло мне на днях приглашение посетить украинскую онлайн-конференцию по управлению проектами. Программа была доступна и я потратил несколько минут на анализ.
Помимо традиционного для наших краев TBD вместо тем докладов некоторых спикеров, мое внимание привлек доклад, скриншот которого я привожу тут.
На дворе 2020 год, через год Аджайл Манифесту исполняется 20 лет. Это уже давно "новый ватерфол", который пытаются прислонить куда угодно - от маркетинга до бухгалтерий. А тема доклада "Что такое аджайл и аджайл мышление". И мы по-прежнему говорим о том, что "с аджайлом команды деливерят больше за то же время".
Я в шоке. Два года назад я написал статью о том, почему я перестал посещать мероприятия в Украине, и сегодня я перезалил его в оригинальном виде. Несмотря на устаревание некоторых цифр, факты остались теми же, и я огорчен тому, что за все это время в системе организации конференций в Украине не изменилось практически ничего.
А вы посетили бы такую конференцию?
#beardlearn #мероприятия
Пришло мне на днях приглашение посетить украинскую онлайн-конференцию по управлению проектами. Программа была доступна и я потратил несколько минут на анализ.
Помимо традиционного для наших краев TBD вместо тем докладов некоторых спикеров, мое внимание привлек доклад, скриншот которого я привожу тут.
На дворе 2020 год, через год Аджайл Манифесту исполняется 20 лет. Это уже давно "новый ватерфол", который пытаются прислонить куда угодно - от маркетинга до бухгалтерий. А тема доклада "Что такое аджайл и аджайл мышление". И мы по-прежнему говорим о том, что "с аджайлом команды деливерят больше за то же время".
Я в шоке. Два года назад я написал статью о том, почему я перестал посещать мероприятия в Украине, и сегодня я перезалил его в оригинальном виде. Несмотря на устаревание некоторых цифр, факты остались теми же, и я огорчен тому, что за все это время в системе организации конференций в Украине не изменилось практически ничего.
А вы посетили бы такую конференцию?
#beardlearn #мероприятия
О бесплатных вебинарах и рекламе.
В ковидное время множество программ обучения перекочевали онлайн, что логично и правильно. Изменилась и концепция продвижения этих программ. Перед их запуском нынче модно давать "бесплатные вебинары", чтобы закинуть наживку.
Все бы было ничего, но и я лично, и мои коллеги, кто делился опытом, отмечают стремительный перекос пропорции реклама/полезность в сторону первой. Расскажу такую историю. Недавно побывал на вебинаре по продажам, тема была действительно интересно заявлена. И каким-то образом я проспал момент, что этот вебинар предназначен для продажи буткемпа за много денег. Чтобы вы понимали абсурд ситуации, модератор вебинара рассказывала об этом буткемпе, буквально перебивая автора темы, пытаясь делать перебивки между разделами контента. Апофигеем этой феерии стала секция вопросов в конце вебинара, которая была просто прервана на 30% отвеченных вопросов в пользу дополнительной рекламы скидок на этот буткемп. И такие случаи в последнее время не единичны.
Чтобы не тратить свое время зря, поразмыслите над следующими пунктами:
🈯️ Увидев встречу в ФБ, оглянитесь в поисках организатора вебинара, найдите причину его запуска. 5 минут анализа могут сэкономить час-полтора вашего вечера.
🈯️ Посещайте мероприятия с темами, которые вас волнуют прямо сейчас. Если это для общего развития, быстрее будет прочесть блог.
🈯️ Конечно же, если вам интересно получить понимание о главном мероприятии, которое планируется, или получить на него скидку, это отличная возможность послушать спикера.
🈯️ Не стесняйтесь уходить с середины, если понимаете, что ситуация заходит в тупик. Ваше время - невозобновляемый ресурс.
🈯️ Самое главное и самое неприятное - не ждите чудес на бесплатных вебинарах. Бизнес есть бизнес, и если за информацию можно взять денег, за нее будут брать деньги. А если она бесплатна - значит, это кому-нибудь нужно =).
Этот несложный чеклист может легко сохранить вам пару-тройку часов в месяц на семью и друзей.
Подходите к своему обучению с умом. И хороших выходных!
#beardthink #beardlearn
В ковидное время множество программ обучения перекочевали онлайн, что логично и правильно. Изменилась и концепция продвижения этих программ. Перед их запуском нынче модно давать "бесплатные вебинары", чтобы закинуть наживку.
Все бы было ничего, но и я лично, и мои коллеги, кто делился опытом, отмечают стремительный перекос пропорции реклама/полезность в сторону первой. Расскажу такую историю. Недавно побывал на вебинаре по продажам, тема была действительно интересно заявлена. И каким-то образом я проспал момент, что этот вебинар предназначен для продажи буткемпа за много денег. Чтобы вы понимали абсурд ситуации, модератор вебинара рассказывала об этом буткемпе, буквально перебивая автора темы, пытаясь делать перебивки между разделами контента. Апофигеем этой феерии стала секция вопросов в конце вебинара, которая была просто прервана на 30% отвеченных вопросов в пользу дополнительной рекламы скидок на этот буткемп. И такие случаи в последнее время не единичны.
Чтобы не тратить свое время зря, поразмыслите над следующими пунктами:
🈯️ Увидев встречу в ФБ, оглянитесь в поисках организатора вебинара, найдите причину его запуска. 5 минут анализа могут сэкономить час-полтора вашего вечера.
🈯️ Посещайте мероприятия с темами, которые вас волнуют прямо сейчас. Если это для общего развития, быстрее будет прочесть блог.
🈯️ Конечно же, если вам интересно получить понимание о главном мероприятии, которое планируется, или получить на него скидку, это отличная возможность послушать спикера.
🈯️ Не стесняйтесь уходить с середины, если понимаете, что ситуация заходит в тупик. Ваше время - невозобновляемый ресурс.
🈯️ Самое главное и самое неприятное - не ждите чудес на бесплатных вебинарах. Бизнес есть бизнес, и если за информацию можно взять денег, за нее будут брать деньги. А если она бесплатна - значит, это кому-нибудь нужно =).
Этот несложный чеклист может легко сохранить вам пару-тройку часов в месяц на семью и друзей.
Подходите к своему обучению с умом. И хороших выходных!
#beardthink #beardlearn
О релизном планировании и слепоте от скорости.
Солидные 10% опрошенных ранее заявили, что Уставу проекта не место в гибких подходах. Давайте разберемся, так ли это.
В контексте продуктовой разработки, любой скраммастер скажет, что у нас есть Видение продукта и Цель спринта. Видение продукта - всеобъемлющая цель существования продукта, которая помогает направлять людей и принимать решения по развитию продукта. Цель Спринта - инструмент из Скрам Гайда, который разрабатывается в процессе планирования и отвечает команде на вопрос "зачем мы разрабатываем инкремент". Вроде бы все отлично и понятно. Проблемы начинают возникать на этапе, когда бизнесу становится интересно, а когда же функциональность, готовая для рынка (minimum marketable feature - MMF), до этого рынка дойдет. Или сколько времени (читай - денег) на нее нужно потратить, соответственно, как монетизироваться. Если мы взглянем на Видение продукта или Цель спринта, то мы найдем много вдохновения, у продвинутых владельцев продукта и скраммастеров - какие-то метрики. Отвечают ли они на заданные вопросы?
Нет. На заданные вопросы отвечает релизное планирование, которое многими либо критикуется, либо просто упускается по незнанию. Результатом которого должен быть артефакт, который задаст рамку на следующие несколько спринтов, а также поможет с управлением ожиданиями бизнеса и команды. На что же это может быть похоже? =)
Хорошо, хорошо, вы не хотите писать Устав. В конце концов, ребята на Lean Coffee засмеют. Что ж, у меня есть чем вам помочь:
🈯️ 1-Page Charter
🈯️ А3 Charter
🈯️ GO Product Roadmap
Эти инструменты работают прямо из коробки. Естественно, если есть понимание, вы вольны менять что угодно. К примеру, я часто использую GOPR с добавлением рисков и состава команды.
Релизное планирование - одно из средств борьбы с так называемой "слепотой от скорости" (Speed Blindness у Оливера Леманна). Этот феномен можно объяснить метафорой про тигриных жуков. Они являются одними из самых быстрых живых существ на планете. В то же время, ученых в свое время интересовал вопрос - почему, обладая такой скоростью, жук в погоне двигается зигзагами и с остановками? Причина оказалась в том, что насекомое движется так быстро, что натурально ничего не видит по сторонам. Поэтому оно вынуждено периодически останавливаться и осматриваться. И в нашем случае, Цель спринта слишком мала для обоснования выпуска массивных частей функциональности, а Видение продукта слишком далеко, чтобы на пути к нему ни разу не споткнуться. Именно для предотвращения "слепоты от скорости" нам и нужны путевые камни побольше (релизы) и их документация (аджайл-варианты Уставов).
Для более детальной информации рекомендую вот эту статью Романа Пихлера.
#beardthink #практика
Солидные 10% опрошенных ранее заявили, что Уставу проекта не место в гибких подходах. Давайте разберемся, так ли это.
В контексте продуктовой разработки, любой скраммастер скажет, что у нас есть Видение продукта и Цель спринта. Видение продукта - всеобъемлющая цель существования продукта, которая помогает направлять людей и принимать решения по развитию продукта. Цель Спринта - инструмент из Скрам Гайда, который разрабатывается в процессе планирования и отвечает команде на вопрос "зачем мы разрабатываем инкремент". Вроде бы все отлично и понятно. Проблемы начинают возникать на этапе, когда бизнесу становится интересно, а когда же функциональность, готовая для рынка (minimum marketable feature - MMF), до этого рынка дойдет. Или сколько времени (читай - денег) на нее нужно потратить, соответственно, как монетизироваться. Если мы взглянем на Видение продукта или Цель спринта, то мы найдем много вдохновения, у продвинутых владельцев продукта и скраммастеров - какие-то метрики. Отвечают ли они на заданные вопросы?
Нет. На заданные вопросы отвечает релизное планирование, которое многими либо критикуется, либо просто упускается по незнанию. Результатом которого должен быть артефакт, который задаст рамку на следующие несколько спринтов, а также поможет с управлением ожиданиями бизнеса и команды. На что же это может быть похоже? =)
Хорошо, хорошо, вы не хотите писать Устав. В конце концов, ребята на Lean Coffee засмеют. Что ж, у меня есть чем вам помочь:
🈯️ 1-Page Charter
🈯️ А3 Charter
🈯️ GO Product Roadmap
Эти инструменты работают прямо из коробки. Естественно, если есть понимание, вы вольны менять что угодно. К примеру, я часто использую GOPR с добавлением рисков и состава команды.
Релизное планирование - одно из средств борьбы с так называемой "слепотой от скорости" (Speed Blindness у Оливера Леманна). Этот феномен можно объяснить метафорой про тигриных жуков. Они являются одними из самых быстрых живых существ на планете. В то же время, ученых в свое время интересовал вопрос - почему, обладая такой скоростью, жук в погоне двигается зигзагами и с остановками? Причина оказалась в том, что насекомое движется так быстро, что натурально ничего не видит по сторонам. Поэтому оно вынуждено периодически останавливаться и осматриваться. И в нашем случае, Цель спринта слишком мала для обоснования выпуска массивных частей функциональности, а Видение продукта слишком далеко, чтобы на пути к нему ни разу не споткнуться. Именно для предотвращения "слепоты от скорости" нам и нужны путевые камни побольше (релизы) и их документация (аджайл-варианты Уставов).
Для более детальной информации рекомендую вот эту статью Романа Пихлера.
#beardthink #практика