Перечитываю комментарии, работая над продолжением статьи. Ниже в комментариях вроде разобрались, что я имела в виду, что аналитик, в основном, не заменяет архитектора, а чуть-чуть разбирается в архитектуре (на уровне, который необходим для подготовки качественных требований и разговора с программистами на близком языке: ER-модель, знание модели данных и понимание организации интеграции между системами, или что такие-то Api используют и возвращают такие-то параметры, etc).
Хотя мне действительно везло на команды, где аналитик выступал в роли архитектора, но это ведь не эталон, а просто специфика.
Смутившую вас фразу:
«а) на фазе обсуждения бизнес идеи аналитик может подсказать:
— возможна ли реализация,
— способы и стоимость реализации.» надо будет заменить на «участвует в обсуждении бизнес идеи и оценке». Ибо, хоть мне и приходилось во всех проектах собирать команду и заниматься оценкой, но это было пересечение с ролью ПМ, что тоже специфика, а не эталон :-)
Еще раз повторюсь:)
Мнением архитектора и других специалистов никто не злоупотребляет.
Но, всё же, вы недооцениваете труд и знания аналитиков:) Тот же Вигерс (классика по требованиям) приводит в шаблоне спецификации требований такие разделы, как модель БД (логическая), требования к пользовательским и внешним интерфейсам, etc.
А еще часто залезть в БД, посмотреть на структуру, связи, атрибуты, а так же посмотреть код работающей системы — чуть ли не единственный источник требований. И об этом тоже пишут уважаемые авторы книг, по которым сдается сертификат по системному анализу. Наверное, мне стоило всюду в статье использовать термин «системный аналитик», а не просто аналитик.
Хотя, будем откровенны, у нас часто бизнес аналитиков называют системными и наоборот :)
Спасибо!
Каждый должен заниматься своим делом, и делать его хорошо, согласна.
Просто нет стандартной должностной инструкции аналитика. В зависимости от компании, от проекта, требования к такой роли варьируются. Часто происходит совмещение: аналитик+ПМ.
Где-то аналитик занимается только функциональными требованиями, где-то — проектирует БД, составляет use cases (в том числе и вызов нужных API на соответствующих шагах сценария), моделирует прототипы пользовательского интерфейса, описывает правила интеграции систем.
Здравствуйте!
Спасибо за комментарий.
Правильно я понимаю вашу мысль, что аналитик должен заниматься только требованиями и не распыляться на другие задачи?
Так складывалось неднократно, что в мои обязанности, как аналитика, входила также и оценка сроков.
При необходимости, привлекала к этому процессу программистов, тестировщиков, админа, дизайнеров. Стандартные, несложные проекты сама могла оценить. К счастью, заказчики не жаловались.
Спасибо за ваш комментарий, за ваш опыт.
Действительно, если задача не стандартная, то я общаюсь с командой (и не только с программистами, а и с дизайнерами, тестировщиками). Мы совместными усилиями разрабатываем решение или варианты решений, после чего предложение озвучивается заказчику или менеджеру проекта.
Неужели так смутила фраза в статье, что аналитик принимает участие и на этапе обсуждения бизнес идеи, и что-то может подсказать?
Мне кажется, что это неплохой вариант, ведь аналитику потом писать требования, пусть будет в курсе с самого начала проекта.
Возможно, у вас другой опыт, процесс организован иначе. Я описала свой опыт.
лично у меня не было опыта использования таких инструментов преобразования. Ну а план тестирования тестировщики сами составляли обычно, я могла просмотреть, ответить на вопросы при необходимости.
Здравствуйте, спасибо за комментарий!
Правды ради стоит сказать, что в описанной истории на документе таки была подпись руководителя программистов и (формально) вопросов у него не было.
Там именно некоторые требования звучали неконкретно, их можно было интерпретировать по-разному. Программистам все было понятно. Но поняли неправильно. Тестировщики интерпретировали их, как и я, а программисты иначе.
Но да, не могу не согласиться, что нужно программисто спрашивать, обсуждать требования. И об этом как раз пункты 3.2 и 3.3 в статье.
Книг достаточно прочитала, да и до аналитики немного работала в разработке и проектировании.
Но я Вас понимаю, лучше, когда есть и архитектор, и аналитик.
А вот на практике бывает иначе. В двух компаниях из четырех от меня требовали заниматься проектированием. Пришлось разбираться. И сейчас мне кажется, что даже хорошо, когда аналитик в состоянии копнуть немного глубже.
Здравствуйте!
спасибо за Ваш опыт!
В моей практике простые или стандартные изменения оценивались аналитиками, более сложные — сообща. А вы все изменения командно оцениваете? Даже если заказчик просто узнает потенциальную возможность и примерные споки/влияние?
А откуда вообще берется опыт? (Риторический вопрос). Аналитику в принципе нужно много знать и уметь. Мне приходилось работать в компаниях, где роли аналитика и архитектора были совмещены. И знаю, что не только в тех компаниях так было.
На этап обсуждения бизнес-идеи уважающий себя аналитик приходит подготовленный. А если знания, опыта не хватает, чтоб сходу посоветовать, то не зазорно взять время и провести дополнительный анализ.
Решения принимает на основании анализа системы (как ни банально это прозвучит), знаний и опыта. Бывают случаи (часто!), когда аналитик выполняет функцию архитектора. В разных проектах разное распределение ролей.
По поводу подсказать или транслировать: оба варианта имеют место быть. Глупо злоупотреблять опытом гуру. Иногда нужно собрать их мнение и транслировать заказчику, это тоже работа аналитика, он выступает звеном между заказчиками и разработчиками.
На счёт оценки системы: не могу сходу ответить. Оценка возможностей системы, существующих решений, уровня программистов и т.д. может занимать достаточно долгое время.
Здравствуйте!
Можно получать знания по-разному. Что-то с hh почерпнуть, что-то — на основании книг, опыта, ошибок.
Я поделилась ошибками и выводами первого полугодия работы. Кому-то может это пригодиться, кто-то научиться чему-то на моих ошибках. Буду рада.
Здравствуйте!
Когда я там начинала работать, отношений с agile у компании не было. А в году 2010 или 11-м некоторые менеджеры проектов стали смотреть в сторону agile и пробовать на подходящих проектах.
Хотя мне действительно везло на команды, где аналитик выступал в роли архитектора, но это ведь не эталон, а просто специфика.
Смутившую вас фразу:
«а) на фазе обсуждения бизнес идеи аналитик может подсказать:
— возможна ли реализация,
— способы и стоимость реализации.» надо будет заменить на «участвует в обсуждении бизнес идеи и оценке». Ибо, хоть мне и приходилось во всех проектах собирать команду и заниматься оценкой, но это было пересечение с ролью ПМ, что тоже специфика, а не эталон :-)
Мнением архитектора и других специалистов никто не злоупотребляет.
Но, всё же, вы недооцениваете труд и знания аналитиков:) Тот же Вигерс (классика по требованиям) приводит в шаблоне спецификации требований такие разделы, как модель БД (логическая), требования к пользовательским и внешним интерфейсам, etc.
А еще часто залезть в БД, посмотреть на структуру, связи, атрибуты, а так же посмотреть код работающей системы — чуть ли не единственный источник требований. И об этом тоже пишут уважаемые авторы книг, по которым сдается сертификат по системному анализу. Наверное, мне стоило всюду в статье использовать термин «системный аналитик», а не просто аналитик.
Хотя, будем откровенны, у нас часто бизнес аналитиков называют системными и наоборот :)
Каждый должен заниматься своим делом, и делать его хорошо, согласна.
Просто нет стандартной должностной инструкции аналитика. В зависимости от компании, от проекта, требования к такой роли варьируются. Часто происходит совмещение: аналитик+ПМ.
Где-то аналитик занимается только функциональными требованиями, где-то — проектирует БД, составляет use cases (в том числе и вызов нужных API на соответствующих шагах сценария), моделирует прототипы пользовательского интерфейса, описывает правила интеграции систем.
Спасибо за комментарий.
Правильно я понимаю вашу мысль, что аналитик должен заниматься только требованиями и не распыляться на другие задачи?
Так складывалось неднократно, что в мои обязанности, как аналитика, входила также и оценка сроков.
При необходимости, привлекала к этому процессу программистов, тестировщиков, админа, дизайнеров. Стандартные, несложные проекты сама могла оценить. К счастью, заказчики не жаловались.
Действительно, если задача не стандартная, то я общаюсь с командой (и не только с программистами, а и с дизайнерами, тестировщиками). Мы совместными усилиями разрабатываем решение или варианты решений, после чего предложение озвучивается заказчику или менеджеру проекта.
Неужели так смутила фраза в статье, что аналитик принимает участие и на этапе обсуждения бизнес идеи, и что-то может подсказать?
Мне кажется, что это неплохой вариант, ведь аналитику потом писать требования, пусть будет в курсе с самого начала проекта.
Возможно, у вас другой опыт, процесс организован иначе. Я описала свой опыт.
Правды ради стоит сказать, что в описанной истории на документе таки была подпись руководителя программистов и (формально) вопросов у него не было.
Там именно некоторые требования звучали неконкретно, их можно было интерпретировать по-разному. Программистам все было понятно. Но поняли неправильно. Тестировщики интерпретировали их, как и я, а программисты иначе.
Но да, не могу не согласиться, что нужно программисто спрашивать, обсуждать требования. И об этом как раз пункты 3.2 и 3.3 в статье.
Тестировщики этим занимаются: составляют тест-кейсы и тестируют.
Путем поддержки постоянной обратной связи с заказчиком.
Но я Вас понимаю, лучше, когда есть и архитектор, и аналитик.
А вот на практике бывает иначе. В двух компаниях из четырех от меня требовали заниматься проектированием. Пришлось разбираться. И сейчас мне кажется, что даже хорошо, когда аналитик в состоянии копнуть немного глубже.
спасибо за Ваш опыт!
В моей практике простые или стандартные изменения оценивались аналитиками, более сложные — сообща. А вы все изменения командно оцениваете? Даже если заказчик просто узнает потенциальную возможность и примерные споки/влияние?
На этап обсуждения бизнес-идеи уважающий себя аналитик приходит подготовленный. А если знания, опыта не хватает, чтоб сходу посоветовать, то не зазорно взять время и провести дополнительный анализ.
По поводу подсказать или транслировать: оба варианта имеют место быть. Глупо злоупотреблять опытом гуру. Иногда нужно собрать их мнение и транслировать заказчику, это тоже работа аналитика, он выступает звеном между заказчиками и разработчиками.
На счёт оценки системы: не могу сходу ответить. Оценка возможностей системы, существующих решений, уровня программистов и т.д. может занимать достаточно долгое время.
Можно получать знания по-разному. Что-то с hh почерпнуть, что-то — на основании книг, опыта, ошибок.
Я поделилась ошибками и выводами первого полугодия работы. Кому-то может это пригодиться, кто-то научиться чему-то на моих ошибках. Буду рада.
Когда я там начинала работать, отношений с agile у компании не было. А в году 2010 или 11-м некоторые менеджеры проектов стали смотреть в сторону agile и пробовать на подходящих проектах.