Как создаются программные решения. Описание процесса для клиента IT-компании.
Прозрачность на старте
Обычно, когда процессы в вашем бизнесе уже отлажены и какие-то операции хочется регламентировать, а данные поместить в четкую структуру и получать отчетность - возникает вопрос создания информационной системы. Или приобретения готовой.
Для большей части процессов, которые похожи в разных организациях - уже написано много разного софта. И задача - выбрать наиболее адекватный и наименее дорогой, и еще чтобы было легко внедрить, поддерживать и развивать в процессе. По сути, чтобы цена владения была приемлемой и соответствовала получаемой полезности.
Но есть процессы особенные, как правило - это ноу хау вашего бизнеса, что-то, свойственное только вам. И под них требуется специфическое решение. И оно должно вам соответствовать и решать именно ваши задачи и решать удобно. И оно должно быть достаточно легко адаптируемым, если ваши процессы и потребности будут меняться во времени.
Мы специализируемся на таких решениях и я хочу поделиться опытом, который может быть полезен при заказе такого вот проекта.
Очень важно при определении задач, которые будет решать создаваемый софт, собрать информацию у всех, кто будет с ним работать тем или иным образом. Это и руководители и непосредственные исполнители, это люди, которые работают потом с отчетами, это системные администраторы, которые будут все это поддерживать. Задача по сбору требований у всех участников процесса - это задача аналитика. Обычно нормальный подрядчик предоставляет такого специалиста клиенту до старта проекта, чтобы создать общее видение продукта, определить ключевые цели, расставить приоритеты. На этом этапе можно определить варианты создаваемого решения и приблизительные бюджеты для того или иного варианта.
После выбора варианта решения прорабатывается уже детальное техзадание. Должна отметить, что это не всегда возможно. Иногда клиент сам не видит еще, каким должен быть финальный продукт. И пока не повертит в руках разные прототипы - не может определить, что ему больше подходит. Такой вариант сбора требований, как создание прототипов для различных компонент системы - тоже возможен. Хотя обычно этот подход используется для проектирования каких-то инновационных продуктов. Зато он позволяет до начала проекта понять, каким должен быть функционал основных блоков. Хотя, это уже можно рассматривать, как фазу старта проекта.
Для старта проекта критичным является не детальное ТЗ (его можно прорисовывать в процессе работы над конкретными кусками), а именно хорошее понимание ваших бизнес целей разработчиком. Но этого тоже не достаточно, существует масса вещей, которые также нельзя упустить на этом этапе:
Объем данных, который планируется в системе
Вопросы защиты информации
Вопросы интеграции с вашей уже существующей информационной средой
Нагрузка, под которой будет работать система (вдруг, вы - интернет магазин и у вас десятки тысяч пользователей онлайн одновременно)
Требования к непрерывности работы системы (можно ли ее останавливать на технические работы или она должна быть онлайн 24 часа в сутки 7 дней в неделю)
Различные иные нефункциональные требования к системе
При старте проекта очень важно зафиксировать всю вышеперечисленную информацию. Заказывая проект, вы сами должны очень четко понять все ваши требования к создаваемому решению. И хороший подрядчик должен обеспечить процесс вот этого создания внятных требований.
В следующей статье я расскажу о процессе разработки с точки зрения клиента, и как клиент может контролировать, что подрядчик делает именно то, что нужно.