7. Возможные причины запросов на прямую
коммуникацию с командой
Преимущества и недостатки прямой коммуникации
для команды и компании
# 7
ЧТО ДЕЛАТЬ? ЗАЧЕМ ? ЧТО ДЕЛАТЬ?
Тип контракта
Методология разработки
География команды и клиента
Изменения в проекте и Что будет
после завершения проекта?Личные качества
9. Тип контракта
# 9
Fixed Price
• Требования максимально
детализированы
• Неизменные: объем, цена
• Гибкость: низкая
• Любые изменения
дополнительно
согласовываются
• Риски: на исполнителе
10. Тип контракта
T & M
• Требования могут уточнятся
и изменяться
• Изменяемые: объем, цена
• Гибкость: высокая
• Изменения быстро
обрабатываются
• Риски: на клиенте
Fixed Price
• Требования максимально
детализированы
• Неизменные: объем, цена
• Гибкость: низкая
• Любые изменения
дополнительно
согласовываются
• Риски: на исполнителе
# 10
11. Тип контракта
T & M
• Требования могут уточнятся
и изменяться
• Изменяемые: объем, цена
• Гибкость: высокая
• Изменения быстро
обрабатываются
• Риски: на клиенте
Fixed Price
• Требования максимально
детализированы
• Неизменные: объем, цена
• Гибкость: низкая
• Любые изменения
дополнительно
согласовываются
• Риски: на исполнителе
Fixed Budget
[Capacity]
• Требования могут изменяться
• Поэтапные релизы
• Изменяемые: объем
• Неизменные: цена
• Гибкость: высокая
• Изменения быстро
обрабатываются
• Риски: между клиентом и
исполнителем
# 11
12. • [+] Совместные сессии по обязанностям
в рамках нового типа контракта
• [+] В начале расширенный репортинг
• [+] Контроль изменений
• [+] Мониторинг настроения клиента и
команды
• [+] Совместный риск менеджмент
• [-] Пускать на самотек
Тип контракта
# 12
• Изменение типа контракта может
приводить к прямой коммуникации
• Доверие к исполнителю
• Если нет ясности, каким будет решение
• Изменения – фича или дополнительные
требования
T & MFixed Price
Fixed Budget
[Capacity]
14. Методология разработки
# 14
Waterfall
• Требования к продукту
предельно ясны и стабильны;
• Известны используемые
технологии и инструменты;
• Чувствителен к изменениям;
• Зачастую проблемы выявляются
на этапе тестирования;
• Пример: внедрение новой
версии известного продукта
15. Методология разработки
# 15
Waterfall
• Требования к продукту
предельно ясны и стабильны;
• Известны используемые
технологии и инструменты;
• Чувствителен к изменениям;
• Зачастую проблемы выявляются
на этапе тестирования;
• Пример: внедрение новой
версии известного продукта
Agile
• Итеративная разработка;
• Конечный пользователь
вовлечен с начала;
• Легко вносить изменения в
требования
• Высокий уровень
профессионализма команды
• Риск: в процессе постоянных
изменений не достигнуть
завершения проекта
16. Методология разработки
# 16
Waterfall
• Требования к продукту
предельно ясны и стабильны;
• Известны используемые
технологии и инструменты;
• Чувствителен к изменениям;
• Зачастую проблемы выявляются
на этапе тестирования;
• Пример: внедрение новой
версии известного продукта
Agile
• Итеративная разработка;
• Конечный пользователь
вовлечен с начала;
• Легко вносить изменения в
требования
• Высокий уровень
профессионализма команды
• Риск: в процессе постоянных
изменений не достигнуть
завершения проекта
Iterative
Incremental
• “мульти-водопад”
• Модульная поставка
• Вначале основная часть, а в
следующих поставках
инкрименты
17. Методология разработки
# 17
Waterfall Agile
Incremental
Iterative
development
• Изменение методологии
может приводить к прямой
коммуникации
• Отсутствие опыта
• Риски по проекту
• [+] Совместные сессии по новой методологии
• [+] Воркшопы с заказчиком по формату
работы с командой
• [+] Контроль изменений
• [+] Мониторинг настроения клиента и
команды
• [+] Совместный риск менеджмент
• [-] Саботировать изменения
19. Методология разработки :: распределение ролей
# 19
Заказчик Команда
• Распределение проектных ролей
между клиентом и командой
• Как заказчик видит проектную
команду?
• (где есть менеджеры и какие у них
обязанности)
20. Методология разработки :: распределение ролей
# 20
Заказчик Команда
Менеджер проекта?
Team Lead
Practice Lead
Разработчики
Менеджер проекта
21. Методология разработки :: распределение ролей
# 21
Заказчик Команда
Team Lead
Разработчики
Product owner
Scrum Master
Practice Lead
Менеджер проекта
22. Методология разработки :: распределение ролей
# 22
Заказчик Команда
Team Lead
Разработчики
Product owner
[-] Scrum Master
Practice Lead
Менеджер проектаРазработчики?
Изменения в
команде
заказчика
People Management?
Менеджмент
в локации?
Переформатирова
ние команды
исполнителя
24. География команды и клиента
# 24
Onsite
[onshore]
Near shore Offshore
Offshore
Offshore
Распределенная команда или
нет?
25. География команды и клиента
# 25
[+] Регулярные Governance Review, QBR
[+] Договориться о представителе у клиента
[менеджер, аналитик или архитектор/эксперт]
[-] Удаленная работа показывает
проблемы, которые могут не
проявляться в офисе
Onsite
[onshore]
Near shore Offshore
Offshore
Offshore
[+] Визиты ключевых людей к
заказчику
[+] Визиты
заказчика в
деливери центры
27. Что будет после завершения проекта?
# 27
Видение клиента по
разработанному
решению?
28. Что будет после завершения проекта?
# 28
Видение клиента по
разработанному
решению?
• Оставить у исполнителя на
поддержку
• Передача другому вендору
• Передача своему центру
разработки (инсорсинг)
Важно доверие и
прозрачность планов между
клиентом и исполнителем
29. Что будет дальше? Эволюция отношений с клиентом
# 29
1
Разработка части решения
[outstuff]
2
Разработка продукта для
клиента [outsource]
3
Предоставление сервиса
[managed service]
4
Участие в решении бизнес-
задач клиента
5
Участие в разработке
стратегии клиента
Где клиент?
Где проект?
Видение клиента по
разработанному решению?
31. Причины. Преимущества и недостатки
# 31
• Недоверие
• Предыдущий опыт
• Отсутствие опыта с вендором
• Репутация вендора/команды
• [отклонения] Риски по проекту
Возможные причины запросов на
прямую коммуникацию с командой
Стоит ограничить данную коммуникацию
или сформировать другие каналы
32. Причины. Преимущества и недостатки
# 32
• Недоверие
• Предыдущий опыт
• Отсутствие опыта с вендором
• Репутация вендора/команды
• [отклонения] Риски по проекту
• Скрытые планы клиента
Возможные причины запросов на
прямую коммуникацию с командой
33. Причины. Преимущества и недостатки
# 33
• Недоверие
• Предыдущий опыт
• Отсутствие опыта с вендором
• Репутация вендора/команды
• [отклонения] Риски по проекту
• Наличие технического бэкграунда
и желание повлиять на решения
• Изменение команды у клиента
• Изменение типа контракта
• Изменение методологии
• Изменение географии команды
• Скрытые планы клиента
Возможные причины запросов на
прямую коммуникацию с командой
Возможна прямая коммуникация, если это часть изменений
34. Причины. Преимущества и недостатки
# 34
• Недоверие
• Предыдущий опыт
• Отсутствие опыта с вендором
• Репутация вендора/команды
• [отклонения] Риски по проекту
• Наличие технического бэкграунда
и желание повлиять на решения
• Изменение команды у клиента
• Изменение типа контракта
• Изменение методологии
• Изменение географии команды
• Скрытые планы клиента
Возможные причины запросов на
прямую коммуникацию с командой
• На работу с разными причинами
требуется разное количество
усилий
Возможна прямая коммуникация, если это часть изменений
Стоит ограничить данную коммуникацию
или сформировать другие каналы
39. Что делать?
# 40
Тип
контракта
Методология
География
команды
Что будет
дальше?
Личные
качества
• Что важно?
• PAEI
• Social Behavior Style
• DISC
• Какие планы по
методологии?
• Какие планы по
локациям?
• Какие планы по
команде клиента?
• Какие с проектом?
• Какие планы с
вендором?
40. Клиент [прямая коммуникация] Команда
Клиент предпочитает работать с командой напрямую
ИМЕЕТ ли это СМЫСЛ?
Андрей Данилов
VI.2017