Комментарии 38
Никогда нет времени выполнить работу как следует, но всегда есть время, чтобы переделать.
Задумка хороша - спасибо. Ошибки начинаются в пропущенных кейсах и потому предложила бы к дополнительным вопросам добавить перечень связанного функционала (он упомянут в нагрузке) и описание как такой функционал должен реагировать на фичу.
Да, после такой аналитики и разработки потом хлебнут горя следующие 'поколения'. Особенно, когда внезапно что-то сломается, а из документации только вот такие вот записки на салфетках. Подобный подход, как правило всем очень нравится до первого критичного инцидента на проде. После этого, обычно следует заявление по собственному.
Задача бизнес-аналитика сделать грамотную постановку задачи с описанием всех ключевых моментов. Чем, например, глоссарий, поможет разобраться в причинах, если вдруг что-то пошло не так?
Имхо, надо отталкиваться от объема проекта и сроков. Ни разу не видел проекта, в котором содержится исчерпывающая и актуальная информация на все случаи жизни.
Либо она отсутствует, либо ее так много и она так запутана и объемна, что задачу приходится по полдня ставить.
Бич нашего время, лишь бы сейчас как-то работало, а разбираться уже будут другие. Главное "швабры не разбирать".
Интересно, какого это жить и работать в учреждении с системным подходом, с инженерами в руководстве, грамотными экономистами и без потогонки?
Если придерживаться системного подхода и понимать как устроены процессы, то разобраться не так уж сложно. Да и мой подход не про то, чтобы как-то работало, а про написание простым человеческим языком, понятным всем. Важна суть, а не формат. А вот суть иногда сложнее изложить, если ты не понимаешь про что пишешь.
Интересно, какого это жить и работать в учреждении [...] с инженерами в руководстве
Я работал в плюс-минус таком учреждении. И у меня плохие новости.
Когда инженеры начинают руководить, они превращаются в менеджеров. Потому что им приходится решать чисто менеджерские проблемы. Но, как менеджеры, они уже не так хороши. Поэтому, зачастую, потогонка только крепчает.
Таков мой опыт. Надеюсь, бывает по-другому.
Я разработчик, иногда приходится писать ТЗ самому, чаще получаю ТЗ от аналитика. Так, вот, полностью согласен с автором, что вода в спецификации на доработку только мешает быстрому включению разработчика в процесс. И автор постоянно напоминает о том, что упрощенный подход эффективнее при описании именно доработок системы. Полностью согласен!
PS: важно понимать, что обилие аббревиатуры в тексте - сокращает его длину, но при этом усложняет восприятие.
А какая связь между бизнес аналитикой, кнопками на приложении, структурами данных, таблицами - по-моему это совсем из разных опер понятия
Ой, бизнес-аналитик, на самом деле и жрец, и жнец ... Я не понимаю как писать какие-то требования, если ты не понимаешь, как устроены процессы и системы с которыми ты работаешь.
Ты просто не поняла то, что критикуешь.
Я не критикую, я понимаю когда нужно такое. Я за понимание достаточности и полноты ТЗ для простых задач. Для очень редкой задачи нужно полное ТЗ как из моего примера, а многие, пишут их для просто доработки действующей системы (например, добавить новое поле на страницу формы, при том, что это поле уже есть в системе).
На практике обычно всё сводится к карточке в Jira. Достаточно добавить простое описание и этого хватит, чтобы команда поняла суть и начала работать
Потом искать описание в задачах. Соболезную коллегам через пару месяцев
Отдельная красота, если доработка будет с API. Если сразу все в таске писать явно руками, без вложений сваггера, прям от одной мысли больно. Если нужно сделать ручку, скорректировать DTO какие нибудь
KISS - Keep it simple, stupid. До сих пор пожинаем плоды некачественного ТЗ и его реализации. Приемщиков тоже хочется погладить, утюжком. Доработка по моим замечаниям и предложениям идёт уже 3 год и конца края не видно.
А все из-за того, что ТЗ составляли без оглядки на пользователей и реальные процессы, и реализация проводилась в отрыве от конечных пользователей.
Некачественное ТЗ и ТЗ написанное простым языком это не одно и тоже. Может быть ТЗ оформленное по всем правилам, но в нем не учтено и 10% от нужного. Я в своей статье и писала, что бизнес-аналитик должен понимать процессы и системы с которыми работает. А так же понимать язык пользователей. Это ключевые навыки бизнес-аналитика.
Тоже хочу поддержать автора, все отлично написано. Документацию можно дотянуть в процессе, а вот сделать так чтобы разработчики все поняли и как можно скорее приступили к выполнению задачи, это часто один из приоритетов.
Я обычно рисую сразу схему в BPMN и заводу задачи, добавляя ссылки на них в схему. Это убивает всех зайцев
Не все, к сожалению, могут читать BPMN, да и не всегда можно схемой описать постановку (( Схема это классный инструмент, согласна. Я их чаще "рисую" для себя. Мне так понятнее.
Мы проводили эксперимент с бизнес пользователями, все без проблем читали процессы, к которым имели отношение (правда, брал чуть выше рядовых сотрудников, но такие редко пишут бизнес запросы). Про 'не всегда можно описать постановку' - тут скорее всего просто речь о непонимании бизнес - смысла. Не доводилось встречать процессов, которые нельзя было бы положить на BPMN.Буду рад примерам.
Не все, к сожалению, могут читать BPMN
Я довольно долго работал системным и бизнес-аналитиком в нескольких компаниях. От здравоохранения до стриминговых сервисов. Вы будете смеяться, но за много лет я не видел ни одного человека, который мог читать BPMN.
Чему не учат на курсах бизнес-аналитика: почему шаблоны ТЗ мешают работе