Может я вас расстрою, но за 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, тесткейсы, общие и техописания в отдельные от требований документы. Соответственно ведут их разные люди - архитекторы свое, аналитики свое, техписы и разрабы свое. Хотя где-то аналитик может быть как Дартаньян - один за всех)
Хехе, именно так - всякому хрустальному шару нужен хороший колдун) давеча бывшие коллеги рассказали, что молодая поросль инженеров насчитала уровень шума у здоровенного морского редуктора на уровне 10 дБ и ни у кого здравый смысл не всколыхнулся) Но вообще в правильных руках все работает на ура, только вот стоят эти правильные руки весьма недешево.
Сейчас уже год как съехал с этой темы, сходу не вспомню смотрел ли, но в Политехе этот ГОСТ писали скорее "аналитики") а я отвечал за технику и то, чтобы маркетинг сильно от реальности не отрывался, а то там смешались в кучу цифровые двойники, высокопроизводительные вычисления и умный помощники)))
В малоразмерных гтд запросто и 100 и 200 тыс (погуглите те же Jetcat). Там как раз применяются подшипники с керамическими шариками без сепараторов, правда ресурс 25 часов :)
Так можно ж гибрид сделать, гтд заряжает батарейку, а электродвигатель крутит колеса :) А так, для куража, можете повесить на обычный мотоцикл что-то типа реактивного Jetcat p-200, шума там на 120 дБ на Макс тяге)))
Может я вас расстрою, но за 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, тесткейсы, общие и техописания в отдельные от требований документы. Соответственно ведут их разные люди - архитекторы свое, аналитики свое, техписы и разрабы свое. Хотя где-то аналитик может быть как Дартаньян - один за всех)
Вы крепко заблуждаетесь, думая, что концепция а-ля tabula rasa верна. Это я вам как отец двойняшек уверенно заявляю :)
Хехе, именно так - всякому хрустальному шару нужен хороший колдун) давеча бывшие коллеги рассказали, что молодая поросль инженеров насчитала уровень шума у здоровенного морского редуктора на уровне 10 дБ и ни у кого здравый смысл не всколыхнулся) Но вообще в правильных руках все работает на ура, только вот стоят эти правильные руки весьма недешево.
Это ж чуваки, которые курсами аналитики промышляют - советы соответствующего качества :)
Сейчас уже год как съехал с этой темы, сходу не вспомню смотрел ли, но в Политехе этот ГОСТ писали скорее "аналитики") а я отвечал за технику и то, чтобы маркетинг сильно от реальности не отрывался, а то там смешались в кучу цифровые двойники, высокопроизводительные вычисления и умный помощники)))
Не уверен, что это развеет туман, но погуглите ГОСТ Р 57700.37-2021
Немного (чуть больше автора статьи) довелось поработать над этой темой
В малоразмерных гтд запросто и 100 и 200 тыс (погуглите те же Jetcat). Там как раз применяются подшипники с керамическими шариками без сепараторов, правда ресурс 25 часов :)
Так можно ж гибрид сделать, гтд заряжает батарейку, а электродвигатель крутит колеса :) А так, для куража, можете повесить на обычный мотоцикл что-то типа реактивного Jetcat p-200, шума там на 120 дБ на Макс тяге)))
А вы точно хотите турбоРЕАКТИВНЫЙ делать? А то может всё-таки турбовальный?) Как специалист по ГТД сочувствую и желаю удачи