Доклад "Вяжем плед из требований для теплой ламповой поддержки".
Тизер: Как узнать, что происходит с вашим приложением и как подготовить требования для этого?
Одна из характеристик качества приложения — сопровождаемость. Я работаю аналитиком в команде, которая разрабатывает коробочный entrprise-продукт для компаний с миллионами клиентов. Это телеком, банки, страховые. Мы собираем клиентские данные из разных систем компании в одну базу, чтобы упростить обслуживание клиентов. Из-за интеграций с операционными системами, которые работают с клиентом в режиме реального времени наша система становится бизнес-критичной, поэтому мы должны гарантировать ее работоспособность.
Но предусмотреть абсолютно все ошибки и ситуации невозможно, поэтому важно понимать, что в каждый момент происходит с системой для предупреждения ошибок или поиска причины проблемы. Мы не просто поставляем продукт, но и оказываем третью линию поддержки всем нашим заказчикам.
В докладе расскажу, с чего мы начинали и как за 5 лет выстроили механизмы, позволяющие нам предупреждать серьезные проблемы и поддерживать 15 заказчиков силами 2 человек.

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

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

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

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

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

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

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

Основные проблемы, с которыми сталкивается аналитик

• На старте проекта и обследовании объекта автоматизации
• В ходе проекта

Подход для решения проблем

• Цели подхода
• Инструменты для повышения скорости и качества работы аналитика
• Инструменты для упрощения представления и улучшения понимания результатов работы аналитика
• Общие рекомендации для повышения ценности аналитика в проектах разработки ИТ-систем

Результаты внедрения подхода

• Что улучшилось по результатам применения подхода
• Новые проблемы, которые возникли при применении подхода

Бывают внезапно большие проекты, а бывает внезапно большая команда. Расскажу как наша команда трансформировалась из небольшой команды из 6 человек в большую продуктовую группу из 30+ человек. С какими сложностями столкнулись и что изменилось в работе аналитика в такой большой команде.

Привет! Хочу предложить собственный мастер-класс на тему места аналитика в гибких методологиях. Формат конференции и самой темы предполагает то, что однозначного ответа на этот вопрос быть не может, поэтому я и устраиваю мастер-класс, состоящий из трёх частей:
1. Обсуждение того, что же вообще делает аналитик. Я буду задавать простые вопросы, вы на них отвечать, а потом сравнивать ответы с ответами, которые я нашел для себя. В итоге мы сформируем единую понятийную и методологическую базу, которую будем использовать на следующем шаге. Возможно, кто-то с ней и не согласится - и это здорово, так как на следующем шаге мы проверим эффективность каждой из них. Самое главное, что вся аргументация будет перед глазами участников. Время - 30-40 минут в зависимости от активности участников.
2. Мы попытаемся смоделировать четыре спринта проекта, приближеного к реальному. И на этой симуляции попробуем всё то, что обсуждали на первой части. Время - 1 -1,5 часа. Опять таки, в зависимости от активности участников.
3. Обсуждение итогов, отзывы, впечатления. Время - минут 20.

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

Немного обо мне. Я занимаюсь разработкой ИТ-продуктов и проектов больше 15 лет. Из них лет 5 занимался именно аналитикой. Был и системным аналитиком, и бизнес-анлитиком, и внедрял методологию разработки ПО. Дальше стал заниматься больше управлением. Управлял департаментом, где был отдел аналитики, чью работу я выстраивал и систематизировал. Последние 6 лет я управляю собственной студией разработки сложных и нетривиальных ИТ-продуктов, где, естественно, на проектах есть аналитики. Моими клиентами были разные компании - и мелкие, и средние, и чьё имя каждый день можно услышать по телевизору. Мы применяли в зависимости от проекта и "водопад", и гибкие методологии. Сейчас я управляю разработкой двух ИТ-продуктов для крупной государственной компании и строю работу именно по гибким методологиям.

Буду рад обменяться опытом с единомышленниками и ярыми противниками :)

Бывало ли у вас такое, что поставленная Вам задача размыта, неконкретна или даже недостижима? У вас есть оценка, список работ и вопросы. Я расскажу про свой опыт работы на таких проектах. Будут раскрыты следующие тезисы:

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