Желания не соответствуют бюджету

02.06.2015

Задача: разработать сайт, который состоит из кучи разделов и страниц, возможностей миллион, 5 личных кабинетов, 2 месяца на разработку, бюджет строго ограничен, условия устанавливаются заказчиком и могут меняться в любое время без предварительного согласования. Да это просто мечта любой веб-студии!

Предлагаю разобраться как обстоят дела на самом деле?

На данном этапе, не особо важно кто представляет интересы конечного заказчика: сам заказчик или его представитель, например, менеджер.

Важно признать, что 99.9% всех технических заданий в сфере веб-разработок, которые поступают от заказчика - это просто набор пожеланий или, как часто говорят, "хотелок". Даже если такая "хотелка" расписана на 4-10 листах и всё (как кажется заказчику) в содержимом структурировано до "не могу, держите меня крепче" - это ещё не техническое задание.

Взгляд со стороны заказчика такого чудо-ТЗ

1. Данное ТЗ - это идея идей! Данное ТЗ - это верх совершенства! Данное ТЗ идеально во всём! Данное ТЗ самое "ТэЗэшное" из всех ТЗ!

2. Мы платим, значит - мы руководим процессом.

3. Если мы пришли к вам, то мы - ваши клиенты! А клиент всегда прав!

Это до боли знакомая картина всем аутсоурсинговым компаниям и организациям разного масштаба. Особенно боль вызывает ситуация, когда со слезами делаешь заведомо неправильно, так как правильный вариант до заказчика донести не удаётся. Вот такая правда! Сначала объясняем, потом плачем, но делаем так, как хочет заказчик.

Менеджмент, конечно, никто не отменял, но есть определённые законы, которые работают вне зависимости от мнения заказчика или возможностях исполнителя.

Приведём очень грубый пример, который фактически не возможен, но наиболее контрастно отражает суть проблемы. Предположим, что задача заключается в рисовании кругов с использованием системы, которая умеет рисовать только квадраты. Заказчик не понимает в чем проблема рисовать круги, а менеджеры со стороны исполнителя не видят проблемы в задаче "нарисовать круг". Наклёвывается проблема, которая станет очевидна в процессе реализации, но абсолютна не ясна первоначальным контактёрам. Как быть?

Как сказал Стив Джобс: "Мы нанимаем умных людей для того, чтобы слушать их, а не говорить им, что они должны делать". Тут тоже делема, ведь мир устроен так, что каждый считает себя умнее другого. Правда, это работает до определённого момента. Основная, задача - не изменять концепцию самих процессов и подходов, то есть срабатывает закон, который говорит: "любые капризы за ваши деньги". Если заказчик хочет экспериментировать, то это его право. Если бюджет позволяет, то можно экспериментировать сколько душе угодно. Есть только одно, большущее НО: заказчики в своём большинстве считают, что эксперимент - это не работа, что тут не требуется никаких ресурсов, что к бюджету на проект количество экспериментов отношения никакого не имеют. И, вообще, пропускают это мимо себя, даже при прямом и преждевременном предупреждении о дополнительных затратах. Тут важно услышать друг друга изначально.

Взгляд со стороны потенциального исполнителя проекта по такому чудо-ТЗ

1. Клиент явно не в ту сторону пошёл. За определённую оплату подкорректируем аля-ТЗ.

2. Мы много чего делали, с этим проектом однозначно справимся.

3. С таким списком пожеланий, заказчик готов оплачивать этого "Франкенштейна"


Разбор по-пунктно

по п.1 Заказчик (или его представитель) физиологически и психологически очень тяжело воспринимает информацию о своих ошибках и уж точно не собираются платить дополнительные деньги за корректировку собственных пожеланий.

по п.2 Опыт не может быть однополярным. Реальная работа подразумевает как положительный опыт так и отрицательный. Отрицательный опыт говорит нам, что у нас есть представление о том как точно не нужно делать. И очень подозрительно когда у таких гигантов как Apple и Microsoft есть отрицательный опыт, а у мелких или средних IT-компаний этот опыт исключительно положительный.

по п.3 Не стоит забывать, что подавляющее число розничных заказчиков не имеют большого бюджета. С учётом того, что список пожеланий может быть большой, планируемый бюджет, как правило, способен покрыть от 50% до 75% "хотелок". И уж точно не расчитан на процесс рефакторинга, даже на стадии согласования.

Готовность заказчика принять изменения первостепенных пожеланий мала. Дополнительно финансировать уже проделанную работу и финансировать эксперименты в случае изменений требований - это будет новостью для заказчика и абсолютно нормальным явлением для представителя компании-реализатора.

Пропасть в подходах вызавает разрыв между согласованностью задач и бюджетов.

Причины технических разногласий

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

Ожидает завершения


Возврат к списку