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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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