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