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

[mnt_dx]

Цитата:

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

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

Клиенту ERP нужно работающее что-то большое, под его конкретику, а не абы что, что можно быстро сделать. Scrum требует конкретных постановок, тут не подходит неопределившийся пользователь. Можно по этой методологии вести поддержку или дорабатывать коробку, которая уже развернута и настроена, но не внедрение с нуля.
Наверняка можно организовать и миграцию из одной системы в другую, если функциональность задокументирована.

[ice]

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

[gl00mie]

+1. См. также Coordinated agility:

Цитата:

Project management happens differently at different levels of scale and abstraction. There is the team or feature level (around 10 people), the project level (between 50 and 5,000 people working on a specific release), and the product level (multiple releases led by executives). Agile methods work beautifully at the team level; formal methods work beautifully at the project level; and long-term strategic planning methods work beautifully at the product level. However, people rarely work at multiple levels at once; in fact, years typically separate those experiences for individuals. So people think effective methods at one level should be applied to others, which is how tragedies are often born. The moral is: small tight groups work differently than large disjointed organizations. Choose your methods accordingly.
Scrum is loaded with planning, and efficiently tracks more data in more detail than any other project management method I’ve seen at Microsoft (except for TSP, used by a few teams). Likewise, high-level project planning is critical to successfully scoping, coordinating, and delivering any large-scale initiative. If you have limited vision, then Scrum alone is fine. If you want to deliver lower quality and less customer value in more time than your competitors, or if you want to micromanage every aspect of your limited scope, then project planning alone is fine. If you have a bold vision with broad scope that you want delivered efficiently with high quality and copious customer value, then you need a balance of both high-level project planning and Scrum.

[belugin]

Несколько любопытных ссылок про скрам:

• http://scrumtrainingseries.com - интерактивный тренинг
• Срач на RSDN

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

[Ivanhoe]

Думаю, важно для нашего разговора определиться, что мы внедряем. Коробку с допилами или Самописку на платформе. И в том и в другом варианте что классика, что agile будут иметь свои плюсы и минусы.

[Удвой Покуров]

Ролик назывался "I love this job". А насчет agile - вот классный ролик: https://www.youtube.com/watch?&v=c84HVg_xAyw

Хорошая критика и разбор полетов - где применимо, а где - нет.

[belugin]

http://www.martinfowler.com/bliki/ScopeLimbering.html


...
To illustrate, here's a specific example with a client that I'll call Nebbiolo. As is often the case with our work, we came in because another delivery company had failed (you'd recognize their name, but I'll spare their blushes). They'd spent a long time gathering requirements but got nowhere with development. So the client had detailed requirements which had cost a lot of time and money, and were feeling rather sore from the other firms inability to get things done. So they insisted on a fixed scope arrangement, based of course on those detailed requirements.

We took a look at those requirements and estimated it would take us about half a million dollars to build it. Like most people tackling a fixed scope project, we added a buffer - in this case quite a large buffer doubling it to a full million. This was still less than the original contracting company's estimate. (We charge much higher daily rates for our people, but since we have better and more productive people, we can actually do the job for less.)

We weren't at all shocked to discover that despite the detailed and heavily reviewed requirements, the requirements changes still came thick and fast. For each one we estimated the scope of the change and figured out how much it would cost, but didn't charge the client for the change. Slowly but steadily the changes ate up the buffer. After about six months or so the changes had used up the buffer completely. We'd been quite open with Nebbiolo during this whole time, so they weren't surprised when we told them that we couldn't afford to eat the cost of the changes any more. During that time we'd collaborated closely with Nebbiolo and they'd grown to trust us. We had no problem finding more money, indeed it took another half million to cover the requirements changes that were needed before we delivered.

At the end of all this Nebbiolo agreed that the fixed scope approach was a mirage, and we would do future projects together using a more flexible charging scheme.
...

[DSPIC]

[ax_mct]

Цитата:

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

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

Смешно?

Это может называться Workshop или даже Proof Of Concept.
Вполне себе оправданно и часто именно так и нужно делать когда "иди туда не знаю куда но принеси то, что мне надо но я сам еще не знаю что точно мне надо".

[macklakov]

Цитата:

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

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

Смешно?

Хороший вам пользователь попался, честный и умный. С такими работать одно удовольствие.
Смысл большинства проектных документов тупо в том, чтобы переложить ответственность на заказчика. Все равно ведь ни заказчик, ни исполнитель не могут предусмотреть всех ньюансов и вариантов. А пользователи к тому же не понимают половину терминологии. Да и бизнес может поменяться в процессе внедрения. И технология может не заработать так, как описано в документации. В этом и кроется секрет такого высокого процента неудачных внедрений.
Получается натуральный АвтоВАЗ. Продукт от начала до конца делают, а потом начинают тестировать. В процессе изготовления неизбежно накапливается брак. Списать уже собранный автомобиль дорого, поэтому снижаются критерии качества.
Для сравнения, на заводах конкурентов, контроль качества непрерывный, поэтому брак выявляют и исправляют на стадиях когда это еще дешево сделать.
Попробуйте предложить клиенту одну из agile методологиий. Сейчас, к примеру, scrum в моде.
Будете планировать на 2 недели. И каждые 2 недели что-то работающее им в руки давать. На 2 недели планировать реально. А если кто и ошибется, то цена ошибки мнимальна. Т.к. каждые 2 недели делается разбор полетов, то буквально через месяц-другой качество заметно улучшается, а ошибки почти исчезают.

[Ivanhoe]

Проблема, как правило, не в методологии, а в том, что у заказчика обычно никто не хочет брать ответственность и обычно никто не хочет платить даже за "что-то сделанное за две недели".

Нет проблемы сделать и показать. Хоть по какой методологии. Есть проблема чтобы за это заплатить.

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

Agile - это хорошо, но не на практике в большом проекте ERP в России. На западе, при внедрении коробки (а это очень четкое понятие и со стороны внедренца и со стороны заказчика), это может быть хорошо и реально альтернатива классическому подходу.

[macklakov]

Цитата:

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

Agile - это хорошо, но не на практике в большом проекте ERP в России. На западе, при внедрении коробки (а это очень четкое понятие и со стороны внедренца и со стороны заказчика), это может быть хорошо и реально альтернатива классическому подходу.

Ну вот смотри как это работает. Сколько нужно времени, чтобы настроить склад без заморочки на правильную разноску в ГК, без ячеек, без сводного и т.д.? Просто через журналы. Пришло, ушло, в наличии.
Мне почему-то кажется что даже в уникальных российских условиях это реалистично за пару месяцев сделать. И конечно же это все должно сопровождаться нормальной проектной документацией, планированием, дизайнами и т.д. Как обычно.
Следующим шагом привинчиваются ячеечное хранение ИЛИ закупки/продажи ИЛИ ОС. Опять все оформляется честь по чести, как полноценный проект.
Каждый из таких мини-проектов разбит на несколько более коротких этапов. В конце каждого релиз оттестированного кода и настроек, демонстрация и планирование следующего этапа совместно с заказчиком.
При этом риски ограничиваются 2-мя месяцами. Пользователи очень рано попадают в систему и начинают жаловаться, а значит всякие шероховатости исправляются на самом раннем этапе. По мере того как одни отделы привыкают к системе, входить в другие отделы становится все легче. Можно делать шаг назад и доводить до ума уже внедренный функционал, прежде чем автоматизировать следующий отдел. Нет эфекта шока, возникающего при waterfall запуске, когда несколько отделов одновременно начинают вижжать как резанные и просто физически невозможно мгновенно привлечь столько ресурсов, чтобы закрыть все эти дыры.

Но есть и проблемы в этом подходе.
1. Усилия по выбиванию бюджета на внедреж часто не зависят от размера бюджета. Т.е. для клиента пробивать много мини-проектов гораздо тяжелее, чем один грандиозный.
2. Сейлам такая схема обычно не очень интересна.
3. Это противоречит привычной бизнес-схеме консалтинга. Есть риск что клиент довольно быстро обнаружит что система уже автоматизировала самые важные вещи, а ГК и зарплатна не нужны вовсе, т.к. есть выгрузка в 1С.
4. Как упоминул fed, бывает псевдо-agile, когда просто разработка разбита на короткие этапы, а реально пользователей пускают в систему через год-два. Это гораздо хуже чем обычный waterfall, т.к. риски те же, а ответственного не найти.

[fed]

Agile вообще на больших проектах не работает. Ее хорошо использовать чтобы какие-нибудь пользовательские интерфейсы или печатные формочки на поздних стадиях проекта отлаживать. Гораздо интереснее бывает когда ты решения по настройке производства, например, принимаешь. Там чтобы последствия решения увидеть, надо запуститься и пару месяцев проработать. Никакой Agile в этих случаях не помогает.
Более того - в той же Турции такой огромный процент факапов на проектах как раз из за широкого применения agile. Сначала клиент через двухнедельные марафоны (или как оно там называется), тратит весь бюджет на какие-нить удобные формы для пользователя или отчетики, а потом после запуска выясняет, что ему основную финансовую отчетность толком не построить, сводное работает через одно место, себестоимость не считается и тп. А ему просто во время марафонов всего этого не показали (потому что за марафон не уложиться).

[Logger]

Цитата:

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

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

Интересно, а финдир, главбух и.т.п. участвовали в этих двухнедельных забегах ?
И если участвовали, то что им показывали ? Неужели они удовлетворились какими-то формочками, но не обеспокоились отчетностью, которую они на ЭТОМ будут готовить ?

[fed]

Цитата:

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

Интересно, а финдир, главбух и.т.п. участвовали в этих двухнедельных забегах ?
И если участвовали, то что им показывали ? Неужели они удовлетворились какими-то формочками, но не обеспокоились отчетностью, которую они на ЭТОМ будут готовить ?

Обычно они считают что все это доступно out-of-the-box в любой ERP. Поскольку вылизывание формочек - это типа отраслевая специфика. А отчеты и сводное - оно у всех есть. И естественно - отчеты и сводное им показывали на Contoso, где все они без проблем работают.
P.S. Ну и другая стандартная проблема - что топам некогда внедрением плотно заниматься, а тимлиды на местах (ака ключевые пользователи) обычно больше озабочены удобством ввода, чем глобальными задачами внедрения.

[ax_mct]

Цитата:

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

Обычно они считают что все это доступно out-of-the-box в любой ERP. Поскольку вылизывание формочек - это типа отраслевая специфика. А отчеты и сводное - оно у всех есть. И естественно - отчеты и сводное им показывали на Contoso, где все они без проблем работают.
P.S. Ну и другая стандартная проблема - что топам некогда внедрением плотно заниматься, а тимлиды на местах (ака ключевые пользователи) обычно больше озабочены удобством ввода, чем глобальными задачами внедрения.

Я бы добавил что например для британцев в принципе некомфортно и непонятно когда ты говоришь о ВОЗМОЖНЫХ и ПОТЕНЦИАЛЬНЫХ проблемах достаточно отдаленных и еще непонятных. Будет проблема - будем ее решать, чего парится заранее - примерно такой жизненный позитивизм. В этих условиях предупреждать о чем то глобальном - просто выглядеть чудаком. Не принято о плохом заранее говорить С одной стороны есть управление рисками но менталитет многое определяет. Наверное поэтому немцы считаются лучшими руководителями проектов

[macklakov]

Цитата:

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

И естественно - отчеты и сводное им показывали на Contoso, где все они без проблем работают.

Э-э. Ну какбы против лома нет приема... Если внедрюки хотят прокинуть юзверя, а юзверь этому рад, т.к. хочет саботировать изменения и готов заплатить тому, кто возьмет на себя ответственность, то ни одна методология не в силах помешать этому стремлению.

[kALVINS]

Цитата:

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

Более того - в той же Турции такой огромный процент факапов на проектах как раз из за широкого применения agile.

Это потому, что Product Owner нихрена в критичных задачах для своего бизнеса, методике внедрения и информационных системах не понимает, а не потому, что методология нерабочая!
Суть фреймворка Scrum в том, что Product Owner определяет приоритет у задач и последовательность их реализации. Нормальные люди сначала основные функции реализуют, а потом за хотелки принимаются. Вот поэтому на турецких внедрениях и проблемы ))))

[fed]

Цитата:

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

Это потому, что Product Owner нихрена в критичных задачах для своего бизнеса, методике внедрения и информационных системах не понимает, а не потому, что методология нерабочая!
Суть фреймворка Scrum в том, что Product Owner определяет приоритет у задач и последовательность их реализации. Нормальные люди сначала основные функции реализуют, а потом за хотелки принимаются. Вот поэтому на турецких внедрениях и проблемы ))))

Как я обычно говорю - любая методология рассчитанная на вменяемость клиента и его способность четко сформировать цели, стратегию и критерии - заведомо обречена на провал. Условно говоря - если бы клиент был такой умный, он бы проект сам сделал (иногда покупая разработчиков и консультантов на почасовку на тактические задачи), а не нанимал бы консалтинговую фирму. То есть - сам факт привлечения консультантов говорит о том что клиент не в состояни определять приоритет у задач, определять стратегию, строить ключевых пользователей, разрешать конфликты интересов между ключевыми пользователями и тд и тп.
И решение всех этих проблем - это имено то, за что внедренцам ERP-систем и платят их неплохие почасовые ставки. Которые, кстати, заметно выше чем ставки у финансовых аудиторов или офшорных разработчиков. (Которые, по сути, смежные по проблематике профессии).

[pitersky]

Цитата:

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

Условно говоря - если бы клиент был такой умный, он бы проект сам сделал (иногда покупая разработчиков и консультантов на почасовку на тактические задачи), а не нанимал бы консалтинговую фирму. То есть - сам факт привлечения консультантов говорит о том что клиент не в состояни определять приоритет у задач, определять стратегию, строить ключевых пользователей, разрешать конфликты интересов между ключевыми пользователями и тд и тп.
И решение всех этих проблем - это имено то, за что внедренцам ERP-систем и платят их неплохие почасовые ставки

А я бы с этим поспорил.
Факт привлечения консультантов говорит только о том, что клиент НЕ ХОЧЕТ сам решать те задачи, которые на них возлагаются. Причины же нехотения при этом могут быть самые разные, "не могу" всего лишь одна из них.