Статья не соответствует времени: в 2023 году уже почти ни у кого не должно вызывать вопрос "Что такое и для чего нужно ТЗ?". Другое дело, что в современных реалиях разработки ПО ТЗ стало почти исключительно формальным документом, приложением к договору, но никак не спецификацией требований, которой может воспользоваться команда разработки. В общем, я к тому, что такие статьи периодически всплывают на Хабре, но не вызывают ничего, кроме удивления.
Так как же эти советы по организации работы с техдолгом помогут снизить вероятность конфликта между бизнесом и разработкой? Самое важное ведь не рассказали - про методы убеждения заказчика выделять ресурсы на минимизацию техдолга.
А если серьёзно, то в мои школьные годы никому при желании не мешало забивать на отдельные предметы и освобождённое время вкладывать в другие увлечения. Правда, когда я заканчивал среднюю школу, не было ещё ЕГЭ... Наверное, сейчас тоже можно найти оптимальный подход к распределению усилий в школе, чтоб и лишнее в голову не пихать и при том суметь поступить в ВУЗ.
Ну и важен фактор вовлечённости родителей в процесс обучения своего чада: благо, айтишники не могут жаловаться на жизнь - мол, ни времени, ни сил, не средств нет, чтоб инвестировать в дополнительное образование своих детей.
Можно дополнить шаблон разделами про асинхронное взаимодействие (перечень каналов через Kafka/Rabbit) и со сценариями использования сервиса; а в разделе про REST отдельно упомянуть про список ошибок и аутентификацию.
Если рассматривать статью как инструкцию для коллег, кто ещё не проходил путь проектирования API с нуля, то на мой взгляд для некоторых шагов не хватает объяснения их назначения (в частности, 3,4 и 6) - что может быть не совсем очевидно.
В п.2 есть некоторая путаница с терминологией: по смыслу там ведь выявляются сущности предметной области, которые затем по какому-то принципу преобразуются в ресурсы API и уже лишь на 6м шаге это дело распределится по компонентам.
Справедливости ради, стоило упоминуть и о минусах Design First. Пусть их в оригинальной статье набралось немного, но всё же - нет большого резона проектировать API, когда нужно быстро построить решение для проверки концепта или сам сервис незамысловатый.
Никак. Скорее всего, Тараповский либо нагло врёт, либо банально некомпетентен. Если в каких-то странах (например, Казахстане) ещё год назад можно было оформить пластик по доверенности или даже онлайн, то сейчас такой возможности нет - нужно лично явиться в отделение банка.
Шаблоны, чеклисты и прочие средства-помощники для проработки документации хороши, когда аналитику требуется многократно создавать описания для однотипных задач. И тут дизайн-система хороший пример - в том смысле, что она решает похожую задачу, но применимо к работе дизайнера и фронтендера. Уверен, что при создании ГосУслуг и то и другое просто необходимо - и потому я скорее удивлён тому, что это не было сделано ещё много лет назад.
Поддерживаю претензию к слабой аргументации! Если провести аналогию с продуктовой разработкой (то есть дать крен в область проблем), то с тем же успехом можно заявить, что аналитики не должны заниматься, например, формированием продуктовых гипотез и выработкой метрик использования продукта, т.к. делают они это плохо да и вообще эта работа владельца/менеджера продукта.
И всё же не совсем понятно, какую задачу позволяет решать предложенный чеклист для проработки требований к UI. Если речь про то, чтобы не забыть указать такие детали, как формат отображения значения, валидации введённого значения, состояние элемента в зависимости от условий и т.п. - то это применимо скорее для относительно простых элементов вроде поля ввода, выпадающего списка, чекбоксов; поведение карты и списка уведомлений намного сложнее и требует более специфического описания.
Сбер гребёт (или грёб) джунов-аналитиков лопатами и обучает.
https://tinyurl.com/2ckxlybh Ну уж прям-таки гребёт! Истории людей без опыта работы в айти (в "интернетах" есть много статей от тех, кто прошёл расхваленные курсы) показывают, что можно месяцами искать работу - пройти десятки собеседований и остаться без единого предложения. И это было ещё в "славные" времена начала эпохи Ковида.
На вход — базово понимать, как работает интернет/ПК, что такое БД и желание глубоко разбираться в своей предметной области.
Как "работает" Интернет и ПК изучают на первом курсе технического ВУЗа и даже в старшей школе. Только это никак не может рассматриваться как достаточное условие для того, чтобы всерьёз недеяться на трудоустройство на позицию системного аналитика.
Проблема действительно не высосана из пальца. Однако подача материала аккурат соответствует эпохе тик-тока. Если кому интересно более основательное исследование по теме, советую книгу https://www.livelib.ru/book/1000497636-the-shallows-what-the-internet-is-doing-to-our-brains-nicholas-carr.
Статья не соответствует времени: в 2023 году уже почти ни у кого не должно вызывать вопрос "Что такое и для чего нужно ТЗ?". Другое дело, что в современных реалиях разработки ПО ТЗ стало почти исключительно формальным документом, приложением к договору, но никак не спецификацией требований, которой может воспользоваться команда разработки. В общем, я к тому, что такие статьи периодически всплывают на Хабре, но не вызывают ничего, кроме удивления.
Так как же эти советы по организации работы с техдолгом помогут снизить вероятность конфликта между бизнесом и разработкой? Самое важное ведь не рассказали - про методы убеждения заказчика выделять ресурсы на минимизацию техдолга.
Автор несправедливо не включил в список ОРКСЭ!
А если серьёзно, то в мои школьные годы никому при желании не мешало забивать на отдельные предметы и освобождённое время вкладывать в другие увлечения. Правда, когда я заканчивал среднюю школу, не было ещё ЕГЭ... Наверное, сейчас тоже можно найти оптимальный подход к распределению усилий в школе, чтоб и лишнее в голову не пихать и при том суметь поступить в ВУЗ.
Ну и важен фактор вовлечённости родителей в процесс обучения своего чада: благо, айтишники не могут жаловаться на жизнь - мол, ни времени, ни сил, не средств нет, чтоб инвестировать в дополнительное образование своих детей.
Можно дополнить шаблон разделами про асинхронное взаимодействие (перечень каналов через Kafka/Rabbit) и со сценариями использования сервиса; а в разделе про REST отдельно упомянуть про список ошибок и аутентификацию.
Если рассматривать статью как инструкцию для коллег, кто ещё не проходил путь проектирования API с нуля, то на мой взгляд для некоторых шагов не хватает объяснения их назначения (в частности, 3,4 и 6) - что может быть не совсем очевидно.
В п.2 есть некоторая путаница с терминологией: по смыслу там ведь выявляются сущности предметной области, которые затем по какому-то принципу преобразуются в ресурсы API и уже лишь на 6м шаге это дело распределится по компонентам.
Справедливости ради, стоило упоминуть и о минусах Design First. Пусть их в оригинальной статье набралось немного, но всё же - нет большого резона проектировать API, когда нужно быстро построить решение для проверки концепта или сам сервис незамысловатый.
Рутюб есть. Осталось дождаться Рупедии. И больше нам ничего не надо! ?
Может быть, медицина когда-нибудь позволит восстанавливать обонятельный эпителий, если он был повреждён воздействием химических веществ или вирусом.
Я бы сказал, что это больше похоже на Scope and Vision, который часто составляют после фазы Discovery.
Вот о самом любопытном как раз умолчали! Что "исповедуете" - SAFe, LeSS или что-то самобытное?
Никак. Скорее всего, Тараповский либо нагло врёт, либо банально некомпетентен. Если в каких-то странах (например, Казахстане) ещё год назад можно было оформить пластик по доверенности или даже онлайн, то сейчас такой возможности нет - нужно лично явиться в отделение банка.
Шаблоны, чеклисты и прочие средства-помощники для проработки документации хороши, когда аналитику требуется многократно создавать описания для однотипных задач. И тут дизайн-система хороший пример - в том смысле, что она решает похожую задачу, но применимо к работе дизайнера и фронтендера. Уверен, что при создании ГосУслуг и то и другое просто необходимо - и потому я скорее удивлён тому, что это не было сделано ещё много лет назад.
Поддерживаю претензию к слабой аргументации! Если провести аналогию с продуктовой разработкой (то есть дать крен в область проблем), то с тем же успехом можно заявить, что аналитики не должны заниматься, например, формированием продуктовых гипотез и выработкой метрик использования продукта, т.к. делают они это плохо да и вообще эта работа владельца/менеджера продукта.
И всё же не совсем понятно, какую задачу позволяет решать предложенный чеклист для проработки требований к UI. Если речь про то, чтобы не забыть указать такие детали, как формат отображения значения, валидации введённого значения, состояние элемента в зависимости от условий и т.п. - то это применимо скорее для относительно простых элементов вроде поля ввода, выпадающего списка, чекбоксов; поведение карты и списка уведомлений намного сложнее и требует более специфического описания.
Автор, правительство уже предусмотрело решение описанной проблемы - с 2022г в ВУЗах стали появляться "цифровые кафедры" https://digital.gov.ru/ru/activity/directions/1085/
Сбер гребёт (или грёб) джунов-аналитиков лопатами и обучает.
https://tinyurl.com/2ckxlybh Ну уж прям-таки гребёт! Истории людей без опыта работы в айти (в "интернетах" есть много статей от тех, кто прошёл расхваленные курсы) показывают, что можно месяцами искать работу - пройти десятки собеседований и остаться без единого предложения. И это было ещё в "славные" времена начала эпохи Ковида.
На вход — базово понимать, как работает интернет/ПК, что такое БД и желание глубоко разбираться в своей предметной области.
Как "работает" Интернет и ПК изучают на первом курсе технического ВУЗа и даже в старшей школе. Только это никак не может рассматриваться как достаточное условие для того, чтобы всерьёз недеяться на трудоустройство на позицию системного аналитика.
Именно долларов? :)
Раз на Марсе не удалось создать колонию, то хотя бы городок в Техасе ?
Заявлялось, что эта мера по удержанию/возвращению ценных кадров в Россию.