Канбан Метод. Базовая практика

Дочитал ночью эту книгу Леши Пименова, которая посвящена оптимизации процессов нематериального производства. Сразу, начиная с обложки, Алексей опрокидывает все базовые представление о Канбане

- его изобрели на "Тойоте"
- в нем есть доски и стикеры
- там ограничивают количество незавршенной работы

И дальше идет отстройка от старого канбана к новому, который придумал David J Anderson и превратил это в Kanban Univerysity (с курсами и сертификациями). Оставим в стороне сам подход к выбору уже используемого слова, а дальше объяснению всем, что это слово теперь значит что-то другое на совести David J Anderson. А рассмотрим саму книгу, которая состоит из четырех разделов.

1. Нематериальное производство
В этой части дается краткая отсылка к истории, когда производство было материальным и можно было видеть как материалы и незаконченное производство двигается по стадиям процесса (как в "Тойота"). А вот в условной разработке мы это движение уже не видим и нам нужно делать приседания для визуализации (откуда и растут ногу у знаменитых досок с тикетами)

2. Введение в Канбан Метод
Здесь все начинается с разбора принципов управления изменениями
- Начните с того, что есть сейчас (если задуматься над фразой, то сложно начать с чего-то другого)
- Договоритесь об эволюционном развитии (нет революциям и да постепенным улучшениям)
- Поощряйте проявление лидерства на всех уровнях
Дальше автор переходит к рассмотрению принципов поставки ценности
- Начиная с определения, что такое сервис поставки ценности
- Продолжая развитием правил для улушения показателей
- Отмечая важность понимания и фокуса на ожиданиях заказчика
- Говоря про важность управления работой, а не людьми
Завершает автор разбором базовых практик
- Визуализация
- WIP лимиты
- Управление потоком
- Явные правила
- Использование петель обратной связи
- Совместное развитие на основе моделей и научного подхода

3. Начиннаем использовать канбан
Здесь автор рассказывает про то, как изучать и улучшать процессы на практике, а точнее про
- Метрики производственного процеса
- Жизненные циклы
- Классы обслуживания
- Как строить канбан систему: про обязательства в такой системе, ее составные части, как дизайнить тикеты и саму доску.
Отдельно разбирается STATIK (System Thinking Approach To Introducing Kanban)

4. Улучшение канбан-системы
В этом разделе предполагается, что у нас уже есть канбан-система и мы дальше начинаем ее файн-тюнить, используя
- Накопительную диаграмму потока (cumulative flow diagram)
- Работу с узкими звеньями (как их выявить и что с ними делать)
- Работу с ресурсами непостоянной доступности (что это такое и как с ними быть)
- Что делать с вариативностью и как использовать теорию вероятности и массового обслуживаня (очень интересна часть про работу с рисками)
- Отдельно разбираются типы встреч и их ритмичность в канбан системе

Если подводить итоги, то вот мое мнение относительно книги
- Название книги не обмануло - в ней действительно собраны базовые практики по управлению процессами
- Эти практики являются полезными и хорошо бы руководителю про них знать и уметь применять
- Сама книга отлично подходит для начинающих руководителей, так как описывает эти практики и показывает буквально на пальцах как их стоит использовать себе во благо
- Для опытных руководителей книга может показаться скучной - в ней обсуждаются очень базовые вещи, ну и большое количество диаграмм в некоторых частях хоть и полезно новичкам, но у опытных людей вызывает мысли "да и так уже все ясно, а дальше-то что"

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

Про улучшение процессов разработки софта я тоже как-то уже рассказывал и про kanban я там говорил по книге "Making Work Visible", на которую я как-то написал краткое саммари.

#Processes #Management #Leadership #Software #Kanban

Вакансия TPM (technical product manager) в IDP (internal developer platform) @ Tinkoff

Большие технологические компании в какой-то момент времени приходят к созданию своих платформ разработки, которые должны консолидировать общие инструменты и предоставить их консистентно всем продуктовым командам. За счет этого компании стремятся к упрощению разработки продуктовых вещей, сокращению time-to-market, а также к экономии на масштабе. В Тинькофф это произошло 4 года назад с приходом в компанию Игоря Маслова, вокруг которого стала собираться core-команда, которая потом превратилась в coretech. На заре становления к этой команде присоединился и Дима Гаевский, который когда-то начинал работать у меня, потом руководил несколькими командами в coretech, а теперь исполняет роль CPO (chief product officer) нашей внутренней платформы. И сейчас Дима ищет себе технического продакта на направление "Code & Build" (Version Control + CI домен).

Вот как Дима сам описывает то, чем занимаются ребята в IDP

Что мы делаем:
- Собираем воедино все сценарии разработки, тестирования и сопровождения приложений в Tinkoff, создавая централизованную application-centric PaaS платформу Spirit.
- Платформа представляет собой консоль в стиле gcp/aws, построенную вокруг SSO с тесной интеграцией в общие сценарии инфраструктурных сервисов (БД), систем непрерывного запуска нагрузочных тестов, DevSecOps, VCS (Gitlab CE), движок квот, браузерные и мобильные фермы, хранилище артефактов, и multi-cloud runtime платформу.
- Продукт включает более 15 систем, объединенных вокруг различных этапов производственного цикла, с постоянным расширением числа систем.

Spirit включает в себя продуктовые направления:
- Discover - Inner Source, поиск, маркетплейс решений
- Code & Build - VCS (сейчас форк community Gitlab), CI, Artifact management (свое registry)
- Configure & Deliver & Operate - централизованная система конфигурации и деплоя приложений, а также рантайм платформа

Наша глобальная цель:
- Создать экосистему глубоко интегрированных инжиниринговых продуктов для разработчиков закрывающих все потребности на всем цикле производства. Экосистема объединяет в себе платформу для разработки Spirit, управления инцидентами FineDog и Observability - SAGE.
- Мы - часть Core Technologies, подразделения, созданного для повышения продуктивности разработки в Tinkoff, в IT которого трудится уже более 10 тысяч инженеров.
Мы придерживаемся идеологии you build it - you run it, пишем качественный код, самостоятельно покрываем все unit и интеграционными тестами. Задачи в команде варьируются от решения багов до написания сложных RFC по продуктовым требованиям и декомпозиции на задачи.

Если вам понравилась эта позиция, то вы можете написать Диме (@drwatsno)

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

#Vacancy #Software #ProductManagement

Ну и картинка из брендбука нашей внутренней платформы разработки Spirit к предыдущему посту

UpTeam @ Tinkoff

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

1. Были ли в карьере кризисные моменты, когда хотелось бросить все? За счет чего удалось выйти из кризиса?
Да, у меня были кризисные моменты. Раньше это часто заканчивалось уходом из компаний, где я работал до этого. В Тинькофф у меня тоже были кризисы, но я их успешно проходил через нахождение новых смыслов и изменения зон ответственности. Например, когда я от онлайн привлечения перешел к развитию мобильного банка или уже стал отвечать за "Клиентские интерфейсы, маркетинг и вовлечение". Часть из этого я рассказывал в докладе на YaTalks
2. Какие ошибки в своем развитии вы совершали? (как карьерном, так и в рамках обучения)
У меня была ошибка в развитии на втором курсе МФТИ, когда я слишком расслабился, начал играть в онлайн-игры и чуть не вылетел из универа. Эта ситуация научила меня двум вещам:
- онлайн-игры - это зло (персонально для меня)
- нельзя останавливаться в своем развитии
С тех пор я не играю в компьютерные игры и постоянно занимаюсь самообучением
3. На что разрешаешь себе отвлекаться во время рабочего дня?
На общение с коллегами, изучение новых технологий, чтение whitepapers:)
4. Лидерам тоже свойственно постоянно сравнивать себя с другими и страдать от расстройства? С кем себя сравниваешь?
Я считаю, что человеку надо сравнивать себя с самим собой, но более ранней версией. Суть в том, чтобы увидеть diff и понять, а растешь ли ты как специалист, руководитель и просто человек:) Также можно найти примеры крутых ребят, на которых хотелось быть похожим. Например, мне персонально импонирует Jeff Dean
5. Какой самый нестандартный способ развития у тебя был?
Лучше всего я помню фейлы - неудавшиеся экзамены, собеседования, выступления. С учетом моей склонности к саморефлексии я вынес из этих моментов достаточно много.
6. Какой у тебя был самый большой факап в карьере и чему он научил?
До Тинькофф я вышел на роль исполняющего обязанности CTO в один стартап, который на бумаге выглядел красиво. Но под капотом все оказалось совсем не так как рассказывали фаундеры. Из этого я вынес то, что обязательно надо спрашивать на собеседовании "А что произошло с человеком, который был до меня на этой должности?":)
7. Как бороться с ленью? Когда вроде знаешь, что нужно развиваться, но все время откладываешь тот же курс или проект
Надо просто заниматься тем, что тебе нравится. Тогда лень приходит не так часто. Плюс отдельно надо уметь ловить work/life баланс и если энергии сейчас недостаточно, то заниматься задачами попроще.

P.S.
Кое-что из этого я рассказывал в подкасте с Андреем Смирновым "Как и зачем профессионалу сохранять мотивацию учиться всю жизнь"

#SelfDevelopment #Management #Leadership #Career

Найм в компанию и promotion внутри

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

Найм
При найме в большую компанию часто существуют отдельные интервью на разные темы, которые кандидат проходит по очереди, а дальше ему выставляется грейд и зовут на фит интервью с командами. Разные этапы интервью дают разные сигналы, которые можно использовать для предсказания того, как кандидат будет работать после выхода на работу. Условно, если у нас есть три этапа:
- Алгоритмы и стрктуры данных
- Интервью по языку и платформе вокруг него
- Интервью по проектированию распределенной системы
То мы можем понять насколько хорошо у кандидата с hands-on experience по написанию кода, наколько хорошо он знает свой инструмент (язык и платформу) и может ли он дизайнить какое-то решение или ему надо специфицировать задачи до уровня напиши метод в этом классе, который будет забирать данные из вот этого API. Все эти сигналы позволяют снизить false positive ошибки (мы нанимаем слабого человека), которые в большой компании достаточно дорого стоят:
- С точки зрения потраченного времени - кандидату обычно требуется много времени вникнуть во внутреннюю специфику платформ, инструментов, процессов, систем, за которые отвечает его команда. Это приводит к тому, что обратная связь о том, что человек не тянет может приходить с запозданием
- С точки зрения вклада кандидата - иногда такие новички, находясь в состоянии неосознанной некомпетентности пишут такой код, который потом долго приносит "радость" другим членам команды
- С точки зрения бренда работадателя - никто не любит уходить с испытательного срока, а негативный фидбек распространяется лучше позитивного

В итоге, для повышения точности оценки и снижения false positive требуется проводить несколько секций. И если мы хотим минимизировать false positive мы получаем некоторое количество ошибок false negative (мы не нанимаем сильного человека) - и с этим приходится мирится (или уметь делать исключения по дополнительной информации).

Promotion внутри компании
Здесь уже история другая - для понимания стоит промотировать человека или нет есть очень много информации:
- Результаты его работы за предыдущие периоды времени (в виде оценок по performance review)
- Отзывы коллег (условный 360 если они собираются)
- Промо пакет (у нас это заявка в рамках нашего процесса Т-рост, про который я рассказывал подробнее здесь)
В итоге, тут информации для принятия решения достаточно много и его можно сделать взвешенно, опираясь на результаты работы и демонстрируемое поведение, а не прокси-метрики (как результаты интервью при найме). Поэтому мы при росте внутри профессии обычно и используем не аттестации с проведением интервью как при найме, а ориентируемся на результаты работы. Плюс если все сделать правильно, то сотруднику внутри можно подкидывать задачки посложнее и смотреть как он с ними справляется - этакая адаптивная сложность как в некоторых играх. Если он справляется с ними хорошо на протяжении некоторого времени, то promotion не заставит себя долго ждать, а если нет, то сотдник ничем особо не рискует.

P.S.
Если подводить итоги, то в этом посте я постарался объяснить почему
- Найм в крупную компанию выглядит как набор отдельных интервью
- Promotion в крупной компании выглядит как оценка результатов работы человека (а не ассемент)

Материалы на тему найма и промо
- Как нанимать технических руководителей
- Эволюция роли технического руководителя от инженера до CTO
- Как и куда развиваться, если ты уже Senior Software Engineer
- Варианты роста инженера, если он уже Senior
- Как развиваться, если ты уже Senior System Analyst
- Про performance review в командах разработки
- Как мотивировать разработчиков
- Трансформация роли CTO по мере роста компании

#HR #Career #Management #Software

Технологии @ Тинькофф

Мои коллеги сделали отличный раздел на нашем сайте, в котором рассказывается о технологиях внутри Тинькофф. Сейчас там уже есть развернутый рассказ про
- Sage - наша observability платформа, которая используется для централизованного сбора и анализа телеметрии всех сервисов компании. Предшественником был Splunk
- Kora - наш фреймворк для написания приложений на Java и Kotlin с упором на производительность, эффективность, прозрачность.
- Taiga UI - наша библиотека компонентов, возглавившая целое семейство проектов для комфортной и быстрой разработки приложений на Angular.
- Helicopter — вычислительная платформа с расширенными возможностями для совместной работы команд, которые занимаются исследованиями и операционализацией данных: построением аналитики, ETL-процессов, отчетов и data-приложений. Предшественником был Zeppelin

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

#Software #DistributedSystems #Engineering

Code of Leadership #2  Antifragility in IT

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

Предыстория выпуска такова, что
- Саша с большим интересом делится своим подходом к антихрупкости (он рассказывал про это на Codefest 2023)
- Я недавно прочитал его книгу и уже рассказл про нее раньше
- Когда я предложил Саше прийти в гости, то он легко согласился, а также написал небольшой ответ на мой обзор
- Когда мы обсуждали план на выпуск, то поняли, что интересно будет поговорить про "карты гипотез", продуктовый и проектный подход, работу в модели заказчик/исполнитель или внутри организации и многое другое

Что получилось в итоге можно посмотреть на моем Youtube канале и послушать в виде подкаста на podster.fm

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

Made at Intel

Буквально на днях вышла книга Валерия Черепенникова, которая была собрана из его серии статей "Made at Intel", которые он публиковал на Хабре. И хотя я прочитал больше половины этих статей в момент выхода, я решил, что хочу перечитать их в виде книги и поставить ее к себе в библиотеку. Если кратко, то данная книга является набором историй, где-то веселых, где-то грустных, местами стандартных, а местами выдающихся. Мне очень импорнирует стиль автора и ощущение, что эти истории тебе рассказывает твой приятель, с которым ты встретился в баре и вы травите байки за былые дни, когда трава была зеленее, а небо голубее.
Одновременно, если задумываться об этих историях, то видно, как выглядит
- влияние культуры на все в большой компании (и как это превращается в религию)
- развитие ISA x86 (Instruction Set Architecture) и фокус на этом наборе инструкций в ущерб другим направлениям:)
- непопадание в тренды (mobile, AI, ...) и как это постепенно влияет на неповоротливого Голиафа:)
- федеративное устройство крупной компании, где у разных юнитов разные интересы
- корпоративная политика и ее влияние на высокопоставленных менеджеров и даже направление компании
- merge & acquisitions и как они заканчиваются обычно
- сокращения персонала (cutoffs) и из периодичность
- что бывает если технической компанией начинают руководить бухгалтеры
- и так далее

Честно говоря, книгу просто интересно читать (я справился за несколько часов), а также интересно размышлять и примерять происходившее в Intel на собственный опыт. Поэтому я книгу рекомендую к прочтению.

P.S.
У автора есть tg-канал "Китайский русский", на который я подписан и почитываю время от времени.

#Management #Leadership #SuccessStory #Engineering #Software #Hardware

How to Bake a Change • Daniel Terhorst-North • GOTO 2023

Интересное выступление Daniel Terhorst-North про изменения в организациях. Автор подчеркивает, что не существует универсального рецепта, но это не означает, что консультанты и методические фирмы не выстраиваются в очередь, чтобы продать вам его:) Часто в качестве этого универсального рецепта предлагают SAFe, LeSS, Spotify model (которую сам Spotify давно перерос). Альтернативный взгляд на эту проблему в том, что каждая организация и контекст различны, а значить каждой нужен свой уникальный рецепт, который вам нужно выяснить с нуля. А автор выступления считает, что истина находится где-то посередине. К каждой ситуации нужен свой контекстуальный подход, но не обязательно начинать с нуля. И в этом выступлении он рассказывает про свой подход, который сводится к следующему
1) Understand the problem. Don't just rock up with a solution.
2) Listen to the people. They know their context better than you
3) Seek alignment. Connect people, and bring them on the journey
4) Try small, iterative, evidence-based changes. Science is hard, VESSA is your friend. VESSA is Visualize, Eliminate, Simplify, Standardize, Automate

#Management #Leadership #Software #Processes #Agile

Code of Leadership #3 Herding Cats

Вышел третий выпуск подкаста "Code of Leadership", в котором идет речт про книгу "Как пасти котов", которую мы разбираем с Евгением Кузовлевым. Женя является техническим директором платежей в Тинькофф, входит в программный комитет Highload++ и вообще отлично разбирается как в менеджменте, так и в проектировании сложных систем. Женя предложил обсудить эту книгу не случайно и вот как он описывает сам свой выбор:

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

#Management #Software #Processes #Project #ProductManagement #Engineering #Processes #Leadership

Analogue Evolution, Digital Revolution: Tipping Points in Technology • Dylan Beattie • YOW! 2023

Забавное выступление Dylan Beattie про переломные моменты в развитии технологий. Тут речь шла в основном
- Intro - автор рассказывает про путеводитель, что он купил на Amazon и который был написан ChatGPT:)
- Tipping points - рассказ про концпепцию переломных моментов, в одном из которых мы и находимся по мнению автора (а чтобы пережить его успешно, можно глянуть на предыдущие переломные моменты)
- Film vs digital cameras - история про Kodak, который был лидером в аналоговой фотографии, но потом пришла цифровая
- Music industry - история про появление iPod и новой модели распространения музыки по сравнению с покупкой виниловых дисков, кассет, CD и покупкой музыки альбомами
- GenAI - про генеративный AI на примере DALL-E 3 и генерации картинок
- Books - раньше мы верили тому, что написано в книгах, а теперь легко получить книгу, написанную генеративным интеллектом
- Stack Overflow - и эта база вопросов и ответов идет в сторону обучения модельки и дальше создания ассистента для помощи решения типовых проблем прямо в IDE
- Will AI replace software engineers? - интересный вопрос, ответ на который в том, что GenAI пока умеет писать код, а software engineer умеет работать с требованиями, проектировать надежное и производительное решение (и пока есть scope работы для хороших инженеров)
- DALL-E - стеб над тем, что при генерации изображений GenAI вообще не раздупляет смысл запроса и смысл ответа:)
- ChatGPT - стеб над тем, что ChatGPT не понимает смысл запроса и ответа на примере созданния аннаграм по запросу
- Alice & Bob - мысленный эксперимент с обучением ассистента на базе LLM и дальше передачу ему полномочий для заботы о себе
- Solid project - автор рассказывает про Solid (Social Linked Data), проект по созданию децентрализованной всемирной паутины инспирированный Тимом Бернерс-Ли, автором изначальной концепции WWW, разработанной совместно с Массачусетским технологическим институтом (MIT).
- Conclusion - рассказ про стикеры и просьбу сгенерировать стикер для Metadata аля стикер Metallica (спойлер: DALL-E 3 не справился без ошибок с написанием слова metadata), а потом Ones N' Zeros в стиле Guns N' Roses, где DALL-E 3 опять не справился, но смог помочь с частью работы при ручной генерации

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

#AI #ML #Software #SoftwareDevelopment #Engineering

Вакансия R&D Lead в AI-ассистент разработчика @ Tinkoff

В новогоднем выпуске Code of Architecture мы говорили про подходы в RnD в Google и как это выглядит у нас в Тинькофф.
Гостями эфира были наши коллеги
- Игорь Маслов, руководитель управления базовых технологий и обработки данных Тинькофф
- Станислав Моисеев, директор инженерных исследований в Тинькофф

А сейчас Стас открыл первую вакансию себе в команду. Он ищет лида на R&D в области AI-ассистентов. Это отличная возможность подключиться к крутой команде и поработать над перспективным продуктом. Ваша работа сможет повлиять на тысячи инженеров внутри компании, помочь снять им часть когнитивной нагрузки и повысить эффективность. Процитирую выдержки из описания вакансии, которую показывают насколько это интересная тема

Искусственный интеллект применяется повсеместно. AI-ассистенты разработчиков, например GitHub Copilot, Amazon CodeWhisperer, Tabnine, Codeium, Replit Ghostwriter, трансформируют привычный стиль работы инженеров-программистов. Мы видим потенциал снижения когнитивной нагрузки при использовании AI-ассистентов для разработчиков ПО, аналитиков данных, data-инженеров, QA-инженеров, специалистов SRE, системных аналитиков, технологов и других.
Наша команда исследует и разрабатывает AI-ассистентов для разных задач. Первая версия для инженеров-программистов уже используется в компании. Сейчас мы работаем над расширением ее функций, поддержкой новых сценариев и улучшением решений.
Наша цель — разработать ассистент для инженеров-программистов с широкой функциональностью: автодополнением, модификацией кода, рефакторингом, объяснением кода, генерацией документации и тестов, поиском ошибок и стилистических проблем, оптимизацией кода, анализом уязвимостей и так далее.

Если вам понравилась вакансия, то по ее поводу можно писать сразу Стасу (@stanislav_moiseev)

#Vacancy #AI #ML #Engineering #Management