The Art of Project Management (Искусство управления IT-проектами) - Part I (Рубрика #Management)

Это одна из первых книг по управлению проектами, которую я прочитал еще в начале своей карьеры. Книгу написал Скотт Беркун в 2005 году, а в 2007 году она была переведена на русский язык издательством Питер. В это время я заканчивал университет и у нас был отдельный предмет "Управление проектами", который нам рассказывали ребята из СОВНЕТ (это российская часть международной ассоциации IPMA). В общем, ребята были достаточно формальны и мне хотелось изучить что-то более технологичное без налета госпроектов - так я набрел на эту книгу и не пожалел. Скотт написал книгу по итогам своих 10 лет работы в Microsoft, которую он начинал с инженерной должности, а потом перешел на позицию руководителя программ. В этой должности он работал над Microsoft Office, Visual Basic и предшественниками Internet Explorer 6.0 (богомерзкой хрени из прошлого).

Сама книга местами актуальна до сих пор, но вот отсылки к инженерным процессам смогут понять только опытные ребята, которые писали код в те времена:)
Книга состоит из четырех частей, а здесь мы разберем первые две:
- Part 0. Preface
- Part 1. Plans
- Part 2. Skills
- Part 3. Management

Part 0. Preface
1) A brief history of project management (and why you should care) - здесь Скотт рассказывает, что управление проектами было с нами давно, но раньше его так не называли

Part 1. Plans
2) The truth about schedules
Панирование и календарные сроки направлены на закрытие трех целей
- Определить сроки
- Определить участников проекта
- Создать средство для контроля выполнения проекта
Но надо понимать, что планы - это вероятностная история. Сами планы создаются с использованием подхода разделяй и властвуй, а высокорисковые работы планируются в первую очередь, чтобы снизить неопределенность планов.

3) How to figure out what to do
На проект стоит взглянуть с трех точек зрения: бизнесмена, инженера и потребителя
- Бизнес - как мы заработаем на этом проекте (PnL)
- Инженер - как мы сможем спроектировать и реализовать запланированное
- Потребитель - что именно требуется потребителю, а точнее какой набор возможностей должен быть в нашем продукте
Чтобы проект удался требуется сбалансировать эти три взгляда, а дальше зафиксировать их в виде отдельных документов - тут автор приводит достаточно тяжеловесные примеры артефактов, что были популярные тогда (market requirement document, work brakedown structure)

4) Writing the good vision
Здесь Скотт рассказывает про создание хорошей концепции, которая должна быть простой, целенаправленной, вдохновляющей способной консолидировать и которую при этом можно запомнить:) Скотт считает, что у хорошей концепции только один автор. Желательно сделать краткую и емкую концепцию, а не объемную и размытую.

5) Where ideas come from
Здесь автор рассказывает про разрыв между проблемами и решениями. Здесь автор говорит про креативность и вспоминает про дивергентное и конвергентное мышление. Он выдает тезисы, которыые отвечают на вопрос в названии главы
- Источником хороших идей становятся хорошие вопросы. Это примерно то же самое, что хороший вопрос - это уже половина ответа.
- Источником хороших идей становятся плохие идеи
Множество хороших идей приводят к хорошему проекту. Проектирование часто стоит начинать от потребителя, а не от технологии.

6) What to do with ideas once you have them
Генерация идей - это круто, но главное не увлечься. Изначально новые идеи стоит группировать в похожие и проверять их на прототипах. По мере движения к заврешению проекта остается все меньше пространства для экспериментов и внесения изменений, поэтому приходящие идеи можно запоминать до следующего проектка:)

Продолжение в следующих постах

#Management #Agile #Project #Leadership #SelfDevelopment #Software #Processes

Platform Strategy - Gregor Hohpe & James Lewis - GOTO 2024 (Рубрика #Architecture)

Это интересное интервью ребят из книжного клуба GOTO с Gregor Hohpe, который написал недавно очень интересную книгу "Platform Strategy". Gregor - тертый калач и я уже как-то рассказывал про его достижения, среди которых написание книг "Enterprise Integration Patterns" (мой пост о книге), "The Software Architect Elevator" (мой пост о книге), "Cloud Strategy", которую я ее еще не читал и "Platform strategy", которую я читаю сейчас и о которой идет речь.

Основныые тезисы в интервью следующие
- Платформы важны, потому что они помогают снизить когнитивную нагрузку на инженеров
- Классификация платформ: base platform (навроде AWS), а также кастомные платформы внутри компаний, которые должны не повторять AWS, а закрывать специфичные для компании сценарии. На эту тему Грегор рассказывал доклад "Build abstractions not illusions", про который я уже рассказывал. В общем, платформы могут создавать иллюзии простоты, но на самом деле могут быть сложными и требовать принятия решений.
- Платформы должны предоставлять полезные абстракции для создателей приложений и не вводить в заблуждение. Здесь автор вспоминает про книгу "The Software Architect Elevator" и говорит о том, что если для правильного использования платформы требуется погружаться в детали реализации абстракции, то что-то не так с платформой
- Грегор рассказывает про переименование разнообразных систем в платформы. И для того, чтобы понять платформа ли перед вами надо помнить, что платформы не должны делать все за вас, а должны облегчать выполнение задач.
- Во время создания платформ важно общаться с командами разработчиков и наблюдать за тем, что они делают, чтобы понять, как они решают проблемы. А сам Грегор часто помогает командам понять, что они на самом деле сделали, и как это может быть использовано в других контекстах.
- Метафоры могут помочь людям мыслить по-другому и повысить прозрачность в общении. Собственно, сам Грегор использует автомобильные метафоры для рассказа о платформах - в автоиндустрии уже давно начали использовать платформы для шасси, а сверху лепили чуток отличающиеся кузовы. Затраты на создание шасси фактически разделяются между разными моделями автомобилей
- Собственно хорошие платформы гармонизируют основу, а поверх нее позволяют расцвести инновациям - так было в мире автомобилей и то же самое мы видим в мире облачных платформ
- Стандартизация может быть инструментом для инноваций, но важно не превращать ее в самоцель. Это просто инструмент для достижения целей
- Когда мы задумываемся об изменениях, то надо понимать как ограничения, которые устраняются, могут влиять на мировоззрение людей и их работу. Этот переход к новой парадигме может быть трудным для людей, но это может привести к новым возможностям и ограничениям. Одновременно важно задавать вопросы о том, а какие новые ограничения возникают вместе с новыми технологиями.
- При создании внутренней платформы разработки в компании надо создать платформу, которая будет полезна для бизнеса, а не просто для инженеров. Она должна быть сосредоточена на том, что важно для бизнеса, а не на технических аспектах.
- Экономика внутренней платформы может быть хуже, чем у облачного провайдера, из-за меньшего масштаба. Кроме того, она может быть связана с вопросами ценности и долговечности продуктов.

В будущем Грегор планирует написать книгу о стратегии API и интеграции, которая будет учитывать границы и поможет людям усвоить эти концепции. Это будет в некотором роде продолжение книги "Enterprise Integration Patterns", которая вышла больше 20 лет назад.

#Conference #PlatformEngineering #SystemEngineering #Software #Architecture #DistributedSystems #Management

The Art of Project Management (Искусство управления IT-проектами) - Part II (Рубрика #Management)

Продолжая рассказ про эту книгу Скотта Беркуна, начатый ранее, я хотел бы поговорить про вторую часть книги под "Skills"

7) Writing good specifications
Автор рассказывает о том, что хорошая спецификация дает тройную пользу
- Дает направление и некоторые гарантии создания нужного продукта
- Фиксирует контрольную точку, когда завершается планирование проекта
- Дает возможность обсуждения и сбора отзывов о том, куда движется проект
Составление спецификаций - это не то же самое, что проектирование, так как мы тут описываем что хотим сделать, а не как.

8) How to make good decisions
Для начала надо научиться принимать решение о том, а каким решениям надо уделать время, а какие принимать не раздумывая. Важно понимать последствия решения перед тем, как тратить на них свое время. Надо уметь сравнивать заслуживающие внимания решения по списку критериев. Информация и данные не примут решения за вас, поэтому не стоит постоянно пытаться собрать больше данных:)

9) Communication and relationships
Проект движется вперед при помощи общения людей в команде, причем важно качество общения. Хорошие взаимоотношения улучшают и ускорят общение, а плохие могут парализовать проект. Существуют типичные проблемы в общении, которые хороший руководитель проектов должен уметь идентифицировать и фиксить:
- Неверные предположения
- Отсутствие ясности изложения
- Нежелание слушать
- Диктат
- Подмена понятий
- Персональные нападки и упреки
Для улучшения взаимоотношений часто достаточно распределить и зафиксировать роли

10) How not to annoy people: process, email, and meetings
В этой главе автор рассказывает как не раздражать других людей, сделав неинвазивные процессы, а также соблюдая базовые правила отправки писем и проведения совещаний. В принципе, советы дельные, но достаточно базовые

11) What to do when things go wrong
Здесь автор классно рассказывает о том, как вести себя во время сложной ситуации. Начать надо с того, что сохранять спокойствие и попробовать действовать по принципу разделяй и властвуй, отдельно решая под-проблемы, входящие в одну общую. Автор разбирает как действовать в стандартных ситуациях: когда был просчет в расписании, вас принуждают к нерациональным действиям, у вас дефицит ресурсов, низкое качество проекта, поменялось направление или даже если есть угроза мятежа. Важно принять на себя ответственность и дальше взять решение проблемы в свои руки. Тут же автор дает базу по ведению переговоров и разграничению полномочий при решении проблем. Заканчивается глава тем, как люди реагируют на давление обстоятельств (по разному)

Окончание рассказа в следующем посте

#Management #Agile #Project #Leadership #SelfDevelopment #Software #Processes

Дисциплины в университете: что изучают студенты ФКН (Рубрика #Career)

Недавно вышел интересный эпизод подкаста "Уютный ФКНчик", в котором обсуждается прикладное значение курсов, которым обучают в университете и их полезность в дальнейшей карьере. Подкаст интересен темой и своим звездным составом
- Евгений Соколов - ведущий подкаста, а также научный руководитель Центра непрерывного образования ФКН, академический руководитель образовательной программы «Прикладная математика и информатика» ФКН
- Иван Пузыревский - гость подкаста, а также директор по технологиям в Yandex Cloud
- Игорь Маслов - гость подкаста, а также директор базовых технологий в Т-Банке

Ребята за час успевают обсудить кучу вопросов, которые могут помочь не только студенту, но и уже сложившемуся инженеру понять как ему прокачиваться дальше
- Сколько и каких языков программирования надо знать хорошему специалисту;
- Что нужно знать про операционные системы, чтобы устроиться в Yandex Cloud;
- Зачем на собеседованиях требуют знания алгоритмов и структур данных;
- Почему необходимо изучать математику и как она пригождается на практике;
- Нужно ли машинное обучение классическим разработчикам;
- Как писать безопасный код и что для этого надо знать.

Подкаст организован Центром непрерывного образования ФКН совместно с Т-Банком.

P.S.
Я с большим интересом послушал этот подкаст, но еще интереснее общаться на эти темы с ребятами вживую:)

#Career #Software #Architecture #SystemEngineering #Engineering

Creating Software with Modern Diagramming Techniques - Ashley Peacock & Stefan Hofer - GOTO Club (Рубрика #Architecture)

Во время прогулки с собакой решил послушать выпуск подкаста конференции GOTO и выбрал обсуждение книги про рисование диаграмм "Creating Software with Modern Diagramming Techniques". Иронично, что это аудиовыпуск, в котором нет ни одного изображения не то, что диаграмм, но и участников выпуска:) Но меня это не смутило, так как я рисовал много диаграмм и пользовался всеми упоминаемыми инструментами сам. Эшли написал книгу "Creating Software with Modern Diagramming Techniques" для того, чтобы рассказать новому поколению разработчиков о том, что было хайпом порядка 20 лет назад, когда визуальным CASE средствам моделирования пророчили те же лавры, что сейчас пророчат Copilot в написании кода:) Идея была в том, чтобы нарисовать диаграммы, а из них должен был получиться рабочий код. Это конечно не случилось, но по дороге к этому средства моделирования усложнились до того, что их перестали использовать сами разработчики. Зато их начали использовать архитекторы всех сортов:)

Но вернемся к интервью с автором и основным тезисам
- Эшли написал книгу не просто про диаграммы as a Code, а про использование этого подхода вместе с инструментом Mermaid
- Эшли преимущественно использует 3 вида диаграмм: sequence diagram прямиком из UML, C4 Model от Саймона Брауна (подробнее в моем разборе его выступления), модель предметной области
- Sequence диаграмма используется для моделирования взаимодействия систем или людей
- C4 Model используется для моделирования архитектуры на разном уровне абстракции: context, container, component, code
- Модель предметной области - это просто вариация на тему старой доброй ER диаграммы и она используется для описания проблемной области, в которой работает софт
- Вообще, есть и другие инструменты для построения диаграмм из кода
— Plantuml - хороший инструмент для построения диаграмм, движок которого написан на Java, а не javascript как Mermaid
— Structurizr - хороший инструмент для моделирования в нотации C4 Model от автора концепции. Этот инструмент не позволяет рисовать условно произвольные диаграммы
- По мнению автора книги Mermaid выигрывает у Plantuml, так как Mermaid сделан на js, а значит может исполняться и на чайнике, а также он встроен в GitHub и Gitlab. У Structurizr же Mermaid выигрывает широтой поддержки разных диаграмм
- И немного про фичи Mermaid
— Поддерживает широкий спектр типов диаграмм, от формально определенных языков моделирования до моделирования в свободной форме
— Определяет язык разметки для описания диаграмм в виде кода и имеет инструменты для создания реальных визуальных диаграмм.
— Имеет хорошую документацию и живой редактор для создания диаграмм.
— Обеспечивает обратную совместимость и постоянно добавляет новые типы диаграмм.
- Общие плюсы diagram as a code в том, что диаграмма описывает простым текстом, а значит ее легко положить в систему контроля версий, а также видеть изменения между версиями
- Автор отмечает, что сейчас можно использовать LLM для того, чтобы создать диаграммы по простому описанию - LLM просто генерит код в нотации Mermaid для построения диаграммы
- Ну и в конце разговора автор говорит, что возможно мы увидим возрождение архитектуры, основанной на моделях, или разработки, основанной на моделях, с новыми инструментами и искусственным интеллектом.

#Architecture #Vosualisation #Software #SystemDesign

The Art of Project Management (Искусство управления IT-проектами) - Part III (Рубрика #Management)

Этим постом заканчивается рассказ про книгу, начатый в постах 1 и 2. Здесь мы поговорим о последней части "Management"

12) Why leadership is based on trust
Глава начинается с обсуждения простых вещей, которые помогают завоевать доверие, например

Делайте то, о чем говорите, и говорите то, о чем думаете

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

13) How to make things happen
Глава начинается с того, что Скотт рассказывает о качестве крутых руководителей - о способности добиваться желаемого результата. Он так определяет эту способность

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

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

14) Middle-game strategy
Здесь автор рассказывает про этапы проекта и показывает как мониторить его выполнение. В общем и целом, сейчас есть гораздо более интересные книги на этот счет, например, “Визуализируйте работу” (“Making Work Visible”). Я рассказывал про эту книгу раньше

15) End-game strategy
Эта глава посвящена завершению проекта, которое по мнению автору подобно приземлению самолета

И то и другое требует приближаться к финишу долго и медленно. При этом нужно быть готовым к внезапному повторному взлету без серьезных переделок

В общем и целом, сейчас запуск IT проектов все-таки будет попроще, так как у нас есть CI/CD и все части системы можно обновлять и тестировать по много раз на дню. Но если проект комплексный и в нем замешаны все функции компании, то он может быть очень сложен и его запуск действительно похож на описанное выше

16) Power and politics
Последняя глава посвящена власти и политике. Честно говоря, я это не особо люблю, но политика является естественным следствием человеческой природы. В итоге, если люди работают в единой группе, то там точно будет какое-то распределение властных полномочий. Автор отмечает, что
- У каждого руководителя есть свои политические ограничения и чем больше власти у человека, тем сложнее структурно эти ограничения
- Политическая власть может включать: поощрения, принуждения, манипулирование осведомленностью, сложившимися отношениями и влиянием
- Для решения политических проблем надо понять расклад и дальше попробовать договориться с теми, у кого есть политическое влияние на участников
Отдельно отмечу, что автор советует почитать книгу "48 законов власти", которая как мне кажется наполнена антипаттернами того, как должен вести себя руководитель. В итоге, ее можно читать только как книгу "Вредные советы" Григория Остера:)

#Management #Agile #Project #Leadership #SelfDevelopment #Software #Processes

How to Do Great Work Without Being an Asshole (Как управлять хаосом и креативными эгоистами) - Part I(Рубрика #Management)

Оригинальное название этой книги Пола Вудса нравится мне гораздо больше переводного. Но и в переводе есть смысл, так как автор рассказывает про свой опыт управления креативным агенством. Эта небольшая книга наполнена забавными историями про основы менеджмента, которые в такой подаче проглатываются за пару часов, благо книга небольшая и вот ее содержание
1) Быть приятным человеком выгодно - для долгосрочного успеха важно выстроить хорошую культуру в компании, а это проще сделать не будучи мудаком. Так и хороших сотрудников проще привлечь на работу и с клиентами выстроить отношения. Сейчас с появлением сайтов типа Glassdoor все тайное очень быстро становится явным и быть приятным человеком действительно выгоднее, чем быть asshole. Но это не отменяет того, что для получения выдающегося результата надо круто работать - легких путей здесь нет
2) Эгоцентризм в креативном мире - автор делит большую часть креативных ребят на 2 категории: уязвимые и неуверенные в себе и эгоистичные нарциссы. Первые страдают от своей неуверенности и им нужно внешнее одобрение, что открывает дорожку для манипуляций. А вторые считают себя выше правил и процессов и зачастую разрушают культуру компании. Мне особенно понравилась фраза автора в сторону руководителей "ваша обязанность - растить команду, а не собственное эго".
3) Деловые совещания - совещаний должны быть меньше, но они должны быть эффективнее. У встречи должна быть четкая цель, список участников и время проведения. Во время встречи нужно начать с цели, а дальше придерживаться плана обсуждения, фассилитировать дискуссию, зафиксировать следующие шаги и ответственных. После встречи надо разослать участникам meeting notes и подсветить ожидания по следующим шагам.
4) Питчинг - здесь автор рассказывает про то, что в креативной индустрии presale раньше не оплачивался. Агенство готовило питчи по продуктам часто бесплатно, а потом как на конкурсе талантов клиент слушал n питчей и выбирал победителя. Автор говорит, что это порочная практика, так как она не характеризует стандартную работу клиента с дизайн агенством, так как в реальности они обычно должны работать парой, поэтому не ясно что таким подходом проверяется. Кроме того, это обесценивает работу креативщиков - никто не любит работать бесплатно. Автор предлагает заменить это практикой демо-дня, где клиент и ребята из агенства вместе работают один день над задачами клиента.
5) Подготовка проекта - здесь автор рассказывает на пальцах про планирование проекта целиком, а дальше его выполнение спринтами из Скрама. В общем и целом, это дает нужную предсказуемость в креативном агенстве.
6) Брифинги - рассказ про важность спецификаций от клиента. В письменном виде и с правильной структурой:
- Контекст задания
- Описание проекта в одном предложении
- Какие бизнес-задачи он должен решить?
- Перечень конкретных ожидаемых результатов
- Промежуточные и окончательные дедлайны
- Ссылки на файлы и документы, что нужны для выполенения проекта
7) Обратная связь - ее нужно давать вовремя и качественно. Автор так формулирует базовые правила обратной связи
- Говорите прямо и открыто
- Будьте позитивны и конструктивны
- Выражайтесь ясно и точно
- Приводите примеры
- Просите задавать вопросы

Окончание обзора в следующем посте

#Management #Leadership #Processes #Project #Productivity