Аналитика ≠ проектирование

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

Сначала я думал, что это шутка, но похоже это всерьез. Теперь начинаю догадываться, что пока я три года писал книгу о важности проектирования, все стало не лучше, а наоборот хуже! Если раньше клиента нужно было убеждать, что без проектирования невозможно ни оценить проект, ни тем более разработать, то теперь все уверены, что проектирование они делают, но клиенты продолжают получать некачественные продукты, а агентства нести убытки из-за ошибок в оценке (даже если они работают по t&m 😅).

Давайте разберемся что не так с аналитиком, который якобы закрывает вопрос проектирования. Представим, что вы строитель мостов. И к вам приходит клиент, которому нужно соединить два берега реки. Вы внимательно выясняете какие задачи должен решать этот мост, сколько машин в сутки пропускать и какую нагрузку должен выдерживать. А потом сразу передаете эти требования вашей строительной бригаде. Стооооп, что?! Как бригаде? Сначала вы должны мост по этим требованиям спроектировать! Выбрать его архитектуру, рассчитать параметры его деталей и сформировать технологию сборки. И только после этого переходить к строительству.

Что происходит в ИТ. Приходит клиент, компания, которой нужен какой-то цифровой сервис (кстати откуда такая уверенность?), агентство отправляет к нему бизнес-аналитика, который выясняет как у него устроены процессы, какие cjm у его пользователей и какие use cases должны быть. Да! Еще проводятся исследования, чтобы точно быть уверенными, что это не пустые гипотезы. Все! Проектирование готово!

А, нет, сори, еще призодят ux-еры, которые с умным видом прорабатывают пользовательский опыт. Все уверены, что проектирование готово и пора в разработку. Ничего не пропустили?! Да вроде нет, разработчики сами со всем разберутся. Как говорил мой знакомый диз «да все они могут!» на очередные возмущения разрабов, что сделать задачу по макетам невозможно.

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

И тут наступает самое сложное. Такой роли на современном ит-рынке можно сказать что и нет. Да, конечно, есть технические писатели, системные аналитики и архитекторы, ux-проектировщики, но это все моно-специализации. Была надежда на продактов, как тех, кто сможет интегрировать в одном видении разные аспекты продукта, но те теперь заняты метриками продукта и пытаются стать внутренними предпринимателями (это продюсеры если что). Короче есть все, но проектировщика продукта нет. И нет подходящей технологии его работы, потому что если нет позиции, то нет и методов работы.

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

Все это как нетрудно было догадаться была реклама моей красной книги «Метод параноика» и второй — черной, в которой эта технология будет описана в деталях. Ну а заодно моих услуг по построению и настройке проектных офисов и команд.

На этом пока все 🙏😇

Кстати о книге! Она уже добралась и до Норвегии! Ну а вы всегда можете ее заказать на Озоне, почитать и послушать на Литресе, а для самых экономных есть открытый вариант на сайте «Метода параноика» (там же доступны все перечисленные варианты и даже больше!) https://paranoidmethod.org/books

Пока еще не начались съемки нового сезона подкаста, хочу вспомнить вместе с вами первый подход к снаряду 6 летней давности. Тогда подкаст назывался MITYAKIN ON AIR, всего вышло 8 эпизодов. Я просто купил видеокамеру и записал интервью с несколькими интересными для меня людьми.

Одним из самых интересных и не потерявших актуальности считаю эпизод со Славой Карпенко и Кириллом Мурзиным из Unreal Mojo: https://youtu.be/dpkY6P8XbTw

Иерархия артефактов и проектные тиски

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

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

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

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

В своей книге я пишу о пяти уровнях проекта, как раз представляющих иерархию артефактов: (1) бизнес, (2) функциональный, (3) интерфейсный, (4) технический и (5) организационный уровни. Первый уровень задает цели создания продукта, второй, третий и четвертый — как собственно должен быть устроен продукт, чтобы достигнуть с его помощью целей бизнеса, а пятый уровень определяет наши ресурсы, которые должны потребоваться для выполнения проекта.

Из этого кстати складывается одна интересная концепция, под названием тиски. Решения об устройстве продукта (2), (3) и (4) зажаты в пространстве между тем, что мы хотим (1) и тем, что мы можем (5). Управление проектом как раз и заключается в том, чтобы зажать этот проектный бутерброд и найти подходящие решения на каждом из его уровней.

Подробнее об этом в 7 и 8 главах книги «Метод параноика»

Друзья, спасибо всем, кто забустил! ❤️

https://t.iss.one/theparanoidmethod?boost

Что бывает, когда вместо полноценного проектирования продукта вы говорите «разработчики разберутся сами!»

Как выглядит диалог между дизайнером и верстальщиком на итоговой защите

Всем добрый вечер! На этом веселые истории закончились, а я хочу сообщить, что вернулся в Москву и все, кто планировал попасть на мой подкаст (новый сезон) или обсудить проектные задачи (в консультационном и трекерском формате), можно уже писать и договариваться @vadim_mityakin

Я ищу съемочную площадку под новый сезон подкаста и поэтому самое время сказать спасибо за гостеприимство моему другу Максу Повтареву (@xxxwanderer), на площадке которого были отсняты первые 17 эпизодов.

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

Но еще более удивительно то, где эта площадка находится — в самом центре Москвы с балкончиком на Остоженку. Кто видел бекстейдж подкаста, тот знает. Собственно тут вся интрига — как Макс это помещение нашел и купил. Про то, как искать что-то похоже, у Макса есть специальный канал, велкам: https://t.iss.one/valuestate

Лекции по продуктовой разработке

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

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

Содержание базируется на продюсерской модели и инструментах контроля неопределенности из моей книги «Метод параноика». Мой интерес состоит в том, что я собираю и обкатываю материал для своей новой книги ("черной") по практическим приемам продуктовой разработки, которая будет состоять из четырех разделов:
— Бизнес
— Продукт
— Команда
— Процесс

У меня закончилась активная фаза подготовки красной книги к переизданию и появляется возможность чаще проводить что-то подобное. Поэтому если у вас и вашей команды назрела потребность провести сессию с методологом, пишите, обсудим @vadim_mityakin

Просто удивительно, как в большинстве проектных команд нет знания о том, кто такие проектировщики. Я встречаюсь и работаю с большим количеством компаний и команд, и практически в 100% на вопрос о том, есть ли у них роль проектировщика в команде, звучит ответ — "да, у нас есть аналитик". Иногда спрашивают, идет ли речь о UX и технической архитектуре, но практически никогда о роли участника, который бы комплексно представлял себе устройство продукта. Если вам это тоже кажется странным, то можно глянуть раздел "Роль проектировщика" в 6-й главе книги: https://mityakin.com/paranoid-method-book-06#role

Я работаю с ребятами из Work Solutions и возможно это то, что вы хотели обсудить!

Уже третий год мы являемся кураторами IT-кластера ARDA, в котором собрали почти 200 директоров из IT-компаний.

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

В этот четверг проведем встречу на тему "Найм СЕО в ИТ-аутсорсинговую компанию: опыт Аспирити".

Ратибор Секиров, ex-CEO компании Aspirity, расскажет о том:

- как его нанимали 4 года назад в компанию с выручкой 30М;
- как разделяли роли, проводили онбординг, формировали процесс взаимодействия с основателями компании;
- как развивались отношения с основателями, включая получение доли и другие интересные особенности;
- как нанимали нового СЕО Владимира Меха в компанию с выручкой 100М.

Когда: 2 ноября в 14:00 по МСК
Где: онлайн-встреча в Zoom

👉Регистрация

Хочу узнать ваше отношение к подписке на email-рассылку. Читаете кого-то в таком формате из профессионалов?

Когда кто-то (специалист или компания) говорит, что он номер один (на рынке, в профессии), для меня это признак номер один, что работать с ними не стоит.

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

Онлайн-вариант книги, а вместе с ней и весь сайт переехал на новый домен. Заодно появился раздел консалтинга, которым я занимаюсь последние пару лет после выхода книги: https://mityakin.com/consulting

Немного про неопределенность https://youtu.be/efiYL0vthrE?si=icDMOXQHjj7VRL1P