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

Цитата:

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

Поймите вы эксперт

"Конечно могу! Я же эксперт"

ЗЫ Словоблудием, извините, занимаетесь.

[ax_mct]

Цитата:

Сообщение от DynamicsAX-2015

"Конечно могу! Я же эксперт"

ЗЫ Словоблудием, извините, занимаетесь.

Может неправильно написал, сорри.
"Поймите, вы - эксперт." Для них вы технический эксперт по системе.
Который лучше знает как именно сделать, поэтому лишние детали можно и нужно опустить.

[AlexeyS]

Цитата:

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

Собственно программирования как такого 25-30% времени. Остальное время на анализ, вопроизведение и тестирование.

Зачастую, примерно так время и распределяется поровну 1 / 1 / 1 на анализ(воспроизведение_ошибки) / программирование / тестирование. Но это при наличии консультанта, который уже пообщался с бизнес-пользователем или группой и формализовал требования. Соответственно, при исключении консультанта время на анализ сильно вырастет

[ALES]

Цитата:

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

"It sources with the wrong UOM" - упрощая строка не должна сохранятся, insert не должен случится.
То есть когда нет конверсии UOM мы должны сделать так чтобы вводимая строка была удалена.

Правильный русскоязычный АХ программист: "Да вы охренели ленивые буржуи, что трудно написать конкретно чего хотите?"

Правильный западный АХ консультант/заказчик: "Нам нужен настоящий senior программист, этот не в состоянии понять даже простую задачу."

Если отбросить "трудности перевода" (а это явно не проблема "заказчика") то "за день" человек "с нуля" вполне может написать\позвонить\выяснить, не только "кто как когда в каких случаях" вводит строчки заказов.. но и как их затем разносят и в последствии корректируют + обговорить удалять ли их "молча" или кому-то при этом пожаловаться на отсутствие пересчета со сбором статистики (раз 8 часов в бюджете под это дело заложено)

[ax_mct]

Цитата:

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

Если отбросить "трудности перевода" (а это явно не проблема "заказчика") то "за день" человек "с нуля" вполне может написать\позвонить\выяснить, не только "кто как когда в каких случаях" вводит строчки заказов.. но и как их затем разносят и в последствии корректируют + обговорить удалять ли их "молча" или кому-то при этом пожаловаться на отсутствие пересчета со сбором статистики (раз 8 часов в бюджете под это дело заложено)

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

Гипотетически представьте что задача именно в таком виде, не больше и не меньше.
За сколько времени и денег возьмётесь за подобную задачу?

[ALES]

Цитата:

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

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

Гипотетически представьте что задача именно в таком виде, не больше и не меньше.
За сколько времени и денег возьмётесь за подобную задачу?

Если гипотетически и именно "в таком виде" (+ с такими "коммуникациями" ), то по тайм\материал
А если практически подумать, что "удаленный" вменяемый кодер "с нуля" не в теме через какой "портал"\интеграцию\импорт у вас там все это уже "внедрено" и заводится, то без всяких вопросов дешево быстро (и возможно за предоплату) получите от "студента" иф не те единицы то стоп

[ax_mct]

Цитата:

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

Если гипотетически и именно "в таком виде" (+ с такими "коммуникациями" ), то по тайм\материал
А если практически подумать, что "удаленный" вменяемый кодер "с нуля" не в теме через какой "портал"\интеграцию\импорт у вас там все это уже "внедрено" и заводится, то без всяких вопросов дешево быстро (и возможно за предоплату) получите от "студента" иф не те единицы то стоп

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

Другое дело что строки можно вводить не только напрямую через грид но есть и еще способов 5 в стандарте. И тут интересно что консультант может и не знать обо всех этих способах а программист знать обязан. Для прикрытия своей задницы. Можно реализовать только один способ, но соответственно упомянуть об этом.

Ожидать от консультанта перечисления всех сценариев ввода строк заказа это значит удивить его своим незнанием AX. Лучше перечислять самому при уточнении.

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

[AlexeyS]

Цитата:

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

Если отбросить "трудности перевода" (а это явно не проблема "заказчика") то "за день" человек "с нуля" вполне может написать\позвонить\выяснить, не только "кто как когда в каких случаях" вводит строчки заказов.. но и как их затем разносят и в последствии корректируют + обговорить удалять ли их "молча" или кому-то при этом пожаловаться на отсутствие пересчета со сбором статистики (раз 8 часов в бюджете под это дело заложено)

зачастую проблема не в том, чтобы позвонить или написать или спросить, а в доступности человека. Бизнес-пользователя бывает трудно отловить для допроса с пристрастием. Поэтому получил задание, выслал уточняющее письмо и два часа ждешь ответа? как в удаленной работе обговариваются такие моменты?

[ALES]

Цитата:

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

зачастую проблема не в том, чтобы позвонить или написать или спросить, а в доступности человека. Бизнес-пользователя бывает трудно отловить для допроса с пристрастием. Поэтому получил задание, выслал уточняющее письмо и два часа ждешь ответа? как в удаленной работе обговариваются такие моменты?

Один из рисков и не только "удалённой" работы... если не обговорены заранее коммуникации и за чей счет "простой", можно и два года ответа прождать..

[Ivanhoe]

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

Цитата:

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

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

Зачастую подобное есть и к примеру в РФ. Однако вроде бы никто не пытается рассказать как это круто.

[ice]

Цитата:

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

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

так получается у них проблема с кадрами, а нам тут впаривают про эволюцию процесса

[DaxDevRemote]

Я для себя всегда делю задачу на 3 роли и 3 части задачи.

1. Есть жизнь, бизнес, бизнес-процессы. Эта часть не имеет отношения к системе. В этой части свою роль играет аналитик (не настаиваю, что корректное название роли, важно, что эта часть не имеет отношения к системе). В этой роли может быть аналитик какого-то отдела, начальник отдела, бухгалтер, финансовый директор, какой-то специальный человек по бизнес-процессам … Кто-то от бизнеса. Для этой роли важно ориентироваться в бизнесе, знать жизнь, как есть, как должно быть и пр.
2. Вторая часть это система со своим функционалом и настройками, её интерфейс, отчеты и пр. Тут главенствует консультант. Под этим я подразумеваю именно консультант по конкретной системе MS Dynamics AX. Он знает, как многие бизнес-процессы правильно отражаются в системе, знает функционал системы, её настройки. Ведущий консультант (главный, старший, супер, тимлид и пр.) - консультант с большим опытом, знает больше реализаций процессов в системе, может делегировать и распределять задачи между консультантами, управлять и организовать работу группы консультантов.

В каждой части происходит своя работа. Аналитик знает (или узнаёт, проектирует, думает, работает, исследует, принимает решения), как и что должно быть в жизни или какие изменения необходимо сделать в бизнесе и предаёт эту информацию консультанту в терминах бизнеса (например, с помощью документа_1 – Описание БП). Эту работу нужно делать и на неё нужно время_1. Консультант, зная систему, понимает (или узнаёт, проектирует, думает, работает, исследует, принимает решения) как правильно отразить этот процесс или изменения в системе, делает необходимые настройки в системе, рассказывает и консультирует аналитика и пользователей о работе системы (например , с помощью документа 2 – Инструкция пользователя или Описание функционала, если нет таких готовых документов от поставщика системы). На эту работу тоже нужно время_2. Передача информации между консультантом и аналитиком происходит в терминах бизнеса и бизнес-процессов, в терминах интерфейса системы (пункты меню, формы, закладки, группы полей, поля и пр.) и в терминах процессов системы (закрытие склада, разноска и пр.).

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

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

Кто такой кодер не очень представляю, не встречал. Замечал, что обычно это слово применяют к программистам, которые не желают выполнять консультантскую работу, намекая на их (программистов) некомпетентность или лень в работе. Я бы определил, что это тот, кто желает получать информацию от консультанта только в технических требованиях системы (вплоть до описания классов и методов) и не способен (не желает) работать по описаниям в терминах интерфейса и процессов системы.

Передача информации между ролями консультант и программист может происходить при помощи, например, документа_3 – ТЗ или Спецификация, написанными в терминах системы. На разработку (или программирование) требуется время_3.

Обсуждаемые тут темы:
1. Бывает, что эти 3 роли и работу в них могут выполнять разные люди или один человек.
Что лучше – это вопрос. Наверное, зависит от конкретных задач, целей, от конкретных ситуаций, людей и определения понятия «лучше». Очевидно, что для выполнения работ в каждой из 3-х частей нужны свои опыт, знания и навыки, и у кого их больше, тот быстрее и правильнее выполнит эту работу.

Часто слышал аргумент о сокращении времени в случае выполнения всех ролей одним человеком.

Суммарные трудозатраты (разные люди) = время_1(аналитика) + время на передачу информации_1_2 + время_2(консультанта) + время на передачу информации_2_3 + время_3(программиста)
Суммарные трудозатраты (один человек) = время_1(программиста) + время_2(программиста) + время_3(программиста)

В одном случае сокращается время на передачу информации, в другом работа делается быстрее и профессиональнее. Спорный вопрос, что лучше. Зато в случае если передача информации происходит через документы, то ещё и документация останется.

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

3. Бывает, что задача в каждой из этих частей ставится полно или неполно (угадайкой, сделай то, не знаю что). Она может так ставится и аналитику в его части, и консультанту в его части (когда, например, ещё не проработан бизнес-процесс (не отработал аналитик), а пытаются к системе требования предъявить), и к программисту. Тут либо формализовать требования к постановке задачи, либо выяснять полную информацию, задавая вопросы.

4. А бывает, что одновременно и ожидания разные и информации недостаточно. Вот чтобы такого не было, поможет деление задач по ролям. Хотя бы условно и в голове. Сначала мы формулируем задачу в первой части, потом её во второй, потом (если необходимо) в третьей. Может и программист-то не так часто нужен будет.

[Ivanhoe]

Цитата:

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

Зачастую подобное есть и к примеру в РФ. Однако вроде бы никто не пытается рассказать как это круто.

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

Цитата:

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

так получается у них проблема с кадрами, а нам тут впаривают про эволюцию процесса

Нет, "проблема" в подходе. Система внедряется менее кастомизированная, нет смысла из каждого конса делать архитектора и платить соответственно.

Цитата:

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

..
А у них - это норма, внедрить Коробку и иногда чуть-чуть ее подпилить...

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

И вопросы нищебродства иногда возникают не только на Западе но и в РФ. У них возможно ярче так, как Аксапта сравнительно доступнее (наши нищеброды предпочтут 1С) а зарплатки выше.

[ax_mct]

Цитата:

Кто такой кодер не очень представляю, не встречал. Замечал, что обычно это слово применяют к программистам, которые не желают выполнять консультантскую работу, намекая на их (программистов) некомпетентность или лень в работе. Я бы определил, что это тот, кто желает получать информацию от консультанта только в технических требованиях системы (вплоть до описания классов и методов) и не способен (не желает) работать по описаниям в терминах интерфейса и процессов системы.

Абсолютно точно и грамотно все изложено.

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

Цитата:

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

..
Это наше образование и селекция рождает супер-специалистов с системным и техническим мышлением..

Вы рассказываете о каких то супер специалистах: консультантах и разработчиках одновременно при этом как результате эволюции на Западе...

Определитесь.

[ax_mct]

Цитата:

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

Вы рассказываете о каких то супер специалистах: консультантах и разработчиках одновременно при этом как результате эволюции на Западе...

Определитесь.

А если в контексте подумать?

Удалённая работа. Скорее всего на западного заказчика.
Ваши ожидания от вашего опыта с нашими специалистами.
Они у нас действительно супер.

Их ожидания от вас - другие. Ваши ожидания от них - нереальны.

И рассказываю я о том "что у них ружья кирпичом не чистят".
Как бы делюсь нелегким опытом, а если меня слишком много получается то прошу прощения.

P.S. Вы ожидаете связного и логичного изложения мыслей с корректными терминами чтобы вам было понятно сразу. Я лично до сих пор ностальгирую по такому изложению мыслей и давно уже отвык от такого. Если подумать то тесты на IQ они как раз на умение улавливать конктест.

[macklakov]

Цитата:

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

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

Не возражаешь если я еще одно уточнение внесу?
Есть в проклятом буржуинстве школы и универы, в которых логику и правилность вдалбливают как следует. Только вот выпускники Оксфорда или Гарварда обычно не размениваются на внедрежи. А вот для выпускника МГУ, согласно моим наблюдениям, норма жизни. Поэтому в пост-СССР среди внедренцев много людей просто потрясающего ума. А здесь внедрежами часто занимаются выпускники бухгалтерского ПТУ.

[ax_mct]

Цитата:

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

Не возражаешь если я еще одно уточнение внесу?
Есть в проклятом буржуинстве школы и универы, в которых логику и правилность вдалбливают как следует. Только вот выпускники Оксфорда или Гарварда обычно не размениваются на внедрежи. А вот для выпускника МГУ, согласно моим наблюдениям, норма жизни. Поэтому в пост-СССР среди внедренцев много людей просто потрясающего ума. А здесь внедрежами часто занимаются выпускники бухгалтерского ПТУ.

Именно так. Я бы еще добавил что сказывается и ментальность. Не принято "парится", "искать проблемы", тот кто говорит о проблемах которых нет прямо сейчас - не позитивный человек и все только усложняет на ровном месте.

Также культура бюрократии на нас наложила. Они же любят чтобы неформально. Вернее не подозревают о том насколько мы внутри бюрократы.

Год назад сдавал лаптоп по окончании контракта. В ближайший региональный офис корпорации. Без подписи о принятии и описи чувствовал себя неютно. Они вообще не поняли о чем я. Сфотографировал на столе что оставил. Мне было реально стыдно и за вопросы о сдал-принял и за фотографию. Для них эта была полная дикость.

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

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

Поэтому наши требования "а должно быть так и так", формализовано, структурировано и все суслики построены - для них культурно и ментально чуждо.

Что не может не сказываться на удаленной разработке так как все на ожиданиях друг от друга. Для них постановка задачи в как можно более неформальной форме и как можно проще - естественна.