- Архитектура ПО - Системная и бизнес аналитика - Построение и развитие команд архитекторов и аналитиков
Цель
Обмен лучшими практиками в развитии направлений архитектуры, системной аналитики ПО в компании.
Задачи
Научить слушателей разрабатывать лучшие документы по аналитике, чем кто-либо Поделиться опытом выстраивания работы отдела архитектуры и аналитики
Описание секции
Секция посвящена лучшим практикам в работе архитекторов и системных аналитиков ПО. Участники узнают, как сделать свои тексты более полезными и избежать скуки, что важно при выстраивании работы отдела системной аналитики и архитектуры.
Для кого
1
архитекторы ПО
2
системные аналитики
3
руководители проектов
4
руководители ИТ подразделений
5
интересующиеся темой архитектуры и системной аналитики в разработке ПО
Спикеры
Максим Иванкин
Менеджер продукта
Элком+, г. Томск
«Осторожно! Дефектные работы. Что аналитики делают не так и не для чего»
Кирилл Щемелинин
г. Калининград
«Как организовать эффективный отдел архитектуры и аналитики ПО»
Купить билет на Город IT
8 сентября мы собираемся на Воркшопе который ориентирован в первую очередь на тимлидов и желающих ими стать (так же воркшоп подойдет руководителям направлений, менеджерам проектов и продуктов и всем, кто работает с людьми). Покупая билет на воркшоп, БОНУСОМ вы получаете доступ к всем секциям Город IT Pro.
Покупая билет на секции, вы получаете право принять участие во всех секциях Город IT Pro (9 и 10 сентября), в билет не входит посещение Воркшопа. На секции мы приглашаем всех, кто интересуется IT выступлениями спикеров и мощнейшим нетворкингом.
Работает в ИТ с 2007 года в таких компаниях как ContekSoft, Palex, Unigine, Rubius, UTS, NTR Lab
Осторожно! Дефектные работы. Что аналитики делают не так и не для чего.
Тезисы:
Ваши системные и/или бизнес-аналитики работают, работают хорошо, пишут много, анализируют… Но результат их труда несет невысокую ценность: много текста, мало смысла, мало деталей, много вопросов. Что не так? Где дефекты в работе аналитиков. Попытаюсь исправить видение работы в головах аналитиков и дать кое-какие практические советы, чтобы ваши труды были полезны и не вызывали скуку и уныние в головах потребителей аналитики.
Кирилл Щемелинин
Как организовать эффективный отдел архитектуры и аналитики ПО.
Денис Юрьев(Skyeng)
Ваша компания сделала успешный продукт в своей нише. Круто, но пора двигаться дальше. Часто бизнес решает масштабироваться для большего охвата клиента с похожим решением, но «с перламутровыми пуговицами». Компания нанимает новую команду. Команда клонирует имеющийся код, слушает советы старичков, начинает отрезать лишнее и докручивать нужное, и... через полгода у компании уже два совершенно разных проекта, независимо от того, насколько одинаковы были решаемые задачи. Сложность поддержки тоже выросла.
У меня такое пару раз было и с тех пор хотелось сделать это всё иначе. Поэтому когда в Skyeng решили запускать новые предметы после успеха нашей с командой платформы, предложил: «А давайте мы своими силами». Поддержка новых репозиториев казалась неинтересным, а с учетом планов на десяток потенциальных проектов — самоубийственным решением. Поэтому мы пошли новой дорогой.
Предстояло найти компромисс между удобством поддержки нескольких проектов минимальными силами и требованием беспроблемно вносить новый функционал. Возможность запуска новых продуктов в течение считанных часов получилась сама собой.
В докладе поделюсь историей в деталях, как мы спланировали архитектуру, как пошли не по принятым в компании практикам, на какие «грабли» Symfony наткнулись в процессе — и почему оно у нас вообще получилось.
Денис Юрьев(Skyeng)
Ваша компания сделала успешный продукт в своей нише. Круто, но пора двигаться дальше. Часто бизнес решает масштабироваться для большего охвата клиента с похожим решением, но «с перламутровыми пуговицами». Компания нанимает новую команду. Команда клонирует имеющийся код, слушает советы старичков, начинает отрезать лишнее и докручивать нужное, и... через полгода у компании уже два совершенно разных проекта, независимо от того, насколько одинаковы были решаемые задачи. Сложность поддержки тоже выросла.
У меня такое пару раз было и с тех пор хотелось сделать это всё иначе. Поэтому когда в Skyeng решили запускать новые предметы после успеха нашей с командой платформы, предложил: «А давайте мы своими силами». Поддержка новых репозиториев казалась неинтересным, а с учетом планов на десяток потенциальных проектов — самоубийственным решением. Поэтому мы пошли новой дорогой.
Предстояло найти компромисс между удобством поддержки нескольких проектов минимальными силами и требованием беспроблемно вносить новый функционал. Возможность запуска новых продуктов в течение считанных часов получилась сама собой.
В докладе поделюсь историей в деталях, как мы спланировали архитектуру, как пошли не по принятым в компании практикам, на какие «грабли» Symfony наткнулись в процессе — и почему оно у нас вообще получилось.
Денис Юрьев(Skyeng)
Ваша компания сделала успешный продукт в своей нише. Круто, но пора двигаться дальше. Часто бизнес решает масштабироваться для большего охвата клиента с похожим решением, но «с перламутровыми пуговицами». Компания нанимает новую команду. Команда клонирует имеющийся код, слушает советы старичков, начинает отрезать лишнее и докручивать нужное, и... через полгода у компании уже два совершенно разных проекта, независимо от того, насколько одинаковы были решаемые задачи. Сложность поддержки тоже выросла.
У меня такое пару раз было и с тех пор хотелось сделать это всё иначе. Поэтому когда в Skyeng решили запускать новые предметы после успеха нашей с командой платформы, предложил: «А давайте мы своими силами». Поддержка новых репозиториев казалась неинтересным, а с учетом планов на десяток потенциальных проектов — самоубийственным решением. Поэтому мы пошли новой дорогой.
Предстояло найти компромисс между удобством поддержки нескольких проектов минимальными силами и требованием беспроблемно вносить новый функционал. Возможность запуска новых продуктов в течение считанных часов получилась сама собой.
В докладе поделюсь историей в деталях, как мы спланировали архитектуру, как пошли не по принятым в компании практикам, на какие «грабли» Symfony наткнулись в процессе — и почему оно у нас вообще получилось.