Удаленная разработка в MS Dynamics AX

[greench]

Цитата:

Это кто, программист на аутсорсинге будет 'объяснять&предлагать'?

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

Цитата:

то зачем нужен 'консультант', не знающий системы?

Вот здесь все сложнее. Крупные проекты зачастую заходят не напрямую, а через субподряд от огромных консалтинговых монстров типа Accenture/IBM/Dell и т.д. А там клиенту продают иногда таких "консультантов" что волосы дыбом встают. Причем в таких случаех очень часто еще общение напрямую девелопер - конечный клиент строго запрещено. Все общение идет через "испорченый телефон".

[trud]

Цитата:

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

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

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

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

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

[DaxDevRemote]

Иностранная компания сказала, чтобы ждал когда сами выйдут на связь. Договор с фиксом с 4-го мая.
До сегодняшнего дня молчали. Время и денежки капают, надеюсь)
Сегодня начали присылать всякие учетки, пароли, подключения.

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

[ax_mct]

Цитата:

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

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

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

[DaxDevRemote]

Цитата:

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

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

Да, всё так.
Будем искать точки соприкосновения (в рамках согласованного бюджета).

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

[AlexeyS]

Цитата:

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

Да, всё так.
Будем искать точки соприкосновения (в рамках согласованного бюджета).

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

такие вещи как Test Plan, видимо, в бюджете тоже не прописаны?
по сути, процесс разработки в таком виде представляет собой Agile, как в таком случае решается вопрос с увеличением бюджета?

[DaxDevRemote]

Цитата:

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

такие вещи как Test Plan, видимо, в бюджете тоже не прописаны?
по сути, процесс разработки в таком виде представляет собой Agile, как в таком случае решается вопрос с увеличением бюджета?

По этой конкретной задаче на 70 часов пока не знаю. Похоже нам повезло и мы все-таки уложимся в оценку. Надеюсь.

От консультанта был такой комментарий: "мне все понравилось в первом пункте надо следующий делать" - это касалось половины ТЗ. Есть подозрение, что полноценного тестирования не проводилось. Просто скинули клиенту. Но тенденция хорошая!)

[ax_mct]

Цитата:

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

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

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

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

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

А там где по контексту цепочки вопросы задавать глупо можно просто создавать Release notes оговаривая рамки сделанного и фиксируя свою ответсвенность. Я довольно часто так делаю потому как многие вопросы задавать некому и незачем. "Вот вам вариант для начала, он таков, а теперь давайте его допиливать как вам хочется."