Чему ИТ может научить бизнес. Пара замечаний о Product Development.

лиса и журавльВ компании, из которой я недавно уволился, я не все время работал Главным ИТ архитектором. Несколько лет я проработал менеджером по запуску новых продуктов (value added services). Правда, в определенный момент пришло осознание того, что мы делаем все не очень правильно. Собственно,  потому я и перешел в ИТ на позицию архитектора. Архитектор, особенно архитектор предприятия (Enterprise Architect) — это тот человек, который может исправить некоторые ошибки бизнеса (я оставлю за скобками вопрос, кто такой EA и почему в отечественных реалиях такая должность не встречается в бизнес-подразделениях). Я надеюсь, что в будущем компания успешно справится с болезнями роста и скорректирует процессы развития и управления продуктами, но во время моей работы этот процесс был таким, каким он был.  

Сейчас тема развития и управления продуктами довольно популярна. Существует множество материалов, описывающих соответствующие техники. Даже айтишники уже знают слова «позиционирование», «клиентский опыт», ну или, по крайней мере, встречали с такими вещами как value proposition canvas .

value-proposition-canvas-questions-600x450

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

Управление проектами вещь нужная, полезная и хорошо себя зарекомендовавшая. Особенно, если вы решаете задачу высадки человека на Луну или реализуете стратегическую оборонную инициативу (впрочем, вроде это не самый лучший пример). Однако, если вы занимаетесь развитием продуктов, эта техника уже не столь хорошо применима (см. Gartner: Projects Today, «Change Operations» Tomorrow) . В частности, если каждое существенное изменение в продукте делать в виде проекта, то проектов становится невероятно много (на момент моего увольнения в портфеле их было более семидесяти, плюс еще шестьдесят в другом портфеле). Другая проблема проектной организации работ заключается в том, что зачастую каждый новый проект делается с «чистого листа». Т.е. отсутствует или недостаточно выражена преемственность и передача знаний. Такие вещи мы и вылавливали уже на уровне ИТ. Приходит, например, бизнес-заказчик запускать новую бонусную программу для клиентов. Но ИТ-архитекторы и аналитики люди опытные и сообразительные, а потому знают, что была старая бонусная программа. А три года назад была еще более старая бонусная программа. И пять лет назад была совсем старая бонусная программа. И все эти программы реализованы в определенных информационных системах, и по каждой из них есть операционная отчетность, которую можно изучить. Ну и, в крайнем случае, можно документ High Level Design найти для соответствующих проектов. Посмотреть, что думали архитекторы античной эпохи о реализации такого рода продуктов.

Как, на мой взгляд, должен был бы выглядеть такой процесс в идеале. Важно понимать, что product development, product management и product marketing вещи хоть и связанные друг с другом, но все же немного разные. Product management — это основной процесс, остальные два — вспомогательные. И управлять нужно не портфелем проектов, а портфелем продуктов. Пусть их будет десять, двадцать, пятьдесят, сколько угодно. Главное, чтоб у каждого из них был Product manager, которому и поручено определять, как он будет управлять развитием своего продукта. Нужны ли ему для этого проекты, развивающие функционал, или же изначально реализация продуктов должна обладать достаточной гибкостью, чтоб изменение функционала осуществлялось в рамках линейной деятельности. Product marketing не ограничивается определением цен и скидок на продукт. По сути, он должен диктовать требования по возможностям «перелицовки» продукта, обертывания его в новые упаковки. Это и есть тот самый pace layer подход.  Если процессы выстроены таким образом, то и product development становится намного более осмысленным, позволяет «захватить» требования будущих изменений. А от этого быстрых и кривых решений (workaround-ов) становится меньше.

Приведу один пример. Пришел как-то к нам заказчик и попросил сделать функцию понижения скорости мобильного интернета при исчерпании включенных в тарифный план бесплатных мегабайт. Потратил абонент месячный лимит, значит, надо либо платный пакет трафика подключить, либо ждать, пока месяц закончится. Мы, естественно, это сделали посредством внедренной незадолго до этого программной платформы Glassfish ESB (Open ESB). Теперь-то мы уже знаем, что через полгода тот же самый заказчик придет просить не ежемесячные, а ежедневные пакеты. А еще через пару лет придет уже другой заказчик и захочет, чтоб пакет с дополнительным трафиком подключался автоматически. А в промежутках между этими моментами времени будут приходить заказчики с проектами улучшения имеющейся услуги. У нас даже в названиях таких проектов специальный хэш-тэг имеется — #improvement. И долгое время будут отдельные линейки тарифов для смартфонов и USB-модемов. Разумеется, по каждой из них будет своя «линейка» проектов. Уж не помню, как обстояли дела с отчетностью по данным продуктам, но точно помню, что на уровне реализации мы довольно быстро запутались, кто, кому и за что снижает или повышает скорость мобильного интернета (это мы потом поумнели и сейчас не стали бы запускать ни одно решение, не оснастив его функционалом онлайн статистики).

Но вопрос, безусловно, не только в реализации. Продуктовый взгляд на вещи улучшает подход к оценке эффективности проектов. Представьте такую себе ситуацию. Приходит к вам менеджер проекта и говорит: «Я потрачу 20 рублей на свой проект, а зарабатывать буду по 100 рублей ежемесячно». Хороший бизнес-кейс? Безусловно. По крайней мере, пока вы не поймете, что запускаемый в этом проекте продукт каннибализирует, т.е. вытесняет с рынка другой продукт. А предыдущий продукт, между прочим, зарабатывал по 90 рублей в месяц без каких-либо дополнительных вложений. Такой кейс, безусловно, за пару месяцев тоже окупится. Если, конечно, клиент окончательно не запутается в вашей продуктовой линейке.

В общем, не смотря на то, что понятие архитектуры предприятия довольно невнятное, дискредитированное непутевыми консультантами, потребность в ней существует. То, как вы структурируете систему своих понятий, свяжете  между собой продукты, проекты и ресурсы, какие таксономии станете использовать для планирования и контроля операционной деятельности, очевидно, будет влиять на её результаты. Только заниматься этим вряд ли должно ИТ. А так — мы что? Мы ничего, примус починяем бесплатные советы тут раздаем.

Чему ИТ может научить бизнес. Пара замечаний о Product Development.: 4 комментария

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

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *