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

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

2. Заказчики, получившие очень небольшой опыт, не дошедшие до масштабирования продукта.

3. Заказчики, не имеющие опыта в разработке продукта.

Для удобства на время обобщим пункты 2 и 3 в один - заказчики, не имеющие опыта успешного прохождения полного цикла жизни продукта.

Проблема, с которой мы сталкиваемся в 99% случаев при работе с такими заказчиками - несоответствие ожиданий и непонимание процесса разработки.

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

Используем классический подход и, опираясь на классиков, разделим продукт на 4 варианта. Под продуктом будем подразумевать ПАК - программно-аппаратный комплекс, в составе которого есть как программное обеспечение, так и "железо":

  1. "Гаражный продукт"
Это завершённое устройство, пригодное для запуска своим автором в тех условиях, в которых был разработан. И это именно тот продукт, который создаётся парой энтузиастов в гараже.

2. Продукт, который может использовать, тестировать, исправлять и развивать любой пользователь.

Этот вариант подразумевает необходимое документирование и тщательные тесты. Документация необходимо в том качестве, которое позволяет каждому вносить исправления и расширять её.

Я считаю, что для лучшего понимания лучше всего выражать всё в деньгах. Так вот этот вариант продукта стоит как минимум втрое дороже гаражного.

3. Продукт как компонент комплекса.

Чтобы стать частью какого-то комплекса, необходимо обеспечить корректное взаимодействие продукта с прочими элементам: требуемые для работы ресурсы и интерфейсы должны быть согласованы с другими частями комплекса, а также должны быть проведены все необходимые тесты во всех сочетаниях, которые могут встретиться. Тестирование здесь особенно важно, тк для него может потребоваться значительное время и ресурсы, потому что количество тестируемых случаев растёт экспоненциально.

Продукт как компонент комплекса стоит минимум втрое дороже гаражного варианта.

4. Системный продукт.

От гаражного отличается по всем вышеперечисленным пунктам. Соответственно, стоит минимум в 9 раз дороже гаражного. Однако именно он обладает наибольшей ценностью.

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

Команды разработчиков, не имеющие достаточного опыта работы над сложными системами или просто ведущие нечестную игру, не объясняют заказчику весь предстоящий процесс. А заказчик, в свою очередь, ждёт на выходе сразу системный продукт за минимальный бюджет и после первой же итерации разработки. В дальнейшем мы с вами рассмотрим разные этапы работы, но сейчас я хотел бы с помощью одной фразы аргументировать ту самую разницу в качестве: ещё по стандартам СССР на документирование закладывалось не менее половины бюджета проекта. И это совсем не из-за зашкаливающей бюрократии, а из-за большого объёма работы. Можно дополнить этот тезис ещё одним: прототип не стоит ничего, максимальную ценность имеет только документация. Иначе говоря, нужна повторяемость результата независимой третьей стороной, ведь только в этом случае результат работ становится отделим от тех, кто его создал.

Какие есть пути решения несоответствия ожиданий? Путь здесь всего один - разработчикам нужно вести адекватный диалог и честно объяснять все аспекты. В частности, одна из причин создания этого блога - помощь неопытным заказчикам.


В следующей статье мы подойдём к формированию одного из основных подходов к разработке и начнём с рассмотрения двух первых этапов, очень тесно связанных друг с другом - формирование требований и написание технического задания. Казалось бы, термин "техническое задание" всем уже набил оскомину, но всё же очень многие не неверно понимают его важность.
Автор: Алексей Павлюченко.