Managing Humans: Biting and Humorous Tales of a Software Engineering Manager (Как управлять интеллектуалами: я нерды & гики) - Part VIII (Рубрика #Management)

Продолжаю рассказ про эту книгу обзором третьей и последней части "Versions of You", где автор рассказывает на пальцах о мышлении гиков и о том, как успешно научиться с разными людьми, где каждый человек - это другая версия вас:)
Посты о других частях книги доступны здесь 1, 2, 3, 4, 5, 6, 7

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

50) Ваш увольнительный "чек-лист"
Хорошие советы о том, как правильно покидать компанию
- Не обещайте того, чего вы не сможете сделать
- Уважайте нетворкинг
- Обновите свою "бригаду" (тех, кого бы хотели видеть в своей команде)
- Не используйте недозволенных приемов
- Ведите себя подобающим образом с теми, на кого вы работали, а также с теми, кто работал на вас
- Не соглашайтесь выполнять работу после увольнения (или если очень надо, то запросите за это много денег)
- Не предоставляйте слишком много информации (например, не сообщайте о переходе слишком рано)

51) Исчезновение именных табличек
Интересная глава о том, когда именно сотрудник прощается с компаний. Суть в том, что у человека есть свои желания и ценности и если работа приводит к тому, что желания не удовлетворяются, а ценности серьезно расходятся, то человек становится открыт для других опций. Фактически, в этот момент он и прощается с компанией, хотя еще некоторое время работает в ней
52) Прекрасные хаотичные снежинки
Люди - это хаотичные снежинки. Поэтому даже если у вас как у руководителя был план, то в океане неизвестности он может пойти по п...е. Главное уметь работать с этой неопределенностью и не теряться.

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

#Management #Software #Engineering #SoftwareDevelopment #Processes #Leadership

Почему «Головоломка» (Insinde Out) — великий мультфильм (а вторая часть — идеальный сиквел) (Рубрика #ForKids )

Недавно мы всей семьей посмотрели "Головоломку" и "Головоломку 2", а тут мне youtube подкинул 15 минутный обзор этих мультиков от Кинопоиска, который мне понравился. Интересно, что в 2015 году я пропустил этот мультик, но тут с детишками все наверстал. Каждому из сыновей мультики понравились, но каждый поймал что-то свое с учетом возраста: 3, 8 и 18 лет. Моя жена тоже с большим удовольствием посмотрела новую "Головоломку 2", которая ей понравилась, а это хороший знак, так как Настя обладает впечатляющей эмпатией и учится в магистратуре с названием "Психоаналитическое бизнес-консультирование" и многие из теоретических основ психологии изучает достаточно глубоко. В общем, я рекомендую посмотреть и этот краткий обзор от Кинопоиска и сами мультики, желательно всместе с детишками.

#ForKids #ForParents #SelfDevelopment #Brain

Обсуждение книги "Learning Domain-Driven Design" вместе с ребятами из клуба { между скобок } (Рубрика #Architecture)

Сегодня вечером в 19:00 я приду к ребятам в гости, чтобы обсудить последнюю, четвертую часть книги, которая называется "DDD и другие методологии и паттерны". Вся книга очень интересна и я рассказывал об этом раньше. Кроме того, последние главы мне настолько понравились, что я даже в свое время сделал отдельные разборы каждой главы
14 глава. DDD и микросервисы
15 глава. DDD и event-driven architecture
16 глава. DDD и data mesh
Поэтому я с большой радостью откликнулся на приглашение Гриши Скобелева обсудить эту книгу вместе.

#Management #Architecture #SoftwareArchitecture #DDD #SystemDesign #Leadership #DistributedSystems #SystemEngineering #SoftwareDevelopment

Научный руководитель vs бизнес-менеджер: как управлять R&D - Алексей Гусаков (Яндекс) (Рубрика #Management)

Интересный доклад на тему управления разработкой и исследованиями (research & development или просто RnD). Доклад рассказывает Алексей Гусаков, технический директор Яндекс Поиска, который отвечает за все поисковые технологии компании, развитие больших языковых моделей и внедрение нейросетей в сервисы Яндекса для российского и международного рынков. Мне персонально этот доклад импонирует тем, что Алексей рассказывает о том, что важно находить баланс между наукой и бизнесом, чтобы не стать "фигней" или забыть об инновациях.

Основные тезисы примерно такие
- Алексей рассказывает про свою роль как менеджера, где он должен находить баланс между наукой и бизнесом. Есть две ключевые задачи: сохранять технологическое лидерство и обеспечивать бизнес необходимыми технологиями, многие из которых завязаны на ML
- Сам ML можно разделить на три части: продукт и конкретные заказы от них, R&D и зона неизвестного:
-- Продуктовые инкрементальные улучшения обусловлены каким-то запросом на доработки от бизнеса, есть понятные метрики и вообще тут комфортно инкрементально работать командам. Здесь важно, чтобы были челленджи для развития команд и технологий. Но этот инкрементальный подход может привести к состоянию, когда прогресс замедляется.
-- RnD - это технологии, в которые уже есть инвестиции, но результат ожидаются в будущем. Результаты не гарантированы, но вероятны. Важно обеспечивать баланс между бизнесом и RnD. Также достаточно сложно мотивировать команды на такие проекты, так как люди не любят работать с непредсказуемыми резальтатами
-- Зона неизвестного - это технологии, что развиваются в мире и по которым пишутся whitepapers. Тут можно следить за происходящим, читать whitepapers, но инвестировать особо не получится, так как зона неизвестного очень велика
- Оценивать RnD деятельность сложно - обычно это получается сделать только пост-фактум и с большим лагом. Важно проводить ретроспективный анализ, чтобы помочь определить, какие решения были правильными или неправильными. Пример успешного ответа на этот вопрос - объединение трех технологий (распознавание речи, синтез речи и машинный перевод) для создания синергии.
- Оценить работу в области зоны неизвестного сложно - слишком много выходит научных статей в мире, все не прочитать и не попробовать. Алексей рассказывает про два больших тренда в ML: инвестиции в reinforcement learning и прохождение Atari Games и инвестиции в LLM. В первое ребята не ивестировали, а вторым занимались активно. Поэтому Yandex начинал погоню за OpenAI не с нуля

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

Кстати, секция Q&A была настолько интересной, что я разобрал ее в следующем посте

P.S.
Я как-то тоже делал подход к снаряду и даже выступал на Techlead Conf с докладом "Как RnD появляется в крупных IТ-компаниях". Там я рассказал про то, как для меня выглядит подход к RnD у Google, Amazon, Yandex и немного рассказал про наш подход в Т-Банке. Круто, что в этом докладе "Научный руководитель vs бизнес-менеджер: как управлять R&D" Алексей рассказал о том, как изнутри Yandex это устроено:)

#Management #Architecture #Culture #RnD

Научный руководитель vs бизнес-менеджер: как управлять R&D - Алексей Гусаков (Яндекс) - Q&A (Рубрика #Management)

Секция вопросов к спикеру в этом докладе тоже была интересной:

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

- Как RnD стрим продает свои технологии в бизнесовую часть Яндекса? - ответ в том, что технологии в бизнесовые технологии часто пушить не надо, так как команды сами готовы их пулить к себе и интегрировать в продукты. Но конечно RnD стрим может помогать распространению

- Как управлять мотивацией сотрудников, что занимаются RnD, когда они не удачны? - в RnD большая часть экспериментов заканчиваются неудачами, поэтому к этому надо быть готовым. Если говорить про формальности, то за хорошую работу не ругают, даже если RnD проект не выстрелил

- Как принимаются решения и приоритизируются активности? - Финальные решения принимает Алексей + несколько лидов (На вопрос: "А почему так?" был ответ "Потому, что мы не сторонники демократии"). Честно говоря, я тоже считаю, что стратегические решения не получится принять через консенсус в большой группе

- Как обосновать RnD в компании и как их продать? - Если в мире появляются технологии, которые могут быть полезны для компании, но она не инвестирует в них, то это может быть аргументом в пользу необходимости R&D.

- Как происходит объединение технологий и потребностей клиентов и продуктов - в Яндексе есть продуктовые люди, которые исследуют потребности пользователей и предлагают новые технологии для их удовлетворения. Однако, не всегда удается реализовать все потребности пользователей используя текущие технологии и тогда приходит очередь RnD

#Management #Architecture #Culture #RnD

Code of leadership #17 - Interview with Anton Kosterin about Architecture (Рубрика #Architecture)

В 17 выпуске подкаста Code of Leadership я беру интервью у Антона Костерина, который является заместителем технического директора и занимается выстраиванием архитектурной функции внутри Т-Банка. Собственно про проектирование и архитектуру мы и говорим в этом выпуске и обсудим темы

- Эволюция подходов к архитектуре в компании
- Импортозамещение и архитектурные процессы
- Процесс ревью изменений
- Процесс принятия решение
- Синергиия между командами из разных функций (разработка, инфраструктура, безопасность, ...)
- Tooling и инструменты
- Архитектурная документация
- Сбор данных для анализа архитектуры
- Автоматизация этого процесса
- Процессы RFC и ADR
- Конфликты и решения
- Путь к становлению архитектором
- Архитектура и проектирование
- Важность разностороннего опыта для архитектора и как стать как Антон

P.S. Антон как и обещал выдал список книг
1) “Requirements Engineering for Software and Systems” Phillip A. Laplante - лучшая книга о требованиях по мнению Антона, а из требований следует всё остальное, и даже архитектура:)
2) “Distributed Systems” Andrew S. Tanenbaum и Maarten vav Steen - классика о проектировании распределённых систем, чтобы знать о правилах “игры”, в которую играем. Мы разбирали эту книгу в подкасте "Code of Architecture" и вот есть разводящий пост на саммари по этой книге
3) “Найти идею. Введение в ТРИЗ – теорию решения изобретательских задач” - Генрих Альтшуллер - учимся ломать матрицу, чтобы выйти из ограничений. У меня есть обзор этой книги

#Architecture #Processes #Management #Leadership #Software

ЦЕХ 4 - Урок #18 "Продвижение в самиздате. Эксперт — Евгений Селиванов" (Рубрика #Writing)

Очередной урок из курса книгописания и книгоиздания от МИФ вел Евгений Селиванов, который имеет богатый опыт в маркетинге и продвижении книг. Евгений запускал платформу "Литрес Самиздат" и вывел ее в лидеры рынка.
Мне запомнились следующие тезисы из этой лекции:
1) Для успешно продвижения надо использовать маркетинг-микс или 4P: product, place, price, promotion
2) Книга должна быть превращена в продукт - это не просто текст, это физический артефакт, который может быть представлен как печатное издание, pdf версия или аудиофайл. Это сложный процесс, который разбирался в предыдущих уроках подробнее
3) Доступ к книге должен зависеть от жанра и аудитории и может быть как платным, так и бесплатным (если мы хотим самопиара, а не заработать на конкретной книге)
4) Продвижение книги - это очень важный фактор, в него входит и выбор правильного ценового диапазона и использование бесплатных способов привлечения внимания
5) Книгу можно выпустить в издательстве или на платформе самиздата - сейчас это тоже может быть прибыльно
6) Для продвижения книги можно использовать разные инструменты: социальные сети, скидки, рекламные инструменты на площадках, где опубликована книга, а также таргетированную рекламу
7) Для продвижения можно использовать услуги профессионалов - внутри издательства, если книга издается в нем, или фрилансеров, если это самиздат
8) Хорошая рекламная компания часто имеет позитивные пост-эффекты и формирует эффект трамплина, когда она привлекает аудиторию и после окончания
9) Автору желательно собирать фанбазу и уметь продавать себя и свои книги - это является ключевым фактором успеха для писателей
10) Универсального рецепта успеха нет, но если знать свою аудиторию и уметь с ней общаться, то шансы на успех повышаются
11) Иллюстрации и хорошая верстка могут добавить ценности книги
12) Есть целая группа платформ для самиздата, которые можно попробовать вместо подачи книги в издательство
13) При продвижении книги можно использовать все те же рекламные инструменты и аналитику по ним (аля воронку продаж), что используется и при продвижении других продуктов

Предыдущие посты про этот курс писательского мастерства доступны здесь
1. Увидеть свое имя на обложке может каждый
2. Целевая аудитория и ее потребности в создании книги
3. Жанры и стили. Как найти тему для нон-фикшн-книги
4. Как организовать работу
5. Как преодолеть писательские блоки. Практическое занятие
6. Жду музу, а она все не приходит
7. Книга по полочкам
8. MS Word для работы с большими и сложными текстами
9. Рассказываем истории: сторителлинг в книге
10. Саморедактура: работа с текстом, сокращения, фактчекинг
11. Правила сильной книги захватывающего текста
12. Авторская стилистика
13. Как превратить рукопись в сценарий
14. Рукопись готова. Что дальше?
15. Превращение рукописи в издание
16. Авторские права и договор с издательством
17. Дизайн книги.

#SelfDevelopment #PublicSpeaking #Storytelling #Writing

Профессии в IT - серия совместного подкаста Т-Образования и ФКН ВШЭ (Рубрика #Career )

Недавно я поучаствовал в совместном подкасте своих коллег из образования и ребят из Высшей Школы Экономики. Темой подкаста стали профессии в ИТ, где мы поговорил как про продакт менеджеров, дизайнеров, SDE (software development engineers), аналитиков, кибербезов, SRE инженеров и так далее. Мы обсуждали то, какие процессы разработки бывают и какие роли в них требуются, а дальше от этого шли к навыкам и компетенциям людей, которые могут эти роли исполнять.

В обсуждении участвовали
- Евгений Соколов - академический руководитель ПМИ ФКН ВШЭ
- Денис Син - тимлид в Т-Банке и руководитель совместной научной программы Т-Банка и ВШЭ
- Александр Поломодов - технический директор в Т-Банке и автор этого канала
На всякий случай вот ссылка на запись выпуска в VK.

P.S.
Кстати, в предыдущем выпуске этого подкаста, который назывался "MLOps в теории и на практике", я тоже участвовал и рассказывал про него раньше.

#Career #Management #Software #SoftwareDevelopment

Архитектурный чекап здоровья систем - Андрей Шалунов, Яндекс Плюс (Рубрика #Architecture)

Это архитектурное выступление интересно тем, что построено на одной хорошей метафоре. И эта метафора - сравнение ИТ систем с живым организмом. А дальше отсюда идут остальные аналогии
- Состояние системы превращается в здоровье организма
- Архитектурный аудит превращается в архитектурный чекап
- Архитектор, что проводит ревью в доктора
- Архитектурный комитет со своими правилами превращается в систему здравоохранения
- Изучение внутрянки системы с исследованием проблем превращается в анализ симптомов и постановку диагноза
- А вопросы нужные для этого исследования превращаются в список анализов, который доступен здесь
- Выполнение предписаний превращается в следование плану лечения, причем проблемы иногда бывают хронические, а значит пить таблетки придется до упора
- И как и при поддержании здоровья организма при архитектурном чекапе требуется соблюдение правильной периодичности

P.S.
Выступление мне зашло по трем причинам
1) Я на этой неделе выступал внутри на бизнес-стендапе с 10 минутным рассказом про эволюцию архитектуры Т-Банка и направлении дальнейшего развития. И это выступление начиналось с того, что я объяснял почему строительная метафора вредна, а метафора природы и живых организмов полезна, правда я там говорил про леса и рисовые поля, где как и в архитектуре часто сложно узнать что происходит за поверхностью воды или интерфейса:)
2) Я в последнее время много времени уделяю медицинским процедурам и прохожу этакий чекап, посещая невролога, кордиолога, окулиста, ... И кажется, что чекап надо было делать раньше, а не забивать на него.
3) Недавно у меня был выпуск подкаста "Code of Leadership" с Антоном Костериным, заместителем технического директора в Т-Банке, про наш процесс управления архитектурными изменениями и при желании часть активностей оттуда можно было бы назвать архитектурным чекапом

#Management #Architecture #SoftwareArchitecture #SystemDesign #SystemEngineering #SoftwareDevelopment

День знаний и рассказ про роль SDE для студентов с ФКН ВШЭ

Конечно день знаний был вчера, но именно сегодня все пошли в свои образовательные учреждения:) Мой старший сын сам пошел первый раз в свой университет (подробнее здесь), среднего сына жена отвела во второй класс школы, а младшего сына я отвел в садик в первый раз на полный день (до этого он ходил в садик на полдня). Ну а сам я приехал после этого на работу и начал готовиться к выступлению перед студентами. У нас сегодня в гостях студенты ДРИП (Дизайн и разработка информационных продуктов) ВШЭ ФКН, что учатся на совместной программе с Центральным Университетом. И я им буду рассказывать про то, как выглядит роль SDE инженера в технологической компании сейчас, а вообще на полчаса будет очень много тем
- Современные процессы разработки и инженерные практики в российских tech компаниях - расскажу про то, как все начиналось, потом появилась история с devops, потом shift-left everything и X+Ops:)
- Как выглядит карьерный путь SDE (software development engineer) с развилкой в менеджмент и путь individual contributor высоких грейдов
- Как выглядит матрица компетенций для SDE в Tinkoff
- Как выглядит процесс роста сотрудников внутри (Tinkoff рост)
- И другие полезные мысли про саморазвитие и рост внутри компании:
-- Как использование Cynefin фреймворка
-- Как работать над сложной проблемой (и создавать артефакты RFC/ADR)
-- Как приоритизировать задачи используя матрицу Эйзенхауэра
-- Как работать со своей мотивацией
-- Как планировать работу используя backcasting (это примерно тоже самое, что working backwards от Amazon)
-- Как работает мантра "You build it, you run it" и почему она помогает инженерам расти над собой быстрее

Это выступление уже как-то рассказывал перед студентами, а также отдельно записал для зрителей своего канала TellMeAboutTech на Youtube. Также я подготовил большой список рекомендаций

Материалы по процессам разработки
- Современные подходы к разработке программного обеспечения
- Совершенствование потока разработки программного обеспечения
- Проектируем надежные системы — стоит ли игра свеч
- Про управление проектами и продуктами
- The Pipeline-Driven Organization • Roy Osherove • GOTO 2022
- Code of Architecture — “Distributed Systems, 4th Ed” #2 (Architecture)
- Архитектура в масштабе на ArchDays 2020
- Devops культура: мифы и реальность
- Про MLOps
- The State of Application Security 2023 • Sebastian Brandes • GOTO 2023
- Как RnD появляется в крупных ИТ-компаниях

Материалы по проектированию и system design
- Статья про System Design Interview в общем
- Статья про то, как мы оцениваем System Design Interview
- Статья о том, как подготовиться и пройти System Design Interview
- Публичное System Design Interview на C++ Russia 2022
- Публичное System Design Interview на конференции ArchDays 2022
- Статья со списком книг о проектировании программного обеспечения
- Курс Essential Architecture #Code
- Курс Essential Architecture #Data

#Management #Software #Processes #Project #ProductManagement #Engineering #Processes #Leadership #Staff #Architecture #Career

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