“Уважение как принцип формирования взаимоотношения с сотрудниками и клиентом.”
Данная статья покажется неоднозначной, но к сожалению работа проект менеджера не может быть загнана в шаблоны, и если бы это было возможно то я давно потерял бы работу, и известные баг трекер автоматизировали бы мою часть труда.
Уверен многие из вас сталкивались с ситуацией, когда на проекте беда, все идёт через одно место, разработчики бунтуют, клиент недоволен и хочет сменить вендора.
В такой момент работа проект менеджера крайне важна. От того как он будет общаться с коллегами, помогать им общаться с заказчиком и решать проблемы, зависит успех вашего проекта.
Первое с чего нужно начать, это наладить процесс обработки проблемы, понятный всем участникам проекта, включая ваших PO.
рассмотрим типичную проблему, заказчик столкнулся с серьёзной проблемой с производительность. вот список правил которые мы используем в своей работе при обработке проблем:
- Создаем чат с названием support, в который входит вся команда и заказчик.
- назначаем часть команды ответственными за проблемы с прод ишуями.
Я предпочитаю формацию Feature Team когда в разборе проблем в первую очередь вступает один QA один Front и Один Back end developer. как показывает практика, не существует коллективной ответственности, если на назначить ответственных и их роли в рамках support команды, толку не будет.
Как пример QA может быть ответственным за первичную коммуникацию с клиентом, банально отвечать на любые баги зарепроченые клиентом в течении 15 минут, “We are looking in to it!”. ну а разработчики на подхвате, каждый за свою часть должен подсыпать деталей, если клиент не против.
- Если в течении дня не смогли решить проблему, пожалуйста проявите уважение к клиенту и напишите в конце для, за 30-40 минут до конца рабочего дня, что к сожалению не смогли за день пофиксить. Возможно ишуя супер критична и клиент предложит поработать в овертайм, но решить сегодня.
- По всем ишуям с прода, заводится документ с названием Post mortem. в данный документ в реальном времени записываются все основные действия, которые предпринимает команда, дальнейший анализ записей позволяет понять что в следующий раз сделать лучше или иначе.
- Когда все закончится, обязательно обсудите все проблемы на ретроспективе. Как показывает практика, ретроспектива это отличный инструмент взаимодействия с клиентом. Открытый формат работы, будет воспринят позитивно, если конечно вы не пытаетесь выдать June за Senior. Чаще всего европейский клиент очень ценит проактивность и открытость. Я рекомендую вносить вопросы для обсуждения на ретроспективе в процессе спринта и не ждать его конца, иначе все забудете.
В следующий раз, расскажу как интересно и поучительно проводить ретроспективы.