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

Создание программного продукта и управление его развитием

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

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

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

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

Источник

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

Процесс разработки разделяют на back-end и front-end.

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

Функционал бэк-энд разработчика включает:

  • проектирование архитектуры сервиса;
  • создание ядра сайта;
  • разработка платформы и основного функционала;
  • работа с архитектурой кода;
  • разработка приложений, поддерживающих пользовательский интерфейс и безопасность;
  • контроль за состоянием серверов (боевого, тестового и рабочего);
  • контроль версий, базы данных, непрерывной интеграции.

Фронт-энд разработчик создает визуальный интерфейс приложения или веб-сайта. Он создает функции, видимые пользователю.

Функции фронт-энд разработчика:

  • создание HTML-страницы сайта на основе дизайн-макетов;
  • вёрстка сайта и шаблонов для CMS;
  • привязка к пользовательскому интерфейсу скриптов, которые обеспечивают визуализацию и анимацию страниц сайта;
  • обеспечение необходимого уровня пользовательского интерфейса (UI — User Interface) и опыта взаимодействия (UX — Uzer Experience).

Специалист, который работает одновременно на фронт-энд и бэк-энд, называется фулл-стак разработчик (с англ. «full stack developer»).

При совместной работе разработчики применяют систему контроля версий и принцип разработки ветвями.

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

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

Часто требуется интегрировать несколько программных продуктов между собой для получения эффекта синергии.

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

Различают следующие виды интеграции:

1) консолидация — данные извлекаются из источников, и помещаются в Хранилище данных. Процесс заполнения Хранилища состоит из трех фаз — извлечение, преобразование, загрузка (ct, Transformation, Loading — ETL). Еще одна распространенная технология консолидации данных — управление содержанием корпорации (enterprise content management, сокр. ECM). Большинство решений ECM направлены на консолидацию и управление неструктурированными данными, такими как документы, отчеты и web-страницы.

Консолидация — однонаправленный процесс, то есть данные из нескольких источников сливаются в Хранилище, но не распространяются из него обратно в распределенную систему. Часто консолидированные данные служат основой для приложений бизнес-аналитики (Business Intelligence, BI), OLAP-приложений.

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

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

4) сервисно-ориентированная архитектура SOA (Service Oriented Architecture): данные также остаются у владельцев. При запросе происходит обращение к определённым сервисам, которые связаны с источниками, где находится информация и её конкретный адрес.

Читайте также:  Каким продуктом заменить печень

5) быстрая и простая форма интеграции является применение интерфейса прикладного программирования (Application Programming Interface, API). API позволяет абстрагироваться от того, как именно эта функциональность реализована.

Все требования, переданные в разработку следует разделять на задачи (таски), которые также декомпозируются на более подробные требования. В системе хранения и управления задачами у каждой задачи в обязательном порядке есть описание и автор, связь с проектом и трекером (например, JIRA, REDMINE). Каждая задача имеет статус. Статусы представляют собой отдельную сущность с возможностью определения прав на назначение статуса для различных ролей (например, статус «отклонен» может присвоить только менеджер) или определение актуальности задачи (например, «открыт», «назначен» — актуальные, а «закрыт», «отклонен» — нет). Задачи могут быть взаимосвязаны. Система поддерживает учёт затраченного времени. Эти данные могут быть использованы, например, для анализа вклада каждого участника в проект или для оценки фактической трудоемкости и стоимости разработки.

Источник

Ещё раз про семь основных методологий разработки

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

1. «Waterfall Model» (каскадная модель или «водопад»)

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

С помощью каскадной модели мы создали множество проектов «с нуля», включая разработку только ТЗ. Проекты, о которых написано на Хабре: средний — рентгеновский микротомограф, мелкий — автообновление службы Windows на AWS.

Когда использовать каскадную методологию?

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

2. «V-Model»

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

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

Когда использовать V-модель?

  • Если требуется тщательное тестирование продукта, то V-модель оправдает заложенную в себя идею: validation and verification.
  • Для малых и средних проектов, где требования четко определены и фиксированы.
  • В условиях доступности инженеров необходимой квалификации, особенно тестировщиков.

3. «Incremental Model» (инкрементная модель)

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

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

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

Когда использовать инкрементную модель?

  • Когда основные требования к системе четко определены и понятны. В то же время некоторые детали могут дорабатываться с течением времени.
  • Требуется ранний вывод продукта на рынок.
  • Есть несколько рисковых фич или целей.

4. «RAD Model» (rapid application development model или быстрая разработка приложений)

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

Читайте также:  Какими продуктами заменить мясо

Модель быстрой разработки приложений включает следующие фазы:

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

Когда используется Rмодель?

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

5. «Agile Model» (гибкая методология разработки)

В «гибкой» методологии разработки после каждой итерации заказчик может наблюдать результат и понимать, удовлетворяет он его или нет. Это одно из преимуществ гибкой модели. К ее недостаткам относят то, что из-за отсутствия конкретных формулировок результатов сложно оценить трудозатраты и стоимость, требуемые на разработку. Экстремальное программирование (XP) является одним из наиболее известных применений гибкой модели на практике.

В основе такого типа — непродолжительные ежедневные встречи — «Scrum» и регулярно повторяющиеся собрания (раз в неделю, раз в две недели или раз в месяц), которые называются «Sprint». На ежедневных совещаниях участники команды обсуждают:

  • отчёт о проделанной работе с момента последнего Scrum’a;
  • список задач, которые сотрудник должен выполнить до следующего собрания;
  • затруднения, возникшие в ходе работы.

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

Когда использовать Agile?

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

6. «Iterative Model» (итеративная или итерационная модель)

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

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

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

Когда оптимально использовать итеративную модель?

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

7. «Spiral Model» (спиральная модель)

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

Спиральная модель предполагает 4 этапа для каждого витка:

  1. планирование;
  2. анализ рисков;
  3. конструирование;
  4. оценка результата и при удовлетворительном качестве переход к новому витку.

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

Подытожим

На слайде продемонстрированы различия двух наиболее распространенных методологий.

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

О технологиях разработки:

Ещё раз про семь основных методологий разработки.

10 главных ошибок масштабирования систем.

8 принципов планирования разработки, упрощающих жизнь.

5 главных рисков при заказной разработке ПО.

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

Источник