2016-03-29: о прошлогодней AnalystDays-2015

(Из ленты MaksWiki — Блог:Максима Цепкова [ru])

Готовясь к новому Analyst Days обнаружил, что отчет с прошлой AnalystDays-2015 в Минске я до сих пор не опубликовал, хотя заготовку написал еще на самой конференции. Исправляюсь.

А на конференции этого года в Питере я выступаю с интересным докладом Коммуникация при различной структуре мышления — таксономия против фолксономии про способы мышления. Начало его экспромтом возникло на WIAD-2016 и будет развернуто, а развитие будет неожиданным. Приходите!

А теперь — написанное почти год назад.

Конференция 2015 года порадовала меня высоким уровнем докладов и активным общением в кулуарах. Конференция аналитиков отличается очень сильным составом постоянных участников, с которыми интересно общаться. На конференции они в значительной мере вырываются из операционного контекста и открыты для общения на самые разные темы. И этим ценно участие в конференциях. А доклады — можно посмотреть в записи. Но на конференции, слушая доклад — ты тоже вырван из операционного контекста и можешь лучше сосредоточиться на содержании доклада. А если доклад тебя зацепил — можно еще пообщаться с докладчиком. Так что — приезжайте на конференции!

Дальше краткий обзор интересных мне докладов.

Сергей Кадомский. Wargaming. Использование практик бизнес-анализа в проектах big data и data science

Очень крутой и неожиданный доклад про Research and Development подразделение в Wargaming, самый интересный для меня на конференции. Они занимаются вовсе не разработкой игр в привычном понимании. Их предмет — анализ человеческого поведения, от принятия решений в игре и маркетинговых идей до социальных последствий увлечения игрой, включая анализ текстов на форумах. У них работают социологи, психологи.

Они анализируют как игры влияют на семьи. Сообщество «жены против танков» — есть, но есть и письма: мой раньше выпивал, а теперь — играет в танки, дома, хорошо. Они сотрудничают с институтом социологии Белорусским, и там много исследований. А еще для игры -им важно знать, почему он ушел, надоело или ужинать, или к детям. Мобильное приложение — чтобы показать статистику друзьям. А еще — lifestyle, новости по второй мировой — и это все требует исследований, отношения к танкам и второй мировой. И они всем этим занимаются.

Содержательные задачи были фоном и примерами, а основной рассказ был о налаживании коммуникаций между разработчиками-аналитиками и теми, кто ставит им задачи. Их 12 человек, основной персонал — кандидаты наук, математика и физика, сложная алгоритмика. Но при этом — не понимают бизнес. И, более того, им часто не рассказывают эту бизнес-задачу, а сразу дают техническую, которую они начинают решать. При этом, в силу специфики, не получается построить промежуточный слой общения в виде аналитиков, потому что для предложения приемлемых вариантов решения надо понимать технику — анализ на данных порядка 100Т за разумное время получается далеко не всегда. А есть кейсы, когда от них требуется выдать алгоритмы, способные проводить анализ в ходе игры, чтобы подстраивать под игрока окружение.

И в обратную сторону тоже надо строить коммуникацию, особенно если результаты анализа оказываются неожиданными для бизнеса: он ожидал получить подтверждение своих гипотез и уточнить параметры, а анализ выявил, что сама гипотеза неверна. Как объяснить заказчику, что ошибается он, а анализ проведен корректно и не содержит ошибок? Про непредсказуемость результата нужны коммуникации с самого начала. Потому что люди часто не понимают ограниченность научных методов, требования к статистической надежности данных и т.п. Вообще подтверждение гипотез бизнеса — не несет Заказчику большой ценности. А вот конфликтующее — означает, что есть новая информация, с помощью которой можно улучшить бизнес. Ранее вы об этом думали неверно. Но это надо уметь донести до Заказчика.

В общем, успех аналитического проекта — лежит в плоскости коммуникаций. И надо учить scientist коммуникациям и управлению ожиданиями.

А еще — требуется быстро погрузиться в особенности хранения данных конкретного приложения, понять, где лежит нужная информация. У них и разработчики игр (танков, кораблей), и маркетинг — оценка потенциальных предложений, и платежники. Чтобы разобраться, они ведут по системам глоссарий бизнес-определений и словари данных.

Проблема завышенных ожиданий

• Фиксация vision & scope перед стартом проекта
• Формализация бизнес-целей. Что заказчик будет делать с результатами анализа в бизнесе, гипотезы вариантов — в зависимости от этого требования к результату могут сильно меняться.
• Фиксация гипотез с вовлечением экспертов
• Цена ошибки. Поиск фродовых платежей — а что с этим будут делать, какова цена определения истинного как фрода.

Работа с нефункциональными требованиями

• Скорость работы моделей — если отклик от модели нужен за 20 минут, а не разово — нужны другие алгоритмы.
• Качество моделирование
• Reusability: это ad-hoc или будем внедрять?

А еще бывают white-box и black-box подходы. Black-box может дать более высокое качество, но объяснить получение результата — нельзя. И это — ограничение на применение метода, если объяснение требуется.

Максим Цепков. CUSTIS. Разделение ответственности в заказной разработке

Продолжу рассказом про свой доклад. Я рассказывал про разделение ответственности в заказной разработке. Основная идея мысль в том, что не существует какого-то идеального, правильного процесса разработки и разделения ролей, которым мы жертвуем, потому что идеал не достижим, адаптируя его к конкретным условиям. Наоборот, разделение ролей правильно строить каждый раз заново, с учетом контекста этого проекта — доли и сложности аналитической работы и разработки, устоявшихся процессов заказчика, на которые мы, однако, можем влиять, компетенций имеющихся сотрудников, из которых мы формируем команду проекта.

Но при этом строить заново для проекта, безусловно, не означает разработки с нуля. Здесь как с разработкой кода — уместно использовать шаблоны и готовые схемы, но помнить о границах применения, а применять всегда единственный шаблон, да еще спорить о том, каков правильный — глупо. А само проектирование процесса стоит делать технологично, так, как принято делать проектирование в ИТ — на подходящей диаграмме.

В докладе я предлагал инструмент для такого проектирования — разделение ролей на V-диаграмме, и приводил различные примеры и варианты из опыта разных проектов собственной компании. Потому речь шла преимущественно о заказной разработке — мой практический опыт в ней. Хотя само проектирование на V-диаграмме применимо и к продуктовой разработке тоже. С помощью этих инструментов процесс проектируется достаточно эффективно. Вместо V-диаграммы можно использовать представление процесса как движения альф по гейтам-состояниям, принятое в OMG Essence. Но это — более сложный, хотя и мощный фреймворк, и Вам решать — будете ли Вы его использовать, или обойдетесь более простой V-диаграммой. Или вообще сочтете, что ваши проекты настолько одинаковы, что проектировать тут нечего.

Вообще может показаться, что разница — невелика: проектируем мы каждый раз процесс заново или адаптируем некоторый имеющийся у нас идеальный процесс. На самом деле разница — принципиальна, это — разная конструкция ценностей. В одном случае идеальный процесс есть, а в другом — его нет, есть ситуативная сборка. Это такое же крушение идеалов, как и разочарование некоторых разработчиков в том, что нет идеального фреймворка для разработки или идеального языка программирования. Но осознание отсутствие идеала в средствах разработки многие прошли, а некоторые и не заблуждались на этот счет, а вот в идеальный процесс, по моему опыту обсуждений, многие верят. И свидетельство этому — частое практическое превращение Scrum в догматично устроенный процесс и боль от того, что «у нас scrum не идеален» без всякого упоминания о контексте.

Дмитрий Безуглый. ООО «Системный Подход». Бизнес аналитик — решение проблем и внедрение изменений

Мне слушать Диму — всегда интересно. У него сложные доклады высокого уровня, которые несут концептуальные представления. И они заставляют задуматься, сопрячь высказанное со своей картиной мира, они меняют ее. В чем и есть ценность докладов.

Основная мысль доклада — меняется позиция ИТ относительно бизнеса. Из обслуживающей позиции, получающей задания, спецификации и их выполняющие — в проактивную позицию помощника-партнера бизнеса. Который понимает идеи бизнеса, подсказывает бизнесу возможности развития. Собственно, на эту тему — про явный тренд перехода ИТ в партнерскую позицию — я слышал доклады на европейских конференциях, и это — объективный тренд, в том смысле, что это не проявление идеи «давайте жить дружно и равноправно», а обусловлено все возрастающим влиянием ИТ на успех бизнеса, возможности которого зависят напрямую от ИТ. И я с ней — совершенно согласен.

И из этого вытекает изменение позиции бизнес-аналитика, который должен обеспечивать такую партнерскую позицию, реально понимая идеи бизнеса. При этом в традиционном ареале он не столь нужен, его обязанности занимают руководители проекта и системные аналитики. А вот позиции фасилитатора, в том числе в работе со стейкхолдерами со стороны бизнеса и в предметной бизнес-области — становятся сильно востребованы. И в результате происходит ребрендинг, от бизнес-аналитика — к бизнес-архитектору. И переход (на Западе) от термина Enterprise architecture, который свойственен бизнесу, к Business architecture, чему свидетельство появление BIZBOK — Business Architecture Body of Knowledge.

Но в партнерстве с бизнесом есть вопрос воплощения ИТ-разработке. Помимо амбиций на партнерскую позицию надо еще уметь практически ее воплощать. Что означает работу в долгую, работу с архитектурой приложений и ИТ-ландшафта в целом. Умение строить гибкие приложения. Но при этом бизнес еще и ожидает от ИТ быстрого выполнения его запросов. А с этим в традиционной разработке имеются большие проблемы. В большинстве организаций бизнес глухо ненавидит ИТ за то, что выполняется в лучшем случае десятая часть запросов, при этом не самых важных, а самых простых. Это пытаются решить, внедряя agile-подходы в разных видах, и часто разрушая при этом долговременную архитектурную работу в пользу краткосрочных эффектов быстрого исполнения требований. Возникает отложенный отрицательный эффект, архитектурный долг, с которым, а отличие от технического, еще не научились работать.

И вот здесь я сильно не согласен с Димой. Во-первых, потому что видел те же проблемы, на которые он ссылается как результат внедрения agile, и при традиционных подходах. Просто определенные архитектурные аспекты не считаются важными, упускаются, что и приводит к таким последствиям. С другой стороны, я знаю и видел примеры успешного использования agile-процессов, в том числе в inhouse-разработке. Которые обеспечивают прозрачность прохождения проектов и выполнение именно приоритетных требований, а архитектурная работа — сохраняется. Так что я думаю, как обычно, что вопрос не в подходах, а в мозгах.

Игорь Беспальчук. CUSTIS. Цель и ответственность в деятельностных системах

Очень хороший доклад-размышление про цели и ответственность. Про то, что есть целеустремленного движения. И как бы сделать так, чтобы его практическим результатом не становились объяснения о том, почему цель не была достигнута. И чем оно отличается от позиции «сижу и жду, пока проплывет труп врага». Так — тоже можно, но это — другой подход к жизни и редко приводит к результативным результатам в разработке софта. Конечно, софт зарождается сам где-то там в мире, но это — не твой софт.

По месту — он дополняет доклад Димы, говоря про задачи БА. В контексте деятельности — правой половины интегральной карты из него, того, что объективно — а не субъективно.

А по сути я пересказывать не буду, потому что доклад, с моей точки зрения, нацелен на размышления, на включение мозга. У Игоря, кстати, большинство именно таких докладов. Так что если целеустремленное движение интересует — надо смотреть и думать, а не читать краткое содержание. Оно, кстати, важно не всем. Scrum, например, нацелен на целеустремленную команду, идущую к цели проекта, а Kanban — построен на оптимизации процессов, целеустремленность всех — не требуется. И нормально работает.

Антон Семенченко. DPI Solutions, ISSoft / CoherentSolutions. Преподавание концептуальных основ ООП как простой способ повышения производительности Бизнес и Системного Аналитика

90% даже разработчиков не понимают концептуальных основ ООП. И НЕ понимают «зачем». Знают только практические основы. И через 10 лет приходит какое-то просветление. Этот путь надо сократить всячески. Поэтому они читают тренинг. И мидл-разработчикам и начинающим бизнес-аналитикам.

Как читать курс разнородной аудитории? У них общее — школьное образование. И надо основываться на этой базе, при чем на том, что еще не забыли. Тренинг небольшой, 3-5 академических часа. Объясняют, начиная от основ через метафоры. Например, объясняют работу архитектора как работу с моделями. Правда, надо объяснить еще что есть модель — и тут на помощь приходит школьное образование: планетарная модель, таблица Менделеева, устройство молекулы — это все модели, и в школе рассказывают их эволюцию, это и получается объяснение работы архитектора.

Тренинг читают senior специалисты, остальные знают Как, а не Почему. Архитектор с серьезным опытом, среднего уровня, не low-level dev. Но не слишком high — иначе они витают в концепциях. И надо, чтобы хотел и мог — потому что коммуникативные навыки. Такие люди обычно заняты, и проблема ресурсов — непустая.

ООП — способ борьбы со сложностью в ИТ.

• Техническая сложность (производительность, гибкость ПО).
• Предметная сложность — домен. Сложность описания поведения дискретных систем (не-гладкие функции).
• Социальная сложность, взаимодействие между людьми
• Управление, менеджмент.
• Ресурсы.

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

• Инкапсуляция. Говорят, что это сокрытие — для простоты. А если так не проще? То зачем она.
  • «Была одна строчка, теперь 9 — стало проще». Нифига! Проще не стало. «Мы все скрыли» — нет не скрыли. Как с зарплатой. А реально инкапсуляция скрывает детали при развитии, усложенении кейса.
  • Итого — инкапсуляция — это борьба с изменчивостью, а не со сложностью. Борьба с изменчивостью — всегда за счет увеличения сложности. А вот дальше, поскольку две стороны — идет поиск баланса.
• Рефакторинг «extract method». Вынесли 5 строчек в метод. Метод — он чтобы дал понимание. Если правильное название, и дали бизнес-смысл. А вот если одна строчка -выделять?
• Принцип don’t repeat yourself — это тоже инкапсуляция. Хотя это — не имеет отношения к разработке.
• Полиморфизм — тоже частный способ инкапсуляции.

Юлия Ерина. i-Sys. BDSM для аналитика или разговоры о садистах, выгорании и проектах, от которых лучше сразу отказываться

Рассказ о том, что в конфликтной позиции мы-они на проекте мы вовсе не всегда оказываемся сильнее, чем они. И победа любой ценой — ложный вызов, разумнее уйти с такого проекта и сберечь себя. Потому что проекты еще будут, а ты — один. Но это — мое резюме доклада, а не цитата автора.

И с моей точки зрения, в доклад с самого начала заложена излишне конфликтная позиция коммуникации, проводимой во враждебном окружении. И «они» в контексте доклада — это не только заказчики, это часто еще и руководство, которое манипулирует аналитиком. И лично я бы в этой ситуации подумал бы об уместности пребывания в Компании, где руководство склонно к таким действиям, а не просто выбирал приемлемые проекты. «Подумал» здесь не значит «однозначно ушел», но это должно быть внутри размышлений, а здесь — вынесено за рамки доклада. Возможно, из-за внутренней убежденности, что руководство всегда такое и так себя ведет. А вот это — не так, это признак старой компании эпохи великих свершений, сменившейся эпохой манипулирования. Но сейчас уже достаточно много компаний с другой внутренней атмосферой, нацеленных на сотрудничество со своими сотрудниками и их самореализацию. Надо просто искать и выбирать.

Тем не менее, обстоятельства жизни бывают разные, и если вы выбрали работать в некомфортной компании или проекте, то из доклада можно почерпнуть много полезного про построение коммуникации в таких условиях, про ведение работы так, чтобы не выгореть на работе, а сохранить силы для будущего. Здесь распространенная ошибка — быть хорошим для всех. Так не бывает, надо находить баланс.А то, что нас не убивает — делает нас сильнее, и это тоже правда.

Манипулирующее взаимодействие с аналитиком

• Нога в двери. Определенный скоуп — не забюджетирован, заказчик забыл. Но скоуп — нужен, его проталкивают. «Давайте поговорим о … Ну просто поговорим, чтобы не забыть… Ну давайте в протокол, ну, давайте кусочек в ТЗ»: ноготок увяз — всей птичке пропасть.
• Агрессия. Прилетает, когда первый вариант не срабатывает. Агрессия — обычно не негатив, плохое отношение. Хотя да, бывает плохое настроение просто. Но гораздо опаснее, когда у человека просто рабочий инструмент.
• Сомнения. А он хороший аналитик, а он компетентный? Человек работает на износ, чтобы доказать.
• Сарказм и троллинг. Со стороны коллег, и особенно от Заказчика. Разрушает самооценку полностью.
• Шантаж и угрозы. Очень редко, но встречалась. На пресейлах «Сбросьте цену, а то не будем работать.»
• Яркие проявления любви. Когда Заказчик любит, принимает и невероятно доверяет. Когда по-дружески через любовь проталкивают.

Противоядия.

• Надо создать физические границы, чтобы они чувствовались. Всегда изучает границы проекта, договор и прочее.
• Оценивайте риски. Что проиграете в худшем случае, что — в лучшем. Что приобретете.
• Максимально сводить к конструктиву и диалогу.
• Осмысливайте уступки. Не делайте уступки с самого начала. Уступки часто не налаживают отношения, а прикармливают волков. История на севере — отбивались от волков кидая мясо — научили просто бегать за санями.
• Не жалуйтесь — договаривайтесь. Жалобы бессмысленны.
• Эскалируйте. Когда требуют принять решение немедленно — откладывать.
• Молчание — начало из начал. Ставить отсрочку на письмах, чтобы откатить эмоцию.

7 признаков выжигающего проекта

• Безнадежность проекта по классификации Йордана (сроки-ресурсы в 2 раза меньше)
• Векторы мотивации компании и конкретных стейкхолдеров имеют противоположную направленность
• Восторженно-завышенные ожидания от проекта у любой из сторон. Корректировать на входе.
• Увиливание от конечного «Да» при согласовании требований. Всех устраивает, но не подписывают.
• Попытки влияния на аналитика в обход руководителя проекта. Она в такие ситуации попадала
• Туманные требования
• Неявные обещания.

Здесь, с моей точки зрения, хорошее начало, а вот продолжение — не слишком операбельно, похоже на расплывчатые квалификации-жалобы.

Конкретный кейс. Заказчик пару лет назад посередине проекта понял, что они сами не справляются — и поменял руководителя проекта посередине на аутсорс. Их цель — сдать проект к сроку. А новый руководитель был заинтересован затянуть проект, потому что для него руководство проектом — определенное положение — и начал это делать. Ситуация изменилась, когда уговорили Заказчика, что таких людей надо по-другому мотивировать. И он назначил ему финальную компенсацию по сдаче проекта. Проект — полетел.

Статья про концлагеря — как превратить людей в биомассу.

• Вы занимаетесь бессмысленной работой. Выкапывать и закапывать одну яму
• Вы несете коллективную ответственность за сдачу или несдачу проекта. Люди подсиживают, сдают друг друга.
• Вы начинаете верить, что от вас ничего не зависит.
• Вы делаете вид, что ничего не замечаете.
• Вы не можете себя контролировать. Возникают неконтролируемые эмоции.
• Вы играете по правилам, которые вам неизвестны. Она с этим сталкивалась в одной американской компании — по отношению к молодым.

Многие из этих техник — применяют. И надо их знать и опознавать, как и другие техники манипулирования. И дальше — делать выводы.

Вадим Мустяца. Itransition. NoBA: Кончайте требовать и начинайте со-трудничать

Вадим — интересный человек, он все время пробует новое, развивается, и зажигательно рассказывает об этом. И этот доклад — о том, как рождаются волонтерские проекты, взгляд изнутри. Это интересно и замечательно. Движение к живым пользователям. От манифестов.

А название — аллюзия к NoSQL: Я не любил SQL, я сделал NoSQL, но потом добавил SQL так что им тоже стало можно пользоваться. Так и здесь NoBA — не значит, что бизнес-анализа нет совсем. Он есть, но есть не только он. А роль аналитика Вадим видит как батарейку проекта.

Но батарейке нужны инструменты — Тулы stories on board design и прочее. И он делает все это — как волонтерский проект в личное время! Он хочет понять, что им светит дальше. Хотелось бы солнышко… Замутили репозиторий, вики. И он зовет со-участвовать.

К этому в конце был вопрос «а зачем, из прикола что ли». Вадим ответил из позиции евангелиста, который продвигает новое. И дальше уже вопрос вашего выбора: хотите вв этом участвовать или нет. Быть евангелистом — не обязательно. Но наполняет жизнь смыслом.

Ольга Павлова. «Собака Павлова». Сколько стоит идея шефа, или инвестиционный подход для менеджеров

Как всегда у Ольги, энергичный доклад с кучей полезной информации. Как всегда, приличная доля позиции «я — д’Артаньян», которая мне лично не нравится. Зато, при должной рефлексии, ты можешь извлечь из доклада даже больше. чем при обычной нейтральной позицией, формулируя для себя, что тебе кажется правильным, а против чего ты возражаешь и почему. И возражательные части — тоже полезны, потому что часто заставляют прояснить себе то, о чем не думал.

Андрей Колесников. ООО «Иншуранс Солюшенс». Особенности работы с требованиями при доработке продукта для заказчика

Рассказ о конкретном подходе к архитектуре адаптивного к изменениям продукта, который они применяют.

• Для каждого пользователя нужна настройка пользовательского интерфейса
• Для каждой сущности нужна настройка жизненного цикла
• Настройка структур данных — появление и скрытие полей
• Привязка полей к подтипам, например, управляемая типом продукта для страховщиков.

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

• Конфигурация. Доступна всем пользователям
• Параметризация. Через специальную таблицу или конфигурационные файлы
• Доработка самого ПО. Стараются избегать.

В целом — понятно. И нужно не только при продуктовой разработке, в случае заказной такой подход позволяет хорошо реагировать на изменения бизнес-процессов заказчика. И при начальной разработке с такой ориентацией — не слишком дорого, хотя многие разработчики, особенно проникнутые ООП уверены в обратном.

Игорь Ямшанов. Telesens. Его величество «Документ»

Неплохой доклад для для начинающих, которым приходится самим создавать процесс работы с документами. Такая стартовая инструкция, ToDo, с которой можно стартовать. А потом уже дорабатывать и адаптировать самим. Да, при этом придется почему фрейм именно такой — в докладе этого нет. Но тут литература и опыт в помощь, а за 40 минут всего этого не расскажешь.

Ирина Гертовская. ОТР-2000. Управление функциональными и интерфейсными требованиями в смежных системах

Довольно подробный рассказ о процессах разработки и поддержки большой системы для Федерального казначейства. Много процессных диаграмм, рассказ о налаживании взаимодействия с заказчиком. Из неожиданного — они используют собственную разработку для ведения требований, при этом рассматривали РеквизитПро и Doors — те не понравились.

Валентина Крупадерова. ГК «СКАУТ». Кастомизация продукта: не так страшен черт

Доклад — история развития подходов к кастомизации у них в продукте — ПО мониторинга транспорта.

В замысле кастомизация — как Лего, для Заказчика и для развития продукта.

Когда появляется кастомизация продукта? Когда второй клиент. Замечательно, но немного настроек. Потом — следующий. В результате продукт, где учтены все фичи, в том числе и противоречивые. Продукт становится тяжелым, и допиливать его сложно. Такая кастомизация — не Лего, а карточный домик.

Быстро и дешево — первое время. А потом — надо выкинуть. И написать с нуля. И это — тяжелое решение.

Первая попытка была все доработки пустить по полному циклу, с анализом! В принципе — хорошо, только долго. В докладе — очень сложная схема. И это уже не Лего, а вышивание крестиком. Новый релиз со всеми фичами — очень долго ждать.

И они решили делать по-другому — через интеграцию по API. Выдали API — и кастомный блок будет. Но вот первый раз сделать API — дорого. Спроектировать, что туда нужно вынести. И понять, что продукт работоспособен. Зато через API можно подключить другие системы, использовать стандартный функционал, а не делать оригинальное.

Следующий этап — Plugins API. C защищенным ядром. Разработчики это любят. И это помогает учить новых разработчиков — они начинают с плагинов. А еще возможность сделать плагины — позволяет быстро сделать кастомизацию, которую можно будет передать другим заказчикам. Способ получения идей для развития. Только вот для этого нужен стабильные продукт, а на начальную конструкцию — приличные вложения,минимум двухкратные.

Екатерина Литвинова. Материалайз. От проектов на заказ к конфигурируемому продукту: работа над ошибками

Это история рефакторинга от настроек, размазанных по коду, к общей платформе и кастомной логике с кастомизацией и конфигурациями. В результате они пришли к конфигурированию в Excel, из которого xml идет как конфигурация разработчикам, и идет трассировка тестировщикам. Но путь оказался непростым и для разработчиком и для аналитиков и для тестировщиков. И о подводных камнях и особенностях был рассказ.

Юрий Куприянов. WikiVote. Анализ требований с точки зрения UX

Специализация привела к тому, что есть два слабо пересекающихся мира:

• аналитики, проектирующие системы
• и проектировщики интерфейсов (UX)

Что эти миры не пересекаются — он знает из тренингов, которые ведет, и статистика амазона тоже говорит, что они не читают литературу друг для друга.

В теории на проекте должны присутствовать обе специализации, это разделение труда. На практике есть только одна, какая — зависит от специфики проекта и традиций компании. Из-за такой однобокости возникают типовые ошибки, и в докладе был их разбор.

Источник: 2016-03-29: о прошлогодней AnalystDays-2015