Опыт госпроектов и взаимодействия с корпоративными структурами
Download as PPTX, PDF0 likes233 views
Доклад Максима Цепкова посвящен особенностям сотрудничества с крупными корпоративными заказчиками в области разработки и внедрения IT-решений. В нём рассматриваются роли и функции UX/UI-специалистов и аналитиков, а также важность коммуникации со стейкхолдерами для успешной реализации проектов. Цепков делится опытом планирования и проведения демонстраций, подчеркивая необходимость адаптации к процессам крупных организаций.
Опыт госпроектов и взаимодействия с корпоративными структурами
- 1. Сотрудничество с корпорациями: рецепты из практики Максим Цепков Главный архитектор дирекции развития решений Конференция «ПрофсоUX» Санкт-Петербург, 15 апреля 2017
- 2. Я IT-аналитик, архитектор и руководитель проектов Заказная разработка и внедрение корпоративных систем (более 20 лет) Крупные компании и государственные заказчики Ведение проектов по Agile, выстраивание партнерских отношений с заказчиками Кто я и о чем расскажу? Этим опытом я поделюсь в докладе, думаю, он поможет вам ориентироваться в таких проектах 2/20
- 3. Место UX/Usability/UI-специалиста в проекте Особенности проектов крупных заказчиков Практики планирования проекта План доклада 3/20
- 4. Место UX/Usability/UI- специалиста в проекте 4/20
- 5. Эволюция: UI Usability UX Concept Requirements and Architecture Detailed Design Implementation Integration and Test System Verification Maintenance V-Model (Wikipedia) UI-design – в интерфейсе легко ориентироваться Usability – интерфейс удобно использовать UX – интерфейс интуитивно понятен и соответствует ожиданиям Пользователи Многие заказчики (и не только они) не различают специализации и, говоря «UX», подразумевают «UI» и немного Usability 5/20
- 6. Область аналитика – требования, функции и конструкция системы Область UX/UI-специалиста – взаимодействие системы с пользователем Казалось бы, нужны два специалиста, но обычно есть только один Юрий Куприянов на Analyst Days – 2015 разбирал типовые проблемы этого Некоторые заказчики полагают, что UX-специалист – это просто «новый аналитик», будьте готовы UX/UI-специалист и аналитик Здесь тоже путаница, будьте готовы 6/20
- 8. У крупного заказчика обычно есть процесс, принятый для реализации ИТ-проектов Он часто ориентирован на водопад: редкие поставки, согласования постановок, работа через артефакты Но он включает налаженные каналы взаимодействия с сотрудниками в большой организации И общение с сотрудниками не противоречит ему Есть неформальные правила – их надо соблюдать Процесс или коммуникации? Нужно пользоваться преимуществами и адаптироваться к недостаткам 8/20
- 9. У заказчика обычно есть стейкхолдеры, заинтересованные во внедрении софта Они понимают, что для успеха бывает необходимо менять требования и скоуп Стейкхолдеры готовы совместно находить решения: обмен скоупа, допсоглашения и др. Иногда (или часто) для этого требуется жесткость позиции, но не конфронтация Изменения в требованиях Найдите заинтересованных стейкхолдеров и взаимодействуйте с ними 9/20
- 10. Позиции стейкхолдеров у заказчика 10/20 Заказчик Компания Технологи и руководители, проектный офис Concept Requirements and Architecture Detailed Design Implementation Integration and Test System Verification Maintenance ИТ-отдел(ы) новых разработок и проектов Операционные сотрудники Эксплуатация ИТ (админы) Нужно понимать принятый у заказчика способ разрешения конфликтов (эскалация или переговоры) Служба контрактования
- 11. Коммуникация со стейкхолдерами заказчика: пользователями и руководителями, бизнесом и ИT Понимание потребностей, предложение и согласование решений Коммуникация между разными отделами заказчика Выявление неформальных правил коммуникации Демонстрация и внедрение результатов, обучение: вы понимали потребности – вам и представлять результат Психотерапия и психоанализ Коммуникация с командой, донесение ей смыслов от заказчика Поддержка руководителя проекта в работе с заказчиком Функции UX-специалиста/аналитика в проекте 11/20
- 12. Нужно различать роли стейкхолдеров заказчика Надо знать и учитывать процедуру контрактования Например: Демо может играть роль испытаний софта (или обучения) Пожелания на демо могут оформляться в протоколе как замечания (устранение бесплатно) или запросы на доработку Часть запросов на доработку требует отдельного подтверждения Пожелания в письмах также могут быть основанием для доработок или требовать отдельного согласования Заказчик понимает, что ход проекта отклоняется от процедуры, отдельные люди контролируют размер допустимого отклонения и его цели Поддержка контрактования 12/20
- 14. Общий скоуп проекта определяется бизнес-целями проекта заказчика и не всегда может быть изменен Большой проект часто можно разбить на этапы Есть опытно-промышленная эксплуатация (ОПЭ), в нее может быть передан ограниченный функционал Сценирование проекта. Этапы Этап 2 ОПЭ Этап 1 Первый этап для ОПЭ – замкнутый функционал, решающий существенную проблему заказчика. MVP (Minimum Viable Product) надо выявлять Софт в ОПЭ уже работает! 14/20
- 15. Разработка функционала для ОПЭ – 4–6 месяцев Разбиваем на 2–4 демо, представляя интересный бизнес-заказчику, целостный функционал Первые демо проводим на нашей территории – так заказчик знакомится с командой Далее разворачиваем тестовую среду у заказчика, переносим демо в нее, совмещая с испытаниями Сценирование проекта. Демо Этап 2 ОПЭ Этап 1 Демо у нас У заказчика 15/20 Этап 2 ОПЭ Этап 1
- 16. У каждого демо – целевая группа и интересный ей функционал. Группа должна увидеть свой процесс Учитываем разрывы с текущей автоматизацией и связанные с этим ожидания Нужно показать ожидаемые улучшения Дать понять, что «по площади» не станет хуже Логику разработки учитываем творчески Разрабатываем хороший операционный документооборот, полный функционал – документы и справочники велик для первого демо Можно показать документооборот, а справочники без интерфейсов Или позвать группу, для которой ценны новшества в справочниках Планирование серии демо 16/20
- 17. Демо сценируем и проводим с учетом интересов бизнес-пользователя на его языке Демо обычно проводят те, кто собрал требования, – у них уже есть контакт с заказчиком В демо у нас участвует вся команда – таким образом заказчик с ней знакомится Демо у заказчика – это испытания для его ИТ и обучение для пользователей, мы их разделяем Такой подход позволяет расширять круг контактов у заказчика Пользователи заказчика могут посмотреть софт сами Но не вся команда участвует – надо доносить обратную связь Проведение демо 17/20
- 18. Определяются бизнес-потребностями заказчика Релизы к сроку с заданным функционалом Релизы заданного функционала к моменту готовности Срочные обновления с небольшим функционалом Это нарушает ритм работы и требует планирования Это влечет накладные расходы на процесс Это обеспечивает решение проблем бизнеса Релизы после ввода в ОПЭ 18/20
- 19. Различаем формальное и фактическое назначение Бывает, что есть формальная write-only документация для соблюдения процедур и легкого фактического согласования Бывает, что формальный документооборот является налаженным способом работы бюрократической машины заказчика Документооборот в большой организации – способ согласования действий, его нужно поддерживать Документы, как и коммуникация, – способ налаживания сотрудничества, а не конфронтации Часть отделов лучше общается через нас, а не напрямую внутри организации Документация 19/20
- 20. Найдите стейкхолдеров, заинтересованных в успехе проекта, и ведите с ними коммуникацию Сочетайте общение с перепиской, другими видами формальной и неформальной коммуникации Используйте налаженные в организации пути Помните о формальном контрактовании Успешного сотрудничества! Корпорации: путь к сотрудничеству Вопросы? Обращайтесь! Максим Цепков mtsepkov.org 20/20