IT-менеджером сразу, как правило, не становятся. Чаще всего вырастают из рядовых сотрудников. Главное – придя на новую должность, ни минуты не забывать, что ИТ-менеджмент – в первую очередь это «менеджмент». Когда из системного администратора вдруг становишься начальником, оказывается, что тебе не хватает многих навыков. Я достаточно часто встречаю выращенных из рядовых сотрудников начальников отделов в рамках моей работы. Они прекрасные профессионалы своего дела, замечательно разбираются во многих ИТ-технологиях. Но получается так, что, заняв новую должность, они зацикливаются на технологиях, иногда уделяют много времени процессам в ИТ-отделе и фирме в целом. Но самое страшное, что чаще всего они не умеют общаться с людьми, не понимают их. А порой даже боятся. Это влечет за собой сложности в коммуникациях как между начальником и подчиненными, так и просто между рядовыми сотрудниками внутри отдела. Нередки случаи, когда сотрудники делают параллельно одно и то же, и хорошо, если они своими действиями не мешают друг другу, а только неэффективно растрачивают время. Слова «инициативность» и «ответственность» сотрудниками отгоняются, словно назойливые мухи.

Обидно, что при таком подходе для ИТ-отдела отсутствует не только стратегическое мышление, но и даже тактическое. И каждый день превращается в череду непредсказуемости и «залатывание» по-скорому дыр. Видение будущего для ИТ-инфраструктуры лежит только в голове начальника, где-то далеко и очень смутно. Совещания собираются без повода, чаще спонтанно. Чаще всего решения толком не принимаются, нет четкого списка ответственных за выполнение задач, к четким срокам задача не привязывает. Ничего удивительно, что все потихоньку идет «вкривь и вкось». Отдел как бы существует, заявки пользователей вроде закрываются, но эффективность отдела как бизнес-единицы оставляет желать лучшего. И неудивительно, что «бизнес» на проекты денег не выделяет, лояльность к отделу со стороны окружающих отделов оставляет желать лучшего, а мотивация сотрудников ИТ-отдела не приводит к желанию креативно мыслить, и все задачи выполняются ровно на зарплату, и присутствует высокая текучесть кадров. Это неудивительно, ведь сотрудника как личность не ценят. Многие нововведения начальника подчиненными воспринимаются в штыки и скрытно саботируются, что приводит к невозможности качественно осуществить проекты. И начальник, в конце концов, деградирует до надзирателя с бамбуковой палкой в руках.

Сам термин «руководитель» и возник от слов «рукой» и «водить», но это совершенно не обозначает, что речь идет о человеке, который стоит на возвышении и делает пасы руками. Это тот человек, который ежедневно ведет за руку по тернистому пути своих подчиненных. Его слова – не пустое сотрясание воздуха. Он сам и его подчиненные осведомлены о целях отдела на ближайший год, есть четкое понимание зон ответственности, существует качественная подмена среди сотрудников в случае отсутствия. Насколько возможно, ведется достаточная и структурированная документация. Все спорные и сложные моменты мудро и однозначно решаются, основываясь на адекватном анализе. Такое представление может показаться совершенно фантастичным. Но если изначально создать внутри отдела нормальную рабочую атмосферу, приправить все выращиванием эффектно-ориентированной ИТ-культуры и следовать «заклинаниям», тогда ваше соответствие термину «руководитель» возникнет само собой.

Прежде всего необходимо усвоить для себя формулу, что «руководитель – это власть».

Любая руководящая должность предоставляет определенный объем власти. Главное – понимать ее возможности, границы и уметь отстоять посягательства на выделенный вам объем власти. Власть – это возможность распоряжаться ресурсами по своему усмотрению, так, чтобы был достигнут ожидаемый результат. Абсорбируя всю власть только у себя, получаете лишнюю нагрузку и авторитарное, ручное управление подразделением. В такой ситуации вряд ли можно ожидать инициативности, оптимизации при решении задач, самостоятельно потушенных «пожаров» из возникших проблем с серверами и сервисами. Сама по себе власть полагается на ограниченность информации в своих действиях. Информация – это ресурс власти, и им нужно уметь рационально распоряжаться. Чем больше необходимой информации вы откроете вашим коллегам, тем более упрочните свою власть среди подчиненных. Ведь если делишься своей властью, тем увеличиваешь ее объем. Чуть выше я сказал, что власть надо защищать от посягательств, когда, например, руководители соседних отделов посягают на время ваших подчиненных напрямую или когда в обход вас пытаются решать ключевые задачи, не удосужившись послушать вашего мнения. Еще когда вышестоящий начальник напрямую контактирует с вашими прямыми подчиненными и его задачи идут вразрез с вашими. Самое время вступать в бой и вспоминать средневековую поговорку «Вассал моего вассала – не мой вассал».

Продолжайте требовать, чтобы подчиненные действовали строго в рамках регламентов и ваших распоряжений. Отстаивайте свою позицию и защищайте подчиненных, которые что-либо сделали, опираясь на ваши указания и внутренние документы компании. Необходимо каждый день доносить до сведения сотрудников, что заполнение заявок и соблюдение регламентов – один из способов поддержания порядка. Разумеется, в компаниях есть список VIP-сотрудников, чьи запросы имеют более приоритетное значение, но, как правило, нет четкого списка заявок, для исполнения которых можно отступить от выработанной схемы выполнения запроса VIP-пользователя. Возможно, и нет смысла создавать такой список, потому что он, скорее всего, не сможет покрыть все различные факторы, когда можно отступить от установленного в обычной ситуации алгоритма. Поэтому остается только доносить до сведения подчиненных информацию, что маршруты в системах документооборота, учета заявок (как и действия приказов генерального директора, различные регламенты, корпоративный кодекс и прочие внутренние документы) распространяются на всех сотрудников компании без исключения с первых минут работы.

Это и есть границы вашей власти, в которую вторгаются другие, жаждущие ее уменьшить или же дискредитировать.

Если вы не можете свободно управлять зарплатами подчиненных в рамках оговоренного бюджета, не имеете права нанять и уволить сотрудника, действительно по своей воле, поощрить, так как считаете нужным, то объем вашей власти сильно ограничен, что, в свою очередь, ограничивает ваши возможности по управлению вверенным персоналом департамента. В условиях власти, ограниченной внешними факторами, придется использовать в основном обаяние, авторитет и умение договариваться, быть готовым, что подчиненные просто пошлют «куда подальше» и завалят проект.

Вначале старайтесь придерживаться правила «Карабкаться на крутые склоны необходимо в медленном темпе» (В. Шекспир). Принимая на работу или повышая в должности, от нас, как правило, начальство ожидает, что во время испытательного срока мы сможем проявить себя, выполнив какой-нибудь сложный и значимый проект. И еще, как правило, общее состояние ИТ-инфраструктуры, после беглого анализа первых дней на новом месте, производит на нас удручающее впечатление. В результате у нас, как никогда, чешутся руки все поменять или заняться сложным и важным проектом. И мы готовы, резко дернув штурвал, стать на курс кардинальных перемен. Но ведь нет! Спустя совсем небольшое время придется идти на ковер к начальству с отчетом. И нужно будет докладывать, что такого хорошего и правильного вы сделали за испытательный срок. И может оказаться, что сильно хвалиться нечем. Да и столь резкие перемены вряд ли принесли много союзников в ваши ряды. Весь наш проект еще покрыт защитной сеткой и лесами, и реальных результатов не видно. А недовольные пользователи уже успели нажаловаться на вас. Успехов никто не видит и не помнит, а ошибки и сбои помнятся долго и всплывают из памяти в самый неподходящий момент. Придя на новое место, в первую очень надо понять, с кем из подчиненных предстоит работать. А не какие есть железки, сети и коммуникации. Помните, что большой растянутый проект не позволяет продемонстрировать полноценно функциональность до его завершения. Не пытайтесь делать его очень быстро, чтобы уложиться в испытательный срок. Даже если основной задачей, поставленной для него, и был этот самый большой и сложный проект. Нет смысла добиться его завершения любой ценой.

Управление ресурсами начинается через людей, они исполняют поручения, отчитываются. Неплохо на этом этапе ознакомиться с резюме каждого из сотрудников, понять их ключевые навыки. А в проектах используйте вначале принцип маленьких побед и красивых показателей. Сложные и большие проекты делите на небольшие задачи и этапы. Тогда будет возможность по завершении этапа отчитаться перед начальством, демонстрируя вашу методичность и результативность, и избежать впоследствии ошибок и злой критики.

Мне кажется, что лучше четко и обстоятельно, по все правилам завершить несколько этапов проекта. Получить по их результатам цифры и их демонстрировать начальству. В том числе появятся и важные данные – это требуемое время на завершение проекта. Такая необоснованная гонка требует излишнего напряжения, постоянная работа в состоянии цейтнота приводит к потере внимания и ошибкам. Ошибки же сейчас для нас очень и очень нежелательны. Зная такие положения, не обещайте начальству при приеме на работу или повышении осуществить сложный проект в кратчайшие сроки. Лучше сразу раздробить на этапы и показать, какие этапы можно успеть осуществить за указанное время. Ну и сами же старайтесь избегать резких рывков штурвалом.

На начальном этапе самым лучшим KPI (Key Perfomance Indicator – ключевой показатель эффективности) будет хорошее отношение к службе ИТ от руководства компании. Потом, когда более-менее освоитесь, сможете понимать установленные предшественником показатели и ввести новые, чтобы корректно управлять подразделением и быть готовым отчитываться по возникающим у руководства вопросам.

Не менее важным для дальнейшего развития вашего успеха в выбранных проектах является искренняя поддержка сторонников. Еще в XIX веке в театральной сфере появилось движение клакеров, которых нанимали, чтобы создать успех постановке. Они громко аплодировали за деньги и в конце спектакля кричали «Браво» и «Бис», вовлекая в этот процесс все больше обычных рядовых зрителей, которые, используя эффект социального доказательства, подключались к проплаченным клакерам. Так и в наших с вами проектах, надо завоевать нескольких сторонников, а если это будут добровольные сторонники, это двойной успех. Такой ИТ-евангелист с горящими глазами будет вместе с вами завлекать все больше сторонников в процесс, создавая результативное движение, направленное на достижение результата для проекта или изменение бизнес-процесса.

Мыслите, как рыцарь у стен крепости. Однажды летом, путешествуя по Воронежской области, мы семьей заехали в поселок Дивно-горье, где на вершине горы на берегу Дона расположены развалины древней Маяцкой крепости IX–X вв. У нас зашла речь о ее неприступности. Крепость-то на горе, отвесные стены вокруг, видимость в каждую сторону километров по 30, и это с развалин, стены-то не сохранились. И одним из способов захватить ее был предложен вариант окружить и просто несколько месяцев сидеть и ждать. На что я контр-аргументировал, что надо просто подкупить охранников ворот крепости. Дать им столько золота, как несколько месячных зарплат небольшого или даже большого отряда солдат. Все зависит от жадности полководца и текущей цены золота. Это окажется очень выгодным. Если держать солдат несколько месяцев в осаде крепости и ждать, когда же защитники сдадутся, придется их все это время кормить, поить и развлекать, а еще платить зарплату. И не факт, что удастся компенсировать затраты грабежом внутри крепости. ROI получалось сильно отрицательным. А вот затрата в виде взятки могла бы решить проблему, и тогда вложения на такой проект захватом крепости, может быть, и не окупятся, но все равно это оказалось бы дешевле, чем проект «Осада». Так и в наших проектах, ищите свои «взятки» охранникам крепостей под названием «Уж так у нас исторически сложилось» и «А оно нам надо?». Мы ведь ИТ-рыцари. Не будем сводить все к деньгам, ведь мы умеем действовать более гибко. Взяткой может оказаться книжка в подарок, где автор разделяет ваши мировоззрения и призывает к тому же, что и вы. Если вам нужна поддержка по внедрению какого-либо продукта или технологии, поход сотрудника на семинар, посвященный этой теме, может более результативно вовлечь сотрудника в ваши ряды, чем месяцы споров и доказательств на совещаниях, что это всем нужно. Главное – выбрать цель, кого подкупаем, какой результат от «подкупа» мы ожидаем. Наша цель – получить открытые ворота. Как в примере с крепостью – подкупить можно охрану, подкупить можно и военачальников, чтобы они активно «пропиарили» идею сдаться подошедшим к крепостным стенам войскам.

Еще хочу порекомендовать – не переливайте «пустое» в «порожнее». Вводите в боевую ИТ-инфраструктуру временные или случайно освободившееся серверы и оборудование только в крайнем случае и при наличии веской причины. Серверы могут забрать в любой момент для осуществления проектов других отделов, они могут даже оказаться не предназначены для нашего отдела. А там могут работать боевые системы, которые остановить для переноса может быть очень даже не просто. Поэтому такие действия – пустая трата людских и временных ресурсов.

Старайтесь, чтобы вы своими действиями не создавали ситуаций переливания «пустого» в «порожнее». Прежде чем давать команду на осуществление перемещения виртуальных машин, серверов, переездов с одного оборудования на другое, посмотрите, как ваши действия вписываются в общий план. Не нужно ли будет все переделывать и переносить обратно, потому что вы чего-то не учли. «Семь раз отмерь, один раз отрежь». Я не перестаю повторять, что все решения должны быть взвешены и продуманы, укладываться в общий план.

Прежде чем что-либо осуществить, всегда задавайте себе вопрос: Насколько это будет эффективно? Сколько ресурсов потребуется? Какой экономический эффект для компании потребуется? Приведите ответы к общему денежному знаменателю. И если эффект очевиден и реально ощутим – осуществляйте задуманное.

Чтобы быть эффективным начальником для бывшего системного администратора, нужно навсегда отказаться от своего старого, приземистого мышления уровней RAID, версий ОС и пакетов обновлений. Одной из задач будет роль переводчика, доносящего задачи на языке бизнеса, которые придется оформить в технические термины и назначить ответственных среди своих подчиненных. «Бизнесу» важны показатели эффективности, он мыслит цифрами затрат, экономии и прибыли. На начальном этапе пробуйте следовать «заклинаниям» и «мантрам», сначала слепо, потом более осознанно, отсеивая те, что не нашли применения в вашей среде.

Пытаясь понять, какая вам досталась ИТ-инфраструктура, начните с аудита. Билл Хьюлетт (основатель «Хьюлетт-Паккард») говорил: «Вы не можете управлять тем, что невозможно измерить». Ежедневное понимание текущих количественных характеристик ИТ-структуры предприятия и построенные на их основе KPI позволяют оценивать текущее положение и планировать варианты трансформации в будущем.

А что, если подойти к исследованию пока неизвестного вам предприятия как захвату территории в стратегической игре? Сначала ИТ-составляющая словно закрыта «туманом войны». Бессмысленно начинать точечные удары, не видя, куда они попадут. Данные в игре мы будем собирать постепенно, высылая разведчиков, и, найдя что-либо, представляющее интерес, будем исследовать интересное место, открыв его настолько, чтобы было понятно, какие ресурсы тут есть и откуда ожидать нападения врага. После этого обязательно примем меры, для того чтобы ресурсы оказались в безопасности. Так же и ИТ. Исследование сети рекомендую проводить, придерживаясь принципа «извне внутрь», на такую глубину детализации, которая необходима по каждому из конкретных вопросов. Последовательность похожа на методологию изображения бизнес-процессов – IDEF0, когда каждый из слоев еще более детализирует каждый элемент. При таком подходе сразу видно, где требуется детализация, а где уже достаточно информации и нет нужды тратить время и средства для сбора ненужных данных. Осознав проблемные места, к ним можно применить обычные средства отказоустойчивости и бекапирования.

Главное – помнить: основная задача любого аудита – дать информацию, которая продемонстрирует вам общую картину исследуемого объекта и позволит ее использовать для принятия решений в рамках управления.

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

Важно получить картину повседневных бизнес-транзакций, которые осуществляются в организации. Это поможет выявить критические службы для бизнеса, остановка которых недопустима. Специфика повседневной работы в ИТ не позволяет нам тратить время на сбор и обработку данных, которые не будут впоследствии нести полезной нагрузки. Так что аккуратно подходите к выбору критериев для аудита. Чаще всего, исследуя предприятие, мы ищем ответы на вопросы «где…», «сколько…», «почему…», «куда…». Количественные характеристики, ролевое и функциональное разделение объектов при аудите (сотрудников, компьютеры, серверы) позволяют более эффективно видеть протекающие бизнес-процессы компании, выявлять проблемные места и использовать результаты аудита во время исполнения служебных обязанностей.

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

Полезным для решения сложных задач может оказаться принцип мозгового штурма. Выделите 10 минут на него, запишите идеи, кратко проранжируйте. Рекомендую более подробно про мозговой штурм и визуализацию идей почитать у Сергея Бехтерева в книге «Майнд-менеджмент: решение бизнес-задач с помощью интеллект-карт». Вопросу визуализации я посвятил целую главу этой книги.

Для упрощения можете считать, что если по результатам вашего совещания или «летучки» не было сформировано ни схемы, ни документа или протокола, то время потрачено зря. Что это прямые убытки для вас и компании. Все принятые решения на таком совещании, по «закону Мерфи», скорее всего, будут выполнены неверно. Можете просто посчитать время, потраченное на собрание, умножить на количество сотрудников, участвующих в нем, и их среднюю зарплату. Вы получите средний размер прямых убытков, которые только что принесли вашей компании таким неэффективным собранием. А еще можно прикинуть косвенные убытки от переделок, недоделок, которые совершили сотрудники, по-своему истолковавшие результаты собрания. Также можно добавить стоимость дополнительных совещаний, которые придется проводить, чтобы выправить ситуацию, и может оказаться, что суммарная эффективность отдела, выраженная в денежных единицах, просто катастрофическая.

Перед совещанием надо дать возможность подчиненным заблаговременно ознакомиться с материалами, которые будут обсуждаться на собрании. Перед собранием разошлите ссылки или документы вместе с приглашением на собрание. Никогда не требуйте к совещанию рассмотреть «фантастические» способы решения. Только конкретику, только реально возможные и работающие варианты. Надо сразу определить цель совещания и что должно быть получено в качестве итога совещания. И в процессе строго придерживаться этой цели, не позволяя перейти деловому совещанию в пространное обсуждение.

По результатам совещания обсуждаемые задачи должны быть разбиты на составляющие, обязательно должны быть назначены ответственные лица за каждый этап, с учетом рисков назначены сроки, по необходимости выделен бюджет времени, человеческих и финансовых ресурсов. Насколько возможно, четко проговорены сложные моменты. А те места, где возможно двойственное толкование, должны быть обязательно прописаны в «протоколе».

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

Подобное собрание, только в других терминах, проводится и для «бизнеса», который является основным заказчиком для нашего ИТ-отдела. Тут не надо углубляться в подробности построения сети, требуемого аппаратного обеспечения, нужно показывать цифры улучшения, экономии, оптимизации. Если вы планируете заводить речь о бюджете, обязательно указывайте стоимость возможных убытков от простоя организации или медленного выполнения ежедневных обязанностей пользователями. Пытайтесь все, что можно измерить в денежном эквиваленте, посчитать и определить, какую экономию могут дать фирме планируемые вами изменения. Как часто проводить такие собрания – решайте сами. Но вряд ли будет эффективно, если они будут чаще, чем раз в квартал.

Считается, что внедрять ITIL в организации дорого, сложно и невозможно. Сущая правда скрыта в этих словах. ITIL – «идеальный газ из учебника по физике», некое эфемерное «прекрасное далеко». Но из постулатов книг по ITIL можно взять некоторые очень полезные термины и технологии. Они не требуют денежных вложений, зато улучшают уровень ИТ-культуры внутри отдела, упрощают и стандартизируют внутренние процессы. Благодаря таким внедрениям уменьшается количество того, что необходимо проговаривать каждый раз, ставя задачу подчиненным.

Очень много сложностей для руководителя можно было бы избежать, если вспомнить «волшебные» слова из ITIL: «People, Process, Technology – люди, процессы, технологии». И самое главное, что тут порядок имеет решающее значение. Каждый сотрудник – в первую очередь личность. Он может лениться, может не любить работать по утрам или не умеет писать планы выполняемых работ. Может также оказаться, что подчиненный сильно зацикливается на «перфекционизме», все делает капитально и на века, все время срывая сроки выполнения задачи. Кто-то умеет общаться с пользователями, у него нет неприязни, он не боится в бухгалтерии в сто двадцать пятый раз рассказывать, как напечатать документ из Word. Другому подавай «железки», и никаких людей. Вновь пришедшему начальнику лучше всего создать свою собственную матрицу с указаниями, кто из сотрудников на что годится и что собой представляет в общем. Важно также понять, к чему лежит душа у сотрудника, в чем он себя ищет, что ему интересно изучать. Если удастся совместить желание сотрудника познавать что-нибудь новое, учиться, развиваться с потребностями компании, это сильно замотивирует сотрудника, и его эффективность будет гораздо выше. Такое, к сожалению, возможно не всегда, но начинать отношения с сотрудниками в качестве начальника надо именно с этого. В любом случае, получив подобные данные о своих подчиненных, можно максимально эффективно использовать их как ресурс.

Более знающий и способный сотрудник сможет справиться со сложной и важной задачей быстрее, чем тот, который будет это делать впервые. Скорость и качество выполнения задач отдельными сотрудниками отдела в сумме являются индикатором эффективности руководителя в лице начальства и пользователей.

Также можно учесть, что если нет спешки, для задач, которые могут превратиться в важные процессы, можно использовать как раз неопытного сотрудника, назначив ему в качестве наставника более опытного. Это будет тот, кто сможет подсказать, как подойти к задаче, где и что почитать, как максимально эффективно ее решить. Такие «тандемы», как показывает практика, оказываются очень эффективными. Неопытный сотрудник приобретает ценный опыт, опытный контролирует выполнение задачи и тоже приобретает опыт. В итоге мы получаем двух сотрудников, способных поддерживать технологию или процесс и способных подменить друг друга.

Поняв текущие навыки своих подчиненных, совместив с грядущими изменениями в ИТ-инфраструктуре, можно начинать планировать процессы обучения и повышения квалификации сотрудников отдела. Обучение бывает внутреннее и внешнее. На внутреннем знающий сотрудник аккумулирует свои знания и проводит обучение для своих коллег. Внешнее обучение проводится сторонним сотрудником и даже вне стен компании. Например, в учебном центре. Одним из важных минусов обучения является то, что оно может обходиться недешево для компании. Дополнительную эффективность от внешнего обучения разве что можно извлечь, если знания, полученные вне стен организации, удастся еще озвучить для внутренних нужд в рамках семинаров или докладов для сотрудников отдела.

Чаще всего мы думаем об обучении сотрудников отделов, но совсем забываем, что знающий пользователь поможет уменьшить количество инцидентов и принести больше пользы компании, понимая, как эффективно использовать свои компьютерные знания для своей работы. Также это один из способов увеличить лояльность к ИТ-отделу как от руководства, так и от пользователей. Поэтому если есть возможность, обязательно учите своих пользователей эффективнее работать в офисных и бизнес-приложениях. Проводите семинары, рассылайте небольшие письма, раскрывающие тонкости работы в приложениях, наиболее часто используемые клавиатурные комбинации. Главное тут – не перестараться, чтобы ваша рассылка не превратилась в распространение многостраничных мануалов, которые никто читать не будет.

Учитесь сами, но больше упор делайте на управленческую тематику. Отложите пока книги и мануалы, посвященные настройке Exchange Server или MS SQL. Теперь пусть упор на них делают ваши подчиненные. Вашей темой должны стать книги и статьи, которые посвящены вопросам управления персоналом и проектами в сфере ИТ, бюджетирования и экономики, психологии и вопросам коммуникации.

Понимая, как эффективно можно использовать человеческий ресурс в рамках работы отдела, можно выстраивать сначала внутренние процессы, затем переходить к внешним. Будет непросто, так как придется ломать текущие устои, которые, как правило, далеки от эффективности. Но они так вошли в привычку, что все верят, что это лучшее, что может быть.

Работа в любой сфере – это хождение по минному полю. И не у каждого из них есть карта. Под картой я подразумеваю четко выясненный алгоритм действий и четко определенные штрафные санкции за их невыполнение. Некоторые руководители выпускают на такие поля своих подчиненных и, потирая руки, ждут, когда они подорвутся, бросаются их «гнобить». Словно основная задача такого руководителя – «самовыразиться» за счет ошибки своих соратников. Но ведь это неправильно. Почему же важно никогда не ругать и не штрафовать подчиненных за ошибку, совершенную без карты минного поля? Я вижу три основные причины:

1. Руководитель выглядит глупо в глазах подчиненных, это не способ повысить свой авторитет.

2. Проблема не решена, на это поле в следующий раз зайдет другой или повторно подорвется тот же сотрудник.

3. Есть другой, более правильный путь решить эту проблему.

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

Какие часто возникающие «ошибки» существуют?

• Не знал, как пошагово должен выполняться процесс.

• Забыл по самонадеянности, какие действия на каком этапе нужно выполнить.

• Не знал, что нужно его, меня, того парня информировать о ходе действий или получении результатов.

• Забыл передать какие-либо ключевые данные для решения вопроса.

• Выполнил, но не проконтролировал достижение результата или не получил подтверждения заказчика, что его запрос выполнен корректно.

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

Жизненный пример. С легкой подачи директора департамента ИТ в СЭД появился новый маршрут. Новая кнопка, которая уже сразу видна всем пользователям. Но в течение полутора месяцев данный механизм не работает, нет заявок, движений. Может, потребности в этом действии нет? Есть, конечно, но все решается по старинке, в обход, потому что:

• никто про него не знает;

• официальных новостей о введении данного типа заявок не было;

• в самом маршруте отсутствует описание, при каких условиях надо создавать заявку и куда она попадет.

Увидев такую кнопку, первые мысли, которые пришли в голову, я не держал при себе и сразу оформил письмом автору идеи:

«Когда и как заработает в СЭД новая заявка? Какие условия для ее инициализации? Кто должен это формировать?»

На мой запрос и вопросы был получен ответ:

«Данный маршрут РАБОТАЕТ больше месяца».

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

Для того чтобы создать карту такого «минного» поля, требуется проанализировать корректную последовательность действий. Кто на каком этапе должен выполнять определенные действия, когда и каким способом должен информировать и передавать.

Иллюстрируя такое утверждение, я бы хотел привести пример.

В достаточно сложный процесс подготовки рабочего места для нового сотрудника вовлечены сотрудники нескольких подразделений. Сотрудники HR формируют заявку на выход сотрудника, сообщают место, где он будет сидеть. Дальше сотрудниками, ответственными за логины и пароли, создается учетная запись, и в ней заполняются необходимые поля, после в другом подразделении подготавливается рабочее место и заранее устанавливается. В двух предложениях процесс выглядит просто, но по закону Мерфи, когда сотрудник, не часто выполняющий процесс создания «учетной записи», не передал информацию дальше, процесс на нем сломался. Цена такой «ошибки» – вовремя не установленный компьютер на рабочем месте, а значит, услуга выполнена некачественно.

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

А можно взглянуть вглубь проблемы и понять, что процесс существовал до этого момента «по понятиям» и устной договоренности, что сохранять такое состояние дел крайне рискованно и имеет смыл создать карту. Такая схема преследует две основные цели – показывает правильный проход среди мин и позволяет видеть, в каком месте произошел подрыв и кто виноват.

Для пошагового описания вашего процесса вы можете использовать бесплатное приложение BizAgi Process Modeler, созданное для визуализации бизнес-процессов и процессной документации. Приложение Modeler позволяет визуализировать диаграммы и модели бизнес-процессов по стандарту BPMN, который, в свою очередь, является международным стандартом для моделирования бизнес-процессов.

После того как карта создана, обязательно нужно довести ее до сведения сотрудников. Расшифровать легенду (что какой знак обозначает) и почему именно так устроен процесс. Последний этап – убедиться, что сотрудникам их роли понятны, средства взаимодействия между собой оговорены. Можно взять на вооружение армейский принцип пошагового прогона по карте. Когда каждый из подчиненных будет рассказывать, что он делает на этом этапе, как переходит на другой или передает необходимые данные другим участникам по схеме.

На что важно обратить внимание для внутренних процессов:

• Регламентируйте рутинные операции, вводите «чек-листы». Например, заведением пользователей и распределением прав во всех системах занимается только один сотрудник. Нужно будет создать некий «чек-лист», как при проверке самолета перед взлетом. В нем указать, в зависимости от роли пользователя, в каких системах и в каких группах, с какими правами на файловые ресурсы должен быть заведен пользователь. Включите в такой список проверки, насколько корректно применились права, все ли настроено верно. И только после проверки, что все корректно, отдавайте учетные записи для пользования новому сотруднику. Такие «чек-листы» позволят избежать ситуации, что кого-нибудь забыли завести в важную систему, или прав на файловые ресурсы выдано больше, чем положено. Также позволит избежать вольнодумства и лишних запросов. Ну и главное – сможет улучшить рейтинг отдела в глазах руководства и заказчиков, так как не будет жалоб на нас, что мы что-то забыли или сделали неправильно.

• Используйте одинаковые приемы документирования и информирования. Оговорите с подчиненными одинаковые методы ведения документации, комментирования строк кода. Выработайте свой собственный формат информирования о внесенных изменениях в ИТ-инфраструктуру. Следите, чтобы такие договоренности выполнялись. Не удивляйтесь, что людям свойственно забывать, просто напоминайте по мере, когда забывчивость и лень подчиненных выходят за рамки.

• Пресекайте попытки выполнить заявки «из-под полы». Все заявки пользователей должны быть зафиксированы в систему учета заявок. Это позволит отследить, кто из подчиненных чем занимался или занимается в любой из моментов времени, какие решения были приняты. Фиксировать можно и постфактум. Глупо отсылать просителя с простой задачей и заставлять писать письмо, или тратить время на запись в систему. Проще сначала выполнить, а только потом вернуться на рабочее место и все записать.

• «Не выносите сор из избы». В случае возникновения спорной или конфликтной ситуации между сотрудником ИТ-отдела и пользователем в первую очередь удовлетворить любой ценой пользователя, а не заниматься выяснением отношений. Для пользователей и начальства ИТ-отдел должен выглядеть слаженной эффективной бизнес-единицей, всегда готовой прийти на помощь, выполняющей поставленные задачи как единый механизм, четко и без ошибок. Любой открытый конфликт сильно бьет по репутации отдела. Все конфликты должны решаться внутри отдела, нужно последовательно разобрать сложившуюся ситуацию на внутреннем собрании.

• Культивируйте отказоустойчивость человеческих ресурсов. Старайтесь не допускать ситуаций, когда уходит в отпуск или увольняется сотрудник, который единственный, кто может поддерживать что-нибудь в нашей инфраструктуре. Так же плохо, если бывает ситуация, когда знания о поддерживаемой системе надо передать за 1–2 дня. Эффективность такого «обучения», особенно если в это время все время отвлекают на выполнение ежедневных обязанностей, будет близка к нулевой. Если же заранее сформировать пары ведущий – ведомый. В такой связке ведущий постоянно будет передавать свои знания, умения и изменения в поддерживаемой системе ведомому. Тогда всегда сотрудники будут готовы подменить друг друга. Уходы в отпуск, болезни или увольнения будут происходить менее болезненно.

Рис. 3.1. Простая таблица человек – задачи позволяет увидеть незарезервированные области и ключевые обязанности всех сотрудников

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

Для лучшего понимания, как к нам относятся наши же заказчики, можно использовать метод опросов. От самого простого диалога в коридоре до обычной или электронной анкеты с несколькими вопросами. Важно помнить при таком анкетировании, что все мы люди и вряд ли кто-то будет отвечать больше чем на 5 вопросов искренне и честно. Пусть будет две разнесенные по времени анкеты, чем одна большая, которую заполнят «абы как», совершенно не показывающая адекватную картину. Но результаты такого анкетирования позволят получше посмотреть, как воспринимается ИТ-отдел в глазах пользователей. Также результаты разных анкетирований можно использовать в целях результирующей отчетности для своего руководства, выявления трендов и для направления подчиненных.

Еще полезно, как одно из средств мотивации, собирать отзывы о сотрудниках отдела от пользователей, вводить голосования и награды лучшим сотрудникам месяца.

Вот теперь, после того как мы смогли разобраться в подчиненных и удалось более эффективно построить процессы внутри отдела и во взаимоотношениях с внешними заказчиками, мы дошли до технологий. Вот тут наступает время, когда можно выбирать, кто, когда и на какие системы будет ставить обновления. Теперь можно выбрать, какую систему учета заявок или резервного копирования устанавливать и использовать, какое сетевое оборудование покупать и внедрять. Если мы бы начали с этого, скорее всего, мы бы столкнулись с тем, что дорогостоящие системы работают неэффективно. Тот функционал, который должен был быть самым востребованным в глазах начальника отдела, совсем не используется, а подчиненные все делают «по старинке». Сам процесс внедрения буксовал бы и саботировался.

Многие мои коллеги считают: раз уж ты начальник, значит, ты всегда должен быть прав. И если твои подчиненные пишут тебе письмо, в котором критикуют твои действия или твою оценку, нужно обязательно жестко и четко в ответном письме поставить зарвавшегося подчиненного на свое место. Но когда, остыв, перечитываешь ответное письмо, можно увидеть, что не все так правильно, как ты считал еще несколько минут назад. Привычка для всех входящих писем пользоваться кнопкой «Ответить всем» могла добавить к получателям гневного письма лишних наблюдателей для вашего конфликта. Ну и уже дело чести для подчиненного отстаивать свою позицию. В результате рождается достаточно большое количество усиливающих конфликт писем, за которыми с интересом наблюдают в лучшем случае в своем отделе другие сотрудники, а что еще хуже, и из соседних отделов. Преобразование конфликта в «цирк» не добавляет эффективности работе отдела и является неоправданной тратой времени.

Для хорошего руководителя распознать такой конфликт в зародыше и перенести его для последовательного разбора с глазу на глаз с подчиненным очень важно как для собственной репутации, так и для общей репутации отдела. Если нет возможности устроить совещание без лишних свидетелей из-за большого расстояния, лучше всего, если у телефонного звонка будет как можно меньше лишних ушей с обоих концов. Звонок можно совершить из переговорной, например, на сотовый телефон, чтобы собеседник мог выйти в другое помещение. В личном общении в первую очередь ищите причину, почему возник конфликт. Для этого постарайтесь разобрать, где и когда было допущено нарушение, повлекшее за собой череду неправильных действий, в результате выросшее в конфликт. Всегда старайтесь исходить из позиции, что причина конфликта – случайное стечение обстоятельств, вызванных несовершенством процессов, выполняющихся в нашем отделе. Обязательно выслушайте позицию оппонента, старайтесь его не перебивать, дайте выговориться. Одной из важных задач разрешения конфликта важно понять, как исправить текущее состояние и как не допустить повторений. Выяснение, кто виноват и кто более прав в данной ситуации, может оказаться не так эффективно для разрешения конфликта.

Просто «потушить» конфликт мало, из него обязательно нужно вынести «уроки». Это может быть инструкция, рекомендация или даже новый процесс, чтобы в следующий раз такого недопонимания не было. В письме или документах не нужно указывать имен и фамилий «провинившихся» или породивших данное изменение. Будьте этичными по отношению к подчиненным. Лучше обязательно опишите способы, как действовать в подобных ситуациях, какие критерии важны при принятии решений, какую лучше последовательность действий выбрать. Для эффективного «тушения» конфликта к разработке такого документа привлекайте главного участника конфликта. Любой адекватный сотрудник всегда рад найти способ избегать в будущем конфликтных ситуаций, делать свою работу прозрачнее и не растрачивать ее на бесполезное пререкательство с начальством.