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

Сначала подготовьте сопоставимую должностную инструкцию.

Когда вы запросите у трех разработчиков программного обеспечения расценки на одно и то же приложение, вы можете столкнуться с тремя разными областями применения. Один оценивает только экраны, другой добавляет передачу данных, а третий предлагает обслуживание отдельно. Эти предложения нельзя сравнивать по одной и той же сумме. Сначала опишите текущую работу и ожидаемый результат на кратком примере. Какую информацию получает сотрудник, готовящий предложение, кто его утверждает и какой документ поступает заказчику? Распространение реального примера путем извлечения личных данных обеспечивает более понятное начало, чем просто перечисление названий функций.

Должностная инструкция не обязательно должна представлять собой детальное техническое задание. Пусть пользователи, обязательная информация, основные операции, ожидаемый результат и важные исключения будут понятны. Затем попросите каждого кандидата письменно ответить на те же вопросы. Следующие пять вопросов можно использовать, чтобы понять цену и посмотреть, как приложение выживет после поставки. Длинный ответ не является доказательством качества. Важнее, чтобы оно было применимо в вашем бизнесе и могло быть проверено при приемке.

Первый вопрос: кто будет выполнять работы по техническому обслуживанию?

Список продуктов, бизнес-правила или внешние услуги могут измениться после поставки программного обеспечения. Кто будет реагировать, когда сообщат об ошибке, и какой канал будет использоваться? Исправления ошибок, обновления безопасности и дополнения к новым функциям должны быть записаны отдельно в объеме обслуживания. Не думайте, что это одна и та же цена. Также отделите время ответа от времени разрешения. Если вы говорите, что уведомление получено, это не означает, что ошибка исправлена; Следует четко определить, чего ожидают стороны в каждой ситуации.

Работа с единственным поставщиком сама по себе не является проблемой. Но спросите, кто продолжит работу, когда человек уйдет в отпуск или покинет проект. Резервное копирование, откат и регистрация изменений также являются частью обслуживания. Попросите их объяснить на примере, как они тестировали обновление перед его внедрением в эксплуатацию. Автоматика работает Определение лица, осуществляющего техническое обслуживание, при планировании снижает неопределенность, которая возникнет после завершения проекта. Вместо того, чтобы выбирать самый широкий пакет для каждой потребности, определите поддержку, которая вам действительно нужна.

Второй вопрос: у кого будет код и посылка?

Модель поставки готового сервиса и заказного ПО может отличаться. Будет ли предоставлен исходный код, установочный документ и информация о зависимостях раздела, который будет разработан специально для вас? Каковы будут условия, при которых другая команда сможет продолжить заявку? Не оставляйте эти вопросы со словесными ответами. Комплект поставки и условия использования следует видеть в предложении. Предоставление ссылки на репозиторий не раскрывает все права использования; При необходимости условия контракта и компонентов должны быть оценены соответствующими экспертами.

Определите небольшой тест для проверки удобства использования поставки. Установка в чистой среде, выполнение основного процесса и восстановление образца резервной копии могут быть хорошим началом. Запишите, какую операцию с каким документом можно выполнить. Контроль доставки исходного кода вы также можете прочитать. Размещение паролей и ключей внутри кода не является методом доставки. Доступ должен передаваться посредством отдельного, авторизованного и зарегистрированного процесса; Ненужный доступ должен быть закрыт по окончании проекта.

Третий вопрос: где и как будут управляться данные?

В какой среде будут храниться данные о клиентах, заказах или персонале? Кто сможет видеть данные, какая роль сможет выполнять какие действия и как будут экспортироваться записи? Попросите провайдера показать поток данных на простой диаграмме. Также следует уточнить направления, направляемые внешним службам. Не передавайте реальные личные данные только для того, чтобы подготовить предложение; Используйте образцы или анонимные данные. Обязательства по обработке данных могут потребовать экспертной оценки в зависимости от области применения.

Оцените утверждение о том, что была сделана резервная копия, и то, как она была восстановлена. Где находится резервная копия, у кого есть к ней доступ и тестировалось ли ранее восстановление? Также спросите, в каком формате вы получите свои данные после завершения обслуживания. Предоставление отчета в формате PDF не может означать, что все записи могут быть перенесены в другую систему. Имена полей, связи и дополнительные файлы должны быть включены в экспорт. Добавление этих требований к первоначальному предложению может уменьшить необходимость определения нового проекта при его отправке.

Четвертый вопрос: какую работу завершит первый релиз?

Не обязательно включать все идеи в первую версию. Важно завершить определенный рабочий процесс от начала до конца. Если пользователь входит в систему, но не может распечатать утвержденный документ, возможно, основное задание еще не завершено. Если попросить кандидата подробно рассказать о первой версии, эта разница станет заметной. Проясните, какие данные будут вводиться вручную, какое подключение будет отложено и какой отчет будет сформирован. Напишите ожидаемый результат выборочной операции, а не расплывчатый список свойств.

Создайте критерии приемки для того же задания. Что происходит, когда необходимое поле отсутствует, как обрабатывается двойная регистрация и что видит пользователь, если транзакция отменена? Рассмотрение потоков ошибок позволяет избежать оценки, основанной исключительно на успешной демонстрации. С самого начала изучите метод внесения изменений и подход к ценообразованию для новых функций. Вместо того, чтобы гарантировать точное время для каждого этапа проекта, четко оцените зависимости, ожидаемую от вас информацию и даты принятия решений.

Пятый вопрос: кто и как будет тренировать команду?

Демонстрация разработчика не доказывает, что сотрудники могут использовать приложение. Спланируйте обучение на основе вашего примера процесса. Позвольте пользователю открыть запись, исправить ошибочное поле, получить необходимое одобрение и создать выходные данные. Также следует объяснить шаги по изменению разрешений администратора и сообщению о проблеме. Краткое руководство пользователя и образец записи также будут полезны начинающему работнику. Застойные моменты в обучении не следует рассматривать как просто ошибку пользователя; Следует рассмотреть вопрос о том, требуются ли улучшения отображения или описания.

Соберите ответы на пять вопросов в одной таблице: объем работ, ответственные, документ поставки, приемочные испытания и стоимость. Уточните все открытые вопросы до подписания предложения. Целью не является ранжирование кандидатов по количеству технических терминов. Надежным ориентиром является выбор команды, которая понимает ваш бизнес, четко описывает его границы и обеспечивает возможность проверки результатов. Таким образом, последующее использование и обслуживание учитываются в решении так же, как и первый показ.

Частые вопросы

Как сравнить предложения?

Сравните с тем же процессом, объемом, показателями доставки и ожиданиями в отношении ухода. Сравнивать только общую стоимость недостаточно.

Должны ли быть включены все функции в первый выпуск?

Можно выбрать ограниченную серию, дополняющую основной рабочий процесс. Разберите недостающие функции и напишите следующий этап.

Должно ли обучение быть частью обучения?

В комплект поставки могут входить практическое обучение и краткое руководство пользователя, в котором люди, которые будут использовать данную работу, смогут выполнять примеры операций.