Мы пришли к выводу, что ИТ‑шник, который каждый год меняет свое место работы, по факту не может создать себе комфортное рабочее пространство и наладить взаимоотношения коллегами по работе.
Такой вывод сделан с опорой на печальную статистику найма сотрудников в вашу компанию? В начале статьи слишком кратко упомянуто про "собственный опыт и знакомых тимлидов", но не уточняется их место работы по отношению к автору. В общем, не хватает конкретных кейсов, чтобы можно было поверить, понять или даже посочувствовать.
Изменение требований это естественный процесс. Куда сложнее ситуация, когда изначально упущены принципиальные хотелки. Причём пожелания заказчика это лишь часть того, что должно быть учтено в процессе выявления требований: ведь в проекте обычно задействованы различные заинтересованные лица, и анализ этих групп обычно выполняется на первичном этапе работ по созданию решения.
Аналитик часто неосознанно, а иногда и осознанно, может выполнять функции проектного менеджера (руководителя проекта). Почему так происходит?
Истинных причин скорее лишь две: 1 - потому что работодатель решил оптимизировать проектную команду сэкономить на ФОТ, 2 - аналитику предложили точку роста в другую роль впихнули обязанности, не обговоренные на собеседовании. Другие мотивы лишь для ширмы. Впрочем, сотрудник действительно может воспользоваться ситуацией, но при этом никак не должен.
Применимо прежде всего для заказной или внутренней разработки. Когда необходимо создавать или дорабатывать продукт, то нужны другие подходы для выявления требований - генерация и валидация гипотез вместе с PO, изучение систем конкурентов, анализ поведения пользователей...
Ситуация схожа с применением ин.яза: можно таскать с собой переводчика, а можно выучить самому на хорошем уровне и не быть зависимым от другого человека или технических средств.
Да какая разница, каким способом написана статья? Если в ней мало пользы (солянка из нескольких случайно выбранных сложностей в работе аналитика), то как она появилась на свет, уже не принципиально.
Дело не в желании потешить самолюбие, а банальном отсутствии понимания, как правильно проводить собеседование. Поэтому обычно и задают груду теоретических вопросов, которые не выявляют опыт и не раскрывают потенциал к решению практических задач.
Верно подмечено! Не хватает анализа корреляции от предметной области, вида системы и ключевых задач. Но видимо, такая информация не собиралась. Хотя приписка, что опрос проводился в группах финтех-компаний отчасти объясняет полученную картину.
Видимо, это как раз те команды (см. первую таблицу), где уже есть сотрудники, которые просто пересказывают слова заказчика, потому что не смогли разобраться в предметной области, и тем самым увеличивают сроки и стоимость разработки.
Как по мне, так "самое ненавистное" в работе аналитика - знать, что твой коллега когда-то не оформил требования/постановку должным образом; и теперь ты должен тратить своё и его время (а часто ещё и других участников проекта) на восстановление этих знаний.
Можете рассказать чуть подробнее, каким образом экспертная группа оценивала кандидатов, чтобы избежать субъективности? Ведь если у "оценщиков" нет формальной методики, то избежать неточности результатов весьма непросто; тем более в ситуации, когда состав такой группы меняется время от времени.
Это не вопрос из разряда бинарных: можно обойтись без документации или нет? В такой постановке сразу читается две крайности, где "справа" - тонны текста и картинок. А дело в необходимом и достаточном наборе артефактов и степени детализации их содержания! Ведь на каком-то проекте хватит user stories + BDD, а на другом нужно готовить ТЗ, ЧТЗ, ТП и далее C4 схемы, набор use cases с sequence diagram, ER диаграммы и т.п.
Мы пришли к выводу, что ИТ‑шник, который каждый год меняет свое место работы, по факту не может создать себе комфортное рабочее пространство и наладить взаимоотношения коллегами по работе.Такой вывод сделан с опорой на печальную статистику найма сотрудников в вашу компанию? В начале статьи слишком кратко упомянуто про "собственный опыт и знакомых тимлидов", но не уточняется их место работы по отношению к автору. В общем, не хватает конкретных кейсов, чтобы можно было поверить, понять или даже посочувствовать.
Изменение требований это естественный процесс. Куда сложнее ситуация, когда изначально упущены принципиальные хотелки. Причём пожелания заказчика это лишь часть того, что должно быть учтено в процессе выявления требований: ведь в проекте обычно задействованы различные заинтересованные лица, и анализ этих групп обычно выполняется на первичном этапе работ по созданию решения.
Аналитик часто неосознанно, а иногда и осознанно, может выполнять функции проектного менеджера (руководителя проекта). Почему так происходит?Истинных причин скорее лишь две: 1 - потому что работодатель решил
оптимизировать проектную командусэкономить на ФОТ, 2 - аналитикупредложили точку роста в другую рольвпихнули обязанности, не обговоренные на собеседовании. Другие мотивы лишь для ширмы. Впрочем, сотрудник действительно может воспользоваться ситуацией, но при этом никак не должен.Применимо прежде всего для заказной или внутренней разработки. Когда необходимо создавать или дорабатывать продукт, то нужны другие подходы для выявления требований - генерация и валидация гипотез вместе с PO, изучение систем конкурентов, анализ поведения пользователей...
Ситуация схожа с применением ин.яза: можно таскать с собой переводчика, а можно выучить самому на хорошем уровне и не быть зависимым от другого человека или технических средств.
Да какая разница, каким способом написана статья? Если в ней мало пользы (солянка из нескольких случайно выбранных сложностей в работе аналитика), то как она появилась на свет, уже не принципиально.
В российских современных ЖК так же делают. Но учитывая общее качество строительных работ, лично я решил всё же кинуть трубку до канализации.
Дело не в желании потешить самолюбие, а банальном отсутствии понимания, как правильно проводить собеседование. Поэтому обычно и задают груду теоретических вопросов, которые не выявляют опыт и не раскрывают потенциал к решению практических задач.
Верно подмечено! Не хватает анализа корреляции от предметной области, вида системы и ключевых задач. Но видимо, такая информация не собиралась. Хотя приписка, что опрос проводился в группах финтех-компаний отчасти объясняет полученную картину.
Видимо, это как раз те команды (см. первую таблицу), где уже есть сотрудники, которые просто пересказывают слова заказчика, потому что не смогли разобраться в предметной области, и тем самым увеличивают сроки и стоимость разработки.
Оставьте в покое уже тему с Use Cases! Технике более 20 лет, но нет - аналитики продолжают про неё рассказывать, будто это что-то невиданное.
SMART не методология, а техника постановки целей или задач. Применяйте инструмент по назначению, и не будет возникать вопрос "Почему оно не работает?"
Как по мне, так "самое ненавистное" в работе аналитика - знать, что твой коллега когда-то не оформил требования/постановку должным образом; и теперь ты должен тратить своё и его время (а часто ещё и других участников проекта) на восстановление этих знаний.
Минтруда с вами не согласно https://profstandart.rosmintrud.ru/obshchiy-informatsionnyy-blok/natsionalnyy-reestr-professionalnykh-standartov/reestr-professionalnykh-standartov/index.php?ELEMENT_ID=126779
Почему "чатом" называют возможность отправить в одну сторону предопределённое сообщение?
В статье - да. Но на почту присылаете ссылку на Яндек.Диск, где выложены книги.
Можете рассказать чуть подробнее, каким образом экспертная группа оценивала кандидатов, чтобы избежать субъективности? Ведь если у "оценщиков" нет формальной методики, то избежать неточности результатов весьма непросто; тем более в ситуации, когда состав такой группы меняется время от времени.
В джентельменском наборе моделей почему-то отсутствует архитектура системы. Хотя тот же С4 упомянут.
А вы литературу для подготовки распространяете, конечно же, с разрешения правообладателей? ;)
Это не вопрос из разряда бинарных: можно обойтись без документации или нет? В такой постановке сразу читается две крайности, где "справа" - тонны текста и картинок. А дело в необходимом и достаточном наборе артефактов и степени детализации их содержания! Ведь на каком-то проекте хватит user stories + BDD, а на другом нужно готовить ТЗ, ЧТЗ, ТП и далее C4 схемы, набор use cases с sequence diagram, ER диаграммы и т.п.