Какая методология лучше в случае "Сначала сделайте, а мы посмотрим"

[slava09]

Оформили список дополнительных функциональных требований.
Отдали пользователям на проверку и утверждение, а они заявили: "Мы читать не любим. Вы сначала сделайте, а мы потом посмотрим и скажем ответ."

Смешно?

[kashperuk]

На самом деле - очень
Ответ должен быть следующим: "Мы программировать не любим. Вы сначала заплатите, а мы потом посмотрим и скажем, будем ли мы это делать"

[galka]

Цитата:

Сообщение от slava09

Оформили список дополнительных функциональных требований.
Отдали пользователям на проверку и утверждение, а они заявили: "Мы читать не любим. Вы сначала сделайте, а мы потом посмотрим и скажем ответ."

Смешно?

Ага, особенно когда у самой такое было на половине проектов
А потом эти же заказчики удивляться будут почему бюджет проекта уже закончился, а система у них еще и не работает (ну или работает не так, как они себе это представляли).

[Nick]

Цитата:

Сообщение от slava09

Оформили список дополнительных функциональных требований.
Отдали пользователям на проверку и утверждение, а они заявили: "Мы читать не любим. Вы сначала сделайте, а мы потом посмотрим и скажем ответ."

Смешно?

Нет!
Если Заказчик финансирует такой способ работ - почему бы и нет?!
Как правило, при грамотной команде внедренцев проект даже и более рентабельным для клиента выходит...

[slava09]

Цитата:

Сообщение от Nick

Как правило, при грамотной команде внедренцев проект даже и более рентабельным для клиента выходит...

При грамотной команде внедренца, можно внедрить за 1 месяц SAP
Если команда, конечно, ОЧЕНЬ грамотная!

[glibs]

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

В смысле, мы сами себе выбираем заказчиков.

[slava09]

Цитата:

Сообщение от glibs

Я предполагаю, что история того, как вы этому клиенту продались, звучит не менее смешно.
В смысле, мы сами себе выбираем заказчиков.

Если я смогу представить себе эту историю, то отвечу было ли мне смешно или нет

[George Nordic]

Lucky13 и ice абсолютно правы: это бот. Который возродил очень интересную дискуссию. Темы объединил, дал более осмысленный заголовок. Бот забанен.

С Уважением,
Георгий

[mazzy]

Цитата:

Сообщение от George Nordic

это бот. Который возродил очень интересную дискуссию. Темы объединил, дал более осмысленный заголовок. Бот забанен.

1. Блин
2. Спасибо
3. Вот ведь дискуссии раньше были - теплые, ламповые...

[EVGL]

Цитата:

Сообщение от mazzy

1. Блин
2. Спасибо
3. Вот ведь дискуссии раньше были - теплые, ламповые...

Не проблема, щас испортим:

• Пора валить!
• А что есть в вашей Аксапте, чего нет в 1С?
• Украинский программист умнее русского.
• Жить стало лучше, а скоро станет еще лучше.
• Доллар будет расти, евро - падать, а рубль сравняется с гривной.

[mazzy]

Цитата:

Сообщение от slava09

Смешно?

Зависит от стадии отношений.

Сужу по тому как сам бываю заказчиком.
В самом начале, чтобы понять на что способен исполнитель я обычно выделяю мини-задачу. И явно предупреждаю исполнителя, о максимальном бюджете и о том, что задача будет оплачиваться в любом случае, что я хочу посмотреть на что способен исполнитель.

(Что-то типа тестовых заданий у Темы Лебедева при приеме на работу)

На следующих стадиях конечно же задачи ставлю на том уровне, который достигнут на первой минизадаче.

==============
Поэтому, как уже говорилось здесь:
1. подобные неопределенные задачи должны быть оплачены при любом исходе
2. такое очень даже нормально на первых этапах знакомства с исполнителем, чтобы понять его уровень

Неопределенные задачи - всего лишь инструмент. В некоторых случаях вполне можно использовать.

[ice]

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

[kALVINS]

Цитата:

Сообщение от ice

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

При таком раскладе будут делаться хотелки того пользователя кто громче всех кричит )))
Нет, Product Owner должен активно работать в команде внедрения и сам определять приоритеты всех задач.

[macklakov]

Цитата:

Сообщение от ice

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

Ну как-бы это его прямая должностная обязанность. Если он на это забивает, то к нему применимы обычные дисциплинарные меры. Если он не умеет, для этого есть специальные экспресс-курсы.
Вопли пользователей это замечательно. Их надо писать в backlog. А когда идет планирование следующего этапа, ставится вопрос: "каким функционалом мы будем жертвовать?" Ибо априори все хотелки исполнить невозможно. Команда принимает только тот объем, который может осилить за спринт. Все остальное откладывается на потом. Если будет желание и бюджет, то будет хорошо всем. Не будет желания или бюджета, то будет система которая многих раздражает, но основные задачи выполняет.

[Bergman]

Эджайловский Product owner в применении к АХ это ответсвенный консультант за определенный участок. Таким образом, кто как не он будет заниматься пользователями и корректировать их требования согласно best practices, а уже потом вместо с командой клиента и своей командой (возможно с другими Product ownerами) расставлять приоритеты.

[mnt_dx]

Я всегда считал, что аджайл расчитан на работу поддержки, когда пользователи выдают понятные требования, критерии выполнения которых понятны и достижимы в короткий срок: добавить кнопку, она делает то-то. На следующем этапе покрасить кнопку в зеленый. Это не тоже самое, что добавить аналитический признак в те документы, которые надо, чтобы через полгода можно было выполнить консолидацию по правилам, которые ещё в разработке.

[macklakov]

Цитата:

Сообщение от mnt_dx

Я всегда считал, что аджайл расчитан на работу поддержки, когда пользователи выдают понятные требования, критерии выполнения которых понятны и достижимы в короткий срок: добавить кнопку, она делает то-то. На следующем этапе покрасить кнопку в зеленый. Это не тоже самое, что добавить аналитический признак в те документы, которые надо, чтобы через полгода можно было выполнить консолидацию по правилам, которые ещё в разработке.

Вы что, кнопку 2 недели привинчиваете? За 2 недели парочка новых журналов с кастомной разноской и печатными формами делаются минимальной командой. И когда этот журнал делается, привинтить контроль аналитики тоже дело не хитрое. Если не плясать с бубном, в надежде сварганить бузупречную всеобъемлющую спеку на века, а быстро написать короткую историю, а с деталями настроики и девелопмента по ходу разбираться, процесс быстро идет.
Да, время от времени приходится переделывать, но издержки при этом гораздо меньше, чем на продумывание всеобъемлющих спек. Ведь все равно часто всего оказывается что клиент забыл консультанту что-то упомянуть и тщательно проработанную спеку можно в помойку выбрасывать.

[mnt_dx]

Цитата:

Сообщение от macklakov

Ведь все равно часто всего оказывается что клиент забыл консультанту что-то упомянуть и тщательно проработанную спеку можно в помойку выбрасывать.

Об этом и речь - аджайл не подходит для внедрения ERP.

[macklakov]

Цитата:

Сообщение от mnt_dx

Об этом и речь - аджайл не подходит для внедрения ERP.

Это как ты такой вывод сделал? Я тут пытаюсь объяснить что весь смысл существования scrum это как-то работать с пользователем, который никак не определится, чего он хочет. Поэтому детальные спецификации, мягко говоря, не поощряются. Все направлено на то, чтобы клиент как можно быстрее получил на руки что-то работающее. А потом уже можно писать вдумчивую документацию. Если, опять таки, клиент этого захочет и у него будут деньги.

[Bergman]

Цитата:

Сообщение от macklakov

Это как ты такой вывод сделал? Я тут пытаюсь объяснить что весь смысл существования scrum это как-то работать с пользователем, который никак не определится, чего он хочет. Поэтому детальные спецификации, мягко говоря, не поощряются. Все направлено на то, чтобы клиент как можно быстрее получил на руки что-то работающее. А потом уже можно писать вдумчивую документацию. Если, опять таки, клиент этого захочет и у него будут деньги.

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


В АХ аджайл очень удобный только для контроля команды (стендапы, канбан, оценка задач, ретроспективы). Но передавать задачу в разработку лучше в готовом для разработчика дизайне.