Как разработчику освоить функционал?

[skad]

Приветствую! Занимаюсь несколько лет разработкой в AX и вот очень сильно озадачился вопросом развития скиллов по части консультрования и аналитики. Читаю посты людей, которые блещут познаниями как в разделе форума "разработка" так и в "функционал" и диву даюсь.

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

[mazzy]

базовая вещь http://axapta.mazzy.ru/lib/mrp

классика
Автор: Дитгер Хан, Харальд Хунгенберг
ПиК. Стоимостно-ориентированные концепции контроллинга
http://www.ozon.ru/context/detail/id/2421625/
раньше называлось "ПиК - концепции контроллинга"

игорь аверчев: GAAP
http://gaap.ru/articles/section/1054...rase_id=206767

[pitersky]

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

[BOAL]

Но и без теории брать на себя функции аналитика - это подставить коллег и заказчика. Видел я такие ФД, по которым кодили и делали формы и бизнес-процессы... жесть
Разработчкику освоить Ах проще, тк чуть что - лезем в код и смотрим, "что это за галочка и где она живет?"
По мануалям так не найти - есть много мест в системе, где без 0.5л не понять и без поиска if (config... _PL или LT не узнать, почему должно работать, а фиг

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

Потому - ищем в гугле брошюрки вида MBA для начинающих, конспекты лекций и прочие
Они есть в ПДФ, размер от 20 до 70 стр каждой, но сами в модулях и модулей много. Но идут от простого в дебри. Потому и начать с простого, понять, что интересно. Узнать в целом о бизнесе, учете, фичах. Понять, что реально понятно и интересно рыть дальше - и в эту область уже лезть вглубь.

И вот тут - брать на себя функции аналитика или умного разраба, читающего ФД и задающие вопросы - "а это точно так? А что будет если они...." и ставить тем самым в ступор консалта-автора ФД.
Или уже как в мультике про Вовку в сказке - брать толстьую книжку и "посмотрим, как тут избы делаются"(С) и самому пытаться окучить что-то
Только, опятьже, показать все старшим товарищам, дабы не подставлять заказчика хорошей реализацией (в коде) нехороших замыслов (консультанта).

[EVGL]

Цитата:

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

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

Развить в себе брюзгу. Подвергать все сомнению, в первую очередь - собственные идеи. Всегда спрашивать и переспрашивать.

[Удвой Покуров]

А оно вам надо? Нет, в смысле, освоить функционал: это обязатьльно для девелопера, а то еще будете дублировать стандартную функциональность или что там вам еще конс написал. А вот переквалифицироваться в консультанты - гораздо сложнее. Чем объяснять разработчику, что именно надо сделать - быстрее все самому написать. А уж потом еще с разработчиками бодаться, что они не так сделали, а вот так не работает, а тут вы не то имели в виду...

Не такой большой функционал у дакс, давайте честно. Удивительно, что за несколько лет вы его не выучили наизусть.

[BOAL]

Цитата:

Сообщение от Удвой Покуров

Не такой большой функционал у дакс, давайте честно. Удивительно, что за несколько лет вы его не выучили наизусть.

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

Кто-то писал, что вот, к примеру в 1С все они разработчики были по жизни - "все в одном". И только сча начали делиться на К и Р.
И пока они не разделялись - это были и + и - одновременно, на кого нарвешься

[sukhanchik]

Цитата:

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

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

Из поставленных вопросов сразу следует глобальная ошибка. Разработчик всегда изучает новое по книжкам. А консультант - в первую очередь по общению. А книжки - лишь приложение к общению.
Самый простой способ стать консалтом - посидеть на поддержке. Сначала будут ответы типа "Ваш вопрос понял - сейчас посмотрю и Вам перезвоню", а затем уже бодренько так будете знать ответы на вопросы.
В этом случае - книжка / РП (руководство пользователя) / ПИ (пользовательская инструкция) будет в помощь при решении вопросов.

Следующий этап (после того, как будет освоена поддержка) - это написание РП по существующему функционалу. Уже будет понятно - что следует осветить пользователям. Да и уже сами поймете, что пользователь ощущает при чтении РП. Здесь должна будет прийти в голову главная мысль - что 5-минутное добавление галки в интерфейс влечет за собой обновление кучи РП и скриншотов.

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

Все. После этого - Вы консалт. Вы умеете общаться с народом и осуществлять суппорт. Вы умеете писать документы на языке пользователя. Вы умеете транслировать хотелки пользователя в задания на разработку.

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

[Андрей К.]

Цитата:

Сообщение от Удвой Покуров

Удивительно, что за несколько лет вы его не выучили наизусть.

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

[jonny]

Ресурсы для изучения основ:
БУ - http://www.intuit.ru/department/itmngt/fundacc/
CRM - http://www.intuit.ru/department/itmngt/crm/
логистика - http://www.intuit.ru/department/itmngt/baselogic/

Так же по БУ могу порекомендовать книжку
http://www.ozon.ru/context/detail/id/4194936/