Все выступления

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

В нем рассказывается о работе ресурсного менеджера группы аналитиков и отвечу на возможные вопросы:

1. Чем занимается ресусрный менеджер?

2. Ресурсный менеджер - это роль или должность?

3. Как стать ресурсным менеджером?

Ссылка на тезисы в моем письме ниже.

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

Предварительно 1.5 часа 

Рано или поздно перед массовым аналитиком, проработавшим Х лет в ИТ-доставке, в получении вопроса – «В какой степени использовать дальше перевозить?»

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

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

Для таких аналитиков развитие может стать качественным ростом в бизнес-архитекторе. 

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

Рассмотрим возможные вопросы:

- При всем богатстве выбора...

Немного перечислим и рассмотрим обычные пути развития карьеры аналитика

- А почему, собственно, бизнес-архитектор?

Рассмотрим несколько причин, почему стоит обдумать именно это движение в сторону

- А если серьезно, что такое бизнес-архитектура?

Принять основные, предназначенные и привлеченные бизнес-архитектуры концепции

- Зачем нужен бизнес-архитектор?

Узнаем в чем привлекает бизнес-архитектора, что является результатом его работы

- Я б архитекторы пошел, пусть меня научат..

Поговорим о требованиях к квалификации и бизнес-архитекторам, в чем сходство и в чем отличие аналитика и архитектора, какие есть пути перехода в бизнес-архитекторы

- Москва не сразу строилась...

Поговорим о том, какие бизнес-архитектурные задачи можно выполнить в рамках ИТ (и не только) проектов, которые можно использовать и с какими-то сложностями можно столкнуться. Рассмотрим несколько примеров из практического опыта.

- С чего начать?

Список ресурсов, литературы и полезных советов

Доклад будет своеобразным введением перед взаимодействующей частью по применению технологий или инструментов бизнес-архитектора. Формат пока на конференции.
 

В продолжение доклада есть идея сделать мастер-класс в игровом формате, чтобы дать возможность заинтересовавшимся аналитикам попробовать свои силы в области бизнес-архитектуры.
Конкретные инструменты и техники пока в стадии выбора.
Предварительно - будем решать кейс по созданию нового "бизнеса" / открытию нового направления бизнеса.
Предварительный набор техник и инструментов:
- Канва бизнес-модели (Business Model canvas)
- Анализ способностей бизнеса (Business capabilities analysis)
- Путь пользователя (Customer Journey map)
- Метрики и показатели эффективности (Metrics and KPIs)

Продолжительность 1 час, возможно - 1,5.
Продолжительность будет зависеть от количества техник.

Разные люди называют это по-разному: управление изменениями, управление проектами, трансформация, реструктуризация, ---ация.

Я же говорю: это все изменения, которыми надо управлять. Системно, имея в арсенале четкую пошаговую методологию, включающую следующие шаги:

- сформировать необходимые ресурсы для запуска процесса;

- определить точки В и А. Именно в таком порядке;

- составить план перехода;

- дойти до конца

Ведь то, что есть сейчас - результат прошлого. Будущее - результат действий сегодняшних.

Так давайте уже сегодня начнем путь, на котором проблемы станут возможностями, а потенциал развития - реальностью!

Расскажу про чат-ботов помощников, которых используем в компании.

Не хотите ходить по ссылкам от коллег? Бот пришлет всё самое важное. Нужно развернуть нужный билд на сервере? Просто напишите боту. Хотите узнать нагрузку на приложение, не анализируя большие логи? Бот всё сделает за вас. А еще - избавит  от мелких рутинных задач, которые в сумме занимают час или больше времени. И даже если вы просто хотите поближе узнать коллег, но стесняетесь, бот тоже поможет!

Остановлюсь на том, какой функционал есть в наших ботах:

• Валера — подскажет название статьи, задачи, какие тесты упали, а еще откроет дверь, расскажет, кто сегодня болеет.
• Долорес — развернет нужный билд.
• Марвин — посчитает доступное время команды, отправит статус по релизу, сделает запрос на нужное API и покажет ответ.
• random_lunch — подберет случайную пару на обед.
• secret_santa — поможет с организацией тайного Санты в компании.

Докажу, что ботов создать несложно. Например, трех из наших ботов я написал сам, хоть и не программист. 

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

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

Рассказать подробно о том, как правильно и быстро привлечь новых участников проекта с участием более 30 человек

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

1) Как коммуницировать и разделять ответствености с продактом. Как проводить встречи с продактом - на первой встрече знакомстве, на встречах 1-1, на встрече обратной связи.

2) Как работать с беклогом. Что делать аналитику, если пустой беклог или слишком перегруженный или слишком быстро меняем приоритеты. Как в этом случае поможет построение CJM и MVP.

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

На КС обсудим - что случилось с проектированием в разработке ПО и ИС?

Вопросы на КС:

1. Действительно ли так нужны требования, а не проект системы?

2. Кто и как может делать проект системы?

3. Нужны ли индустрии проектировщики?

4. Где взять проектировщиков?

5. Что нужно знать и делать аналитику, чтобы он смог делать проект системы?

• Прокрастинация…
• А нужна ли задача?
• А вдруг подобное уже реализовали?
• Как собрать воедино этот хаос?
• Как вписать в архитектуру?
• Когда, что и с кем согласовывать?
• А что от меня ждут на выходе?

Опишу свой опыт по творческому подходу к анализу больших данных. Условия задачи: всего 3 действия по времени проверки - 1 месяц и необходимо проверить закупочную деятельность организации с более чем 14,5 тысячью извещений и контрактов. Очевидно, что физически это привело к тому, что за такое время было невозможно проверить все и со всей точностью, т.о. нужно было "подсветить" куда смотреть в первую очередь. 

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

Далее была придумана вторая индикация - уже о включении в проверку (чтобы не было проверено однократно и тоже). Так "лед гасил пламя".

Дерево было построено как граф на основе финансового рек: слева были контракты с неменьшими суммами, а справа - рядом. Т.о. при анализе высшее руководство сказало "не рассматривать мелочи и обязательно рассматривать обширные".

Этот подход применим ко многим ситуациям. На подъеме банка.

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

Про проектирование, моделирование ИС написано большое количество книг и статей, сделано значительное количество интересных докладов. Но несмотря на весь это без сомнения полезный труд, что многие из нас видят в проектах, продуктах или любом другом процессе или подходе, направленном на создание ИС, программные продуктов, сервисов и т.п.?
"Пилите таски из jira!". Вот и вся работа. А результаты проектирования пыляться и скучают где-то в килотоннах документации (если она есть), или находятся в голове 5% старожилов команды и строго хранятся этим орденом. Конечно, это скорее преувеличение, но тем не менее зачастую моделирование и проектироание или не включено в поток, или в ключено, но очень слабо.

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

Я расскажу про базовые принципы описания интеграционных интерфейсов, соблюдение которых является залогом быстрой и качественной интеграции. За 20 лет работы я выработала такие базовые принципы интеграций: 

- степень детализации описания требований к интеграции зависит от срочности задачи и уровня зрелости команды разработки,

- соблюдать договоренности внутри команды / внутри проекта,

- учитывать справочные значения в интеграционных интерфейсах.

Кроме этого есть еще ряд нюансов, которые тоже следует учитывать в работе интеграционного аналитика:

- работу с пустыми и отсутствующими значениями,

- работу со всевозможными маппингами (преобразованиями) между разными интеграционными слоями,

- обработку ошибок на всех ветках алгоритма,

- сокращение Http Status Code = 500.

Если следовать этим принципам и учитывать нюансы, то "блох" интеграции, выявленных при тестировании и при выходе в ПРОД, будет в разы меньше.

Когда работаешь над продуктом для массового пользователя, хочется быть уверенным, что UX/UI работает: достаточно ли интерфейс понятен, логичен, удобен, правильно ли работают все его технические элементы. Результатом UX тестирования является перечень рекомендаций, что и каким образом нужно изменить, чтобы повысить количество конверсий и превратить посетителей сайта в его постоянных и преданных пользователей.

Как проводить UX тестирование? На какие моменты обратить внимание? Об этом я расскажу в своём докладе.

При составлении бэклога или списка требований часто возникает проблема трассировки задач бизнеса на конкретные фичи продукта. Не всегда из набора фичей складывается ясная картина влияния продукта на целевые метрики бизнеса.

Impact Mapping — это мощная техника выстраивания соответствия целей и конкретных решений. Она позволяет быстро выявить полезную функциональность (и избавиться от бесполезной), приоритезировать состав функций продукта и сфокусироваться на решении задач бизнеса, а не запиливании фич.

Кроме того, техника дает каркас для выработки решений, не связанных с изменением продукта, а лежащих в области изменения процессов и маркетинга.

На мастер-классе участники самостоятельно попробуют применить Impact mapping на учебной задаче, получат фидбэк и разбор всех нюансов построения карт влияния.

Длительность мастер-класса - 2 часа.

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

В IT есть два типа людей: те, кто пропагандирует использование REST API, и те, кто его не ненавидит. Мы встанем на третью сторону и посмотрим, какие границы применимости имеет эта концепция при проектировании API.

На воркшопе спроектируем HTTP API в рамках REST парадигмы и обсудим сложности, которые возникнут в процессе. После рассмотрим менее очевидные проблемы при использовании REST API.

Будет полезен для специалистов, имеющих опыт проектирования реальных или учебных REST API.

Длительность: 90 минут