Максим Цепков - отчет об ADD-2011/Взаимоотношения заказчика и исполнителя на проекте

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

Дмитрий Завалишин на этой конференции рассказывал не про Фантом ОС (которая постепенно развивается, это из разговоров в кулуарах), а про менеджерскую часть своей деятельности. Которая, думаю, весьма успешна — если остается время и силы на Фантом ОС.

Их компания занимается заказной разработкой, и Дмитрий обобщал опыт. Как он сказал, это первый его доклад по такой теме. В целом мои впечатления — это очень сокультурно нам, нашим мыслям. И — мы соразмерны по уровню, что редкость. В докладе был определенный экстремизм, хотя очень мне импонирующий — когда мы делаем не так (что бывает не часто), в меня скребут кошки. Хотя у них компании — несколько другая бизнес-модель, при этом проекты — сопоставимые с нашими, 20-30 человеко-лет. Они делают ставку на точные спецификации, исполняемые разработчиком. Мы так работали примерно лет 6-7 назад, а потом — сменили парадигму, приняв что квалифицированный разработчик сам способен сделать приличную часть постановки, если понимает бизнес-часть, а понимать ее в многолетних проектах он будет.

Дальше я оставляю практически все заметки в исходном виде.

Начало — традиционное, 80 % провалов.

• Исполнитель не умеет вынимать требования
• Заказчик не знает, что ему нужно
• Проект реально сложен и действительно не поддается оценке заранее

Ответ программерский — виноват заказчик.

Заказ по умолчанию — «на сайте должен быть форум». Когда дальше работают аналитики — у него просыпается фантазия, он хочет многое. Только потом — у него нет денег, и вообще это ему не нужно. Они стараются урезать хотелки, направить на важное, решение реальных проблем.

Российский заказчик склонен снимать ответственность. Реально проект — совместная деятельность. Гарантировать от проблем не может никто.

Цели.

• Счастье клиента
• В срок
• В бюджет

Бывают проекты только со счастьем клиента — сам проект провалился, зато дал заказчику альтернативное видение ситуации, с которым он развивается дальше.

Функциональность в списке целей отсутствует — потому как реально это самая гибкая часть. Всегда что-то уходит, что-то приходит, в общем случае не нужно ничего.

Заказчик должен сказать, как он будет на проекте зарабатывать деньги (или как проект сделает его счастливым, это синонимы!). Если уяснив бизнес-задачу поняли, что можно сделать проще — не скрывайте. Надо выйти в бизнес-минимум реализации, на котором можно пробовать.

Если клиент хочет неоправданно сложный проект — отказывайтесь.

Важно — нужны конечные пользователи, стейкхолдеры, а не только директор.

Ситуация: «директор посмотрел и сказал — все переделать» +30 % переработки. И Менеджер не может принять проект. Реально, это проблема Разработчиков — надо на входе понять, кому сдавать.

Но даже если пользователи принимать не будут — они потом будут пользоваться и вас материть — оно вам надо?

Лезьте в бизнес-схемы клиента. Понимайте зачем.

Узнайте бюджет. В России тяжело, вопрос про деньги «не приличный». Ты хочешь узнать, сколько у меня денег и потратить? Да, хочу — все равно проект будет дороже и дольше, и эти деньги мы потратим — так что скажи сразу, мы разумнее спланируем.

Коммуникации

• единое понимание целей
• единое понимание рисков
• единое понимание точности оценки

Если про цели как-то есть, то 2 и 3 — реже.

Желательно

• знать, что можно урезать
• знать, что можно перенести попозже
• иметь представление о приоритетах задач

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

Пример. Отложить оплату части проекта — на поддержку.

Бумажки

• Vision одна страница в первые 2 дня. Вехи
• Требования. В начале, 100 страниц, ревью с клиентом и разработчиком. Эскизы и usecase
• Тест-план, если требования детальны может отсутствовать
• План проекта. Реально работает при детализации 2-3 часа на задачу, но полезен даже если в нем 3 строки
• Деплоймент-диаграмма — чтобы не было сюрпризов на сдаче

Важно. Клиенту требования надо структурировать по бизнес-областям. А программист часто хочет получить кусок на код, а остальное не слишком читать. Я: Это видение у нас было лет 5 назад. Работает и востребовано когда программисты не погружаются в бизнес-область. На их потоке проектов это оправдано.

Инструменты.

• Трекинг процесса. Два ползунка — сколько съели объема (фич, например) и сколько бюджета.
• Регулярные релизы, ревью с клиентом, прогоны.
• Сначала сделать все, потом полировать. Все равно, треть не нужно — зачем его полировать. И нет риска застрять на полировке и не сделать минимального ядра.

Я: Это правильно — делать по фрагментам надо вчерне, а не до совершенства. Но делать, а не прототипы.

Что делать когда клиент не верит. Например, две задачи, он считает, что оно почти одно и то же, а стоимость — разная. У них разработчики в конце недели пишут лог (тайсминг) в свободной форме. Их можно предъявить, и нельзя подделать, это в крупном. А сейчас научились фиксировать время на баги. Это все можно показать клиенту, объяснить и убедить.

Архитектура и компоненты

• Знакомый инструмент — лучше. Незнакомый инструмент снижает предсказуемость, а это важнее сроков.
• Готовый код третьей стороны снижает стоимость, но повышает риск — если компонента не знакомая. Объясните это клиенту.
• Клиенту никогда не нужно именно то. Ему нужно «нечто похожее». Если есть наработки — можно использовать готовое. Использование своего кода — снижает и цену и риск.
• Интеграция с существующими системами — отдельный проект. Лучше не пытайтесь fixprice.

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

После 90 % бюджета получается нормальный продукт. Хороший — будет после еще 90 %. А третьи 90 % позволят сделать блестящим. Поэтому надо сделать вчерне за 30 % времени и бюджета — тогда есть шанс получить блестящее за остатки. Хотя у них не слишком работает.

Очень важно — постанализ по проекту.

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

Оценка одного «за три дня» — значит за 5-6. А другого — за 2 сделает что нужно, еще день будет развивать и надо остановить. Это можно понять только на опыте постфактум, и надо это делать.

Сравнение с инхаузом. В том числе — коэффициент года. Налоги. Инхауз обычно не считает затраты админов, которые часто закрывают деплоймент. Почитать документацию — тоже реальная работа.

Как выбирают подрядчика.

• Опыт. Внятность по видам проекта
• Адекватность. Решение задачи клиента, а не свою
• Надежность как предсказуемость итогов. Очень важно.
• Цена. Хотя это в разных проектах по-разному.

Вопрос — фикс или тм. У них в основном фикс. ТМ — мечта, но расслабляет. А еще при ТМ клиент тоже начинает париться на тему, что он действительно хочет.