Как правильно учить/дообучать стажеров и не только?

[axm2017]

Философский вопрос.
Для меня не текущий но вдруг стало интересно глядя на старающихся коллег.

Как правильно готовить разработчика по Акс?

Грузить теорией? суровая практика?
В колумбусе в свое время на сколько представляю народ после краткого тренинга банально кидался на проект (винтовку добудешь в бою) но это вместе с преимуществами порождало иногда пробелы: человек представлял те задачи с которыми сталкивался но не более + его решения зачастую были практическими но не корректными. В MS опять же по слухам не учили вообще: лучшее учение это практика.

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

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

[Pandasama]

Цитата:

В колумбусе в свое время на сколько представляю народ после краткого тренинга банально кидался на проект

Вполне подходит, имхо, для аксапты - сам примерно так вливался (имея за плечами понимание о программировании вообще, конечно). Тут уже встает вопросов конкретно "краткости тренинга".

Цитата:

человек представлял те задачи с которыми сталкивался но не более

Ну а как можно обучиться чему-то, не сталкиваясь с этим? никак, конечно.

Цитата:

его решения зачастую были практическими но не корректными

Код ревью и обратная связь от руководителя проектом помогает это исправить

Цитата:

С этим по слухам боролись проводя порой эпизодические лекции или пытаясь создать центры компетенции

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

[axm2017]

Цитата:

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

Ну а как можно обучиться чему-то, не сталкиваясь с этим? никак, конечно.

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

Цитата:

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

Код ревью и обратная связь от руководителя проектом помогает это исправить

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

Цитата:

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

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

Это само собой

[sukhanchik]

Цитата:

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

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

Складываем 2 вопроса и получаем - как обучиться вечно за минимальный срок? ))
Ответ простой - скорректировать реальную жизнь. Т.е. разработчику нужно давать не те задачи, которые есть на проекте, а те, которые он потянет. Это не всегда выполнимо, но это единственный способ получить эффективный результат от разработчика.
Вопросы кстати не связаны конкретно с АХ . "Это так в любой системе, сынок" ))

Из собственной практики. Когда я знакомился с АХ - мне дали сделать простейшую задачу - вывести некоторые данные в Excel-шаблон. При этом сама процедура выборки данных была тривиальной (цикл то ли из двух сджойненных таблиц, то ли вообще из одной таблицы).
Задачу я делал месяц. Ну как месяц.... Я делал, сдавал, получал замечания, доделывал, после чего снова сдавал и когда задача получалась выполненной - я ее начинал делать с нуля другим способом. И так - 4 раза. За этот период удалось освоить RunBase + RunBaseBatch достаточно... эммм плотно.
Что было дальше - не помню, но помню, что у меня было много задач по отчётности .

[db]

Практика плюс коллега с опытом. Как на заводе
Краткий тренинг
Потом в цикле до просветления:
Стажеру дается задача
Стажер думает (обязательно сначала сам), рассказывает наставнику как собирается реализовывать, вместе обсуждают правильное решение
После реализации смотрять вместе что получилось, стажер доделывает/переделывает опять же обязательно своими руками
Если в процессе реализации возникает что то с точки зрения стажера непреодолимое, то стажер обязательно сначала сам некоторое время это решить. Пусть неправильно, но обязательно сам. Т.е. ни в коем случае не справшивать сразу у наставника как правильно, а пытаться думать, искать реализацию похожего в стандарте

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

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

[mazzy]

Цитата:

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

Как правильно готовить разработчика по Акс?

Хорошо поставленный вопрос.

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

навсикдку, начинающему на проекте разработчику обязательно надо рассказывать о:
= best practice (соглашения о наименованиях, нумераторах, коллекциях, штатных массивах) и дополнительные соглашения, принятые на проекте
= особенности container в Аксапте и особенности использования контейнера, принятные на проекте
= трехуровневость, передача данных с клиента на сервер (pack/unpack), модификаторы server client
= tts и перехват ошибок, userConnection и другие Connection
= вывод ошибок и сообщений (в частности, работа с инфологом в классических аксаптах)
= логирование, принятое на проекте
= глобальные переменные и глобальные класы infolog, appl и т.п.
= глобальные кэши и кэширование данных
= механизмы сравнения кода, old-слои
= кластеризация
= журналы, зачем нужна блокировка журналов
= и т.п.

на каждом проекте, что я работал, дополнительно к штатным библиотекам были приняты собственные тараканы и заморочки (что можно и что нельзя делать в деве-тесте-проде, соглашения об оформлении кода и объектов, соглашения о достаточном уровне документирования, кто-то не приемлет временных таблиц, кто-то все делает на временных таблицах безо всяких list/set/map)

в общем, много чего можно и нужно рассказать ДО того, как кидать на проект.
В свое время я курс читал с названием "Решительный шаг" и подзаголовком "Зачастую решительный шаг является результатом хорошего пинка под зад"

[mazzy]

Цитата:

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

За художества сразу по рукам бить.

В этом случае от твоих рук должны остатся одни обмылки ))

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

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

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

Согласен и с тем, что на проекте у db я мало что привнес и много чему научился..

[mazzy]

Цитата:

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

Вот хз. Руководителю важны сроки.

тут либо крестик, либо трусы.

если стажеры, то какие могут быть сроки? никаких.
если сроки, то нужна сработавшаяся команда опытных профессионалов.

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

[Pandasama]

Цитата:

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

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

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

[axm2017]

Кстати стало интересно
А как у вас коллеги на работе устроен процесс расшаривания знаний, повышения квалификации и прочее?

Зы опросил экс коллег с МС: там по сути никак (в некоторых командах есть попытки идти по Agile и ко но это личная инициатива руководителя).

[George Nordic]

1. Центр компетенций (ядро внедрения, опытные коллеги)
2. Обучение (опытные коллеги читают курсы разработки и best practices новичкам)
3. Наставничество - постановка задачи, обсуждение подходящих решений, код ревью
4. Обмен опытом. Например, на первом проекте мы в 18-00 ПРЕКРАЩАЛИ работу и 1-2 часа рассказывали друг другу какие задачи решали, и как устроен модуль, что нового и интересного нарыли.
5. Грамотное распределение и постановка задач - давать стажеру задачи, с которыми он может справится и чуть сложнее
6. По-хорошему, еще надо вести базу знаний. Но, к сожалению, это довольно трудозатратная задача, а без актуализации информации в ней знания быстро устаревают.

С Уважением,
Георгий

[axm2017]

Мелкие комментарии

Цитата:

Сообщение от George Nordic

1. Центр компетенций (ядро внедрения, опытные коллеги)

По опыту клумбы это было (во всяком случае для меня) чем то эфимерным. То есть вроде они есть но в нужный момент хрен кого выдернешь.

Цитата:

Сообщение от George Nordic

3. Наставничество - постановка задачи, обсуждение подходящих решений, код ревью

Работает при заинтересованности. Но так да must have

Цитата:

Сообщение от George Nordic

4. Обмен опытом. Например, на первом проекте мы в 18-00 ПРЕКРАЩАЛИ работу и 1-2 часа рассказывали друг другу какие задачи решали, и как устроен модуль, что нового и интересного нарыли.

По Agile на который таки происходит постепенный переход такое предусмотренно как Retrospective (т.е. после окончания sprint-а)

из https://www.pmoffice.by/blog/agile/agile-approach.html

PS интересен был опыт IT Box а где народ вроде читал полу добровольно лекции друг другу.

Цитата:

Сообщение от George Nordic

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

Да что то wiki подобное было бы интересно но не видел толком реализацию.
О попытках иной реализации слышал слухи что в MS реализовано было подобное через onenote - как понял работает крайне хреново.

[belugin]

Цитата:

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

Да что то wiki подобное было бы интересно но не видел толком реализацию.
О попытках иной реализации слышал слухи что в MS реализовано было подобное через onenote - как понял работает крайне хреново.

Там на усмотрение команды. Но есть централизованное хранилище в Azure Devops Wiki. В OneNote проще добавлять в wiki проще читать.

[belugin]

Цитата:

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

Зы опросил экс коллег с МС: там по сути никак (в некоторых командах есть попытки идти по Agile и ко но это личная инициатива руководителя).

В основном, на откуп команды, но в рамках нашего подразделения, есть wiki, Knowledge transfer сессии, рассылки, чаты и так далее.

Результаты ретроспектив команд рассылаются в общие рассылки. Я чужие довольно часто читаю.

[belugin]

Видос про онбординг в ламоде https://www.youtube.com/watch?v=3Fw-3Z0KbeY&t=2037s

[dech]

1. Обучение по материалам (в первый месяц испытательного срока)
2. Ведение базы знаний
3. Проведение лекций
4. Реальные задачи, накопление компетенций
5. Код-ревью

[gl00mie]

Цитата:

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

Как правильно готовить разработчика по Акс? Грузить теорией? суровая практика?

Теория, если говорить за AX2012 и более ранние версии, хорошо описана в штатных тренингах и книжках.

Цитата:

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

В колумбусе в свое время на сколько представляю народ после краткого тренинга банально кидался на проект (винтовку добудешь в бою) но это вместе с преимуществами порождало иногда пробелы: человек представлял те задачи с которыми сталкивался но не более + его решения зачастую были практическими но не корректными.

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

Цитата:

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

Как правильно должен быть выстроено обучение с учетом что разработчик учится почти вечно?

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

Цитата:

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

Как подготовить стажера к реальной жизни за минимальный срок?

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

[gl00mie]

Цитата:

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

навсикдку, начинающему на проекте разработчику обязательно надо рассказывать о:
= best practice (соглашения о наименованиях, нумераторах, коллекциях, штатных массивах) и дополнительные соглашения, принятые на проекте
= особенности container в Аксапте и особенности использования контейнера, принятные на проекте
= трехуровневость, передача данных с клиента на сервер (pack/unpack), модификаторы server client
= tts и перехват ошибок, userConnection и другие Connection
= вывод ошибок и сообщений (в частности, работа с инфологом в классических аксаптах)
= логирование, принятое на проекте
= глобальные переменные и глобальные класы infolog, appl и т.п.
= глобальные кэши и кэширование данных
= механизмы сравнения кода, old-слои
= кластеризация
= журналы, зачем нужна блокировка журналов
= и т.п.

Стажеру хорошо бы освоить для начала Development I, чтобы просто мог создать новую таблицу по всем правилам и номерную серию к ней прикрутить а уж когда он там на практике до old-слоев доберется...
Дополнил бы еще такими вещами, как:
= перекрестные ссылки и навыки их использования с учетом иерархий классов, перехода от методов Map к таблицам и т.п.
= механизмы рефлексии (Dict-классы, UtilElements, TreeNode - при том, что последние два актуальны разве что до AX2012), умение решать задачи с их помощью, скажем, job-иком найти готовую временную таблицу типа tempDb, у которой есть поле типа real и поле типа string длиной от 20 символов.

[gl00mie]

Цитата:

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

Код ревью и обратная связь от руководителя проектом помогает это исправить

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

Цитата:

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

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

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

Цитата:

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

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

Представим, что идет стройка, и откуда-то привели начинающего "строителя", который пока почти ничего не умеет. Доверят ли такому строителю-стажеру заливать бетон для фундамента? Думаю, вряд ли... Доверят ли ему что-то, влияющее на сроки сдачи объекта? Тоже вряд ли. Как будет проверяться результат его работы? Наверно, приставленный к нему прораб будет смотреть квадратным глазом еще по ходу дела, чтоб раствор хорошо мешал или, там, арматуру вязал без огрехов, потому что вариант "ревью проводить неглубоко" работает только с опытными строителями, имеющими некий кредит доверия. Мне кажется, и со стажером-разработчиком аналогично

[sukhanchik]

Интересное развитие обсуждения.
Фактически, получается 3 варианта:
Как правильно учить / дообучать - если ты партнёр
Как правильно учить / дообучать - если ты вендор (Microsoft)
Как правильно учить / дообучать - если ты клиент.
Из этой ветки + из общения со своими знакомыми у меня получается такая картина:
Вендор:
Есть команды и разные технические возможности. Т.е. взаимодействия между людьми нет, но есть wiki, OneNote и прочие технические средства, куда можно "сложить" знания. При этом насколько я понял вопрос качества выложенной туда информации (=пользы от всего этого) остается за кадром.
Партнёр:
Есть наставничество, т.к. человека нужно как можно быстрее воткнуть в проект, чтобы его продавать, как специалиста. Соответственно - цель - как можно быстрее человека "дорасти" до продаваемого состояния. При этом никто не заморачивается использованием тех или иных методик (типа Agile и т.д.)
Клиент:
Есть наставничество, но оно менее интенсивное, нежели у партнёра. Поэтому здесь больше акцент делается на тренинги, изучение существующих материалов, поддержка (сначала посиди на телефоне, а потом уже дадут крупные задачи). Здесь может быть некая смесь методик ведения проекта и использование разных технических средств (Jira и т.д.). Опять-таки - вопрос качества внесенной туда информации остается за кадром.

Было бы интересно ещё услышать какие-нибудь мысли