Как свести к нулю количество конфликтов между проектной командой и командами поддержки (Юрий Матвиенко, SPMConf-2011) — различия между версиями
Материал из 0x1.tv
StasFomin (обсуждение | вклад) (Batch edit: replace == Слайды == with {{youtubelink|}} == Слайды ==) |
StasFomin (обсуждение | вклад) |
||
== Видео == <!-- {{spmconf-video-preview|remove-conflicts-developers-and-support-matvienko.scenario.avs.avi}} --> {{vimeoembed|33792593|720|288}} {{youtubelink|}} |4SLzusNOd4Q}} == Слайды == [[File:Как свести к нулю количество конфликтов между проектной командой и командами поддержки (Юрий Матвиенко, SPMConf-2011).pdf|left|page=-|256px]] == Примечания и отзывы == <!-- <blockquote>[©]</blockquote> --> <references/> [[Категория:Менеджмент]] [[Категория:SPMConf-2011]] |
Версия 01:25, 20 ноября 2017
Содержание
Аннотация
- Докладчик
- Юрий Матвиенко
Большинство конфликтов между проектными командами и командами поддержки возникает по двум причинам. Первая – несоответствие их целей друг другу. Вторая – отсутствие даже самых элементарных знаний о принципах работы смежной команды.
Мы редко задумываемся о том, что можем быть полезны друг другу. Поддержка должна быть звеном, связывающим проект с заказчиком. Поддержка лучше всего понимает настоящие потребности конечного пользователя и потому может быть, например, первым приёмщиком продукта. Это позволит не допускать до глаз заказчика очевидные для него изъяны. С другой стороны, работа в проекте для сотрудника поддержки – отличная школа, шаг вперёд в саморазвитии и превосходный мотиватор.
Каким образом проблемы взаимодействия служб развития и поддержки были решены в отдельно взятом ИТ департаменте крупного холдинга? Как правильно ставить цели обеим командам? В какой момент и в какой роли вводить в проектную команду сотрудников поддержки? Что надо закладывать в план и бюджет проекта ещё до принятия решения о его старте? Каким должен быть регламент передачи продукта в поддержку? Эти вопросы рассматриваются в докладе. Основной упор будет сделан на успешный практический опыт.
Видео