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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[ Хронологический вид ]Комментарии