Работа аналитика в условиях неопределенности
Отвечаем на вопросы с трансляции
Динар Каримов
Аналитик в Naumen Contact Center
  • Правильно ли я понимаю что нам так или иначе придется разобраться в области заказчика и его системы проектов и нормативной документации?
    Работая в В2В, мы разрабатываем инструменты для бизнеса. Чтобы эти инструменты работали, они должны учитывать специфику бизнеса. Для этого при проектировании инструментов нам надо хорошо понимать предметную область. В нее могут входить такие аспекты как:
    • терминология;
    • бизнес-процессы;
    • бизнес-ограничения — нормативные документы, отраслевые требования, требования законодательства;
    • конкуренты, партнеры и так далее.
    В идеале нужно хорошо изучить и учесть все эти вопросы. Иначе рискуете упустить детали, которые могут повлиять на эффективность разработанного инструмента.

  • Приведите примеры деления новой задачи, в которой много неопределенности, на области и аспекты. Не совсем понимаю, как эта абстракция выражается в документации
    Для начала важно понять, где начинается и где заканчивается ваша зона ответственности в рамках новой задачи.
    Далее посмотрите, какие крупные вопросы необходимо проработать для этой задачи. Если, например, вы бизнес-аналитик, вам может потребоваться подготовить расчет экономического эффекта от реализации функциональности. Чтобы это сделать декомпозируете эту подзадачу на список вопросов, на которые вы должны ответить. Для удобства их лучше приоритезировать. Далее в порядке приоритета или в порядке того, что вам уже известно, отвечаете на них.
    Какую-то информацию вы можете запросить у бизнес-заказчика, какую-то найти сами в документации. Для каких-то вопросов могут потребоваться инструменты, например, схемы бизнес-процессов As Is и To Be.
    Прорабатывайте список, пока не ответите на необходимые вопросы. В результате у вас появляется информация и вы можете выполнить сам расчет и оформить его. Также поступаете с другими крупными вопросами.
  • На сколько DoR и DoD помогает в работе с неопределённостями ? Как реагируют заказчики на просьбу предоставить DoR/DoD для снижения неопределённостей?
    Оба инструмента хорошо решают этот вопрос за счет того, что позволяют контролировать процесс. Если пройтись по этим чек-листам мы видим, что все выполнено: у нас появляется уверенность, что все необходимые вопросы учтены и работы выполнены в полном объеме.
    Но DoR и DoD больше про внутренние процессы в команде. Они могут содержать технические вопросы, о которых заказчик может и не знать. Поэтому эти инструменты больше ориентированы на самих разработчиков. А с заказчиками обычно готовность проверяется при помощи программы испытаний на этапе приемо-сдаточных испытаний.
  • Что делать, если заказчик после оценки, понимает что не готов оплатить всю систему и хочет сократить функционал?

    Это нормальная ситуация. Если заказчик готов отказаться от части функциональности, можно весь scope поделить на модули, подсистемы, эпики, фичи или приоретизировать и выбрать только самое необходимое, чтобы вписаться в бюджет. Либо попытаться договориться об итеративной или инкрементальной разработке.

    Какой формат для описания задач используете при написания тз разработчикам? гост 34/19 трудоемкий. Просто текст читать муторно и не опишешь все тех.моменты. Поделитесь опытом описания задачи

    По поводу шаблона, мне кажется, идеального стандарта нет. Можно использовать и ГОСТ34/19 в том объеме, как это подходит вам. Можно подойти к этому вопросу гибко и посмотреть другие стандарты, если кажется правильным дополнить шаблон разделами из них.

    Без текста к сожалению не обойтись. Чтобы не превращать постановку в простыню на мой взгляд нужно учитывать такие моменты:

    • обязательно делать понятную структуру по разделам и сквозную иерархическую нумерацию;
    • если какие-то пункты шаблона не нужны при разработке, лучше исключать их;
    • лучше отбросить литературные таланты и писать максимально сухо, чтобы сразу была понятна суть, не стоит использовать сложные предложения и деепричастные обороты;
    • писать атомарные требования, 1 требование = 1 строка;
    • технические моменты иногда легче передать схемой, при необходимости использовать нотации;
    • можно выделять жирным шрифтом важные моменты, например названия атрибутов, функций.

    Если нет ресурсов приступить к параллельной разработке разными методами, как сократить риски пойти неверным путем и не получить результат как у вашей первой команды?

    Тут надо понимать риски. Если не подстраховаться, потери при негативном сценарии могут значительно превысить затраты на ресурсы для параллельной разработки. Если же нет возможности это сделать, то какие есть варианты:

    • одной командой сделать небольшие исследовательские проекты, на небольшом объеме или за небольшое время проверить оба метода;
    • изучить практику в сообществах, с помощью каких методов чаще решаются аналогичные задачи.
    • проконсультироваться с экспертами.
  • А смотрели в сторону BABOK, для формирования областей. аспектов, вопросов и инструментов?
    Да. Этот стандарт я тоже рекомендую использовать при составлении mindmap.
  • По неопределенности: пришла в команду, где нет аналитика. Сейчас нужно разобраться с документацией, все причесать, создать формат для ТЗ. А я сама с небольшим опытом. С чего начать?
    Если совсем нет никаких описанных ранее требований, можно собраться с лидами разработки и попросить их рассказать, что на их взгляд точно должно быть в постановке. Желательно чтобы было 2-3 специалиста — они смогут подискутировать и дополнить друг друга.
    Зафиксируйте их мнения. Желательно понять для чего нужен каждый пункт.
    Также посмотрите в каком формате требования вы получаете от заказчиков. Их структуру также можно попробовать перенести в ваш документ. Создать базовую версию, получить обратную связь от лидов.
    А дальше улучшать и актуализировать.
  • Какие конкретные требования, такие как сценарии использования (use case), вы считаете необходимыми для уточнения и доработки в процессе рефакторинга?
    Если речь идет о рефакторинге кода, то, как правило, функциональность при этом не меняется. Соответственно, функциональные и нефункциональные требования с точки зрения аналитика здесь не нужно прорабатывать. Там должны учитываться другие специфические требования, которые входят в зону ответственности разработчиков.
  • Какие существуют методы для снижения неопределенностей?
    Тут желательно понимать о какой неопределенности идет речь и на каком этапе работы она возникает.
    Если не хватает какой-то информации от заказчика, то есть методы для сбора информации, например анализ документации, интервью, фокус-группы, опросные листы.
    Если мы собрали информацию, но не уверены, что она достоверна, здесь могут помочь различные способы валидации. Например, рецензирование требований, обсуждение User Story, User Story Mapping, прототипов интерфейсов.
    Если не знаем какой способ реализации выбрать, то можно использовать бенчмаркинг, обсуждение с командой, анализ альтернатив, A/B тесты.
  • Как настраиваете трассировку чтобы преодолеть неопределенность?
    При написании постановки наряду с описанием функциональных и нефункциональных требований мы сразу описываем бизнес-требования и пользовательские требования в формате User Story. Связи между фичами реализуем с помощью инструментов ИСУП, в котором можно присвоить атрибуты родителя, связанной задачи, блокирующей задачи. Соответствие разработанного решения постановке проверяем с помощью тест-кейсов. Отдельной таблицы изменения требований не ведем, запросы на изменения фиксируем с помощью заведения новых тасков в ИСУП, привязывая их к корневой задаче.
  • В условиях неопределенности, коммуникация с заинтересованными стейкхолдерами проекта играет важную роль для обмена идеями, уточнения требований и получения обратной связи?
    Да. В этой ситуации хорошо, если заказчик понимает ситуацию и настроен лояльно. Тогда вы можете договариваться и устраивать сессии мозговых штурмов, проверять гипотезы, обсуждать допущения и риски.
  • Можно потом посмотреть где то презентацию? ГОСТы, прочие стандарты
    Ссылка на mindmap: https://miro.com/app/board/uXjVNEOGewU=/. Там вы можете найти список стандартов, которые можно использовать в качестве ориентиров.
  • Где находится граница разумности между управлением неопределённостями и собственно самим рабочим процессом аналитика?
    Граница субъективна. Для одного аналитика задача покажется нерешаемой, для другого решаемой. Просто потому что один сталкивался ранее с такой задачей и он уже знает, что нужно делать, какие инструменты можно использовать. Чем опытней специалист, тем больше у него насмотренность и больше инструментов.
  • Как понять, что принятое решение по задаче в условиях неопределенности не является псевдорешением?
    При наличии неопределенности вероятность того, что вы не попадете в цель будет всегда. Вопрос в том насколько она велика. Составьте список вопросов, на которые вы не можете ответить. Посмотрите какой риск может скрываться за каждым вопросом. Сложите все вместе и вы увидите общую картину бедствия.