🚬 Расскажу немного про приоритизацию (курильщика).

Что нам говорят продуктовые курсы: есть много алгоритмов приотизации, берите любой из них, например, RICE или ICE, и ебаш… эээ, приотизируйте. Будет вам счастье. Да… но! Помимо очевидных проблем приоритизации, у нас все немного сложнее и душнее, потому что К - корпорация.

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

С большими проектами более-менее все ясно.

Это инициативы, которые требуют подключения X команд (где X>1) и серьезных затрат по ресурсам. Так как в разных отделах разные наборы метрик, то большие проекты сводятся и ранжируются, как правило, по одной из трех финансовых метрик: контребу (GMV), ореху (OPEX) или ябеде (EBITDA). Чаще всего, к первым двум, третью - что-то давно не видел.

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

Дальше идут маленькие проекты. Эта мелочь отличается от крупняка количеством необходимых для закрытия задачи человекочасов. Здесь приоритизация работает так, как хочется отделу: кто-то использует RICE, кто-то, наверное, Value/Effort, кто-то использует правило буравчика. Эффект от разных задач бывает сложно свести в одну систему координат, потому что сюда часто попадают чисто технические задачи. Например, они нужны другому отделу в рамках какого-то бизнес-проекта: в рамках всего проекта как будто эффект есть, но в рамках отдела - как будто нет. Поэтому иногда мы просто договариваемся, чтобы поднять задачу повыше.

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

Для того, чтобы процесс приоритизации был прозрачен, у нас есть специальные мероприятия: техкомы и продкомы, где демонстрируется очередь проектов, меняются приоритеты, озвучиваются сроки и тд. Туда мы зовем заказчиков от бизнеса и со всеми договариваемся.

Есть еще третий вид проектов - технологические инициативы, которые затрагивают весь Озон или большую его часть. Например, отказ от какого-нибудь legacy. Часто, это вообще не касается локального техдолга команды. Тут речь идет о налоге на быстрый рост. Почему это нужно? Потому что на масштабе какое-то древнее говно мамонта может привести к тому, что ляжет критически важный сервис. Упадет order flow, компания недополучит выручку. А это, к слову, довольно большое число даже за час простоя.

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

Как-то так. Лайк, если было полезно. Вопросы - в комментарии.