Контекст в котором мы создаем by Kristina Erofeeva

Speaker Кристина Ерофеева
Title - Название доклада
Контекст в котором мы создаем
Annotation (no more 1000 letters) - Аннотация (не более 1000 символов)

Доклад раскрывает идею разделить общение в котором участвует аналитик на описание/обсуждение конкретных задач и на обсуждение части предметной области в которой задачи возникают.

В первой части я выделаю роль аналитика как посредника в общении внутри команды и команды с заказчиком. При разделении общения на общение (устное и письменное) по конкретным задачами и обсуждение контекста оно становится более эффективным и в разных ситуациях с которыми аналитик сталкивается в каждодневной работе имеет некоторые "бонусы".

Во второй части я рассказываю о тех "бонусах" с которыми я встречалась на практике при таком разделении общения.

В третьей части я рассказывваю о конкретных способах которые с тем или иным успехом были мной опробованы в работе и о сложностях при вовлечении себя и команды в предметную область. 

Description - Развернутые тезисы

Основная идея - разделить передачу информации о функциональности (как от заказчика к аналитику так и от аналитика к команде) и передачу информации о контексте (предметной области/процессе)

 
Проблема создания программного обеспечения это коммуникация, все друг друга не понимают, или понимают недостатоно эффективно, поэтому в большинстве случаев нужен аналитик как посредник в коммуникации, аналитик управляет информацией, получает ее, отдает команде, фиксирует.
Инфомацию участвующую в этом можно условно разделить на специфику реализации задачи (т.е. как именно и что именно должно быть сделано) и общие правила и описание среды в которой задача решается (описание бизнеса, глоссарий, формулы-алгоритмы-процессы, етс)
 
1) выгоды выделения этой деятельности 
- более изящная структура документации, более изящное изложение в документе
Этот раздел о том что иногда описание функциональности невольно включает контекст: формулы расчетов переменных при описании экранной формы на которой они должны появляться, описание стандартных цветовых индикаций являющихся отраслевым стандартом, описание стандартов среды, законодательных ограничений. 
В итоге документация "скачет" от контекста к функциональности и обратно. Если выделить контекст отдельно то можно сделать более простую документацию задач, при этом дополнительно выделить и при желании / необходимости документировать все сопуствующие объяснения в своей структуре, которая вполне может не сопадать со структурой задач проекта. (Пример: общая практика выделять глоссарий но редко кто идет дальше и также выделяет общее описание предметной области етс) 
 
- более предсказуемая эффективность аналитика / команды
Если в проект формируется новая команда или наплыв новичков то даже при том что итоговая производительность команды не изменится (например, уходят сотрудники) то аналитик испытывает сложный период т.к. возрастают усилия на формирование понимания контектста у новичков.
Особенно сложно если в команду добавляются аналитики 
Так же ожидаема более тяжелая работа над небольшой дополнительной функциональностью, но лежащей за границами "освоенного" контекста. (например, если на стоковый проект добавить форекс функциональности то аналистам и команде надо некоторое время "освоить" новый контекст и эффективность может упасть хоть предметная область и похожа) 
Напротив, бывают периоды когда команда полностью загруженна разворачиванием среды, задачами по исправлению критичных ошибок перед запуском системы или ее очередного этапа, техническими задачами по обеспечению безопасности, производительности. В такие периоды аналитик может создать "задел" на периоды повышенной занятости и качество документации и поддержки разработки будет более предсказуемым и стабильным. 
 
- проблема "затянутых" совещаний. 
Нередко возникают ситуации когда планирование задач, обсуждение взаимодействий проектных команд по нескольким смежным проектам, регулярные скрам-совещания превращаются в обсуждение функциональности. В некоторых случаях можно исправить такую ситуацию запланировав предварительно обсуждение или лекцию о том, в каком процессе функциональность будет запланирована. Если это совещание нескольких команд, аналитик каждой может ввести свою команду в контекст работы другой команды, какую функциональность это затрагивает, как эти части функциональности взаимодействуют друг с другом. В таком случае даже если собственно время не будет сэкономлено, каждое из совещаний будет более цельным и не демотивировать сотрудников которые "все это уже слышали", также очень важно делать такие вводные совещания или лекции перед теми совещаниями на которые приглашаются труднодоступные представители заказчика чтобы не терять их время. 
 
2) управление уровнем погружения в предмет
аналитик принимает решение насколько ему надо быть "в теме" и насколько "в теме" должна быть команда
в каждом из случаев "чем больше тем лучше", то есть чем лучше аналитик и команда разбираются в контексте тем меньше риск недопонимания, но необходимо взвешено принимать решение о трудозатратах на освоение предмета
 
- проект/продукт (продуктовый аналитик, в отсутствии эксперта на стороне заказчика должен быть более погружен в предмет) и в целом наличие и доступность экспертов на стороне заказчика, чем меньше экспертизы от заказчика тем лучше должен разбираться в предмете аналитик
- специфика предметной области (легкость ее освоения) легкую можно бы и изучить со всех сторон, вреда не будет сплошная польза, в сложной когда ощутимые затраты на освоение, то уровень ограничивается потребностью/здравым смыслом 
- интерес/желание освоения предмета 
- вероятность применить знания в дальшейшей работе/карьере
- "творческое" применение знаний обывателя
говорить о том что бывает некоторый уровень который уже нельзя назвать некомпетентностью и он опасен ощущением экспертизы, и аналитик или член команды который обладает начальным но неполным знанием в области может трактовать "недопонимание" с точки зрения своей экспертизы, когда наиболее уместным будет уточнить и разъяснить эту часть предмета у эксперта либо внутри либо на стороне заказчика. идеально когда члены команды либо не достигают уровня компетенции (и поэтому спрашивают вопросы при затруднениях с контекстом) либо уже находятся на стадии когда их понимание предмета действительно соответствует достаточному уровню для принятия "творческих" решений. 

3) формы передачи контекста
- вводная лекция на проект / обучающий курс для молодых сотрудников в компании
объем материала в зависимости от потребности / располагаемых ресурсов 
- все входящие вопросы и уточнения делятся на а) действительно уточнения фукнциональности б) вопросы уточнения процесса/контекста, второго типа вопросы не должны приводить к объяснению как это должно быть сделано в этой части фукнциональности, а желательно приводить к объяснению этой части контекста, причем возможно не только человеку который задал вопрос но и всей команде
- документирование контекста 
а) глоссарий
б) формулы/алгоритмы расчета 
в) текстовое описание предметной области
г) ссылки на чтиво разной степени глубины по предметной области
Type of Presentation - Тип доклада
  • Regular Talk - Секционный доклад (40 min)
Level of audience - Уровень аудитории
Last Updated 19 Apr 13:03