"Новые" методологии

[Bobkov]

Цитата:

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

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

Позволю себе выразить мнение, что причина тут не в организации "консалтинг" или "внутренний проект", а в мотивации исполнителя.

В общих чертах, это выглядит так:

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

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

Цитата:

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

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

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

В тех проектах которых доводилось участвовать то что предполагалось изначально порой очень сильно расходилось с действительностью на конечном этапе. Причин масса: зачастую пользователи ака ключевые пользователи слабо представляют работу Dynamics Ax а в свою очередь консультанты слабо представляют бизнес процессы и их тонкости. В итоге рождение подробных ТЗ на первоначальном этапе, приводило к тому что в ходе показов пользователям приходилось перерабатывать все достаточно серъезно вплоть "проще было бы сделать с нуля"

[gl00mie]

Цитата:

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

Позволю себе выразить мнение, что причина тут не в организации "консалтинг" или "внутренний проект", а в мотивации исполнителя.

Очень тонко подмечено

Цитата:

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

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

В переводе на русский, если сотрудник заинтересован в результате, то он документирует работу по проекту ("получите, распишитесь"), а если в самом процессе безотносительно результата, то концентрируется на удовлетворении хотелок пользователей ("чего изволите?")

Цитата:

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

В тех проектах которых доводилось участвовать то что предполагалось изначально порой очень сильно расходилось с действительностью на конечном этапе. Причин масса: зачастую пользователи ака ключевые пользователи слабо представляют работу Dynamics Ax а в свою очередь консультанты слабо представляют бизнес процессы и их тонкости.

В переводе на русский: консультанты не разбирались в бизнесе заказчика.

[Ivanhoe]

Цитата:

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

Причин масса: зачастую пользователи ака ключевые пользователи слабо представляют работу Dynamics Ax а в свою очередь консультанты слабо представляют бизнес процессы и их тонкости. В итоге рождение подробных ТЗ на первоначальном этапе, приводило к тому что в ходе показов пользователям приходилось перерабатывать все достаточно серъезно вплоть "проще было бы сделать с нуля"

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

Показы, я так понимаю, после реализации. Опять же вопрос к методологии. Кто мешает, сдавая ТЗ, показывать живую систему, при необходимости даже с на коленке выполненными доработками? Это очень сложно делать если вы пишите космос - ну так не надо тогда Акс внедрять. Если же нормально пользователи видят систему после того, когда все сделано или даже на обучении - это неправильная методология внедрения Акс.

Цитата:

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

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

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

Цитата:

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

Опять же вопрос к методологии. Кто мешает, сдавая ТЗ, показывать живую систему, при необходимости даже с на коленке выполненными доработками?

Ровно так и делали и выяснялось порой что не учтены определенные ньюансы серъезно влияющие на дальнейших ход всей разработки.

Цитата:

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

Если же нормально пользователи видят систему после того, когда все сделано или даже на обучении - это неправильная методология внедрения Акс.

В итоге приходим к тому что по факту имеем необходимость частого общения с пользователями, на что и нацелена agile методология