Разрабатывая требования, мы упускаем один важный момент. Заказчик не понимает особенностей развертывания разработанного ПО, и на этом моменте возникает ряд недопониманий при развертывании. Чтобы этого избежать, необходимо заставить заказчика трезво оценивать все особенности при развертывании ПО.
Прочитав данную статью вы больше никогда не столкнётесь с проблемами недопонимания со стороны заказчика в процессе развертывания программного обеспечения.
Первое правило работа с заказчиком по обсуждению особенностей развертывания
Дорогой мой читатель, напоминаю тебе известную фразу “Если вы смогли записать проблему на бумаге, то на 50% она уже решена”. Это основной тезис, который должен сопровождать вас при общении с заказчиком. Рассказывайте и обсуждайте все, что касается развертывания.
Важно понимать, что заказчик ничего не знают о вашей работе и в его понимании вы все сделайте так, как нужно. В том числе это касается развертывания программного обеспечения, которое вы итоге разработайте. Проще говоря, заказчик думает, что его ПО, будет работать на волшебном эфире, за который не придется платить и ничего в системе никогда не сломается.
Необходимо объяснять заказчику самые элементарные вещи от того, что оказывается нужно купить сервера, где будет размещаться его ПО, до поддержки. Заказчик рассчитывает, что он заплатит вам деньги за разработку, а там будет все включено.
Следовательно, первое правило будет звучать так:
- если в процессе общения с заказчиком у вас промелькнула мысль “а этот момент он и сам прекрасно знает”, значит на этом нужно заострить больше всего внимания и объяснять дольше всего.
Второе правило при обсуждении с заказчиком особенностей развертки ПО
Будьте учителем для заказчика.
Это означает, что вам необходимо объяснять сложные вещи простым языком. Помните, что заказчики в большинстве своём не из мира информационных технологий и для них все это непонятно.
Сам факт того, что заказчик осознал необходимость прийти к вам за разработкой, это уже большой шаг, но только первый. Представьте заказчика ребенком, которого нужно научить читать. С чего вы начнете? Конечно же с изучения алфавита. Затем научите собирать звуки из согласных и гласных, а потом подойдете к словам. Лишь потом ребенок сможет читать предложения. Все всем этом четко прослеживается одно слово детализация.
Заказчик является ребенком, которого нужно научить читать мир IT. И конечно же нужно придерживаться принципа детализации при обсуждении особенностей развертывания.
В разделе "Особенности развертывания" в документе о концепции и границах необходимо детализировать общие составляющие развертывания на разделы:
- Технические требования и зависимости, связанные с развертыванием системы. В данном подразделе четко опишите информацию о необходимых технических ресурсах, совместимости с другими системами и зависимостях от внешних компонентов;
- Процедуры установки и настройки. Здесь следует описать шаги по установке и настройке системы, включая необходимое программное обеспечение и конфигурационные параметры;
- Планы масштабирования и обновлений. Этот раздел должен включать информацию о возможностях масштабирования системы в будущем, а также процедуры обновлений и поддержки.
Если читая эти пункты вы подумали “ну и что здесь такого? Это и так понятно, стандартная вещь”, то в этом и состоит ваша будущая проблема. Все это понятно для специалистов, а заказчики понимают другие вещи, например сколько денег они вам заплатили за разработку, а вы приходите и просите еще какие-то деньги на сервера и поддержку.
Помните, что в глазах заказчика вы человек, который хочет забрать его деньги и при этом каждый раз рассказывает про какие-то новые проблемы. Чтобы этого не происходило вам нужно учить заказчика в процессе разработки требований.
Таким образом, второе правило будет звучать так:
- обучай заказчика базовым вещам в сфере IT путем детализации всех этапов развертывания. Подготовь заказчика на этапе разработки требований к тому, что будет в процессе развертывания.
Третье правило при разработке требований
Не бойся тратить много времени на обсуждение и согласование с заказчиком.
Особенности развертывания могут быть разные и не пытайтесь действовать по какому-то шаблону, создавайте свой шаблон исходя из особенностей разрабатываемого ПО.
Процесс общения с заказчиком при обсуждении особенностей развертывания должен происходить в формате предпосылка ➡ следствие.
Никогда не обсуждайте сразу следствие, в первую очередь покажите заказчику предпосылку, которая в итоге приведет к следствию. Например, обсуждая технические требования ошибкой будет сразу указать минимальные требования.
Плохо (только следствие):
- для вашей платформы понадобятся минимальные требования к серверу N, который выльется в сумму аренды S.
Почему это плохо? Напоминаю, заказчик видит в вас только расходы и когда вы говорите одну сумму, то его первая реакция максимально сократить расходы. Потом вам придется тратить много времени на то, чтобы приводить свои неубедительные доводы о том, что система будет работать некорректно. Я думаю, что вы уже не раз сталкивались с тем, что заказчик не хочет платить, хочет очень дешево и сердито, поэтому его нужно готовить.
Хорошо (предпосылка, затем следствие):
Предпосылка:
- в вашей платформе есть определенная особенность, которая вытекает из совместно разработанных требований. Вы указали на то, что данные ваших клиентов должны храниться только на ваших сервера. Исходя из этого возрастает требование не только на объемы памяти, но и на вычислительные мощности, т.к. на поиск и обработку данных будут уходить дополнительные ресурсы, поэтому нужно установить такой минимум, чтобы при работе с платформой ваши клиенты не испытывали дискомфорта из-за дефицита вычислительной мощности сервера.
Следствие:
- исходя из этих потребностей системы, мы подобрали для вас минимальные требования удовлетворяющие запросы комфортной работы системы для N количества пользователей и стоить аренда такого сервера будет S рублей. Как вы понимаете лучше брать с запасом, т.к. клиентов в перспективе может быть больше, но решение принимать вам
Заметили разницу в подходе данной конструкции от простого следствия? Мы даем заказчику прозрачное толкование того, на что он должен потратить свои деньги. Также мы вешаем на него часть ответственности за то, что он сам указал ранее в требованиях. Из этого вытекает такая-то потребность, которая покрывается, посредством - и вот только в этот момент вы выдаете следствие.
Обратите внимание, что даже в следствии нужно быть максимально прозрачным и обозначить, что выбор должен сделать сам заказчик и вы не покушаетесь на его деньги. Все решения о затрате он принимает сам.
Да, на обсуждение будет уходить много времени, но в этом и состоит третье правило:
- чем больше времени вы потратите на разработку требований, тем меньше проблем будет на этапе реализации.
Заключение
Безусловно кодирование является главным навыком программиста. Но писать код без нормальных требований, это как ехать по неизвестному маршруту, в неизвестной местности. Я умею водить машину, я еду полностью соблюдая ПДД и у меня полный бак топлива. Но достаточно ли этого набора знаний и инструментов для того, чтобы доехать до необходимого места? Конечно же нет, нужен четки маршрут.
Правильно разработанные требования к ПО являются тем самым построенным маршрутом в вашем навигаторе по программированию и без него все ваши усилия, это всего лишь репутационные потери в момент развертывания и сдачи заказчику разработанного ПО. Ваши пользователь оценят программу по её удобству, а не потому, что вы знаете классные и современные фреймворки.
Поэтому подписывайся на канал, чтобы ничего не пропустить.
