В разных компаниях менеджеров и владельцев по-разному определяют, ну и менеджеры разного уровня бывают. Можете уточнить, с чем в моём описании этих двоих вы не согласны? Интересно.
А что до отработки, вероятно, и джунов-архитекторов кто-то нанимает, а авто-тестировщиков без опыта точно, но я бы очень не рекомендовала самим кандидатам соваться в эти сферы без опыта. Более с этой позиции в рыжих красила.
1) Сайт про генератор ничего не знал. А генератор не знал, как из относительных ссылок в репозитории или из url до репозитория сделать ссылку, которая подходила бы hugo. Однако аналитик вполне мог установить адрес будущей страницы в hugo, их и ставили сразу в документ.
2-4) Почему все копипастят "не поддерживают"? Там дальше выделенное "в полной мере". Ну типа здорово предположить, что мы не читали документацию, читая статью по диагонали.
5) Да, это решение. Но сравните количество действий между ним и "выделил-тегнул". Плюс обучение не только аналитиков (с ними-то намучилась), плюс разграничение доступов к репозиториям... В общем, мне не кажется хорошей идея выполнять простые действия сложными путями при наличии специализированных средств. Выигрыша от гита мы не получили, сравнением версий разработчики пользоваться не стали, в том числе потому, что изменения у нас обычно радикальные. Исходные гипотезы не подтвердились и нашей команде Docs as Code не подошёл.
Так и наши поддерживают) На эстетические грабли мы наступили далеко не сразу. Нюансы отображения иногда способны очень сильно испортить читаемость, пока не наткнёшься -- не узнаешь о них (
Не целесообразно даже тратить ресурсы на сборку, потому что документация ветки конкретной фичи интересна примерно никому, как и исходники. Разве что для QA в момент тестирования пригодится. В остальном даже разработчики предпочитают иметь ввиду целевое решение и будущие смежные доработки.
Четвёртый пункт некорректен. Если посмотрите вакансии для системных аналитиков, то увидите, что знание типов архитектуры, умение спроектировать API и опыт работы с брокерами сообщений требуются с уровня мидла, а понимание нефункциональных требований — с джуна. Всё, что Вы описали в четвёртом пункте для Архитектора справедливо и для системного аналитика. Вероятно, Вы имели ввиду бизнес/продуктового аналитика.
Ревью при пулреквестах. У нас ревьюят лиды разработки, а не те разработчики, которые будут пилить задачу.
В разных компаниях менеджеров и владельцев по-разному определяют, ну и менеджеры разного уровня бывают. Можете уточнить, с чем в моём описании этих двоих вы не согласны? Интересно.
А что до отработки, вероятно, и джунов-архитекторов кто-то нанимает, а авто-тестировщиков без опыта точно, но я бы очень не рекомендовала самим кандидатам соваться в эти сферы без опыта. Более с этой позиции в рыжих красила.
1) Сайт про генератор ничего не знал. А генератор не знал, как из относительных ссылок в репозитории или из url до репозитория сделать ссылку, которая подходила бы hugo. Однако аналитик вполне мог установить адрес будущей страницы в hugo, их и ставили сразу в документ.
2-4) Почему все копипастят "не поддерживают"? Там дальше выделенное "в полной мере". Ну типа здорово предположить, что мы не читали документацию, читая статью по диагонали.
5) Да, это решение. Но сравните количество действий между ним и "выделил-тегнул". Плюс обучение не только аналитиков (с ними-то намучилась), плюс разграничение доступов к репозиториям...
В общем, мне не кажется хорошей идея выполнять простые действия сложными путями при наличии специализированных средств. Выигрыша от гита мы не получили, сравнением версий разработчики пользоваться не стали, в том числе потому, что изменения у нас обычно радикальные. Исходные гипотезы не подтвердились и нашей команде Docs as Code не подошёл.
По-вашему, с опытом рождаются?
Так и наши поддерживают) На эстетические грабли мы наступили далеко не сразу. Нюансы отображения иногда способны очень сильно испортить читаемость, пока не наткнёшься -- не узнаешь о них (
Спасибо, это полезно.
Плагин для ссылок звучит хорошо, хотя есть сомнения в применимости для множества репозиториев с кросс-ссылками.
Что до боли, причиняемой аналитиками -- понимаю, сочувствую 😅
Не целесообразно даже тратить ресурсы на сборку, потому что документация ветки конкретной фичи интересна примерно никому, как и исходники. Разве что для QA в момент тестирования пригодится. В остальном даже разработчики предпочитают иметь ввиду целевое решение и будущие смежные доработки.
Четвёртый пункт некорректен. Если посмотрите вакансии для системных аналитиков, то увидите, что знание типов архитектуры, умение спроектировать API и опыт работы с брокерами сообщений требуются с уровня мидла, а понимание нефункциональных требований — с джуна. Всё, что Вы описали в четвёртом пункте для Архитектора справедливо и для системного аналитика.
Вероятно, Вы имели ввиду бизнес/продуктового аналитика.
Эта карта навыков довольно сильно устарела.
А почему нет? Аналитик должен иметь представление, как его требования будут реализовывать и тестировать. И да, управление проектами очень не лишнее.