2016-04-25: AnalystDays-2016 в Петербурге - много мыслей и позитива

Материал из MaksWiki
Перейти к: навигация, поиск
Короткая ссылка: AnalystDays-2016
О других конференциях

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

Отмечу, что в эти числа параллельно шло пять конференций: AnalystDays и ProfsoUX в Петербурге, Jpoint в Москве, SECON в Пензе и Стачка в Ульяновске. И была реальная проблема выбора конференции, потому что все они - известные и качественные. Не все жители столиц знают, что в регионах уже несколько лет делают очень хорошие конференции, потому что есть потребность развивать разработчиков, и конференция с приглашением хороших спикеров - хороший инструмент. Правда, аналитических секций и других подобных специализаций там практически нет, так что для аналитиков есть AnalystDays, ProfsoUX и ЛАФ, который в этом году будет 18—19.06. Только на IT Global Meetup Piter United очень репрезентативно представлены не только разработчики, но и смежные soft-skill сообщества.

Фото Григория Печенкина

Но вернемся к AnalystDays. Лично я не смог оценить ее доклады в полной мере, потому что после своего выступления в первый день начал активно общаться с Димой Безуглым, который проверял и дорабатывал конструкцию своего доклада для второго дня. Обсуждение было публичным, собрало много зрителей у флипчарта и отмечено Александром Ставровским на facebook. В общем-то, я не предполагал что это затянется до вечернего мастер-класса Димы, но так произошло. И на следующий день после его утреннего доклада, в котором приятно было услышать благодарность за свой вклад в обсуждении накануне, обсуждение продолжилось, потому что появились новые мысли.

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

Елены Волченко. Прогнозная модель расчета LTV клиентов на примере игрового проекта Небеса

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

Мой доклад

Фото Дмитрия Безуглого

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

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

Мой доклад доступен в статье Коммуникация при различной структуре мышления - таксономия против фолксономии (Максим Цепков на AnalystDays-2016), и, я постараюсь в ближайшее время добавить к презентации тезисное изложение, а после появления видео - добавлю ссылку.

Мастер-класс Димы Безуглого. Работа с лестницей потребностей.

Фото Александра Ставровского

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

  • Business Model Canvas Александра Остервальдера. Я его видел довольно давно, и его разделы в целом мне понятны. Однако, Дима рассказал не только внутреннюю логику построения, но практическую значимость именно такой структуризации. Александр Остервальдер проанализировал в книге современные бизнесы, разложив по этой кнаве, дал их классификацию. И показал, что такие элементы, как взаимоотношения с клиентами для ряда бизнесов являются ключевыми, без них успех бизнеса и сущность инновации объяснить нельзя. И я понял, почему эту область знаний мне надо будет осваивать. Книга не переведена, для быстрого знакомства быстро нашел краткий конспект и еще немного материалов, буду смотреть. Потом, наверное, возьмусь за книгу.
  • Для потребителей надо проводить четыре вида сегментации, которые существенно не совпадают друг с другом, потому что имеют разные основания. Очень часто излагают только один из них. вот они.
    • Сегментация потребителей по последовательности захвата рынка - стратегия продвижения продукта.
    • Сегментация по начальному привлечению потребителя. Именно в ее терминах работают социальные сети при привлечении трафика и маркетинг в целом.
    • Сегментация по ведению потребителя внутри продукта, постепенного разворачивания удовлетворения его потребностей от начального знакомства до продвинутого уровня использования сучетом лестницы потребностей J-S-P (далее).
    • Сегментация по способам работы, UX.
  • Мотивация потребителя и ценность продукта рассматривается на трех уровнях: Job, Social и Personal, и против каждого ставить свои способы удовлетворения в виде Function, Gain и Pain. Это используется при сегментации захвата рынка и ведении потребителей.
    • Здесь Дима бегло рассказал несколько примеров. Какой-то из online-покеров использует 27 психологических портретов игрока и для каждого из них использует свою стратегию удержания в игре, чтобы пользователь играл, проигрывал, но получал от игры этого удовольствие и не остановился, но и не подсел чрезмерно.
    • И был немного рассмотрен кейс Uber - не только для пассажиров, но и для водителей и показано несколько нетривиальных ценностей, которые Uber выявил и запроектировал.

Agile (гибкая) стратегия, бизнес и системный анализ. Дмитрий Безуглый

Основные мысли доклада, как я их услышал. Я с ними в целом согласен.

  1. Антихрупкость в сложном мире
    1. Нынешние системы являются большими, сложными и многоуровневыми инженерными решениями И необходимо жестко поддерживать, овеществлять границы элементов системы для того, чтобы изменение элементов системы проходило безопасно.
    2. Для позиционирования своей системы и ситуации в сложном мире стоит использовать Cynefin framework chaos - complex - complicated - simple.
    3. Исследовательские эксперименты уместны в области наступления на хаос, превращения его в complex, или в области simple, где последствия просчитываются, неуместны в области complex, и особенно complicated, если нет надлежащего контроля границ.
    4. Очень часто simple снаружи обеспечивается невидимым complicated внутри. И лица, принимающие решения, не учитывают этой сложности, разрешая эксперименты или оптимизацию.
    5. Еще один фреймворк, который помогает разбираться с неопределенностью - концепт VUCA-мира:
      • Volatility (быстрые изменения мира) - ответом является Vision своего места
      • Complexity (в мире больше факторов, требующих учета при принятии решений) - ответом является Understanding, модель мира
      • Ambiguity (неоднозначность последствий решений) - ответом является Clarity, ясность действий и планов
      • Uncertanly (неопределенность настоящего) - ответом является определенность движения к выбранной цели с помощью гибкости, Agility
    6. Негативные последствия изменений, в отличие от позитивных, часто проявляются отложенно. И это способствует опасным изменениям. Дима тут приводил пример отмены антиобледенительной обработки самолетов. Реально она необходима только во вполне определенных условиях взлета самолета, однако наличие или отсутствие таких условий уверенно предсказать невозможно. А вот задержки взлета из-за такой обработки вполне понятны, поэтому ее отмена точно даст позитивный эффект. Только вот самолеты начнут иногда падать.
    7. Нынешние ситуации внедрения Agile часто ограничиваются изменением управления работамми, которое способствует принятию неоправданных решений об изменениях и, более того, может стимулировать их, например, практикой активного рефакторинга. А инженерные практики, делающие изменения безопасными, например, автотесты интерфейсов на границах подсистем, внедряются сильно реже. Потому переход на Agile приводит к увеличению хрупкости с отложенными последствиями. У меня тут несколько другая картина, но об этом дальше отдельно.
  2. Целенаправленное движение
    1. Agile-методы в том поверхностном варианте, который часто продвигается, нацелены на быстрое перемалывание задач, то есть повышение скорости движения.
    2. Движение должно быть не только быстрым, но и целенаправленным, иначе оно становится беспорядочной реакцией на внешние стимулы.
    3. Для целенаправленного движения должно быть стратегирование. И оно тоже должно быть гибким (Agility): сейчас нельзя принимать стратегию на 5 лет и ее выполнять. Необходимо пересматривать стратегию раз в полгода, сохраняя при этом горизонт стратегии в 3-5 лет. Так делают успешные компании.
    4. При принятии стратегии нельзя ограничиваться внутренним движением своего продукта. Надо смотреть вокруг, в широкой рамке на тренды окружающего мира, на работу конкурентов. Казалось бы, очевидно. Но, говорят, выработка стратегии производится такими людьми и в таких формах, которые этого не обеспечивают, участники не имеют такого видения, их горизонт ограничен компанией.
  3. Виды стратегий для крупных.
    1. Лидер рынка. Researcher
    2. Второй крупный - Analyser. MS-стратегия. Сделать вторым, но сделать лучше. Мониторинг + мощности Dev как Enabler
  4. Источники и материалы по стратегиям
    1. Хороший слайд про темпоральную войну.
    2. Книги. Bob Johansen - Get There Early.
    3. Цикл Forsight - Insight (decision) - Action.
    4. Business Architecture Framework.
    5. Ярополк Раш. Военная психология.
    6. Archimate помогает осознавать, что есть в организации.
  5. Отдельная интересная тема в ответах на вопросы - перспективы специализации аналитика при отделении сейчас новых профессий
    1. Список профессий
      • Business Analyst
      • System Analyst
      • Product Owner
      • Product Manager -- профессии нет, но методология складывается
      • Facilitator -- есть технология
      • UX -- есть техники
      • UI -- есть техники
      • Data Analytic -- нужна математика
      • BizArch -- направление, посредник бизнес-ИТ, пока нет даже методологии
    2. Пути SA - BA, UX, UI, наверное BizArch
    3. Пути BA - Product Manager, UX, наверное BizArch

Agile и ГосAgile

Обсуждения с Димой касались рамки и места Agile, а так же его уместности в гос.проектах. Они были очень полезны и в результате у меня получается зафиксировать свою позицию более развернуто в тезисах.

О рамке Agile

  1. Agile первоначально был создан именно как практика быстрой и эффективной разработки софта
    1. Предпосылкой была нехватка квалификацированных инженерных кадров, возникшая из-за резкого увеличения потребности в разработке с приходом персоналок. Решить это традиционным способом регламентного нормирования разработки не получилось.
    2. Предполалось, что цели разработки, назначение и полезность софта заданы извне. И, во всяком случае, на эту задачу квалифицированных кадров хватает.
    3. Результатом этого были готовые методики постановки процесса разработки - Scrum, позднее Kanban и их модификации
  2. Agile создавали инженеры, понимавшие опасность разработки кода при ограниченной квалификации разработчиков и в его рамках есть много практик, обеспечивающих качество изделия.
    1. Репозитарий кода, Continious Integration, тестовая среда, позднее автоматические тесты, с дальнейшим развитием в TDD, парное программирование, Code Review
    2. Использование шаблонов проектирования рекомендовалось, хотя считалось частью культуры, непосредственно не связанной с Agile
    3. Декомпозиция сложных систем с закреплением ответственности за код и интерфейсы - FDD, Джеф де Люка
    4. Построение архитектуры системы на основе модели для сложных систем и предметных областей - DDD, Эрик Эванс
  3. Agile декларирует, что набор и сложность применяемых практик должны быть адекватны сложности проекта и квалификации персонала, при этом отвергает универсальную максималистичную регламентацию - что правильно.
  4. Современный процессный фреймворк OMG Essence обеспечивает возможность индивидуальной настройки процесса для конкретного проекта, с его формальным описанием. Включая альфу технологий. Правда, отмечу что он не получил широкого распространения. Я думаю, что это в будущем, но могу ошибаться. А в перспективе формальное описание дает возможность инженерного конструирования метода. Но это еще через шаг.
  5. Agile постепенно поднимал рамку, втягивая в нее практики для работы с назначением софта, оценки его полезности, работы со стейкхолдерами проекта
    1. Основой сертификации Product Owner, которую вел Джефф Паттон в 2013, как раз составляло описание пользователей и его потребностей, и выработка стратегии их удовлетворения в релизах продукта, исходя из представлений о сегментах рынка и последовательности их овладения. Конкретные практики я перечислять не буду.
    2. OMG Essence явно описывает стейкхолдеров разработки и те возможности на рынке, которые должна обеспечить система, как одну из семи основных альф, с которыми необходимо работать.
  6. Agile появился именно в ИТ из-за особенностей развития отрасли. Но он имеет потенциал при переносе в другие отрасли. Правда, требует соответствующей перерабдотки, как Lean и Kanban перерабатывались при втягивании в Agile.

О внедрении Agile и тех, кто этим занимается

  1. Как и во всякой консалтинговой или фасилитационной деятельности внедрением Agile занимаются люди различной квалификации, различной стоимости и с различным уровнем ответственности за результаты своей работы. И это не всегда напрямую связано с ценой услуги, хотя и коррелирует.
  2. Люди должны быть соразмерны сложности решаемой задачи. Конечная ответственность на выборе консультантов - за Заказчиком, и это - повсеместная практика для выбора любых консультантов, включая врачей.
  3. Проблема современного мира состоит в том, что консультант (как и любой поставщик), более ответственно подходящий к представлению своего продукты проигрывает конкурентную гонку с менее ответственными. При этом в конечном итоге проигрывают потребители в совокупности. Это - известная проблема персиков и яблок. Те, кто внедряют Agile дейтвуют в тех же самых условиях.
  4. Когда ставятся процессные практики управления разработкой по Agile, то обычно минимальный набор инженерных практик, как то репозитарий кода, Continious Integration, тестовые среды - ставится. В ряде случаев пытаются поставить и более продвинутые практики, например Code Review. Даже если есть заказ только на управление разработкой. Хотя, естественно, далеко не всегда это оканчивается успехом.
  5. Внедрение инженерных практик является более сложной задачей, чем изменение упраления разработкой, и предъявляет дополнительные требования к квалификации исполнителя. Что далеко не всегда осознается заказчиком, особенно если у него нет понимания инженерной сути процесса разработки софта.
  6. Для сложных задач может возникнуть известная ситуация, когда квалифицированный исполнитель, адекватный задаче, не берется за нее, считая ее не реализуемой. А менее квалифицированный - согласен попробовать сделать результат, предупреждая Заказчика, что может и не получиться и ограничивая ответственность. В общем-то, это честная ситуация.
  7. Однако, бывает усугубление ситуации, которое уже не является честным. Когда квалифицированный исполниетль представляет реальный объем работ, который стоит за задачей, и оценивает ее соответственно с учетом рисков. А менее квалифицированный предлагает сделать работы в гораздо меньшем объеме и дешевле, предупреждая, что успех не гарантирован, но скрывая, насколько он маловероятен. И потому выбирают его. К сожалению, различть два описанных варианта очень сложно.

О ГосAgile, уточнение моей позиции и моего видения того. что происходит в рамках этого движения.

  1. Я согласен, что нынешние стандарты не противоречат ведению итеративной agile-разработки. И есть положительные примеры. Однако, исполнителю и заказчику приходится совместно вырабатывать формы, в которых это обеспечивается, и это не просто, во всяком случае в первый раз, и требет квалификации обоих сторон в части правового поля. Но если человек утверждает, что ведению итеративной agile-разработки с нынешними стандартами невозможно - он не владеет ситуацией или сознательно ее искажает.
  2. Я разделяю тезис о том, что по мере информатизации государственных органов у них возникает все больше текущих задач по доработке развитию существующих систем или небольших разработках. Заказчик на них, в общем случае, не является квалифицированным. А характер работ часто не требует высококвалифицированного исполнителя. В этих условиях создание методических рекомендаций, на основе опыта проектов, в которых agile уже применялся, которые помогут таким заказчикам найти адекватного исполнителя и совместно оформить контракт, по-моему, является полезным.
  3. Полезным может так же явиться доработка нормативных документов, чтобы небольшие проекты и текущие доработки могли контрактоваться по упрощенному методу, естественно, с ограничением по объемам и стоимости, как это принято для любых упрощенных процедур. Это обычная практика, применяемая, например, для налогобложения. Естественно, это будет вызывать споры в части определение границы, объема упрощения и возможности злоупотреблений, однако основные коррупционные конструкции возникают вовсе не в области упрощенных процедур, разве что туда специально вписаны коррупционные исключения.
  4. Принесение культуры инженерных практик на базовом уровне, которые несет с собой Agile, их объяснение государственным заказчикам так же полезно. И для ряда проектов является шагом вперед. Хотя я признаю, что в других ситуациях может привести к деградации инженерных практик с оптимизацией без понимания серьезности отложенных последствий.
  5. С моей точки зрения, agile в целом повышает контроль достижения результата. Особенно если потребовать поставку работающего ПО в результате каждого этапа. А упрощенный порядок для небольших задач может стимулировать их декомпозицию и движение малыми шагами. Во всяком случае, утверждается, что это проявляется на международном опыте. Хотя я понимаю, что когда речь идет о государственном заказчике к любой статистике и любому опыту надо относиться очень аккуратно.
  6. Естественно, флаг внедрения Agile может быть использован для изменения нормативных документов еще и для расширения возможности коррупционных проектов, возврата оплеты за процесс без результата, time and material, то есть просто списания денег. Поскольку, как обычно, инициатива будет со стороны одних лиц, а менять документы в конечном итоге будут другие. Но это - обычный риск любого изменения нормативных документов. И пока я не вижу таких намерений со стороны тех, кто ведет эту работу.
  7. Более того, есть отчетливое желание через переход к Agile-подходам повысить результативность разработки и снизить срок доставки реального результата, в том числе в крупных проектах. И включить в рекомендации и нормативные документы, пропагандировать направленные на это практики Agile (они есть). Зарубежные нормативные документы изучаются именно на предмет такого опыта, потому что там тоже такие намерения были одним из драйверов изменений.
  8. Отдельный трек в рамках движения касается переноса Agile-практик управления ИТ-проектами на другие типы проектов, ведущихся государственными органами и организациями. В целом я бы считал его позитивным, а не опасным в части вовышения качества небольших проектов. Понятно, при условии, что это не приведет к деградации больших. Но за результативностью больших есть отдельный контроль, и я не думаю, что он ослабнет, а количество коррупционных проектов возрастет. Могу ошибаться, и готов признать это на фактах.
  9. При этом я знаю, что "благими намерениями дорога в ад вымощена". И даже знаю про теории, согласно которым развал Союза был инспирирован соответствующими службами противника, внушавшими мысли всяким "полезным идиотам". Что наблюдается и в других событиях. Но я не думаю, что движение ГосAgile - это реализщация коварного плана врага по развалу российского государства.
  10. Внедрение Agile в Сбербанке - это отдельный от ГосAgile процесс, его развитие надо смотреть отдельно. Хотя они и находятся в рамках общего тренда и пересекаются по участвующим людям. Но лица, принимающиерешения - другие, решают другие задачи и мыслят из другой логики.

Место и Afterparty

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

После первого дня, как обычно, было общее party со струнной музыкой. И afterparty в оба дня конференции с более узким составом участников. Там встречалось то ядро аналитического сообщества UML2.ru, которое еще 6 лет назад организовало Летний аналитический фестиваль, ЛАФ. Но при желании на afterparty мог попасть любой, потому что секрета никакого не делали, а платит каждый за себя. И там было много народа.

А я, пользуясь случаем, еще раз хочу позвать всех приезжать участвовать и выступать на ЛАФ-2016 18—19 июня в Иваново. Это - другой формат, не конференция, а фестиваль. Но качество докладов - хорошее и творческая атмосфера второго дня - тоже.

Все фото взяты из Facebook, из ленты конференции, при переходе можно попасть в соответствующий пост.

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

Комментарий от Димы Безуглого при repost

Максим Цепков Опубликовал отличный обзор наших дискуссий и доклада на ‪#‎AnalystDays‬. Часть комментариев на мой взгляд очень хорошо дополняют, то что прозвучало на докладе.

Однако он смягчил ряд тезисов.

  1. Мастер класс. Agile Product Owner не равно Product manager , то что Jeff Patton давал в теме управления продуктом на несколько голов выше стандартного сертификационного тренинга и самой рамки Agile методологий.
  2. Доклад по Гибкой стратегии и Гибкому анализу. Не хватает вывода. Без гибкой стратегии и гибкого анализа переход на agile это гарантированный ход, в конкурсе за премию Дарвина, только для организаций
  3. Гос - Agile. Мой тезис простой. Т.к. текущее законодательство и практика разработки сложных систем НЕ ПРЕПЯТСТВУЕТ итеративным подходам для взаимодействия Гос с исполнителями. ( Везде где важен результат это делается). Способствование расширению этих практик есть ДОБРО. Любая попытка ЗАКОНОДАТЕЛЬНО провести схемы контрактования T&M под Agile, ( без четкого определения результатов и SLA по TimeMaterial), является 100% признаком или глупости, или осознанного повышения коррумпированности процесса...

Дальнейшее обсуждение читаем на FB.

— Максим Цепков • 25 апреля 2016 в 13:14 последняя правка 27 апреля 2016 в 01:24

Денис Бесков в комменте дал ссылку на русский перевод Александра Остервальде Построение бизнес-моделей. Я уже скачал с litres, читаю.

— Максим Цепков • 27 апреля 2016 в 01:21

Войдите, чтобы комментировать.

— Максим Цепков • 11:03, 25 апреля 2016 • 2 комментария
Источник — «https://mtsepkov.org/index.php?title=Блог:Максима_Цепкова/2016-04-25:_AnalystDays-2016_в_Петербурге_-_много_мыслей_и_позитива&oldid=6353»