Войти через соцсеть:
Войти через email:
Несколько лет назад мы в компании столкнулись с проблемами в управлении ожиданиями. Сроки размывались, результат инициатив не удовлетворял потребностям клиентов, а взаимодействие команд скатывалось в почтовый «футбол».
Расскажу о нашем опыте:
• как абстрактные аналитики разделились на бизнес- и системных аналитиков, solution- и системных архитекторов;
• почему мы отказались от fullstack-аналитиков и архитекторов;
• как внедрение С4-нотации и предоценки ИТ-инициатив изменило наш производственный цикл;
• почему мы проводим трассировку требований, и это нормально.
Подробно обсудим:
как выстроено управление ожиданиями в нашей текущей схеме проектирования: начиная с исследования до передачи системы или изменения в системе в поддержку релизной команды;
проверенные инструменты управления ожиданиями;
как мерить управление ожиданиями, и чем это может закончиться.
В своем выступлении я поделюсь опытом проектирования API в крупных информационных системах. Рассмотрим два различных подхода: первый, основанный на многократном переиспользовании методов, и второй, предполагающий разработку индивидуальных методов для каждой функциональной возможности. В ходе выступления мы сосредоточимся на анализе преимуществ и недостатков обоих подходов, а также обсудим эффективные стратегии устранения проблем с целью оптимизации процесса разработки и снижения общих трудозатрат команды.
Расскажу подходы к работе аналитика на основании моего опыта:
- Выстраивание работы в команде, когда какой-то роли не хватает
- Разберу типичные ситуации в реальных проектах.
Какие ошибки совершила и как можно было поступить удачнее
- Планирование своих задач и работа с ожиданиями
Это позволит вам успешно провести аналитику в проекте в срок даже в условиях неполной команды, успешно запустить проект, но при этом не стать человеком-оркестром, который ответственен за всё.
На нашем круглом-столе я поделюсь своим опытом в проектировании и разработке API, представлю перечень невидимых и скрытых проблем, с которыми я сталкивался в своей работе. Вместе мы проанализируем способы их устранения и создадим общую карту типичных ошибок при разработке API, а также эффективные методы их решения.
1. Существует множество подходов к документированию API. Определить подход к документированию сложно, так как с одной стороны есть потребность к полному и подробному описанию, с другой стороны такое описание не будет иметь практической ценности из за своей избыточности для отдельно взятых участников процесса разработки.
2. При определении подхода к описанию API нужно учитывать факторы:
a. Степень зрелости продукта. Как пример, для продуктов на ранней стадии развития, можно ограничиться простым описанием в системах управления знаний, или на уровне постановки задач на разработку.
b. Потребители API. В зависимости от потребителей API подход к документированию может быть разный. Для продуктов, которые предоставляют интеграционные интерфейсы для внешних систем, нужно подробное описание API, для внутренних интеграций достаточно краткого описания, так как существуют дополнительные документы.
c. Стандарты принятые в компании. В больших компаниях уже существуют лучшие практики описания документации.
3. Для определения подхода к документированию можно использовать чек листы. Чек лист помогает выбрать подход и инструменты для описания API учитывая потребности всех участников процесса разработки. Чек лист помогает стандартизировать документацию по продукту и повысить её качество.
В докладе расскажу о концепции как инструменте определения границ проектируемой системы и оценки трудоемкости работ по анализу. Поговорим о том, что это за артефакт, что он должен содержать, как выглядит процесс работы с ним и как он помогает нам в дальнейшей работе над реализацией системы.
В докладе я расскажу о своем опыте ведения документации при реализации IT-продукта. В первой части представлю структуру документации, которую мы используем в ITFB Group, а во второй расскажу, как принципы работы с документами влияют на управление изменениями и развитие продукта.
1 часть: Методология ведения документации по проекту в компании ITFB Group
- какой комплект документов передаем заказчикам
- как собираем и фиксируем требования
- что описываем для передачи в разработку
- на основе чего проводим тестирование и приемку
2 часть: Как методология помогает при управлении изменениями:
- принципы ведения документации, чтобы аналитику было проще
- как вести трассировку (связанность) требований и не упускать важные детали при изменении требований
- как аналитика помогает сделать точную оценку проекта
- как оценить саму аналитику в крупном проекте с низкой степенью детализации
На воркшопе постараемся совместно с аудиторией рассмотреть проблематику ожиданий различных ролей в ИТ-проектах от бизнес- и системного аналитика.
У участников будет возможность встать на сторону какой-то роли и поделиться своими идеями и опытом по разным аспектам, таким как:
- "hard'овые" ожидания в части навыков и опыта.
- должен ли аналитик быть немного менеджером, тестировщиком и иногда писать код?
- должен ли аналитик думать за заказчика или "желание клиента для нас закон"(с)?
- аналитик-интроверт это норма?
- можно ли иногда работать по правилу "и так сойдет"(с)?
Также подумаем над тем, верен ли тезис "ваши ожидания - это ваши проблемы".
В заключении вместе сформируем рекомендации по улучшению взаимодействия и повышению эффективности работы бизнес- и системного аналитика на проекте.
1. поговорим о PlantUML - многофункциональном инструменте для построения диаграмм на основе текста
2. вместе построим sequence-диаграмму REST-api, используя "плюшки" программирования
3. сравним PlantUML с другими инструментами визуализации (draw.io, Mermaid)
- Что на самом деле хочет корпорация и руководство от аналитика: статистика из вакансий и примеры реальных ожиданий руководителей доменов и команд.
- Ключевые ожидания от аналитика на фазе онбординга.
- Выполнения каких задач на регулярной основе ожидают от аналитика в Enterprise.
- Что делать аналитику, если внутри компании и конкретной команды нет устоявшихся рабочих процессов.
- Как аналитику определить свои зоны ответственности и задачи.
- Наиболее востребованные soft-skills у аналитика с точки зрения руководителя.
Многие системные аналитики принимают участие в проектировании микросервисов. В своем докладе я расскажу, как можно применять BPMN для этой задачи. Поговорим как его использовать при проработке альтернативных потоков. Разберемся в границах ответственности аналитика и архитектора решения. Посмотрим на примерах как оценить получившийся результат.
Меня зовут Ирина, я — директор департамента аналитики в ITFB Group.
Свой департамент я вырастила из маленького отдела, состоящего из 8 человек. Сейчас в моей команде 91 сотрудник, и я не планирую останавливаться!
Хочу поделиться своим опытом и рассказать вам:
1. Как у нас выстроен карьерный трек от стажера до главного аналитика.
2. Как выглядит карьерная лестница.
3. Что важно на каждом из этапов роста.
4. На что делать акценты, когда строишь свою карьеру в IT.
5. А как быть, если ты уже специалист уровня middle+.
6. Обязательно ли расти в управленца или можно куда-то еще.
7. У всех ли получается стать менеджерами и надо ли это делать.
8. Почему круто, когда в компании выстроен карьерный трек и как это мотивирует сотрудников.
Вы узнаете о реальном практическом опыте, который уже работает и на который ориентируются новые направления внутри компании, а также внешние заказчики. Вы получите и заберете с собой знания, которые можно будет применять и становиться лучше.
