Итоги Интерактива «Заказчик вас использует. Что делать?»

Итак, подводим итоги интерактива, который прошел в Днепропетровске 3.02, в SpaceHub.

Что обсуждали и какие можно запомнить рекомендации?

Обсудили случаи:

  • Fixed Price проекты с распределенными командами, когда на стороне заказчика команда/разработчик работает part time;
  • Fixed Price проекты с любимым заказчиком-StartUp-ером, который постоянно совершенствует свой продукт, что для украинской команды выливается в поток изменений;
  • Заказчик, который пытается защитить себя, устанавливая «вознаграждения» и «штрафы»;
  • Заказчик, который меняет спецификации после согласования стоимости проекта.

p01

Обсуждение, которое особенно оживилось во второй части мероприятия, позволило выработать некоторые р̲е̲к̲о̲м̲е̲н̲д̲а̲ц̲и̲:

а) ̲F̲i̲x̲e̲d̲ ̲P̲r̲i̲c̲e̲ ̲п̲р̲о̲е̲к̲т̲ы̲ — в Устав проекта должны быть заложены правила работы с изменениями ( ̲C̲h̲a̲n̲g̲e̲ ̲R̲e̲q̲u̲e̲s̲t̲s̲). Заказчик (особенно StartUp-ер) не всегда понимает как его изменения влияют на объем работ для подрядчика. Поэтому необходимо проговорить до заключения контракта, что изменения — это не просто добавление/изменение кода, но и время на анализ влияния на уже существующий функционал и архитектуру продукта. В Fixed Price проекте заказчик должен быть готов на замену/изъятия функционала и на доп. соглашения.
p02
б) ̲Р̲а̲с̲п̲р̲е̲д̲е̲л̲е̲н̲н̲ы̲е̲ ̲к̲о̲м̲а̲н̲д̲ы̲ — (и особенно команды, где для одной из команд это не приоритетный проект или один (или более) из подрядчиков — фрилансер):
— нужно быть очень осоторожными с выбором типа контракта. Fixed Price (четко оговоренная цена за проект(!)) чреват финансовыми потерями, в случе, если для партнера это не ключевой проект. Рекомендуемый тип контракта — Выделенная команда (Dedicated Development Team);
— нужно четко разделять задачи для разных команд и вводить инструментарий, который позволяет отслеживать статус всех задач во всех командах, рассчитывать время «простоя» между задачами.
p05
в) Заказчик устанавливает ̲»̲ш̲т̲р̲а̲ф̲ы̲»̲ ̲и̲ ̲»̲в̲о̲з̲н̲а̲г̲р̲а̲ж̲д̲е̲н̲и̲я̲»̲:
— прежде всего, стоит показать свой профессионализм и выяснить с заказчиком, каковы критерии и кто делает оценку, объективна ли она;
— выяснить, зачем именно нужна эта мера, и возможно вы сможете удовлетворить потребность заказчика другим путем 🙂
— возможен также вариант — выставить свои критерии к качеству работы заказчика (вы же партнеры 😉 )
Любой из этих подходов может привести либо к тому, что вы начнете серьезно задумываться о метриках (и постепенно это даст позитивный эффект для вашего бизнеса), или заказчик откажется от этой «уловки». В любом случае, в глазах заказчика ваш авторитет вырастет!

г) ̲У̲п̲р̲а̲в̲л̲е̲н̲и̲е̲ ̲к̲о̲н̲ф̲и̲г̲у̲р̲а̲ц̲и̲я̲м̲и̲ — единая система учета версий рабочих продуктов — лучший способ избежать «подлога». «Рабочие продукты» — это не только код или инсталляционный пакет, но и все результаты нашей работы, которые мы согласовываем с заказчиком. Это могут быть — спецификации (ТЗ), test cases и др.

д) Одно из самых больших упущений директоров — отсутствие коммуникаций между отделами (в частности — межде Sales и командой разработки) понимания общей цели, понимания интересов бизнеса и специфики работы друг друга. Тут можно только посоветовать совместную работу 🙂 и ей тоже нужно учиться.

е) И последнее, но не самое незначительное — нужно выстраивать отношения с заказчиком (и с коллегами).
p04
Большинство из озвученных проблем можно решить на предконтрактном этапе, о чем мы и будем говорить на нашем тренинге 13 февраля.
Для участников семинара — специальные условия.

Спасибо большое Антону, Вере, Наташе и Наташе, Ярославу, Дмитрию и другим активным участникам семинара!
p03

Tags: , , ,

Comments are closed.