Что такое продукт и проект в IT

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

“Да кто ты такой?” - спросите вы. А я отвечу. Я - Дима Балашов, руководитель проектно-аналитического направления компании Decart IT-production, занимающейся заказной разработкой проектов и продуктов и предоставляющей аутстафф-услуги крупным российским компаниям. За более чем 6 лет работы я управлял разработкой проектов для России и ЕС, занимался продуктовой и бизнес-аналитикой. Все это позволило получить богатый опыт как в работе над продуктами вместе с их основателями, так и в организации работы команды разработки.

Кому же будет полезен блог?

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

На этом вводная часть закончена, переходим к делу!

В этом блоге я часто буду использовать термины продукт и проект, а также позиции продакта(product manager) и проджекта(project manager). Давайте разберемся, что это, в чем отличия и как они влияют на принятие решений.

Согласно американскому институту проектного менеджмента:

Продукт - произведенный артефакт, который можно выразить количественно и который может являться как конечным объектом, так и компонентом.

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

Возьмем приложение Камера на iPhone. Это продукт, который является неотъемлемой частью другого продукта - самого iPhone. При этом разработка конкретной версии этого приложения является проектом, имеющим даты начала и завершения. Будет выходить следующая iOS, и в рамках продукта iPhone инициируют новый проект по улучшению приложения Камера.

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

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

Например, вы обратились за разработкой ИТ-проекта, который оценили в 2 млн, а у вас есть 1,8 млн. В таком случае вы можете:

• Уменьшить объем работ. Это можно сделать двумя способами или их комбинацией: убрать часть функционала или упростить имеющийся.
• Увеличить срок выполнения работ. На это могут идти не все компании-разработчики и не во всех ситуациях, но я в своей практике пару раз так делал. Для заказчика это плюс, если не горят сроки. Фактически чистая экономия денег. Для исполнителя это снижение рисков и возможность для уменьшения себестоимости разработки, в результате чего его чистая прибыль может не измениться или даже увеличиться.
• Осознанно “ухудшить” качество. Качество бывает внутреннее и внешнее. Внешнее - видимое пользователем. Проявляется в виде багов, непродуманных пользовательских сценариев и тд. Внутреннее - недосягаемое для пользователей. Проявляется в виде проблем в дальнейшем развитии сервиса(или даже невозможностью это сделать), увеличении стоимости разработки.

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

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

У коммерческого продукта совсем другой фокус. Я разделяю его на создание ценности для клиента и управление финансами.

Создание ценности включает в себя:

• Простоту получения продукта. Сколько времени и денег придется потратить, чтобы начать использовать продукт. Сюда можно отнести время на заключение договора или стоимость интеграции.
• Простоту использования продукта. Нужны ли специальные навыки для работы с продуктом, какого риски при работе с ним. И до Тинькофф Инвестиций можно было торговать акциями, но именно этот продукт вывел сферу на новый уровень простоты.
• Профит от использования продукта. Насколько эффективно продукт закрывает потребности пользователей. Например, после внедрения продукта А производительность сотрудников отдела В в среднем выросла в Х раз.
• Стоимость продукта. Сколько стоит и насколько он интересен пользователю с учетом этом стоимости.
• Ценность бренда. Уверен, вы легко назовете с десяток брендов, у которых стоимость бренда в общей стоимости их товаров или услуг значительно выше себестоимости.

Управление финансами содержит:

• Модель получения прибыли. Подписка, разовая оплата, оплата за количество и тд
• Стоимость продукта. Из чего она формируется, что на нее влияет
• Распределение доходов и расходов.

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

Последним различием, о котором хочу поговорить, является подход к работе. Разработка продуктов основана на тестировании гипотез. Что это значит? Вы не можете быть заранее уверены, что внедрение фичи А со стоимостью реализации В увеличит показатель Y в Х раз. Это просто невозможно на данном этапе развития людей и технологий. Поэтому команда строит ряд гипотез, оценивает их по нескольким параметрам и выбирает для реализации те, у которых оптимальное соотношение пользы и стоимости. Далее эта гипотеза тестируется. Если гипотеза подтвердилась или по крайней мере показала положительную динамику, она внедряется на постоянной основе. Если нет, анализируются причины, и делаются выводы.

Подробно расскажу обо всех этих процессах в следующих статьях.

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

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

P.S. Буду благодарен за конструктивную обратную связь в комментариях, вопросы и предложения🙏