Картина маслом: имеется проект с достаточно поверхостно составленым ТЗ. Параллельно с разработкой менеджер проекта собирает недостающие требования. Тим лидер готовит дополнительные вопросы, анализирует собранные требования на предмет реализуемости. Применяется политика частых релизов, результат раз в 1-2 недели выкладывается заказчику. Каждый релиз сопровождается подробным письмом с описанием того, что было сделано и на что стоит обратить внимание.
По идее, такой подход позволяет своевременно выяснить, в правильном ли направлении двигается команда. Но проблема в том, что заказчик не смотрит промежуточные результаты. По крайней мере, пока не запахнет релизом альфа-версии. После каждого промежуточного релиза — куча хвалебных слов, но абсолютно никакой конкретики.
В результате, в данном случае оказалось, что пять из шести секций сайта оказались реализованы не совсем так как надо. Типичный miscommunication, которого довольно трудно избежать. Но если бы заказчик вовремя смотрел промежуточные результаты, то rework не был бы настолько серьезным.
И это уже не первый раз, тенденция. Мне нужен совет, как стимулировать заказчика? Как заставить его смотреть результаты? Какие доводы применить?
Здравствуйте, slskor, Вы писали:
S>И это уже не первый раз, тенденция. Мне нужен совет, как стимулировать заказчика? Как заставить его смотреть результаты? Какие доводы применить?
Выполнить переделку за счёт заказчика, подробно объяснив ему, из-за чего так произошло. Если заказчик умеет считать деньги — в следующий раз будет тщательно контролировать, что делается. Если не умеет — вам же лучше
Здравствуйте, Eugene Beschastnov, Вы писали:
EB>Здравствуйте, slskor, Вы писали:
S>>И это уже не первый раз, тенденция. Мне нужен совет, как стимулировать заказчика? Как заставить его смотреть результаты? Какие доводы применить?
EB>Выполнить переделку за счёт заказчика, подробно объяснив ему, из-за чего так произошло. Если заказчик умеет считать деньги — в следующий раз будет тщательно контролировать, что делается. Если не умеет — вам же лучше
Забыл добавить — разумеется, приоритеты и последовательность задач должен определять заказчик. Ну и крайне желательно, чтобы уже после первой-второй итерации заказчик имел хоть как-то работающую программу — а в идеале, уже и работал бы на ней. Это всё, разумеется, общеизвестно, но иногда и общеизвестные вещи полезно проговаривать
Можно согласиться, что "Выполнить переделку за счёт заказчика" выход из положения,
но заставить заказчика платить очень трудно.
Если у тебя постоянно или регулярно такое возникает, проблема в тебе,
а не в заказчике. Я всего 3 года работаю в аутсоурсе тим лидом и
продакшен менеджером и могу сказать, что первое, что я делаю
это налаживание тесного взаимодействие с заказчиком.
Телефон, IM, почта. И конференции устраиваю каждый день.
Конференции войсом, если есть время и число проблем, которые
нужно обсудить больше двух трех.
НА КАЖДОЙ конференции, подчеркиваю, что это ОЧЕНЬ важно
и КРИТИЧНО для проекта иначе будут дополнительные затраты и
мы не уложимся в срок.
Второе, каждую неделю я пишу отчет, саммари ревью, в котором
указываю проблемы, которые обсуждались, проблемы которые почему-то
не обсудились (и по какой причине). Если виноват заказчик, так и указываю,
заказчик отказался обсуждать проблему, делаем так-то и так то (по его спецификации)
с его позволения. Потом, когда проект входит в стадию релиза, заказчику ничего не остается,
как поджав губки доплатить за переработку.
Но как правило, такого не возникает, если ты звонишь к заказчику и общаешься войсом.
Здравствуйте, Молодой, Вы писали:
М>Здравствуйте, slskor, Вы писали:
Забыл добавить.
Ты, как проджект лид, в ОТВЕТЕ,
за то что происходит и за то, что
ТВОИ девелоперы вынужнены перерабатывать.
Каждый день себе это говори.
Ты за это деньги получаешь.
Здравствуйте, slskor, Вы писали:
S>Картина маслом: имеется проект с достаточно поверхостно составленым ТЗ. Параллельно с разработкой менеджер проекта собирает недостающие требования. Тим лидер готовит дополнительные вопросы, анализирует собранные требования на предмет реализуемости. Применяется политика частых релизов, результат раз в 1-2 недели выкладывается заказчику. Каждый релиз сопровождается подробным письмом с описанием того, что было сделано и на что стоит обратить внимание.
S>По идее, такой подход позволяет своевременно выяснить, в правильном ли направлении двигается команда. Но проблема в том, что заказчик не смотрит промежуточные результаты. По крайней мере, пока не запахнет релизом альфа-версии. После каждого промежуточного релиза — куча хвалебных слов, но абсолютно никакой конкретики.
S>В результате, в данном случае оказалось, что пять из шести секций сайта оказались реализованы не совсем так как надо. Типичный miscommunication, которого довольно трудно избежать. Но если бы заказчик вовремя смотрел промежуточные результаты, то rework не был бы настолько серьезным.
S>И это уже не первый раз, тенденция. Мне нужен совет, как стимулировать заказчика? Как заставить его смотреть результаты? Какие доводы применить?
Вообще нужно сразу оговаривать принятие промежуточных версий. Сейчас же просто их вводить. В качестве довода можно использовать уже то, что получилось. То есть нужно сказать примерно следующее:
Каждая промежуточная версия будет сопровождаться документом. Для продолжения работы над этим шагом, необходимо подписать этот документ. Это необходимо для контроля работы и соблюдения выставленных требований. В будующем это позволит определить: или не реализованны все указанные требования или появились новые. Так же это избавит от доработок на коленке и затягиванию сроков. Нарпимер решили что в следующей версии будет создан раздел "О компании" и что в разделе будет написана строка "Для получения информации позвоните по телефону +7333333333". Этот документ скрепили подписями и начали делать. Если по окнчании шага появится новое требование, то, в зависимости от "тяжести", его переносят в следующюю версию или пишут дополнение к этой. Таким образом даже через год можно установить как должна выглядеть эта страница. Такой документ защищает как ваши интересы так и наши.
Здравствуйте, slskor, Вы писали:
S>Картина маслом: имеется проект с достаточно поверхостно составленым ТЗ. Параллельно с разработкой менеджер проекта собирает недостающие требования. Тим лидер готовит дополнительные вопросы, анализирует собранные требования на предмет реализуемости. Применяется политика частых релизов, результат раз в 1-2 недели выкладывается заказчику. Каждый релиз сопровождается подробным письмом с описанием того, что было сделано и на что стоит обратить внимание.
S>По идее, такой подход позволяет своевременно выяснить, в правильном ли направлении двигается команда. Но проблема в том, что заказчик не смотрит промежуточные результаты. По крайней мере, пока не запахнет релизом альфа-версии. После каждого промежуточного релиза — куча хвалебных слов, но абсолютно никакой конкретики.
S>В результате, в данном случае оказалось, что пять из шести секций сайта оказались реализованы не совсем так как надо. Типичный miscommunication, которого довольно трудно избежать. Но если бы заказчик вовремя смотрел промежуточные результаты, то rework не был бы настолько серьезным.
S>И это уже не первый раз, тенденция. Мне нужен совет, как стимулировать заказчика? Как заставить его смотреть результаты? Какие доводы применить?
Большинство Заказчиков может стимулировать только одно — деньги
Много полезного feedback'а можно получить только если ваш продукт действительно начинает использоваться. Всякие "посмотрите" не сравнимы с реальным использованием.
Вот и два [видимых мне] возможных выхода из ситуации:
1. Поставляйте не полуготовый веб-сайт, а полностью готовые пол-сайта. Тогда заказчик сможет немедленно начать им пользоваться
2. Если поставлять функциональность полностью готовыми кусками и дать заказчику возможность прекратить дальнейшую разработку в любой момент (с премией, естественно), заказчик будет очень внимательно смотреть на то, что уже поставлено. Что интересно, при таком подходе и постоянном внимании заказчик часто наоборот, готов заказывать ещё и ещё
Я так думаю, что нужно:
1) внятно объяснить ему, что и зачем вы от него хотите. Если есть большой негативный опыт, на него можно и опереться
2) новая версия раз в неделю слишком часто. Все-таки заказчик не тестер ПО. Кроме того, вы точно объяснили ему, зачем вы ему эти версии засылаете?
3) процесс тестирования заказчиком промежуточных версий нужно сделать как можно проще. В случае с сайтом, вы должны обновлять «девелоперскую» версию сайта, а заказчик лишь должен смотреть (а не получать «релиз» сайта). У вас это так сделано?
4) возможно, стоит ввести понятие прототипа, недоделанная версия сайта, которая показывает как все будет реализовано. Заказчик подписывается под тем, что он посмотрит и утвердит прототип. Это как альтернатива частым релизам.
А вообще, это распространенная проблема. Парится заказчик, как правило, не хочет. Вникать в технические детали (типа workflow и usecase) тоже не хочет (ибо все что нужно написано в его «идеальном» ТЗ). Ну а потом начинает дожимать — платить сверху, да еще и признавать свои ошибки никто не любит.
PS: Частные релизы пришли из Agile методик?
How can you get buy-in for the use of Scrum?
In general, if you start showing customers, the Product Owner, the stakeholders, deliverables at the end of Sprint and they don't show any interest in being engaged, or collaborating with the Team, then it's probably not worth using Scrum, nor is it worthwhile continuing with the project.
Т.е. если заказчик не интересуется результатами то нет большого смысла использовать Scrum, да и вообще проект пора прикрывать.
Что-то в этом есть, но на мой взгляд несколько категорично. На практике немало проектов предназначены просто для освоения денег, и заказчику плевать на них, лишь бы что-то работало и можно было отрапортовать выше по иерархии. Так что незаинтересованность заказчика — не повод отказываться от денежки
Здравствуйте, slskor, Вы писали:
S>После каждого промежуточного релиза — куча хвалебных слов, но абсолютно никакой конкретики.
Конкретика должна быть в виде акта приема/передачи с перечнем замечаний. С подписями сторон. Нет акта — нет следующего этапа. И до свидания, будет акт — звоните.
Здравствуйте, _doctor, Вы писали:
_>1. Поставляйте не полуготовый веб-сайт, а полностью готовые пол-сайта. Тогда заказчик сможет немедленно начать им пользоваться
Про историю разработки в Питере (интеловского?) компилятора не читали? Очень познавательно.
O>Т.е. если заказчик не интересуется результатами то нет большого смысла использовать Scrum, да и вообще проект пора прикрывать.
Ну, то, что проекту не подходит scrum еще не значит, что проект не жилец.
Кстати, я обратил внимание, что очень часто применяют agile технологии (типа круто) не задумываясь об области применимости и ограничениях.
Здравствуйте, Gregory Liokumovich, Вы писали:
GL>Ну, то, что проекту не подходит scrum еще не значит, что проект не жилец.
Логический вывод там другой. Если результаты работы заказчику неинтересны, то сам проект теряет смысл и
"по-уму" его надо прикрывать. Действительно, зачем делать никому не нужную работу?
Здравствуйте, S-SH, Вы писали:
SS>Здравствуйте, _doctor, Вы писали:
_>>1. Поставляйте не полуготовый веб-сайт, а полностью готовые пол-сайта. Тогда заказчик сможет немедленно начать им пользоваться
SS>Про историю разработки в Питере (интеловского?) компилятора не читали? Очень познавательно.
Здравствуйте, olegkr, Вы писали:
O>Здравствуйте, Gregory Liokumovich, Вы писали:
GL>>Ну, то, что проекту не подходит scrum еще не значит, что проект не жилец.
O>Логический вывод там другой. Если результаты работы заказчику неинтересны, то сам проект теряет смысл и O>"по-уму" его надо прикрывать. Действительно, зачем делать никому не нужную работу?
То, что заказчик не хочет участвовать в тестировании промежуточных версий (результате спринтов), не означает, что ему неинтересен конечный результат.
Довольно типичная позиция заказчика: я все хорошо описал (и не важно, что это не так), принесите мне все работающее к первому числу завернутое в ленточку.
Здравствуйте, S-SH, Вы писали:
_>>1. Поставляйте не полуготовый веб-сайт, а полностью готовые пол-сайта. Тогда заказчик сможет немедленно начать им пользоваться
SS>Про историю разработки в Питере (интеловского?) компилятора не читали? Очень познавательно.
Не читал. Что там можно познать? В контексте этой темы, интеловский пример — положительный или отрицательный?
Здравствуйте, minorlogic, Вы писали:
SS>>Про историю разработки в Питере (интеловского?) компилятора не читали? Очень познавательно.
M>А где можно почитать ? дайте наводку плз !
- Правда ли, что Рабинович вчера выиграл пять тыщ на ипподроме?!
— Правда, только не на ипподроме, а в карты, не пять тысяч, а пятьдесят рублей, и не выиграл, а проиграл.
