|
|
| Строка 35: |
Строка 35: |
| | Дмитрий Завалишин делился со сцены своим опытом работы с заказчиками. Опыт бесценный, но не знаю насколько он применим без собственного выстраданного опыта. То о чем говорил Дмитрий - анализ требований заказчика, который не всегда точно знает чего он хочет и способность понять что ему нужно и убедить в этом - это же требует мощной интуиции и опыта работы с людьми. А такая интуиция появляется только с собственным опытом. В любом случае доклад был мегаинтересный и Дмитрия всегда интересно слушать, будь это доклад про Фантом ОС (отдельный респект!) или рассказ о собственном жизненном опыте. | | Дмитрий Завалишин делился со сцены своим опытом работы с заказчиками. Опыт бесценный, но не знаю насколько он применим без собственного выстраданного опыта. То о чем говорил Дмитрий - анализ требований заказчика, который не всегда точно знает чего он хочет и способность понять что ему нужно и убедить в этом - это же требует мощной интуиции и опыта работы с людьми. А такая интуиция появляется только с собственным опытом. В любом случае доклад был мегаинтересный и Дмитрия всегда интересно слушать, будь это доклад про Фантом ОС (отдельный респект!) или рассказ о собственном жизненном опыте. |
| | [http://yggdraa.livejournal.com/2009.html ©]</blockquote> | | [http://yggdraa.livejournal.com/2009.html ©]</blockquote> |
| | + | |
| | + | {{include-review|Максим Цепков - отчет об ADD-2011/Взаимоотношения заказчика и исполнителя на проекте}} |
| | | | |
| | <references/> | | <references/> |
Дмитрий Завалишин на этой конференции рассказывал не про Фантом ОС (которая постепенно развивается, это из разговоров в кулуарах), а про менеджерскую часть своей деятельности.
Которая, думаю, весьма успешна — если остается время и силы на Фантом ОС.
Их компания занимается заказной разработкой, и Дмитрий обобщал опыт. Как он сказал, это первый его доклад по такой теме. В целом мои впечатления — это очень сокультурно нам, нашим мыслям. И — мы соразмерны по уровню, что редкость. В докладе был определенный экстремизм, хотя очень мне импонирующий — когда мы делаем не так (что бывает не часто), в меня скребут кошки. Хотя у них компании — несколько другая бизнес-модель, при этом проекты — сопоставимые с нашими, 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 сделает что нужно, еще день будет развивать и надо остановить. Это можно понять только на опыте постфактум, и надо это делать.
Сравнение с инхаузом. В том числе — коэффициент года. Налоги. Инхауз обычно не считает затраты админов, которые часто закрывают деплоймент. Почитать документацию — тоже реальная работа.
Как выбирают подрядчика.
- Опыт. Внятность по видам проекта
- Адекватность. Решение задачи клиента, а не свою
- Надежность как предсказуемость итогов. Очень важно.
- Цена. Хотя это в разных проектах по-разному.
Вопрос — фикс или тм. У них в основном фикс. ТМ — мечта, но расслабляет. А еще при ТМ клиент тоже начинает париться на тему, что он действительно хочет.
Призыв к зрителям!
Мы призываем всех зрителей видеозаписей докладов давать хоть какой-нибудь, желательно конструктивный feedback.
Где? — неважно.
В блогах, в форумах, в комментах — пофиг, лишь бы можно было найти, например, поиском по блогам, по ключевому слову «ADD-2011» (ну и/или по названию доклада).
Что-то побольше твиттер-вскрика, хотя бы пару абзацев.
Да, иногда краткая характеристика бывает достаточной («маркетинговый булшит», «унылый самопиар» — обычно в адрес «спонсорских докладов»), но это очень, очень редко, а так хочется прочитать что-то большее, чем «сижу на XXX, говорят о YYY».
Что писать? Что хорошо, что плохо («плохо» неудачное слово, скажем, «неправильно на ваш взгляд»), как вы поняли то, что рассказано, как это спроецировалось конкретно на вас — все это фантастически важно и полезно:
- Другим потенциальным зрителям (смотреть/не смотреть, «правильно ли я понял»).
- И докладчикам:
- «Правильно ли меня поняли»,
- «Что я делал правильно, а что улучшить»
- Даже критический отзыв лучше, чем никакого!
- Плюс — это мотивация, это награда за немалый труд многие готовятся долго, раскрывают свой опыт, старательно делают слайды, репетируют выступление — и ради чего? двадцать минут театра перед парой десятков зритетелей и все?
- Организаторам конференций (этой и других) — они внимательно следят за отзывами, и пытаются понять, кого имеет смысл звать («рубит фишку и жжет!»), а к кому отнестись скептически, и если брать, то, например, «прокачать в части выступлений» — мы, например, старались это делать, итеративно рецензировали слайды, рассылали подборку литературы о правильных слайдах и искусстве выступлений.
- Безотносительно лично докладчиков — важно понять, исчерпала себя тема или для народа еще остаются откровениями то, что для более пресыщенных инфопотоками людей (а организаторы обычно такие) уже выглядит как «аццкий боян». Ну и вообще — что еще интересно, и что было бы интересно услышать-увидеть-пообщаться на тему о…
- Ну и кстати, мне тоже важно — вообще имел ли смысл весь этот сыр-бор с сьемкой, видеомонтажем и обработкой и публикацией (это, вообще-то дорогая работа, расценки профессионалов в этой области весьма недетские, при том, что до этого уровня монтажа им, как правило очень далеко), или кроме участников конференции эти темы никому не интересны. Может есть какие-то косяки в видео? или предложения как сделать лучше? — связывайтесь со мной, возможно это можно будет исправить (или хотя бы вырезать). Это кстати относится и к докладчикам — если есть какие-то
позорные неудачные моменты, или что-то не нравится — это можно убрать.
