При производстве кастомного IT-решения мы назначаем менеджера, который контролирует работу и взаимодействует с заказчиком, формируем команду, развертываем проектное окружение.
Процесс разработки программного продукта включает в себя несколько фаз. Каждая фаза состоит из трёх блоков: уточнение требований, реализация решения, передача проекта заказчику. Поговорим подробнее об этапе уточнения требований.
Уточнение требований поможет максимально чётко выявить потребности заказчика, определиться с ресурсами и командой, оценить стоимость IT-проекта. Основываясь на требованиях, команда разработки согласовывает с заказчиком фазы и сроки реализации решения и определяет методику приемочного тестирования программного продукта.
Стоит оговориться, что наш подход не претендует на уникальность. Его ценность состоит в том, что мы собрали и проанализировали аспекты различных методологий оценки качества, протестировали их в своей работе над кастомными проектами и составили список требований (чек-лист), достаточный для адекватной и точной оценки IT-проекта.
Чек-лист проработки требований к проекту состоит из нескольких крупных блоков.
1. Функциональные требования к "успешным" сценариям
В этом пункте мы выясняем, что должна делать система. Заказчиков, к которым у разработчиков не возникает вопросов по функциональным требованиям, мы ещё не встречали.
Например, клиент описывает ожидаемый результат: "Пользователь заходит в личный кабинет, выбирает там то-то, а дальше переходит туда-то". Стоп! Откуда возьмется личный кабинет? Как пользователи регистрируются? Как меняют и восстанавливают пароли? Нужно ли импортировать/подключить уже существующую базу пользователей? Выяснять "упущенные", неявные требования — задача команды.
2. Функциональные требования по обработке нештатных ситуаций
Когда мы покупаем автомобиль, мы думаем о том, как он будет нас возить в разные интересные места, а не о том, как нам придется его заправлять.
Обычно заказчик более или менее чётко представляет, как будет работать решение при позитивных сценариях.
По нашему опыту значительная часть трудозатрат приходится на обработку ошибок, связанных с внешними факторами: нестабильная связь, некорректная работа сторонних сервисов, недостаточный объем хранилища для бэкапов и так далее.
3. Нефункциональные требования
a. Производительность и мощность
Желательно уточнить цифры: количество пользователей, скорость ответа при заданных объемах данных и нагрузке на систему, объем хранимых данных, ресурсопотребление системы при штатной эксплуатации.
Бывает такое, что клиент стремится минимизировать трудозатраты за счёт всего, в том числе просит предусмотреть минимальную производительность. Проект доживает до стадии прототипа, а реальную нагрузку продакшн-уровня уже не тянет.
В нашей практике был случай, когда клиент заказал демонстрационный прототип с возможностью быстрого развертывания на собственном ноутбуке, а потом запустил в него десяток пользователей, не посоветовавшись с нами. Прототип не смог обеспечить одновременную работу такого количества юзеров.
На самом старте важно объяснить заказчику, что на бумажном самолете пассажиров не увезешь.
b. Устойчивость
Выясняем ожидания по MTBF (mean time between failures — средняя наработка на отказ) при нормальной, критичной и закритичной нагрузке. На основе этого можно выбрать наиболее пригодный технологический стек и определить, нужно ли дополнять решение таким "побочным" функционалом, как расширенный мониторинг, самовосстановление, автомасштабирование.
Анализ проводится параллельно с пунктами a, c, e, f, g.
c. Надёжность и восстанавливаемость
Здесь мы учитываем время на восстановление системы после падения, полного уничтожения всего дата-центра и рабочих данных. Обговариваем требования к резервному копированию данных и резервированию системы.
d. Безопасность
Не забываем выяснить роли групп пользователей, схему разграничения прав доступа, требования к шифрованию данных и каналов коммуникации.
Этот пункт особенно важен для проектов с персональными данными, которые хранятся в облаках.
Что делать, если клиент, работающий с "чувствительными" персональными данными, решил перенести базу со своих серверов в облако? На одном из проектов мы сделали следующее: собрали бэкапы со всей сети, зашифровали и разложили их в облачные хранилища таким образом, чтобы никто, у кого появился доступ к одному хранилищу, ничего не смог бы расшифровать.
e. Масштабируемость
Всегда обсуждаем возможности масштабирования и требования к нему, затем уточняем время и стоимость развёртывания дополнительных мощностей.
f. Расширяемость
Масштабируемость и расширяемость имеют две стороны медали. Либо мы делаем проект быстро и недорого, но с ограничениями по объёму данных, скорости, мощности и другим показателям. Заказчик моментально выходит на рынок, получает обратную связь, меньше платит за инфраструктуру. Другой вариант развития событий, когда мы работаем на перспективу, но есть риск, что продукт взлетит не скоро, а затрат потребует больших. Конкуренты не дремлют. Они могут сделать всё быстро и дёшево, но без масштабируемости и расширяемости.
Кого в итоге выберет клиент в качестве субподрядчика? Того, кто сумеет показать, что понимает и сможет удовлетворить потребностям заказчика с учетом ограничений, в том числе финансовых.
Может случится такое, что заказчик запросит суперуниверсальное решение. Модель данных/архитектура/схема развёртывания в итоге окажется очень дорогой по себестоимости разработки (без видимого горизонта возврата инвестиций), потребует слишком много времени на реализацию и больших расходов на обслуживание и на инфраструктуру. Вот почему важно соблюсти баланс на старте.
g. Обслуживаемость
Один из наших заказчиков из Британии начинал работать с клиентами из своей тайм-зоны. Долгое время систему относительно безболезненно можно было останавливать на профилактику в ночное время. Потом у него появились пользователи в Австралии и Германии. Окно возможностей резко сократилось, а когда подключился Китай, окончательно захлопнулось.
Важно учитывать особенности системы: некоторые требуют доступности 99,999% времени, и больше чем на 8+ часов в год их не остановишь.
Выясните, кто будет заниматься установкой, обслуживанием и обновлением продукта. Если это админы со стороны заказчика, важно уточнить их квалификацию и предусмотреть соответствующий уровень сложности мониторинга, диагностики и обновления системы. Это требование соотносится с документированностью, речь о которой пойдёт ниже.
h. Эргономика
Выясняем требования к usability, accessibility, учитываем время на освоение системы среднестатистическим пользователем, простоту выполнения типичных сценариев, встроенную документацию (help). Если эргономика прорабатывается не на стороне клиента, то у нас этим занимаются UX-эксперты.
i. Графический дизайн
Опять же на старте оценки проекта выясняем, предоставляет ли заказчик готовый дизайн или отдаёт его в разработку нашей команде.
j. Документированность
Если установкой и настройкой решения занимаются сотрудники клиента, явно потребуется инструкция по установке. Здесь важно учитывать уровень квалификации операционного персонала. От этого будет зависеть подробность такой инструкции.
k. Лицензионная чистота
Что делать, если заказчик пожелал использовать фреймворк, на который у него нет лицензии? Либо покупать лицензии, либо искать альтернативы.
Однажды к нам обратилась компания, в брендбуке которой были платные шрифты, которые клиент не покупал. Пришлось объяснять юридические последствия. В итоге в брендбук были внесены изменения.
l. Соответствие стандартам и законодательству
Что нельзя обойти вниманием в оценке IT-проекта? ФЗ о персональных данных, обязательное лицензирование отдельных видов деятельности, фискальный учёт, расположение серверов и хранение данных в определённых юрисдикциях. Самые чувствительные в этом отношении проекты связаны с хранением и безопасностью персональных данных.
Вместо заключения
Наш чек-лист оценки IT-проекта может использоваться полностью или частично, в зависимости от конкретного запроса потенциального заказчика. Максимально точное понимание, что хочет создать заказчик, позволяет снизить неопределенность в проекте и повысить точность оценки. Усилия, потраченные на устранение неопределенности со стороны клиента, могут косвенно демонстрировать его готовность к дальнейшему сотрудничеству.
