7192
правки
Изменения
м
mtsepkov, [25.05.24 22:10]
Нет описания правки
Эта конференция не типична тем, что продажи очного участия были закрыты за полнра месяца по переполнению площадки. И действительно, во многих залах на докладахз было очень плотно. При том, что программа конференции тогда еще не была сформирована, по значительной части докладов решенеи принималось позднее. Что говорит о хорошей репутации конференции. Надеюсь, организаторы учтут это и смогут найти более вместительную площадку.
На конференции было много качественных докладов. В их числе я хотел бы отметить доклады про мышление и различные модели социального устройства. Это [[#Алексей Пименов. Социология на службе аналитика]], [[#Наталья Семенова. Концептуальное мышление: зачем оно вам, есть ли оно у вас, и как его развить]], [[#Дмитрий Безуглый. Эволюция организационного интеллекта и роль системного аналитика]] [[#Рустам Иргалиев. Антихрупкость аналитиков. Менеджмент внутри команды]].
Мой доклад [[Системное мышление и его место в работе аналитика (AnalystDays-2024a)|'''Системное мышление и его место в работе аналитика''']] тоже был посвящен мышлению. На прошлой AnalystDays я уже делал доклад [[Рациональное и системное мышление: практики и компетенции аналитика (AnalystDays-2023)|'''Рациональное и системное мышление: практики и компетенции аналитика''']], и в обсуждении от разных участников был тезис: Системное мышление - это круто, но зачем так сложно, есть же специализированные модели - Archimate, c4 model, BPMN и другие, почему их недостаточно?", и своим докладом я попробовал ответить на это возражение. Так что рассказ строился от практических задач, в которых использование специализированных моделей влечет проблемы, если у аналитика не хватает системного мышления для удержания сложных моделей. Основных проблемных места два: стык между бизнесом и софтом, и понимание конструкции бизнеса в целом, для которого распространенной процессной модели BPMN хватает далеко не всегда. За подробностями - смотрите доклад, конспекты собственных докладов я обычно не пишу.
Среди других докладов я хочу отметить доклад [[#Ekaterina Goncharova. Что такое Custom GPTs и как их готовить]]. Там основное - не техника использоания использования ИИ, а то, что аналитик, став продактом, начал делегировать аналитическую работу, на которую перестало хватать времени, не другим аналитикам, а ИИ. Так получалось проще и эффективнее. И это - качественный переход. Да, пока редкий, но получается, что делегирвоать делегировать ИИ простую работу уже легче, чем сотруднику. Еще я хочу отметить доклады [[#Валерий Разномазов. Архитектура мобильного приложения]] и [[#Галина Ларина Райффайзенбанк. Неочевидные практики архитектора в арсенале аналитика]].
В целом доклады конференции - хорошие и востребованные аудиторией. Среди участников конференции - большинство молодых, которые в профессии недавно и развиваются. Но, на правах опытного и давно участвующего, я отмечу следующую проблему в ряде докладов: докладчик не приземляет теоретическую модель на материал, не показывает особенности применения. А ведь это - самое важное. Моодель можно прочитать. Интересно - чем именно вам помогло ее применение, как был достигнут позитивный эффект, и какие были сложности. Ведь к моделям обращаются многие, а успешно воспользоваться получается далеко не у всех. Этот феномен известен как "ошибка выжившего": мы видим, чем пользовались в успешных проектах, пробуем - а оно не получается, потому что важно еще как именно этим пользовались. И хочется, чтобы доклад это раскрывал.
А еще доклады отражают общую проблему отрасли: отсутствие культуры знакомства с проработанными сложных теорий. Термин при этом могут знать, но понимать в бытовом смысле, например, системное мышление как синомним синоним для мышления о чем-то сложном, без понмиания понимания стоящих за ним принципов, методов и концепций. А в результате простые вещи превращаются в сложные изи или запутанные, если говорить в терминах Кеневин-фреймворка. Вместе с тем, материалов по разным териям теориям сейчас достаточно много и стоит их искать и знакомитсьязнакомиться, прокачивая свой метанавык быстрого освоения новых теорий. И это - не проблема конференции, тут доклады отражают ситуацию в отрасли в целом.
Ну а теперь - о докладах.
* У племени есть общий враг - не надо им становиться
* Члены племени наделены внутренним сходством
* У племени свои ритуалы и обряды - объекты ценности, их не надо нарушать и подрывать, вы станете врагом. Иногда надо сносить. , но аккуратно
* Племя понимает источник успеха, не дает шатать
* Племени есть свой язык.
Про общего врага. Это не должен быть человек или другая команда, не играйте в игру против команды PVP, играйте PVE - против внешней среды, против рынка и так далее.
Ритуалы. Как искать общее в новой команде? Первое - отношения с каждым. Выявляем соуиальные социальные группы - ВУЗ, хобби, проживание. Дальше - разматываем, создаем личный контакт. Когда с каждым личный выстроен - объединяем. Если общее. И против проблемы. И сам: можем побороться - поддержите. С удаленщиками искать общее на порядок сложнее. Возможно, игры, стриминг, телеграм-чатики.
Вопрос. Что делать, если несколько групп? Ответ: это не страшно. Страшно - когда начинают бороться. Пример - футбол: есть кузьмичи - смотрят и ультрики - подраться. Они взаимно уважают, любят футбол. Конкуренция отделов. Варианты: лидеры борются за власть - одного убрать. Если честная конкуренция - можно позволить. Очень часто работает схема, что круче тот, у кого больше подчиненных - и набирают штата, и там можно попробовать поменять критерий на эффективность, если уместно. Бывает старая против новой части команды: кто-то использовал старый самописный фреймворк. И начинают защищать.
Концептуализация: все переводи в диаграммы.
Задача - приоритизация архитектурного бэклога платформы относительно продуктовых. Что делаем: Накидываем элементы, затем кидаем связи: Компания - Клиент и цепочка продажи; Компания: продажа, разработка, поддержка; Этапы, стоимость, сроки; Клиент: продукт стоимость качество функции; поток ценности и стоимость владения; Первая сделка: маржа, конкурентное преимущество, стоимость владения, стоимость приобретения. Получаем блоки: компания, продукт, клиент, по каждому - пункты. И дальше оцениваем наши задачи по каждому разрезу, получая основания для приоритетов.
= Галина Ларина Райффайзенбанк. Неочевидные практики архитектора в арсенале аналитика =
За докладом стоит интересный кейс: система доставки продуктов банка. Исторически была собственная доставка и система вендора, которая ей управляла, потом начали использовать курьерские компании и сделали маршрутизатор. который запросы направлял в собственную систему или универсальный гейт для внешних компаний, при этом вендорская система собственной доставки - в процессе разработки собственной для замены. Каждой системой занималась отдельная команда в реактивном режиме, и внутри - все разнообразно. В этой ситуации бизнес решил объединить все команды в одну, в ответственность которой передать всю ИТ-поддержку доставки. И для начала команде надо было разобратсья разобраться в том зоопарке, в который им достался. Для этого она пошла в обучение solution architect, и использовала эти методы для проекта.
Цепочка методов интересная.
На мой взгляд, самое интересное в докладе - ситуация: Екатерина из аналитиков стала продуктом, времени на аналитические задачи стало меньше, но вместо передачи их аналитикам она выделила рутинную часть, которую передала ChatGPT. B это в целом получилось. И это как раз те изменения, которые происходят, включение GPT в виде помощников вместо людей. А в целом в докладе была техника - как добавить к GPT дополнительную информацию, которую он учитывает в ответах. Это есть в платной версии, раздел ExporeGPT. Что туда стоит класть?
* Шаблон результатов ответа, с объяснением для каких сиутаций ситуаций их применять, в разных файлах.
* Инструкции - то, что добавляешь в промпе, это процедура: описал бизнес - подумай про user story и далее.
* Информация о проекте или продукте
* Стратег Зоя. В СА из бизнеса, хорошо понимает и генерит космические и прорывные идеи. Процессный подход, ограничения лишь в голове. Способ решения - выгодный бизнесу, в описании это очень хорошо. А дизайна - нет, оно не прорабатывается. Хорошая работа с мотивированными разработчиками. Ориентация на будущее помогает подбирать решения сейчас. Но! если разработчики неопытные, джуны - будут проблемы. И с техдоком может быть пробел. А ще стратег не может оценить реализуемость, сроки и ресурсы - и может быть большая сложность решений. Соответственно работа с опытным разработчиком или с тех-экспертом
* Педант Федя. Работал проектным менеджером, подвыгорел, и пошел в аналитики. Фокус - процесс и документация, формализация и проработка мелочей. Фокус на процесс, сплочение коллектива на задаче. Может начать управлять или быть оркестратором процесса - это профит. А минусы - когда он навязывает свое видение сроков и решений, возможны конфликтам. А следование правилам и формализм дают накладные расходы. И тут надо очертить ответственность, смягчение выпадов.
* Новатор Снежана. Много курсов и полезных статей, разносторонняя личность. Следуй за мечтой, буть быть на шаг впереди, все модно-
молодежно. Полон энтузиазма, пишет творчески и эстетично, новые техники, шаблоны и методы. Слушать и вдохновлять. Полезен, когда нужен уходить от стандартных решений надо фантазировать. А в долгоиграющей задачи или бюрократической - теряет интерес. Новые методы часто используют не потому, что они реально нужны, а чтобы попробовать. Надо приземлять на практику. И уменьшать рутину. Подкрепить педантом или практиком.
Product Backlog Refinement - инструмент коллективного обсуждения задач при подготовке к включению в спринт. Идея состоит в том, что на отдельных встречах задачи представляются и обсуждаются командой, разработчики намечают способ реализации, тестировщики - способ тестирования, и задача оценивается. Такая встреча снижает неопределенность, позволяет на этапе разработки обойтись без уточнений и сделать то, что нужно. Они внедрили такой процесс, бэклог подготавливается на 2-3 спринта вперед. Внедрение - постепенное, сначала команда просто учится готовить задачи в формате заранее такого обсуждения, и уже потом учится оценивать. Профит - отсутствие необходимости уточнений и возвратов для изменения реализации, а также повышение точности планирования. Накладные расходы - часть подготовленных задач в низком приоритете в реализацию не идет, и время подготовки сгорает.
{{wl-publish: 2024-05-30 14:32:21 +0300 | MaksTsepkov }}
