Видимость и продвижение вашей команды в компании. По результатам доклада.

Выступил на тему “Видимость и продвижение вашей команды в компании”.

Забавное видео получилось:

Спасибо за видео докладчикам второй части события: Катерине Синдяковой и Инне Кравченко.

Также доступны презентации на русском и английском языках.

Отдельное спасибо компании Materialise, которая дала мне возможность проделать то, о чем была презентация, и без которой мне бы не было чем делиться с коллегами.

Уточнения

По ходу презентации я не всегда точно отвечал на вопросы из сала, поэтому здесь добавляю комментарии, которые поясняют и уточняют мои ответы.

C HR нужно общаться лично, потому что вопросы новых людей очень важны. Но с другой стороны никакого продвижения, блогов и т.д. не надо, потому что это небольшая аудитория.

NDA внутри компании есть, особенно если это касается данных пользователей. Но нашу команду это редко касалось, поэтому ответ на вопрос мог показаться странным.

Как сделать так чтобы люди подписывались на рассылку? Обычно в компании доступно мало информации, особенно понятной для людей со стороны, поэтому людям в целом интересно. А вы предлагаете другим информацию, причем объясняете, что таким образом вы вместе можете достичь лучших результатов.

Иногда попадались не интересные проекты, но очень нужные. В целом я пытался такие случаи минимизировать. Но по моему опыту часто проект не интересен не сам по себе, а потому, что не понятно, для чего он, мало обратной связи и непонимание проблем, с которыми сталкивается разработчик, нечеткие требования и т.д.

Различие между публикациями и Release Notes можно описать так: публикация может появиться еще до Release Notes, может идти разговор также о некоторых специфических случаях использования, сравнении фич и т.д. С другой стороны в публикациях некоторые очень специфические фичи, которые используются малым количеством пользователей, лучше не использовать.

Очень часто пользователи используют продукт не так, как мы предполагали. Нужно побольше узнавать о таких кейсах. Это источник новых проектов. Это очень для тех разработчиков, кто с этим столкнулся первый раз – тем, кто этого не делал, обязательно стоит пообщаться с конечными пользователями.

Делегировать деятельность по продвижению команды легче человеку Quality Assurance, чем разработчику, потому что у него и так больше общения и он видит продукт снаружи, а не его внутренности – то, что, по большому счету, нужно показывать снаружи команды.

Был вопрос касательно укорочение цепочек общения и субординации. Основной момент здесь следующий – все нужно делать постепенно, с согласием вовлеченных людей. Если это будет приводить к положительным результатам, все будут “за”. Как я уже говорил на презентации, язык общения от пользователя к разработчику меняется. И изучать его желательно постепенно.

P.S. Собираюсь послушать 22 сентября выступление Василия Кривоноса на следующий встерече КУЛ ИТ о взаимодействии PM c заказчиками. Чуть меньше года назад он уже представлял доклад о зарплатах.

Share

Leave a Reply

Your email address will not be published. Required fields are marked *