В теме 3 ответа, и 4 участника, последнее обновление сделано пользователем 
Надежда Тарасюк 10 г, 6 мес. назад.
-
Сообщения
-
Здравствуйте, коллеги!
Мне поступила задача – отрисовать вайрфреймы для мобильного приложения и web панели управления. На входе есть описание бизнес-задачи клиента, перечень фич и несколько скетчей.
В начале мне все казалось предельно понятно, но после пары дней работы на митингах возникает много вопросов и разногласий с сотрудниками. Проблема в том, что мы все по-разному понимаем бизнес-логику работы системы.
Я, наверное, допустил ошибку, что не настоял на проработке логики работы системы перед вайрфреймами? Т.е. можно было начать с UML или BPMN диаграммы отражающую самые важные (и спорные) моменты в работе системы. Это так?
Я заранее извиняюсь за, возможно, глупый вопрос. Хотелось бы услышать мнения опытных коллег, как нужно действовать, в ситуации:
Компания подписала контракт на пакет часов (40-60) на бизнес-анализ
Клиент прислал видение проекта, поверхностное описание сценария использования системы, скетчи
Руководство хочет из всего этого получить от меня – вайрфремы, чтобы доказать клиенту что мы отлично понимаем задачу и готовы реализовать проектДобрый день.Вначале по тексту немного комментариев:
1) Не совсем понятно, что такое UML- или BPMN-диаграмма, отражающая спорные моменты. Визуализация — это всего лишь способ подачи информации… в некоторых ситуациях, помогающий прояснить участникам коммуникации и автору неясные/упущенные моменты в требованиях. Ну то есть, это не панацея от незнания логики.
2) Компания оценила трудозатраты на анализ без вашего участия? Круто… Теперь, похоже, придется исходить из ограничений, а не из потребностей.
А в чем конкретно сейчас сложность? Начинайте прояснять непонятные моменты с людьми на стороне клиента, отвечающими за эту область. Исходя из предоставленной информации, я могу предположить, что либо доступ к клиенту уже по какой-то причине закрыт, либо проблема именно в часах на анализ. В первом случае, попытайтесь этот доступ либо открыть:), либо поясните все, что вы думаете о подобных процессах и явно выделите все ваши предположения и неясные/неизвестные моменты, на которых будут базироваться ваши скетчи. Во втором случае — ну… попытайтесь донести необходимость пересмотра контракта, либо же фокусируйтесь на главном, и опять же поясните явно, что вы не успели сделать или проработали не так глубоко, как хотелось бы, в силу ограничения времени.
Я возможно чуть не в ту сторону начал размышлять. Поясните, пожалуйста, в чем собственно главные проблемы. Ну то есть, если вы БА, то не знать некоторые требования на каком то этапе — это нормально, их обычно можно узнать.
Очень интересный вопрос! С этим я уже давно сталкиваюсь. Всю логику работы системы с помощью только UML, BPMN и вайрфреймов не возможно отработать, т.к. пока все не пощупал руками (т.е. на практике) о многих необходимых фичах даже не догадываешься. Лучший выход — все отрабатывать на динамических интерактивных прототипах, с последующим их согласованием у Заказчика. Об этом был мой доклад на конференции «Analyst Days 2014″. Тезисы доклада Вы можете просмотреть с моего сайта ( http://www.webmax.by/docs/ad2014/home.html — кстати тут сама листалка страниц сделана в Axure RP, т.е. это тоже динамический прототип), ну и по ссылке (http://www.webmax.by/docs/shicht/home.html) представлен пример достаточно сложного динамического прототипа-имитатора на котором можно показать очевидные преимущества такого метода. Хочу ещё заметить, что по-сравнению с написанием кода для программы-прототипа здесь большой выигрыш во времени и все гораздо легче изменять и править.Добрый день,Я согласна с Германом в том, что это нормально не знать всех нюансов логики системы в начале этапа анализа (собственно узнать у заказчика и продумать эти нюансы — это и есть работа аналитика).
Из самого очевидного — пообщайтесь с заказчиком и изучайте аналогичные продукты (как они справляются с теми вопросами, что возникают у вас).
И 60 часов вполне может быть достаточно на прояснение таких вещей и создание вайфреймов несложной системы на мобильном устройстве (говорю очень приблизительно, т.к. деталей не знаю).Меня насторожило две фразы в вашем вопросе:
1) «На входе есть описание бизнес-задачи клиента, перечень фич и несколько скетчей.»
То есть кто-то уже провел часть аналитической работы ? Возможно вам стоит поплотнее взаимодействовать с этим человеком — он сможет прояснить часть ваших вопросов.2) «В начале мне все казалось предельно понятно, но после пары дней работы на митингах возникает много вопросов и разногласий с сотрудниками. Проблема в том, что мы все по-разному понимаем бизнес-логику работы системы.»
Если под сотрудниками вы подразумеваете ваших коллег (разработчиков, тестеров), то, похоже, у вас все с ног на голову)
Если я верно поняла, то группа людей, которые не имеют выхода к заказчику, не знают его, его бизнес, потребности и т.д. достаточно долго, чтобы делать верные предположения, не имеют достаточной экспертизы в предметной области (иначе бы долгих обсуждений не было — все бы согласились с экспертом) сидят и «придумывают» как система должна себя вести?
И какова ваша роль, как аналитика, в таких обсуждениях?
Вы должны авторизироваться для ответа в этой теме.
