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

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