#Highload Сергей Ларионенко (Авито) OpenTelemetry и эволюция распределенного пайплайна трейсинга в Авито. Это песня о том, как, сделав пайплайн на открытых инструментах, они разбирались с потерей 70% трейсов, расшивая узкие горла и делая форки в туле. Проблема началась с обнаружения битых трейсов. Вставили проверку на связность графа - и обнаружили что таких 70%. Начали разбираться. Обнаружили, что на нодах следующая конструкция: много обработчиков пишут в Go-канал, а дальше этот канал вычитывается только одним потоком и передается на другую ноду. Запись в Go-канал - точка синхронизации, буфер канала ограничен. И сделано, что когда в буфер нельзя записать, то пакет просто теряется, и увеличивается статистика сбоев. Только они этого не видят, потому что статистика в конструкторе инициализирована NullFactory. А поток вычитывания работает медленно, потому что там синхронный вызов удаленный вызов по gRpc, и на приемной стороне - приличная обработка. Для решения сделали fork Otel batching, несколько процессов чтения, из которых активен один, но при исчерпании буфера переключаемся на следующий. Массовые сбои ушли, остались индивидуальные, причина - падал коллектор данных. А он падал потому, что там две процедуры: обработка очередного события и оценка, что накопленные события пора отправлять пакетом. И оказалось, что там код написан так, что при одновременном выполнении получается конфликт и все падает. Это тоже поправили. Все заработало.
👍2
#Highload Илья Иванов из Яндекс 360. Архитектура биллинга: как не стать единой точкой отказа. В докладе - архитектура биллинга. Она по факту трехслойная. Сам биллинг получает сумму, которую надо списать за услуги, выставляет счета, принимает оплату, выдает чеки и готовит отчеты. Тарификацию ведут пребиллинги, связанные с конкретными бизнесами, в них - тарифы, промоакции и промокоды. А также платежные механики - подписки или другие способы учета. Они зависят от каждого бизнеса, свои для Яндекс 360, Яндекс Плюс, Яндекс Облако и так далее, потому что каждый из них ведет свою тарифную и рекламную политику, которую надо менять независимо от других. Собственно, независимое развитие бизнесов как раз является основанием для такой архитектуры, а вовсе не соображения про точку отказа - централизованный биллинг по-прежнему им является.
Пребиллинг в Яндекс 360 переводит конкретные тарифы в наборы подключенных услуг, которые могут быть подключены индивидуально и для компании, при этом часть услуг для компании переводится в индивидуальные для сотрудников. Добавление услуги инициирует добавление для всех сотрудников, каждое добавление выполняется индивидуально и асинхронно, простая модель состояний init-sinking-actual, поэтому даже при больших организациях 10к+ человек выполняется быстро. Добавление услуги означает обращение к конкретному сервису с установкой там каких-то квот, например, объема доступного диска. И далее этот сервис работает в пределах квоты ресурсов, или количества писем. При этом одни ресурсы, например, диск, выделяются индивидуально, а другие, например количество писем в рассылках, может быть установлено общее, на всех сотрудников компании.
Неявное ограничение модели - не должно быть ситуации, когда несколько сервисов расходуют один и тот же ресурс, или они должны сами проверять его расход, чтобы не было преувеличения. Конструкция биллинга для мобильных операторов, когда все сервисы (звонки, смс, интернет) тратят одни и те же деньги на счете в реальном времени до исчерпания тут не сделать. Но это уже мое дополнение.
А вообще доклад получился, на мой взгляд, достаточно простым и очевидным, а тема единой точки рассказ раскрыта не была. Впрочем, может это так с учетом моего опыта.
Пребиллинг в Яндекс 360 переводит конкретные тарифы в наборы подключенных услуг, которые могут быть подключены индивидуально и для компании, при этом часть услуг для компании переводится в индивидуальные для сотрудников. Добавление услуги инициирует добавление для всех сотрудников, каждое добавление выполняется индивидуально и асинхронно, простая модель состояний init-sinking-actual, поэтому даже при больших организациях 10к+ человек выполняется быстро. Добавление услуги означает обращение к конкретному сервису с установкой там каких-то квот, например, объема доступного диска. И далее этот сервис работает в пределах квоты ресурсов, или количества писем. При этом одни ресурсы, например, диск, выделяются индивидуально, а другие, например количество писем в рассылках, может быть установлено общее, на всех сотрудников компании.
Неявное ограничение модели - не должно быть ситуации, когда несколько сервисов расходуют один и тот же ресурс, или они должны сами проверять его расход, чтобы не было преувеличения. Конструкция биллинга для мобильных операторов, когда все сервисы (звонки, смс, интернет) тратят одни и те же деньги на счете в реальном времени до исчерпания тут не сделать. Но это уже мое дополнение.
А вообще доклад получился, на мой взгляд, достаточно простым и очевидным, а тема единой точки рассказ раскрыта не была. Впрочем, может это так с учетом моего опыта.
❤1
#Highload Алексей Цветков. Как воспитать себе помощника: применение локального ИИ для разработки. Это был рассказ о практических возможностях ИИ быть помощником по разработке. При этом, что важно, использовалась автономная версия, которая с нормальной скоростью работает локально на обычном компе разработчика (в презентации были характеристики). А по мощности она сравнима с GPT-4, Gemini, Copilot, правда в специализированной области разработке софта. Модель не зависит от конкретного языка и знает 338 разных языков. Модели загружаются с помощью ollama, рекомендуется модель codestral:22b (при подготовке он использовал предыдущую версию), и нужен плагин continue для VScode и GoLang - он позволяет обращаться из среды к провайдерам. Модель умеет из коробки строить индекс по вашему проекту и использовать его при выполнении заданий. В презентации были конкретные команды и ссылки.
Первым было тестовое задание: напиши функцию на Go для слияния каналов в один. За минуту достаточно хороший код, еще с комментариями на русском. Правда, с ошибками. И в реальной задаче мы их не можем увидеть через ревью. Однако, модель можно попросить написать юнит-тесты, и дальше рассматривать по-отдельности. И модель пишет тесты с большей охотой, чем разработчики.
Дальше - попытка сделать реальный проект - прототип распределенной платежной системы: сервис на Java, который получает поручения от человека и делает балансы на шардах, каждый из которых ведет баланс. Код порождался в несколько этапов, он выдавал задания. По коду была построена компонентная схема вызовов методов и диаграмма последовательности. А еще gRPC API, dockerfile для сборки, yaml для запуска, описание и схемы и тест-кейсы. Тест-кейсы - простые, но на вопрос, а что еще можно предложить, был выдан список сложных тест-кейсов: сложные, обработки ошибок, параллелизма, нагрузочное, стабильности, времени ответа, и далее можно предложить каждый их написать. Вообще это типичный способ работы: ты не сразу требуешь написать проект, а по шагам. В том числе - предложить план, а потом этот план по шагам исполняешь. Типиная работа с джуном в обучающем режиме.
Всего генерация проекта - 30 запросов к модели, 10 уточняющих. Результат 15 файлов, 3 без исправлений, а в остальных потребовались исправления человеком при отладке, но сильно меньше объема файла, всего около 5% строк. Правда, в Java процент больше, около 15% На слайде была детальная информация, и это выложено на github.
Интересное применение: читать постановки, код, логи. Модель может держать большое количество объектов. И у нее есть специализированные знания, например, как сделать сложный makefile.
В запросе можно указывать файлы, которые добавляются в запрос для контекста. Есть API и структура БД - и модель реализует CRUD. Смотришь - нет транзакций для согласованного изменения таблиц баланса и операций. Спрашиваешь "а ты консистентно сделал?" - модель сама говорит про транзакции, и может их в код добавить.
Механизм RAG. Кодовая база разбивается на фрагменты, и модель выдает вектор смысла. embeding и индекс. Запрос тоже пропускается через embeding и модель добавляет релевантные кусочки. Например, получить весь список сервисов. И описать конкретные сервисы. Или показать, где происходит распределение счетов по шардам. И это - помощь в освоении кода незнакомого проекта.
Модель может сделать рефакторинг, тоже по шагам: сначала - какие файлы затронет, потом - что поменять в каждом из них. Для теста он попросил в проекте поменять количество шардов с 2 до 8 и получил осмысленные результаты, хотя и с ошибками.
Что локальный ИИ не может делать хорошо
* Отладка сложных кейсов в runtime - для этого надо понять состояние системы в момент ошибки, а он его не знает
* Ограниченный контекст. 16384 токена, у новой - на порядок больше. Но все равно есть ограничения, и по окну внимания.
* Редактирование многих файлов одним запросом, надо по-одному.
* Выполнение последовательности одним запросом - надо дробить на куски (но набор кусков он может предложить).
Первым было тестовое задание: напиши функцию на Go для слияния каналов в один. За минуту достаточно хороший код, еще с комментариями на русском. Правда, с ошибками. И в реальной задаче мы их не можем увидеть через ревью. Однако, модель можно попросить написать юнит-тесты, и дальше рассматривать по-отдельности. И модель пишет тесты с большей охотой, чем разработчики.
Дальше - попытка сделать реальный проект - прототип распределенной платежной системы: сервис на Java, который получает поручения от человека и делает балансы на шардах, каждый из которых ведет баланс. Код порождался в несколько этапов, он выдавал задания. По коду была построена компонентная схема вызовов методов и диаграмма последовательности. А еще gRPC API, dockerfile для сборки, yaml для запуска, описание и схемы и тест-кейсы. Тест-кейсы - простые, но на вопрос, а что еще можно предложить, был выдан список сложных тест-кейсов: сложные, обработки ошибок, параллелизма, нагрузочное, стабильности, времени ответа, и далее можно предложить каждый их написать. Вообще это типичный способ работы: ты не сразу требуешь написать проект, а по шагам. В том числе - предложить план, а потом этот план по шагам исполняешь. Типиная работа с джуном в обучающем режиме.
Всего генерация проекта - 30 запросов к модели, 10 уточняющих. Результат 15 файлов, 3 без исправлений, а в остальных потребовались исправления человеком при отладке, но сильно меньше объема файла, всего около 5% строк. Правда, в Java процент больше, около 15% На слайде была детальная информация, и это выложено на github.
Интересное применение: читать постановки, код, логи. Модель может держать большое количество объектов. И у нее есть специализированные знания, например, как сделать сложный makefile.
В запросе можно указывать файлы, которые добавляются в запрос для контекста. Есть API и структура БД - и модель реализует CRUD. Смотришь - нет транзакций для согласованного изменения таблиц баланса и операций. Спрашиваешь "а ты консистентно сделал?" - модель сама говорит про транзакции, и может их в код добавить.
Механизм RAG. Кодовая база разбивается на фрагменты, и модель выдает вектор смысла. embeding и индекс. Запрос тоже пропускается через embeding и модель добавляет релевантные кусочки. Например, получить весь список сервисов. И описать конкретные сервисы. Или показать, где происходит распределение счетов по шардам. И это - помощь в освоении кода незнакомого проекта.
Модель может сделать рефакторинг, тоже по шагам: сначала - какие файлы затронет, потом - что поменять в каждом из них. Для теста он попросил в проекте поменять количество шардов с 2 до 8 и получил осмысленные результаты, хотя и с ошибками.
Что локальный ИИ не может делать хорошо
* Отладка сложных кейсов в runtime - для этого надо понять состояние системы в момент ошибки, а он его не знает
* Ограниченный контекст. 16384 токена, у новой - на порядок больше. Но все равно есть ограничения, и по окну внимания.
* Редактирование многих файлов одним запросом, надо по-одному.
* Выполнение последовательности одним запросом - надо дробить на куски (но набор кусков он может предложить).
👍2
Таким образом, даже локальные генеративные модели хорошо понимают то, чем занимаемся разработчик. Он бы модельный проект сделал быстрее, но про джуна - не уверен. Модели могут допускать ошибки - но люди тоже допускают, надо придумать защиту, например, тесты. Бум ИИ пришел на нашу улицу, они повышают скорость и качество результатов. Опасности, что джуны разучатся разрабатывать, работая с моделью Алексей не видит, потому что конечный результат все равно надо доводить совместно. А для этого надо разобраться в коде, который модель сделала. Она может его объяснить, построить схемы. Так что, скорее, джуны научатся.
На этом я завршаю отчет с Highload. В целом конференция была ожидаемая: хорошие доклады и много общения. И опять больше предыдущей, на этот раз было 2500 участников. А в четверг - Teamlead.
На этом я завршаю отчет с Highload. В целом конференция была ожидаемая: хорошие доклады и много общения. И опять больше предыдущей, на этот раз было 2500 участников. А в четверг - Teamlead.
👍5
#Teadmlead Максим Смирнов. Как рассказывать архитектурные диаграммы. Доклад из двух частей. Сначала пять затруднений, которые возникают при презентации архитектуры и способах их преодоления, а потом - о том, как сделать хороший рассказ. Вторая часть не следует из первой, она поверх нее.
Рассказывать на реальном сложно - погружение в контекст. Есть кейсы, на которых O'Reily проводит соревнования архитекторов, варианты выкладываются на github. Если не в курсе - гуглите, это интересно. И рассказ был на кейсе Sysops Squad: гигант электроники с продажами по всей стране. При покупке - абонентское обслуживание, при проблеме специалисты приезжают.
Пять затруднений
1. Пояснить запутанную диаграмму - в этом запутываешься сам и путаешь других
2. Неясно, что надо рассказывать
3. Риск потеряться в вариантах развития событий. Их много, люди не держат контекста
4. Сложно не утонуть в обсуждении деталей
5. Непонятно, как донести замысел архитектурного решения
Теперь про каждую.
Сложность. В примере большая c4 диаграмма, как водится с мелкими надписями. Подробно рассказать - невозможно, а перечисление типа "5 контейнеров, 8 очередей" - это не содержание!
Реально содержание архитектуры - другое
* Вытащим из монолита компоненты взаимодействия с клиентами
* И все их взаимодействие - через асинхронные очереди
* А взаимодействие с инженерами - вторая часть
* И третья и четвертая - платежи и отчетность
Его и надо рассказывать. И я отмечу, что для этого надо подготовиться заранее: раскрасить квадратики в разные цвета, возможно, сделать обводы и фоновые выделения. А может и нарисовать более крупную диаграмму для рассказа.
Другая идея: смотреть на картину как на карту и поверх нее рассказывать, как развиваются события - просто показать последовательность как взаимодействуют компоненты. Я бы для этого тоже крупно заранее пронумеровал пунты такого взаимодействия.
Еще отмечу, что это - два разных рассказа, для разных целей и аудиторий, и надо понимать, что именно ты рассказываешь.
В алгоритмах и поведении есть развилки, а в историях - их нет. Use case решают это через основной и дополнительные ветви. И в рассказе тоже не нужно рассказывать все варианты. Расскажите основной. Я тут дополню, что часто кроме основного есть особенно интересные кейсы, обычно касающиеся того, с чем имеются или предполагаются трудности. А структура через use case еще и поможет при вопросах про детали: вы переключаетесь на дополнительную ветку, потом возвращаетесь.
Как донести замысел решения? Есть формат.
1. Цель: желаемый результат, целевое состояние в которое хотим понять
2. Что мешает достичь целевого результата просто - препятствия
3. Хитрость, ловкий прием чтобы преодолеть эти препятствия
Три подсказки.
1. Используйте шаблон ADR записи архитектурного решения
2. Обсуждайте альтернативные варианты. Их обязательно надо сформулировать и обсудить
3. Передайте эстафету решения вашим слушателям
Шаблон Y-statements
1. Контекст - для чего применимо архитектурное решения
2. Facing - для каких требований архитектура, что мешает просто взять и сделать
3. we decided - что решили
4. and neglected - от чего отказались
5. we achieve - что мы достигнем
6. accepting what - какую цену заплатим
Например. Пиковая нагрузка может быть вызвана специфическими запросами в начале месяца - и их можно вынести в отдельный масштабируемый сервис, чтобы на основу это не влияло. Но система в целом станет сложнее.
Зачем обсуждать альтернативы? Тут пример домика: дешево и быстро, быстро и дорого, дорого и хорошо, слишком хорошо. Мы проектируем индивидуально, не вовлекая заказчика. И он далеко не всегда специалист. Но если мы предлагаем варианты - то получается пространство выбора. И критерии могут быть различны.
B конце презентации был канвас для рассказа, он опубликован на канале Максима @it_arch, посвященному архитектуре.
Рассказывать на реальном сложно - погружение в контекст. Есть кейсы, на которых O'Reily проводит соревнования архитекторов, варианты выкладываются на github. Если не в курсе - гуглите, это интересно. И рассказ был на кейсе Sysops Squad: гигант электроники с продажами по всей стране. При покупке - абонентское обслуживание, при проблеме специалисты приезжают.
Пять затруднений
1. Пояснить запутанную диаграмму - в этом запутываешься сам и путаешь других
2. Неясно, что надо рассказывать
3. Риск потеряться в вариантах развития событий. Их много, люди не держат контекста
4. Сложно не утонуть в обсуждении деталей
5. Непонятно, как донести замысел архитектурного решения
Теперь про каждую.
Сложность. В примере большая c4 диаграмма, как водится с мелкими надписями. Подробно рассказать - невозможно, а перечисление типа "5 контейнеров, 8 очередей" - это не содержание!
Реально содержание архитектуры - другое
* Вытащим из монолита компоненты взаимодействия с клиентами
* И все их взаимодействие - через асинхронные очереди
* А взаимодействие с инженерами - вторая часть
* И третья и четвертая - платежи и отчетность
Его и надо рассказывать. И я отмечу, что для этого надо подготовиться заранее: раскрасить квадратики в разные цвета, возможно, сделать обводы и фоновые выделения. А может и нарисовать более крупную диаграмму для рассказа.
Другая идея: смотреть на картину как на карту и поверх нее рассказывать, как развиваются события - просто показать последовательность как взаимодействуют компоненты. Я бы для этого тоже крупно заранее пронумеровал пунты такого взаимодействия.
Еще отмечу, что это - два разных рассказа, для разных целей и аудиторий, и надо понимать, что именно ты рассказываешь.
В алгоритмах и поведении есть развилки, а в историях - их нет. Use case решают это через основной и дополнительные ветви. И в рассказе тоже не нужно рассказывать все варианты. Расскажите основной. Я тут дополню, что часто кроме основного есть особенно интересные кейсы, обычно касающиеся того, с чем имеются или предполагаются трудности. А структура через use case еще и поможет при вопросах про детали: вы переключаетесь на дополнительную ветку, потом возвращаетесь.
Как донести замысел решения? Есть формат.
1. Цель: желаемый результат, целевое состояние в которое хотим понять
2. Что мешает достичь целевого результата просто - препятствия
3. Хитрость, ловкий прием чтобы преодолеть эти препятствия
Три подсказки.
1. Используйте шаблон ADR записи архитектурного решения
2. Обсуждайте альтернативные варианты. Их обязательно надо сформулировать и обсудить
3. Передайте эстафету решения вашим слушателям
Шаблон Y-statements
1. Контекст - для чего применимо архитектурное решения
2. Facing - для каких требований архитектура, что мешает просто взять и сделать
3. we decided - что решили
4. and neglected - от чего отказались
5. we achieve - что мы достигнем
6. accepting what - какую цену заплатим
Например. Пиковая нагрузка может быть вызвана специфическими запросами в начале месяца - и их можно вынести в отдельный масштабируемый сервис, чтобы на основу это не влияло. Но система в целом станет сложнее.
Зачем обсуждать альтернативы? Тут пример домика: дешево и быстро, быстро и дорого, дорого и хорошо, слишком хорошо. Мы проектируем индивидуально, не вовлекая заказчика. И он далеко не всегда специалист. Но если мы предлагаем варианты - то получается пространство выбора. И критерии могут быть различны.
B конце презентации был канвас для рассказа, он опубликован на канале Максима @it_arch, посвященному архитектуре.
❤3🔥2👍1😐1
#Teamlead Игорь Гранщиков из Авито. Система управления с обратной связью. Тимлид вырастает и начинает руководить не командой, а другими тимлидами. И тут старая система управления перестает работать, надо строить новую, о которой был доклад. Система состоит из двух элементов: целеполагание и операционное ревью, на котором оценивается текущее состояние команд. При этом у руководителя - светофорная модель из метрик, и если на ней горит красный сигнал, то разобраться в деталях - задача тимлида. В этом смысле, получается, что руководитель второго уровня внутри квартала не нужен - за светофорами может наблюдать и автомат. Ну или у него получается почти бесконечное масштабирование по числу команд. Какая-то тут есть засада.
Возвращаясь к докладу. Целеполагание. Три группы целей:
* Продукт - ценность, поставляемая в продакшн
* Процессы - метрики их функционирования, например, cycle time
* Люди: счастье, найм.
Цели - фиксируем ожидания. Операционное ревью: есть цели и факт. И если есть невыполнение или риск невыполнения - должен сработать триггер и дать корректировку действий.
Были рассмотрены 5 задач.
1. Контролировать результативность и эффективность
2. Настраивать процессы чужими командами
3. Запускать команды чужими руками
4. Контролировать перформанс-менеджмент
5. Развивать старших инженеров.
Теперь о них по порядку.
1. Контролировать результативность и эффективность. Результативность - делать правильные вещи, эффективность - делать их правильно (быстро, качественно). Это - разное, следить надо за обоими.
Burndown. Результативность - поставка того, что выпускает. План-факт. А скорость - эффективность, производная от скорости. Одна из метрик - cycle time.
Если цель - запустить ипотечную анкету на мобильных платформах. Отставание 10 дней, один из эпиков заблокирован смежниками. Метод изменений: в начале квартала сверять планы свои со смежниками. Цель по cycle time может быть не достигнута по той же причине.
Тимлид докапывается до причин, а руководитель тимлидов смотрит на светофор. Есть еще несоклько метрик индексов: support ticket sla reaction, zero bug policy, crashes, LSR SLA
2. Настраиваем процессы чужими руками. Досталось легаси плохого качества, много пользователей обращались в поддержку. Обращения матчатся с багами, для каждого известно. Цель: привести HD count к целевому значению. И количество решенных тикетов от суппорта 10+. Дальше мониторили - и получилось успешно за пару кварталов. Потом вывели на мониторинг.
3. Запускать команды чужими руками. При запуске команды есть общее: процессы и практики соответствуют стандарту. Agile periodic table - чек лист. Начал печатать, класть на стол и помечать. Но не масштабируется.
В Авито есть модель зрелости Team maturity model. Опрос по соответствию. И дальше по каждому пункту светофорная модель. Тимлид видит детали у себя, а руководитель - сводку по командам и динамику. И раз есть метрика - мы можем ставить цели по движению по по модели.
4. Контролировать performance management. Тимлиды затягивают обратную связь сотрудникам. Особенно начинающие. И начал включать в операционное ревью мини-оценку сотрудника. При этом требовалось каждого оценить, обязательно хорошо-плохо. Бинарно, нормально объединено с хорошо, и это - сознательно. Потому что у начинающего тимлида нормально - это плохо, по которому он не хочет выдавать обратную связь. Если плохо - то причины и action plan. Это побуждает тимлида давать обратную связь.
5. Развивать старших инженеров. Стандартные планы не работают, нужны нестандартные challenge. Например challenge: реализовать платформу календарей и применить для разных платформ. Или повысить SLA.
Как часто? Есть быстродействие, регулирование и точность. Слишком часто - задергаем команду, слишком редко - не будем реагировать. Целеполагание - как целеполагание в организации, у них раз в квартал. А операционное ревью 10% - 1-2 недели (9 дней формально). На последней период операционного ревью есть выполнение целей. И мы можем воспользоваться для обратной связи. Но! Это не должно становиться KPI, это должно быть поддерживающей штукой.
Возвращаясь к докладу. Целеполагание. Три группы целей:
* Продукт - ценность, поставляемая в продакшн
* Процессы - метрики их функционирования, например, cycle time
* Люди: счастье, найм.
Цели - фиксируем ожидания. Операционное ревью: есть цели и факт. И если есть невыполнение или риск невыполнения - должен сработать триггер и дать корректировку действий.
Были рассмотрены 5 задач.
1. Контролировать результативность и эффективность
2. Настраивать процессы чужими командами
3. Запускать команды чужими руками
4. Контролировать перформанс-менеджмент
5. Развивать старших инженеров.
Теперь о них по порядку.
1. Контролировать результативность и эффективность. Результативность - делать правильные вещи, эффективность - делать их правильно (быстро, качественно). Это - разное, следить надо за обоими.
Burndown. Результативность - поставка того, что выпускает. План-факт. А скорость - эффективность, производная от скорости. Одна из метрик - cycle time.
Если цель - запустить ипотечную анкету на мобильных платформах. Отставание 10 дней, один из эпиков заблокирован смежниками. Метод изменений: в начале квартала сверять планы свои со смежниками. Цель по cycle time может быть не достигнута по той же причине.
Тимлид докапывается до причин, а руководитель тимлидов смотрит на светофор. Есть еще несоклько метрик индексов: support ticket sla reaction, zero bug policy, crashes, LSR SLA
2. Настраиваем процессы чужими руками. Досталось легаси плохого качества, много пользователей обращались в поддержку. Обращения матчатся с багами, для каждого известно. Цель: привести HD count к целевому значению. И количество решенных тикетов от суппорта 10+. Дальше мониторили - и получилось успешно за пару кварталов. Потом вывели на мониторинг.
3. Запускать команды чужими руками. При запуске команды есть общее: процессы и практики соответствуют стандарту. Agile periodic table - чек лист. Начал печатать, класть на стол и помечать. Но не масштабируется.
В Авито есть модель зрелости Team maturity model. Опрос по соответствию. И дальше по каждому пункту светофорная модель. Тимлид видит детали у себя, а руководитель - сводку по командам и динамику. И раз есть метрика - мы можем ставить цели по движению по по модели.
4. Контролировать performance management. Тимлиды затягивают обратную связь сотрудникам. Особенно начинающие. И начал включать в операционное ревью мини-оценку сотрудника. При этом требовалось каждого оценить, обязательно хорошо-плохо. Бинарно, нормально объединено с хорошо, и это - сознательно. Потому что у начинающего тимлида нормально - это плохо, по которому он не хочет выдавать обратную связь. Если плохо - то причины и action plan. Это побуждает тимлида давать обратную связь.
5. Развивать старших инженеров. Стандартные планы не работают, нужны нестандартные challenge. Например challenge: реализовать платформу календарей и применить для разных платформ. Или повысить SLA.
Как часто? Есть быстродействие, регулирование и точность. Слишком часто - задергаем команду, слишком редко - не будем реагировать. Целеполагание - как целеполагание в организации, у них раз в квартал. А операционное ревью 10% - 1-2 недели (9 дней формально). На последней период операционного ревью есть выполнение целей. И мы можем воспользоваться для обратной связи. Но! Это не должно становиться KPI, это должно быть поддерживающей штукой.
Итак, построение системы управления
1. Настройте целеполагание
2. Выберите метрики
3. Настройте операционное ревью - формат
4. Поставьте ревью в календари
5. Make policies explicit - чтобы люди знали, что от них ожидают
В вопросах - метрики же могут не корректно показывать. Ответ: надо периодически исследовать детали, для погружения в команду любит замещать руководителя на время отпуска. И это дает дополнительную диагностику.
1. Настройте целеполагание
2. Выберите метрики
3. Настройте операционное ревью - формат
4. Поставьте ревью в календари
5. Make policies explicit - чтобы люди знали, что от них ожидают
В вопросах - метрики же могут не корректно показывать. Ответ: надо периодически исследовать детали, для погружения в команду любит замещать руководителя на время отпуска. И это дает дополнительную диагностику.
👍5
#Teamlead Роман Поборчий. Особенности создания внутренних сервисов в крупных компаниях, и как избежать провала. Рассказ начался с вопроса, что такое провал? Мы попробовали, сделали, но это не оказалось полезным. Это провал или нет? Ответ - итерация, мы потратили свое время и чужие деньги, чтобы уточнить картину мира. Полезный опыт.
Дальше была история. 1957 fairchild semiconductor. 8 человек уволились от William Shockley, чтобы основать свою компанию, и основали ее как дочку fairchild, которая занималась разным. Они изобрели интегральную схему и начали делать, начали делать процессоры и память. Одновременно с Килби, было признано. В 1971 Don Hoefler написал статью про fairchild semiconductor, где впервые употребил термин silicon valley - и он прижился.
Все росло в 2 раза, и был год, когда дочка приносила 60% холдингу, там были внутренние дележки. Но в 1968 двое ушли, основали Integrated Electronics - Intel, был первый коммерчески неуспешный год. А в 1969 - Sanders уволился и основал advanced micro devices - AMD.
Провал - когда вы были в нужное время в нужном мести, придумали то что нужно людям, сделали. Но у вас это почему-то не получается, а этот нужный сервис делает кто-то другой.
Возвращаясь к внутренним сервисам. Внутренний сервис - это сервис, потребителями которого являются клиенты компании, может быть разным: платформа, биллинг, аналитика (человек+машина). Внутренние пользователи и внешние - отличаются. Внешние - многочисленны, обезличены. Хотя в b2b некоторые важнее других. Но в целом восполнимый ресурс. Внутри пользователей мало, они рядом с руководством, и они - не восполнимый ресурс.
Внутренний сервис делает своему подразделению, часто маленькими ресурсами, а потом распространяют на другие. И общий принцип: не стоит делать чужую работу. И есть подводные камни, которые этому мешают.
1. Интеграция. Аналитический сервис, мы получаем данные и возвращаем. Клиент приходит, говорит где взять. А дальше много клиентов - и везде разные форматы и разные данные. И интеграция разнородных форматов начинает занимать значительную часть работы. Нанять 15 стажеров - не выход, с ними надо общаться, развивать, они не хотят всю жизнь парсить логи, они отнимают твое время. А еще любые внутренние логи могут поменять формат и вам надо будет переделывать. Да еще тесты у них не упадут - НЕ работает у вас.
Поэтому правильно оставить интеграцию клиента на другом конце: клади данные в этом формате сюда. Но! удобный API - ваша часть. И помощь в написании тестов. Но это работает начиная с 3-4 клиента, первых надо сделать самим - иначе они просто не начнут пользоваться.
2. Приоритеты. Agile учит планировать спринт, собирая заказчиков, и заказчики договариваются. В принципе работает, если общее дело, есть точки пересечения, на которых договариваются. Если же много разных подразделений, то они отказываются договариваться. Не приходят на встречу, а если пришли - только познакомились на ней. И они не договариваются между собой, а пытаются договорить вас. Ошибка - пытаться самому принять решение, кто важнее. Но если подразделения далекие и компания большая, то вы не можете сделать.
Что помогает? Наименьший общий начальник. Был кейс в Яндекс-поиске, много начальник. Но оказалось, что можно привлечь к планированию одного из топов. Пару раз в месяц, на планировании спринта, он приходил. Так бывает можно, не надо бояться.
Правда, на мой взгляд, это больше счастливый случай, а не правило. Если же НОК не доступен - приходится решать самому. Помогают квоты и предложение при срочных азачах ими меняться или брать в долг. Дело в том, что не хотят договариваться не со зла, а потому что нет времени вникнать в проблемы другого, а чтобы договориться - это нужно. А обмен или взять в долг - понятная конструкция.
Дальше была история. 1957 fairchild semiconductor. 8 человек уволились от William Shockley, чтобы основать свою компанию, и основали ее как дочку fairchild, которая занималась разным. Они изобрели интегральную схему и начали делать, начали делать процессоры и память. Одновременно с Килби, было признано. В 1971 Don Hoefler написал статью про fairchild semiconductor, где впервые употребил термин silicon valley - и он прижился.
Все росло в 2 раза, и был год, когда дочка приносила 60% холдингу, там были внутренние дележки. Но в 1968 двое ушли, основали Integrated Electronics - Intel, был первый коммерчески неуспешный год. А в 1969 - Sanders уволился и основал advanced micro devices - AMD.
Провал - когда вы были в нужное время в нужном мести, придумали то что нужно людям, сделали. Но у вас это почему-то не получается, а этот нужный сервис делает кто-то другой.
Возвращаясь к внутренним сервисам. Внутренний сервис - это сервис, потребителями которого являются клиенты компании, может быть разным: платформа, биллинг, аналитика (человек+машина). Внутренние пользователи и внешние - отличаются. Внешние - многочисленны, обезличены. Хотя в b2b некоторые важнее других. Но в целом восполнимый ресурс. Внутри пользователей мало, они рядом с руководством, и они - не восполнимый ресурс.
Внутренний сервис делает своему подразделению, часто маленькими ресурсами, а потом распространяют на другие. И общий принцип: не стоит делать чужую работу. И есть подводные камни, которые этому мешают.
1. Интеграция. Аналитический сервис, мы получаем данные и возвращаем. Клиент приходит, говорит где взять. А дальше много клиентов - и везде разные форматы и разные данные. И интеграция разнородных форматов начинает занимать значительную часть работы. Нанять 15 стажеров - не выход, с ними надо общаться, развивать, они не хотят всю жизнь парсить логи, они отнимают твое время. А еще любые внутренние логи могут поменять формат и вам надо будет переделывать. Да еще тесты у них не упадут - НЕ работает у вас.
Поэтому правильно оставить интеграцию клиента на другом конце: клади данные в этом формате сюда. Но! удобный API - ваша часть. И помощь в написании тестов. Но это работает начиная с 3-4 клиента, первых надо сделать самим - иначе они просто не начнут пользоваться.
2. Приоритеты. Agile учит планировать спринт, собирая заказчиков, и заказчики договариваются. В принципе работает, если общее дело, есть точки пересечения, на которых договариваются. Если же много разных подразделений, то они отказываются договариваться. Не приходят на встречу, а если пришли - только познакомились на ней. И они не договариваются между собой, а пытаются договорить вас. Ошибка - пытаться самому принять решение, кто важнее. Но если подразделения далекие и компания большая, то вы не можете сделать.
Что помогает? Наименьший общий начальник. Был кейс в Яндекс-поиске, много начальник. Но оказалось, что можно привлечь к планированию одного из топов. Пару раз в месяц, на планировании спринта, он приходил. Так бывает можно, не надо бояться.
Правда, на мой взгляд, это больше счастливый случай, а не правило. Если же НОК не доступен - приходится решать самому. Помогают квоты и предложение при срочных азачах ими меняться или брать в долг. Дело в том, что не хотят договариваться не со зла, а потому что нет времени вникнать в проблемы другого, а чтобы договориться - это нужно. А обмен или взять в долг - понятная конструкция.
👍2
Еще один трюк. После планирования приходит заказчик, говорит "Мне очень надо, ты сделай, давай я тебе помогу". Ваша работа - заранее думать, что я могу попросить у такого клиента. И в этот момент быть готовым попросить. В идеале, когда разовая услуга меняется на долгосрочные обязательства. Например, попросили сервис, который в ответ на слово отдавал основную форму - это часто нужно. Это выигрышная стратегия, стоит вкладываться.
3. Стабильность. Начинается на маленьком железе, старый сервер. Внутренние лучше внешних, они не уходят, осознают ресурсный голод. Но в какой-то момент не могут терпеть. Как оттянуть этот момент, и успеть сделать нормально?
Если от внутреннего сервиса не зависит продакшн - его не обязательно резервировать. Достаточно мониторить и вешать плашку "не работаю планово". И по входным данным - вести мониторинг, вешать плашку "мы уже знаем". Это как "мы адекватны и стараемся".
Рост нагрузки системы. Измеряться может в разном, а скачки - с новым клиентом. И часто есть точка апокалипсиса - ресурс весь потребляется. Например, может быть время на ежедневную обработку данных - не должно превышать 24 часа. Пока всего мало, можно проводить тесты и предсказать точку апокалипсиса. Это надо сделать и готовиться.
Мониторинг и информирование - важнее постоянной доступности.
4. Велосипеды. Однажды было нужно строить тепловую карту России по метрикам, по регионам. Маленькая команда, Apach Superset - позволяет подобное делать. Но! Деление по регионам может быть не очень хорошим, Красноярский край - большой, надо дробить. А еще есть города - миллионники - они маленькие, людей много - их надо показывать специально. А еще состав региона надо уметь менять. Коробка - не поддерживает. В результате аналитик данных занимается тем, что пытается поставить точку в нужное место и другой борьбой с инструментом. В результате, пока боролись, другая команда напилила собственные карты, начала им предоставлять.
Готовые инструменты хороши для прототипов, но даже для MVP - не обязательно. Надо оценивать, не слишком ли он дорог. Часто на первом этапе нужно небольшое подмножество, но с нашлепкой, которую сложно сделать, и это проще сделать самим.
3. Стабильность. Начинается на маленьком железе, старый сервер. Внутренние лучше внешних, они не уходят, осознают ресурсный голод. Но в какой-то момент не могут терпеть. Как оттянуть этот момент, и успеть сделать нормально?
Если от внутреннего сервиса не зависит продакшн - его не обязательно резервировать. Достаточно мониторить и вешать плашку "не работаю планово". И по входным данным - вести мониторинг, вешать плашку "мы уже знаем". Это как "мы адекватны и стараемся".
Рост нагрузки системы. Измеряться может в разном, а скачки - с новым клиентом. И часто есть точка апокалипсиса - ресурс весь потребляется. Например, может быть время на ежедневную обработку данных - не должно превышать 24 часа. Пока всего мало, можно проводить тесты и предсказать точку апокалипсиса. Это надо сделать и готовиться.
Мониторинг и информирование - важнее постоянной доступности.
4. Велосипеды. Однажды было нужно строить тепловую карту России по метрикам, по регионам. Маленькая команда, Apach Superset - позволяет подобное делать. Но! Деление по регионам может быть не очень хорошим, Красноярский край - большой, надо дробить. А еще есть города - миллионники - они маленькие, людей много - их надо показывать специально. А еще состав региона надо уметь менять. Коробка - не поддерживает. В результате аналитик данных занимается тем, что пытается поставить точку в нужное место и другой борьбой с инструментом. В результате, пока боролись, другая команда напилила собственные карты, начала им предоставлять.
Готовые инструменты хороши для прототипов, но даже для MVP - не обязательно. Надо оценивать, не слишком ли он дорог. Часто на первом этапе нужно небольшое подмножество, но с нашлепкой, которую сложно сделать, и это проще сделать самим.
👍4
#Teamlead Эрик Бурыгин. Сила нетворкинга, или Нетворкинг как стиль жизни. Доклад с одной сквозной историей о пользе нетворкинга и множестве частных. Основная идея: не бойтесь начать, и активно делайте. Потому что нетворкинг реально помогает достигать своих желаний и осуществлять мечты. Сила в том, что когда вам что-то нужно - вы знаете у кого спросить, и вам расскажут. Например, вы умеете шить одежду, захотели запустить производство - и вам расскажут процесс в деталях, ведь уметь шить - далеко не все. А еще через нетворкинг можно найти ресурсы. Но чтобы это случилось, надо активно знакомится, знать кто чем может помочь. Не когда у вас возник конкретных вопрос, а заранее, чтобы когда вопрос возник - уже было понятно кто ответит. При этом жизнь часто ходит очень извилистыми путями, но приводит в нужном направлении, если вы при этом активны и ловите моменты.
Это иллюстрирует сквозная история - о том, как Эрик хотел сделать курсы, и даже учился этому - но у него не получалось. Но однажды он попал в Гонку героев. Потому что до этого хотел попасть в спорт, было 100500 попыток, но не складывалось. А тут увидел в инстаграмме фотку с гонки героев, где был его друг, узнал, решил в очередной раз попробовать, друг дал телефон - и этот вариант зашел. И он не просто участвовал, а стал инструктором, сдал необходимое, хотя для этого пришлось с другими инструкторами договориться о переносе даты экзамена, он не мог в назначенную. А потом был тренинг по публичным выступлениям, где он человек рассказывал про Яндекс-практикум, и он подумал, что это клевое место, пошел туда работать. Но с курсом не складывалось, надо было пройти обучение, а там не было вакансий. Однако, Гонка героев осталась, он собрал команду от Яндекса, только формально они опоздали, но поскольку руководитель по спорту в Яндексе тоже был инструктором в гонке героев, он договорился. А потом, на гонке, познакомился с девочкой QA-факультета, рассказал ей про мечту о курсе, его начала включили в середину обучения, а позднее у него получилось сделать курс, и он быстро нашел команду для этого за счет накопленных контактов. И таких историй у Эрика много.
Дальше были рекомендации. Они, в общем простые и достаточно известные.
Люди часто охотно разговаривают о том, что они делают. Это кажется, что они не хотят. Просто они не обо всем.
Где и как разговаривать? Везде.
* Профильные конференции
* Пейте кофе, ходите на обед с новыми людьми. В Яндексе есть рандомный кофе
* Тимбилдинги и неформальные встречи. Если не хватает - свои: настолки, пати, спорт...
* Открытые и доброжелательные
* Проявляйте заинтересованность, не отвлекайтесь на встрече
* Делитесь историями
* Обменяйтесь контактами
* Не забывайте напоминать о себе
* Будьте отзывчивыми
* Не будьте навязчивыми
* Если плохое настроение - перенесите
Страхи. Ему и сейчас страшно. Но он пытался изменить, потому что хотел. Как готовиться?
* Начать здороваться с коллегами. И на улице тоже. Это точка входа.
* Больше говорить на встречах. Презентовал проекты и так далее.
* Активно использовать текстовую коммуникацию. Писать проще, чем говорить.
Систематизируйте контакты. Набрать целый телефон - не проблема, проблема вспомнить кто. Оставляйте артефакты, делайте селфи или кружки с новым знакомым и отправляйте в телегу. Больше общайтесь, со временем нетворкинг станет частью жизни.
Чек лист быстрого старта
* Какую задачу нетворкинг поможет решить сейчас
* Определиться со списком задач и подготовить вопросы
* Подумать, кто может помочь, где и как начать коммуникацию.
Хотел стать сейлом. Всех сейлов спрашивал - а как ты стал сейлом? Многие рассказывали. И руководители просили подчиненных.
Это иллюстрирует сквозная история - о том, как Эрик хотел сделать курсы, и даже учился этому - но у него не получалось. Но однажды он попал в Гонку героев. Потому что до этого хотел попасть в спорт, было 100500 попыток, но не складывалось. А тут увидел в инстаграмме фотку с гонки героев, где был его друг, узнал, решил в очередной раз попробовать, друг дал телефон - и этот вариант зашел. И он не просто участвовал, а стал инструктором, сдал необходимое, хотя для этого пришлось с другими инструкторами договориться о переносе даты экзамена, он не мог в назначенную. А потом был тренинг по публичным выступлениям, где он человек рассказывал про Яндекс-практикум, и он подумал, что это клевое место, пошел туда работать. Но с курсом не складывалось, надо было пройти обучение, а там не было вакансий. Однако, Гонка героев осталась, он собрал команду от Яндекса, только формально они опоздали, но поскольку руководитель по спорту в Яндексе тоже был инструктором в гонке героев, он договорился. А потом, на гонке, познакомился с девочкой QA-факультета, рассказал ей про мечту о курсе, его начала включили в середину обучения, а позднее у него получилось сделать курс, и он быстро нашел команду для этого за счет накопленных контактов. И таких историй у Эрика много.
Дальше были рекомендации. Они, в общем простые и достаточно известные.
Люди часто охотно разговаривают о том, что они делают. Это кажется, что они не хотят. Просто они не обо всем.
Где и как разговаривать? Везде.
* Профильные конференции
* Пейте кофе, ходите на обед с новыми людьми. В Яндексе есть рандомный кофе
* Тимбилдинги и неформальные встречи. Если не хватает - свои: настолки, пати, спорт...
* Открытые и доброжелательные
* Проявляйте заинтересованность, не отвлекайтесь на встрече
* Делитесь историями
* Обменяйтесь контактами
* Не забывайте напоминать о себе
* Будьте отзывчивыми
* Не будьте навязчивыми
* Если плохое настроение - перенесите
Страхи. Ему и сейчас страшно. Но он пытался изменить, потому что хотел. Как готовиться?
* Начать здороваться с коллегами. И на улице тоже. Это точка входа.
* Больше говорить на встречах. Презентовал проекты и так далее.
* Активно использовать текстовую коммуникацию. Писать проще, чем говорить.
Систематизируйте контакты. Набрать целый телефон - не проблема, проблема вспомнить кто. Оставляйте артефакты, делайте селфи или кружки с новым знакомым и отправляйте в телегу. Больше общайтесь, со временем нетворкинг станет частью жизни.
Чек лист быстрого старта
* Какую задачу нетворкинг поможет решить сейчас
* Определиться со списком задач и подготовить вопросы
* Подумать, кто может помочь, где и как начать коммуникацию.
Хотел стать сейлом. Всех сейлов спрашивал - а как ты стал сейлом? Многие рассказывали. И руководители просили подчиненных.
В целом Эрик весь доклад объяснял, что никакая магия тут не нужна. Нужна активность и простые приемы, и не надо бояться, и получится куча пользы. Но реально магия - требуется. Тут как со спортом: многие знают, что это нужно и несложно, и часть из них даже покупает абонементы в фитнес, а реально занимаются - гораздо меньше. Так что не в страхе дело, или не в нем одном. Возможно, лично для Эрика главным было преодолеть страх, а дальше мастерство как-то росло и сейчас это на уровне неосознанной компетентности, которую он не может раскрыть, потому что она неосознанна.
Но по-любому такой доклад заставляет заглянуть в себя и спросить - почему ты сам этого не делаешь. Я лично не то, чтобы совсем не нетворкаюсь, но вот так, как делает Эрик - точно не делаю. Хотя знаю, что это нужно. Наверное, дело в том, что я не люблю строить орг.системы из людей, не вижу именно в этом свою реализацию. А нетворкинг - он про это, ты просто копишь материал, чтобы использовать в нужный момент. Впрочем, это вполне может быть лишь рассуждение "от ответа", а не реальная причина. Но это не страшно, ведь обязанности - нет.
Но по-любому такой доклад заставляет заглянуть в себя и спросить - почему ты сам этого не делаешь. Я лично не то, чтобы совсем не нетворкаюсь, но вот так, как делает Эрик - точно не делаю. Хотя знаю, что это нужно. Наверное, дело в том, что я не люблю строить орг.системы из людей, не вижу именно в этом свою реализацию. А нетворкинг - он про это, ты просто копишь материал, чтобы использовать в нужный момент. Впрочем, это вполне может быть лишь рассуждение "от ответа", а не реальная причина. Но это не страшно, ведь обязанности - нет.
👍6❤3🔥2
#Teamlead Александр Зиза. Три субкультуры в IT-компаниях. Очень хороший рассказ о происходящих сейчас принципиальных изменениях в культуре компаний. Это был второй слот, но конспект я публикую только вечером, потому что было желание обдумать и дополнить то, что говорил Александр, а это требует времени. Свои дополнения я отделяю от конспекта, пишу от первого лица. Но надо понимать, что всякий конспект - интерпретация, а не точная передача смысла.
Итак, сейчас, летом 2024 происходит много изменений. И в результате в каждой компании есть винегрет разного. В докладе Александр расчерчивает карту, чтобы в этом разном разбираться.
До субкультур надо поговорить про культуру ИТ-компаний в целом. И это - важно, хотя многие руководители говорят "вы мне практик дайте, не надо про культуру". Я замечу, что такие руководители просто не понимают, насколько у людей различается мышление, и насколько это мышление влияет на жизнь и поведение людей. При этом про себя они бычно это понимают, а вот других считают не такими, как они сами (иначе им бы не были нужны практики управления) - основная ошибка атрибуции. Впрочем, может, они и про себя понимают, и им нужны практики не только для других, но и для себя.
Какие есть проекции, планы, viewpoint для описания культуры? Их много, они перечислены, и большинство остались за рамками доклада, но по ним есть источники.
1. Ограничивающие убеждения, система-1 и система-2 Канемана в мышлении.
2. Культура цивилизаций. Тойнби: цивилизация это культура. Запад: мышление и коммуникации между равным позициями, Россия - эмоциональное присоединение. Интернет, платформы, чаты - про организацию коммуникаций. Выстраивание отношений - это не про коммуникации, отношения бывают деловые и не деловые - разные.
3. Культура как культура быта, артефакты. Они впитаны.
4. Организационная культура - инструменты спиральной динамики.
5. Индустрия в цифровом торнадо (digidal tornado). Каждая индустрия в разных ситуациях.
6. Организационные субкультуры. DevOps, продуктовый подход.
Каждый viewpoint дает фрагментированное представление, надо собирать целое.
Безработица 2.7%, для нормального рынка труда нужно 6-7%. В ИТ не хватает 45% специалистов. У части ИТ-шников есть стратегия: каждый год менять место. Я тут хочу сказать, что это - не особенность России. Питер Друкер, рассматривая вызовы менеджмента 21 века, более 20 лет назад писал о том, что переход от физического труда к умственному приведет к переходу от профицитного рынка труда к дефицитному, при котором специалист будет сам выбирать место работы, при этом деньги будут не основным фактором. Собственно, это и происходит, в ИТ - раньше, в других отраслях - позже, но оно неизбежно.
Культура: цели, ценности, стереотипы, практики. Два способа движения по жизненному циклу: upstream и downstream.
Развитие технологий. Из жизни: как делаем самолеты. Три фазы.
* Модель, ответ на вопрос взлетит или нет.
* Два экземпляра прототипа. Один летает, второй в запасе
* Дальше завод штампует.
Жизненный цикл - детальнее. Важно, что есть Разные места, разные типы деятельности: наука, производство, бизнес.
Здравоохранение - продуктовый подход.
* Обычные задачи - поликлиника, регламенты, ОМС/ДМС
* Сложная проблема - научный клинический центр. И там - другой подход внутри.
* И еще - наука, экспериментальные методы.
Интегрировать это - все очень сложно.
Стивен Деннинг. Эпоха Agile. Складывается мозаичная система и надо интегрировать.
Инженер: назначение бизнеса - обеспечивать развитие науки и технологии. На Highload очень много докладов, и за каждой - стоит тот, кто так думает. Из основного процесса развития технологии появляются боковички развития технологии: о - можно упаковать и продать. И это может быть сырая непонятная шняга. Или Технология как продукт - он рисковая, может быть голубой океан, а может - пусто. А может быть технология как коммерческий продукт. Но инженер об упаковке не думает. Он видел историю со светодиодами времен СССР: у нас развивали науку и рассказывали, а японцы упаковывали.
Итак, сейчас, летом 2024 происходит много изменений. И в результате в каждой компании есть винегрет разного. В докладе Александр расчерчивает карту, чтобы в этом разном разбираться.
До субкультур надо поговорить про культуру ИТ-компаний в целом. И это - важно, хотя многие руководители говорят "вы мне практик дайте, не надо про культуру". Я замечу, что такие руководители просто не понимают, насколько у людей различается мышление, и насколько это мышление влияет на жизнь и поведение людей. При этом про себя они бычно это понимают, а вот других считают не такими, как они сами (иначе им бы не были нужны практики управления) - основная ошибка атрибуции. Впрочем, может, они и про себя понимают, и им нужны практики не только для других, но и для себя.
Какие есть проекции, планы, viewpoint для описания культуры? Их много, они перечислены, и большинство остались за рамками доклада, но по ним есть источники.
1. Ограничивающие убеждения, система-1 и система-2 Канемана в мышлении.
2. Культура цивилизаций. Тойнби: цивилизация это культура. Запад: мышление и коммуникации между равным позициями, Россия - эмоциональное присоединение. Интернет, платформы, чаты - про организацию коммуникаций. Выстраивание отношений - это не про коммуникации, отношения бывают деловые и не деловые - разные.
3. Культура как культура быта, артефакты. Они впитаны.
4. Организационная культура - инструменты спиральной динамики.
5. Индустрия в цифровом торнадо (digidal tornado). Каждая индустрия в разных ситуациях.
6. Организационные субкультуры. DevOps, продуктовый подход.
Каждый viewpoint дает фрагментированное представление, надо собирать целое.
Безработица 2.7%, для нормального рынка труда нужно 6-7%. В ИТ не хватает 45% специалистов. У части ИТ-шников есть стратегия: каждый год менять место. Я тут хочу сказать, что это - не особенность России. Питер Друкер, рассматривая вызовы менеджмента 21 века, более 20 лет назад писал о том, что переход от физического труда к умственному приведет к переходу от профицитного рынка труда к дефицитному, при котором специалист будет сам выбирать место работы, при этом деньги будут не основным фактором. Собственно, это и происходит, в ИТ - раньше, в других отраслях - позже, но оно неизбежно.
Культура: цели, ценности, стереотипы, практики. Два способа движения по жизненному циклу: upstream и downstream.
Развитие технологий. Из жизни: как делаем самолеты. Три фазы.
* Модель, ответ на вопрос взлетит или нет.
* Два экземпляра прототипа. Один летает, второй в запасе
* Дальше завод штампует.
Жизненный цикл - детальнее. Важно, что есть Разные места, разные типы деятельности: наука, производство, бизнес.
Здравоохранение - продуктовый подход.
* Обычные задачи - поликлиника, регламенты, ОМС/ДМС
* Сложная проблема - научный клинический центр. И там - другой подход внутри.
* И еще - наука, экспериментальные методы.
Интегрировать это - все очень сложно.
Стивен Деннинг. Эпоха Agile. Складывается мозаичная система и надо интегрировать.
Инженер: назначение бизнеса - обеспечивать развитие науки и технологии. На Highload очень много докладов, и за каждой - стоит тот, кто так думает. Из основного процесса развития технологии появляются боковички развития технологии: о - можно упаковать и продать. И это может быть сырая непонятная шняга. Или Технология как продукт - он рисковая, может быть голубой океан, а может - пусто. А может быть технология как коммерческий продукт. Но инженер об упаковке не думает. Он видел историю со светодиодами времен СССР: у нас развивали науку и рассказывали, а японцы упаковывали.
👍1
У бизнеса - противоположный взгляд. Ему не интересны технологии. Задача - делать продукты, которые продаются. Но встречаются проблемы: то, что делаем - вдруг не продается. Первая идея - выяснить почему не выполнили план. Следующая стадия: поищем другие средства, лучше готовые. Если их не получается найти, можно поставить цель на создание средств. Но в голове у бизнеса - нет способа про это подумать. Это же нельзя запланировать, нет гарантий и непонятны бюджеты.
Итого, классификация:
* Средства понятны и доступны - задачи
* Средства неясны, но их можно найти - Цель
* Средства никогда не созданы - Проблема.
Отмечу, что это близко к классификации Дэвида Майстера на три типа проектов: Мозги, Седина и Процедуры.
И есть вопрос владения результатом. Бизнес поставил задачу: инженер, сделай эту метрику не 10, а 5. Инженер думает, придумал, на коленках в выходные - сделал технологию, которая снимает проблему. Вопрос - кому принадлежат права на это средство? Менеджер "сделал у меня", инженер "в воскресенье на кухне". Эта бизнес-проблема, она не решенная. И пока выигрывают инженеры, которые уносят технологии - если не была явно поставлена цель.
Карта фаз развития технологии
* Проектирование: технологии, рынок, орг.управление
* Разработка и тестирование
* Производство и эксплуатация
Каждая фаза - своя субкультура, принципиально отличающаяся от других.
* Заказная разработка, культура операционной эффективности: инженеру ставят задачи. Фокус - орг.управления + производств и эксплуатация. За последние 2 года в России взорвалась - есть большой госзаказ. Как правило, коммерческие средства с гарантией результата. Создаются орг.формы и партнерства с заказчиком и так далее. Главный вызов - сформировать слой среднего управления, умеющий вести орг.проектирование
* Продуктовая компания: разработка и тестирование, fail fast, гибкая технология управления
* Инновационно-технологическая компания, инженерная культура. Разработка новых технологий и средств, которые обеспечат новизну. Главный вызов - связь технолога и бизнеса, это сложно, потому что говорят про разное.
* Культура операционной эффективности - план-факт, все через процессы и kpi, приходят за стабильностью.
* Продуктовая культура - fail fast fail cheap. Ключ - нетворкинг и сообщества. Потребление, а не деньги. Главное, чтобы заработало. Приходят за востребованностью.
* Инженерная культура. Придумать, чтоб показать работоспособность, дальше не важно. Любопытство. Бизнес - обеспечивающая структура для исследований.
Александр говорит, что в компании объединяются только попарно: продукты + операционная эффективность или инженерная культура + продукты. Но я хочу сказать, что изменения текущего момента состоят в том, что надо рассматривать целостную деятельность из всех трех фаз, пусть не в одной компании, а в кооперации. Это раньше, когда развитие технологий было медленным, можно было рассматривать отдельно. У меня есть есть статья https://mtsepkov.org/De3-ground, где я формулирую такую схему деятельности ценностно.
И Александр в заключении сказал, что для целостного представления необходимо коммуницировать, несмотря на разницу культур. Коммуникация есть преодоление отвращения к точки зрения собеседника, это Александр сослался на Бориса Марковича Островского, одного из учеников Щедровицкого-старшего, от которого я тоже много почерпнул. Чтобы вести такую коммуникацию, надо говорить про дело, оставляя все остальное - за рамками.
И вот такому подходу к коммуникации в России - всего 30 лет, до этого было эмоциональное присоединение. Впрочем, я считаю, что с этим надо детально разбираться: что было у нас и как это изменялось со временем, что было на западе и как оно изменялось там, когда там возникла коммуникация равных позиций и кого считали равными. Потому что есть известный эффект, когда победившая в борьбе сторона ретроспективно переписывает историю, объявляя себя продолжателем традиции...
Итого, классификация:
* Средства понятны и доступны - задачи
* Средства неясны, но их можно найти - Цель
* Средства никогда не созданы - Проблема.
Отмечу, что это близко к классификации Дэвида Майстера на три типа проектов: Мозги, Седина и Процедуры.
И есть вопрос владения результатом. Бизнес поставил задачу: инженер, сделай эту метрику не 10, а 5. Инженер думает, придумал, на коленках в выходные - сделал технологию, которая снимает проблему. Вопрос - кому принадлежат права на это средство? Менеджер "сделал у меня", инженер "в воскресенье на кухне". Эта бизнес-проблема, она не решенная. И пока выигрывают инженеры, которые уносят технологии - если не была явно поставлена цель.
Карта фаз развития технологии
* Проектирование: технологии, рынок, орг.управление
* Разработка и тестирование
* Производство и эксплуатация
Каждая фаза - своя субкультура, принципиально отличающаяся от других.
* Заказная разработка, культура операционной эффективности: инженеру ставят задачи. Фокус - орг.управления + производств и эксплуатация. За последние 2 года в России взорвалась - есть большой госзаказ. Как правило, коммерческие средства с гарантией результата. Создаются орг.формы и партнерства с заказчиком и так далее. Главный вызов - сформировать слой среднего управления, умеющий вести орг.проектирование
* Продуктовая компания: разработка и тестирование, fail fast, гибкая технология управления
* Инновационно-технологическая компания, инженерная культура. Разработка новых технологий и средств, которые обеспечат новизну. Главный вызов - связь технолога и бизнеса, это сложно, потому что говорят про разное.
* Культура операционной эффективности - план-факт, все через процессы и kpi, приходят за стабильностью.
* Продуктовая культура - fail fast fail cheap. Ключ - нетворкинг и сообщества. Потребление, а не деньги. Главное, чтобы заработало. Приходят за востребованностью.
* Инженерная культура. Придумать, чтоб показать работоспособность, дальше не важно. Любопытство. Бизнес - обеспечивающая структура для исследований.
Александр говорит, что в компании объединяются только попарно: продукты + операционная эффективность или инженерная культура + продукты. Но я хочу сказать, что изменения текущего момента состоят в том, что надо рассматривать целостную деятельность из всех трех фаз, пусть не в одной компании, а в кооперации. Это раньше, когда развитие технологий было медленным, можно было рассматривать отдельно. У меня есть есть статья https://mtsepkov.org/De3-ground, где я формулирую такую схему деятельности ценностно.
И Александр в заключении сказал, что для целостного представления необходимо коммуницировать, несмотря на разницу культур. Коммуникация есть преодоление отвращения к точки зрения собеседника, это Александр сослался на Бориса Марковича Островского, одного из учеников Щедровицкого-старшего, от которого я тоже много почерпнул. Чтобы вести такую коммуникацию, надо говорить про дело, оставляя все остальное - за рамками.
И вот такому подходу к коммуникации в России - всего 30 лет, до этого было эмоциональное присоединение. Впрочем, я считаю, что с этим надо детально разбираться: что было у нас и как это изменялось со временем, что было на западе и как оно изменялось там, когда там возникла коммуникация равных позиций и кого считали равными. Потому что есть известный эффект, когда победившая в борьбе сторона ретроспективно переписывает историю, объявляя себя продолжателем традиции...
👍2
Книги по различию Запада и России:
* Лотман. Беседы о русской культуре
* Бердяев. Истоки и смысл русского коммунизма.
* Александр Зиновьев. Русская трагедия
* Аузан Культурные коды экономики
* Эрик Мейер. Карта культурных различий
А начать можно с лекций Аузана, которые гуглятся по словам "Аузан Арзамас".
Книги про современную западную культуру.
* The beginers guide to OKR
* Никаких правил - про Netflix
* Ким Скотт. Радикальная прямота
* Стивен Деннинг. Эпоха Agile.
* Лотман. Беседы о русской культуре
* Бердяев. Истоки и смысл русского коммунизма.
* Александр Зиновьев. Русская трагедия
* Аузан Культурные коды экономики
* Эрик Мейер. Карта культурных различий
А начать можно с лекций Аузана, которые гуглятся по словам "Аузан Арзамас".
Книги про современную западную культуру.
* The beginers guide to OKR
* Никаких правил - про Netflix
* Ким Скотт. Радикальная прямота
* Стивен Деннинг. Эпоха Agile.
👍6
#Teamlead Юлия Лукина. Как окунуться в новую предметную область и не утонуть. Юлия сменила много предметок: телеком (управление железом, портал для сотрудников), DWH+BI, Порталы госуслуг, Атомные станции, e-com (озон). Погружение в новую область кому-то тяжело, кто-то обжигаешься, кому-то больно. И она рассказывала свои техники погружения, чтобы не было страхов. Приемы - простые, превратились в чек-лист. Это про предметную область, смену стека она полагает отдельной, хотя лично я не очень вижу разницы на уровне чек-листа. Дальше по пунктам.
1. Глоссарий. В новой сфере он свой, и там куча сокращений, сленга. Который ясен тем, кто работает внутри. Глоссарий часто собран в головах. И тогда надо сделать самому. И удобно сделать общедоступным. И не надо накапливать, заносить быстро, каждый день. При этом полезно не только понимать термины, но и самому начинать употреблять.
2. Волна непонятной информации. Визуализировать и собирать по крупицам. Как собирать паззл или вести расследование. Картинку сразу увидеть хочется, но ты не увидишь. Только вот в паззле есть целевой образ, а у нас - нет. Нужно место, и тоже надо обновлять регулярно, пару раз в неделю. И видеть прогресс. Стикеры в миро как процесс или сущности и связи или что-то еще. Схема процессов, но это - на любителя.
3. Множество новых контактов. В новом отделе 10-15 человек в принципе запомнишь через 2 недели. Но есть большие проекты, где в чате 1000 человек. Матрица взаимодействия, Миро или что-то еще. Кто за что отвечает.
Где брать на все это время? Реально достаточно 15 минут в день, как и с контактами. И надо каждый день. С визуализацией пореже, но тоже не накапливать.
4. Обязательно задавайте вопросы. Да, даже глупые, и если кажется, что это элементарно.
Исnория - термин Mesh. Все употребяют, а она не знает. Но не спрашивает, спрашивает у коллег, а те - не знают. И полтора часа потерянного времени, потому что спросить надо было того, кто сказал. При чем выяснилось, что это - сленг, включить "как на проде"
Спрашивать надо своевременно. Рассказывают про червяка, во-время не спрашивают, надеется понять из контекста, не получается. Но когда полчаса говорили, сложно. А это на отгрузке зона, куда паллеты ставят. Или вопрос про имя через два дня знакомства.
Будь тем, кто переспросит и уточнит. Особенно на фразу "не буду останавливаться, всем понятно". Не понятно - спросите. Может потом, в личке. Но лучше - сразу, не только вам не понятно.
Не бойся спрашивать у экспертов. Если у эксперта спрашиваешь "расскажи мне все" - он не знает, что ответить, он три года может рассказывать. Стоит в вопросе раскручивать от задаче, а потом идти вширь, если уместно. Не "какие бывают топологии сети", а "если роутер вышел из строя - как узнать топологии, в которых он включен"
5. Фокус на здесь и сейчас - погружение через текущие задачи. Отбрасывать все лишнее. Беречь силы. Не распылять внимание. Иначе вас может накрыть, узнать все - не реально.
6. Практика. Наблюдай, как реально работает предметная область, если есть возможность. Если есть порталы, приложения, сайты - попробуй работать как пользователь. Посещая объекты, для которых работаешь - если есть возможность. В озоне она реально работала на складе, 12 часов. А на немецкой атомной станции, для которых работала, было без шансов. Погружение позволяет почувствовать требуемую эргономику.
7. Понять и простить. В первую очередь себя. Если мы принимаем решение о смене предметной области, надо заходить с пониманием на входе, что ты не понимаешь ничего. И не постигнешь все за неделю-две. Будут моменты, когда будет жестко накрывать, будете сидеть с кипящей головой. Обращаемся за помощью к себе самим, сила в нас. Тут помогает книга Е.Резанова "Это норм". А еще есть эксперты. Она ищет жертву среди экспертов, и просит рассказать, как он начинал, погружался. И в 90% случаев они отвечают "я и сейчас не понимаю", а другие "первые полгода я не понимал". И тут становится легче. И можно явно попросить помощи, не обязательно сделать задачу за вас, а направить на правильный путь.
1. Глоссарий. В новой сфере он свой, и там куча сокращений, сленга. Который ясен тем, кто работает внутри. Глоссарий часто собран в головах. И тогда надо сделать самому. И удобно сделать общедоступным. И не надо накапливать, заносить быстро, каждый день. При этом полезно не только понимать термины, но и самому начинать употреблять.
2. Волна непонятной информации. Визуализировать и собирать по крупицам. Как собирать паззл или вести расследование. Картинку сразу увидеть хочется, но ты не увидишь. Только вот в паззле есть целевой образ, а у нас - нет. Нужно место, и тоже надо обновлять регулярно, пару раз в неделю. И видеть прогресс. Стикеры в миро как процесс или сущности и связи или что-то еще. Схема процессов, но это - на любителя.
3. Множество новых контактов. В новом отделе 10-15 человек в принципе запомнишь через 2 недели. Но есть большие проекты, где в чате 1000 человек. Матрица взаимодействия, Миро или что-то еще. Кто за что отвечает.
Где брать на все это время? Реально достаточно 15 минут в день, как и с контактами. И надо каждый день. С визуализацией пореже, но тоже не накапливать.
4. Обязательно задавайте вопросы. Да, даже глупые, и если кажется, что это элементарно.
Исnория - термин Mesh. Все употребяют, а она не знает. Но не спрашивает, спрашивает у коллег, а те - не знают. И полтора часа потерянного времени, потому что спросить надо было того, кто сказал. При чем выяснилось, что это - сленг, включить "как на проде"
Спрашивать надо своевременно. Рассказывают про червяка, во-время не спрашивают, надеется понять из контекста, не получается. Но когда полчаса говорили, сложно. А это на отгрузке зона, куда паллеты ставят. Или вопрос про имя через два дня знакомства.
Будь тем, кто переспросит и уточнит. Особенно на фразу "не буду останавливаться, всем понятно". Не понятно - спросите. Может потом, в личке. Но лучше - сразу, не только вам не понятно.
Не бойся спрашивать у экспертов. Если у эксперта спрашиваешь "расскажи мне все" - он не знает, что ответить, он три года может рассказывать. Стоит в вопросе раскручивать от задаче, а потом идти вширь, если уместно. Не "какие бывают топологии сети", а "если роутер вышел из строя - как узнать топологии, в которых он включен"
5. Фокус на здесь и сейчас - погружение через текущие задачи. Отбрасывать все лишнее. Беречь силы. Не распылять внимание. Иначе вас может накрыть, узнать все - не реально.
6. Практика. Наблюдай, как реально работает предметная область, если есть возможность. Если есть порталы, приложения, сайты - попробуй работать как пользователь. Посещая объекты, для которых работаешь - если есть возможность. В озоне она реально работала на складе, 12 часов. А на немецкой атомной станции, для которых работала, было без шансов. Погружение позволяет почувствовать требуемую эргономику.
7. Понять и простить. В первую очередь себя. Если мы принимаем решение о смене предметной области, надо заходить с пониманием на входе, что ты не понимаешь ничего. И не постигнешь все за неделю-две. Будут моменты, когда будет жестко накрывать, будете сидеть с кипящей головой. Обращаемся за помощью к себе самим, сила в нас. Тут помогает книга Е.Резанова "Это норм". А еще есть эксперты. Она ищет жертву среди экспертов, и просит рассказать, как он начинал, погружался. И в 90% случаев они отвечают "я и сейчас не понимаю", а другие "первые полгода я не понимал". И тут становится легче. И можно явно попросить помощи, не обязательно сделать задачу за вас, а направить на правильный путь.
🔥5👍1
8. Погружение через обучение других. Когда начали понимать - помогайте, и при этом сам разбираешься.
И в конце это сведено в чек-лист: глоссарий, визуализация, карта взаимодействий, фокус на задачах, изучай в реальности что делаешь, не пытайся объять необъятное, изучай в реальности что делаешь, не пытайся объять необъятное, фокусируйся на своих сильных сторонах, обращайся к опыту и помощи экспертов, погружайся через помощь менее опытным.
И есть смысл многое вынести в онбординг в команду. Например, глоссарий.
На этом все. А я в заключении хочу резюмировать и дополнить, что по сути есть две стороны. Во-первых, надо выкинуть свои комплексы. Синдром самозванца, стеснительность некомпетентности и так далее. И доклад был во многом об этом. А во-вторых, надо прокачивать концептуальное мышление. Не собирать картинку из кусочков, как делают сенсорики, а создавать концепции, как делают интуиты (сенсорик-интуит - это одна из дихотомий MBTI). Практически это второй пункт, визуализация, просто интуиты быстро выходят на схему верхнего уровня, применяя что-то известное из своей модели мира, которую потом доопределяют, они не работают с чистого листа.
И в конце это сведено в чек-лист: глоссарий, визуализация, карта взаимодействий, фокус на задачах, изучай в реальности что делаешь, не пытайся объять необъятное, изучай в реальности что делаешь, не пытайся объять необъятное, фокусируйся на своих сильных сторонах, обращайся к опыту и помощи экспертов, погружайся через помощь менее опытным.
И есть смысл многое вынести в онбординг в команду. Например, глоссарий.
На этом все. А я в заключении хочу резюмировать и дополнить, что по сути есть две стороны. Во-первых, надо выкинуть свои комплексы. Синдром самозванца, стеснительность некомпетентности и так далее. И доклад был во многом об этом. А во-вторых, надо прокачивать концептуальное мышление. Не собирать картинку из кусочков, как делают сенсорики, а создавать концепции, как делают интуиты (сенсорик-интуит - это одна из дихотомий MBTI). Практически это второй пункт, визуализация, просто интуиты быстро выходят на схему верхнего уровня, применяя что-то известное из своей модели мира, которую потом доопределяют, они не работают с чистого листа.
🔥3
#Teamlead Антон Огородников из Mаgnit Tech. Инженерная культура. Что это и почему она важна? У бизнеса компании есть продуктовая культура со своими принципами. Они были на слайде, но я не успел записать. А у ИТ - инженерная культура, обеспечивающая поддержку бизнеса. Принципы формулировали на уровне руководства ИТ.
1. Здоровье сервиса - нулевой приоритет. Если у тебя проблемы с продом - ты чинишь. А не сидишь на встрече с руководителем. Ты покрываешь сервис метриками, чтобы следить за его здоровьем, не катишь без метрик, не переключаешься на другие фичи.
2. Инцидент - незапланированная инвестиция в стабильность сервиса. Инцидент - нормально. Но если он произошел - сделай вклад в стабильность. Упала база, сервис - не рестарт, а постмортен и разбор причин с их устранением. Ответственность - на команде, доносим до команды целиком.
3. Platform by design. Если есть задача, то (а) поищи этот велосипед в других командах и (б) при разработке подумай об использовании в других командах, особенно если в ходе поиска обнаружил интерес. Сделали, когда в появилось два сервиса авторизации. Обобщение - в ответ на интерес другой команды.
4. Принцип горящего дома. Ситуации - разные, отпуска, болезни. Если есть проблема, то как ее изолировать от других. Ну и потушить. Поднимаем то, что упало, и потом - ищем причины. Кейс - большая кастомизация поверх базового механизма сломалась при обновлении. Сначала - делаем костыль, чтобы поднялось. Потом - хорошее решение и профилактика будущего.
5. Tech follows Business. ИТ поддерживают. Были прецеденты, когда расходились. В частности: мы как ИТ должны уметь давать оценки. Как можем по текущему описанию. Некоторые инженеры - не про бизнес, они про фреймворки и технологии, и таких не берем.
6. We build it - we run it. Команда отвечает за фичу целиком, без функционального деления, от начала и до конца. Люди приходят из разных компаний, у многих сопровождение отдельно, а у них - нет. Команда отвечает за фичи на проде, за данные, которые через себя пропускает, и метрики - чтобы следить за этим.
7. Explicit is Better Then Implicit. Явное лучше неявного. Все, что делаешь должно быть визуализировано и оставлять артефакты. Камеры на встречах, это упрощает коммуникацию и упрощает встречи, невербальная коммуникация. Например Feature release freeze в конце года: мы не катим фичи.
8. Принцип швейцарского ножа. В нем много элементов. Инженер-программист должен стремитсья к тому, чтобы быть универсальным, хотя основное время пользуется 1-2 инструментами. Можно заменить того, кто заболел, не ждете его.
Выводы
* Культура может являться фундаментом
* Нет плохой и хорошей культуры, есть текущая ситуация
* Заниматься формированием культуры можно начинать, когда становится много
* Культура не высечена в камне, она живет.
Распространение. Сначала продать принципы руководству. А затем закидывать в инженеров точечно. А потом как достигается принятие нужной массой экспертов - распространяют на всех.
1. Здоровье сервиса - нулевой приоритет. Если у тебя проблемы с продом - ты чинишь. А не сидишь на встрече с руководителем. Ты покрываешь сервис метриками, чтобы следить за его здоровьем, не катишь без метрик, не переключаешься на другие фичи.
2. Инцидент - незапланированная инвестиция в стабильность сервиса. Инцидент - нормально. Но если он произошел - сделай вклад в стабильность. Упала база, сервис - не рестарт, а постмортен и разбор причин с их устранением. Ответственность - на команде, доносим до команды целиком.
3. Platform by design. Если есть задача, то (а) поищи этот велосипед в других командах и (б) при разработке подумай об использовании в других командах, особенно если в ходе поиска обнаружил интерес. Сделали, когда в появилось два сервиса авторизации. Обобщение - в ответ на интерес другой команды.
4. Принцип горящего дома. Ситуации - разные, отпуска, болезни. Если есть проблема, то как ее изолировать от других. Ну и потушить. Поднимаем то, что упало, и потом - ищем причины. Кейс - большая кастомизация поверх базового механизма сломалась при обновлении. Сначала - делаем костыль, чтобы поднялось. Потом - хорошее решение и профилактика будущего.
5. Tech follows Business. ИТ поддерживают. Были прецеденты, когда расходились. В частности: мы как ИТ должны уметь давать оценки. Как можем по текущему описанию. Некоторые инженеры - не про бизнес, они про фреймворки и технологии, и таких не берем.
6. We build it - we run it. Команда отвечает за фичу целиком, без функционального деления, от начала и до конца. Люди приходят из разных компаний, у многих сопровождение отдельно, а у них - нет. Команда отвечает за фичи на проде, за данные, которые через себя пропускает, и метрики - чтобы следить за этим.
7. Explicit is Better Then Implicit. Явное лучше неявного. Все, что делаешь должно быть визуализировано и оставлять артефакты. Камеры на встречах, это упрощает коммуникацию и упрощает встречи, невербальная коммуникация. Например Feature release freeze в конце года: мы не катим фичи.
8. Принцип швейцарского ножа. В нем много элементов. Инженер-программист должен стремитсья к тому, чтобы быть универсальным, хотя основное время пользуется 1-2 инструментами. Можно заменить того, кто заболел, не ждете его.
Выводы
* Культура может являться фундаментом
* Нет плохой и хорошей культуры, есть текущая ситуация
* Заниматься формированием культуры можно начинать, когда становится много
* Культура не высечена в камне, она живет.
Распространение. Сначала продать принципы руководству. А затем закидывать в инженеров точечно. А потом как достигается принятие нужной массой экспертов - распространяют на всех.
👍5🔥2
#Teamlead Ольга Муттер из СберМаркет. Прозрачная структура проектов в компании от стратегии до исполнителя. Структуру выстраивали на 100+ команд в 3-уровневой иерархии команда-юнит-домен. Каждая команда живет своей жизнью, у нее свой проект в Jira, разный flow, разные типы задач и виды оценок. У бизнеса проблема - предсказуемость, понять, когда будет сделана фича. А еще им интересно оценить эффективность системы в целом и работать над повышением. Они решали эту задачу 2 года. Четыре компоненты: единая точка входа, ключевые метрики по эффективности, процесс работы с метриками и культура. Есть ее статья "Как подружить проектное управление с продуктовым подходом". Дальше - по пунктам.
1. Единая точка входа. Свой мир Jira в команде оставили, но два года назад сделали единый проект, с обобщенным flow, в котором надо вести все эпики. И смогли посмотреть на работу всей компании однородно. Дальше надо было всех заставить там работать. Это - отдельный доклад. Был пилот на нескольких командах, потом директива. И это была первая итерация.
Вторая итерация - новый тип работ - инициатива. Инициатива - это направление бизнеса, нацеленное на изменение бизнес-метрик компании. К ним должны быть привязаны все эпики, и это дает связь эпиков со стратегией. И можно было увидеть, куда тратим время и ресурсы. Появилось единообразие полей, отчеты и метрики.
С апреля 2024 следующая итерация - перенести в Jira discovery. Тип работы Идея, и тоже привязан к стратегии через инициативы. И бизнес-требования, замена Excel с бэклогом. Получается трассировка: Стратегия - Инициативы - Идеи, Эпики и бизнес-требования. Решилась проблема приоритизации, потому что инициативы имеют приоритет.
Этот путь требовал много работы: воркшопы обучения, шаблоны structure представления информации, дерево продуктовых меток, плагины wip-лимитов, доски под все нужды, дашборды визуализации работ, документация, сбор обратной связи, чат поддержки.
2. Метрики. Что есть эффективность для ИТ и как выражается? Проблема бизнеса: не понимаем, когда команда разработки это сделает. Постоянные переносы.
1. lead time - сроки поставки ценности
2. точность поставки - попадание в сроки
3. объем поставки - эффективность использую ресурсы
4. Эффективность поставки - чтобы не было делаю за час в течении недели
Урок: сначала накопите статистику lead time, а потом ставьте целевые значения. Они поставили сразу, и потом долго с этим мучились - команды заметали сложности под ковер и так далее.
Метрики показали, какой этап сколько занимает и какие разбросы. И позволил с этим точечно работать в разных командах. Работа часто останавливается по внешним причинам, и было добавлены блокеры разных видов, которая команда вешала, когда встречалась с этим, а дальше вели анализ и устраняли проблемы.
У всех готовы объяснения, почему lead time нельзя улучшить. Опыт показывает, что можно - но надо проводить анализ. Поэтому на входе нельзя идти в персонализацию, надо чтобы люди научились вести анализ метрик, разбираться в проблемах? это должно стать частью культуры работы.
Целевые метрики - менялись. Добавили: t2m, cycle time discovery, value, % отмен. value - что приносим ценность, а не просто делаем объем работ. Но мерить - сложно, пока тут проблемы. Системы можно взломать, они следят и работают через контр-метрики, это - постоянный процесс.
3. Процесс. Есть поддержка от вице-президента по технологиям. Точки контроля на уровне компании - в OKR появились процессные метрики. KPI тоже пробовали, там грабли. B Performance review. Для метрик - int-autometion-bot с уведомлениями - предсказание, что не попадешь в сроки, изменение метрики и так далее.
Анализ цепочки поставки - оценка каждого этапа поставки. Кластеризация проблем - по фазам. Проблема-влияние-ответственный-решение. После анализа: Проактивные действия - здесь и сейчас, и системные улучшения, которые делают итерациями.
1. Единая точка входа. Свой мир Jira в команде оставили, но два года назад сделали единый проект, с обобщенным flow, в котором надо вести все эпики. И смогли посмотреть на работу всей компании однородно. Дальше надо было всех заставить там работать. Это - отдельный доклад. Был пилот на нескольких командах, потом директива. И это была первая итерация.
Вторая итерация - новый тип работ - инициатива. Инициатива - это направление бизнеса, нацеленное на изменение бизнес-метрик компании. К ним должны быть привязаны все эпики, и это дает связь эпиков со стратегией. И можно было увидеть, куда тратим время и ресурсы. Появилось единообразие полей, отчеты и метрики.
С апреля 2024 следующая итерация - перенести в Jira discovery. Тип работы Идея, и тоже привязан к стратегии через инициативы. И бизнес-требования, замена Excel с бэклогом. Получается трассировка: Стратегия - Инициативы - Идеи, Эпики и бизнес-требования. Решилась проблема приоритизации, потому что инициативы имеют приоритет.
Этот путь требовал много работы: воркшопы обучения, шаблоны structure представления информации, дерево продуктовых меток, плагины wip-лимитов, доски под все нужды, дашборды визуализации работ, документация, сбор обратной связи, чат поддержки.
2. Метрики. Что есть эффективность для ИТ и как выражается? Проблема бизнеса: не понимаем, когда команда разработки это сделает. Постоянные переносы.
1. lead time - сроки поставки ценности
2. точность поставки - попадание в сроки
3. объем поставки - эффективность использую ресурсы
4. Эффективность поставки - чтобы не было делаю за час в течении недели
Урок: сначала накопите статистику lead time, а потом ставьте целевые значения. Они поставили сразу, и потом долго с этим мучились - команды заметали сложности под ковер и так далее.
Метрики показали, какой этап сколько занимает и какие разбросы. И позволил с этим точечно работать в разных командах. Работа часто останавливается по внешним причинам, и было добавлены блокеры разных видов, которая команда вешала, когда встречалась с этим, а дальше вели анализ и устраняли проблемы.
У всех готовы объяснения, почему lead time нельзя улучшить. Опыт показывает, что можно - но надо проводить анализ. Поэтому на входе нельзя идти в персонализацию, надо чтобы люди научились вести анализ метрик, разбираться в проблемах? это должно стать частью культуры работы.
Целевые метрики - менялись. Добавили: t2m, cycle time discovery, value, % отмен. value - что приносим ценность, а не просто делаем объем работ. Но мерить - сложно, пока тут проблемы. Системы можно взломать, они следят и работают через контр-метрики, это - постоянный процесс.
3. Процесс. Есть поддержка от вице-президента по технологиям. Точки контроля на уровне компании - в OKR появились процессные метрики. KPI тоже пробовали, там грабли. B Performance review. Для метрик - int-autometion-bot с уведомлениями - предсказание, что не попадешь в сроки, изменение метрики и так далее.
Анализ цепочки поставки - оценка каждого этапа поставки. Кластеризация проблем - по фазам. Проблема-влияние-ответственный-решение. После анализа: Проактивные действия - здесь и сейчас, и системные улучшения, которые делают итерациями.
❤1
4. Культура. Она не строится за месяц или за квартал. Она в том, что все понимают, что нужна задача верхнего уровня именно в общем проекте. Так устроено. Все задачи подвязаны. И бизнес появился именно поэтому вместо Excel. Работа на всех уровнях VP, EM/CPO, Unit lead, team lead. Распространение с обратной связью.
Как починили проблему? Тимлид - мини-CTO, он понимает, как он на уровне всей компании влияет на то, что компания делает. А бизнес может по каждой команде посмотреть скорость работы, попадание в обещания и построить прогноз.
В заключении я хочу отметить, что 10 с небольшим лет назад я слушал доклад про то, как в Касперском ставли единообразие процессов обработки задач и отметить разнообразие подхода. Там главным была общая система и одинаковый workflow для всех типов задач, без отдельного пространства для команд, и меряли единые характеристики, а все особые случаи согласовывал комитет по изменениям уровня компании, и их на всю компанию была пара случаев. А вот речь о трассировке задач до уровня стратегии - не шла. А в этом случае задачей было обеспечить единообразное представление только на верхнем уровне, и построить трассировку до стратегии, которую обвесить метриками. С моей точки зрения, это характеризует изменения, произошедшие за это время в культуре отрасли в целом.
Как починили проблему? Тимлид - мини-CTO, он понимает, как он на уровне всей компании влияет на то, что компания делает. А бизнес может по каждой команде посмотреть скорость работы, попадание в обещания и построить прогноз.
В заключении я хочу отметить, что 10 с небольшим лет назад я слушал доклад про то, как в Касперском ставли единообразие процессов обработки задач и отметить разнообразие подхода. Там главным была общая система и одинаковый workflow для всех типов задач, без отдельного пространства для команд, и меряли единые характеристики, а все особые случаи согласовывал комитет по изменениям уровня компании, и их на всю компанию была пара случаев. А вот речь о трассировке задач до уровня стратегии - не шла. А в этом случае задачей было обеспечить единообразное представление только на верхнем уровне, и построить трассировку до стратегии, которую обвесить метриками. С моей точки зрения, это характеризует изменения, произошедшие за это время в культуре отрасли в целом.
👍5🔥2
#Teamlead Игорь Курочкин. Как стать 10x экспертом. Основная идея доклада: экспертность сейчас определяется не накопленными в мозге знаниями и опытом, а мощностью личной базы данных, вынесенной из головы во внешнюю систему хранения знаний, которая дает возможность быстро решать задачи. И доклад - призыв осознать это и вести собственную базу, дополненный описанием процесса, которым для этого пользуется сам Игорь.
Контекст. Игорь работал с высоконагруженными системами, и несколько лет назад ушел в консалтинг по этой теме вместе с партнером. Проблема - нехватка знаний, потому что есть большое разнообразие технологий и все время появляются новые, техрадар за 15 лет накопил 1600+ технологий. И большая нехватка времени в операционной работе, чтобы это освоить. Идет большой поток информации, при этом в нем много шума и мало сигналов, а у предметной области - высокая сложность. Поэтому поиск в тот момент, когда задача уже получена - слабо эффективен. Решение - вести личную базу знаний, в которой накапливать и структурировать информацию заранее. Сейчас у него накоплено 15к заметок и 50к связей, и это - персональная база. У партнера - собственная, иначе организованная, чуть меньшего масштаба - 10к заметок, и когда они решают вопрос, то идет взаимное ревью или совместное решение, при котором каждый использует свою базу.
Как он это делает? Первое - надо организовать входящий поток ограниченной мощности, который ты успеваешь перерабатывать. Он подписан на профессиональные соцсети в linkedin и github и ряд профессиональных блогов по теме. А также почтовые рассылки - они все еще живы, и среди платных есть качественные, надо отбирать. Вопрос доверия к автору. Есть платные относительно качественные. Получается лента под себя, которую разбираешь пару раз в неделю. Далее, поиск. Помимо личной базы знаний, выполняешь поиск в почте, где собраны рассылки, и настраиваешь Google CSE, ограничивая список URL, где ищем. У него в индексе 884 блога - инженерные техблоги разных компаний. И прикрутили валидацию и проверку источников. А при разборе рассылок - еще анализируют кто, где и что публикует и добавляют в базу источников.
Второе - систематизация. Быстро переработать большой материал, когда уже пришел запрос - тяжело, надо заранее. И еще вести мысли и заметки, чтобы не повторять. Этапы структурирования:
* Данные - набор фактов.
* Информация - раскрашивание фактов по категориям.
* Знания - граф связей между фактами.
* Озарение (insight) - это связь двух точек.
* А мудрость (wisdom) - видение путей в графе.
У него примерно так: источников данных 10к+, информация 1к, знания 100 узлов, заметки-инсайты 1к, мудрость 10к заметок и *3 связей. За 3 года 15к заметок, 50к связей, 555к слов, 8к картинок, 800 контактов, 800 компаний, 530 конференций и других событий, 465 книг.
Инструменты: obsidian, roam research, logseq, Zettlr. Подходы: lyt/ideaverse, basp/para, Zettlercasten
Наполнение базы знаний - ежедневная работа. 10 заметок в день, примерно одна в час. Надо доверять своей базе знаний. Заметки визуализируются и анализируются, можно увидеть проблемы: заметки без связей и клубки сильно связанного. Нужен рефакторинг и структура. Визуальный граф на таком количестве не работает, а поиск на графах - работает.
Собственно, все. Следующие шаги, который он видит: дайджест или рассылка по списку своих блогов; поиск по tg, github, twitter; персональный дашборд; персональный помощник. НА правах идеи - я бы еще подумал о подключении к этому GPT: сейчас есть доступные технологии, при которым ты подключаешь к GPT собственный массив информации так, что он первично формирует ответ с учетом ее, в чем-то по сути это получается аналог поиска по заданному набору URL, но GPT знает про синонимы и связи понятий, что расширяет контекст.
Контекст. Игорь работал с высоконагруженными системами, и несколько лет назад ушел в консалтинг по этой теме вместе с партнером. Проблема - нехватка знаний, потому что есть большое разнообразие технологий и все время появляются новые, техрадар за 15 лет накопил 1600+ технологий. И большая нехватка времени в операционной работе, чтобы это освоить. Идет большой поток информации, при этом в нем много шума и мало сигналов, а у предметной области - высокая сложность. Поэтому поиск в тот момент, когда задача уже получена - слабо эффективен. Решение - вести личную базу знаний, в которой накапливать и структурировать информацию заранее. Сейчас у него накоплено 15к заметок и 50к связей, и это - персональная база. У партнера - собственная, иначе организованная, чуть меньшего масштаба - 10к заметок, и когда они решают вопрос, то идет взаимное ревью или совместное решение, при котором каждый использует свою базу.
Как он это делает? Первое - надо организовать входящий поток ограниченной мощности, который ты успеваешь перерабатывать. Он подписан на профессиональные соцсети в linkedin и github и ряд профессиональных блогов по теме. А также почтовые рассылки - они все еще живы, и среди платных есть качественные, надо отбирать. Вопрос доверия к автору. Есть платные относительно качественные. Получается лента под себя, которую разбираешь пару раз в неделю. Далее, поиск. Помимо личной базы знаний, выполняешь поиск в почте, где собраны рассылки, и настраиваешь Google CSE, ограничивая список URL, где ищем. У него в индексе 884 блога - инженерные техблоги разных компаний. И прикрутили валидацию и проверку источников. А при разборе рассылок - еще анализируют кто, где и что публикует и добавляют в базу источников.
Второе - систематизация. Быстро переработать большой материал, когда уже пришел запрос - тяжело, надо заранее. И еще вести мысли и заметки, чтобы не повторять. Этапы структурирования:
* Данные - набор фактов.
* Информация - раскрашивание фактов по категориям.
* Знания - граф связей между фактами.
* Озарение (insight) - это связь двух точек.
* А мудрость (wisdom) - видение путей в графе.
У него примерно так: источников данных 10к+, информация 1к, знания 100 узлов, заметки-инсайты 1к, мудрость 10к заметок и *3 связей. За 3 года 15к заметок, 50к связей, 555к слов, 8к картинок, 800 контактов, 800 компаний, 530 конференций и других событий, 465 книг.
Инструменты: obsidian, roam research, logseq, Zettlr. Подходы: lyt/ideaverse, basp/para, Zettlercasten
Наполнение базы знаний - ежедневная работа. 10 заметок в день, примерно одна в час. Надо доверять своей базе знаний. Заметки визуализируются и анализируются, можно увидеть проблемы: заметки без связей и клубки сильно связанного. Нужен рефакторинг и структура. Визуальный граф на таком количестве не работает, а поиск на графах - работает.
Собственно, все. Следующие шаги, который он видит: дайджест или рассылка по списку своих блогов; поиск по tg, github, twitter; персональный дашборд; персональный помощник. НА правах идеи - я бы еще подумал о подключении к этому GPT: сейчас есть доступные технологии, при которым ты подключаешь к GPT собственный массив информации так, что он первично формирует ответ с учетом ее, в чем-то по сути это получается аналог поиска по заданному набору URL, но GPT знает про синонимы и связи понятий, что расширяет контекст.
🔥10❤3
Меня лично этот доклад заставил задуматься - а почему я не пользуюсь подобной системой личных заметок? Наверное, потому, что нарабатывал навыки работы со знаниями, когда компьютеры для этого были не доступны. А потом освоил предыдущий стек, вики-системы, которые мы в компании применяем с 2005 года, в которых вел персональные заметки наряду с проектными. При этом персональных заметок всегда было не много, потому что освоение новых областей практически всегда шло в рамках проектной деятельности. А, заметив интересное помимо проекта - тоже старался поделиться в виде блога, который с 2010 стал еще и публичным, к 2014 превратившись в собственный сайт. И как-то сложилось, что освоение новых тем я тоже делаю в публичном пространстве. Так было с конспектом лекций Петра Щедровицкого по СРТ. Так произошло с моделями soft skill, которые я собрал в модель личности: были доклады, потом - статьи и книга, в процессе подготовки было много заметок, но они вошли в книгу, остались только наборы ссылок-источников, которые вполне помещаются в GoogleDocs. Впрочем, может быть это объяснение "от ответа", чтобы не делать. Но, в любом случае я активно использую поиск по своему сайту при работе над разными вопросами, и регулярно нахожу очень интересные материалы собственного авторства :)
🔥11