1. Нужен ли нам продукт?
Игорь Новиков
NAUMEN

2. Зачем говорить об этом?
• Зачем нужны продукты?
• Всегда ли нужен продукт?
• Как создать продукт?
2

3. Проекты и продукт
• Проект – разовая производственная
деятельность.
• Продукт (программное обеспечение):
• Маркетинг;
• Требования;
• Реализация.
3

4. Проекты и продукт
Проекты приносят деньги.
В продукт инвестируют, чтобы дешевле
выполнять проекты.
4

5. История 1.
«Три проекта – один код»
5

6. Начальные условия
• Новая команда делает «с нуля» новый проект.
Предметная область – закупки – новая для всех.
• Отсутствие известных аналогичных продуктов на
рынке и даже устоявшейся методологии.
• В компании нет бизнес-направлений со своими
бюджетами.
6

7. Куда пропало несколько человеко-
месяцев?
1. Несколько «похожих» проектов стартовало в одно время.
2. Возникла мысль объединить усилия.
3. Аналитики совместно определили требования,
разработчики закодировали (осень 2006 г.).
4. Проекты потеряли общие черты, для удешевления
сопровождения вернулись к истокам (весна 2007 г.).
7

8. Потрясающе проработанная
структура модулей
8

9. Почему не получилось?
• Проекты были мало похожи… Вообще не
похожи!
• Внутри компании не было того, для кого
продукт мог быть ценен.
9

10. История 2.
«Некогда объяснять – надо делать!»
10

11. Начальные условия
• Выполнен первый «типичный» проект.
• Заказчики определяют требования к
системе на 100%, а мы залазим в «чужие»
конкурсы.
• Бизнес-направление в условиях
выживания.
11

12. Несколько проектов в «правильной»
концепции
Модули
Проекты
Свердловская
область, 2006 г.
Ступино, 2008 г.
Орловская область,
2010 г.
BK + + +
DBK + + +
GUIC + + +
… … … …
GPMS + + +
- SVO +
- STUPINO +
- OREL +
12

13. Следующие проекты создавались как копия
более подходящего
• BK
• DBK
• GUIC
• …
• GPMS
– TAGIL
• BK
• DBK
• GUIC
• …
• GPMS
– SPB
• BK
• DBK
• GUIC
• …
• GPMS
– SVO2
Нижний Тагил,
2010 г.
Санкт-Петербург,
2010 г.
Свердловская
область, 2011 г.
13

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

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

16. История 3.
«Правильный продукт»
16

17. Начальные условия
• Накоплен опыт нескольких проектов, ещё больше
получено в результате деятельности по продажам.
• Централизованное регулирование предметной
области усилено – больше ограничений на
желания заказчика.
• Реформа в предметной области даёт возможность
избавиться от «балласта».
17

18. Выводы
• Нет смысла пытаться создать продукт, без его
видения. Если не понятно, есть ли видение,
значит его нет.
• «Копипаст проектов» не вреден сам по себе и
может иметь обоснование, понятное даже
разработчикам.
• Если даже у вас есть видение продукта, не факт,
что вас ждёт успех 
18

19. Спасибо!
Игорь Новиков
inovikov@naumen.ru
twitter.com/kunfui