timsa.ru: заметки с тегом проектирование

Кеневин

Fri, 28 Feb 2025 13:20:05 +0500

Часто управленец пытается решать задачу неподходящим способом. Человек по фамилии Сноуден (не тот, другой) придумал модель Cynefin, по-нашему — Кеневин. Валлийское слово, примерно переводится как «среда обитания».

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

Очевидный домен

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

Осложненный домен

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

Сложный домен

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

Хаотичный домен

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

Беспорядочный домен

Это когда вообще непонятно, в каком ты домене. Команда тупит, клиенты недовольны, начальство что-то требует.
Определи, в каком ты домене, потом действуй.

Зачем нужна модель Кеневин? Чтобы определить тип задачи и выбрать верный способ управления. Бессмысленно решать задачи, требующие проверки гипотез с помощью «наилучших отраслевых практик». Не сработает, даже если позвать сто экспертов.

Давайте теперь разберемся, как применяют модель. Вот менеджер Марианна. Ее команда готовится выкатить обновление приложения для курьеров. За пару дней до релиза кто-то замечает: карты загружаются медленнее обычного.

Вроде проблема простая: не хватает мощности серверов. Это легко проверить, надо посмотреть загрузку. Ой, да! Сервер не справляется. Решение очевидно: добавляют ресурсы, карты снова работают быстро.

Через час проблема возвращается. Значит, дело не только в мощности. Осложненная ситуация: требуется анализ. Марианна подключает разрабов, те смотрят логи. А-а-а, изменился алгоритм загрузки карт, сервер перегружен ненужными запросами. Решение найдено, разрабы правят код.

Все хорошо? Не-а. Теперь у части пользователей приложение вообще не запускается. Разрабы не понимают, в чем дело, аналитики тоже. Это уже сложная ситуация, причин может быть много. Нужно выдвигать гипотезы, тестировать. У Марианны глаза цвета спелой клубники. Тут команда выясняет, что проблема в несовпадении версий чего-то там. Разрабатывают патч, все в порядке.

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

Важно не только решать проблемы, но и понимать, с чем именно ты имеешь дело. Простому — инструкция. Осложненному — эксперт. Сложному — эксперимент. Хаосу — быстрые действия.

Ликбез: менеджер проектов vs менеджер продуктов

Wed, 29 Jul 2020 21:32:56 +0500

Люди из непродуктовых компаний часто спрашивают, чем отличаются менеджер проектов (Project Manager) и менеджер продуктов (Product Manager).

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

Несмотря на то, что в ресторане блюда приготовлены правильно, вам сейчас они не подошли. Для вас это неправильные блюда. А мороженое — подходящее, правильное.

Разница между менеджером продукта и менеджером проекта примерно такая же, как между понятиями «сделать правильный продукт» и «сделать продукт правильно».

Когда создается что-то новое — компьютерная игра, гоночный автомобиль, онлайн-сервис выдачи кредитов, смартфон, — то открывается проект. Собирается проектная команда и назначается менеджер проекта. Он будет отвечать за то, что в результате проекта получится продукт с согласованными заранее свойствами.
Машина сможет разгоняться до 1500 км/ч, смартфон будет со встроенным счетчиком Гейгера, а для получения кредита не понадобится никаких документов вообще. Менеджер проекта будет отвечать за то, что этот продукт появится на рынке 1 января 2030 года, а перерасход бюджета не будет значительным. )

Менеджер проекта отвечает за то, что продукт будет создан правильно.

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

Зато есть претензии к тому, кто отвечал за востребованность продукта рынком — менеджеру продукта. Именно он должен управлять свойствами продукта, чтобы продукт был успешен, а пользователи довольны.

Менеджер продукта отвечает за то, что будет создан правильный продукт.

Но менеджер продукта не отвечает за то, что продукт сделан правильно. Если вдруг у машины на презентации арабскому шейху (кто такую еще купит-то?) отвалится бампер, то все претензии к менеджеру проекта. Если к смартфону вместо счетчика Гейгера прикрутили фен, то вопросы к менеджеру проекта.

Еще раз: менеджер проекта делает продукт правильно, а менеджер продукта делает правильный продукт.

Важно: менеджер проекта и менеджер продукта — это роли. Часто их совмещает один человек. Это разумно для больших продуктов, которые делает несколько продуктовых команд, как в Авито. Или для маленьких продуктов с одной командой — как в стартапах, для экономии.

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

Кто из них круче? Менеджер продукта много знает про юнит-экономику, метрики, умеет принимать сложные решения на основе данных и тюнинговать продукт, получая выдающиеся коммерческие результаты.)
Менеджер проекта умеет работать с людьми, ставить цели и достигать их в заданные сроки и бюджет, с нужным качеством.
Оба круты.

Как ставить задачи правильно

Tue, 21 Jul 2020 13:40:11 +0500

Хотите, чтобы что-то было сделано, — ставьте задачу. Если исполнитель вашу задачу не делает, то либо он негодяй, либо у вас нет полномочий ставить задачу этому человеку, либо вы ставите ее неправильно.

Первое правило хорошо поставленной задачи — начните ее с глагола, а не с существительного.
Плохо (отглагольное существительное):
Тестирование модуля Х.
Разработка функции Y.
Хорошо (глагол):
Протестировать модуль Х.
Разработать функцию Y.

Больше конкретики — конкретную задачу легче делать и проще контролировать. Задача создается, чтобы ответить на вопрос «что сделать?», а не «что делать?».
Плохо (неконкретно):
Обдумать риски в проекте А.
Наметить дальнейшие шаги в проекте В.
Хорошо (конкретно):
Составить реестр рисков в проекте А.
Создать план проекта В.

Каждой задаче нужен срок исполнения. Нет дедлайна — нет стимула делать. Дедлайны дисциплинируют и помогают планировать.
Плохо (нет срока):
Создать документ D.
Хорошо (есть срок):
Создать документ D к 31.12.2020.

Должны быть требования к результату. Нужно описать, что именно должно получиться, и что вообще считается выполненной задачей. Критерии выполнения — это важно.

Описание должно включать все нужные для работы материалы. Исполнитель не должен бегать по разным источникам, по крупицам собирая информацию о задаче. Все, что ему нужно для выполнения, должно быть описано и приложено к задаче. То же касается любых ресурсов, которые нужны для выполнения задачи. Хочешь хорошего результата — создай человеку условия для работы.