|
![]() |
#1 |
Модератор
|
Но, увы, она не отвечает на простой вопрос: "в каком документе фиксируются цели проекта".
Так же она не отвечает на вопросы: "в каком документе фиксируются критерии достижения целей проекта", "что явяется критерием достижения вехи проекта", "документы, необходимые при сдаче вехи проекта" и "процесс сдачи вехи проекта" (закрывающие документы). Поверьте, меня эти вопросы вообще не беспокоили - вехи какие-то. А потом я стал разрабатывать КП, и зачастую оплата Заказчиком Исполнителю происходит именно по вехам проекта ![]() А вот это засталяет задуматься и смотреть на методологии на только как "как можно быстро что-то реализовать" и но "процесс, как безболезненно это сделать и прикрыть тылы". Так вот, пока у RIM - очень плохо со вторым вопросом. А у "классических" - наоборот, зачастую сильно перегружена часть, отвественная за точное фиксирование предполагаемого результата и процесса его сдачи заказчику - неудивительно, PMBOK писан кровью ПМов ![]() Однако, если Вы знаете ссылку на подобные документы для RIM - скиньте, я удивлюсь. С Уважением, Георгий |
|
![]() |
#2 |
Гость
|
Цитата:
Отмечу, что: Методология — это система принципов, а также совокупность идей, понятий, методов, способов и средств, определяющих стиль разработки программного обеспечения. Не меньше но и не больше. Документация процесса отдается на конкретной реализации методологии и в общем то это логично при желании сократить количество документации, создаваемой на проекте. Пожелания же к документации смотрите в чем то типа такого http://www.agilemodeling.com/essays/...Specifications |
|
|
За это сообщение автора поблагодарили: George Nordic (5). |
![]() |
#3 |
Модератор
|
Цитата:
Сообщение от George Nordic
![]() Методология Внедрения - это набор методов, рекомендаций, шаблонов документов и практик ведения проектной деятельности с целью достижения целей проекта с оговоренным качеством, призванных снизить проектные риски, в том числе риски выхода за бюджетные и временные рамки проекта, и оптимизировать полезное использование (утилизацию) ресурсов.
Цитата:
В принципе, как я и говорил, мне всегда была ближе точка зрения "зачем все эти методологии, документацию всякую писать - это пустая трата времени - пахать надо". Однако она резко изменилась после работы в консалтинге, а не на внутреннем проекте ![]() У каждого подхода есть минусы и плюсы. В Rapid Implementation Methodology (RIM) - это быстрое достижение целей проекта, и это очень ценно когда цели не ясны или могут меняться. Поэтому для BI-проектов они очень хорошо подходят. В целом, считаю мы пришли к консенсусу, а дальнешее развитие перейдет в тему "а нужна ли [правильная] методология", которая уже обсуждалась. Вкратце, народ понимает важность использования методологии и документирования, но в целом неодобрительно к ней относится, т.к. это съедает очень много времени, сил и ресурсов, и, разумеется, удорожает проект. Вопрос, кто будет за это платить - открытый, клиенту тоже не особо хочется тратить деньги на бумажки, призванные защитить в первую очередь партнера, вместо того чтобы за эти деньги получить результат. Так что в целом пока отношение как к "необходимому злу". Да, как и обещал, накидаю в отдельной теме список документов, вдруг кому пригодится. С Уважением, Георгий |
|
![]() |
#4 |
Участник
|
Цитата:
В общих чертах, это выглядит так: - Если сотрудник сидит на окладе или подрядчик на таймшитах, то они оба будут заинтересованы в том чтобы поменьше писать документов, а побольше удовлетворять пользователей. - А если сотруднику обещана большая премия за результат или подрядчик привлечен на фикс-прайс, то оба они будут очень заинтересованы в том, чтобы требования к результату были заранее поточнее определены и утверждены. Тут и возникает потребность в документах целеполагающего характера. |
|
|
За это сообщение автора поблагодарили: macklakov (2). |
![]() |
#5 |
Гость
|
Цитата:
Общие документы целеполагающего характера никто не отрицает в методологиях. А вот подробные... В тех проектах которых доводилось участвовать то что предполагалось изначально порой очень сильно расходилось с действительностью на конечном этапе. Причин масса: зачастую пользователи ака ключевые пользователи слабо представляют работу Dynamics Ax а в свою очередь консультанты слабо представляют бизнес процессы и их тонкости. В итоге рождение подробных ТЗ на первоначальном этапе, приводило к тому что в ходе показов пользователям приходилось перерабатывать все достаточно серъезно вплоть "проще было бы сделать с нуля" |
|
![]() |
#6 |
Участник
|
Цитата:
![]() Цитата:
Сообщение от Bobkov
![]() В общих чертах, это выглядит так:
- Если сотрудник сидит на окладе или подрядчик на таймшитах, то они оба будут заинтересованы в том чтобы поменьше писать документов, а побольше удовлетворять пользователей. - А если сотруднику обещана большая премия за результат или подрядчик привлечен на фикс-прайс, то оба они будут очень заинтересованы в том, чтобы требования к результату были заранее поточнее определены и утверждены. Тут и возникает потребность в документах целеполагающего характера. ![]() Цитата:
Сообщение от axm2013
![]() В тех проектах которых доводилось участвовать то что предполагалось изначально порой очень сильно расходилось с действительностью на конечном этапе. Причин масса: зачастую пользователи ака ключевые пользователи слабо представляют работу Dynamics Ax а в свою очередь консультанты слабо представляют бизнес процессы и их тонкости.
|
|
![]() |
#7 |
Участник
|
Цитата:
Сообщение от axm2013
![]() Причин масса: зачастую пользователи ака ключевые пользователи слабо представляют работу Dynamics Ax а в свою очередь консультанты слабо представляют бизнес процессы и их тонкости. В итоге рождение подробных ТЗ на первоначальном этапе, приводило к тому что в ходе показов пользователям приходилось перерабатывать все достаточно серъезно вплоть "проще было бы сделать с нуля"
Показы, я так понимаю, после реализации. Опять же вопрос к методологии. Кто мешает, сдавая ТЗ, показывать живую систему, при необходимости даже с на коленке выполненными доработками? Это очень сложно делать если вы пишите космос - ну так не надо тогда Акс внедрять. Если же нормально пользователи видят систему после того, когда все сделано или даже на обучении - это неправильная методология внедрения Акс.
__________________
Ivanhoe as is.. |
|
![]() |
#8 |
Гость
|
Цитата:
Цитата:
В итоге приходим к тому что по факту имеем необходимость частого общения с пользователями, на что и нацелена agile методология |
|
|
|