Привет!
В данной статье мы рассмотрим кто же такой заказчик, как с ним правильнее работать и зачем вообще нужна обратная связь с ним.
Заказчик - это не страшный человек, который любит наблюдать как ты переписываешь проект.
Заказчик - это всего человек, которому нужно решение своей проблемы, ради чего он пришел к тебе. Он может не глубоко и поверхностно разбираться в том, что он хочет получить. Но ради этого он и пришел к тебе, чтобы ты помог ему с этим!
Именно поэтому дальше мы рассмотрим как правильно работать с заказчиком.
Многие команды в работе с заказчиком начинают совершать ошибки, которые ведут к увеличению непонимания между ними и заказчиком, что ведет к растягиванию сроков, переписыванию половины проекта и так далее. Для этого мы подготовили схему работы с заказчиком, которая сможет помочь вам максимально качественно выполнить свою работу.
Данная схема представляет из себя ряд вопросов, на которые вы должны отвечать во время работы с проектом заказчика
и с помощью которых вы сможете более правильно понять чего хочет заказчик.
Какую пользу мы приносим для заказчика?
(Какую проблему решаем?)
Какая целевая аудитория получит выгоду исходя из пользы для заказчика?
(Какие целевые группы получат выгоду после решения проблемы заказчика?)
Какие альтернативные способы решения проблемы заказчика?
(Как можно по другому решить проблему заказчика? Изменение бизнес-процессов, найм персонала, покупка готовых решений и т.п.)
В виде каких функций может быть реализована польза для заказчика?
(Как функции приложения трансформируются в решение проблемы или “нанесение” пользы заказчику. Какая проблема основная, какой дополнительный профит можно получить).
Обратная связь это важный элемент в работе с заказчиком.
Обратная связь позволяет команде более чётко вести проект, корректировать его в зависимости от потребности заказчика.
Обратную связь нужно получать в том случае, если заказчик до конца не может определиться в каком виде он хочет видеть финальный продукт,
если существует множество вариантов реализации одного и того же функционала, если вам необходимо продемонстрировать в каком виде вы реализовали определенный этап вашего проекта.
Резюме - если есть какие-либо элементы в вашем проекте, которые являются специфическими и могут играть важную роль для вашего заказчика или же если вы проходите важный этап в разработке вашего проекта и вам нужно одобрение, то обратная связь с заказчиком необходимо.
Обратная связь бесполезна в том случае, если у вас на руках имеется четко выверенное Техническое Задание и вас нет возможных глобальных отстранений от него, если заказчик не разбирается в тонкостях реализации и у него нету особых предпочтений по проекту, то есть "главное чтобы работала, остальное не важно".
Резюме - если вашему заказчику важен лишь конкретный функционал, который был расписан заранее и возможных изменений в течении разработки проекта не предвидиться, то обратная связь становиться менее актуальной.
Для того, чтобы добиться максимальной эффективности в получении обратной связи от заказчика необходимо правильно выстроить общение с ним.
Для лучшего понимания интервьюирования заказчика вы можете ознакомиться с данной статьей -> "Интервьюирование заказчика"
Обратная связь это мощный инструмент для корректировки вашего проекта. Для того, чтобы извлечь пользу от обратной связи необходимо уметь правльно интервьюировать заказчика,
а так же понимать, на какие вопросы вам необходимо получить ответы и к каким элементам вашего проекта у закачика могут появиться вопросы и правки.
В зависимости от схемы разработки обратная связь начинает играть по разному.
Наилучшей схемой для проекта, который во многом зависит от обратной связи с заказчиком будет ме
Вопрос разграничения зоны ответственности между заказчиком и исполнителем является очень тонким и сложным.
Сторонам важно разграничить те или иные обязанности, чтобы каждый понимал что он обязан предоставить и реализовать для другой стороны.
Данную тему проще всего рассмотреть на примере имеющихся договоров IT компаний.
Рассмотрим вырезку ответственности сторон из шаблона договора на разработку программного обеспечения определенные законодательством РФ.
Рассматривая данный договор, можно увидеть простое взаимотношение между Заказчиком и Исполнителем:
За использование различного стороннего ПО ответственность лежит на Исполнителе
При наличии всевозможных ошибок в ПО и при не соответствии ПО с Техническим заданием Исполнитель должен будет исправить их за свой счёт.
Если Заказчик нарушит договор и будет использовать продукт в получении доходов, то Исполнитель вправе запросить компенсацию не меньше размера таких доходов Заказчика.
Но данные ответственности, являются лишь частью того, что может быть при взаимоотношении Заказчика и Разработчиков.
Очень важно проговорить в начале работы зоны ответственности каждой стороны, иначе в последующем у той или другой стороны могут возникнуть проблемы различного уровня.
Пример того, что может быть если не обосзначить зоны ответственности:
- При разработки сайта в последующем Заказчик может расторгнуть договор и лишить финансов Исполнителя, если его сайт не набрал достаточную популярность, а в договоре не было указано, что ответственность за рекламу и "раскрутку" сайта был ответствененн Заказчик.
- Во время создания приложения не было обозначено, что должны быть оговорены Исполнителем использования третих лиц и после закрытия договора у Заказчика появились проблемы со сторонней фирмой, которая требует лицензирования.
Определение зоны ответственности - это важный элемент любого взаимоотношения между Заказчиком и Разработчиком.
Все это необходимо обозначить ещё на стадии обсуждения работы с заказчиком, для того чтобы не возникало ситуаций, в которой из-за не уточнения во время составления договора одна из сторон подставляла другю и такая ситуация приводила к расторжению договора и т.д.
Такая же ситуация может возникнуть и на уровне студенческих проектов, если не были обговорены некоторые детали проекта, после чего студенческая команда не получает зачет из-за не реализованных частей своего проекта, за которые она была ответственна.
Давайте рассмотрим данную схему в виде ромба, на вершинах которого будут расположены "Денги", "Качество", "Функционал" и "Время".
Данная схема на самом деле представлять из себя достаточно простой пример схемы распределение ресурсов проекта.
При общении с заказчиком вы должны сбалансировать на данном графике все ресурсы, чтобы это удовлеторяло вас и закачика.
К примеру - если заказчик, что ему необходим полный функционал и за минимальное время, то это будет значить то, что тут будет необходимо вложить больше денег или не расчитывать на высокое качество.
Данная схема является удачным примером возможного распределение ресурсов при разработке какого-либо проекта. С помощью этой схемы можно обозначить заказчику зависмость различных факторов от других и помочь вам избежать нереалистичных запросов со стороны заказчика.
