В День знаний я начинаю делиться ими более активно.

Я открываю телеграм-канал для всех, кому интересны темы проектного управления, гибких подходов разработки программных продуктов, управления командами и многие другие.

Что будет в канале:
- зарисовки из трудовыебудней проектных (и не только) руководителей;
- обсуждение статей, книг, материалов, которые я использую в ежедневной работе;
- советы из собственного опыта касательно карьеры, обучения, и многого другого. Вообще, много собственного опыта =).

Stay tuned!

О навыках проектного менеджера и "треугольнике талантов".

Ко мне часто обращаются с вопросами "что должен знать проектный руководитель", "в моей компании никто не знает, как мне развиваться" и т.п. Хочу поделиться очень простой схемой от PMI (здесь и далее - Project Management Institute). Она называется PMI Talent Triangle.

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

- Техническая экспертиза (Technical Project Management) - знания, навыки и поведение, относящиеся к специфическому домену проектного, программного или портфельного управления. Иными словами, написание Устава проекта - это технический навык проектного менеджера (а не писать код).

- Лидерская экспертиза (Leadership) - знания, навыки и поведение, относящиеся к способностям направлять, мотивировать или руководить другими для достижения целей. Иными словами, целеполагание - это пример лидерства от проектного руководителя.

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

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

Примеры навыков из каждого домена - в официальном буклете от PMI.

Проверьте себя =)

#beardthink #карьера

О чеклистах и аджайле.

Уже много лет не стихают дискуссии о том, что же на самом деле входит в, не побоюсь так выразиться, Agile Body of Knowledge. Многие, к примеру, могли наблюдать комичную ситуацию со сбором подписей за то, чтобы создатели фреймворка SAFe удалили упоминания Scrum из него, ибо они не тру, а значит, нечего со свиным рылом, да в калашный ряд. Но я не об этом.

Недавно очередную попытку систематизации и стандартизации предпринял известный Юрген Аппелович Ротердамский, мой сосед с недавних пор (в одном городе живем). В своей рассылке он опубликовал чеклист, который он назвал "Big List of Agility, Innovation, and Leadership Topics". По задумке автора, это некий обзор тем, связанных с аджилити, инновациями и лидерством в организациях. Это довольно интересное чтиво, предлагаю и вам ознакомиться.

Несколько моих персональных наблюдений:
- Если присмотреться к этому чеклисту повнимательнее, то вам может показаться, что он больше относится к списку обязанностей идеальных COO и CEO, чем к гибкости и лидерству.
- Этот чеклист, в первую очередь, инструмент продаж. В письме Юрген говорит, что это темы, которым он обучает или о которых говорит на конференциях. Этим я могу объяснить большую избыточность этого перечня.
- Юрген Аппело не очень понимает Канбан Метод =).

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

P.S. Я перегнал простыню текста в майндмеп, оставив по паре примеров к некоторым секциям. Если очень заинтересует оригинал, дайте знать в комментариях.

#beardthink #agile

Я учел замечания по предыдущему посту. Поэтому отдаю ссылку на майндмеп с Big List of Agility, Innovation, and Leadership Topics by Jurgen Appelo.

Единственное - если вам очень интересно, скопируйте себе, потому что ссылка может пропасть через месяц-два =)

UPD: Я устал бороться с Миро, поэтому вот текстовая версия https://docs.google.com/document/d/17_-7t3KgMAq0bX9Np63Wx0DTAgzRwDwvjc5OsJoybcA/edit?usp=sharing

​​Когда вам говорят, что хороший менеджер найдет подход к любому стейкхолдеру.

#beardlaugh

О важности доменных знаний и странном рекрутинге.

В одном из немногих пока предыдущих постов, я вкратце рассказал о 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 #модели

О жизненных циклах и управлении ими.

Итак, в предыдущем посте мы разобрались с тем, что понятия "waterfall" как выстроенной системы управления проектом не существует. Как же тогда отличить Agile от всего-вот-этого остального? На помощь приходит концепция жизненных циклов.

Жизненный цикл проекта - это набор фаз, которые проект проходит от начала до закрытия. Ни больше, ни меньше. Количество этих фаз, их названия и характеристики зависят от руководителя проектов, а точнее, того, как будет организована работа в проекте. Как говорил один из моих тренеров, универсальные фазы для любого проекта - это "фаза 1", "фаза 2" и так далее =).

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

1️⃣Предиктивная модель. Именно ее имеют ввиду, когда говорят о waterfall, да-да. В фазах, подчиненных этой модели, ограничения определяются на ранних этапах, в дальнейшем изменения в базовые планы внимательно отслеживаются и управляются.
Ключевая фраза - "пообещали - сделаем".
Пример проекта или фазы - прототипирование. Когда мы имеем проблему и четкое понимание усилий для ее проработки, нет ничего зазорного спланировать разработку прототипа загодя. Из моей практики, подобные timeboxed фазы являются отличным началом любого большого проекта.

2️⃣Итеративная модель. Несмотря на то, что конечная цель ясна на ранних этапах, точные затраты по времени и деньга могут пересматриваться через определенные промежутки времени. Именно по этой модели работает множество команд, уверенных в собственном Скраме, тогда как они просто работают над годичным проектом месячными итерациями.
Ключевая фраза - Мы не стремимся сделать все идеально с первой попытки.
Пример проекта или фазы - миграция. К примеру, ваша компания мигрирует с одной СRM на другую. Если представить себе, что разные отделы или филиалы переходят на новую систему не в один присест, потому что это очень рискованно, то мы и получим ситуацию, когда содержание проекта известно достаточно заранее, но исполнение проекта разбивается на итерации.

3️⃣Инкрементальная модель. Ключевым отличием от итеративной модели является обязательное наличие инкремента - полностью готового фрагмента функциональности, который встраивается в существующий продукт.
Ключевая фраза - Мы не стремимся сделать все за один раз.
Пример проекта или фазы - обновление продукта. Переход, положим, от версии 1.1 к 1.2 продукта означает создание рабочей "надстройки" над предыдущей версией. Таким образом, мы не просто итерируем во времени, но и создаем рабочую функциональность end-to-end.

4️⃣Адаптивная модель, или Agile подход. Эта модель совмещает в себе ключевые выгоды итеративного и инкрементального подходов. Детали ограничений и обязательств обсуждаются и фиксируются на итерацию или несколько, допуская не только изменения в требованиях, но и гибкость высокоуровневых стратегий и видения финального результата. Ключевые факторы успеха - частые инкрементные поставки и плотное вовлечение заинтересованных лиц.
Ключевая фраза - Мы делаем лучшее из возможного на данный момент.
Пример проекта или фазы - первая версия нового продукта. В ситуации наличия гипотез, которые необходимо проверять как можно скорее, собирая обратную связь и адаптируя планы по развитию продукта на ходу, любая другая модель разработки чревата лишней работой без каких-либо выгод.

5️⃣Гибридная модель. Интересно, что в реальной жизни гораздо чаще встречаются гибридные комбинации первых четырех моделей. Пример такого подхода я приведу в одном из следующих постов более детально.

Надеюсь, эта информация поможет вам планировать ваши проекты более осознанно.

#beardthink #модели

О контролируемых инновациях и гибридном жизненном цикле разработки.

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

Клиентом является отдел инноваций компании в индустрии maritime, непосредственный спонсор программы это их CIO. Одной из ключевых особенностей этого сектора является высокая задокументированность, поэтому большинство инновационных решений для них - это оптимизация внутренних бизнес-процессов путем цифровизации, улучшения обработки данных и т.п. При этом, стейкхолдеры довольно консервативны и не готовы просто разбрасываться деньгами. Методом проб и ошибок, мы выстроили фреймворк двухфазных проектов, который негласно именуем "контролируемыми инновациями":

1️⃣ фаза проекта называется "research". Входом к началу фазы является бизнес-кейс от клиента с описанием некоторой проблемы и возможных гипотез о ее решении. В этой фазе мы работаем в agile режиме, с недельными спринтами. Команда состоит из сервис-дизайнеров, им ассистируют ux/ui дизайнеры и разработчики. Затраты проекта зафиксированы поспринтово.
Целью этой фазы является обоснование проблемы, подтверждение возможностей ее решения. Нередко, эту фазу мы заканчиваем дизайн-спринтом. Воротами фазы является Project Charter следующей фазы, в который мы включаем оценку трудозатрат и все остальные детали более точного планирования решения проблемы. Иногда, вторая фаза отменяется, если заранее понятно, к примеру, что проблема не стоит инвестиций или на текущий момент ее можно решить другими способами.

2️⃣ фазу мы называем "implementation" и она подчинена предиктивной модели. Мы берем на себя обязательства по решению проблемы на основании результатов исследований, проведенных в предыдущей фазе. Мы следуем Firm Fixed Price модели в составлении затрат на эту фазу. Целью этой фазы является разработка и внедрение решения бизнес-проблемы клиента.

Этот короткий пример показывает, как, анализируя поведение стейкхолдеров и характер их бизнеса, можно выстроить гибридную модель жизненного цикла разработки, которая совмещает в себе плюсы разных методов. В нашем случае, мы имеем необходимую гибкость для исследования проблемы и путей решения (я уверен, особо внимательные читатели увидели влияние Дизайн Мышления), а клиент доволен тем, что затраты находятся под четким контролем. На данный момент, по этой программе мы имеем уровень удовлетворенности клиента не менее 8/10 за проект.

Стоит добавить, что разработку подобных подходов имеет смысл ожидать от проектных руководителей Middle+ уровня.

#beardthink #модели