Какие у вас этапы разработки продукта?

Предположим есть идея, а что дальше с ней делать?

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


Что-то вроде:

1. Общее описание проекта (какие задачи решает?)

2. Целевая аудитория (кто будет этим пользоваться и почему?)

3.… (а дальше что? как?)


Благодарю за любые советы или ссылки на умные статьи!
  • Вопрос задан
  • 3729 просмотров
Решения вопроса 1
beskov
@beskov
Организую обучение аналитиков и проектировщиков
Есть статья Юры Химонина на 50 страниц про то, как разрабатывать требования к программным продуктам: pmi.ru/articles/articles/1211/

Есть и другие полезные книги: school.system-analysis.ru/books/
Ответ написан
Пригласить эксперта
Ответы на вопрос 8
@gleb_kudr
Если вы не госорган и не большая бюрократическая структура, то главное — пишите нормальным человеческим языком. Все бюрократизмы выжигать каленым железом. Не должно быть словосочетаний типа «наша система должна осущствлять функции по взаимодействию...».
Вы создаете продуктовое описание для того, чтобы объяснить концепцию другому человеку. Объяснять нужно человеческим языком.
Очень многие (90%) недооценивают важности этого и пишут продуктовые документы так, как будто это расшифровки съезда КПСС.

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

(дока описывает техпроцесс разработки web-приложения малого масштаба, хотя мб и для среднего подойдёт)

Подготовка к проектной работе
=====================================
1. Требования
1.1. Постановка задачи (оценка и установка лимитов ресурсов и сроков разработки)
1.2. Основные функции (общее описание выполняемых задач)
1.3. Требования к архитектуре
1.3.1. Планы по поддержке проекта
1.3.2. Используемые технологии (исходя из планов по поддержке)
1.3.3. Архитектурное решение (исходя из использ. технол., модульн., монол., слои и т.п.)
1.3.3.1. Сопряжение со сторонними технологиями/ПО
1.4. Описание целевой аудитории (конечные пользователи, их навыки, восприятие, UX)
1.5. Сроки выполнения (на разработку, на интерфейс, на тестирование, на развёрыв.)

2. Техническое задание (на основе требований и дизайн-макета)
2.1. Платформа (связки ПО, с версями и конфигурациями)
2.2. Структура проекта (блок-схема с разделами и подразделами FE и BE)
2.3. Бизнес-объекты (их структура/свойства, действия над ними, и их поведение)
2.4. Бизнес-процессы (алгоритм линейных процессов на основе бизнес-объектов)
2.5. Политика безопасности
2.5.1. Списки доступа (описание разрешений для ролей / групп пользователей)
2.5.2. Меры обеспечения безоп. (библиот., алгоритмы, порядок восст. доступа, ...)
2.6. Принцип хранения данных
2.6.1. Устройство хранилища файлов (форматы, способ хранения)
2.7. Макет интерфейса (базовый макет + детальные черновики всех страниц)
2.8. Поведение интерфейса
2.9. Дизайн-макет (гайды, нормы, правила, черты единого стиля)
2.9.1. Палитры (палитры разделов и типов страниц сайта, для печати, служебные)
2.9.2. Отступы, размеры, геометрия, горизонтальный ритм
2.9.3. UX / особенности и правила поведения интерфейса
2.10. Roadmap проекта (на основе предыдущих пунктов)

Проектирование архитектуры и разработка
=====================================
3. Проектирование (исходя из выбранной политики безоп., на основе ТЗ и требований)
3.1. Cтруктура приложения (детальное описание; URL map, routing, описание actions)
3.1.1. Структура web-приложения (модули, контроллеры и actions)
3.1.2. Карта внутренних маршрутов URL-адресов
3.2. Объектная модель «общего домена» (UML-диаграмма классов)
3.3. Проектирование БД (DDL-диаграмма, SQL-файл, альфа-версия)

4. Backend
4.1. Заготовка Yii2-приложения (config, namespaces, контроллеры, actions, views)
4.1.1. Создание заготовок actions (пустых файлов, либо конфигур. и подкл. базовых)
4.1.2. Подготовка View-файлов (создание пустых + конфигуриров. работы с шабл.)
4.2. Написание УК (управл. код - вызовы функций классов общего домена в actions)
4.3. Разработка вызванных в УК функций (расширение API, функционала библиотек)
4.4. Доработка БД (DDL-диаграмма, SQL-файл, бета-версия)
4.5. Внедрение отладочного функционала
4.6. Генерация тестовых данных приложения в БД
4.7. Описание ключевых аспектов кода (для упрощения поддержки проекта)

5. Интерфейс
5.1. Базовый макет (композиция из блоков, на основе дизайн-макета, подбор grid system)
5.2. Сценарии интерактивности и поведение UI (описание интерактивной части)
5.3. Настройка компонентов и контента (настр. yii\Asset’s, загрузка изображений UI)
5.4. Подключение новых Jade-шаблонов
5.5. Прототип. Базовая Jade-вёрстка (допустимо: приблизительное соотв. макету)
5.6. Javasript/CSS-интерактивность
5.7. Косметика UI (pixel-perfect вёрстка с соблюдением всех требований к дизайну)

Завершение разработки. Развёртывание.
=====================================
6. Развёртывание
6.1. Предстартовая отладка (нагрузочное тестирование, безопасность, ..)
6.2. Комплексная доработка всех частей приложение

мною пока пройдена первая треть и ряд пунктов из UI, вся часть по проектированию и арх. БД и каркаса приложения (а это значит, что всё это ещё может меняться, переставляться местами, удаляться и добавляться ещё не раз и не три.., будьте бдительны!), т.к. начал я писать ТЗ (к Вашему недоумению) где-то на середние разработки, поняв, что это тут будет очень кстати и сейчас и, особенно, потом.

.. +, помимо прочего эти доки (почти каждый пункт в списке - отдельный документ, файл, диаграмма или законченный объект/набор чего-то проектно-полезного) помогли мне мне лучше понять механику продакшена ПО, то самое магическое нечто, что позволяет коду выполнять хотелки, т.е. полноценная, грамотная и красивая реализация прикладных задач (то,ради чего ПО и пишется, но совсем не всегда выполняет свои задачи грамотно, нормально и вообще адекватно.. и вообще выполняет ли - думаю многие видели эти ужасные неповоротливые (в т.ч. enterprise-oriented) решения, с которыми проблем больше чем пользы, ту же Ультиму, к слову, уже сколько лет внедряют в Юлмарте, или уже внедрили, я хз, но, столько лет и млн. денег слито - смех и грех..)
Ответ написан
vshemarov
@vshemarov
ЦА — обязательно на самых начальных этапах. Без понимания аудитории потенциальных пользователей вообще нет смысла затевать проект. И тут важно понимать, что определения типа «все пользователи Рунета», или все жители города N, или все пользователи смартфонов — это все не работает. Нужна конкретика, нужен обобщенный портрет потенциального юзера (в принципе, может быть несколько категорий юзеров, и для каждой — свой портрет). Только тогда будет понятно, для кого разрабатывается продукт, как его упаковывать, как продвигать и т.д.
Ответ написан
beskov
@beskov
Организую обучение аналитиков и проектировщиков
Какого продукта — заказного или для открытого рынка?

Для заказного:

Исследование интересов заинтересованных лиц
Изучение устройства автоматизируемой деятельности
Анализ проблемной ситуации заинтересованных лиц
Постановка целей создания системы
Разработка бизнес-требований
Создание концепции системы
Разработка технико-экономического обоснования
Разработка технического задания
Разработка и тестирование модели взаимодействия пользователя с системой
Разработка стратегии и методики тестирования
Разработка архитектурных решений
Прототипирование архитектурно-значимых сценариев
Разработка и тестирование отдельных сценариев
Регулярное интеграционное тестирование и тестирование внешних атрибутов качества системы
Документирование разработанных сценариев
Развёртывание и демонстрация сценариев
Обучение работе с системой
Сбор обратной связи от пользователей
Ответ написан
beskov
@beskov
Организую обучение аналитиков и проектировщиков
Есть стандарт на разработку требований к системам, в нём есть типовые структуры документов требований и описание процесса: www.computer.org/portal/documents/82129/160549/IEEE+29148-2011.pdf
Ответ написан
Комментировать
— Сначала пишите концепцию. Пишется она, как учили в институте писать дипломные работы — цели, задачи, актуальность (+ исследование рынка и конкурентов), первоначальные наброски и ТЗ.
— Затем если нужна команда, то обращаемся к людям, показывая эту концепцию.
— Потом начинается разработка. Тут многое зависит от проекта. Попутно вводится система учёта ошибок, будущих фитч и журнал выполненных работ.
— Затем наступает этап внутреннего тестирования.
— По результатам тестирования проводится исправление ошибок или перестройка проекта.
— Снова внутренне тестирование.
— Опять исправляем ошибки и кидаем проект на тестирование фокус-группе.
— Снова исправляем ошибки и проверяем.
— Выпускаем релиз и празднуем.
Ответ написан
@rozhik
Если подойти со стороны читателя (сорри, много начитался подобного). Я Рекомендовал бы сделать тезисное описание важного в продукте, и его основные особенностями так, чтобы оно уместилось на одну страницу. В сети можно найти десятки пунктов к описанию (что можно прочесть выше). Но главное именно первая страница, чтобы человека заинтересовать.
Все остальные пункты зависят от аудитории документа. К примеру, если вы продаёте продукт — то реклама покупки, если ищите инвестора — то обьяснение монетизации, если это диплом — то описание меню на выпускном… (я конечно сильно утрирую)
Не пытайтесь впихнуть много пунктов. Вместо этого тезисно напишите что вы хотите читателям доказать — и доказывайте это.
Бог Вас упаси использовать ГОСТ стандарты для описания майнсипера (хотя там пункты очень продуманны)
Ответ написан
xmoonlight
@xmoonlight
https://sitecoder.blogspot.com
3774b0f904b54ccca9dad35189ae02bd.jpg
ТЗ
1. Описание назначения продукта
2. Технологии реализации (железо, ОС, ЯП, фреймворки, библиотеки и т.д.)
3. Список ролей продукта и их назначение
............. и т.д.
(кликните на изображение)
Ответ написан
Комментировать
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы