Winter Analytics Weekend (WAW)

Через месяц я буду выступать на круглом столе про варианты развития системных аналитиков на WAW, зимнем ивенте от организаторов ЛАФ (летнего аналитического фестиваля). Само мероприятие пройдет на выходных 17-18 февраля 2024 в GOPark HOTEL, что находится в Подмосковье. Сама тема для меня не нова - когда-то давно я сам работал недолго системным аналитиком, а относительно недавно я уже рассказывал про развитие аналитиков в следующих постах
- Как развиваться, если ты уже Senior System Analyst
- Техлиды и архитектора (и системные аналитики)
- Кем мы станем, когда вырастем - обсуждение карьеры системных аналитиков с ребятами из NextWay

P.S.
Если вы будете на этом мероприятии, то заходите пообщаться и позадавать вопросы участникам круглого стола:)

#Career #Analyst #Software #SoftwareArchitecture #Architecture #Engineering

Code of Leadership #1 - Team topologies

Вчера вечером я записал первую серию своего личного проекта Code of Leadership, где
- каждый эпизод посвящен одной книге по engineering management
- в каждом эпизоде есть приглашенный гость-эксперт, который может сам предложить свою любимую книгу по менджменту для обсуждения
- эпизод обычно длится час-полтора и может сопровождаться схемами из книги или быть чисто в разговорном жанре

Для старта этого проекта я выбрал книгу Team topologies и позвал ее обсудить Стаса Халупа, своего друга, с которым мы несколько лет работали вместе. Стас много лет выступал в роли технического продакт менеджера и руководителя разработки платформенных продуктов, поэтому я очень хотел обсудить именно с ним эту книгу про топологии команд, где большой фокус был на stream-aligned и платформеннных командах. В итоге, выпуск получился отличным - мы смогли и похвалить книгу и покритиковать ее по делу, а также накидать интересные идеи для расширения применимости самой модели, например, в сторону shift-left security и secure by design (предложение Стаса) или данных и data mesh (предложение от меня). Теперь осталось только смонтировать то, что получилось и дальше выложить в этот канал:)

#Management #Leadership #PlatformEngineering #Software #SoftwareDevelopment #Architecture #Processes

Tinkoff QA Series

Я люблю смотреть айтишные документалки. Прикольно, что у нас в Тинькофф тоже начали их снимать, а премьеры показывать в кинотеатрах. Сегодня речь про документалку о наших процессах разработки и практиках, а также их эволюцию с 2017 года по настоящее время. Причем они разбираются с точки зрения qa-инженеров, которые в 2017 году преимущественно занимались ручным тестированием, а к настоящему времени "отбились от рук" и сфокусировались на автоматизированном тестировании. А вообще за шесть лет в компании мы пришли к stream-aligned и платформенным командам, ручные тестировщики научились автоматизации и было внедрено shit-left-testing.

Премерьера пройдет в Казани 1 февраля в 19.00, а потом сериал станет доступным на Youtube и про это напишут наши qa-инженеры в своем канале "QA Tinkoff"

#Software #QA #Engineering #Processes #SoftwareDevelopment #Management

How A Small Team of Developers Created React at Facebook | React.js: The Documentary

Недавно я посмотрел интересную документалку про то, как появлялся React. С учетом его текущей популярности и того, что эта библиотека появилась в одной из bigtech компании, можно предположить, что успех был предрешен. Но из этой документалки вы узнаете, что это было совсем не так. Из этого фильма вы узнаете, как появилась самая идея в недрах компании, как она конкурировала с внешними библиотеками типа Backbone.js, Ember.js и внутренними типа Bolt.js. В итоге, React.js победил, а потом авторы решили вывести его opensource и как он был изначально принят и как постепенно к нему пришло признание:) Эту историю рассказывают звездные разработчики, такие как Том Оккино, Кристофер Шедо, Пит Хант, Себастьян Маркбоге, Дэн Абрамов и многие другие.

#Software #SoftwareDevelopment #Architecture #Engineering #Management #OpenSource

Антихрупкость в IT. Как достигать результатов в IT-проектах в условиях неопределенности

За пару дней прочитал книгу Александра Бындю и у меня остались очень смешанные ощущения от книги.

Сначала пробегусь по плюсам и разобранным темам
- В начале книги много времени уделяется полезным продуктовым практикам: impact mapping (я уже описывал одноименную книгу на эту тему), customer journey map, user story mapping
- Хорошо разобраны проблемы с большим и формальным техническим заданием (ТЗ)
- Рассказывается про работу с требованиями в agile проектах
- Неплохо обсуждаются причины провалов IT-проектов
- Здраво рассмотрены модели управления проектом: fixed price, time and materials и отчасти fff (fix time, fix budget, flex scope)
- Во второй части дается helicopter view относительно того, как строить процессы разработки в заказной моделе разработки
-- Приводится рассказ про монолиты, микросервисные монолиты, микросервисы и дальше оркестраторы бизнес-сервисов
-- Где стоит применять low-code платфомы и когда с них пора слезать
-- Как работать с legacy системами и как запускать проекты по переходу с них
-- Что делать с техническим долгом

А теперь немного про минусы
- Название книги - это отсылка к работе Насима Талеба, который, по-моему мнению, является графоманом, смысл произведений которого обычно легко укладывается в одну страничку
- Книга рассказывает про взаимодействия заказчиков/исполнителей в модели заказной разработки, другие модели не рассматриваются
- Понятия проект и продукт смешиваются и используются взаимозаменямо, что, с точки зрения компании-исполнителя, в модели заказной разработки понятно, но совсем не так в продуктовой компании (подробнее можно почитать в моей статье "Про управление проектами и продуктами")

Иногда я буду писать "проект", а иногда "продукт". Для себя я не разделяю два этих понятия

(1 часть, глава 4)
- Часть глав выглядит как отработка возражений заказчика при продаже ему проекта - пример с работой по ТЗ или продажа FFF (fix time, fix budget, flex scope) концепции, которая для меня выглядит как просто по другому названый time & materials:)
- Большая часть графиков в книге приведены просто для иллюстраций мыслей автора - за этими графиками нет чисел и какой-то статистики, чисто иллюстрации
- Вообще, в книге нет следов научного подхода - аргументация строится на примерах из консалтинг практики Александра и альтернативных точек зрения не приводится
- В части про IT все написано настолько кратко и тезисно, что, если ты не знаешь всех источников, на которые ссылается Александр, то остается только поверить на слово
- Микросервисы продаются как ответ на запрос адаптивности к изменениям, а дальше все больше походит на рассказ о том, как запустить проект по переходу с монолита на новое решение и какие технические проблемы надо включить в контракт, чтобы не облажаться
- Много раз звучит рефрен про то, что надо вовремя позвать IT консультанта для технического аудита ... и не только

В общем, я бы назвал книгу "Как заказывать/продавать ИТ-проекты" и отметил бы, что книга может быть очень полезна двум категориям
- Бизнес-заказчикам, которым надо выполнить ИТ-проект и они хотят понять как это сделать и не облажаться
- Исполнителям, что продают свои услуги и выполняют проекты, но не хотят продавать руки по time & materials из-за низкой маржи, а также боятся рисков в схеме fix price:)
Остальным рекомендую обратить больше внимания на материалы, к которым отсылает автор и которых к концу книги набежало 100 ссылок вида byndyu.ru/footnote/{id} ({id} от 1 до 100)

#Management #Software #Architecture #Processes #Project #ProductManagement #Engineering #Processes #Consulting

Turn the Ship Around | L. David Marquet | Talks at Google

Посмотрел сегодня интересное выступление на тему лидерства от David Marquet, бывшего капитана американской субмарины и автора бестселлера "Turn the Ship Around". В этой книге автор рассказывал про свой опыт в качестве капитана субмарины "USS Santa Fe", которая когда-то занимала последние места с точки зрения удержания сотрудников и эксплуатации. Его перевели на эту субмарину с другой, где он тоже был капитаном, но здесь ему пришлось столкнуться с новой подводной лодкой, которую он не знал досконально. В итоге, ему пришлось подстраиваться и поменять стиль лидерства с того, чтобы говорить окружающим что им делать, на другой:) Собственно в этом видео автор и рассказывает про свой подход, который принес ему успех в качестве капитана подводной лодки, а потом в качестве автора книг и консультанта по организационному развитию и лидерству.

Если возвращаться к выступлению, то в нем автор говорит про семь мифов лидерства и дальше рассказывает как это работает на практике (по его мнению)
1. Good leaders know all the answers -> Good leaders say "I don't know"
2. Good leaders give good orders -> Good leaders give no orders
3. Good leaders empower their team -> Good leaders TUNE empowerment for their teams
4. Leaders "motivate" their teams -> Leaders make it safe
5. Teams think their way to new action -> Teams act their way to new thinking
6. Leaders know all, tell all -> Leaders know all, tell not
7. Leaders trust their instincts -> Leaders act in ways that counter their instincts

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

Кстати, именно эту книгу я буду обсуждать в одной из следующих выпусков Code of Leadership с интересным гостем (но об этом подробнее я расскажу в следующий раз). А в понедельник уже выйдет первый выпуск, анонс которого я делал раньше.

#Leadership #SelfDevelopment #Management #Processes #SystemThinking #Thinking

Code of Leadership #1 - Team topologies

Вышел первый выпуск моего нового подкаста с разборами книг по engineering management. Начать этот проект я решил с популярной книги Team Topologies, для разбора которой я позвал Станислава Халупа, который много лет выступал в роли technical product manager и engineering manager, занимаясь развитием IDP (internal developer platform). Несколько лет мы работали со Стасом вместе и он много сделал для успеха тех изменений, о которых я рассказывал на разных конференциях.

В общем, мне было приятно позвать Стаса в гости и узнать его мнение о книге "Team topologies", в которой так как много фокуса на stream-aligned и платформеннных командах и их взаимодействии. В итоге, за полтора часа мы успели обсудить книгу в деталях, а также накидать план дальнейшего развития применимости самой модели, например, в сторону shift-left security и secure by design (предложение Стаса) или данных и data mesh (предложение от меня).

P.S.
Помимо выпуска рекомендую еще изучить краткое саммари по книге, которое я написал пару лет назад
- Teams as means of Delivery
- Team Topologies that work for flow
- Evolving team interactions for innovation and rapid delivery

#Management #Leadership #PlatformEngineering #Software #SoftwareDevelopment #Architecture #Processes