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

[George Nordic]

Цитата:

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

ЗЫ касательно гибкой методологии. Из общения в свое время с кликвьюшниками вынес представление что они ее как раз и используют в полной мере в силу крайней привязанности к клиенту и гибкости системы.

Давайте сначала по второй части прокомментирую, а потом по первой спрошу

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

При этом у нас на дату старта проекта нет ни формализованных целей, ни функционального объема проекта. Фактически, хотя это и проект, по аналогии с Dynamics AX это - всего лишь проведение предпроектного обследования, на основании которого мы сможем сформировать требования к проекту. С одним большим плюсом - результатами данного небольшого проекта уже можно вовсю пользоваться, решая те или иные управленческие задачи. Для небольших компаний или на уровне отделов данного проекта вполне достаточно. Но вышеописанные проекты обычно небольшие, при их проведении не разрабатывается необходимая проектная документация и инструкции. Да, внедрение свехбыстрое и результативное, но если мы говорим про большое проект или масштабирование результатов данного пилотного проекта, то тут уже применяется "классическая" методология, базируясь на потребностях, выявленных в ходе подобного внедрения. И там уже все "по-взрослому". Запустить проект на 100+ пользователях, не сформировав целей и требовании к результатам проекта не решится ни одна уважающая себя консалтиногвая компания, так как отсутствие подобных документов увеличивает проектные риски.

Цитата:

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

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

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

В основном все фигурируют следующим списком:
Задание на изменение / Техническое Задание
Акт приемки
Инструкция пользователя

Для большого проекта этого, увы, недостаточно. Особенно если мы не про BI-систему говорим, которая должна быть динамической и быстро меняться, а про ERP / учетную систему, которая должна работать "как положено", хотя бы на этапе сдачи в ОПЭ. Хотя, конечно, если она сможет динамически меняться в соотвествии с изменчивыми требованиями бизнеса - это огромный плюс. В этом мне DAX очень-очень нравится своей сбалансированностью.

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

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

[Vals]

Цитата:

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

В этом мне DAX очень-очень нравится своей сбалансированностью.

Знаешь, всё больше убеждаюсь, что сбалансированность закончилась на AX2009

Цитата:

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

Да, зачастую внедрение Qlik идет именно по Agile - методологии, потому что в начале проекта нет целей: точные цели выстраиваются именно во время внедрения проекта.

Это имхо конечно же не так. Какие то цели внедрения есть иначе продукт не купили.
А вот подробности уточняют порой уже в ходе работ с непосредственным клиентом

Цитата:

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

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

Хм. Документы как раз есть (те же спринты к примеру содержат вполне себе лдостаточно информации). И проекты делающиеся по данной методолгоии масштабом бывают бОльше масштабом чем банальное внедрение DAX

http://habrahabr.ru/company/unicloud/blog/167059/

[George Nordic]

Цитата:

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

Документы как раз есть (те же спринты к примеру содержат вполне себе лдостаточно информации). И проекты делающиеся по данной методолгоии масштабом бывают бОльше масштабом чем банальное внедрение DAX

Увы. Запустить простой процесс на 100 000 сотрудников - это не то же самое, что запустить ERP с кучей взаимосвязанных бизнес-процессов на 100 сотрудников. И тут очень сильные проектные риски. И самый сильный риск по результатам проекта это:
- "А почему этого нет? Вы же обещали!"
- "А где мы вам это обещали?"

Я пока не вижу, как это проблема (еще с десяток подобных) решаются в Rapid Implementation методологиях, какими проектными документами регламентируются эти и подобные вопросы.

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

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

Цитата:

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

Увы. Запустить простой процесс на 100 000 сотрудников - это не то же самое, что запустить ERP с кучей взаимосвязанных бизнес-процессов на 100 сотрудников.

Вообще говоря запускают и не очень простые сервисы и больше чем на 100 000 человек. Систем разных и сложных очень много.

Цитата:

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

И тут очень сильные проектные риски. И самый сильный риск по результатам проекта это:
- "А почему этого нет? Вы же обещали!"
- "А где мы вам это обещали?"

Именно поэтому цели проекта таки есть.

Цитата:

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

Я пока не вижу, как это проблема (еще с десяток подобных) решаются в Rapid Implementation методологиях, какими проектными документами регламентируются эти и подобные вопросы.

Выписать общие идеи чего хотим не проблема +-.

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

Для этого с ним надо общаться узнавать что он хочет и тп. Одна из методологий этого к примеру agile. Она ака устав в армии или ПДД написана кровью и must have у любого консультанта на уровне понимания.