Как выше отметили, разделение на всех этих архитекторов действительно в наше время выглядит ущербно. Особенно, что каждая организация подразумевает нечно свое особенное.
Глядя на описание проектов и ответственности, которые печатают hr, то solution architect будет отвечать скорее за инфраструктуру, и в большинстве случаев это веб и облачные сервисы. Что не очень то вписывается в описание предоставленное в статье.
Но в больших и сложных проектах, действительно приходится разделять роли, кто то отвечате за инфраструктуру, кто то трансформирует хотелки заказчика в удобоваримые требования, кто то на базе этих требования определяет системный функционал, а кто то реализует его по софтверным компонентам, и это если взять только софтверную часть. Если этот эмбедед проект, то тоже придется сделвть и для железа. А если вам еще и компоненты между собой по разным протоколам и технологиям конектить, то вам еще и некторый нетворк специалист понадобиться, да не один.
Нахожу Ваше замечание по поводу "конкретного кейса" вполне обосновано, но все же как то уж много критики, статья вроде более менее понятна.
Ведь если задуматься то скорее всего из "разработчики, тестировщики, скрам-мастер" действительно врядли кто то сможет написать внятные требования заказчика и требования к системе.
Я сам немного в другой области работаю, но так понимаю что системный аналитик плотно общается с заказчиками и составляет хорошо проработанные юз кейсы, и на базе этого формулирует понятные и структурированные требования звказчика (не системные и не софтверные).
Однако в данной схеме мне кажется отсутсвует как минимум архитектор (объеденим системного и софтверного в одну роль и наделим его властью писать реквайрементсы). Ну и скрам мастер тут конечно лишний %)
Спасиюо, прочитал с большим интересом. Однако выскажу свое личное мнение.
Сколько лет уж работаю, но ни разу не видел, что бы стайлгайды работали хоть в одном мало мальски крупном проекте. Зато видел, как много человеко часов тратится на создание такого рода документа.
Например, стайлгайд сэкономит вам кучу времени на объяснения, когда в команду придёт новый человек — достаточно будет переслать ссылку на документ. А ещё гайд избавит от ненужных споров!
Человек скорее всего пролистает его быстренько, и благополучно забудет.
С другой стороны, упомянутая автоматизация, это то что наверняка может сработать.
Как вы сами указали
В начале я упоминал, что подобные стайлгайды чаще всего нужны малым командам в период их внезапного масштабного расширения
Однако я бы ни в коем случае не стал делать этот документ с большим количеством информации. Указать основные моменты хорошего тона, и не более.
Формула, которой я придерживалась:[Job title] at [Current company] | [N years of experience] | [Field of experience 1] | [Field of experience 2] | [Field of experience 3] | [Alternative job title 1] | [Alternative job title 2]
Интересно, что рекрутеры повидимому очень любят вот эти вот проценты .. "улучшил на %..." . Однако, всегда встает вопрос, а как ты эти проценты посчитал, кто может подтвердить, что например твои улчшения в коде, ускорили выполнения проекта на 40% (откуда именно 40%), а если вдруг еще стоит что уменьшили затраты, то становится вообще смешно. Но со стороны соискателя, конечно приходится играть по правилам рекрутеров.. :(
Спасибо, интересно было почитать. Позволю высказать свое мнение по данной теме.
Я бы начал с более детального рассмотрения предоставленного юзкейса. И в первую очередь следовало бы ограничить зону ответственности сервиса. Когда границы определены, можно найти уже и стейкхолдеров (в данном случае другие сервисы).
В статье немного размыты границы между функциональными и не функциональными требованиями к системе. Однако на базе юзкейса будет намного легче определить функциональные требования к сервису (кто и что от него хотят, и какие функции он, сервис, должен предоставить, что бы удовлетворить требования).
Нефункциональные же требования, скорее всего на интервью мало чем помогут (разве что для рассуждений на тему выбора технологий и реализации), но уточнять всегда полезно.
Опять же, когда проработали системные функции сервиса, встает вопрос о данных, не о конкретной реализации API, а именно о данных, чем и как обмениваются между собой сервис со стейкхолдерами (другими сервисами, пользователем и тд.).
Ну и далее по списку, на базе функциональной архитекруты, можно подумать о логической архитекруте, что можно в некоторых случаях один к одному перенести на физический уровень (уровень реализации непосредственно софта) и тд.
Читаю статю я задался вопросом, а отчего такой уровень детализации, вроде жизненного цикла данных и расчета количество требуемых процессоров, если речь идет о системной архитектуре. Очень часто смешивание архитектурных уровней ведет к дальнейшему хаосу, и к тому что никто систумную архитектуру больше не учитывает, и тот же Вася берет и просто что то там реализовавает. :)
70к/1760*2 это около 80€ в час. Вполне себе реалистичный штундезатц ( по гулпу даже меньше среднего, но то гулп просто выбирает из тех кто указал свою желаемую почасовую ставку для поиска проекта).
80 * 1760 получаем почти 141к .. что и так по формуле ясно, в два раза выше готовой зарплаты на найме.
Но что мы имеем на найме.. пенсия.. так она по пунктам считается. Арбайтслосгельд при потере работы вроде только 9 месяцев платят.. а то может уже и 6... Ну мед страховку половину платит работодатель.. так 140к в год куда выгоднее.. после вычета налога .. это где то дополнительные +40к которые фрилансер потратит на свою пенсию, страховку, поиск клиентов и тд.
Вопрос скорее в некотором психологическом комфорте. В долгосрочной перспективе найм может быть и более выгодным, ибо по статистике фрилансеров в среднем работают больше 40 часов в неделю, но сможешь ли ты скажем 20-30 лет работать в таком темпе, вот уж вопрос. Ну и найм в Германии плох тем что тут везде тарифы.. если на найме и вне тарифа тогда ситуация обычно более приятная.
Да 15 минут в день по большому счету роли не играют, главное что бы они не попадали в то время, когда команда наиболее сконцентрированна на работе :).
Тут как говорится "вам шашечки или ехать?". Скарм вроде как фреймворк дающий некоторую методолгию, но не гарантирующий результат. А что бы результат был, его нужно адаптировать под команду, иначе это все работать не будет. Так же тут зависимость есть от области применения. Но как это обычно бывает, вводят скрам по принципу, ну все делаем скрам как в методичке и это решит наши проблемы, но при этом в самой организации ничего не меняется. Все это превращается в трату времени именно изза этих 15 (растягивающихся на пол часа) дейли стендапах.
Например фреймворк Scrum прямо запрещает отказываться от дейли встреч.
Чисто из своего опыта, вот такой подход и есть главная ошибка автора этой статьи. Если команда самоорганизована и в ней нет "слабых" свеньев, то дейли можно и не проводить каждый день. Но часто бывает, что команда разнообразна, а еще и часть работает удаленно, и некоторым людям ежедневные митинги необходими, тогда уж от них отказываться не стоит, даже если часть команды считает это лишней тратой времени.
Я бы интерпретировал ваш результат таким образом: раз модель выдает рандомный результат, а 50% можно смело считать рандомом (хотя всегда имеет смысл сравнить с настоящим рандом), то у вас просто нет зависимостей между x-ми и y-ми. Т.е. модель выступает в качестве простого инструмента выявления статистических зависимостей. И раз модель не находит этих зависимостей, то в вашем алгоритме торговли нет никакого эджа :), либо вы упускаете какие либо данные которые ваш мозг воспринимает как впомогательные для принятия решений, если уж руками ваш торговый алгоритм зарабатывает.
Отсюда следует, что модель следует улучшать лишь тогда, когда у вас есть некоторое приимущество, и ваш алгоритм его использует.
Numba будет медленее чем реализация на чистом c++. Если говорить про питон, то я бы посоветовал посмотреть в сторону RAPIDS (у них там есть реализация датафреймов как пандас но на gpu), но только если имеется cuda. :)
зы. пару месяцев назад ради интереса я тут потестил как ускорить расчет максимальной возможной просадки используя монтекарло и лучший результат конечно был c++ cuda, но из питона мы можем отлично получить почти такую же скорость... Постить тут не буду, но кому интересно может глянуть на моем ютбчике.
да я просто поторопился с комментарием, видимо malloc меня очень задел. Почти во всех проектах которых я работал, динамическое выделение памяти запрещено стандартами. Ну и еще пару мелочей, а так да.. еще раз повторюсь, выглядит все интересно :)
И то верно, cpython, gtk... для pc проектов вполне возможно. Хотя наверное я очень критичен с некоторыми изменениями, возможно наверное и в эмбедед это все отлично вписать.
Хм.. но вы же храните данные о платежах и мена?
А сама бд не должна соответствовать требованиям закона? Или jwt реально достаточно?
У меня вопрос. А как вы решили проблему с gdpr?
Там же надо что бы вы сервис соответствовал закону. Раз уж вы в Германии.
Мы с товарищем тоже думаем запускать сервис.. но вопрос о защите данных и немецкие законы малость беспокоят..
Пилим ai ментора для дей трейдеров с фокусом на психологические аспекты ..
https://steadivus.trade
Ну или тут не ного о прогрессе r/Steadivus
Вопрос. А не теряется ли тональность при переводе?
Как выше отметили, разделение на всех этих архитекторов действительно в наше время выглядит ущербно. Особенно, что каждая организация подразумевает нечно свое особенное.
Глядя на описание проектов и ответственности, которые печатают hr, то solution architect будет отвечать скорее за инфраструктуру, и в большинстве случаев это веб и облачные сервисы. Что не очень то вписывается в описание предоставленное в статье.
Но в больших и сложных проектах, действительно приходится разделять роли, кто то отвечате за инфраструктуру, кто то трансформирует хотелки заказчика в удобоваримые требования, кто то на базе этих требования определяет системный функционал, а кто то реализует его по софтверным компонентам, и это если взять только софтверную часть. Если этот эмбедед проект, то тоже придется сделвть и для железа.
А если вам еще и компоненты между собой по разным протоколам и технологиям конектить, то вам еще и некторый нетворк специалист понадобиться, да не один.
Нахожу Ваше замечание по поводу "конкретного кейса" вполне обосновано, но все же как то уж много критики, статья вроде более менее понятна.
Ведь если задуматься то скорее всего из "разработчики, тестировщики, скрам-мастер" действительно врядли кто то сможет написать внятные требования заказчика и требования к системе.
Я сам немного в другой области работаю, но так понимаю что системный аналитик плотно общается с заказчиками и составляет хорошо проработанные юз кейсы, и на базе этого формулирует понятные и структурированные требования звказчика (не системные и не софтверные).
Однако в данной схеме мне кажется отсутсвует как минимум архитектор (объеденим системного и софтверного в одну роль и наделим его властью писать реквайрементсы).
Ну и скрам мастер тут конечно лишний %)
Спасиюо, прочитал с большим интересом. Однако выскажу свое личное мнение.
Сколько лет уж работаю, но ни разу не видел, что бы стайлгайды работали хоть в одном мало мальски крупном проекте. Зато видел, как много человеко часов тратится на создание такого рода документа.
Человек скорее всего пролистает его быстренько, и благополучно забудет.
С другой стороны, упомянутая автоматизация, это то что наверняка может сработать.
Как вы сами указали
Однако я бы ни в коем случае не стал делать этот документ с большим количеством информации. Указать основные моменты хорошего тона, и не более.
Спасибо за пример.
про OKR интересно почитать...
Интересно однако..
А можно пример вот этого:
Интересно, что рекрутеры повидимому очень любят вот эти вот проценты .. "улучшил на %..." . Однако, всегда встает вопрос, а как ты эти проценты посчитал, кто может подтвердить, что например твои улчшения в коде, ускорили выполнения проекта на 40% (откуда именно 40%), а если вдруг еще стоит что уменьшили затраты, то становится вообще смешно.
Но со стороны соискателя, конечно приходится играть по правилам рекрутеров.. :(
Спасибо, интересно было почитать.
Позволю высказать свое мнение по данной теме.
Я бы начал с более детального рассмотрения предоставленного юзкейса. И в первую очередь следовало бы ограничить зону ответственности сервиса. Когда границы определены, можно найти уже и стейкхолдеров (в данном случае другие сервисы).
В статье немного размыты границы между функциональными и не функциональными требованиями к системе. Однако на базе юзкейса будет намного легче определить функциональные требования к сервису (кто и что от него хотят, и какие функции он, сервис, должен предоставить, что бы удовлетворить требования).
Нефункциональные же требования, скорее всего на интервью мало чем помогут (разве что для рассуждений на тему выбора технологий и реализации), но уточнять всегда полезно.
Опять же, когда проработали системные функции сервиса, встает вопрос о данных, не о конкретной реализации API, а именно о данных, чем и как обмениваются между собой сервис со стейкхолдерами (другими сервисами, пользователем и тд.).
Ну и далее по списку, на базе функциональной архитекруты, можно подумать о логической архитекруте, что можно в некоторых случаях один к одному перенести на физический уровень (уровень реализации непосредственно софта) и тд.
Читаю статю я задался вопросом, а отчего такой уровень детализации, вроде жизненного цикла данных и расчета количество требуемых процессоров, если речь идет о системной архитектуре. Очень часто смешивание архитектурных уровней ведет к дальнейшему хаосу, и к тому что никто систумную архитектуру больше не учитывает, и тот же Вася берет и просто что то там реализовавает. :)
А поделитесь цифрой "предложения от которого невозможно отказаться"? Просто ж у немцев везде тарифные сетки в больших компаниях.
Что то с формулой не так..
70к/1760*2 это около 80€ в час. Вполне себе реалистичный штундезатц ( по гулпу даже меньше среднего, но то гулп просто выбирает из тех кто указал свою желаемую почасовую ставку для поиска проекта).
80 * 1760 получаем почти 141к .. что и так по формуле ясно, в два раза выше готовой зарплаты на найме.
Но что мы имеем на найме.. пенсия.. так она по пунктам считается. Арбайтслосгельд при потере работы вроде только 9 месяцев платят.. а то может уже и 6... Ну мед страховку половину платит работодатель.. так 140к в год куда выгоднее.. после вычета налога .. это где то дополнительные +40к которые фрилансер потратит на свою пенсию, страховку, поиск клиентов и тд.
Вопрос скорее в некотором психологическом комфорте. В долгосрочной перспективе найм может быть и более выгодным, ибо по статистике фрилансеров в среднем работают больше 40 часов в неделю, но сможешь ли ты скажем 20-30 лет работать в таком темпе, вот уж вопрос. Ну и найм в Германии плох тем что тут везде тарифы.. если на найме и вне тарифа тогда ситуация обычно более приятная.
а получить больше 100к в соседней Германии, так это еще ооооочень постараться надо %)
Да 15 минут в день по большому счету роли не играют, главное что бы они не попадали в то время, когда команда наиболее сконцентрированна на работе :).
Тут как говорится "вам шашечки или ехать?". Скарм вроде как фреймворк дающий некоторую методолгию, но не гарантирующий результат. А что бы результат был, его нужно адаптировать под команду, иначе это все работать не будет. Так же тут зависимость есть от области применения. Но как это обычно бывает, вводят скрам по принципу, ну все делаем скрам как в методичке и это решит наши проблемы, но при этом в самой организации ничего не меняется. Все это превращается в трату времени именно изза этих 15 (растягивающихся на пол часа) дейли стендапах.
Чисто из своего опыта, вот такой подход и есть главная ошибка автора этой статьи. Если команда самоорганизована и в ней нет "слабых" свеньев, то дейли можно и не проводить каждый день. Но часто бывает, что команда разнообразна, а еще и часть работает удаленно, и некоторым людям ежедневные митинги необходими, тогда уж от них отказываться не стоит, даже если часть команды считает это лишней тратой времени.
Да походу пункт номер 4 самый главный. Спать нужно достаточно :) и тогда все будет ок.
Я бы интерпретировал ваш результат таким образом: раз модель выдает рандомный результат, а 50% можно смело считать рандомом (хотя всегда имеет смысл сравнить с настоящим рандом), то у вас просто нет зависимостей между x-ми и y-ми. Т.е. модель выступает в качестве простого инструмента выявления статистических зависимостей. И раз модель не находит этих зависимостей, то в вашем алгоритме торговли нет никакого эджа :), либо вы упускаете какие либо данные которые ваш мозг воспринимает как впомогательные для принятия решений, если уж руками ваш торговый алгоритм зарабатывает.
Отсюда следует, что модель следует улучшать лишь тогда, когда у вас есть некоторое приимущество, и ваш алгоритм его использует.
Numba будет медленее чем реализация на чистом c++. Если говорить про питон, то я бы посоветовал посмотреть в сторону RAPIDS (у них там есть реализация датафреймов как пандас но на gpu), но только если имеется cuda. :)
зы. пару месяцев назад ради интереса я тут потестил как ускорить расчет максимальной возможной просадки используя монтекарло и лучший результат конечно был c++ cuda, но из питона мы можем отлично получить почти такую же скорость... Постить тут не буду, но кому интересно может глянуть на моем ютбчике.
да я просто поторопился с комментарием, видимо malloc меня очень задел. Почти во всех проектах которых я работал, динамическое выделение памяти запрещено стандартами. Ну и еще пару мелочей, а так да.. еще раз повторюсь, выглядит все интересно :)
И то верно, cpython, gtk... для pc проектов вполне возможно. Хотя наверное я очень критичен с некоторыми изменениями, возможно наверное и в эмбедед это все отлично вписать.