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

[George Nordic]

Цитата:

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

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

Цитата:

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

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

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

У каждого подхода есть минусы и плюсы. В Rapid Implementation Methodology (RIM) - это быстрое достижение целей проекта, и это очень ценно когда цели не ясны или могут меняться. Поэтому для BI-проектов они очень хорошо подходят.

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

Да, как и обещал, накидаю в отдельной теме список документов, вдруг кому пригодится.

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

[Bobkov]

Цитата:

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

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

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

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

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

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

Цитата:

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

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

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

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

[gl00mie]

Цитата:

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

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

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

Цитата:

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

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

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

Цитата:

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

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

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

[Ivanhoe]

Цитата:

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

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

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

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

Цитата:

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

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

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

Цитата:

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

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

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

Цитата:

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

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

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