Comments 25
Кажется надо было хоть как-то текст отредачить в плане выделения абзацев и тп....
Спасибо за статью. Я лично не могу (пока) представить себе сценарий, чтобы ии заменил аналитика. Промп для ии по своей сути и так является тз, а его ии пишет мягко говоря плохо. История из разряда «напиши мне тз для системы бухучета для 1000 сотрудников и завода» даст примитивный результат в виде черновика-структуры, над которым придется работать. И тут вопрос, а какой смысл писать грамотный структурированный запрос, когда уже проще сделать тз?
По наличию в штате. Конкретно в моем опыте, лучше пусть 1 человек будет отвечать на все вопросы по бизнес логике/требованиям системы, чем мучать лидов, которые не имеют привычки документировать в клерко человеко понятном виде информацию. И заставлять условную лп лезть в джиру и искать таску, где (из-за отсутствия того самого аналитика) в таске понятные только для разработки две строки и описание взаимодействия сервисов будет странно и не продуктивно.
И верно отмечено, что аналитик всегда был универсальным инструментом в компании. ИТ не панацея, эти товарищи могут и в другую сферу пойти.
ну логика здесь такая (пересказываю по памяти, могу ошибаться):
сейчас аналитик это некий промежуток между заказчиком и программистом. ТЗ дает заказчик, значит это он свои хотелки закинет в нейросеть и выдаст ТЗ, причем ТЗ будет подробным, со всяким артефактами, которые сейчас аналитики даже не всегда делают, типа диаграмм ER, юзкейсов и т.д. Далее программист (вайб-кодер) будет закидывать это в нейросеть и получать работающий код (или не работающий, тогда программист его доведет до ума).
В целом понятно, что такая модель не жизнеспособная. Аналитики на проектах нужны в основном не для того, чтобы ТЗ оформлять и диаграммы рисовать, я поэтому и указал, что роль аналитика шире и ИИ не заменяется.
Нейросети инструмент, позволяющий аналитику делать больше, в случае если у аналитика скилл промт-инженера, заменить аналитика ии сможет лишь отчасти, по крайней мере пока. Спасибо за статью.
Пояснение для тех, кто варится только в аналитической тусовке, и не слышал разговоров, что аналитики не нужны.
Есть один известный в узких кругах специалист, Иннокентий Бодров, который неоднократно озвучивал, что аналитики не нужны и делал доклады с такими названиями. Мой пост - это как бы ответ ему и тем, кто его слушает...
Да, говорил и продолжаю говорить. А ответ получился каким то совсем не убедительным, ну или вы больше себя убеждаете)
Особенно про затычку интересно получилось - мне вот как раз всегда как-то не нравилось быть затычкой)
Насчет дешевой замены разработчику тоже спорно - оклады практически сравнялись, если у вас не так, у меня для вас плохие новости.
Лоу код оставим в стороне - там не аналитик нужен, а специалист по внедрению, профессия смежная, но отдельная.
Вайб-кодинг - тут полезно инженерное мышление, но аналитик как раз становится совсем не нужен, ТЗ писать не надо)
Так что, повторюсь, ответ достаточно спорный)
Ну про затычку - это просто констатация факта, а не цель в будущем.
Оклады сравнялись, но специализации то никуда не делись, дешевле нанять специалистов по отдельности, чем одного хорошо делающего и то и другое.
Ну так во многих компаниях специалист по внедрению это и есть аналитик. Если должность называется специалист по внедрению, значит ещё делает работу аналитика. Если должность аналитик, то занимается и внедрением.
Ну и лоу-код это же не про внедрение, это и постоянная кастомизация.
Но зачем тогда преподавать по направлению СА, если считаете его ненужным? Да, вероятно прибыльно, так как востребовано, но насколько это честно по отношению к другим и прежде всего к самому себе?
Согласен, абсолютно не честно.
Поэтому, во первых, я уже не преподаю по направлению СА.
Мой курс, который я создал и 4 года вел на Отусе выгодно отличался от других именно там, что давал не только базу по СА, но и фактически перенаправлял аналитиков в сторону архитектуры и проектирования решений.
Все мои текущие учебные проекты направленны в сторону продуктового и бизнесового развития для аналитиков и технических специалистов.
Так что я считаю, что я абсолютно честен с аудиторией
Ну если у заказчика скиллы аналитика и он сам знает чего хочет и ТЗ составить может, и принять разработку и внедрить, то аналитик и впрямь ненужная прослойка. В каких-то проектах, типа доделать сайт, проще заказчику напрямую с прогером общаться.
А в сложных системах, где доработка одной функции влияет на другие объекты - тут уже сложнее. Работала я как-то в конторе, где были только программисты в отделе, заказчики-пользователи к ним напрямую шли. Кучеряво там жили программисты - заказчик просит сделать какую-то дичь, программист делает, не спрашивая "зачем?". Что-то ломается от славной доработки, программист чинит - короче все при делах полгода. Через полгода выясняется, что эта доработка и нафиг никому не нужна. Ну а там на очереди следующая такая же задачка, зарплата на карту падает, больше ничего и не нужно таким прогерам.
Самая лучшая ситуация, когда вообще участвует только один человек - разработчик какого-нибудь ОПО. Сам себе ставит задачи, сам программирует, сам проверяет. С этим я хорошо знаком, поскольку разрабатываю свою ЛИМС -JDX.
Далее уже возможен вариант, когда есть отдельно заказчик и отдельно программист или несколько программистов.
Ну и дальше с ростом вовлеченных людей, появляется роль аналитика или продакта, а также тестировщика и т.п. При этом производительность каждого в отдельности падает. Можно целую отдельную статью про это писать.
вот тут вы подсветили проблему сломанных процессов. По факту - аналитик, это просто затыкание дырки в процессе лишним человеком, про это автор и писал.
Это простой и в моменте дешевый способ.
Стратегически более верно будет вовлекать разработчика в бизнес процессы. Но для этого надо нанимать разработчика, а не кодера)
Стратегически более верно будет вовлекать разработчика в бизнес процессы. Но для этого надо нанимать разработчика, а не кодера)
а это дороже, значит возвращаемся ко второму пункту про стоимость.
Ну и много ли разработчиков мечтают погрузится в бизнес процессы и общение с пользователями, особенно когда бэкендом занимаешься? Это получается ты и чтец и жнец и на дуде игрец, когда только еще код успеваешь писать. Особенно рекомендую погрузится в процессы отдела бухгалтерии)) А отделов в организации довольно много и везде свои процессы, которые меняются и за этим нужно следить.
Конечно мечта работодателя - это разраб, который во все вникнет, всё поймет с полуслова и быстро сделает, и не нужно дармоедов-аналитиков нанимать)) Я даже таких видела! Только они перегорали нафиг через год такой работы. Где найти еще таких, которые перегорать не будут, и чтобы был прогер-аналитик-тестировщик-продакт-внедренец в одном флаконе, не знаю.
Вы не поверите, но 1С начинался именно с разработчиков, которые садились вместе с бухгалтером и настраивали\дорабатывали.
Перегорают обычно от оверлоада, а не от разнообразия задач, тут тоже проблема в процессах
И не надо того, кто все все умеет, просто и разработчик и инженер по качеству должны понимать, что и как они делают для бизнеса, тогда и бизнесу будет сложно всякую дичь пропихивать. Заметьте, разработчик и инженер по качеству, а не кодер и тестировщик. И да, им аналитик не нужен, они сами умеют головой думать
Стопудов таким аналитик не нужен. Да если бы на рынке были такие разработчики и если бы заказчик свою потребность сам выявлял и мысли формулировал, тогда дармоеды- аналитики как класс не возникли бы вообще.
Но где эти бриллианты-разрабы? Пруд пруди кодеров, которые вникать в процесс не хотят(утомительно это), а заказчики не то что задачу сами поставить не в состоянии, а даже сказать на словах что им нужно не могут. Вот так вот из-за нежелания людей думать (и брать на себя доп. нагрузку) и появились аналитики
А вот тут https://habr.com/ru/articles/982974/ снова говорят, что нужен переводчик с бизнесового на ITшный
Зачем нужны аналитики?