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

Вакансия тимлида в команде Statist (продуктовая аналитика)

Мы в Tinkoff разрабатываем внутреннюю платформу продуктовой аналитики, которая называется Statist и предоставляет необходимый набор инструментов, который позволяет собирать клиентские события и телеметрию со всех web и мобильных приложений в Тинькофф. А еще — визуализировать данные в виде аналитических отчетов и метрик.

Этот продукт является стратегическим для компании, так как он помогает собирать данные с помощью которых мы
- Следим за изменениями в продукте и производительностью клиентских приложений
- Реагируем на проблемы (тут правда, еще помогает наша observability платформа Sage для технической телеметрии)
- Обнаруживаем пострадавших во время сбоев и находим инсайты для улучшения UX в приложениях
Statist поддерживает практики data governance, которые позволяют повысить качество данных за счет разметки событий метаданными об атрибутах, версиях, приложениях и ответственных.

Мы ищем руководителя команды, которая разрабатывает инструмент визуализации данных аналитики.

Руководитель будет
- Управлять командой разработки: улучшать процессы, мотивировать сотрудников, решать конфликты поддерживать конструктивную атмосферу
- Участвовать в найме, онбординге и менторинге сотрудников
- Планировать техническое развитие продукта: работать с техническим долгом, оптимизацией и рефакторингом
- Участвовать в разработке архитектуры системы, проработке фич и спецификации задач
- Отвечать за своевременную поставку фичей
- Решать как backend, так и frontend задачи
- Проводить код-ревью коллег по команде, следить за стандартами качества кода
- Улучшать кодовую базу библиотек, основных и вспомогательных сервисов
- Вести внешнюю коммуникацию с другими командами, стейкхолдерами и руководителями

Для того, чтобы претендовать на позицию надо
- Иметь опыт управления командой разработки
- Уметь выстраивать процессы внутри команды
- Иметь опыт с Node.js, React, написанием тестов
- Уметь проектировать API и приложения (front, back)
- Знать основные архитектурные подходы и паттерны

Отдельно плюсом будут
- Знания и навыки в написании и оптимизации аналитических запросов
- Опыт с Clickhouse и Effector
- Умения в разработке SDK
- Практические навыки работы с современной инфраструктурой: K8s и контейнеры

Кандидат будет работать под руководством Андрея(@tcandrei), который у нас руководит разработкой инструментов продуктовой аналитики и a/b платформы. У Андрея можно многому научиться - он сильный технарь и умеет системно выстраивать процессы разработки в своих командах (и я стараюсь Андрею с этим помогать, так как являюсь его руководителем и мы достаточно много вместе проводим в обсуждении развития Statist и нашей a/b платформы). В общем, если есть желание поработать над этим продуктом, то вы можете писать Андрею или мне.

#Vacancy

Paolo Gallo | The Seven Games of Leadership | Talks at Google

Интересное видео из серии Talks at Google, в котором Paolo Gallo рассказывает про свою вышедшую месяц назад книгу "The Seven Games of Leadership: Navigating the Inner Journey of Leaders" и отвечает на вопросы аудитории. Сам Паоло когда-то был Chief Human Resources Officer в World Economic Forum in Geneva, was Chief Learning Officer at The World Bank in Washington, D.C., and Director of HR at the European Bank for Reconstruction and Development in London.

В самом видео автор начинает с рассказа о том, что он написал эту книгу для своей дочери-подростка, которая однажды его спросила "А чему ты научился папа за много лет своей карьеры". Дальше Паоло задумался и через неделю расска

вопросов, мне особенно понравился следующий
1. Сначала оцените свои достижения от 1 до 10 и запомните число
2. Дальше оцените насколько вы стали тем человеком, которым хотели бы стать - тут тоже надо выбрать число от 1 до 10
3. А дальше сравните два числа - автор утверждает, что большинство таких опросов показывают, что оценка достижений всегда перевешивает и это говорит о том, как люди расставляют приоритеты

Дальше он рассказывает про свою модель 7 игр лидера
1. Inner game - внутренняя игра, в которой человек пытается понять кто он такой, что его мотивирует, за что он выступает и в чем он хорош. Эти вопросы кажутся очевидными, но это совсем не так.
2. Better game - после того, как человек понял в чем он хорош, он начинает пытается это делать максимально хорошо. Это повышает авторитетность и мастерство в той игре, которую выбрал для себя человек. Тут важно, чтобы у человека была решимость продолжать совершенствоваться на протяжении жизни
3. Caring & outer game - на этом этапе этапе человек перестает думать только о себе и других людях (это часть про заботу) и дальше человек развивает контекстуальный интеллект и учится соединять точки и понимать как мегатренды влияют на его область деятельности (изменение в геополитике, климате, технологиях, демографии и так далее). Здесь происходит трансформация и расширение кругозора и понимание глубоких взаимосвязей
4. Crisis game - здесь наступает кризис, причем +/- у всех людей (обычно в районе между 40 и 50 годами). Здесь обычно возникает вопрос "А что я буду делать дальше" и для ответа на этот вопрос может потребоваться несколько лет. В общем, это игра в поисках нового смысла
5. Reinvent game - если смысл удается найти, то начинается игра с переизобретением того, что мотивирует человека
6. Revolution game - это изменения, от которых получат преимущества люди вокруг. Это такой альтруистический взгялд на вклад человека в улучшения, что принес человек в community, город, страну, ...
7. Let go game - иногда люди считают себя незаменимыми, но на этом этапе надо уметь отпустить это ощущение (или как говорил Людовик 14 "Государство — это я"). Здесь автор объясняет, что часто люди фиксируют момент, до которого они готовы двигаться, а потом нужно вовремя уйти. Это вопрос получения мудрости.

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

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

#SelfDevelopment #Leadership #Management