![](https://webcf.waybackmachine.org/web/20210926114206im_/https://habrastorage.org/getpro/habr/upload_files/147/f05/cb6/147f05cb6d06b5f4363a0aabecdf3d1e.png)
Всем привет! В прошлый раз я, как Product Owner клиентского мобильного приложения Первой грузовой компании (ПГК), рассказала о формировании нашей продуктовой команды. Спасибо всем, кто оставил комментарии под текстом. Благодаря вашим сообщениям появился этот материал. Сегодня поделюсь с вами опытом, как мы сформировали матрицу компетенций, и как коллеги развивали свои скилы во время прототипирования и проектирования сервиса.
Напомню, речь о приложении «Мобильный репортер», которое работает по принципу шеринг-сервисов. У пользователя есть анкета по осмотру грузовых вагонов — чек-лист со структурированной информацией и возможностью добавить актуальные фотографии. Это помогает следить за качеством грузовых вагонов на железной дороге и своевременно ремонтировать проблемные.
Как собирали команду
Мы пригласили в команду представителей разных сфер бизнеса. В нее вошли коммерческие специалисты (продажи) – люди, непосредственно работающие с клиентами, принимающие их заявки и понимающие, что им нужно. Они — «первая линия» по сбору обратной связи о некачественных вагонах. Еще позвали представителей вагонного блока – тех, кто отвечает за ремонт вагонов, специалистов движенческого блока, оформляющих документы на отправку вагона в депо, и ИТ-экспертов, которые воплощают в жизнь пожелания бизнеса и клиентов. Отмечу, что мы выбирали и профильных специалистов, и руководителей.
Было сложно. В тот период корпоративной жизни у нас еще не было таких направлений, как «проектная работа» и «продуктовая разработка». Между собой преимущественно общались смежные подразделения. Мы только делали первые шаги в области кроссфункционального взаимодействия. Во время проработки прототипа продукта специалисты по продажам, ремонту и движению вагонов, ИТ по-настоящему «открыли» друг друга во время проработки прототипа продукта.
Читать далее