Авторы статьи предлагают врать на собеседованиях. Т.е. как бы все врут, во всех компаниях, и мы вам врём, вот и вы всем врите! А то минус получите и офер упустите!
Треш, честно говоря. Ужасный у вас мир, и к вам не хочется. Ни на собесы такие попасть, ни вашим советам следовать...
Я на собеседованиях ( с обеих сторон) стараюсь быть честным и откровенным. Чтобы потом не возникало вопросов "зачем я сюда пришёл" и "зачем мы его наняли". Я уверен, что я упускаю оферы. Ну и хорошо, я думаю... нафиг такие оферы, где тебя уже на пороге облопошили...
Я правильно понимаю, что компания, занимающаяся заказной разработкой, кому нужный квалифицированные спецы "недорого" публикует перевод статьи, основной посыл которой "соглашайтесь на меньшие деньги, разрабы"?
Поддерживаю. Статьи от ведущих учителей микрошкол по обучению войтивайтишников изрядно загадили ленту... Вся их суть в привлечении внимания к их каналу по продаже курсов. Но их не модерируют на Хабре от слова совсем.
Да, многие компании по прежнему под "Системным аналитиком" понимают человека-оркестор. И бизнес требования формализирует, CJM с макетами составит и требования к контракту и БД напишет, и роль проджекта на себя возьмёт, наладив процесс в команде... Иногда ещё и потестирует что нибудь.
Только это прошлый век организации разработки. В современных компаниях все эти роли разделены, и бизнес аналитик и системный аналитик это разные люди, изготавливающие разные артефакты документации и стоящие на разных этапах процесса.
Странно утверждать, что рынку нужны описанные выше фулстеки. Хотя, может оно и так, просто не в моей практике...
И поучаствовав в десятках собеседований SA с обоих сторон я могу утвержать, что они проходят совершенно иначе, чем описано у вас в статье. Никто не спрашивает ваше портфолио. Скорее вам дадут приближенную к реальности задачку и посмотрят, как вы рассуждаете. И попутно зададут полсотни технических вопросов. И если вы не знаете, чем отличается GET от POST, то вашему портфолио грош цена.
Нет разделения на бизнес процессы и системные процессы. Бизнес процессы не спроектированы отдельно. Сомнительный патерн использования диаграммы последовательности. В системную логику, где чаще всего и используется диаграмма последовательности, проектировщик даже не погружается, упоминуя её вскользь и перекладывая ответсвенность на разработчиков.
Для стартапа с mvp может и зайдёт, при условии что всё это будет выброшено после проверки гипотезы.
В современных крупных системах так никто не проектирует.
Мысль следующая: инклюд в plantuml и adoc работает по разному.
В adoc инклюдится текст файла. И только собранный текст отправляется на сервер, например кроки.
Можно подумать и сделать аналогичный механизм... сначала собирать инклюдами текст, а потом отправлять его на рендринг. Тогда не важно, есть ли доступ к самим файлам.
С одной стороны работа с git позволяет отслеживать изменения в документации, связанные с конкретной задачей. Но система трассировки требований тут отсутствует.
Теоретически, можно использовать скрытые теги в комментариях при написании документации и помечать те или иные части документации идентификаторами требований. Тогда поиск по этим идентификаторам будет выдавать те места, где они есть. Но для этого у вас, как минимум, должна быть система ведения бизнес требований, в которой эти требования имеют идентификаторы.
Например, в markdown это будет выглядеть так:
3. Проверить, существует ли такой пользователь. <!--#Требование FR-002 --> Для этого:
* Найти в таблице [users] запись, для которой:
В описании при просмотре из git комментария видно не будет, но поиск по 'FR-002' выдаст результат.
Если честно, то статья про то "как проводить ретро" упускает самое главное: а зачем вообще вы его проводите? Нафига вам ретро? Для кого вы использунте этот инструмент?
Я был в нескольких компаниях и в 80% случаев ретро проводят потому, что надо провести ретро. И идут по описанным в статье сценариям.
А там где понимают, зачем нужно ретро проводят её совсем по другому.
Меня раздражают эти абстрактные вопросы, мнимые решения с выбором ответсвенных, если в результате ничего не меняется. Хоть корабликом плыви, хоть гапак танцуй. Если вы сами не понимаете, зачем это нужно, то любой формат пройдёт мимо. Уверенно, задорно и мимо.
Авторы статьи предлагают врать на собеседованиях. Т.е. как бы все врут, во всех компаниях, и мы вам врём, вот и вы всем врите! А то минус получите и офер упустите!
Треш, честно говоря. Ужасный у вас мир, и к вам не хочется. Ни на собесы такие попасть, ни вашим советам следовать...
Я на собеседованиях ( с обеих сторон) стараюсь быть честным и откровенным. Чтобы потом не возникало вопросов "зачем я сюда пришёл" и "зачем мы его наняли". Я уверен, что я упускаю оферы. Ну и хорошо, я думаю... нафиг такие оферы, где тебя уже на пороге облопошили...
Я правильно понимаю, что компания, занимающаяся заказной разработкой, кому нужный квалифицированные спецы "недорого" публикует перевод статьи, основной посыл которой "соглашайтесь на меньшие деньги, разрабы"?
Я ничего не упустил?)))
Поддерживаю. Статьи от ведущих учителей микрошкол по обучению войтивайтишников изрядно загадили ленту... Вся их суть в привлечении внимания к их каналу по продаже курсов. Но их не модерируют на Хабре от слова совсем.
Вообще-то рынок сильно другой.
Да, многие компании по прежнему под "Системным аналитиком" понимают человека-оркестор. И бизнес требования формализирует, CJM с макетами составит и требования к контракту и БД напишет, и роль проджекта на себя возьмёт, наладив процесс в команде... Иногда ещё и потестирует что нибудь.
Только это прошлый век организации разработки. В современных компаниях все эти роли разделены, и бизнес аналитик и системный аналитик это разные люди, изготавливающие разные артефакты документации и стоящие на разных этапах процесса.
Странно утверждать, что рынку нужны описанные выше фулстеки. Хотя, может оно и так, просто не в моей практике...
И поучаствовав в десятках собеседований SA с обоих сторон я могу утвержать, что они проходят совершенно иначе, чем описано у вас в статье. Никто не спрашивает ваше портфолио. Скорее вам дадут приближенную к реальности задачку и посмотрят, как вы рассуждаете. И попутно зададут полсотни технических вопросов. И если вы не знаете, чем отличается GET от POST, то вашему портфолио грош цена.
Статью надо было назвать иначе: " Как успешно преодолеть трудности, которые вы сами себе создали?"
И самые здравые мысли, как обычно, в комментариях: "А как вы вообще дошли до точки, в которой куча бесценной информации лежит в одном человеке?"
Это какая-то мешанина из проектирвоания.
Нет разделения на бизнес процессы и системные процессы. Бизнес процессы не спроектированы отдельно. Сомнительный патерн использования диаграммы последовательности. В системную логику, где чаще всего и используется диаграмма последовательности, проектировщик даже не погружается, упоминуя её вскользь и перекладывая ответсвенность на разработчиков.
Для стартапа с mvp может и зайдёт, при условии что всё это будет выброшено после проверки гипотезы.
В современных крупных системах так никто не проектирует.
Надо фичу запилить)
Мысль следующая: инклюд в plantuml и adoc работает по разному.
В adoc инклюдится текст файла. И только собранный текст отправляется на сервер, например кроки.
Можно подумать и сделать аналогичный механизм... сначала собирать инклюдами текст, а потом отправлять его на рендринг. Тогда не важно, есть ли доступ к самим файлам.
Подскажите, есть ли поддержка операции include в файлах plantuml? У меня большинство сиквенс диаграмм сборные из разных частей.
Можно ли вставлять puml файлы в статьи на markdown? В gitlab мне для этого приходится asciidoc использовать.
Если поделитесь подробностями - буду признателен.
Хороший вопрос.
С одной стороны работа с git позволяет отслеживать изменения в документации, связанные с конкретной задачей. Но система трассировки требований тут отсутствует.
Теоретически, можно использовать скрытые теги в комментариях при написании документации и помечать те или иные части документации идентификаторами требований. Тогда поиск по этим идентификаторам будет выдавать те места, где они есть. Но для этого у вас, как минимум, должна быть система ведения бизнес требований, в которой эти требования имеют идентификаторы.
Например, в markdown это будет выглядеть так:
В описании при просмотре из git комментария видно не будет, но поиск по 'FR-002' выдаст результат.
А как же plantUML?
Почему не рассматривали?
Если честно, то статья про то "как проводить ретро" упускает самое главное: а зачем вообще вы его проводите? Нафига вам ретро? Для кого вы использунте этот инструмент?
Я был в нескольких компаниях и в 80% случаев ретро проводят потому, что надо провести ретро. И идут по описанным в статье сценариям.
А там где понимают, зачем нужно ретро проводят её совсем по другому.
Меня раздражают эти абстрактные вопросы, мнимые решения с выбором ответсвенных, если в результате ничего не меняется. Хоть корабликом плыви, хоть гапак танцуй. Если вы сами не понимаете, зачем это нужно, то любой формат пройдёт мимо. Уверенно, задорно и мимо.