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

[ax_mct]

Вот пример удаленного полноценного задания на 1 день. Задача поставлена консультантом AX.
CS это case splits и S - splits.

[ax_mct]

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

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

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

В чем разница между

Quote:

Originally Posted by ax_mct

..."Да вы охренели ленивые буржуи, что трудно написать
конкретно чего хотите?"

и

Quote:

Originally Posted by ax_mct

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

?

[AlexeyS]

Quote:

Originally Posted by ax_mct

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

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

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

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

[macklakov]

Quote:

Originally Posted by AlexeyS

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

Ну, скажем так, программисту будет лучше, если он таки потратит эти полдня или даже весь день на уточнение. Мне этот скил тяжело дался. Но это надо делать. Не дожмешь, гораздо больше потеряешь.

[ice]

Quote:

Originally Posted by macklakov

Ну, скажем так, программисту будет лучше, если он таки потратит эти полдня или даже весь день на уточнение. Мне этот скил тяжело дался. Но это надо делать. Не дожмешь, гораздо больше потеряешь.

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

[Ivanhoe]

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

Quote:

Originally Posted by Ivanhoe

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

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

[ice]

Quote:

Originally Posted by 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]

Quote:

Originally Posted by axm2013

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

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

Quote:

Originally Posted by ice

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

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

Quote:

Originally Posted by Ivanhoe

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

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

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

[ax_mct]

Quote:

Originally Posted by axm2013

В чем разница между

и

?

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

[ax_mct]

Quote:

Originally Posted by AlexeyS

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

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

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

Quote:

Originally Posted by ax_mct

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

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

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

Quote:

Originally Posted by ax_mct

...обанкротилась...

Раскройте тему при чем тут Dynamics Ax.

[ax_mct]

Quote:

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

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

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

[ax_mct]

Quote:

Originally Posted by DynamicsAX-2015

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

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

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

Quote:

Originally Posted by ax_mct

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

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

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

[ax_mct]

Quote:

Originally Posted by axm2013

Раскройте тему при чем тут Dynamics Ax.

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