ADD 2011: Отчёт Русецкого Георгия/Взаимоотношения заказчика и исполнителя на проекте

Ссылки сюда (3) →

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

Несмотря на то, что любой проект — совместное детище заказчика и разработчика, и никто не может сказать заранее, где возникнут проблемы, часто заказчик требует указания сроков и бюджета («Я не знаю, что мне нужно сделать, но мне нужны точные сроки и бюджет.»). Отсюда:

Цель разработчика — сделать заказчика счастливым за определённые срок и бюджет (при этом, как ни странно, не столь важна реализованная функциональность).

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

1. Кто клиент? А кто будет пользоваться? Часто это разные люди
2. Есть ли у него опыт заказной разработки?
3. Кто платит, кто ставит задачу, кто проверяет
4. Понимает ли он, зачем ему это?

В процессе разработки нужно активно взаимодействовать с заказчиком, стремясь достичь единого понимания целей, рисков, точности оценок. Крайне желательно знать, что можно урезать при необходимости, что можно перенести на потом (но при этом всё же сделать), то есть иметь представление о приоритетах задач. Также является важным документирование в процессе работы над проектом.

1. Vision — идея проекта (1 страница)
2. Требования (формируются в начале работы, страниц на 100, необходимо провести review с разработчиками и заказчиком), а также эскизы и use-cases.
3. Тест-план. По признанию докладчика, они сами обычно его не делают, если требования прописаны детально
4. План проекта
5. Deployment — диаграмма (чтобы не было проблем за день до сдачи, когда выясниться, что написанный софт не ставиться на оборудование заказчика)

Для контроля процесса разработки применяются различные инструменты. Некоторые из них, которые применяются в компании докладчика:

1. Трекинг прогресса разработки. Два прогресс-бара, один показывает готовность проекта по плану, другой — расход бюджета.
2. Регулярные релизы, ревью с клиентом
3. Сперва сделать вчерне всё, поскольку 30 % окажется не нужно, и нет риска застрять на полировке какой-нибудь фичи.

Если клиент не верит в предъявленные трудозатраты, можно:

1. Показать внутреннюю отчётность
2. Показать багтрекер
3. Распечатать код — по утверждению докладчика, он однажды так и поступил ;)

Что касается вопросов применяемой архитектуры и компонентов:

1. Знакомый инструментарий лучше, поскольку всё новое — непредсказуемо
2. Готовый сторонний код снижает стоимость и увеличивает риски
3. Повторное использование компонентов. Велика вероятность, что клиенту подойдёт ранее разработанное решение (его часть)
4. Интеграция с существующими системами — огромный риск

Сделать больше, чем просили — напрашиваться на проблемы. Особенно этого не любят западные заказчики («зачем вы сделали, то, что мы не просили, и кто за это заплатит?»)

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