Если внезапно вам захочется изучить управление проектами, то я рекомендую к прочтению книгу "Rita Mulcahy's PMP® Exam Prep, Tenth Edition"
Это превосходная книжка про управление проектами в общем, несмотря на то, что в названии упоминается подготовка к PMP экзамену:)
Забавно, что стиль изложения этой книги отлично подходит для большинства людей, в то время, когда PMBOK Guide (официальный свод знаний по управлению проектам) читается с таким скрипом, что кажется написанным в расчете на прочтение людьми с обсессивно компульсивным расстройством личности, одержимых именно этой книгой (иначе её не прочитать).
В общем, PMBOK прочитать разок точно стоит, а вот для понимания предмета стоит внимательно изучить PMP Exam Prep от Риты:)

P.S.
Я сам лет пять назад сдавал PMP экзамен по управлению проектами, чтобы стать сертифицированным project manager и книга Риты мне очень помогла:)

#Management #Project #ProjectManagement

В продолжении темы про управление проектам могу порекомендовать достаточно полезную базовую лекцию от ребят из Yandex.
В этой лекции спикер успевает рассказать про
- Историю проектного управления от начала времен и до наших дней
- Как управлять проектом (база про жизненный цикл и группы процессов из PMBoK)
- В чем состоит ответственность руководителя проекта и какие качества должны быть у успешного руководителя проектов
- Пример проекта из Yandex Taxi
- Что стоит учесть при планировании проекта
- Пример релизного флоу, который надо учитывать при планировании
- Как синкать статусы по проекту и писать meeting notes
- Как понимать, что все идет по плану
- ... Что делать, если что-то пошло не так
- Как держать всех в курсе происходящего
- Что делать перед релизом
- Как подводить итоги проекта и как оформить результаты
- Как порадовать команду
- И что делать после запуска -> поддерживать и развивать получившийся продукт

#ProjectManagement #Project #Management #Processes

Мифический человеко-месяц (The Mythical Man-Month)

Эту книгу написал Фредерик Брукс и она была издана впервые в 1975 году и с тех пор она стала классикой жанра.
Стоит ли ее читать почти через сорок лет после издания?
Определенно стоит и вот почему
- Книга посвящена управлению программными проектам и основана на опыте Брукса в IBM, где он участвовал в управлении проектом по созданию OS/360 (в то время, когда я начинал знакомиться с компьютерами от этого проекта от этого проекта остались только мышки с круглым штекером PS/2)
- Управление программными проектами со времен Брукса страдает от похожих проблем и полезно о них прочитать заранее, чтобы попробовать обойти
- Книгу растащили на цитаты и мем, например
-- "Девять женщин не родят ребенка за месяц"
-- "Если проект не укладывается в сроки, то добавление рабочей силы задержит его ещё больше"
-- "Закон второй системы: Программист, разрабатывающий свою вторую систему, склонен добавлять все те возможности, которые он не смог добавить в свою первую систему"
-- "Мифический человеко-месяц" (вынесенное в название книги выражение про оценку трудозатрат)
-- "Серебрянной пули нет" (вынесенное в название одной из глав идея о том, что универсальной таблетки от всего не бывает)
- В общем, чтение этой книги must have для всех технических руководителей, начиная с тимлида и выше. Не только потому, что она крутая, но и потому, что референсы и отсылки к этой книге есть почти в любой другой литературе по менеджменту IT проектов/процессов/продуктов ...

Отдельно отмечу, что книга написана хорошим языком и читается очень приятно.

#Processes #Project #ProjectManagement #Management #Software #SoftwareDevelopment

Критическая цепь (Critical Chain)

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

Например, в классическом project management'е используется структурная декомпозиция работ (WBS) в том числе для уменьшения стандартного отклонения в оценке длительности проекта за счет применения закона больших чисел и центральной предельной теоремы. Объясню на примере:
Если у нас:
1) N задач в WBS
2) оценка длительности задач в WBS приблизительно одинакового масштаба
3)они слабо зависимы и случайно распределены с одинаковым стандартным отклонением x (для простоты)
То:
1) общая оценки длительности проекта равна сумме оценок длительности задач
2) стандартное отклонение оценки длительности проекта равно x делить на корень из N
3) то есть теоретически мы получаем оценку длительности проекта довольно точно
Но в книге Годратта показывается, что обычно в проектах: "Опоздание одного элемента полностью передается следующему элементу. Выигрыш по времени достигнутый одним элементом, как правило, разбазаривается". Если это действительно так (а это очень похоже на правду для многих проектов), то оптимистичный прогноз стандартного отклонения для оценки длительности проекта, указанный выше, уже не срабатывает:) Что приводит к проблемам в запаздывании проектов.
Таких интересных идей в книге довольно много, поэтому её можно рекомендовать к прочтению. Благо читается она легко и быстро.

#Management #Processes #Project #ProjectManagement

Теория ограничений Голдратта (Goldratt's Theory of Constraints: A Systems Approach to Continuous Improvement)

Сразу после производственных романов Голдратта стоит прочитать эту книгу Уильяма Детмера - в ней в структурированном виде изложены те идеи, которые сам Голдратт подавал через свои истории.
Книга начинается с введения в теорию ограничений, дальше идет базис по формальной логике, а именно то, что называется Критериями проверки логических построений.
Дальше читатель знакомится с деревьями текущей и будущей реальности, хотя между ними в книге пролегает диаграмма разрешения конфликта:) а соединяет их дерево перехода:)
Дальше дерево перехода превращается волшебным движением руки в план преобразований.
А финализируется книга групповой динамикой при использовании метода рассуждений Голдратта.

P.S.
Понравились практические упражнения на последних страницах книги, размещенные в приложениях.
Особенно понравилось приложение 5, где предлагают построить дерево будущей реальности, основанное на решении о вступлении в брак:)
Забавно, что это практическое упражнение могло бы помочь многим людям, а не только апологетам теории ограничений Голдратта:)

#ProjectManagement #Management #Processes

Проектный бизнес - Адаптированная модель для России

Эту книгу Сергея Мишина, вышедшую в 2006 году, я читал 15 лет назад и она мне сильно помогла разобраться с темой управления проектами.
Суть в том, что в этой книге автор помимо практических советов еще и объясняет почему стоит делать именно так. Например, в посте про книгу Критическую цепь я рассказывал про связь WBS (Work Breakdown Structure) и закон больших чисел - про это я узнал из это книги Мишина.
Кроме того, автор в первой части своей книги рассказывает о мифах проектного управления, общую модель проектного бизнеса, аспекты общего управления, вопросы позиционирования, система и иерархия моделей проектного бизнеса, продукты, ресурсы, среда проекта и субъекты управления. Здесь же автор проводит некоторое сравнение моделей IPMA и PMI (правда сами версии, которые сравнивает автор уже сильно устарели).
Во второй части книги автор приводит свою версию минимальной модели, которая требуется для введения практики проектного бизнеса в компании:
- проведение аудита текущей системы
- введение предложенной автором минимальной модели, включающей разработанные им стандарты, формы и методические рекомендации, которые можно и нужно подстроить под бизнес компании.

Итого:
- книга действительно хорошая и актуальна большей частью до сих пор
- книга в виде pfg доступна на личном сайте автора

#ProjectManagement #Processes #Project #Management

Илья Якямсев — Как перестать управлять и начать работать

Отличное выступление про менеджмент от Ильи Якямсева, которому уже лет 5 и про которое мне напомнил fb:) Это выступление было в жанре стендап, где слайды просто отмечают перебивки тем. Не со всеми тезисами в докладе я согласен, но по большой части там про менеджмент и софт-скиллы без булшита и практично. Интересно, что дальше Илья стал профессиональным стендап комиком, у которого есть хороший канал, видео с которого я иногда смотрю. В общем, рекомендую выступления Ильи к просмотру.

#Management #Processes #ProjectManagement #Project #Software #SoftwareDevelopment #Engineering

Додо Книга 1

Вчера по дороге с работы прочитал эту книгу от ребят из Додо, которая была издана в далеком 2017 года. Рассказывать про содержание книги скучно, так как вы все сами сможете прочитать при желании (книга есть на сайте dodbrands.io), но стоит поговорить о другом
- Книга как маркетинг - в этой книге авторский коллектив пропагандирует культуру и ценности компании, продавая не пиццу, а миф о пицце из Додо, где всегда чисто, готовят из свежих продуктов и доставляют в течение часа
- Книга как история людей - каждая глава как в хорошем западном научпопе начинается с истории конкретного человека, который открывает магазин, моет полы, стоит на кассе, идет зимой на работу и падает в сугроб ... и все это потом вплетается в миф о Додо пицце, где каждый из этих близких и понятных нам людей становится чуть ли не титаном, который продвинул Додо куда-то вперед
- Книга как набор принципов и подходов - кайдзен, гемба, blameless культура без штрафов, как доверять клиентам, системный подход, теория ограничений и бережливое производство, хайп на горячих темах, модель франчайзи, краудинвестинг - в общем, все эти слова не просто вставлены в фразу навроде "Я знаю карате, кунфу и ... другие крутые слова", а логично вплетены в повестование
- Книга как подарок - помню лет 5 назад эти книги привозили и клиентам, что заказывали просто Додо пицццу - думаю, что тут мысль была в том, что получить подарок и сьесть пиццу с собственной историей приятнее, чем без нее. Этакая современная реализация "хлеба и зрелищ":)

Интересно, что начинание было признано успешным и в 2021 году вышла Додо Книга 2

#Management #Marketing #Leadership #Processes #ProductManagement #ProjectManagement

Как формировать структуру команд под запросы бизнеса - часть 1

Последние 7 лет я работаю в Тинькофф и за это время видел и отвечал за большое количество изменений: организационных, продуктовых и инженерных. Про многие из них я уже рассказывал в выступлениях и статьях, но там был обычно фокус на конкретном изменении. А в этом посте я бы хотел поговорить про принципы дизайна команд и управленческой структуры, без которых мне было бы гораздо сложнее понимать а что надо менять и почему именно так. Для этого надо вспомнить про несколько базовых вещей

- Подход working backwards или backcasting - о том, что начинать лучше с конца, представляя цель изменений и финальный результат.
- Закон Конвея - утверждение Мелвина Конвея про то, что организации проектируют системы, которые копируют структуру коммуникаций в этой организации
- Обратный маневр Конвея - подход, который рекомендует эволюционировать структуру команд и организационную структуру так, чтобы продвигать желаемую архитектуру в организации.
- Топология команд (Team topology)- плодотворный подход с набором паттернов для структурирования типов команд и их взаимодействий, который вводит 4 вида команд: stream-aligned, platform, enabling, complicated subsystem и три вида взаимодействий: collaboration, facilitating, x-as-a-service.
- Управление измнениями (Change management) - набор подходов для того, чтобы осуществлять изменения на всех уровнях: индивидуальном, командном и организационном.
Теперь, когда я упомянул про сами концепции, то можно описать мой подход к формированию структуры управления.

Алгоритм приблизительно такой
1. Определить какая сейчас долговременная цель у той части компании, за которую вы отвечаете
2. Оценить какая архитектура систем подходит наилучшим образом под эту цель
3. Применить обратный маневр Конвея, чтобы понять какая структура команд будет поддерживать желаемую архитектуру
4. Использовать паттерны из team topologies, чтобы спроектировать структуру команд и виды их взаимодействия
5. Использовать менеджмент изменений, чтобы все спланировать и осуществить (про организационный и командный уровень мы поговорили выше, а индивидуальный здесь обсуждать не будем)

В следующей части я расскажу про применение этого алгоритма в 4 сценариях:
- Проект (запуск новой инициативы)
- Развитие продукта (просто продуктовая разработка)
- Масштабирование разработки вверх (scaling up)
- Масштабирование разработки вниз (scaling down)
Все этапы я в свое время проходил на практике и про многие даже рассказывал:)

P.S.
Накидаю источников для изучения
- Про backcasting мы обсуждали в серии Code of Architecture про Technology Strategy Patterns
- Про working backwards написана целая книга
- Про закон Конвея можно почитать в wikipedia
- Обратный маневр Конвея в 2014 году попал в техрадар от ThoughtWorks
- Про team topologies можно почитать мои краткие саммари: Teams as means of Delivery, Team Topologies that work for flow, Evolving team interactions for innovation and rapid delivery
- Про управление изменениями классно написано в книге "Наш айсберг тает", про которую я уже писал

#Management #Leadership #Processes #ProjectManagement #Project #Software #SoftwareDevelopment

Coaching Teams Through Team Change • Heidi Helfand • GOTO 2023

Софтовый доклад от Heidi Helfand, в котором она рассказывает про то, как проводить изменения в командах. Отдельно стоит отметить, что Heidi - автор книги "Dynamic Reteaming", и в этом докладе она кратко рассказывает содержимое своей книги. Она начинает со своего карьерного пути в IT, который стартанул в стартапе еще до бума доткомов. Сначала стартап рос, но потом сделал pivot, так как у оригинального продукта не было достаточного market fit. В итоге, перешлось переигрывать состав команд. Дальше автор приводит примеры причин, по которым командам надо меняться
- Products cancelled
- Growth/attrition
- New work or priority
- Knowledge sharing
- Stagnation & learning
И отдельно автор отмечает, что когда ваши команды меняются, то это не значит, что вы сделали что-то не так. И даже более того, можно сидеть и (не)ждать изменений, а выступить их катализатором и отчасти ими управлять:) Дальше автор рассказаыват про 5 самоочевидных паттернов изменений команд
- One by one pattern - добавление людей в команду по одному
- Grow & split pattern - рост команды и разделение ее на отдельные части (зачастую 2 части)
- Merging pattern - объединение двух отдельных команд в одну общую
- Isolation pattern - сбор общей команды из отдельных индивидуумов, которых забирают из их команд
- Switching pattern - переход одного человека из одной команды в другую
Дальше автор отмечает, что делать все эти изменения ради самих изменений не стоит:) Но изменения - это привычный наш спутник, поэтому к ним надо быть готовым. Автор показывает знак бесконечности (∞), который символизирует непрерывные изменения (а не только devops), а дальше переходит к софтовым историям про то, как с этим всем жить:) Их я пересказывать не буду, так как есть оригинальное выступление и слайды презентаций, которые доступны здесь.

#Management #Leadership #Processes #ProjectManagement #Project #Software #SoftwareDevelopment

Как формировать структуру команд под запросы бизнеса - часть 2

Продолжу пост про структуру команд, в котором поговорю про проектный менеджмент. Мне кажется, что каждый менеджер должен уметь работать в рамках проекта, который PMI (Project Management Institute) определяет как

Project is a temporary endeavor undertaken to create a unique product, service or result

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

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

В Тинькофф у меня было достаточное количество возможностей для применения проектного подхода и я расскажу про оба варианта на примере

1) Проект переезда web привлечения на новую версию Tinkoff.ru (примерно 7 лет назад)
С этого проекта началась моя карьера в Тинькофф
- Проект переезда на новое решение к моему приходу длился уже больше года
- Над ним работало 50+ человек
- Моя зона ответственности была только в страницах привлечения и формах привлечения, над которыми работало 3 человека
- До переезда оставалось 3 месяца, а на новом решении не работали ключевые вещи: не работал SSR (кто-то ошибся с расчетом нагрузки), не работала аналитика (SPA приложения требовали переделать трекинг), не работали многие механики на формах, а также релизы занимали недели из-за ручного регресса.

Мы сделали этот проект в авральном режиме, успешно переехали и дальше начали развивать приложение как продукт. За три года наши страницы привлечения выросли до всей публичной части Tinkoff.ru, включая все продукты, а команда до 50 человек в 7+ командах. Многие ребята, с которыми мы затянули этот проект и развивали продукт до сих пор со мной. Подробнее про этот проект, переросший в продукт, можно посмотреть в моем выступлении на ArchDays 2019

2) Проект запуска отдельных продуктовых команд и процессов в мобильном банке Тинькофф (примерно 4 года назад)
Этот проект стал вызовом для меня - именно с ним я вышел за границы привлечения.
- Проект перехода на продуктовую структуру команд от одной команды в 50 человек длился уже полгода, но шел с пробуксовкой
- Запрос был в том, чтобы повторить для мобильного банка путь по разъезду на отдельные продуктовые команды, который я проходил в web.
- Здесь вызовом было то, что команда была сложившаяся и требовалось гораздо лучше уметь в change management.

Проект изменений мы запустили за три месяца, но я в это время проводил в среднем по 3 интервью в день, не считая разнообразные синки. Так как эти первые три месяца я работал в режиме привлеченного руководителя, то я почувствовал как сложно идут изменения, когда ты работаешь из позиции консультанта, пускай и внутреннего. Этот проект тоже перерос в большую продуктовую историю, про которую я рассказывал в нескольких частях
- В апреле 2021 года "Как мы меняли разработку лучшего* мобильного банка под требования бизнеса"
- В сентябре 2022 года "Канал. Продукт. Платформа” или эволюция подходов к развитию мобильного банка Тинькофф"

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

#Management #Leadership #Project #ProjectManagement #SoftwareDevelopment #Software

Материалы к выступлению на YaTalks про то, как формировать структуру команд под запросы бизнеса

Сегодня в 12.00 я выступаю на YaTalks и традиционно выкладываю сюда материалы, которые я рекомендую для изучения после доклада
Сначала список инструментов, которые я считаю полезными в этом вопросе
- Про backcasting мы обсуждали в серии Code of Architecture про Technology Strategy Patterns
- Про working backwards написана целая книга
- Про управление проектами я рассуждал в статье про три П "Проект, продукт, процесс"
- Про закон Конвея можно почитать в wikipedia
- Обратный маневр Конвея в 2014 году попал в техрадар от ThoughtWorks
- Про team topologies можно почитать мои краткие саммари: Teams as means of Delivery, Team Topologies that work for flow, Evolving team interactions for innovation and rapid delivery
- Про управление изменениями классно написано в книге "Наш айсберг тает", про которую я уже писал

Дальше идут ссылки на материалы, в который я подробнее рассказывал про изменения, о которых упоминаю в докладе на YaTalks
- Доклад на Teamlead Conf 2018 про масштабирование фронтовых команд Tinkoff.ru с управленческой точки зрения
- Доклад на ArchDays 2019 про эволюцию всей связки фронт - бек - система a/b тестов, где фокус больше на архитектурных изменениях
- Доклад на Techlead Conf 2021 про платформизацию мобильного банка Тинькофф с целью создать автономные мобильные команды для каждой бизнес-линии (есть текстовая версия в моем блоге)
- Доклад на Highload++ 2022 про создание stream-aligned команд на базе отдельных мобильных и api команд, которые уже больше похоже на кросс-функциональные, передачу их под руководство CTO бизнес-вертикали и некий technical governance от платформы мобильного банка (и текстовая версия в моем блоге)
- Книга "Learning DDD", в которой хорошо изложены стратегические концепции DDD и которую я активно использовал при проектировании новой оргсхемы своего юнита почти на тысячу человек

P.S.
Ну и можно прочитать пока пару постов из серии, в которой я сегодняшний доклад описываю в текстовом виде
- Тезисно идея доклада, описание инструментов и алгоритмов
- Про проекты и примеры из практики
Пока там только два поста, но после выступления я запилю оставшиеся части:)

#Management #Leadership #Project #ProjectManagement #SoftwareDevelopment #Software