На этапе проектирования решаются следующие задачи:
-
Готовится функциональная спецификация или ТЗ.
-
Обозначаются риски, и согласуется план управления рисками.
-
Создается план проекта.
BRD/FSD/ТЗ
Техническое задание (ТЗ) можно считать приемлемым, если в нем четко и однозначно прописаны объемы и критерии приемки работ.
Если расписывать подробнее, то в ТЗ желательно упомянуть о следующем:
-
Общее описание создаваемой системы автоматизации
-
Сколько пользователей планируется подключить к работе с системой, чем они будут заниматься, пока без детализации.
-
Описание бизнес процессов As Is (до планируемой автоматизации)
-
Описание бизнес процессов To Be (после внедрения нового решения)
-
Технико-экономическое обоснование автоматизации. Документ не обязательный, но поможет мне лучше понять клиента.
-
Ролевая модель (кто за что отвечает, какие права на доступ к данным и алгоритмам имеет и т.д.)
-
Перечисление сущностей, используемых в автоматизации: продукция, заказы, клиенты, денежные потоки и т.д.
-
Классификация сущностей на входные и выходные параметры.
-
Описание систем, содержащих входные/выходные сущности.
-
Какие входные данные генерируются непосредственно пользователями.
-
Количество транзакций, создаваемых пользователями, в системе
-
Перечень и описание пользовательских форм ввода, если есть требования к дизайну, то еще и с картинками.
-
Перечень и описание «защит от дурака» для данных, вводимых пользователями.
-
Перечень проверок для данных, поставляемых другими системами.
-
Перечень спецификаций (в том числе и принятых на международном уровне) сообщений, которым должны соответствовать входные и выходные потоки данных.
-
Требования к интеграции с другими системами автоматизации. Для интернет магазина это, например, интеграция с CRM, IP телефонией,
загрузка заказов из систем партнеров, отслеживание этапов обработки заказов в курьерской компании и т.д.
-
Требования к составу отчетов c описанием атрибутов отчетов и алгоритмами их получения из систем источников, а также прочих алгоритмов расчетов.
-
Требования к источникам данных для отчетности: непротиворечивость, время готовности, API получения данных и т.д.
-
Требования к скорости построения отчетов или временным окнам в которые отчеты должны быть запущены и рассчитаны.
-
Критерии приемки (тест кейсы или программа и методика испытаний (ПМИ)) - для каждой конкретной работы.
Именно по тест кейсам и ПМИ будет сдаваться и приниматься моя работа.
Управление рисками
Что касается рисков. Создание ПО на заказ – это практически всегда создание чего-то нового, того, что связано с высокой степенью неопределенности ,
как неотъемлемого аспекта жизненного цикла (создание, эксплуатация, вывод из эксплуатации) любой программы. Поэтому я стараюсь по возможности,
«постелить соломку» в наиболее опасных местах. Я также стараюсь объяснить свои опасения заказчику, а также масштабы последствий, если эти опасения не
будут приняты во внимание. Я стараюсь всегда оценивать риски в любом проекте, с которым работаю, причем не только в начале, но и в процессе его реализации.
Для каждого риска мы должны договориться, что мы с рассматриваемым риском делаем: принимаем (и если да, то за чей счет), смягчаем последствия и т.д.
Знал бы, где упасть, соломку бы подстелил, или управление рисками по-японски.
Источник.
План проекта
Ну и, конечно же, план проекта. Без него невозможно обоснованно оценить стоимость разработки согласно ТЗ. План проекта – это перечень работ с их длительностями,
трудозатратами и взаимозависимостями, который и является одним из основных документов, обосновывающих стоимость работ для заказчика.
Часто бывает такое, что по одному и тому же ТЗ разные подрядчики дают разницу в оценке стоимости в несколько раз.
Если так получилось, рекомендую заказчику не хвататься за самое дешевое предложение, а сначала поговорить с тем,
кто запросил больше денег – почему его цена столько высока. Особенно это важно, если стоимость человеко-часа у двух
подрядчиков приблизительно одинакова. Вполне возможно, что более дорогой подрядчик заложил необходимые работы,
о которых подрядчик с низкими ценами не подумал. Если эти работы не выполнить, то ПО получится не соответствующим ТЗ и ожиданиям заказчика.