Почему вы под Системным аналитиком имеете ввиду фулстек аналитика???
Таких системных аналитиков делали 20 лет назад, когда бизнес не понимал что тако UI и разарботчики придумывали всё за бизнес.
В современном мире разработки , в совремнных компаниях, эти роли разделены.
Бизнес аналитик проектирует "Что" делает система. И вот там BPMN, CJM, юзкейсы и прочее... и ему пофигу, прокините вы это через 1 монолит или 20 микросервисов.
Системный аналитик проектирует "Как" это реализовано в системе. И вот тут начинаются БД, журналы, ресты и прочее, в купе с архитектурой.
Это две разные роли.
Объединять их в одну это устарело лет 5-10 назад.
А джуны читают этот ваш "полный гайд" и становятся недоаналитиками во всём.
Как бы адекватный SA должен проектировать. Но если проектируют разработчики "на коленках по ходу написания кода", то SA что может сделать? Пойти руководству настучать "у вас процессы говно"???
Как бы процессы обычно выстраивают либо сверху, и тогда надо делать вэбинар для руководителей, либо они сами ввстраиваются " кто как модет", и тогда разрабы, привыкшие писать отсеьятину, пошлют SA с его инициативами ... записывать за ними их гениальный код.
Из моего опыта упущен важный момент: вы рассматриваете команду как некий юнит, который решает задачи. В практике, где вся команда - универсалы и могут делать любые задачи (писать код, тестировать, писать доку) это работает.
Как только вы выделяете в команде роли ( системный аналитик, FE,BE разработчики, QA) то процесс ломается. Потому что для команды статус "в работе", а внутри это передача от этапа к этапу. И отслеживать это становится невозмодно и все виплимиты идут лесом...
Если есть опыт канбана в командах с несколькими ролями - опишите пожалуйста.
Вы никогда не думали, что делая подробное ТЗ вы делаете двойную работу? Вначале аналитик подробно описывает все алгоритмы и спецификации, а потом разработчик делает то же самое, но на другом языке.
Это некорректно сравнение. Разработчик производит код. Это результат.
Документация описывает этот код.
Вы же не будете утверждать, что план разводки розеток и сами провода, лежащие в стене, это одно и тоже???
Я пытаюсь себе представить аналогию с ремонтом. Вы взяли сантехника, электрика, и маляра и вовлекли в продумывание дизайна квартиры...
Сомнительная эффективность, как по мне.
Почему вы не стали выстраивать качественный процесс с системным анлаизом? Чтобы каждый занимался своим профессиональным делом, а не думал о "чужих" областях?
Вообще то, в крупняках и современных компаниях роли СА и БА разделены. И современные СА должны хорошо отвечать на тех. вопросы, а не рассказывать про сбор требований и их типы, и упоси ГОСТы. Если у вас спросили всё из этого списка, значит процессы в нанимающей компании уже давно морально умтарели.
Ну а если в вас это всё впихивают на курсе, значит вы выбрали не тот курс...
Вообще, в компаниях с современными процессами практикуют documentation first.
Т.е. сваггер появляется даже до начала разработки и всем участникам процесса контракт известен заранее.
При этом, одного сваггера недостаточно. Свагер описывает контракт взаимодействия, а не логику работы. Может быть два идентичных метода, возвращающие одинаковые объекты, но совершенно разные данные. Поэтому к каждому методу всё равно необходимо текстовое описание логики работы.
Вы на верном пути, но это только часть необходимой документации.
Компании, использующие современные процессы разработки давно разделили роли системного и бизнес аналитика. Статья скорее заирагивает деятельность бизнес аналитика или продуктового. На системных аналитиков вличние несколько иное.
Аналогия со строительством моста не понятна. Процессы строительства больше перекликаются с процессом разработки, а не с процессом документирования по факту. С этой точки зрения, вы не строите мост, а восстанавливаете проектную документацию на этот мост после пожара в архиве. Берёте инженера с линейкой, и ходите и всё измеряете. Это больше похоже к.м.к.
В остальном, не понятна цель статьи. Запрос в гугле " кто такой техпис" даст примерно такую же информацию... Ощущение, что хотелось что-то написать и это была единственная тема, через которую можно упоминуть свой ТГ канал...
Ну так вы где вырасли? В тиньке??? Там замкнутая экосистема с весёлым матерком и сомнительными культурными ценностями. Зато расти там можно хоть каждые полгода. И это весь ваш IT опыт? Вы там на айтишников насмотрелись?
Я честно попробовал, но даже по инструкции ничего не получилось.
В статье нет примера результата. Оценить качество документации, которую подготавливает инструмент не получилось.
Формат docx широко распространён в узком кругу опрошенных. Хранить доку в docx это лет 15-20 назад было базой. Сейчас - кто во что горазд. Я например, продвигаю doc as code и пишу на markdown. Может имеет смысл присмотреться к другим форматам...
Вообще, openApi и swagger вполне достаточны для документирования. Примеры есть, подёргать можно. В дополнительном описании эндпоинтов может быть описана системная логика. Но вы такое описание из свагера не вытащите, это не возможно. Тогда встаёт вопрос: кто потребитель вашей документации и для чего она вообще нужна?
В развитых проектах, в отличии от "наколеночной разработки", сначала готовится документация, а потом пишется код. И опять таки встаёт вопрос: кто потребитель вашего инструмента, для кого вы его хотите сделать?
Ну и конкуренция с ИИ. Сейчас модели вполне сносно готовят документацию по эндпоинтам проходясь по коду и вытаскивая всю подноготную из системной логики.
Возможно, есть процессы, в которых данный инструмент будет полезен. Тогда, для продолжения работы, необходимо понимать, что это за процессы, как этот инструмент будет встроен в процесс и какие артефакты будет готовить и как будет их обновлять. Определится с тем, кто является потребителем самого инструмента и кто является потребителем результата его работы. И спросить не у всего сообщества (слишком широкий охват и большой процент нецелевой аудитории) а именно тех, для кого этот инструмент будет полезен.
Почему вы продолжаете это делать?
Почему вы под Системным аналитиком имеете ввиду фулстек аналитика???
Таких системных аналитиков делали 20 лет назад, когда бизнес не понимал что тако UI и разарботчики придумывали всё за бизнес.
В современном мире разработки , в совремнных компаниях, эти роли разделены.
Бизнес аналитик проектирует "Что" делает система. И вот там BPMN, CJM, юзкейсы и прочее... и ему пофигу, прокините вы это через 1 монолит или 20 микросервисов.
Системный аналитик проектирует "Как" это реализовано в системе. И вот тут начинаются БД, журналы, ресты и прочее, в купе с архитектурой.
Это две разные роли.
Объединять их в одну это устарело лет 5-10 назад.
А джуны читают этот ваш "полный гайд" и становятся недоаналитиками во всём.
Ну, тоесть ,SA должен своего техдира привести на вэбинар что ли?))
Я не понял для кого этот вэбинар....
Как бы адекватный SA должен проектировать. Но если проектируют разработчики "на коленках по ходу написания кода", то SA что может сделать? Пойти руководству настучать "у вас процессы говно"???
Как бы процессы обычно выстраивают либо сверху, и тогда надо делать вэбинар для руководителей, либо они сами ввстраиваются " кто как модет", и тогда разрабы, привыкшие писать отсеьятину, пошлют SA с его инициативами ... записывать за ними их гениальный код.
Да, но виплимиты тогда не работают.
Мне надо переводить в тестирование, а там уже 5 из 5ти...
Из моего опыта упущен важный момент: вы рассматриваете команду как некий юнит, который решает задачи. В практике, где вся команда - универсалы и могут делать любые задачи (писать код, тестировать, писать доку) это работает.
Как только вы выделяете в команде роли ( системный аналитик, FE,BE разработчики, QA) то процесс ломается. Потому что для команды статус "в работе", а внутри это передача от этапа к этапу. И отслеживать это становится невозмодно и все виплимиты идут лесом...
Если есть опыт канбана в командах с несколькими ролями - опишите пожалуйста.
О, и спасибо за минус! Что ещё ждать от российского автопрома!
Чушь какая!
Ничего оно не объединяет!
Очередное отдельностоящее приложение.
Ну добавили энергию москвы, а яндекс проигнорили.
Есть более охватывающие приложения, где действительно есть почти все зарядные станции. 2chargers например!
Это просто дребедень!
Это некорректно сравнение. Разработчик производит код. Это результат.
Документация описывает этот код.
Вы же не будете утверждать, что план разводки розеток и сами провода, лежащие в стене, это одно и тоже???
Эмм... нет, это компании с незрелыми процессами разработки так работают.
Компании со зрелыми процессами давно работают с documentation first. А те кто хотят это делать быстро и эффективно реализуют его через doc as code.
Я пытаюсь себе представить аналогию с ремонтом. Вы взяли сантехника, электрика, и маляра и вовлекли в продумывание дизайна квартиры...
Сомнительная эффективность, как по мне.
Почему вы не стали выстраивать качественный процесс с системным анлаизом? Чтобы каждый занимался своим профессиональным делом, а не думал о "чужих" областях?
Вообще то, в крупняках и современных компаниях роли СА и БА разделены. И современные СА должны хорошо отвечать на тех. вопросы, а не рассказывать про сбор требований и их типы, и упоси ГОСТы. Если у вас спросили всё из этого списка, значит процессы в нанимающей компании уже давно морально умтарели.
Ну а если в вас это всё впихивают на курсе, значит вы выбрали не тот курс...
Вообще, в компаниях с современными процессами практикуют documentation first.
Т.е. сваггер появляется даже до начала разработки и всем участникам процесса контракт известен заранее.
При этом, одного сваггера недостаточно. Свагер описывает контракт взаимодействия, а не логику работы. Может быть два идентичных метода, возвращающие одинаковые объекты, но совершенно разные данные. Поэтому к каждому методу всё равно необходимо текстовое описание логики работы.
Вы на верном пути, но это только часть необходимой документации.
Очередная статья по продвижению тг канала...
Компании, использующие современные процессы разработки давно разделили роли системного и бизнес аналитика. Статья скорее заирагивает деятельность бизнес аналитика или продуктового. На системных аналитиков вличние несколько иное.
У меня просто два дополнительных мобильных экрана, каждый по 100$.
Ставлю один вертикально.
Всё.
Так много интересного можно написать про яхтинг. Даже про яхтинг в IT. Например, ребята организуют чудесную IT-регату.
А не вот это вот...
Проскролил. Даже на скролинг пожалел потраченного времени. Я не понимаю, зачем об ЭТОМ странном опыте писать на Хабре.
Честно говоря, очень поверхностно.
Аналогия со строительством моста не понятна. Процессы строительства больше перекликаются с процессом разработки, а не с процессом документирования по факту. С этой точки зрения, вы не строите мост, а восстанавливаете проектную документацию на этот мост после пожара в архиве. Берёте инженера с линейкой, и ходите и всё измеряете. Это больше похоже к.м.к.
В остальном, не понятна цель статьи. Запрос в гугле " кто такой техпис" даст примерно такую же информацию... Ощущение, что хотелось что-то написать и это была единственная тема, через которую можно упоминуть свой ТГ канал...
Ну так вы где вырасли? В тиньке??? Там замкнутая экосистема с весёлым матерком и сомнительными культурными ценностями. Зато расти там можно хоть каждые полгода. И это весь ваш IT опыт? Вы там на айтишников насмотрелись?
Я честно попробовал, но даже по инструкции ничего не получилось.
В статье нет примера результата. Оценить качество документации, которую подготавливает инструмент не получилось.
Формат docx широко распространён в узком кругу опрошенных. Хранить доку в docx это лет 15-20 назад было базой. Сейчас - кто во что горазд. Я например, продвигаю doc as code и пишу на markdown. Может имеет смысл присмотреться к другим форматам...
Вообще, openApi и swagger вполне достаточны для документирования. Примеры есть, подёргать можно. В дополнительном описании эндпоинтов может быть описана системная логика. Но вы такое описание из свагера не вытащите, это не возможно. Тогда встаёт вопрос: кто потребитель вашей документации и для чего она вообще нужна?
В развитых проектах, в отличии от "наколеночной разработки", сначала готовится документация, а потом пишется код. И опять таки встаёт вопрос: кто потребитель вашего инструмента, для кого вы его хотите сделать?
Ну и конкуренция с ИИ. Сейчас модели вполне сносно готовят документацию по эндпоинтам проходясь по коду и вытаскивая всю подноготную из системной логики.
Возможно, есть процессы, в которых данный инструмент будет полезен. Тогда, для продолжения работы, необходимо понимать, что это за процессы, как этот инструмент будет встроен в процесс и какие артефакты будет готовить и как будет их обновлять. Определится с тем, кто является потребителем самого инструмента и кто является потребителем результата его работы. И спросить не у всего сообщества (слишком широкий охват и большой процент нецелевой аудитории) а именно тех, для кого этот инструмент будет полезен.
Привет.
Я сам пишу спеки в doc-as-code давно.
Сейчас встал вопрос, а как затащить в подход и другие направления? По хорошему нужен редактор wysiwyg, работающий с git.
Яндекс.Вики работает на базе markdown, но хранит не в git.
Рассматриваю сейчас Gramax.
Собственно вопрос: что-то встречали похожее? Так чтобы и wysiwyg и markdown и хранить в git?