Information
- Rating
- Does not participate
- Location
- Санкт-Петербург, Санкт-Петербург и область, Россия
- Registered
- Activity
Specialization
Systems Analyst, Business Analyst
Lead
From 200,000 ₽
Project management
Organization of business processes
Development of tech specifications
Optimization of business processes
Agile
Information Technology
Automation of processes
Promotion of projects
Мне, кстати, стиль изложения понравился: все логично, и технические детали ложатся в целостную картину.
Я так понимаю, коллега имеет в виду работу бизнес-аналитика, а в статье идет речь о работе системного аналитика. Именно он описывает то, как система должна реализовывать бизнес-требования. Но да, юзер стори надо поменять на ТЗ, тогда вопросов не будет. :-)
Хорошая статья. Мы методом проб и ошибок тоже пришли к такой же схеме взаимодействия. Груминг - вот как называются наши презентации ТЗ разработчикам и тестировщикам! Буду знать. :-)
Мы еще на такие презентации подключаем продакт оунеров. И вот когда от всех приглашенных получен фидбек и апрув, тогда ТЗ передается в разработку. В идеале еще должны быть дизайн-макеты готовы и представлены на таких грумингах.
Тестировщики, кстати, тоже могут давать вполне себе дельные советы по реализации на таких грумингах.
А изменения в ТЗ мы фиксируем в разделе "Изменения" с обязательным описанием причин изменений. Особенно это актуально для сложных задач.
Хотя я работаю в e-com, но деятельность тоже регулируется некоторыми органами. Поэтому все очень похоже. Советы даны правильные.
Есть еще одна проблема, с которой мы сталкиваемся: изменение интеграционного API у регуляторов. Бывают минорные изменения - это не так страшно, а бывают и существенные (например поля, которые были нулабл, вдруг стали не нулабл, а нам никто об этом не сказал, мы стали получать ошибки - пока разбирались, клиенты страдали). И повлиять на это мы, увы, почти никак не можем.
Да, отчасти Вы правы. Мы слепо доверились маркетингу. :-)
Но у нас ситуация, когда у пользователя богатый положительный опыт конкретно в нашем магазине, поэтом мы можем смело доверять анализу его активности и советовать именно то, что выдаст мат модель.
Спасибо. :-)
У нас сейчас в компании сложилась такая структура, что менеджеры проекта больше выполняют роль администраторов проекта. Они подключаются на этапе, когда аналитики передают им готовое ТЗ, назначают ресурсы и уже управляют ими.
Спасибо за комментарий! В итоге так и сделала. :-) Выложила статью еще до того, как до конца продумала и проработала ТЗ. В итоге после дополнительных размышлений сделала да, один endpoint. Но статью решила не исправлять.
Согласна полностью. Шикарная статья. Спасибо автору!
Это не было задачей данной статьи. Я хотела показать, с чем, с кем и на каких этапах приходится работать системному аналитику, что он получает на вход и что выдает на выходе. Детальная проработка требований - это тема отдельной статьи.
Мы используем похожий подход, но кто у вас в итоге описывает обработку ошибок, способы решения, детали реализации? Аналитики? Вы в статье сказали, что аналитик "не способен проектировать решения на уровне системного архитектора".
Я за свой опыт пришла к тому, что аналитик таки должен быть способен на это и еще быть "достаточно технически подкован, чтобы разбираться в сложных программных нюансах". По крайне мере, в общих чертах. В идеале - проконсультировавшись с архитектором. Т.е. в нашем случае аналитик предлагает некое архитектурное решение архитектору, а тот в свою очередь, вносит корректировки при необходимости, затем уже аналитик фиксирует все в документации, которая передается разработчикам.
Согласна, чаще всего именно так и бывает. Самого кассира редко спрашивают, удобно ли ему. Решают за него. :-) Особенно в крупных проектах. Но в небольших, бывают, и спрашивают. Мы вот спрашивали в данном случае. Правда, не самого кассира, а центр обучения кассиров. Ну, почти конечных пользователей. :-)
Но суть статьи в том, что клиент компании - не пользователь системы в данном случае.
Соглашусь частично. Я следую терминологии, определенной Карлом Вигерсом. В его терминологии клиенты - это в том числе и те, кто использует продукт. Т.е. в нашем случае - кассиры. Они же тоже могут и должны влиять на требования к нему, верно? Значит, могут выступать и в роли заказчиков. (Например, им удобнее иметь кнопку внизу справа. Если это не принципиально с точки зрения функциональности, то почему нет?)
Поэтому я все-таки считаю, что Вигерс прав, и пользователи входят в подмножество заказчиков, а не частично с ним пересекается.
Спасибо, буду ждать новой статьи.
Для нас актуализация документации - больной вопрос. Вот думаю над определением триггеров для обновления. Бывают очевидные как в Ваших примерах, а бывают нет. Понимаю, что надо встраивать в жизненный цикл, кое-что уже встроено, но над многим предстоит поработать.
Крайне важный вопрос - как поддерживаете документацию в актуальном состоянии? Кто ее владелец и как он отслеживает изменения, которые нужно отразить в документации?
У нас в компании так было. В итоге получалось нехорошо. Сейчас поменялось на то, как я описала. Пока полет нормальный и довольны все: разработчики, дизайнеры, прожект менеджеры.
Соглашусь с автором. При использовании гибких методологий разработки ПО аналитик должен красной нитью проходить через весь проект от начала и до релиза. Из личного опыта: на первом этапе: опрос бизнеса, выявление требований, анализ возможной архитектуры решения, написание ТЗ, затем — постоянное консультирование разработчиков, разъяснение концепции дизайнерам и выверка макетов, консультирование тестеров по юз кейсам. Если у аналитика в работе не один проект, то важно умение быстро переключаться между контекстами. В общем, аналитики рулят. :-)