А как бы вы организовали контроль проекта?

[Evgeniy2020]

Есть проект upgrade с ax 3 на ax 2009
отдан консалтинговой компании.

вы являетесь Менеджером Проекта на стороне заказчика.

Как бы вы организовали контроль выполнения проекта?

например,
Должны ли консультанты и программисты вести Тайм шиты?
Выполнять ли проект на внутреннем сервере компании через удаленку?
Или копировать по окончании для приложение на сервер компании
Или разработчики и консультанты должны присутствовать на рабочем месте внутри компании?

Выставлять фиксированную ценную и фикисрованный бюджет за проект,
или же как Time & Material?

Как часто проводить статус митинги?
Поэтапно ли делать проект (не более 3-4 недели на этап) или дать возможность самостоятельно работать 2-3 месяца и потом предоставить результат?
Или же лучше делать этапами (2-3 недели) и на каждом тестировать и проверять качество работ?

и что еще можно добавить чтобы улучшить исполнительность качество и контроль за сроками и бюджетом?

спасибо заранее

[Vals]

Цитата:

Как бы вы организовали контроль выполнения проекта?

Нанял бы другую консалтинговую компанию контролировать проект.

Цитата:

Есть проект upgrade с ax 3 на ax 2009

И со своей стороны не рассматривал бы как "перенос" существующей функциональности с 3.0 на 2009-ю, так как последняя существенно отличается от тройки даже в продажах/закупках и складике. Поэтому, в зависимости от того, что у вас работает на 3.0 , каких результатов хотите добиться от перехода на 2009-ю, нужно прорабатывать проект.

[Morpheus]

В ходе upgrade(а) выполняется миграция кода и миграция данных. Миграцию кода можно условно разбить на два этапа:
1) Миграция кода объектов незначительно модифицированных в AX 2009 по сравнению с AX 3.0;
2) Миграция кода объектов значительно модифицированных в AX 2009 по сравнению с AX 3.0.

Первый этап миграции кода и миграция данных - рутинная работа. Поэтому целесообразно договориться с консалтинговой компанией о фиксированной цене. Оценить примерный объем работы поможет стандартный отчет Tools > Development tools > Code upgrade > Estimation report запущенный с параметрами по умолчанию Tools > Development tools > Code upgrade > Parameters. Не забудьте перед запуском отчета запустить Tools > Development tools > Code upgrade > Detect code upgrade conflict для каждого слоя (layer), где выполнены модификации. Время необходимое для upgrade(а) форм обычно в 2 раза меньше предлагаемого отчетом.

Второй этап миграции кода характерен творческой работой от результатов которой и зависит успешность всего проекта. Программистам необходимо выяснить в мельчайших подробностях алгоритм работы сильно измененных классов в AX 3.0 и AX 2009 для того чтобы правильно перенести модификации. Такую функциональность лучше протестировать по заранее подготовленным сценариям. Хорошо документированные изменения для AX 3.0 позволят выполнить этот этап в прогнозируемые сроки по фиксированной цене. В противном случае тип рассчетов Time & Material позволит в любой момент обратьиться к консалтинговой компании за помощью.

По моему субъективному мнению наиболее качественно и за разумные деньги выполнить аудит поможет сторонний разработчик имеющий опыт выполнения upgrade(ов).

[gl00mie]

Цитата:

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

Оценить примерный объем работы поможет стандартный отчет Tools > Development tools > Code upgrade > Estimation report запущенный с параметрами по умолчанию Tools > Development tools > Code upgrade > Parameters. Не забудьте перед запуском отчета запустить Tools > Development tools > Code upgrade > Detect code upgrade conflict для каждого слоя (layer), где выполнены модификации.

Небольшая ремарка: создание проекта выявления конфликтов при обновлении кода по всему AOT'у может так и не доработать до конца - клиент тупо будет сваливаться, не успев создать проект...

Цитата:

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

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

Ага, а еще предстоит напороться на многочисленные грабли - что в стандартном приложении (sys/syp), что в локализации (gls/glp): id-шники полей таблиц, заезжающие в диапазон usr-слоя, id-шники расширенных типов и enum'ов (!), заезжающие в диапазон usr-слоя (вот веселуха-то будет с синхронизацией!), изменившиеся id-шники классов, из-за чего модификации, сделанные для них в 3-ке, перестают видеться ядром в 2009-й, значения стандартных енумов, из-за непонятно с чего взявшегося изменения (было 5, стало 200) "наехавшие" на те значения, которые добавлялись в ходе модификаций... Это на вскидку.

Цитата:

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

По моему субъективному мнению наиболее качественно и за разумные деньги выполнить аудит поможет сторонний разработчик имеющий опыт выполнения upgrade(ов).

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

[fed]

Ну я бы обозначил следующий основной риск при апгрейде с 3ки на 2009ую. В 2009ой локальный микрософт реализовал много функциональности, которая раньше была в партнерских решениях каждого партнера. На вскидку - профиль разноски по складу, товары в пути, комисионная торговля, загрузка курсов с сайта ЦБ, накладняк от третей организации и тп.
И при переходе надо будет по каждой такой фиче принять решение - использовать ли партнерскую версию функционала (то есть то что партнер во времена 3.0 напрограммировал), или микрософтовскую.
Если использовать микрософтовскую версию, то скорее всего возникнут очень большие проблемы с конвертацией старых данных (может оказаться что нужных для новой микрософтовской функциональности данных просто нет в системе). И может оказаться что проще залить в систему остатки и запуститься с нуля, чем пытаться сконвертировать исторические данные.
Если использовать партнерскую версию - то во первых не понятно зачем тогда вообще переход начинать, во вторых - трудозатраты на выкашивание новой микрософтовской функциональности могут превзойти затраты на перевнедрение.
И вот этот риск явно значительно серьезнее чем технические риски связанные с id объектов и временем апгрейда БД.

Так что, IMNSHO, Vals прав однако. Либо проект перевнедрения (с затратами порядка 40-60% от стоимости начального проекта), либо проект апгрейда, но с совершенно непредсказуемым бюджетом и сроками и падучим монстром сшитыми из кусочков партнерского и микрософтовского кода в результате.

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

[gl00mie]

Цитата:

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

Есть проект upgrade с ax 3 на ax 2009
Как бы вы организовали контроль выполнения проекта?
Поэтапно ли делать проект (не более 3-4 недели на этап) или дать возможность самостоятельно работать 2-3 месяца и потом предоставить результат?
Или же лучше делать этапами (2-3 недели) и на каждом тестировать и проверять качество работ?

На счет тестирования при переходе на новую версию есть занимательный момент: чтобы более-менее нормально тестировать обновленное (обновляемое) приложение, нужна соответствующая тестовая БД, а чтобы получить соответствующую тестовую БД (конвертацией рабочей или тестовой БД с версии 3.0), нужно сперва как минимум обновить, т.е. перенести на новую версию, Data Dictionary, а это по затратам времени и сил может занять до трети от всего обновления приложения. Плюс еще, в зависимости от размера вашей рабочей БД, допиливание скриптов обновления данных до работоспособного состояния может также занять приличное время. Т.е. скрипты-то работают, но на сколь-нибудь ощутимых объемах они явно не тестировались (вспоминаются слова из руководства по написанию этих самых скриптов: вот такой-то код обновления данных до оптимизации работает 20 минут, а после оптимизации - 16 секунд. Да если б дело было в 20-и минутах!..). По своему скромному опыту могу сказать, что скрипты обновления данных в 2009-й (классы ReleaseUpdateDB401* и ReleaseUpdateDB41*) написаны местами просто отвратительно - будто наняли каких-то студентов-стажеров, которым в мозг успели вдолбить лишь два с половиной понятия: идемпотентность ("мы говорим «идемпотентность» - подразумеваем «notexist join»"), insert_recordset + update_recordset...
В общем, конечно, лучше бы делать этапами, потому что просто "перенос доработок" может, с учетом разницы в коде стандартных приложений 3.0 и 2009, занять непонятно сколько, что уж там говорить о фактически перевнедрении с использованием всех новых "фишек"... Но на практике, чтобы просто получить что-нибудь работоспособное и просто компилирующееся без ошибок, может уйти очень прилично времени - весьма вероятно, не 2-3 недели и даже не 3-4... Но это, впрочем, сильно зависит от объема модификаций и размера вашей рабочей БД.

[pm-erp]

Цитата:

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

Есть проект upgrade с ax 3 на ax 2009
отдан консалтинговой компании.

вы являетесь Менеджером Проекта на стороне заказчика.

Как бы вы организовали контроль выполнения проекта?

например,
Должны ли консультанты и программисты вести Тайм шиты?
Выполнять ли проект на внутреннем сервере компании через удаленку?
Или копировать по окончании для приложение на сервер компании
Или разработчики и консультанты должны присутствовать на рабочем месте внутри компании?

Выставлять фиксированную ценную и фикисрованный бюджет за проект,
или же как Time & Material?

Как часто проводить статус митинги?
Поэтапно ли делать проект (не более 3-4 недели на этап) или дать возможность самостоятельно работать 2-3 месяца и потом предоставить результат?
Или же лучше делать этапами (2-3 недели) и на каждом тестировать и проверять качество работ?

и что еще можно добавить чтобы улучшить исполнительность качество и контроль за сроками и бюджетом?

спасибо заранее

1. Идеально для Заказчика - fix-price (с четким ТЗ).
2. Консультанты - обязательно должны присутствовать у Заказчика, программисты - желательно (на запуске - обязательно).
3. Оперативки - не реже 1 раза в неделю.

[Ivanhoe]

Цитата:

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

...
Должны ли консультанты и программисты вести Тайм шиты?
Выполнять ли проект на внутреннем сервере компании через удаленку?
Или копировать по окончании для приложение на сервер компании
Или разработчики и консультанты должны присутствовать на рабочем месте внутри компании?
Выставлять фиксированную ценную и фикисрованный бюджет за проект,
или же как Time & Material?
Как часто проводить статус митинги?
Поэтапно ли делать проект (не более 3-4 недели на этап) или дать возможность самостоятельно работать 2-3 месяца и потом предоставить результат?
Или же лучше делать этапами (2-3 недели) и на каждом тестировать и проверять качество работ?

1. Тайм-шиты обязательны, если у вас оплата по T&M, иначе - желательно (чтобы понимать что сделано), но не обязательно.
2. 3. Если со стороны Заказчика тоже есть исполнители (ну или контролеры), то мне кажется правильно делать это у Заказчика. Опять же смотрите что у вас с лицензиями на 2009.
4. Зависит от команды со стороны Заказчика. Всю команду Исполнителя точно не обязательно.
5. Т&M более гибкое, фикс - скорее всего выгоднее Заказчику, но не факт - до
начала проекта очень тяжело прописать нормальные требования.
6.7.8. Обязательно поэтапно, промежуточные итоги желательно каждую неделю.

Цитата:

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

Нанял бы другую консалтинговую компанию контролировать проект.

=) А лучше две ) Я думаю это очень сильно зависит от стоимости для Заказчика. Особенно если Он экономит и "заказывает" "просто переход на 2009" без пересмотра БП, обучения и т.д.

Morpheus, gl00mie - поддерживаю.

Цитата:

Сообщение от pm-erp

1. Идеально для Заказчика - fix-price (с четким ТЗ).
2. Консультанты - обязательно должны присутствовать у Заказчика, программисты - желательно (на запуске - обязательно).
3. Оперативки - не реже 1 раза в неделю.

1. Где бы еще взять четкое ТЗ? Особенно если возникают такие вопросы? )
2. Не так категорично... Переходы бывают разные, в т.ч. без консультантов ) Все зависит от состава работ проекта.
3. +1.

А можно все-таки чуть больше информации - что именно будет выполнятся в рамках перехода? Какие работы, кто за них отвечает, что делает Исполнитель, что - Заказчик? Какой срок?

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

[Bega]

Мы делаем следующим образом:
1.Провели силами пользователей инвентаризацию функциональности (по все подразделениям компании, кто и что использует). Для этого подготовили шаблон и сделали приказ сверху.
2.Определили всю дописанную функциональность, разделили по логическим блокам.
3.Решили, что из новой функциональности DAX2009 будем использовать вместо старой, написали соответствующие ТЗ.
4.Определились, что делаем сами, что отдаем внешним консультантам. Написали ТЗ для внешних консультантов. Сумма, соответственно фикс.

Переход делаем с заливкой начальных сальдо.