После того, как Вы сделали подготовительную работу и можете ответить на вопросы «Что нужно автоматизировать? Для какой цели? Какой тип системы для этого потребуется?», можно переходить к поиску исполнителя. Каким бы способом Вы не искали разработчика, необходимо будет поставить ему задачу. Причем поставить задачу нужно так, чтобы максимально точно передать цель и идею проекта. Ведь чем лучше поставлена задача, тем более точны будут полученные коммерческие предложения. Традиционно, первичную постановку задачи называют RFP (request for proposal) или запрос на предложение. В данной статье мы поделимся советами, как составить RFP так, чтобы разработчики правильно поняли задачу.
Запрос на предложение – это один из самых важных документов, так как именно он создает первоначальное представление о проекте, опираясь на которое потенциальные разработчики составляют свои коммерческие предложения. Здесь важно не торопиться, а еще лучше отвести на составление документа минимум два дня. В первый день максимально подробно расписать все необходимые требования, а на второй еще раз внимательно все прочитать и отредактировать. Когда вы работаете над документом, взгляд «замыливается», и становится трудно адекватно оценить результат. После же того, как вы отдохнете, например, на следующий рабочий день, внести финальные исправления в текст будет значительно проще, а также, возможно, у вас появятся новые идеи или вы увидите упущенные функции.
Начать запрос на предложение мы советуем с вводного слова, в котором следует кратко раскрыть существующую проблему. Почему вы нуждаетесь в автоматизации? Какие проблемы должно помочь решить новое программное обеспечение? Какие показатели вы хотите улучшить? Что планируете достичь в будущем? Ответы на эти вопросы помогут аналитикам исполнителя вникнуть в проект, а может быть и предложить вам более подходящее решение.
Первым пунктом в RFP необходимо зафиксировать цель. Здесь не должно возникнуть трудностей, так как цель уже была сформулирована на подготовительном этапе.
В следующем пункте следует перечислить задачи. Задачи – это конкретные работы, выполнение которых позволит достичь цель. Можно сказать, что данный перечень задач – это чек-лист проекта.
Каждая задача должна соответствовать следующим обязательным критериям:
- Задача должна быть четко сформулирована;
- Критерии выполнения задачи должны быть измеримыми;
- Задача должна способствовать достижению цели.
Как подходить к формулировке задач?
Вернитесь к бизнес-процессам, которые вы решили автоматизировать. Подумайте, какие функции можно автоматизировать, какие данные должны быть в системе, чтобы она могла выполнять эти функции. Можно начать с того, что просто записать все выполняемые функции и данные, которые для этого нужны. Подумайте, каким способом можно поместить нужные входные данные в систему. Может быть есть другая информационная система, в которой можно их взять? Или сайт? А может быть в вашей компании есть универсальный файл, при помощи которого их можно загрузить?
После того, как вы сформируете перечень задач на основе функций, выполняемых вашими сотрудниками каждый день, подумайте, какие еще функции могли бы вам помочь достичь цель. Вы можете включить дополнительные возможности для аналитики, мониторинга и контроля, если это будет способствовать достижению цели.
Первые два пункта данного документа самые важные. Вы будете возвращаться к ним на протяжении всего проекта – на соответствие цели нужно проверять все задачи, появляющиеся в процессе разработки, а перечень задач – это чек-лист для проверки завершенности проекта. Отнеситесь к их написанию максимально внимательно, так как пропустив или неточно сформулировав на данном этапе функционал, вы рискуете получить не тот результат, на который рассчитываете.
Третьим пунктом в запросе на предложение следует описать критерии качества продукта. Примером характеристик для оценки качества системы можно считать:
- Функциональность (соответствие поставленным задачам, безопасность);
- Надежность (отказоустойчивость, резервное копирование, возможность восстановления из резервной копии);
- Эффективность (производительность, быстродействие);
- Сопровождаемость (пригодность к изменениям, стабильность, тестируемость).
Вы можете применять и любые другие наборы характеристик, но лучше, чтобы они соответствовали общим требованиям стандарта ИСО/МЭК 9126.
В последнем пункте запроса на предложение вы можете указать критерии выбора разработчика/поставщика необходимого программного продукта. Данный пункт не обязателен, но весьма полезен, так как позволяет на начальном этапе отсечь заведомо неподходящих кандидатов, и тем самым сэкономить время и себе и им.
Таким образом, получаем следующую структуру RFP:
- Цель;
- Задачи;
- Критерии качества конечного продукта;
- Критерии выбора поставщика/разработчика.
Вы можете придерживаться явной структуры документа, а можете изложить информацию текстом в произвольном виде, но если в вашем запросе на предложение будут содержаться описанные здесь блоки, вероятность того, что полученные в ответ на него коммерческие предложения будут составлены с пониманием целей и задач проекта, значительно увеличивается.
