Сначала рекомендую убедиться, что вам действительно интересно программирование вообще, и 1С в частности.
Для этого начните с бесплатных (или почти бесплатных) материалов.

• "Программирование за 21 день" - бесплатно. Курс старый, но принципиально на уровне азов в 1С ничего не поменялось с тех пор.

• "Программист 1С. Быстрый старт в профессию. " - как и предыдущий, от курсы-по-1С.рф. Увы, уже не продается, но если найдете - смотрите. Тоже старый и тоже это не важно.

• Радченко. Практическое пособие разработчика. (Можно ту часть, где про регистры расчета и регистры бухгалтерии - пока пропускать) . Читаем, пишем код по образцу, гуглим, то что не понятно, пишем еще раз.

• Язык запросов. Книга Хрусталевой "Язык запросов" + https://sql-ex.ru/. Пусть вас не смутит, что на сайте задачи по SQL, а не 1С. Рекомендую прорешать первые заданий 80.

• СКД - бесплатный курс от курсы-по-1С.рф

• Можно еще сдать 1С:Профессионал по платформе.

Если вы дошли в этом списке хотя б до середины Радченко и все еще хотите стать программистом - поздравляю:

• Вы потратили примерно 1000 рублей или чуть больше (если купили рекомендованные книжки)

При этом:

• сэкономили 100+ тысяч рублей на курсы известных онлайн-школ.
• у вас, скорее всего, все получится, т.к вы способны самостоятельно учиться и пользоваться поиском.

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

Тут сложнее неадресно советовать, потому что уровень может быть разный:

- вообще без опыта
- сильный предметник (например, главный бухгалтер)
- Латентный аналитик, как мы это назвали 😀 "Это человек, который уже работает аналитиком (не зависимо, от того, как называется текущая должность), но еще не знает об этом"

Но давайте дадим советы сферическому начинающему аналитику в вакууме.

Совет 0.

Если не знаете, с чего начать - начните с ERP

Совет 1.

Вот здесь схема прохождения курсов ERP от 1С. Не уверена, что нужно обязательно проходить курс по УНФ (мы же ERP пришли изучать?) и по Администрированию, но в остальном - да.
Если как пользователь с 1С уже знакомы - начните с "Концепции прикладного решения" , дальше по интересующей вас теме.

Совет 2.

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

Насколько "мелкая" будет ваша область, зависит от масштаба проекта.

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

Совет 3

Концепцию ERP изучили. Идем дальше. Отличные (и очень длинные) посты :

• "Сценарий изучения ERP" Часть 1
• Часть 2

Совет 4
Здесь оставляю свой пост из ТГ канала: Подборка книг для аналитика

Из этой подборки просто must have, рекомендую всем, и аналитикам, и программистам, кто переходит из не-ИТ сферы "Введение в управление проектами внедрения ERP-систем"

В 2021-22 годах довольно плотно работала со стажерами - программистами.

Как-то раз посчитали статистику (на середину 2022 года): получилось, что на работу выходит примерно 1 из 100 откликнувшихся на вакансию, примерно 1 человек в месяц. Кто-то сказал из коллег: "Конкурс больше, чем в университет". На самом деле нет:) Среди откликов много случайных, из разряда "таксист зашел на HH, 1C никогда не открывал, но решил попробовать", поэтому среди тех, кого мы искали - "конкурс" не такой уж и большой.

Из ограничений: только СПб(стажеры работают только в офисе, "под боком" у наставника) и хотя бы минимальные навыки в 1С (пройденные курсы, или Радченко, что угодно. Нам нужно, чтобы человек приложил уже какие-то самостоятельные усилия, а не просто анонсировал нам свое желание стать программистом). По образованию никаких фильтров не ставили.

Как мы находили этого 1 из 100:

1. Публикуем вакансию на hh.ru. Прямо в тексте вакансии просим ответить на 2–3 простых вопроса. Вопросы такого плана: какой у вас опыт с 1С (курсы, реальные задачи), чем интересна сфера 1С. Собственно, на этом этапе отсеивается уже 50% откликов: либо не отвечают на вопросы (а рассылают резюме на всё подряд, не читая вакансии), либо не из СПб, либо вообще никогда не видели 1C ( но "очень хотят" ). Для чего было так сделано: первое время пытались читать все резюме и приглашать подошедших по резюме на собеседование, но очень много времени это отнимает у того, кто собеседует. Пришлось процесс немного "обездушить".
2. Всем, кто справился с п.1, отправляем тестовое задание — уже по 1С. Просим решить несколько задач. Время на решение не ограничено, можно пользоваться чем угодно, присылать решение когда угодно. Решение присылают примерно 15-20% всех, кто получил задание. То есть, уже 7% из всех откликов на HH. (не густо, да? Но, напомню, мы и хотим найти тех, кто приложил усилия, а не просто решил "попробовать" )
3. Приглашаем уже на очное собеседование в офис тех, кто +/- верно решил тестовое задание. При этом всем даем обратную связь и возможность решение исправить и прислать повторно. Некоторые присылают исправление и с ними общаемся дальше. Кто-то на этом этапе "отваливается".
4. На собеседовании просим кандидата решить ещё несколько простых задачек по алгоритмам при помощи бумаги и ручки. А также обсуждаем решённые задачи из тестового задания.
5. Если и мне, и тимлиду кандидат понравился по итогам личной встречи (а мы - ему) - делаем оффер и в бой.

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

В подкасте упоминаются:

• t.me/yellow_note - мой канал Заметки 1Сницы. Всё о мире 1С и обучении глазами архитектора 1С и наставника.
• t.me/analyst_1c - чат 1С Аналитик / Архитектор
• Подборка книг для 1С аналитиков
• Как стать РП - прошлый выпуск рубрики "Интервью с 1Сником"

Содержание:

0:40 — Дмитрий о себе. Как Дмитрий стал 1Сником. Первое место работы.

10:55 — А что дальше? Переезд и работа во франче. И чем чревата стеснительность в работе с заказчиком.

15:00— О программировании

19:00 — Стоит ли аналитику изучать разработку? Для чего ему это нужно?

20:50 — Чем отличается джун от Middle+ аналитика. Зачем аналитику консоль запросов и СКД? Что нужно знать, чтобы стать аналитиком? Ключевые навыки.

27:45 — Soft skills аналитика.

36:25 — Личный бренд. Зачем он 1Снику?

45:25 — Напутствия и рекомендации начинающим аналитикам

48:00— Дорос до миддла. Куда дальше развиваться аналитику?

53:25 — Карьерные планы Дмитрия

55:05 —Про работу РП

60:20 — Про чтение книг

Дмитрий, привет. Я не буду тебя представлять, ты сейчас сам о себе расскажешь. И начнем сразу с твоей карьерной истории: начиная с того, как ты попал в 1С, и до момента, где ты сейчас.

Да, здравствуй, Настя. Здравствуйте, зрители. Меня зовут Кучма Дмитрий, я ведущий аналитик компании KORUS Consulting. В компании работаю уже несколько лет (для меня это довольно-таки большое достижение), вырос до ведущего аналитика. Вообще, в сфере 1С я с 2007 года. Довольно давно вкатился, когда это еще не было мейнстримом, да? (смеется) Работаю аналитиком на крупных проектах, в том числе федерального масштаба. Сейчас как раз заканчивается проект, который продлился два года, и перехожу на другой проект. Там мы будем с заморского САПа переводить людей на наш православный ERP, 1С:ERP.

Все по современным трендам)

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

Давай вернемся немного в начало, в 2007 год: аналитиков еще не было.

Не было)

Расскажи немного про самое начало: как это было, почему 1С?

Я выучился на сисадмина, моя профессия звучит как «инженер глобальных сетей». После выпуска работал сисадмином несколько лет и потом стал рассылать резюме (я сам из небольшого городка и решил покорить более крупный город). Стал рассылать резюме по различным организациям на вакансию системного администратора. И в одной фирме мое резюме рассмотрели, позвонили, говорят: «Подъезжайте». Я пока приехал, они говорят: «Знаете, мы системных администраторов уже набрали, у нас есть вакансия программиста 1С». Ну я так прикинул: «В принципе, не боги горшки обжигают и то, что один человек придумал - другой может освоить». Говорю: «Дайте мне месячишко, я посмотрю, что и как, и попробуем». Мне дали диски с программой, с базами. Что-то там “поковырял”, почитал синтекс, помощники всякие, и буквально через месяц вышел, начал работать. Соответственно, вначале мелкие вещи делал: печатные формы поправить и так далее. А потом, буквально за год, уже вырос до такого стабильного middle, смог работать сам, полностью автономно.

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

То есть у людей, даже у руководителей фирм, не было представления, что там программисты делают, как, для чего эти программы. Тогда еще было такое вот отношение у бизнеса: программа нужна, чтобы на штрафы не попасть. Ну и +/- деньги считать: сколько нам должны, сколько мы должны. То есть о таких вещах, как аналитика и управленческие вещи, речи не шло.

Это было в штате, да?

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

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

Я с типовой познакомился только в 2012 - то есть я 5 лет типовые в глаза не видел. (смеется) Приходилось все бухгалтерии, все обновления самому писать, самому разрабатывать. Доходило даже до того, что было какое-нибудь изменение в законодательстве, а с меня уже на следующий день требуют: «Когда у нас в базе будет вот это?» Я говорю: «Да подождите, еще фирма 1С даже не выпустила! Я же тоже не метеор». (смеется). То есть требование было от программиста «давай-давай, бегом все делай».

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

Все в одном, в общем. Да-да-да, так и было, тогда про аналитиков вообще не слышали, а сам ходил, снимал задачу, сам программировал, сам писал инструкцию, сам внедрял. Еще и поднимал сервера.

Я, кстати, на пике своей карьеры уже мог сервер (скольный, не юниксовский) поднять за 4 часа: то есть у меня уже был так наработан навык, что я буквально сервер, как чуть ли не домашнюю винду переставлял (смеется) со всеми настройками скуля, торгового оборудования и так далее. Приходилось все одному делать: не было такой роскоши - что тебе тут отдельно аналитик сидит, задачи ставит, отдельно сисадмин тебе сервер настраивает, как это сейчас , чтобы все было комплексно (смеется).

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

И что было дальше, после этого места работы?

Дальше? Я там работал 10 лет, до 2018 года. Потом решил переехать в Петербург, мне понравился этот город. Переехал сюда. Ну и тоже новые места работы: во франчах поработал, в Первом Бите, кстати. Многие начинают в Первом Бите, меня тоже не миновала эта участь (смеется). Хотя многие справедливо критикуют Первый Бит, мне эта работа дала очень много софт-скилов. Я научился там быть настойчивым в работе. К примеру, когда напишешь письмо заказчику, и тебе не отвечают, неудобно вроде как второй раз письмо писать или звонить (люди же вроде как все взрослые, ответственные - должны ответить). А там приучили: тебе не ответили на письмо — напиши еще раз, не ответили еще раз — позвони, трубку не берут — езжай сам, лично. Потому что там мотивация: тебе деньги платят за закрытые часы. Не закрыл часы - все, до свидания, никаких денег - это очень мотивирует (смеется). Поэтому приходилось и звонить, и писать, и ездить - лишь бы к сроку акт закрыли, перечислили деньги. И вот этот навык - он на самом деле очень в работе помогает. Я научился абстрагироваться (ведь все равно есть природная стеснительность), то есть научился делить это на личное и на рабочее. Если мне что-то нужно по работе, например, добиться от заказчика ответа по процессу, то я подключаю все подряд и получаю от заказчика ответ. Это в проектах очень важно и очень нужно.

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

Ну да, еще говорят: «Ошибка, которая на этапе проектирования допущена, гораздо дороже, чем ошибка программиста». Потому что дальше там уже по цепочке идет: уже другие люди поработали (если мы, например, неправильно требования сняли), и уже все это накапливается.

Естественно, оно идет как принцип домино: ты-ды-дым, и покатилось (смеется). Да, абсолютно правильно.

А на каком этапе ты уже перестал программировать?

Перестал программировать? В Бите я еще программировал, и когда не было задач по аналитике, я тряхнул стариной, так сказать, и базы нетиповые обновлял, и кодил. А потом, когда уже перешел именно на крупные проекты целиком, там оказалось, что практически программировать не нужно, и время на самом деле на это нет. То есть вот это все: общение с пользователями, написание документации, тестирование - оно занимает абсолютно все твое время, даже больше, чем рабочий день зачастую, поэтому там уже программировать просто некогда. И вот где-то с 19-го года я уже не программирую, но хотя иногда. Код - естественно, я все помню. Если в чем-то нужно разбираться, залезаю, читаю. Мне на самом деле в работе очень помогает то, что я бывший программист, потому что, если что-то нужно посмотреть или там какой-нибудь запросик накидать, я не обращаюсь, не отрываю программистов, а могу вполне сам залезть и посмотреть, ну или сделать какой-то запрос. Я даже в своей работе сделал себе такую обработку, которая... Вот как в конфигураторе называется сущности и? Синтаксически как это называется? Настя, подскажи.

Синонимы?

Синонимы, вот-вот! (смеется) И вот накидал себе такую обработку, где сущности по синониму. Было очень удобно потом в ТЗ писать вот с этой обработкой: запускаю ее ERP, смотрю, где что называется.

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

Давай тогда такой вопрос затронем: если у аналитика нет опыта разработки - стоит ли учить разработку, какие-то основы и на каком уровне? Что бы ты порекомендовал?


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

Первое, знать внутренность 1С крайне важно аналитику (именно как работают между собой эти все сущности, справочники, документы, регистры) для того, чтобы писать технические задания, задания программисту. Без этого, я считаю, вряд ли получится написать задание, если ты не знаешь, как изнутри программа работает. Вот это базовое, это обязательно. И опционально знать: как накидать запрос, как работает СКД, как пользоваться универсальным отчетом. Это уже начинающим специалистам может и не нужно, но со временем (когда будет middle, middle+) встанет вопрос о твоем грейде: умеешь ли ты так делать? Если умеешь, значит, ты твердый middle. Если ты это все не умеешь - ну извини, там middle- или джун+ получается по уровню. Я частенько наблюдаю в грейдах различных компаний, что требуется умение пользоваться консолью запросов (даже посмотрите эти описания вакансий - во многих написано, что нужно умение пользоваться консолью запросов, какие-то элементарные запросы делать). Поэтому есть такое базовое понимание системы 1С, ее всех функций взаимодействий, и такая вот опциональная вещь для аналитика тоже важна.

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

Я о чем скажу: к сожалению, сейчас (а может и к счастью - не знаю, для меня пока к счастью) аналитики - это такой штучный продукт, на самом деле. То есть вот я, насколько смотрю, (сколько есть курсов там и так далее), вот так, чтобы массово и стабильно выпускать аналитиков - ну просто не получается. Потому что склонность к анализу — это склад ума. Не все люди могут читать тексты. Не все люди могут читать длинные тексты. И еще меньше людей могут такие длинные тексты писать. У нас были такие проекты, где только техническое задание было 3500 страниц (это, конечно, не один аналитик). Но вот я лично пишу ТЗ, на текущем проекте у меня были на 50-75 страниц технические задания, это прочитать и понять не все могут, а написать еще меньше.

Конечно, есть много споров - творческая это профессия или нетворческая - ну как у программистов, согласись (смеется). Про программистов тоже говорят, что это творческая профессия, другие говорят - что нет, есть четкие правила, и можно по этим четким правилам писать и голову не морочить.

И поэтому склонность у людей есть, элементарный анализ. Я даже несколько статей написал для Инфостарта, где вот как раз и описал начало пути аналитика, кому в этом деле будет проще: проще тем, кто знает предметку, кто уже работал в этой области. Вот, допустим: бухгалтерам перейти в аналитику бывает зачастую проще (или экономистам), чем просто вчерашнему студенту, который только знает техническую часть хорошо, где-то там в институте/в колледже их научили алгоритмам, показали приемы разработки на различных языках - Python, JS и так далее. Ничего не зная в отрасли, вряд ли такой вчерашний студент сразу станет хорошим аналитиком. Вот хорошим программистом (ну, по пути программиста) он может сразу пойти: потому что ему дают задание, и он знает, как это делать, он видел приемы.

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

И, соответственно, первая часть знаний и умения аналитика - это все-таки техническая часть: знание конкретно какого-то решения от 1С. А почему именно одно решение? Потому что они сейчас становятся очень большие и очень заточенные под какую-то отрасль, есть даже отраслевые решения: Альфа Авто, например, для автосервисов и автосалонов, управление автотранспортных предприятий, документооборот, ЗУП, бухгалтерия (бухгалтерия сама по себе - это большой блок). И получается, аналитики затачиваются под какое-то конкретное решение. Поэтому, когда начинает человек смотреть, думать - стать ли 1С-аналитиком - ему надо выбрать еще и дорогу конкретную, куда он пойдет, есть у него какое-то понимание или нет. Это вот первая часть, что нужно аналитику, техническая именно.

А вторая - это уже такие софт-скилы, то есть мягкие навыки: это умение проводить интервью, умение проводить совещания, умение презентовать разработки; умение общаться с различными людьми и так далее. Это вторая часть навыков аналитика, и вот этому уже гораздо сложнее научить. То есть если вы не имеете опыта публичных выступлений, не умеете презентацию какою-то делать, то как вы будете сдавать разработку? Представьте: ко мне иногда приходили на сдачу разработки по 40 человек, и как минимум у десяти из них были различные мнения по поводу, как эта разработка должна работать. Представьте, если они начинают вдесятером спорить, и это мнение даже между ними самими не стыкуется (смеется). И провести качественно этот показ или встречу, чтобы выцепить оттуда рациональное зерно, чтобы потом написать протокол (а в протоколе там буквально может быть три строчки: вопрос “такой то, как будет вот это функционировать”, а совещание шло 2 часа). И вот чтобы эти три строчки в протокол выцепить из двухчасового совещания: тоже, согласитесь, навык нужен.

По первости, когда я был на таком совещании (когда не я вел), иногда просто был в шоке: как из такого объема противоречий, информации (для меня это было просто “разговаривают все со всеми, спорят все со всеми”) что-то рациональное выцепить? Мне казалось, это прям такое космическое умение (смеется). А вот люди, которые давно уже с таким работают - они спокойно после этого совещания выцепляли рациональное, писали протоколы. И вот я тоже такому учился: надо систематизировать и выцеплять то, что нужно, уметь вести это собрание - чтобы там спор не ушел в какие-то космические процессы (что «вот мы там через 10 лет хотим, чтобы так то работало»), надо людей приземлять («давайте решим, как сейчас будет это работать»). Вот этому тоже надо учиться, но этому учиться сложнее, потому что курсов нет (таких вот явных), нет каких-то четких правил. На это все смотрим, наблюдаем и учимся у старших опытных товарищей.

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

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

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


Да, бывает на запуске (вот я еще в холдинге работал, запускали новый супермаркет) вплоть до того, кому документы печатать, понимаешь? И вот эти вопросы приходилось решать именно IT отделу (смеется). Бригадир говорит “Идите нафик, у меня своя работа”, оператор говорит “Я тоже свои работой завалена, я не хочу идти реестры печатать какие-то” и приходилось, как третейский судья, приходить:
—Так, печатать будешь ты.
—А почему?
— А потому что я так решил.

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

Ну да, чем больше проект - тем больше организационных изменений.

Да, я тоже слышал такое мнение. Вот взять нашего ближайшего конкурента — САП, который сейчас наконец-то уходит и 1С этому сильно рад. (смеется) Там какой подход? Что процессы предприятий гнут под программу. То есть говорят: «У тысячи предприятий такие же процессы, значит, у вас будет работать так же».

А у 1С наоборот: 1С (за счет того, что она гибкая, ее можно запрограммировать как угодно) подстраивает программу под процессы, то есть здесь ровно наоборот ситуация. И опять же (когда ситуация, как в САП, бывает странная), мне говорили такое мнение: «Представьте, фирма занималась чем-то, и был какой-то процесс. Автоматизировали ее, поставили программу и говорим, что теперь у вас этого процесса не будет, потому что в программе его нет или он не такой». Ну это странная же ситуация, правильно?

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

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

Ну да, интересное замечание. Наверное, еще хочется затронуть тему личного бренда, она сейчас тоже популярная. Ты достаточно публичный человек: пишешь статьи, выступаешь на конференциях. Давай немного поговорим про личный бренд: зачем он вообще нужен 1С-нику, что он даёт? Ты, например, зачем этим занимаешься?

Спасибо, интересный вопрос. Я подсознательно это чувствовал, но по полочкам для себя не раскладывал. Но как-то посмотрел на Ютуб выступление Серебряной пули. Если помните, была такая компания, которая делала всякие расширения для 1С, то есть они именно работали тем, что какие-то там недокументированные возможности использовали, расширение делали и так далее. И одно из выступлений было на тему: как любой специалист вообще развивается в своей профессии.

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

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

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

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

Вот из последних такое для меня было открытие — перевод видео в тексты с помощью искусственного интеллекта. Я этим заинтересовался (даже ,наверное, в этом году позанимаюсь, попробую такое сделать на практике), потому что на самом деле очень полезная штука: когда ты ведешь двухчасовое видео, которое сразу не поддерживает транскрибирование разговоров (перевод в текст), то потом (чтобы найти какую-то тему, которая была в течение двух часов поднята) надо опять 2 часа эти практически пересмотреть. Это дико много времени тратит, я категорический противник такого времяпровождения, да и одно и то же пересматривать по 5 раз — удовольствие ниже среднего. А перевести все это в текст и по тексту найти — милое дело. Я целиком за такое и поэтому заинтересовался, думаю, надо такие вещи освоить. И периодически вот такое узнаешь, в плане профессионализма.

И чтобы нас знали в отрасли. Отрасль у нас маленькая относительно: по различным чатам, по различным конференциям - плюс-минус одни и те же лица (смеется), один же и тот же набор специалистов (редко бывает, чтобы внезапно какой-то новый знакомый). Такие знакомства очень полезны, потому что коллеги и помогут и подскажут. Я тоже помогаю, подсказываю. Ко мне в личке очень много обращается аналитиков по разным вопросам: фирма хорошая/нехорошая - оценить (хотят устроиться на работу и не знают про фирму). Я про многие фирмы знаю, про многие слышал, поэтому могу (хотя бы +/-) сказать: «лучше сюда идти или туда». В плане зарплаты, опять же, спрашивают («предлагают столько-то, это адекватно или нет?»), я оцениваю, стоит аналитик этих денег или нет, потому что я могу подсказать: «подтяни вот такие-то вещи, чтобы действительно этой зарплате уже твердо соответствовать». Ну и спрашивают по работе какие-то вещи, как это сделать - тоже подсказываю.

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

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

Тем, кто начинает, я желаю успешного освоения (прежде всего) этой профессии. Любая профессия - она живет, пока приходят новые и молодые участники, сеньорами сразу никто не становится. Компании, у которых нет джунов, у них не бывает сеньоров. Когда вы “заходите”, профессия, конечно, может показаться сложной и неоднозначной. Но, как и любая другая профессия, она осваиваемая. Я рекомендую найти какого-то ментора или устроиться в организацию, где уже выстроена система доведения новичков до самостоятельной работы. Это вам очень поможет. То есть у людей уже есть практика такая, вы не первый и не единственный, и они помогут вам возрасти.

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

Супер. И кстати (если возвращаться к вопросу про рост, про возможные пути), давай немножко про тебя: есть ли у тебя карьерный план, если не секрет?

Да-да. У меня, конечно, есть карьерный план. Я каждый год его пересматриваю (к концу каждого года смотрю). И вот сейчас я стремлюсь в сторону РП.

У меня был опыт управления, уже 12 аналитиков в пике, и мы довольно эффективно такой командой отработали: сделали техническое задание, все разработали. Мне такой опыт понравился, на самом деле. И вот я в ту сторону стремлюсь - именно в сторону РП. Функциональные архитектуры тоже, конечно, интересно и здорово, но, честно сказать, когда они на запуске не спят ночами - мне что-то не сильно такое нравится, я поспать люблю. РП вроде как часов 7-8 на запуске спит, а функциональный архитектор не спит, вот исходя из этого (смеется). Коллеги есть у нас внутри компании: оценивают навыки сотрудника, куда развиваться, и вот посоветовали все-таки в сторону РП расти. Вот будем туда двигаться, посмотрим, насколько там плюшки сладкие (смеется).

Про РП, кстати: у меня было недавно интервью с Алексеем Бояршиновым (собственник своего проектного франча). У нас была тема разговора этому посвящена: кто такой РП, как им стать. И после разговора с ним (я и так знала, что я не РП, немножко в другой сфере)...

Четко понимаешь, да?

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

Ну, покой нам только снится. Естественно, у нас в проектной деятельности, я скажу тебе так, покоя практически нет (смеется). Но в чем прикол? В том, что проекты заканчиваются. У меня один функциональный архитектор спрашивает: «Почему ты именно в проектной деятельности, а не куда-нибудь на фикс ушел?» Я говорю: «Мне нравится именно то, что проекты заканчиваются». То есть каждый проект - это, считайте, что в отдельной фирме работал: поработал у них, все настроил, автоматизировал, уже заскучал было и тут раз - другая фирма, а там уже свои люди, свои процессы. И, соответственно, этим интерес к проффесии подогревается, к своей работе. Вот, как-то так. Посмотрим, это же не одномоментно, не сразу все. К этому годами надо готовиться и идти потихоньку, мелкими шажочками.

Я, кстати, сторонник фундаментального подхода - то есть изучаю сначала все. Вот я накупил уже себе книжек («Искусство войны» Сунь Цзы, «45 татуировок менеджера»), то есть я уже собираю такую библиотечку, именно управленческую. И скажу, что там интересные мысли о чем-то, я бы даже рекомендовал такое почитать.

Даже если вы не хотите в РП, а просто работаете аналитиком, то почитать очень полезно в плане того, чтобы понять, как руководство принимает решение, что оно от вас хочет, ваше место на проекте и в организации в целом. Это тоже очень важно понимать. Я приведу пример: говорит РП аналитику написать мемо о встрече (мемо - это просто краткий такой пересказ о том, что решили). А он говорит: «Я не ремесленник, я профессионал, надо написать протокол по встрече» (а протокол, чтобы вы знали, написать хороший, день надо, пересмотреть все видео, чтобы понять, какое приняли решение, участников оформить - ну не день, но часа четыре ты убьешь). А на мемо ты потратишь минут 20 максимум.

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

Если идет уже проект и ты видишь какой-то косяк, то да: выскажи, обоснуй, аргументируй. РП люди. Как я говорю: рот для того, чтобы договариваться, а не только для того, чтобы есть. Выйди на РП, объясни, обоснуй ему это. Люди поймут в основном люди понимающие, не дураки. А если просто на ровном месте «я эксперт и все, до свидания»: за твою экспертность денег не заплатит заказчик. Извините, эта экспертность ровным счетом не принесет пользы ни фирме, ни тебе.

Поэтому читайте книжки, очень рекомендую. Сейчас вот купил Никиту Зайцева книжку, начал читать. Интересно, хотя книжка больше для разработчиков. Но там и в целом: как снимать требования, что с ними делать и так далее. То есть в этой части аналитикам вполне даже интересно почитать и ознакомиться.

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

Вот даже элементарный приведу пример: книга “Как мыть слона”, про дизайн интерфейсов. Вроде как 1С от дизайна интерфейсов далек, это и вендор говорит: «У нас платформа все сама рисует, какие там интерфейсы? Вот смотрите, как надо: в типовом это все сделано - так и делайте. Но я ради интереса почитал эту книжку, и вот какую вынес оттуда одну из ценных мыслей: никогда невозможно сделать все идеально, вот просто невозможно. То есть то, что ты сделал вчера - посмотришь сегодня, и окажется, что это было плохо, хуже, чем ты сегодня это видишь. Он говорит, что если подходить с такой точки зрения, то ты ни один проект никогда в жизни не запустишь, ни одна программа не заработает и так далее. То есть ты будешь ее улучшать, улучшать и улучшать до бесконечности.

Но представьте: архитектору заказали здание, он нарисовал архитектуру, и начали строить, а через год он бы посмотрел (он уже возрос, как архитектор, у него какие-то новые знания, новое видение) и он сказал: «Здание плохое, давайте перестраивать», но так ни одно здание тогда невозможно возвести. Вот ты даже, как технический архитектор, тоже ведь постоянно возрастаешь, как специалист. Новые какие-то тренды, новые веяния. Да вон даже сама фирма 1С: у них резервирование было, потом вернули регистр накопления опять. То есть нет предела совершенству, получается (смеется). То есть в разное время смотрят на резервирование по-разному. Если упереться в это резервирование и сказать «вот пока не будет идеального, мы не будем запускаться», можете проект сразу закрывать, попрощаться и сказать «подождем идеального». Но можно и не дождаться.

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

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

Да, спасибо. Тоже интересно, не читала эту книжку, посмотреть надо.
Да, пара мыслей есть интересных.

Дмитрий, наверное, вопросы мы с тобой все обсудили. Спасибо тебе за беседу.
Спасибо тебе, очень интересный был опыт.

Ссылкой на чатик твой поделимся. Но я думаю, большая часть моих подписчиков уже там присутствует.
Может кто-то новый на ютубе посмотрит, к примеру. Да, подключайтесь, у нас там весело. Сейчас мы в основном технические темы там обсуждаем, потому что аналитики поговорить любят (смеется). И настолько любят, что пришлось чат делить на два. Выделили отдельный чат с флудилкой (основной чат оставили все-таки более-менее с техническими темами), чтобы людям было где пообщаться: во флудилке активно общаются, по 200-300 сообщений в сутки (смеется).

1С АНАЛИТИК / АРХИТЕКТОР — чат для общения специалистов по автоматизации на платформе 1С:Предприятие и всех причастных.

Ко мне иногда обращаются с запросом "Как найти первую работу в 1С без опыта?". Звучит почти как блогерская фраза "Меня часто спрашивают..." Но и правда спрашивают.

Основной совет один - откликаться и ходить на собеседования.
Если сходили 1-2 раза и вам отказали , совет второй - откликайтесь еще. Записывайте вопросы, на которые не знали ответ, разбирайте их и идете снова. Вопросы будут повторяться, так или иначе.

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

• может вы участвовали во внедрении, переходе на новую программу, даже если проект был небольшой и/или не на 1С, если претендуете на позицию аналитика;
• может быть вы помогали другу и написали для него какую-то обработку на 1С, которая облегчила его работу, если вы - начинающий программист.

Если пока страшно идти на реальное собеседование - найдите ментора для начала, попросите провести тестовое собеседование и дать обратную связь.

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

Так что, прочь неуверенность. Есть еще и второй фактор, противоположный, - завышенные финансовые ожидания на старте. Но про них как-нибудь потом отдельно.

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

Если надо было бы выбрать один совет: пишите конкретно проект, вашу роль на проекте и что вы сделали (сделали, а не делали). Все эти "работал работу", "делал доработки" , "разрабатывал отчеты и обработки" - мало о чем говорят.
А вот если попробовать использовать глаголы совершенной формы - "Сделал/разработал отчет" - то сразу напрашивается пояснить - а какой отчет? Для кого, для чего?
Кстати, если до этого не задумывались - для чего та или иная задача, какой смысл бизнесу в нем, то самое время начать.

Это актуально для тех, переходит из другой сферы.
Даже если вам кажется, что опыта нет - возможно, вам это кажется. Иногда ко мне на консультацию приходят люди, у которых в резюме ни слова про 1С: "мне нечего написать". Начинаешь копать - выясняется, что есть чего..
Если, допустим, работали бухгалтером/кем-угодно и...
- Ставили задачи своему программисту (или компании-подрядчику)? Указываем
- Обучали коллег, помогали с настройками 1С? Указываем
- В компании внедряли не-1С систему, но вы опять же во внедрении участвовали - ставили ТЗ и т.п? Ну вы поняли, тоже указываем.
Вспоминайте всё, что может быть релевантно.

Кстати, знали, что на первичный просмотр вашего резюме HR тратит 5 секунд?

Собрала для вас посты про резюме от Анны, вот что нашла:

1. Чек-лист - что и как писать в резюме
2. Еще немного про резюме
3. Еще пост для тех, кто в поиске с парочкой советов

Подписчица Ирина (Ира, привет!) подняла интересную тему "Как ставить задачи программисту".

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

Например , приходим к программисту с "ТЗ":
"Добавь реквизит Статус в заказе".
Есть "программисты"-кодеры, которые просто сделают, что попросили, без лишних слов.
Опытный программист спросит: "А зачем?" (Или мой любимый вопрос "Чтобы что?")
И тут начинается самое интересное, выясняется, что нужно хранить , допустим, историю этих статусов, статус должен проставляться автоматически в зависимости от фазы Луны или настроения директора и так далее.

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

Наткнулась на статью Дмитрия Кучмы
Книжный клуб: подборка книг для 1С-Аналитиков

Полностью согласна с выбором книг по управлению требованиями:

• «Разработка требований к программному обеспечению», Карл Вигерс
• «Принципы работы с требованиями к программному обеспечению», Дин Леффингуэлл

Еще от себя из "классики" на эту тему добавила бы

• "Современные методы описания функциональных требований к системам" А. Коберн

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

• Путь аналитика. Практическое руководство IT-специалиста», В. Иванов, А. Перерва

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

Остальные из рекомендованных не читала. Кое-что взяла на заметку себе

Еще от себя добавила бы, именно для начинающих аналитиков:

Итак, давайте сначала разберемся, что же такое - чистый код?

Поможет нам Роберт Мартин и его книга "Чистый код. Создание, анализ и рефакторинг".

Грэди Буч: "Чистый код прост и прямолинеен. Чистый код
читается, как хорошо написанная проза. Чистый
код никогда не затемняет намерения проектировщика"

Дэйв Томас "Чистый код может читаться и усовершенствоваться другими разработчиками, кроме его исходного автора."

"На самом деле соотношение времени чтения и написания
кода превышает 10:1. Мы постоянно читаем свой старый код, поскольку это необходимо для написания нового кода. Из-за столь высокого соотношения наш код должен легко читаться, даже если это затрудняет его написание"

"У бойскаутов существует простое правило, которое применимо и к нашей профессии:
Оставь место стоянки чище, чем оно было до твоего прихода"

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

Про 1С, отличные статьи на Инфостарт:

Последние две пока не читала, лежат в списке к прочтению. "Чистый код" читала, в следующем выпуске вернемся к нему и порассуждаем, что мы можем оттуда почерпнуть применительно к нашей родной 1С.

Пока готовится к публикации наша беседа с Алексеем о том, кто такой РП, вот вам книжные рекомендации от него:

• PMBOK Классика жанра и основа основ.
• Scrum. Революционный метод управления проектами
• Настольная книга project-менеджера
• Человеческий фактор

Deadline. Роман об управлении проектами

Кстати, последние 2 книги входят в Мой личный ТОП 10 книг про ИТ, бизнес и около.
И автор у них один - Том ДеМарко

Как вы могли заметить, в списке нет ничего про 1С. Из "1С-адаптированного" могу порекомендовать к изучению:

• Технологии внедрения от 1С. Входят в ПрофКейс, точно доступен франчайзи, а если вы на стороне заказчика - тут надо узнавать.
• Введение в управление проектами внедрения ERP-систем

После недавного опроса про выгорание решила порекомендовать пару книг, которые сама читала и кое-что почерпнула.

Советов давать не буду, кроме одного: рекомендую этот вопрос решать , лучше раньше, чем позже и лучше с специалистом, чем без него.

А книги такие:

• Книги Елены Резановой, их 3 штуки
• "Никогда-нибудь" - про поиск себя и про откладывание мечт "на потом" (то есть на никогда)
• "Это норм" - про то, что карьерные кризисы это нормально (и неизбежно)
• "Работа, которая заряжает" - про то, как не выгорать на любимой работе

• И специально для тех, кто хочет все бросить и открыть свою кофейню, в комментах были такие: на сайте МИФа можно почитать ее статью по мотивам одной из глав "Никогда-нибудь" Вирусные мечты или почему мы ищем себя подальше от того места, где потеряли
• Депрессия и выгорание. Как понять истинные причины плохого настроения и избавиться от них. Эта от врача. Подробно описывает причины таких состояний. Иногда дело может быть банально в нехватке определенных минеральных веществ в организме или даже непереносимости некоторых продуктов.

Рассказываю, как найти работу в конкурентной среде, где на вакансию приходит 100 откликов, а на просмотр резюме HR тратит 5 секунд. Этот подкаст будет полезен выпускникам или людям, которые меняют сферу деятельности.

1. Пишите нешаблонные сопроводительные письма.
Внимательно прочитайте описание вакансии, обратите внимание на требования и напишите ваше сопроводительное письмо адресно. Также укажите вашу мотивацию: почему вы откликнулись на данную вакансию.

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

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

Узнавайте также причину отказа или долгого молчания после собеседования.

Когда я искала работу и получила от HR шаблонную фразу «Мы вам перезвоним.», мне стала интересна причина. Я написала руководителю, проводившему собеседование, с просьбой дать обратную связь. Меня пригласили на встречу, где обсудили мои слабые и сильные стороны. После этой встречи мне прислали оффер.

3. Не сдавайтесь!

Когда мне было 18 лет, я работала оператором в кол-центре на холодных звонках. На стене висел плакат с надписью «Чтобы сделать одну продажу, нужно получить 9 отказов». Каждый отказ приближает вас к успеху. Я знаю историю, когда понадобилось 50 попыток прежде, чем найти работу. Но ведь оно того стоило!

Сегодня мы собрались с Владимиром поговорить про ИИ. Тема заезженная, но мы решили поговорить вот в каком контексте: Правда ли, что поздно начинать изучать разработку в 2026 году, что джуны никому не нужны, их заменят нейросети, которые уже решают задачи джунов.

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

Да, мы здесь состыковали наш опыт и решили им со всеми поделиться.

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

Во-первых, не хочу никого пугать. С другой стороны, не хочу никого и совсем уж обнадёживать. На самом деле, доля правды в этом есть. И если посмотреть на статистику, правда, статистику США, то за последние несколько лет занятость молодых разработчиков - 22-25 лет - упала на 20%. При этом занятость разработчиков [с опытом] более 10 лет, наоборот, выросла.

То есть виден тренд, что молодые разработчики как будто бы меньше нужны, а те, кто уже с опытом, наоборот, более востребованы. Здесь нет прямой корреляции, что это возникает именно из-за ИИ. Кроме того, нет статистики по РФ. Повторюсь, это статистика США. Но, тем не менее, это заставляет задуматься. Возможно, какая-то часть истины в этом есть.

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

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

Работа разработчика - это не только код. По данным телеметрии, статистике различных IDE, разработчик занимается написанием кода в среднем 15% своего рабочего времени. Остальное время он тоже что-то делает, да? Если задуматься, что мы ещё делаем? Общаемся с заказчиком, постановщиком, тестируем функционал. Выполняем проектирование функционала. То есть, не только пишем код.

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

И тестирование - то же самое. Да, это тоже в каком-то виде можно сделать автоматически, но не всегда и не во всём.

Задач меньше не становится. Скорее всего, сейчас будет становиться даже больше. И если говорить, что мы джунов теперь отменяем, они нам не нужны - а кто эти задачи будет делать? Да, предположим, ИИ будет делать. Но его нужно контролировать. Предположим, у нас есть разработчики мидл, они эти задачи, которые когда-то делал джун, должны теперь все взять. Я по своему опыту сужу. Мне, например, сесть и сделать три задачи одновременно уже довольно тяжело. Когнитивная нагрузка и переключение - не бесплатные, они имеют стоимость с точки зрения затрат сил. В итоге, три задачи одновременно делать уже тяжеловато. Я хотел бы, наверное, взять на себя какие-то сложные задачи. Самые простые всё-таки дать джуну, который будет их делать.

Вопрос только в том, как он будет делать. Я себя сейчас представляю в роли работодателя. Если придёт молодой [разработчик], который говорит: «Да, у меня опыта мало, продуктовой разработкой я ещё не занимался, сам особо не сопровождал 1С. Но я знаю, как установить Cursor, как связать его с 1С. И какой-то опыт у меня уже в этом плане есть, я уже что-то умею». И приходит другой джун, который говорит: «Я вообще ничего не умею». Интереснее будет поработать с тем, который в новые веяния начинает включаться, и сможет, скорее всего, больший эффект и результат показать, чем тот, который пока только вкатывается в это дело, и такого опыта у него нет.

С точки зрения 1С, я - уже опытный разработчик. Иногда делаю какие-то проекты на Python’е, которого я вообще не знаю. С этой точки зрения можно сказать, что я джун в нём, но, тем не менее, у меня что-то получается, об этом ещё чуть позже поговорим.

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

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

Пока тебя слушала, у меня несколько мыслей в дополнение возникли.
Первое - это про возраст. То, что ты говоришь, что меньше молодых, больше 30+. Применительно к сфере 1С, если есть выбор взять условно студента, которому 20 лет, и человека 30+ или 40+, но у которого уже есть опыт в бизнесе: бухгалтерия, финансы - в какой-то предметной области, которая релевантна нашим проектам, то я бы взяла этого второго человека 30+. Потому что, применительно к 1С, кроме того, что ты можешь писать код, который уже за тебя ИИ, очень важно понимать саму задачу. Как раз то, что ты говорил: понять, что пользователь хочет, и дальше уже понять, как сделать это в 1С.

И, собственно, так изначально было, когда мы с тобой довольно давно начинали разработку. Когда программисты были и аналитики, и знали предметку: ходили с МарьИвановной-бухгалтером пить чай и обсуждать её потребности. В какой-то момент всё сместилось к узкой специализации: появились аналитики, программисты, и появилось целое поколение программистов, которые просто пишут код по ТЗ.

Я у себя в «Заметках…» писала такую мысль: мне кажется, это - первые кандидаты, кого можно заменить ИИ. Мы сейчас не берём людей на уровне 1С-эксперта - высокого уровня спецы, которые занимаются производительностью и, условно, могут себе позволить только техническими вещами заниматься. Такой условный мидл, который говорит: «Дайте мне ТЗ, я сделаю точно по букве, как напишите, не буду думать». Мне кажется, это как раз кандидаты на вылет.

Тема с софт-скиллами набила оскомину, как и тема с ИИ, но это та вещь, в которой нас нейросети пока что не заменят.

Да, всё верно, так и есть. Софт-скиллы - это вещь, которая с ИИ не связана. Это - сама по себе ценность, которая есть независимо от того, знаешь ты или не знаешь [что-то], владеешь или не владеешь написанием кода - она уже тебя делает ценным специалистом, это однозначно.

А что ты думаешь по поводу такой существующей сейчас проблемы: представим, я - начинающий разработчик 1С. Курсы прошла, условного Радченко прочитала. Есть такая определённая демотивация у начинающих: зачем мне усилия вкладывать? Учиться писать код, учиться писать оптимальные запросы по стандартам, если я просто могу закинуть в ИИ: «Напиши мне такой-то запрос,» и она его пишет. Как с этим быть?

Дело в том, что она, если напишет код, то напишет, скорее всего, даже правильно. Даже не то что правильно - код будет рабочий. Но он не будет оптимальным. Там не будет изначально по стандартам, даже если её попросить: по стандартам пиши. Не факт, что модель из коробки сразу сообразит, чего же ты хочешь.

Знаешь, этот вопрос можно немножко переформулировать так: а чем вообще может ИИ быть полезен джуну? Если он только начинает, зачем ему всё это осваивать? Но осваивать-то нужно в любом случае, потому что без контроля из этого ничего хорошего не получается, как сейчас показывает практика. Без контроля, без экспертизы человека.

Если приходит в профессию молодой специалист, который только, как ты говоришь, Радченко прочитал, может быть, не нужно сразу же кидаться за то, чтобы просить ИИ писать код. Можно начать с того простейшего варианта - разбираясь в задачах, когда какие-то вещи не до конца понимаешь, в режиме обычного чата (я не говорю сейчас про какие-то IDE с языковыми моделями), а просто обычный чат GPT - поспрашивать у модели вопросы, которые ты не понимаешь. Может быть, человеку тебе их немножко стыдно задать, потому что кажется, что вопросы глупые. Модель-то она всё стерпит. Ей можно любые вопросы задавать. Попросить её: объясни такой-то момент, поищи в интернете и объясни мне, как это работает, или как с этим быть, как это устроено. И в итоге тихонечко повышаешь свою экспертизу, начинаешь собираться. И потом уже, если ты переходишь к написанию кода, то есть уже к разработке, то делаешь это гораздо более осознанно.

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

Я приведу пример из личной практики. У меня небольшой open-source проект есть по предоставлению моделям доступа к базам 1С. И у него есть небольшая часть, написанная на Python’е. Когда я его разрабатывал, я немного представлял, как Pythonработает, но не глубоко - какие-то библиотеки Python’овские я, конечно, не знал. И я решил сделать его полностью с помощью Cursor’а, чтобы он мне полностью его подготовил. Я же это делал не так, что: ты мне там напиши хорошо, а плохо не пиши. Чтобы поставить задачу тоже нужно иметь, скажем так, наработанную интуицию. Как это правильно делать, как это сделать так, чтобы получить тот результат, который ты ожидаешь. При этом не зная стека, но имея базовое понимание того, как строится система, получилось построить.

В итоге код написан, читать его мне довольно тяжело. Я не знаю, что там Cursor написал: хорошо он написал, плохо написал, хорошая там архитектура или плохая. А чтобы разобраться, я начинаю смотреть эти модули и прям чуть ли не каждую строчку модель спрашивать: а тут что делается? А здесь зачем так? Да, а это почему так работает? Точно ли так работает? А здесь ты не ошибся ли?

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

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

Вот к чему мы идём. Пусть даже код будет сгенерирован кем-то, моделью, но вы можете в нём разобраться. Я говорю сейчас про джунов, но не только - про любых специалистов. Взять за него ответственность. Вы понимаете, как он работает - да, он работает правильно. Я за него отвечаю - я смогу, если что, его поправить, возможно, опять-таки вместе с моделью, с Cursor’ом. Я это так всё вижу.

В любом случае, не нужно смотреть на то, что код напишет Cursor. Отвечать за него всё равно должен будет человек. Поэтому тут вопрос: как добиться того, чтобы понимать код, который будет написан, и как ему доверять. И, повторюсь, брать за него на себя ответственность.

Здесь, наверное, ещё такой тезис. Я вижу, что как раз ИИ может помочь в самом процессе обучения. Да, мы можем у него спрашивать, как ты приводил пример с Python: «Почему здесь так?». И если такая задача стоит, то ты в процессе можешь свои знания по Python’у прокачать. Я сейчас у Perplexity такой режим обнаружила: «учись шаг за шагом» (или study mode в английском). Как раз когда ты закидываешь тему, например: я джун, хочу научиться писать запросы 1С-ные. И она с тобой в режиме диалога по кускам выдаёт информацию, в конце задаёт тестовый вопросик на понимание. Такая имитация режима наставника.

Мне кажется, такое интересно. Я даже пробовала: закидывала иногда вопросы, когда готовила задания к курсу. У меня сейчас есть история, эксперимент, где я учу 1Сников программированию с нуля. Я до этого учила уже тех, кто какую-то базу получил. А сейчас с нуля. И там бывают такие вопросы, на которые сходу нет ответа. Потому что, когда ты уже давно в этой теме варишься, [есть] эффект неосознанной компетентности. Из серии: а вот почему есть отдельно процедуры и функции, если можно функцию использовать как процедуру, вызывать? Допустим, как человеку объяснить, учитывая, что действительно, в принципе, ты можешь функцию вызывать как процедуру, это работает. Объяснить, например, смысл процедуры и функции. Или ещё что-то такое.

И мне тут ИИ помогал. Я закидывала, говорю: объясни мне, пожалуйста, на пальцах, как новичку. И он какие-то примеры [выдавал].

Я объясняла, почему не надо код писать в одно такое большое полотно. И в чём смысл логических разделений на функции. Например, она мне выдала рецепт борща: пошагово нарезать овощи, сделать то, сделать это. Классно, я бы сама такое не придумала.

Или задание, я там делала сквозной пример: мы разрабатываем свою конфигурацию. Задание я придумала сама, а потом просто закинула в Perplexity и попросила расписать более подробно, чтобы это понятно было новичку, который первый раз решает такую задачу. И тоже точно получилось лучше, чем я бы это [делала] сама, без помощи.

Да, у меня та же самая история. Мы с тобой из сферы образования, про курсы всё знаем. Когда свой курс готовил, обычно в части примеров я просто показываю практические задачи, которые я реально для клиентов решаю. С ними проблем не было. А вот теорию как к этому подвести и как так изложить грамотно, чтобы это было действительно любому понятно, вот это, знаешь, непросто –всё это логично выстроить.

Сидишь, общаешься [с ИИ]: давай вот эту тему с тобой обсудим, давай так сделаем. Перечитаешь - нет, я тут не понимаю, как это переделать? В таком диалоге вместе с достаточно умным помощником устраивается какая-то структура, и ты потом на неё смотришь и думаешь: я раньше сам так на это не смотрел, не так это понимал. Тут так всё логично, хорошо получилось. И в итоге уже можно это в работу пускать, в курс выкладывать. Поэтому [ИИ] не только для разработки, но и просто для упорядочивания информации и её переформулирования так, чтобы это стало понятно конкретно тебе. Потому что у каждого свой опыт, каждому близки какие-то свои примеры. В этом плане языковые модели сильны, много чего могут.

С другой стороны, важно не попадать в определённые ловушки. Ты или я в теме более-менее разбираемся, поэтому мы можем понять, модель правильно посоветовала что-то или нет. Лучше, чем то, что мы знаем, или хуже.

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

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

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

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

И в итоге главное - это не то, как выглядит этот код. Важно то, чтобы ты его понимал. О чём я чуть раньше и говорил: важно пойти прямо по отдельным строкам, если ты совсем ничего не понимаешь, и начать выяснять, как это работает, как это связано с другими, не ломает ли это что-то. Нужно быть таким, как бы сказать, въедливым. Таких людей другие люди, может быть, и не любят - они слишком прикапываются к каким-то деталям и т.д. Модели всё равно, она на все вопросы ответит.

Поэтому надо быть въедливым и постараться добиться того, что ты чётко всё понимаешь: что сделано, как работает и т.д. Занимает достаточно много времени, чтобы в чём-то разобраться. И без модели это займёт у вас времени не меньше. Если, предположим, нет у вас Cursor’а, нет ничего. Вы сели в голом конфигураторе, вам надо код написать. Что делать? Обложиться книжками, интернетом, в Google искать какие-то инфостартовские вещи, пытаться в них разобраться. Будете примерно то же самое делать, только более витиеватым путём. А тут вам сразу же какая-то заготовка, в которую просто надо погрузиться и из неё уже формировать что-то более соответствующее тому, что нам нужно получить.

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

Получается, по большому счету ничего не меняется в процессе. Опять же, я начинающий программист, или даже не начинающий. Я тоже сажусь писать код. А бывает, что я что-то забыла, например, как мне передать таблицу с клиента на сервер. И что я раньше делала? Я шла в Google, и мне выдавали какую-нибудь ссылку, например, на Mista или на Infostart, на форумы. Или если мы говорим не про 1С, а большое IT, это был какой-нибудь сайт StackOverflow, где 100% есть уже твоя ситуация, кто-то её решил. Мы смотрим этот форум, там есть пример кода - это чей-то код. Я копирую себе этот код. Если я начинающий, я могу просто не думая скопировать и посмотреть, работает / не работает.

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

Получается, сейчас то же самое - просто я иду не в Google, а спрашиваю у нейросетки.

Может даже спросить у неё, чтобы она сходила в Google и поискала всё, что нужно. Самостоятельно у вас это займёт больше сил: проанализировать несколько источников, всё это как-то свести. Модель вам сразу выдаст уже такой скомпонованный готовый отчёт. Вот, посмотрел там, там, решение такое.

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

Это тоже такой важный момент - просто спросить у модели, не прося её в интернете всё поискать. Perplexity всегда опирается на данные поиска. Если мы работаем с ChatGPT, скажем, или Claude моделью, то он не обязательно пойдет в интернет. Он, может быть, и сам выдаст своё решение. И, когда модель не опирается на какие-то источники, тут больше вероятность, что она что-то напридумывает. Поэтому такой интересный важный приём есть: если тема сложная, особенно такая специфическая, узкая, то один из лайфхаков - спросить модель не просто ответить, а сходить в интернет, изучить вопрос и потом ответить.

Ещё момент: когда модели обучают, то у обучающей выборке, на которой модель училась, обычно срез знаний довольно несвежий. Год назад, может быть, полгода назад - в лучшем случае. Тут эта проблема отпадает: модель пойдёт, посмотрит в интернете. Можно уточнить, что нужно смотреть самые последние источники, и она придёт к вам уже со свежей информацией. С тем, что сейчас актуально, а не было актуально год назад. Так что это - тот же поиск в интернете, только другим способом, скажем так.

Да, это хороший прикладной совет. Хочу зафиксировать: спросить именно источники и перепроверять информацию по источникам.

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

Я читала такую интересную историю про StackOverflow. В последние годы резко упал трафик на этом сайте, потому что люди стали ходить в нейросети, не туда. И сейчас они зарабатывают на том, что свою наработанную базу знаний продали вендорам-разработчикам этих моделей. И у них всё хорошо с финансами: они не закрылись, не обанкротились. Но дальше у меня возникает вопрос: вот всё прекрасно, но сейчас, получается, эту базу знаний никто не пополняет. Никто не пишет вопросы-ответы на форуме. И что будет через какое-то количество лет, когда этих источников, по сути, не останется?

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

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

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

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

Мне кажется, это так работает. Поэтому такой уж большой проблемой не будет, что теперь сместилось общение со StackOverflow в чат с ChatGPT, условно говоря.

Интересный вопрос. Посмотрим, что будет. Получается, информация просто становится платной? То, что раньше было бесплатным.

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

Продолжение

Практикум-погружение в работу программиста 1С - Практический курс от Анастасии, переход от "теорию знаю, но опыта нет" до Junior+

"1С-разработка с ИИ" - Не менее практический Курс Владимира для действующих программистов 1С (от Junior+)

Предлагаю перейти к более практической части и что-то посоветовать именно начинающим разработчикам. Вот я изучила того же условного Радченко, но я далека от того, чтобы использовать 1С:EDT, 1С:Напарник. Что мне делать, с чего начать погружение в чудесный мир ИИ?

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

Это не отменяет того, что, чтобы уже реальные задачи решать, идти в компанию и начать работать, уже какая-то база у тебя внутри должна быть наработана. Как бы ты ни был с ИИ хорошо знаком, у тебя уже в голове модель системы должна быть. Это как раз про, что у тебя есть курс для тех, кто не совсем начинающий, но уже хочет в практику погрузиться, реальные практические задачи попробовать. Без этих знаний прийти и начать что-то делать не получится. В любом случае, базу - Радченко и т.д. - нужно освоить. Без неё перейти к практическим задачам бывает тяжеловато.

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

Я рекомендую начинать с Cursor’а: поставить Cursor, выгрузить вашу базу, конфигурацию. Здесь уже гораздо интереснее становится. Когда мы первый раз открываем в конфигураторе типовую, у некоторых чуть ли не паника возникает. Потому что куча справочников, документов, что они делают, для чего нужны, как с этим всем работать. А у тебя какая-то практическая задача, и как тебе это всё доработать? Или разобраться нужно, или доработать. На этом этапе модели могут очень существенно тебе помочь. Я говорю сейчас даже не про написание кода, а просто про то, чтобы научиться разбираться в том, что у тебя есть в твоей работе или в компании, в которую ты устраиваешься или собираешься устроиться. Ты можешь в чате кодового агента просто задать вопрос: как работает такой документ? С чем мне разобраться, чтобы встроить такой-то функционал? И он уже сможет сам походить по исходникам, по выгрузке, разобраться и тебе дать отчёт. Если тебе он непонятен, ты уточняешь: «Мне непонятно, объясни по-другому». Или: «Вот эта часть непонятна, давай сюда погрузимся», или «это всё не то, поищи ещё раз».

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

Ещё раз: начать можно просто с чата. В чате, в режиме поиска уточнять с моделью какие-то вещи, которые вам не очень понятны или в которых хотелось бы разобраться. Когда уже базовое понимание есть, можно поставить кодовый агент Cursor, выгрузить конфигурацию, в которой вы собираетесь работать или работаете. И вопросы, которые у вас по ней есть, задачи пытаться уже решать не в чате с ChatGPT, у которого нет никакого контекста вашей конфигурации, а в том же Cursor. Там точно такой же чат, но у него уже есть контекст: выгрузка, которую вы сделали, исходники конфигурации, структура. И он сможет вам более прикладные советы давать. Я пока не говорю про доработки кода. Начать хотя бы с этого: просто учиться общаться с моделью.

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

Я расскажу такую историю. У меня есть помощник, который начинал осваивать языковые модели. Один наш клиент-бухгалтер пишет: «Смотрите, у вас тут ошибка. У меня должно это поле так заполняться, а оно заполняется не так. Исправляйте». Помощник тогда ещё только начинал использовать Cursor - как ему пользователь сказал, он так же Cursor’у и написал: есть ошибка, она управляется так и так, её надо исправить. Модель - она как джин, которому ты озвучиваешь желание. Он его выполняет, но понимает его по-своему, и в итоге получается не то, что ты хочешь. И здесь получилась такая ситуация: модель сожгла ему какие-то миллионы докетов, переписала кучу типовых модулей, чтобы эту ошибку исправить. И помощник очень расстроился, потому что это совсем не то, чего он хотел.

Мы с ним начали разбирать диалог, как модель всё решала, потому что она выводит по ходу решения всё, что она делает. И мы видим, что в самом начале её первая фраза была, что в типовом функционале так не предусмотрено, так оно не работает, что пользователь вообще-то был неправ, что всё заполнялось как нужно. Но раз уж ты мне написал, что это ошибка и что надо её исправить, я буду исправлять. И она пошла перепахивать эти модули.

В итоге, задача вышла очень дорого, и решение изначально было неправильным. Просто потому, что нужно было правильно сформулировать запрос. Не "исправь ошибку", а "разберись в ситуации". Видите - одно слово, два слова - и совершенно другой результат.

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

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

Да, так и получается.

Ещё хотела спросить насчёт чатов. Есть ли смысл использовать бесплатные модели или нужно сразу искать платные варианты?

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

Действительно, есть DeepSeek, который без проблем можно открыть в любом регионе без всяких дополнительных ухищрений и с ним поработать. Есть ChatGPT, модели Claude, которые так просто не откроешь и не используешь. Проблемы начинаются с того, чтобы по адресу зайти, и оканчивая регистрацией.

Если говорить про какие-то бытовые вещи, не касающиеся работы 1С, то здесь можно пробовать разные. Можно пробовать ИИ, которые ты используешь: тот же самый DeepSeek, Qwen и т.д. Но если мы говорим конкретно про нашу область, про 1С, то здесь по моему опыту нет конкурентов моделям компании Anthropic: Claude Sonnet, Claude Opus. Они рассчитаны на разработчиков, на корпоративных заказчиков. И они на удивление неплохо ориентируются в платформе, и в типовых конфигурациях некоторых что-то знают, и в синтаксисе 1С, и в терминологии платформы. Как будто бы общаешься действительно с 1Сником, с 1С-разработчиком. С другими моделями может быть по-разному: когда-то получше, когда-то похуже. Но в целом, в среднем, похуже.

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

С Алисой пока кодить на 1С не получится.

Не получится, и даже со сберовской моделью может не получится. У меня не получалось пока. Хотя знаю, что Сбербанк работает над своей моделью, старается, и 1С тоже пытается в обучающую группу включать. Может быть, в ближайшем будущем что-то изменится. Пока что мне кажется, Claude Sonnet выдаёт результаты лучше.

Ждём. Всё-таки технологии не стоят на месте.

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

Первое: я спросил, и она мне какую-то ерунду ответила. Я тоже так начинала. Это были бесплатные модели. И второе возражение: когда люди пытаются что-то сделать, и им ИИ не помогла, потому что она не понимает контекст. У меня был опыт только использования в режиме чата. Я как раз ощутила, что вот тут очень важен контекст. Сейчас с твоей подачи загрузила просто выгрузку конфигурации XML. Я ещё даже не дошла до этапа MCP-сервер настроить. [Загрузила] сами исходники конфигурации, и это уже прямо разница налицо.

Ты очень верно сейчас про контекст говоришь. Это ключевая вещь. Смотрите: вы – 1С-специалист, поймали вы на улице, скажем, самого умного доктора наук, и спросили его, как мне что-то там закодить. Что он вам ответит? Он совершенно не погружён в ваш контекст. Не знает, чем вы занимаетесь и т.д.

С моделями та же самая ситуация: откуда она знает вашу компанию, ваши задачи, конфигурацию? Всё это нужно ей дать.

Первый шаг - это то, о чём ты говоришь: выгрузить конфигурацию XML. Следующий шаг, ты упомянула его - MCP - дать доступ модели в базу, чтобы она могла не просто в исходнике посмотреть, а залезть в саму базу данных и посмотреть её структуру. Выполнить запросы, данные получить, заглянуть в журнал регистрации и т.д. И здесь такой вау-эффект получается: когда отдаёшь модели исходники, она уже тебе более осмысленно начинает отвечать конкретно по твоей конфигурации. Думаешь: «Да, неплохо». А тут уже следующий уровень: модель не только что-то на исходниках пытается объяснить, а конкретно на данных твоей базы.

У меня даже есть такой кейс, я его недавно на конференции показывал, где модель полностью решила вопрос пользователя. Получилось так: пользователь нашел ошибку в отчёте. Он пишет, что тут сумма такая получается, а должна быть другая. И скорее всего, это из-за того, что не тот вид цен подхватывается. Мне некогда было разбираться. У меня окружение уже настроено: подключены MCP-сервера, я пишу прямо в рабочую базу заказчика. Я просто перекинул сообщение пользователя в чат с моделью и потом вернулся посмотреть, что произошло.

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

То есть даже пользователю не удалось её сбить своим предположением. Она сама нашла правильную причину. И говорит, что исправлять. Я удивился, и говорю: «Давай исправляй». Она сама в запрос внесла исправления. И, там достаточно серьёзно всё настроено, сама закачала уже собранный отчёт клиенту и даже загрузила его в рабочую базу. И я просто написал пользователю: «Получается так? Проверь». Проверил - всё нормально, всё работает.

Если идти по ступеням освоения ИИ-агентов: начинаем с чата. Потом у нас идёт работа с контекстом выгрузки конфигурации - уже достаточно неплохо, но это не конец. Можно идти дальше и дойти до такого уровня, когда у вас уже решаются задачи. Но этот вопрос был, скажем честно, сравнительно простой. Он и человеком решается довольно быстро. Просто сам эффект такой получился, что даже включаться не пришлось в это.

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

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

Пока твой рассказ звучит достаточно опасно - модель сама в рабочую базу всё подгрузила. А как все эти страшные истории про то, что у людей нейросетка удалила прод, удалила все архивы, бэкапы и т.д. Как с этим быть?

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

Плюс кодовый агент, который я использую, а это Claude Code. Он - локомотив кодовых агентов, который за собой тащит всё остальное. Всё самое новое появляется в нём. И в нём есть режим, когда он в процессе работы сам контролирует те вещи, которые мы сейчас делаем: они опасны или нет. Если они опасны, он их сразу же сам зарубает. То есть, какой-то уровень защиты он обеспечивает прямо из коробки. Поэтому я ему более-менее доверяю. Понимаю, что надо быть осторожным.

А случай, когда [агент] фотоархив удалил, или вообще диск D удалил - это Паша Чегодаев показывал: "Наведи мне порядок на диске D". И вот он показывает чистый диск. Ничего нет!

Идеальный порядок!

Да! Тут тоже к вопросу с джином. Надо уметь формулировать свои задачи, свои желания так, чтобы их правильно поняли. Одной строкой "наведи порядок" модели задачи ставить не надо. Вы должны зафиксировать видение, что вы в результате хотите получить, как это должно выглядеть. А не оставлять это видение - пусть модель сама решит, как должно быть.

Ты такую ситуацию рассказал, когда был вопрос от пользователя, и если бы мы без нейросетки решали, мы бы пошли в базу, что-то посмотрели, в конфигураторе бы посмотрели, как оно работает. Когда я была джуном, я так и училась. Потому что я попала во франч, там, естественно, разные конфигурации. Я считаю, что основная моя база в 1С, которая следующие 15 лет позволяет мне быть в теме, это первые 2 года во франче, когда я получила опыт с совершенно разными конфигурациями. Меня сегодня на ЗУП отправляли, завтра на УПП и т.д. И это как раз то, что давали джуну: посмотри, почему здесь не работает, или сделай печаточку, тут поправь что-то. Такие простые вопросы. Сейчас вроде как их забирает на себя ИИ. И возможно, условному тимлиду или ведущему разработчику где-то быстрее кинуть это ИИ, как ты это сделал, а не поручать эту задачу джуну. Вопрос: как же тогда мне, как джуну, развиваться, на каких задачах, где их брать, чтобы стать мидлом, сеньором и т.д.?

Я вижу тут два основных подхода. Они больше не от джуна зависят, а от работодателя, который пытается развивать у себя джуна.

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

Но я думаю, что это не единственный способ. Можно пойти немножко по-другому. Способ, который я чуть раньше озвучивал: джун пусть использует инструмент искусственного интеллекта, решает эту же простую задачу, про я которую говорил: почему не та цифра выдаётся. Он кинул в ИИ, она результат выдала. Но как ты можешь ей доверять, если отвечаешь за этот результат всё рано ты? Ты же не скажешь потом, если ошибка есть: «А мне Cursor сказал, я руки умываю». Нет, так не пойдёт.

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

Если подумать, мы привыкли, что есть такая старая школа, что все так учились. А теперь с новыми инструментами вроде бы этого уже не надо. И так ли это плохо, если у тебя этого навыка ручного не будет? У меня нет здесь однозначного ответа. Может быть, и нет. Может быть, у тебя просто другой должен быть навык – навык допытаться у модели и понять, правильно она сделала или нет. А не [навык] того, чтобы это всё сделать вручную. Ты можешь с моделью добиться того, что она тебе скажет, как это вручную проверить, если уж ты совсем дотошный. Она выдала результат, ты у неё спрашиваешь, как мне перепроверить вручную. Она тебе дала сценарий, ты пошёл, это сделал и тоже что-то освоил.

Это второй подход: когда джун работает с моделью, использует модель как своего рода ментора. Она тебе подробно объясняет всё. Не так, чтобы она тебе всё сделала, ты поверил и переслал дальше результат. А чтобы ты получил результат и вместе с моделью подробно разобрался, как вообще это верифицировать, и вместе с ней это сделал. В итоге ты тоже получил знания. Они немножко другие. Получил навык, он отличается от того, как если бы ты делал руками. Но хуже ли этот навык? У меня нет точного ответа, но я думаю, что нет. Почему бы этому навыку и не быть таким, если в будущем у нас уже такой большой необходимости и не будет. Может, даже в будущем у нас уже конфигуратора как такого не будет. Вендор нам сделает какой-то MCP-сервер, условно говоря, и мы сможем полностью разработку вести через модели.

В чатике.

Да. У тебя, может, и не будет такой возможности зайти в конфигуратор, что-то вручную посмотреть. Я не говорю, что это будет сегодня-завтра, но в какой-то перспективе.

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

Здесь я с тобой соглашусь, и мне как раз второй вариант больше импонирует. Ты рассказывал про первый вариант, когда мы ограждаем джуна от ИИ и заставляем делать всё руками, у меня на это есть своя история из жизни. Не про ИИ, про джунов. Когда я ещё работала во франче, я собеседовала джунов. Это были очные собеседования в офисе, ещё до ковида. Я им давала просто листочек с ручкой и просила написать запросы на листочке. Руководствовалась тем, что если ты не можешь это так на листочке написать без конфигуратора, то, наверное, ты не очень хорошо понимаешь язык запросов. И потом я поменяла своё мнение по этому поводу. Потому что поняла, что нужно проверять те навыки, которые реально будет человек в работе использовать. Мне же не нужен программист, который умеет писать код на листочке.

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

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

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

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

Главный месседж, который я хотел бы донести в нашем с тобой мини-подкасте: искусственный интеллект, хотим мы этого или нет, будет захватывать всё новые и новые области. Сейчас он достаточно серьёзно захватывает область генерации контента, изображений, программирования, потому что это везде генерация текста. И как бы мы к этому ни относились, это объективная действительность. С этим надо мириться.

Расстраиваться, что я в IT не вошёл 10 лет назад, и теперь мне ничего не светит, не стоит. Просто стоит смотреть на это в таком ракурсе, что джуны, какими они были условно 5 лет назад, сегодня они такими уже работодателю не очень интересны. Но интересны другие - те, которые начинают ИИ-инструменты использовать, осваивать, и не просто как некую волшебную палочку, а осознанно. Если говорить про обучение, то используют не просто как решатель задач, а как наставника, который ускоряет твой рост. Не как костыль, который рост останавливает, а который действительно помогает.

И если ты это умеешь, то, мне кажется, тебе в любом направлении сейчас гораздо больше двери открыты, чем если закрывать на это глаза и думать, что это хайп, который пройдёт. Хотя бы начать с освоения чатов. Если чаты вы уже осваиваете, если вы уже более-менее в платформе ориентируетесь, попробуйте поставить Cursor, выгрузить конфигурацию. Потратьте на это время. Может, у вас не полчаса-час, а чуть больше займет с этим повозиться. Но я вас уверяю, что эффект, который вы в итоге получите, потом многократно перекроет те затраты времени на освоение, которое вы сейчас вложите. Поэтому не закрывайте на это глаза. Осваивайте и внедряйте в работу. Это практика. Попытайтесь всё это именно на практике применять, в своих рабочих задачах. Тогда эффект будет таким, что сами удивитесь.

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

Совсем уж джунам, наверное, тяжеловато будет. Потому что я этот курс ориентирую на начинающих в ИИ-разработке, но уже имеющих какое-то представление о платформе 1С.

Я объясню почему. У меня довольно много уроков, где я просто беру и полностью решаю задачу 1С-ную. Если ты вообще ничего про 1С не знаешь, не представляешь себе, как в конфигураторе что-то сделать, какие объекты платформы есть, и т.д., то будет тяжеловато. Поэтому мой курс рассчитан уже как минимум на джун+ - того, кто уже представляет себе, как устроена платформа и имеет хоть какое-то представление о том, какие задачи 1Сники решают. Задачи несложные мы решаем, поэтому быть крепким мидлом или сеньором совсем не обязательно. Примеры достаточно простые, жизненные, обычные обработки, которые мы напишем: обмен данными, загрузки заказов с сайтов - такие вещи. Джун+ - это минимум.

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

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

Владимир, спасибо. Я думаю, много интересного у нас прозвучало за этот час. Кто ещё не подписан на канал Владимира, ссылку оставим в описании к этому подкасту. Можно там ещё много интересного почитать.

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