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

[ax_mct]

Цитата:

Сообщение от AP-1055D

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

Мне вот кровать привозили. Кажется из IKEA. Один человек за водителя, экспедитора,
и грузчика. Думаю он был бы совсем не против выполнять только одну роль. А главное разницу в качестве осязает только он сам.

[trud]

Цитата:

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

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

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

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

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

[DaxDevRemote]

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

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

[DaxDevRemote]

Цитата:

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

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

Вот пример части ТЗ - это как раз из задачи от нашего интегратора на 70 часов. Это небольшая вырезка из ТЗ.

Цитата:

Корректировочная финансовая накладная.
Документ отличается от стандартной финансовой накладной, поэтому вводится новый тип разноски: Корректировочная финансовая накладная, который будет доступен только для Заказов на продажу, у который стоит галка Корректировка . При этом Разноска Финансовая накладная будет недоступна.
1. Создать пункт разноски «Корректировочная финансовая накладная» правила аналогичны разноске Финансовая накладная, однако Корректировочная финансовая накладная доступна только в случае если стоит галка Корректировка, и выполняются условия для активности финансовой накладной. При этом разноска Финансовая накладная – недоступна. Если галка не стоит, Корректировочная финансовая накладная не доступна.
Сдублировать механизм разноски Финансовая накладная, доработки механизма будут ниже.
2. При разноске корректировочной финансовой накладной «Тип сторно управленческой накладной» должен быть «Корректировочный»
3. Строки для разноски финансовой накладной должны содержать разницу суммы и количества по строке заказа и корректируемой накладной. При этом, разницу считать по существующим строкам заказа, а также по тем строкам, которые были отсторнированы, но в новом заказе их нет (считать количество в новом заказе равно 0 получатся отрицательные значения), и по новым строкам заказа, которые не были отсторнированы и не существуют в исходной накладной, но содержатся в новом заказе на продажу (первоначальное количество считать равным 0)

[greench]

Цитата:

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

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

[Pavel]

70 часов на 'непонятно что' - казалось бы ерунда... вот только жизненный цикл созданного этим методом 'продукта' будет очень геморным и дорогим.
Способ реализации (аутсорсинг или внутренняя разработка) - это второстепенная деталь.

[Pavel]

Цитата:

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

Вот в Селении тоже так думают. И не только они кстати.
Что senior developer это программист-консультант.
А тот 'консультант' нужен в качестве секретаря.
Блажь? Нет. Естественный отбор.

Да, работали с 90-х со всеми конторами... консультант всегда был нужен, чтобы чаржить клиента, 'контролировать' ход процесса и рулить исполнителем.

На заре рынка внедрения систем консультанты были носителями методологии процесса. Сейчас же все умеют делать проекты... разве нет?

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

[greench]

Цитата:

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

сейчас для этого есть project manager.

[ax_mct]

Цитата:

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

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

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

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

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

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

[ax_mct]

Цитата:

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

Успешный проект - это проект, в котором выполнено Проектное Задание, а процесс изменений формализован и отдельно выделен...

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

[ax_mct]

Цитата:

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

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

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

[DaxDevRemote]

Цитата:

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

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

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

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

[AlexeyS]

Цитата:

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

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

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

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

[DaxDevRemote]

Цитата:

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

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

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

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

[ax_mct]

Бюджет в случае процесса внедрения он на уровне проекта но не на уровне конкретной модификации. Поэтому конкретная модификация это лишь milestone или ступенька по пути.

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

Управление ожиданиями клиента намного важнее чем чистота и качество кода. И соответствие оценки и реального времени критично.

[ax_mct]

Цитата:

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

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

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

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

[ice]

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

[AP-1055D]

ice, я вот тоже так считаю )

[ax_mct]

Цитата:

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

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

Я бы сказал что "западный заказчик" такой в 90% случаев тогда как у вас скажем 10%. Потому как отстаете от мирового тренда
"Скажите государю, что у англичан ружья кирпичом не чистят: пусть чтобы и у нас не чистили..."

"Человек-оркестр" это как раз то что естественно для AX. В чем отличие проблем поддержки и расширения когда это был один человек вместо двух или трех?

Отнюдь не в том что оркестр играл один человек. А в наличии той или документации, понятного кода.

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

Цитата:

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

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

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

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

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

https://www.youtube.com/watch?v=1MvojmgPT6s

Существуют хорошие консультанты и в нашей сфере и работать с ними аутсорсеру только в радость.