Мой стиль демократический —обсудить, всех выслушать, взвесить все за и против, и сделать так, как я считаю максимально правильным. При этом у меня всегда есть право руководителя не согласиться со своими подчинёнными и принять такое решение, которое будет расходиться с решением команды.
Закончить эту главу хочется пожеланиям читателю выбрать свой стиль – определиться в своём амплуа – обсуждать план или не обсуждать, и при этом всегда действовать аккуратно. Спасибо.
Глава 10. Давайте полную картину и не тяните с решением вопроса.
Давайте полную картину с причинами, чтобы не получилось, что вы сами тянете с решением вопроса.
Здесь всё просто, и кажется, что и рассказывать-то нечего – тем не менее эта тема богата деталями.
Есть ответственность двух сторон – это заказчик и исполнитель. На этом принципе, точнее условии, держатся и строятся все договорные отношения.
В любом договоре вы найдёте и заказчика, и исполнителя, и у каждого есть свои ответственности и обязанности. Исполнитель должен исполнять\делать. Заказчик должен оплачивать и не препятствовать решению вопросов. Есть также и внеконтрактная деятельность, когда в контракте написано одно, а по факту выполняются другие больше или меньше, в зависимости от личных договорённостей и отношений, действия.
Ну, допустим – в контракте написано, что вы должны\обязаны помогать заказчику с 09:00 до 18:00.
И вдруг, совсем неожиданно, авария происходит в то время, которое не описано в договоре. Вам звонит заказчик, сообщает о проблеме и просит помочь и подключиться к решению вопроса, несмотря на то, что вопрос вне рамок подписанного договора.
И вот, вы как ответственный исполнитель, честный человек ну и просто эмпат, подключаете всю свою команду и решаете \ устраняете проблему.
Миссия выполнена, вы благодарите команду, прощаетесь с заказчиком, и в радостном расположении духа ложитесь спать.
На следующее утро вас будит звонок директора с требованием срочно приступить к подготовке официального ответа на претензию от заказчика о том, что ваша система работает со сбоем, а вы ничего не делаете для решения проблемы.
Не удивляйтесь – это нормальная практика работы для государственных учреждений России. На словах вы всех красавцы, а потом к вам прилетает официальное письмо о том, что система не работала, и просьба дать официальный ответ о случившемся.
Звонить коллеге с другой стороны баррикад в данном случае нецелесообразно, так как вы получите ответ, что лично к вам претензий нет, но руководство требует, и сейчас от вас ждут официальное письмо с причинами произошедшего.
Ситуация уже не аварийная, у вас есть другие проекты, вы не многорукий Шива, ответ готовится, но уже не на первом уровне приоритета – это не авария.
Вот так делать нельзя – это и называется затягивание конфликта \ ситуации.
Правильный сценарий – это когда у вас уже есть полное описание ситуации и подготовлена рыба \ шаблон ответа на претензию. Вы максимально оперативно даёте ответ на претензию заказчика. Скорость здесь является основополагающей успеха. А вот для того, чтобы эту скорость заработать, у вас должны уже быть готовы детали для ответа. Детали для ответа – это хронология событий, произошедших намедни. Всё должно быть законспектировано в хронологическом порядке, что «отвалилось», во сколько «отвалилось», что сделали, во сколько сделали, какой анализ был проведён, во сколько исправили, во сколько ответили, куда отвечали. У вас должна быть набита рука по написанию официальных писем\ответов на претензии. Должен быть подготовлен шаблон ответа на эту и подобные претензии.
Только в таком случае и ни в каком другом – вам никто не скажет, что вы затягиваете решения вопроса или затягивали его на предыдущем этапе.
Особенно это касается официального уровня. Если вам поступил официальный запрос, он должен быть максимально быстро закрыт.
В официальном ответе не обязательно давать полную картину происходящего, достаточно описать шаги, предпринятые меры для исправления, предпринятые меры для неповторения ситуации. Полную картину мира можно отразить в диалоге с директором, например. Имеется в виду со своим директором.
Итого, действуйте оперативно и решительно.
Глава 11. Какая милая аватарка.
Лучший руководитель проектов – это человек, находящийся в русле событий. Лучший руководитель проектов всегда в курсе всех проблем. Если вы лучший руководитель проектов – вы всегда должны быть в теме всех ключевых проблематик. Это не значит, что нужно лезть в дебри, в детали – хотя, безусловно, это наивысший уровень руководства, когда руководитель может ответить на любой вопрос в деталях. Хотя, давайте детализацию оставим для инженеров и специалистов, а сами рассмотрим руководящие компетенции и уровень по их взаимодействию.
Наверно я махнул лишнего, говоря про то, что лучший руководитель проектов должен быть погружен во все детали – это все же неправильно. Правильно быть в курсе проблем на верхнем уровнем решения проблем.
Как быть в курсе всего и не потеряться в проблемах? Раньше использовались ежедневники, еженедельники, блокноты и тетрадки. Позже к ним на смену пришли цифровые календари и планировщики задач.
В своем арсенале у меня множество разнообразных инструментов, обо всех расскажу в этой книге чуть позже. Эта глава про инструмент руководителя, который называется телеграмм.
Правило такое, что для проекта создается внутренний канал коммуникации на уровне топиков. Одна проблема – один топик. Если вы лучший руководитель проектов, то постепенно к одному проекту у вас добавится второй, ко второму третий. Чем выше рисков, тем лучше руководитель проектов, тем больше проектов ему доверяют. И вот тут, для того, чтобы не запутаться, не потеряться во всём этом множестве проектов – помимо их текстовых обозначений\названий Telegram канала, целесообразно ввести и цветовую градацию – например, логотип компании.
В этой книге я не буду упоминать название компаний, да в общем-то это и неважно, все эти компании лидеры российского и мирового рынков. В моей последней компании при внедрении своего руководящего опыта я столкнулся с непониманием того, для чего я это делаю.
– Какая милая аватарка, – написала Алёна, руководитель параллельного подразделения, в моем Telegram канале для внутренней коммуникации.
Я не стал отвечать на этот троллинг и постарался не словом, а делом показать необходимость цветовой или графической идентификации для разных каналов.
Когда каналов у вас много, а скорость реакции высока, человеческий глаз лучше цепляется за картинку, чем за текстовую идентификацию.
И пусть это звучит или выглядит смешно, когда у каналов есть свои милые, оригинальные аватарки, но это важно для быстрого взаимодействия на уровне команды между каналами коммуникаций по проектам. Лаконичное резюме – аватарка для канала – это важно.
Глава 12. Договорённости в командах.
Есть команда внедрения, есть команда технической поддержки, есть команда разработки, есть команда коммерческого департамента – это всё команды одной компании.
Бывает так, что один и тот же вопрос обсуждается в разных ветках коммуникации, что приводит к общему диссонансу в решении основного вопроса заказчика.
Одна команда решает задачу в одном ключе, другая команда в другом, третья – задачу не решает, а ждёт решение от одной или от другой команды.
Для того, чтобы избежать подобных казусов, используется различные коммуникационные инструменты.
Самый распространённый инструмент – это электронная почта. На втором месте —мессенджеры.
Третье место —инструмент разработки типа Jira.
Ну и самый главный инструмент – это голосовая коммуникация – телефон, голосовые инструменты для проведения встреч, очные встречи и переговоры.
Так вот, от договорённостей в командах очень много всего зависит. Коммуникация – это основной залог быстрого, успешного динамичного развития компании с высокой доходностью.