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