Могу накинуть за/кроме автора :) Не экзотика, просто обыденность, но может будет интересно. Экспозиция - серверная разработка, спутниковое вещание, все довольно абстрактно и запутанно.
Заказчик однажды честно сказал, что не понимает ничего (в одной монструозной фиче один из самых погруженных в технику менеджеров заказчика так прямым текстом и написал :) Поэтому к докам стали прилагать короткое описание с самыми основными тезисами. Не истории/кейсы, а чтоб понятно.
Одно время была благородная попытка дизайнеров вести все макеты для всех UI серверных продуктов. И из постановок картинки экранов от аналитика типа убрать (везде ссылаться на id элементов в макетах). На очередной 1001 однообразной таблице умер очередной дизайнер и было принято волевое решение ограничиться UI kit и вернуть картинки экранов от аналитика
Тексты UI с переводами. Тоже боль, 100500 похожих текстов с переводами на 100500 похожих таблиц. В какой-то момент при переносе очередного текста из доки с требованиями в гит умер очередной фронт разработчик. В итоге теперь тексты UI аналитики льют в гит сами, переводы текстов из постановок убрали.
Вечная борьба текст-диаграмма. Одно время все алгоритмы дублировались диаграммы-текст. В какой-то момент умер очередной аналитик в попытке актуализировать 1001 диаграмму. В итоге количество диаграмм в постановках сильно сократилось, победила исчерпывающая полнота текста и таблиц. Но менее наглядно, да
Статья хорошая, а вот заголовок плохой :) Как показывает жизнь - если ни у кого нет вопросов, то это дурной знак, т.к. никто толком ничего не читал и не осмысливал. Значит все пойдёт "по бороде" при разработке (в лучшем случае), тестировании (уже хуже) или эксплуатации (ваще караул)
Так этой "идее" с ГТЭ на базе авиационных двигателей уже 100 лет в обед как бы. Обычно они и вправду на природном газе работают, но и двухтопливные (природный газ/дизельное топливо) камеры сгорания тоже вполне бывают. Я уж не говорю про ГТЭ "неконверсионные", т.е. изначально разрабатывавшиеся как наземные. Очередная нейросетевая "новость"?)
тут есть такой момент, что аналитик может вообще такими вещами и не заниматься - например, когда спеку в open api генерирует разработчик прямо в коде Т.е. сильная зависимость от того чем именно занимается аналитик и много ли на нем автоматизируемой рутины Если таковой почти нет, то пока нейросетям там вроде как ловить и нечего. Можно конечно заставить их погенерировать кейсы, но тут мне не удалось выхлопа получить
Мое мнение - нейросеть может отрисовать что-то, когда и так уже все понятно. При этом вопрос еще хорошо ли это, т.к. когда рисуешь что-то "руками", то неизбежно возникает момент рефлексии, приводящий к пересмотру и улучшению результата. А вот когда ничего не понятно (но очень интересно) и надо синтезировать решение, удовлетворяющее всех и вся (а это 99% полезной работы аналитика), то тут я слабо представляю что может предложить нейросеть. Отсюда и мало кейсов :)
А я как раз на этом "красивом" считал аэродинамику :) Надо сказать, что по мировым меркам кластер Политеха уже сильно устарел. Но по меркам РФ он и вправду неплох, особенно по сравнению с большинством промышленных (там где они вообще есть).
Вообще прототип в большинстве случаев можно накидать из квадратиков и кружочков прямо поверх существующих макетов или даже скриншотов и это дело 1-2 дней. И заказчику сразу все становится гораздо понятнее. Это из личного опыта аналитики всяких абстрактных и сложных для восприятия API Gateway или генераторов DVB таблиц
Могу сказать, что пользовался Perl года 4 назад - писал скрипты для обработки результатов расчетов газодинамики в постропроцессоре ANSYS CFX :) Так что вполне еще живой, но да, Пайтон конечно удобнее
А вы точно про РФ, где ДМС в принципе довольно редкое явление? Про найм иностранных специалистов (не СНГ) - аналогично :) У нас по-моему больше актуальны вопросы общения с военкоматом или подарки детям сотрудников на НГ. Ну да, это можно эйчарам доверить, хотя как показывает практика того же чата ит-отсрочек, немало случаев когда эйчар тупо забыл нажать кнопку, а потом человек отправляется в армию
От HR может быть польза только если вам надо найти и нанять N кассиров/разнорабочих. Если же вы ищете квалифицированных инженеров, то толку от HR с гулькин нос. Максимум извлекаемой пользы - поставить встречу в календаре, да передать кандидату список документов. Всем остальным нужно заниматься тимлиду (в простонародье начальнику отдела), ибо даже поиск по ключевым словам это недоступное HR знание, ибо они либо просто не знают нужных, либо не умеют их правильно интерпретировать. Все это конечно сугубо личный опыт, основанный на эмпирических данных, начиная с отсмотра студентов на 3 курсе, заканчивая поиском матерых профи в навозной ку... на хэхэ.ру
Как сотрудник возможно той же самой компании с "телевизионными приставками" безусловно соглашусь, что разбираться нужно :) Действительно, оборудование (и не только оно) часто имеет ограничения, которые оказывают огромное влияние на архитектуру всей системы. Для спутникового ТВ это жёсткие ограничения на весь служебный трафик и отсутствие обратной связи от клиентских устройств. Для автомобилей - автономная работа, резервирование, безопасность и тд и тп Верно и то, что это все эти знания могут оказаться ненужными, тк такой специфики в проекте просто нет) Но кажется, что именно этими знаниями, опытом и кругозором преимущественно и можно оценить "синьорность" аналитика.
Может я вас расстрою, но за 10 лет работы инженером по расчетам турбин ГТД я использовал интегралы 0 раз. Даже для диссертации ктн не пригодились. Ещё с коллегами сокрушались - как так, все учили и не понадобилось в итоге, ибо все давно автоматизировали. И я сейчас не уверен смогу ли это дело вспомнить и применить где-то. Понятно, что обучение влияет не впрямую, но в реальности больше пригодился русский язык, как ни странно)
Вам очень повезло) У меня двойняшки 3+ и это ад, конфликты и ор. Не, они конечно играют друг с другом, но не долго. Все очень сильно от самих детей зависит, причем даже не от воспитания, а от врождённых черт характера.
Поддержу, у нас аналитики просто пишут внятные описания api в свободной форме (обычно таблички в конфе) со списком входных/выходных параметров, действий и ошибок. И потом вместе с тестировщиками проверяют через swagger ui, что все сделано корректно. Не, ну можно и на аналитиков повесить делать api через editor, но мне кажется, что более разумно посвятить это время на улучшение качества аналитики или проработку большего количества фич)
Весьма скептически отношусь ко всяким универсальным советам, т.к. жизнь это все опровергает на раз-два :) Как по мне, надо в первую очередь ориентироваться на адресатов этих требований, слушать и слышать их реальные нужды и чаяния. Например, заказчика от бизнеса волнуют в требованиях одни вещи, команду разработки другие, еще и вкусовщина примешивается. Про атомарность и краткость - за все хорошее, но тоже часто не работает. Иным личностям надо написать 5 раз одно и то же разными словами, чтобы они это все-таки прочитали и сделали как написано. И хоть ты тресни. В целом - в каждой избушке свои погремушки, т.е. задача аналитика - достичь некоторого консенсуса, чтобы желания бизнеса трансформировались в продукт с приемлемым для бизнеса результатом. И в каждом конкретном случае форма этого консенсуса будет очень даже своя. Из универсального - описывая требования к фрагментам системы, очень неплохо бы не забывать делать это же самое для всей системы как единого целого. А то фичей на компоненты напилят, а что в целом то должно происходить большинству так и не ясно.
LBA/LBA2 - визуал, атмосфера, геймплей из области фантастики. И самое прекрасное, что никто так и не покусился на ремейк) Всякие спектрумы/денди тоже были, но как-то из той эпохи ничего особо не отложилось
Работал в компании где было наоборот - делали ПО для управления расчетами ГТД. Все аналитики и инженеры были у нас, разработки не было, ей занималась другая компания. Но конечно совсем без разработки не бывает, это факт)
Тут зависит от команды, ситуации и продукта. Есть команды, в которых аналитик описывает только пользовательские сценарии и ui. Есть где аналитик расписывает все таблицы, все api, все внутренние вспомогательные сценарии (типа того как отбирать задачу в очереди задач) и весь ui. В последнем случае аналитик в целом владеет картиной по системе на достаточном для понимания и объяснения (!) другим людям уровне. Про выполнение роли аналитика архитектором имхо есть пара нюансов:
Вот не все могут качественно. Лично переделывал требования за двоих архитекторов - у одного образовалась жуткая помойка из фич с кучей "воды", которой при масштабной переделке системы оказалось невозможно пользоваться. У другого был просто поток сознания и проблемы с орфографией и пунктуацией. В основном до аналитиков надо просто дорасти с точки зрения масштаба проекта, либо необходимости человека с глубокими познаниями в специфичной области.
Архитекторы часто могут начать трактовать требования заказчика "в свою пользу". Вот тут как раз и может пригодиться аналитик, который более нейтрален и для которого архитектор является только одним из источников требований.
На профиль в хабре со статусом "Не ищу работу", з/п 300к, лычкой senior и опытом примерно 4 года в один февральский день написали 5(!) рекрутеров разом (в среднем в феврале-марте порядка тех же 5 в неделю, преимущественно финтех и ритейл, сейчас поток подсхлынул)
В итоге пара офферов на эту сумму
В целом, кажется, что указанные суммы более-менее в рынке, сужу по своему опыту и боту getmatch. На hh не ориентировался вообще
Описанная проблема характерна не только для it, но и например для инжиниринга - использование высокоуровневых абстракций (трёхмерных конечно-элементных расчетов) привело к тому, что многие инженеры забили на физику и расчеты в 1д (на бумажке, в Экселе и тд) при этом совершенно не интересуясь какие ограничения есть у физических моделей в новомодных "черных ящиках" и как там все работает. Компуктер посчитал и все ок. И так оно много где.
Могу накинуть за/кроме автора :) Не экзотика, просто обыденность, но может будет интересно. Экспозиция - серверная разработка, спутниковое вещание, все довольно абстрактно и запутанно.
Заказчик однажды честно сказал, что не понимает ничего (в одной монструозной фиче один из самых погруженных в технику менеджеров заказчика так прямым текстом и написал :) Поэтому к докам стали прилагать короткое описание с самыми основными тезисами. Не истории/кейсы, а чтоб понятно.
Одно время была благородная попытка дизайнеров вести все макеты для всех UI серверных продуктов. И из постановок картинки экранов от аналитика типа убрать (везде ссылаться на id элементов в макетах). На очередной 1001 однообразной таблице умер очередной дизайнер и было принято волевое решение ограничиться UI kit и вернуть картинки экранов от аналитика
Тексты UI с переводами. Тоже боль, 100500 похожих текстов с переводами на 100500 похожих таблиц. В какой-то момент при переносе очередного текста из доки с требованиями в гит умер очередной фронт разработчик. В итоге теперь тексты UI аналитики льют в гит сами, переводы текстов из постановок убрали.
Вечная борьба текст-диаграмма. Одно время все алгоритмы дублировались диаграммы-текст. В какой-то момент умер очередной аналитик в попытке актуализировать 1001 диаграмму. В итоге количество диаграмм в постановках сильно сократилось, победила исчерпывающая полнота текста и таблиц. Но менее наглядно, да
Статья хорошая, а вот заголовок плохой :) Как показывает жизнь - если ни у кого нет вопросов, то это дурной знак, т.к. никто толком ничего не читал и не осмысливал. Значит все пойдёт "по бороде" при разработке (в лучшем случае), тестировании (уже хуже) или эксплуатации (ваще караул)
Так этой "идее" с ГТЭ на базе авиационных двигателей уже 100 лет в обед как бы. Обычно они и вправду на природном газе работают, но и двухтопливные (природный газ/дизельное топливо) камеры сгорания тоже вполне бывают.
Я уж не говорю про ГТЭ "неконверсионные", т.е. изначально разрабатывавшиеся как наземные.
Очередная нейросетевая "новость"?)
тут есть такой момент, что аналитик может вообще такими вещами и не заниматься - например, когда спеку в open api генерирует разработчик прямо в коде
Т.е. сильная зависимость от того чем именно занимается аналитик и много ли на нем автоматизируемой рутины
Если таковой почти нет, то пока нейросетям там вроде как ловить и нечего. Можно конечно заставить их погенерировать кейсы, но тут мне не удалось выхлопа получить
Мое мнение - нейросеть может отрисовать что-то, когда и так уже все понятно. При этом вопрос еще хорошо ли это, т.к. когда рисуешь что-то "руками", то неизбежно возникает момент рефлексии, приводящий к пересмотру и улучшению результата.
А вот когда ничего не понятно (но очень интересно) и надо синтезировать решение, удовлетворяющее всех и вся (а это 99% полезной работы аналитика), то тут я слабо представляю что может предложить нейросеть.
Отсюда и мало кейсов :)
А я как раз на этом "красивом" считал аэродинамику :) Надо сказать, что по мировым меркам кластер Политеха уже сильно устарел. Но по меркам РФ он и вправду неплох, особенно по сравнению с большинством промышленных (там где они вообще есть).
Вообще прототип в большинстве случаев можно накидать из квадратиков и кружочков прямо поверх существующих макетов или даже скриншотов и это дело 1-2 дней. И заказчику сразу все становится гораздо понятнее. Это из личного опыта аналитики всяких абстрактных и сложных для восприятия API Gateway или генераторов DVB таблиц
Могу сказать, что пользовался Perl года 4 назад - писал скрипты для обработки результатов расчетов газодинамики в постропроцессоре ANSYS CFX :) Так что вполне еще живой, но да, Пайтон конечно удобнее
А вы точно про РФ, где ДМС в принципе довольно редкое явление? Про найм иностранных специалистов (не СНГ) - аналогично :) У нас по-моему больше актуальны вопросы общения с военкоматом или подарки детям сотрудников на НГ. Ну да, это можно эйчарам доверить, хотя как показывает практика того же чата ит-отсрочек, немало случаев когда эйчар тупо забыл нажать кнопку, а потом человек отправляется в армию
От HR может быть польза только если вам надо найти и нанять N кассиров/разнорабочих. Если же вы ищете квалифицированных инженеров, то толку от HR с гулькин нос. Максимум извлекаемой пользы - поставить встречу в календаре, да передать кандидату список документов. Всем остальным нужно заниматься тимлиду (в простонародье начальнику отдела), ибо даже поиск по ключевым словам это недоступное HR знание, ибо они либо просто не знают нужных, либо не умеют их правильно интерпретировать.
Все это конечно сугубо личный опыт, основанный на эмпирических данных, начиная с отсмотра студентов на 3 курсе, заканчивая поиском матерых профи в навозной ку... на хэхэ.ру
Как сотрудник возможно той же самой компании с "телевизионными приставками" безусловно соглашусь, что разбираться нужно :) Действительно, оборудование (и не только оно) часто имеет ограничения, которые оказывают огромное влияние на архитектуру всей системы.
Для спутникового ТВ это жёсткие ограничения на весь служебный трафик и отсутствие обратной связи от клиентских устройств.
Для автомобилей - автономная работа, резервирование, безопасность и тд и тп
Верно и то, что это все эти знания могут оказаться ненужными, тк такой специфики в проекте просто нет)
Но кажется, что именно этими знаниями, опытом и кругозором преимущественно и можно оценить "синьорность" аналитика.
Может я вас расстрою, но за 10 лет работы инженером по расчетам турбин ГТД я использовал интегралы 0 раз. Даже для диссертации ктн не пригодились. Ещё с коллегами сокрушались - как так, все учили и не понадобилось в итоге, ибо все давно автоматизировали. И я сейчас не уверен смогу ли это дело вспомнить и применить где-то. Понятно, что обучение влияет не впрямую, но в реальности больше пригодился русский язык, как ни странно)
Вам очень повезло) У меня двойняшки 3+ и это ад, конфликты и ор. Не, они конечно играют друг с другом, но не долго. Все очень сильно от самих детей зависит, причем даже не от воспитания, а от врождённых черт характера.
Поддержу, у нас аналитики просто пишут внятные описания api в свободной форме (обычно таблички в конфе) со списком входных/выходных параметров, действий и ошибок. И потом вместе с тестировщиками проверяют через swagger ui, что все сделано корректно.
Не, ну можно и на аналитиков повесить делать api через editor, но мне кажется, что более разумно посвятить это время на улучшение качества аналитики или проработку большего количества фич)
Весьма скептически отношусь ко всяким универсальным советам, т.к. жизнь это все опровергает на раз-два :)
Как по мне, надо в первую очередь ориентироваться на адресатов этих требований, слушать и слышать их реальные нужды и чаяния.
Например, заказчика от бизнеса волнуют в требованиях одни вещи, команду разработки другие, еще и вкусовщина примешивается.
Про атомарность и краткость - за все хорошее, но тоже часто не работает. Иным личностям надо написать 5 раз одно и то же разными словами, чтобы они это все-таки прочитали и сделали как написано. И хоть ты тресни.
В целом - в каждой избушке свои погремушки, т.е. задача аналитика - достичь некоторого консенсуса, чтобы желания бизнеса трансформировались в продукт с приемлемым для бизнеса результатом. И в каждом конкретном случае форма этого консенсуса будет очень даже своя.
Из универсального - описывая требования к фрагментам системы, очень неплохо бы не забывать делать это же самое для всей системы как единого целого. А то фичей на компоненты напилят, а что в целом то должно происходить большинству так и не ясно.
LBA/LBA2 - визуал, атмосфера, геймплей из области фантастики. И самое прекрасное, что никто так и не покусился на ремейк) Всякие спектрумы/денди тоже были, но как-то из той эпохи ничего особо не отложилось
Работал в компании где было наоборот - делали ПО для управления расчетами ГТД. Все аналитики и инженеры были у нас, разработки не было, ей занималась другая компания. Но конечно совсем без разработки не бывает, это факт)
Тут зависит от команды, ситуации и продукта. Есть команды, в которых аналитик описывает только пользовательские сценарии и ui. Есть где аналитик расписывает все таблицы, все api, все внутренние вспомогательные сценарии (типа того как отбирать задачу в очереди задач) и весь ui. В последнем случае аналитик в целом владеет картиной по системе на достаточном для понимания и объяснения (!) другим людям уровне.
Про выполнение роли аналитика архитектором имхо есть пара нюансов:
Вот не все могут качественно. Лично переделывал требования за двоих архитекторов - у одного образовалась жуткая помойка из фич с кучей "воды", которой при масштабной переделке системы оказалось невозможно пользоваться. У другого был просто поток сознания и проблемы с орфографией и пунктуацией. В основном до аналитиков надо просто дорасти с точки зрения масштаба проекта, либо необходимости человека с глубокими познаниями в специфичной области.
Архитекторы часто могут начать трактовать требования заказчика "в свою пользу". Вот тут как раз и может пригодиться аналитик, который более нейтрален и для которого архитектор является только одним из источников требований.
Про аналитиков соглашусь:
На профиль в хабре со статусом "Не ищу работу", з/п 300к, лычкой senior и опытом примерно 4 года в один февральский день написали 5(!) рекрутеров разом (в среднем в феврале-марте порядка тех же 5 в неделю, преимущественно финтех и ритейл, сейчас поток подсхлынул)
В итоге пара офферов на эту сумму
В целом, кажется, что указанные суммы более-менее в рынке, сужу по своему опыту и боту getmatch. На hh не ориентировался вообще
Описанная проблема характерна не только для it, но и например для инжиниринга - использование высокоуровневых абстракций (трёхмерных конечно-элементных расчетов) привело к тому, что многие инженеры забили на физику и расчеты в 1д (на бумажке, в Экселе и тд) при этом совершенно не интересуясь какие ограничения есть у физических моделей в новомодных "черных ящиках" и как там все работает. Компуктер посчитал и все ок. И так оно много где.