Аннотация
- Докладчик
- Дмитрий Завалишин
В докладе пойдет речь про взаимоотношения заказчика и исполнителя на проекте. Будет проведен анализ рисков и традиционных (на наш взгляд) проблем в отрасли.
Видео
- Скачать
http://ftp.linux.kiev.ua/pub/conference/peers/addconf/2011/1a9-interaction-with-customer-zavalishin.avs.avi
Для этого доклада нужен подкаст (аудиозапись)?
Примечания и отзывы
Дмитрий Завалишин о взаимотношениях заказчика и исполнителя. Хотел бы я услышать его лекцию на курсе по project management на ФИТе, читает захватывающе и по живому. ©
Дмитрий Завалишин рассказал о том, как они это делают в DZ (DigitalZone). Вполне согласен :). Было интересно посмотреть на живого гуру (блог dz.ru был, пожалуй, первым IT-шным блогом, который я начал читать еще в году ~97) и создателя PhantomOS.
©
О программировании там не было ровным счетом ничего, но всем понравилось - уверен, на 99% из-за личности / харизмы самого DZ. ©
День закончил в позитивном ключе Завалишин. Сам он пожаловался, что не уверен в актуальности темы, однако, на мой взгляд, волнения были излишни. Довольно жирные выжимки из опыта борьбы с заказчиком было крайне интересно получить.
©
Дмитрий Завалишин делился со сцены своим опытом работы с заказчиками. Опыт бесценный, но не знаю насколько он применим без собственного выстраданного опыта. То о чем говорил Дмитрий - анализ требований заказчика, который не всегда точно знает чего он хочет и способность понять что ему нужно и убедить в этом - это же требует мощной интуиции и опыта работы с людьми. А такая интуиция появляется только с собственным опытом. В любом случае доклад был мегаинтересный и Дмитрия всегда интересно слушать, будь это доклад про Фантом ОС (отдельный респект!) или рассказ о собственном жизненном опыте.
©
Дмитрий Завалишин на этой конференции рассказывал не про Фантом ОС (которая постепенно развивается, это из разговоров в кулуарах), а про менеджерскую часть своей деятельности.
Которая, думаю, весьма успешна — если остается время и силы на Фантом ОС.
Их компания занимается заказной разработкой, и Дмитрий обобщал опыт. Как он сказал, это первый его доклад по такой теме. В целом мои впечатления — это очень сокультурно нам, нашим мыслям. И — мы соразмерны по уровню, что редкость. В докладе был определенный экстремизм, хотя очень мне импонирующий — когда мы делаем не так (что бывает не часто), в меня скребут кошки. Хотя у них компании — несколько другая бизнес-модель, при этом проекты — сопоставимые с нашими, 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 сделает что нужно, еще день будет развивать и надо остановить. Это можно понять только на опыте постфактум, и надо это делать.
Сравнение с инхаузом. В том числе — коэффициент года. Налоги. Инхауз обычно не считает затраты админов, которые часто закрывают деплоймент. Почитать документацию — тоже реальная работа.
Как выбирают подрядчика.
- Опыт. Внятность по видам проекта
- Адекватность. Решение задачи клиента, а не свою
- Надежность как предсказуемость итогов. Очень важно.
- Цена. Хотя это в разных проектах по-разному.
Вопрос — фикс или тм. У них в основном фикс. ТМ — мечта, но расслабляет. А еще при ТМ клиент тоже начинает париться на тему, что он действительно хочет.
Большой рассказ про взаимоотношения заказчика и исполнителя в сфере разработки ПО, богато украшенный примерами из жизни.
Несмотря на то, что любой проект — совместное детище заказчика и разработчика, и никто не может сказать заранее, где возникнут проблемы, часто заказчик требует указания сроков и бюджета («Я не знаю, что мне нужно сделать, но мне нужны точные сроки и бюджет.»).
Отсюда:
Цель разработчика — сделать заказчика счастливым за определённые срок и бюджет (при этом, как ни странно, не столь важна реализованная функциональность).
Перед тем, как браться за разработку, нужно выяснить бизнес-задачу заказчика, возможно она решается значительно проще, чем видится заказчику. Необходимо сказать об этом последнему — иначе велик риск неудовлетворения заказчика от выполненной работы. В начале проекта необходимо выяснить:
- Кто клиент? А кто будет пользоваться? Часто это разные люди
- Есть ли у него опыт заказной разработки?
- Кто платит, кто ставит задачу, кто проверяет
- Понимает ли он, зачем ему это?
В процессе разработки нужно активно взаимодействовать с заказчиком, стремясь достичь единого понимания целей, рисков, точности оценок. Крайне желательно знать, что можно урезать при необходимости, что можно перенести на потом (но при этом всё же сделать), то есть иметь представление о приоритетах задач.
Также является важным документирование в процессе работы над проектом.
- Vision — идея проекта (1 страница)
- Требования (формируются в начале работы, страниц на 100, необходимо провести review с разработчиками и заказчиком), а также эскизы и use-cases.
- Тест-план. По признанию докладчика, они сами обычно его не делают, если требования прописаны детально
- План проекта
- Deployment — диаграмма (чтобы не было проблем за день до сдачи, когда выясниться, что написанный софт не ставиться на оборудование заказчика)
Для контроля процесса разработки применяются различные инструменты. Некоторые из них, которые применяются в компании докладчика:
- Трекинг прогресса разработки. Два прогресс-бара, один показывает готовность проекта по плану, другой — расход бюджета.
- Регулярные релизы, ревью с клиентом
- Сперва сделать вчерне всё, поскольку 30 % окажется не нужно, и нет риска застрять на полировке какой-нибудь фичи.
Если клиент не верит в предъявленные трудозатраты, можно:
- Показать внутреннюю отчётность
- Показать багтрекер
- Распечатать код — по утверждению докладчика, он однажды так и поступил ;)
Что касается вопросов применяемой архитектуры и компонентов:
- Знакомый инструментарий лучше, поскольку всё новое — непредсказуемо
- Готовый сторонний код снижает стоимость и увеличивает риски
- Повторное использование компонентов. Велика вероятность, что клиенту подойдёт ранее разработанное решение (его часть)
- Интеграция с существующими системами — огромный риск
Сделать больше, чем просили — напрашиваться на проблемы. Особенно этого не любят западные заказчики («зачем вы сделали, то, что мы не просили, и кто за это заплатит?»)
После завершения проекта нужно собраться и проанализировать сделанное с точки зрения архитектуры, финансов, сроков, навыков, коммуникаций и организации.
