Щербинин думает про…

2023-03-20 16:16:42 Про законы Лармана

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

1. Организации устроены таким образом, чтобы избегать изменений структуры власти, статуса-кво между тремя уровнями управления: топами, менеджерами среднего звена и специалистами.

2. Любая инициатива по изменению будет сведена к переопределению существующей либо к вводу новой терминологии, по сути означающей то же самое, что и до изменений, но позволяющей поддерживать статус-кво.

3. Любая инициатива по изменению будет высмеяна как «пуристическая», «теоретическая», «излишне революционная» и «требующая приземления на реалии организации», что мешает началу работ по устранению существующих проблем и сохраняет статус-кво руководителей и специалистов.

4. Культура подчиняется структуре.

Из этих законов следует, что структурные изменения нужно делать только после вовлечения руководства в эти процессы. Иначе вряд ли что-то получится.

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

Ещё по теме: про менеджера менеджеров и плоскую структуру Открыть/Комментировать

2023-03-15 12:50:39 Про прогресс

Водителей заменяют self-driving cars, работа бухгалтеров автоматизируется, а код и тексты уже пишет GPT-модель. Историк Льюис Мамфорд считает, что создание таких «машин» помогает людям высвободить время для чего-то большего. Роботизация и автоматизация стали основными двигателями человеческой эволюции.

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

Да, прогресс упрощает жизнь. Разогреть еду в микроволновке или разобраться со смартфоном может даже ребёнок. Но у этого есть негативная черта: простой доступ к знаниям расслабляет. Технологии не требуют глубокого понимания различных дисциплин.

Современному человек придётся чаще менять работу. Ушло время, когда огромной ценностью были твои глубокие знания в одной области. Важным становится не изучение конкретной специальности, а понимание междисциплинарных идей.

Придётся ещё больше размышлять и не поддаваться простоте, которую диктует прогресс. Не бойтесь сложностей, развивайте мастерство и учитесь концентрировать внимание на чём-то большем, чем на одном «рилсе».

Что делать, чтобы учиться размышлять? Есть два главных способа:

1. Мышление через проговаривание. Это можно делать в группах по интересам, с коллегами и близкими. Чаще делитесь своими размышлениями.

2. Мышление письмом. Этим я занимаюсь прямо сейчас. А вы можете попрактиковаться со мной в комментариях.

Как вы думаете, какие навыки должен осваивать современный человек, чтобы оставаться на гребне волны прогресса? Открыть/Комментировать

2023-03-10 10:51:45 Про PPPI

В посте про ситуационное лидерство мы начали разбираться с тем, как делегировать задачи. В зависимости от опыта сотрудников и понимания задачи мы по-разному контролируем ход выполнения проектов. В этом мне помогает система PPPI.

Практически это выглядит так, что на 1v1 с сотрудником мы смотрим в его документ. Вот, что там написано:

P — прогресс. Какие задачи выполнил человек за прошедший период. Желательно измеримые.

P — план. Что сотрудник собирается сделать до следующей встречи. Максимум 3-5 ключевых проектов.

P — проблемы, с которыми сотрудник столкнулся, не смог преодолеть или потратил слишком много времени. Где ему нужна ваша помощь.

I — идеи человека по улучшению процессов.

Не стоит воспринимать этот документ как жёсткий комитмент. Я, например, никогда не проверяю, соответствует ли предыдущий план текущему прогрессу. Не используйте PPPI для надзора и контроля. Он просто помогает структурировать работу и выровнять ожидания. Открыть/Комментировать

2023-03-08 09:58:51 Поучаствовал в подкасте «IT-шниками не рождаются»

Вместе с Бесланом Курашовым записали подкаст на полтора часа для канала «karpov courses»!

Поговорили о разном, не только про IT:

— Моё детство, игры, институт, работа в школе.
— Про обучение программированию по книжкам и через реальный опыт.
— Как стать CTO
— Про работу в блокчейн-стартапе и индустрии в целом.
— Как я уходил из Mail в СберМаркет, а затем в «Практикум».
— Про рост маркетплейсов в ковид.

Кажется, получился ламповый информативный выпуск, смотрите на YouTube Открыть/Комментировать

2023-03-06 12:54:45 Про ситуационное лидерство

Часто начинающие руководители приходят с таким вопросом: «Вот есть человек, и одну задачу он делает круто и быстро, даже следить не надо. А как даю другую, так спустя два дня ничего не сделано и результата нет. Что это значит и как быть?»

На скрине картинка, которую я чаще всего пересылаю в таких ситуациях. Это инфографика про ситуационное лидерство, когда руководитель выбирает подход к управлению в зависимости от задачи и уровня сотрудника, а не по ситуации

Есть две основные модели. Слева модель Пола Хёрси про «готовность делать», она мне больше нравится. А справа модель Кена Бланшара. В каждой модели нужен разный подход в зависимости от квадрата, в котором вы с сотрудником находитесь. Но в целом модели похожи.

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

А если у сотрудника есть мотивация и точное понимание, как делать задачу, то это уровень «делегирование». От руководителя не требуется много поддержки и надзора.

Всё зависит от ситуации, поэтому нельзя использовать один подход всегда. Именно поэтому с одной задачей сотрудник справляется хорошо, а с другой плохо. Для каждой задачи от руководителя нужен индивидуальный подход, который основывается на конкретном сотруднике.

Ситуационное лидерство помогает управлять эффективностью, потому что руководитель участвует в постановке целей и приоритетов. Плюс легко быть гибким: лидер индивидуально подходит к каждой задаче и исполнителю. Открыть/Комментировать

2023-03-03 10:21:36 Как скрам-артефакты помогают продуктовым компаниям не проседать в качестве

Последние лет 10 я управляю разработкой. Но с годами понимаю, что некоторые идеи были ошибочными. Это подтолкнуло меня в 2022 году выступить на конфе «Тинькофф» с рассказом о своём текущем понимание скрама: как бывает до него, что бывает после и какие проблемы лежат на пути. В пример часто приводил наш опыт в «Практикуме».

Основные поинты:

— Функциональные команды выполняют только часть задач и часто не задумываются о влиянии на продукт.

— После перехода на продуктовые команды люди начинают думать о продукте: уменьшаются очереди, снижается T2M. Но появляются проблемы с техдолгом, устареванием технологий и горящими дедлайнами.

— Чтобы держать качество на высоте, мы стали внедрять различные инструменты: DoD, модель зрелости, гильдии, лайв-кодинг, инцидент-менеджмент, обучение продактов, открытые ретроспективы, грейды и инженерные практики.

Выступлению полгода, но актуальность сохранилась на 100%. Посмотрите полностью Открыть/Комментировать

2023-03-01 12:13:58 Про систему гильдий

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

При этом важно системно повышать уровень компетенций во всём продукте: фронтэнд, бэкэнд, контроль качества и прочее. Иначе развитие продукта и компетенции членов команды будут проседать.

Представьте, что разработчики разошлись по кросс-функциональным продуктовым командам. Кто теперь обновит Python и Django до новой версии? Кто добавит правила для линтеров? А кто предложит внедрить DDD?

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

Чтобы правильно запустить гильдию, нужно определить много вещей. На чём она будет концентрироваться, какие ключевые показатели её существования будем учитывать, по каким принципам она работает и т.д.

Подробно разобраться в этом вопросе поможет гильд-канвас. Нашёл подробный гайд на 60 страниц с подробной теорией и руководством по построению гильдии вплоть до вопросов для фасилитации.

ПДФка ниже ↓ Открыть/Комментировать

2023-02-27 13:12:53 Занимательная математика

Вчера увидел пост, что компании предложили мидла на аутстаф за ₽3000 в час. Автор умножил эти деньги на 8 (рабочие часы в день), а потом на 22 (рабочих дней в месяце). Уже не найду пост, но смысл был в том, что это дорого по сравнению с наймом в штат. Получилось ₽528 тысяч в месяц.

Это неверные цифры, давайте пересчитаем вместе.

В году 247 рабочих дней. Вычитаем 28 дней отпуска и делим на 12. Получаем 18,25 рабочих дней в месяц. А ещё есть больничные, поэтому округляем до 18. Умножаем ₽3000 на 8 рабочих часов и 18 дней. Получаем ₽432 тысячи в месяц.

Но это ещё ничего, давайте посчитаем по-взрослому. Учтём НДФЛ (13%) и отчисления в госфонды (30%), которые аутстаф-компания берёт на себя. Вместо ₽365 тысяч получаем ₽289 тысяч в месяц.

И это ещё мы не учли расходы на найм — два оклада в среднем. А ещё офис, оборудование и возможный вычет по НДС.

В лучшем случае мы получаем сотрудника на аутстафе по цене сотрудника в штат за ₽289 тысяч в месяц. Хорошая рыночная цена. Открыть/Комментировать

2023-02-24 11:23:24 Как избавиться от легаси в Django-приложении с помощью DDD

Мой коллега Паша Свиридов написал большую статью, как мы в practicum.com переписываем большой Django-проект.

Короткий план:

1. Переместите в отдельную папку весь код, связанный с первым идентифицированным ограниченным контекстом.

2. Объедините несколько связанных приложений в одно. Или сгруппируйте приложения внутри корневой папки модуля.

3. Удалите внешние ключи между моделями разных модулей.

4. Терпите и переписывайте старый код, потому что он должен соответствовать новой структуре.

5. PROFIT!!!

Прочитайте статью полностью. Будет особенно полезно, если у вас более 20 модулей, тесты выполняются более 20 минут, и вы часто сталкиваетесь с циклическим импортом.

Читать статью Открыть/Комментировать

2023-02-22 13:31:02 ​Про DoD: как всегда выдавать качественный продукт

В скраме за приоритизацию отвечает продакт оунер. Но не все знают, за что отвечает команда разработки. Нет, это не сроки и даже не бюджет. Это качество продукта.

Есть такая практика — Definition of Done. Это список из пунктов, которые означают готовность к релизу. Задача считается завершённой только когда все чекбоксы закрыты.

Иногда из-за спешки или забывчивости мы не обновляем документацию или не покрываем тестами сложный корнер кейс. Поэтому важно составить DoD вместе со всеми членами команды: разработчиками, тестировщиками, продактами и стейкхолдерами. Нужно договориться, почему каждый пункт важен и обязателен.

Да, нельзя за раз составить DoD и учесть всё необходимое. Это живой список, который подвержен циклам инспекции и адаптации. Часто на ретроспективе мы обновляем DoD и добавляем пункты, которые помогут не допустить ошибки прошедшего спринта в будущем.

Вот пример конкретного списка DoD для одного из проектов ↓ Открыть/Комментировать