Какой программный продукт разработать

Привет, Хабр! Сегодня мы начинаем публикацию серии практических материалов для продакт-менеджеров, основателей стартапов и всех остальных, кто хочет приобрести навыки менеджера по разработке программных продуктов. Этот и последующие посты былы подготовлен на основе лекций курса «Создание программного продукта и управление его развитием», который был организован с помощью компании Acronis.

Всех, кто планирует запускать свои продукты, стремится расширить свои компетенции или хочет подискутировать с нами — прошу под кат.

Оглавление курса

1. Роль менеджера по продукту и фреймворк < — Вы здесь
2. Сегментирование рынка и конкурентный анализ
3. Пользовательские персоны
4. Проверка гипотез
5. Позиционирование продукта
6. Дорожная карта продукта
7. Составление требований для разработки
8. Бизнес-модель и Бизнес-план
9. Финансовый план и ценообразование
10. Запуск ИТ-продукта и проведение маркетинговой кампании
11. Партнерские отношения, каналы дистрибьюции и продажи продукта
12. Этапы развития компании и продукта

Меня зовут Василий Рудоманов, и я отвечаю за развитие продуктов в компании Acronis. Я долгие годы занимался инжиниринговой или технической стороной создания продуктов и решений. Однако полученный технический опыт в итоге привел меня к специализации в области развития программных продуктов. За годы работы в этой сфере я убедился, что умение работать со своим продуктом, понимать, как идея превращается в готовый продукт, выбирать рыночные ниши, позиционировать его и планировать развитие может быть полезным и разработчикам, и инженерам, и основателям стартапов, и сотрудникам отделов продаж и многим другим специалистам в ИТ-компаниях, а не только менеджерам по продукту.

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

Основатель стартапа де-факто является главным продакт менеджером компании и поэтому полностью определяет ее развитие. Впоследствии эту функцию владельцы бизнеса передают продакт-менеджерам. Поэтому последние должны выполнять огромное количество задач, контролировать процесс разработки, анализировать потребности рынка, решать проблемы клиентов и многое-многое другое. Для этого нужно обладать целым спектром важных знаний и навыков, а также уметь работать со специализированными фреймворками. Но сегодня мы начнем именно с идеи… с того «единорога», который возникает в голове каждого человека, когда он решается подарить миру новый продукт.

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

Однако и это еще не все: помимо стратегии часто возникает срочная потребность «реализовать новый функционал за 2 недели под определенную сделку». Инженеры, разработчики и архитекторы предлагают использовать новые технологические стеки, базы данных, технологии и языки программирования, а служба поддержки рапортует о том, что в продукте возникают технические баги, и их нужно исправить.

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

Фактически, менеджер по продукту должен находить проблемы на рынке и предлагать для них решение. Но, как показывает исследование, в реальности продакт-менеджеры тратят на это меньше 20% времени. Остальное уходит на работу со всеми участниками процесса, включая инженеров, топ-менеджеров и, конечно, самих клиентов.

Дело в том, что подход «от идеи» не работает, чья бы это ни были идея — самого менеджера, директора или владельца компании. Рано или поздно приходится слушать рынок, потому что когда sales-менеджеры начинают продавать продукт, выясняется, что в нем чего-то не хватает, продукт продается не тем людям, не в том регионе, может быть, не в своей ценовой категории. После этого происходит переработка, или вообще выпуск новой версии продукта, хотя можно было сразу начать работу в нужном направлении. Именно поэтому роль менеджера по продукту очень важна для успешного выхода на рынок.

Многие разработчики уже знакомы с книгой Фреда Брукса «Мифический человеко-месяц». Очень рекомендую почитать ее, если вы этого еще не сделали. Фред Брукс участвовал в создании IBM 350. В свое время его команда провела большую работу по созданию программного обеспечения для мейнфреймов. В своей книге он очень хорошо описал, в чем заключается отличие программы от продукта или программной системы.

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

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

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

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

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

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

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

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

Работа с фреймворком очень важна для всех категорий сотрудников современной ИТ-компании.

Сегодня мы поговорили об общих подходах к продакт-менеджменту, которые будут полезны как непосредственно продактам, так и СEO стартапов, которые действительно должны выстрелить (по крайней мере, по мнению основателей). В следующем посте мы обсудим как определить, на какой сегмент рынка вы ориентируете свой продукт и как провести конкурентный анализ этой рыночной ниши. Если вам важна и полезна эта тема, не забудьте подписаться на наш блог.

→ Видео-запись всех лекций курса доступна на YouTube

Первая лекция:

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

Основной нашей специализацией в EDISON является разработка сложного заказного программного обеспечения на платформах Windows, Linux, MacOS и мобильных Android, iOS, Windows Phone. За время своей работы мы выполнили свыше нескольких сотен крупных проектов на самом высоком уровне качества разработки и обслуживания клиентов. К сожалению, большая часть самых интересных проектов надёжно скрыты за NDA. Но каким бы ни было разрабатываемое программное обеспечение: системное, прикладное, веб-приложение или приложение для мобильных, — общая схема разработки и ее принципы одинаковы.

В прошлой статье мы рассказали о наших принципах проектирования ПО, в этом посте перейдём непосредственно к процессу разработки в Центре разработки EDISON.

Этапы разработки программного обеспечения

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

Подробно про первый и второй этапы (подготовительный и проектирование программного обеспечения) можно перечитать в прошлой статье.

Перейдём к созиданию:

• Дизайн — вторая по важности составляющая продукта после технических характеристик, влияющая на эффективность и скорость взаимодействия пользователя с ним. Требования к дизайну определяются ТЗ — как правило, важны простота, интуитивность и минимальные затраты на совершения действия (достижение результата), а также красота и соответствие стилю компании и (или) продукта.
• Код — та часть работы, которая обычно ассоциируется с разработкой ПО как таковой. Важно, чтобы код был в достаточной мере оптимизированным, лаконичным и понятным. Назначаем на подобранные под специфику задания в ТЗ языки специализирующихся на их использовании программистов.
• Тестирование. Тестирование в EDISON проводится на каждом этапе разработки ПО, включает множество тестов по плану тестирования, кастомизируемому с учётом специфики проекта на этапе составления технического задания. Результаты тестирования документируются и доступны клиенту в режиме реального времени. Оплата за продукт производится только после прохождения всех видов тестов, в том числе клиентских.
• Документирование — процедура, фиксирующая план, процесс и результат разработки программного обеспечения. Включает в себя всю исходную информацию (ТЗ, макеты), планы работ, затрат, тестирования, список задач исполнителей в каждый момент времени, отчеты о работе и так далее. Документация необходима для быстрого и точного выявления ошибок, прозрачности совместной работы, как обязательная юридическая часть договора.

Схематично создание программного обеспечения выглядит так:

Принципы разработки программного обеспечения

Важный момент для компании, занимающейся разработкой ПО, — определиться с базовыми принципами работы. У каждого разработчика свой подход, свои ценности и приоритеты. Для компании EDISON такими принципами при разработке являются:

1. Ориентация на качество. Мы прилагаем все усилия, чтобы это было не избитым маркетинговым клише, а объективной реальностью. Бесперебойность работы и удовлетворенность конечным результатом обеспечивают:
   • следование ГОСТам, лучшим практикам и методологиям качественной разработки (RUP, Agile),
   • лучшие спецы, четкое разделение труда и хорошая мотивация срок+качество,
   • отлаженная и мощная система тестирования продуктов,
   • качественное и прозрачное планирование и выполнение задач, система управления разработкой и обязательность грамотного технического задания,
   • документирование процесса и результата,
   • гарантии на разработанные продукты, техническая поддержка и обучение пользователей,
   • понятная и удобная система оплаты за разработку ПО.
2. Адаптивность и гибкость. В некоторых проектах нет возможности четкой формулировки требований на этапе составления ТЗ, а иногда у клиента уже на этапе разработки программного обеспечения появляется потребность в изменениях, — мы с пониманием относимся к таким ситуациям и заранее предусматриваем их вероятность и согласовываем с клиентом условия работы при прецеденте.

Примеры реализованных EDISON проектов

Программное обеспечение для микротомографа для изучения материалов, созданного учёными Томского Государственного Университета

Томограф с микроточностью распознает внешнее и внутреннее устройство органических и неорганических объектов размером до спичечного коробка. Программа сканирует предмет, строит 3D модель, выделяет цветом участки одинаковой плотности.

Электронная библиотечная система Vivaldi

Сервис, разработанный EDISON, совмещает в себе электронные библиотеки ВУЗов страны с доступом к базе Российской Государственной Библиотеки. С его помощью студенты и преподаватели из 126 городов России могут получить доступ к ценнейшим и редчайшим научным трудам. ЭБС Vivaldi сотрудничает с крупными библиотеками, научными центрами и периодическими печатными изданиями. Пользователи могут посещать специализированные читательские залы круглосуточно. В данном проекте реализован лёгкий поиск нужной литературы, возможность распечатки, доступ к архивам ВУЗов страны. Сервис легко внедряется в учебное заведение, экономя место и затраты на содержание библиотеки бумажных книг.

Сеть электронных бибилиотек Vivaldi (ЭБС) с аннотацией from EDISON Software Development Centre

Система для контроля и учета рабочего времени «Большой Брат»

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

Есть замечания по нашей методологии или вы хотите поделиться своим опытом? Рады будем пообщаться в комментариях, в нашей группе в Фейсбуке или во Вконтакте.

О компании:
Проектирование программного обеспечения
Разработка программного обеспечения: этапы и принципы
Тестировщик в ответе за всё
Поддержка программного обеспечения
Как йога кодить и жить помогает: личный опыт
Обучаем сотрудников английскому: опыт Edison
Умственный труд и физическая культура