Проектирование

На этапе проектирования решаются следующие задачи:

  1. Готовится функциональная спецификация или ТЗ.
  2. Обозначаются риски, и согласуется план управления рисками.
  3. Создается план проекта.

BRD/FSD/ТЗ

Техническое задание (ТЗ) можно считать приемлемым, если в нем четко и однозначно прописаны объемы и критерии приемки работ.

Если расписывать подробнее, то в ТЗ желательно упомянуть о следующем:

  1. Общее описание создаваемой системы автоматизации
  2. Сколько пользователей планируется подключить к работе с системой, чем они будут заниматься, пока без детализации.
  3. Описание бизнес процессов As Is (до планируемой автоматизации)
  4. Описание бизнес процессов To Be (после внедрения нового решения)
  5. Технико-экономическое обоснование автоматизации. Документ не обязательный, но поможет мне лучше понять клиента.
  6. Ролевая модель (кто за что отвечает, какие права на доступ к данным и алгоритмам имеет и т.д.)
  7. Перечисление сущностей, используемых в автоматизации: продукция, заказы, клиенты, денежные потоки и т.д.
  8. Классификация сущностей на входные и выходные параметры.
  9. Описание систем, содержащих входные/выходные сущности.
  10. Какие входные данные генерируются непосредственно пользователями.
  11. Количество транзакций, создаваемых пользователями, в системе
  12. Перечень и описание пользовательских форм ввода, если есть требования к дизайну, то еще и с картинками.
  13. Перечень и описание «защит от дурака» для данных, вводимых пользователями.
  14. Перечень проверок для данных, поставляемых другими системами.
  15. Перечень спецификаций (в том числе и принятых на международном уровне) сообщений, которым должны соответствовать входные и выходные потоки данных.
  16. Требования к интеграции с другими системами автоматизации. Для интернет магазина это, например, интеграция с CRM, IP телефонией, загрузка заказов из систем партнеров, отслеживание этапов обработки заказов в курьерской компании и т.д.
  17. Требования к составу отчетов c описанием атрибутов отчетов и алгоритмами их получения из систем источников, а также прочих алгоритмов расчетов.
  18. Требования к источникам данных для отчетности: непротиворечивость, время готовности, API получения данных и т.д.
  19. Требования к скорости построения отчетов или временным окнам в которые отчеты должны быть запущены и рассчитаны.
  20. Критерии приемки (тест кейсы или программа и методика испытаний (ПМИ)) - для каждой конкретной работы. Именно по тест кейсам и ПМИ будет сдаваться и приниматься моя работа.

Управление рисками

Что касается рисков. Создание ПО на заказ – это практически всегда создание чего-то нового, того, что связано с высокой степенью неопределенности , как неотъемлемого аспекта жизненного цикла (создание, эксплуатация, вывод из эксплуатации) любой программы. Поэтому я стараюсь по возможности, «постелить соломку» в наиболее опасных местах. Я также стараюсь объяснить свои опасения заказчику, а также масштабы последствий, если эти опасения не будут приняты во внимание. Я стараюсь всегда оценивать риски в любом проекте, с которым работаю, причем не только в начале, но и в процессе его реализации. Для каждого риска мы должны договориться, что мы с рассматриваемым риском делаем: принимаем (и если да, то за чей счет), смягчаем последствия и т.д.

Знал бы, где упасть, соломку бы подстелил, или управление рисками по-японски

Знал бы, где упасть, соломку бы подстелил, или управление рисками по-японски. Источник.

План проекта

Ну и, конечно же, план проекта. Без него невозможно обоснованно оценить стоимость разработки согласно ТЗ. План проекта – это перечень работ с их длительностями, трудозатратами и взаимозависимостями, который и является одним из основных документов, обосновывающих стоимость работ для заказчика. Часто бывает такое, что по одному и тому же ТЗ разные подрядчики дают разницу в оценке стоимости в несколько раз. Если так получилось, рекомендую заказчику не хвататься за самое дешевое предложение, а сначала поговорить с тем, кто запросил больше денег – почему его цена столько высока. Особенно это важно, если стоимость человеко-часа у двух подрядчиков приблизительно одинакова. Вполне возможно, что более дорогой подрядчик заложил необходимые работы, о которых подрядчик с низкими ценами не подумал. Если эти работы не выполнить, то ПО получится не соответствующим ТЗ и ожиданиям заказчика.

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