Управление ИТ

Для большинства компаний управление сотрудниками и их мотивация превращаются в нетривиальную задачу. Как выяснилось в ходе исследования, проведенного Oxford Economics, у компаний нет стратегий, которые позволили бы эффективно управлять сотрудниками поколения миллениума. Руководители кадровых служб понимают, как важно уметь управлять все более разнообразным и мобильным персоналом, но им не хватает стратегий и готовых решений.

Ситуацию усложняет явное доминирование в мотивации сотрудников материальных факторов. При этом многие компании действуют во многом интуитивно, «на глазок». Лишь в последнее время у HR-специалистов начали появляться инструменты в виде систем управления человеческим капиталом (Human Capital Management, НСM) и корпоративных порталов, обеспечивающих создание полноценных социальных сетей.

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

Как сошлись во мнении участники дискуссии «Пряники и ИТ-инструменты» на портале Global CIO, без точно определенной и убедительной цели большинство социальных проектов не приносит выгоды бизнесу. Да и нематериальные «вишенки» начинают работать, только когда материальный «торт» более-менее в порядке.

«Я считаю, что применять корпоративные порталы необходимо. При грамотном подходе они очень помогают сделать человека не просто сотрудником, а частью коллектива, команды. Но все это действенно, если дополнять, а не подменять материальную мотивацию», — отметил Илья Козлов, директор по ИТ концерна «Энергомера». Многие крупные вендоры сейчас интегрируют в свои продукты для корпоративных порталов элементы социальных сетей — достаточно посмотреть на новые функции Microsoft SharePoint.

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

Хорошим примером мотивационного подхода стало внедрение социальной сети в компании «Кьези Фармасьютикалс». В качестве коммуникационной среды там используется платформа «Пряники», интегрированная в портал на «1С:Битрикс». В ее рамках используется корпоративная социальная сеть — для проведения опросов и обмена идеями, виртуальная валюта — для вовлечения сотрудников в проявление благодарности друг к другу, значки (беджи) — для популяризации историй успеха сотрудников и т. п.

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

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

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

Scrum: результат в условиях неопределенности

Гибкие (agile) методики реализации ИТ-проектов — иногда, в зависимости от контекста, встречается вариант перевода «скорые» — получают все большее распространение. 84% ИТ-департаментов, опрошенных VersionOne, ответили утвердительно на вопрос, применяют ли они гибкие методики разработки. Среди них 54% заявили об использовании методики Scrum. Более того, компетенции в Scrum, наряду с технологиями in-memory и предсказательной аналитикой, входят в рейтинг наиболее востребованных ИТ-навыков, составленный Foote Partners.

Гибкие методики соответствуют изменившимся требованиям рынка: устранить риски и увеличить скорость разработки, снизить вероятность провала проекта. По данным The Standish Group, число неудач в Scrum-проектах втрое меньше, чем при традиционном подходе, а число успешно законченных проектов вдвое больше.

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

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

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

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

Как отметил Михаил Петров, заместитель директора департамента проектов по информатизации Министерства связи и массовых коммуникаций РФ, в рамках дискуссии «Мы за скрам!» на портале Global CIO, любая методология имеет область адекватного применения. «Scrum подразумевает намного большую квалификацию исполнителя — как с точки зрения управления объемом и ресурсами, бюджетом, рисками, так и в плане управления ожиданиями заказчика, требует вовлечения заказчика в процесс и создания определенного партнерства», — подчеркивает он. «Классически» воспитанный ИТ-менеджер к такому не привык, но для некоторых проектов (когда делать надо в четко определенный срок, но что — до конца не понятно) такая методология становится единственным выходом. Иногда традиционный подход дает вполне приемлемые результаты, но в ситуации, когда среда меняется, Scrum будет все более и более востребован.

«Традиционная методология разработки ПО «водопад» перестала соответствовать требованиям заказчиков. Эти требования меняются настолько динамично, что то видение, которое было в начале проекта, становится кардинально иным к его концу», — констатирует Тагир Яппаров, председатель совета директоров «АйТи». «Водопад» при таком положении дел дает плохие результаты, ведет к неудачам или превышению по бюджетам и срокам. Поэтому начали активно применяться более динамичные методологии, и Scrum стал элементом крупных проектов. Даже у SAP появились методологические изменения, которые отражают видение таких подходов.

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

«В 90-е годы я сам использовал методологию Scrum — правда, не зная об этом: прямой контакт с заказчиком, реализация с его слов, короткие циклы, постоянные презентации», — вспоминает Александр Огнивцев, руководитель управления сервисной поддержки «АльфаСтрахования». Разница в том, что в те годы заказчик, как правило, точно знал, чего хочет, но не знал, что это можно реализовать через ИТ. Теперь заказчик точно знает, что с помощью ИТ реализовать можно все, но не знает, чего хочет. Ситуация неопределенности воспроизвелась: теперь на новом витке и в иной ситуации, — и конечно, гибкие технологии становятся востребованными.

«Мне кажется, что на открытом конкурентном рынке заказчики вряд ли примут решение в пользу Scrum, потому что основной его минус — неясные результаты за непонятный бюджет», — признает Георгий Давыдов, архитектор интеграционных решений R-Style Softlab. — Покупатель, понятное дело, предпочтет определенные сроки и цифры. Из-за этого приходилось даже скрывать свой «внутренний» Scrum от заказчика, хотя сейчас его элементы используются даже на «водопадных» проектах».

Преимущества этой методики управления прямо проистекают из ситуаций, когда ее выгодно применить. Например, заказчик не знает, что ему нужно; говоря более обобщенно — нет технического задания, что позволяет вообще исключить такой обязательный для «водопада» этап. «С одной стороны, экономия налицо, с другой стороны, привязка к партнеру становится катастрофической, да и сам исполнитель «подсаживается» на ключевых сотрудников. Как вы думаете, полетел бы Гагарин в космос, если бы ракету строили по Scrum?» — задается вопросом Давыдов. Другими примерами могут быть ситуации, когда по каким-либо причинам не получается оценить сроки и бюджет проекта, нужны быстрые результаты или когда исполнитель, не зная инструментов, изучает технику и предметную область на ходу. Наконец, возможен вариант, когда команда устала от однообразия и нужно привнести драйва, а текущая эффективность никого не устраивает.

«Как человек, имеющий команды разработчиков в штате и работающий с аутсорсерами, согласен, что по Scrum хорошо работать, когда обладаешь штатной командой, а запросы от подразделений меняются по два раза на день», — говорит Дмитрий Тепляков, ИТ-директор компании «Донбасс Арена». Тогда работа спринтами имеет смысл: заказчику сразу выдается небольшой работающий кусок, а он корректирует направление работ. Если заказчику результат не нравится — потеря времени на переделки небольшая.

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

«Противопоставление фиксированной для реализации задачи («водопад») и нефиксированной (scrum) в корне неверно», — уверен Алексей Лапшин, руководитель проектного сервиса «АйТи». Ни та ни другая методология не отвечают на вопрос, что будет реализовано, а отвечают на вопрос, как будет реализовано и кто для этого нужен. Это как с геометриями Лобачевского и Евклида — вторая является предельным случаем первой. Если установить продолжительность «спринта» во время, отведенное на весь проект, то Scrum превратится в «водопад».

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

«Сама методика «водопада» никаким образом не препятствует внедрению гибких методов разработки», — согласен Борис Позин, технический директор «ЕС-Лизинг». Скорее, ему препятствует модель Fixed Price, которая применяется в большинстве случаев, и в госзаказах прежде всего. Таким образом, не надо путать экономику, менеджмент и технику.

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

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

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

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

Кракен

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

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

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

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

Стригой

Подобно летающему кровососу из Dungeons & Dragons, стригой в одиночку нананосит малозаметный вред — мелкая дрянь, которая вас почти не задерживает. Но рой стригоев — это уже серьезная проблема. Если не передавить их вовремя, ваш проект может оказаться обескровленным.

Обсуждение начинается невинно: у заказчика есть идея, кажущаяся разумной (по крайней мере, в теории), — и вы задаете уточняющий вопрос. Вместо того чтобы ответить, заказчик зовет кого-то на помощь. Этот человек вроде как отвечает на ваш вопрос, но предлагает еще одну идею, слегка противоречащую первой, и вам кажется, что этот конфликт можно устранить.

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

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

Гидра

Клиент-гидра — маленький зловредный кошмар: вы отрезаете одну голову, а на ее месте вырастают две новых. Единственный способ победить — отрубить все головы одновременно.

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

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

Минотавр

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

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

Если именно «Джим» должен поставить подпись под счетом на ваш гонорар, сворачивайте проект, ибо вы обречены.

Дракон

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

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

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

Единорог

Кто бы что ни говорил, но единорог — это настоящий кошмар. Он проявляется в виде идеальной возможности... которая никогда не воплощается в жизнь. Вам описывают соблазнительную перспективу. Теоретически единорога можно обуздать, но чаще всего он, едва появившись, незамедлительно исчезает, и в итоге вы тратите неимоверные усилия, пытаясь выследить и приручить его. А если к нему приблизиться, есть серьезная вероятность напороться на его рог.

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

Идите прочь, здесь вам нечего ловить.

Оборотень

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

Что хуже, когда он возвращается в человеческое обличье, то ничего не помнит и не верит вам — если, конечно, вам вообще удалось выжить. В мире программного обеспечения в оборотней обращаются не только с наступлением полнолуния. Внезапное превращение в отвратительное существо может быть вызвано тем, что вы поставили под сомнение какую-нибудь технологию, являющуюся для него священной коровой, или указали на очевидные недостатки сомнительной бизнес-практики.

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

Сфинкс

Сфинкс осыпает разработчиков и консультантов загадками и пожирает тех, кто отвечает не так, как он хочет (совсем как кадровики претендентов на вакансии в некоторых пафосных технологических компаниях). Загадки могут быть непростыми; на первый взгляд может показаться, что речь идет об обычных бизнес-проблемах, вроде трудовой дисциплины, низкой продуктивности, проблем с качеством и излишней текучкой персонала. Но — «неверный» ответ, и вы искромсаны, причем, как это часто бывает со сфинксами в мире разработки ПО, верного ответа может вообще не быть!

Сфинкса трудно распознать вовремя, но если вы услышали (или случайно подслушали) фразы вроде «это уже третий консультант за год» или «запасайтесь попкорном, у нас новичок», то весьма вероятно, что вас ждет провал по необъяснимым причинам. Со сфинксом лучше договориться об оплате вперед.

Нежить

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

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

Тролль

Тролли таятся в засаде, нежданно выскакивая перед ничего не подозревающей жертвой. Любой, кто заходил в разделы комментариев на сайтах, узнает интернет-тролля из мира ИТ.

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

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

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

Сирена

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

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

Людоед

Заказчики-людоеды имеют неприятную привычку чисто рефлекторно губить идеи и проекты. Они ничего не могут с собой поделать! Аллергия ли это на новые идеи, тайная нацеленность на провал или просто ненависть лично к вам, не имеет значения: с людоедом у вас ничего не получится.

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

Не удивляйтесь, если людоед уволит вас — людоеды обидчивы.

Блуждающий огонек

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

Знакомая ситуация? Вначале такой заказчик напускает туману: противоречивые, неясные требования; множество начальников и подписей; серия запросов, предложения неоплачиваемых или низкооплачиваемых концептуальных проектов. Но вы так и не получаете ни серьезного контракта, ни четко оговоренных целей. Конечный результат — медленная смерть в попытках вырваться из мрачного вязкого болота.

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

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

Франкенштейн

Чудовище Франкенштейна неправильно понимали. Собранное из фрагментов умерших людей, оно пыталось быть хорошим, но у него ничего не выходило.

Чудовище Франкенштейна — это обычно не сам заказчик, а результат взаимодействия с заказчиком, который не ценит согласованные методы, чистый код и грамотно организованные тестирование, рефакторизацию, взаимодействие с пользователем и т. п. В романе Мэри Шелли истинным монстром был сам доктор Франкенштейн, и именно его черт надо остерегаться в заказчике.

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

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

- Steven A. Lowe. 14 nightmare clients — and how to defang them. InfoWorld. Jan 19, 2015

Специалист по PR и автор книг Кевин Аллен, разрабатывавший успешные кампании, в том числе для MasterCard, говорит, что за его тридцатилетнюю карьеру в принципах руководства произошли определенные сдвиги: командно-административный стиль сменился на более мягкий, ориентированный на клиента.

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

«Плавучесть» руководителя

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

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

«В мире менеджмента определенно происходит эволюция, компаниям теперь приходится другими способами добиваться притока заказчиков и партнеров, — признает Джек Каллен, глава компании Modis, занимающейся рекрутингом, подбором персонала и консалтингом. — Какое-то время тому назад генеральные директора и президенты компаний предпочитали диктаторский стиль руководства. Сейчас лидерам нужно прежде всего быть открытыми, чуткими к проблемам покупателей и служащих».

Технологии меняют руководителей

Технологии являются главной движущей силой отхода от командно-административного стиля управления, уверен Каллен. В частности, благодаря социальным СМИ заказчики могут гораздо больше влиять на бизнес-практики компаний, у них появилась возможность обращаться к более широкой аудитории — как с жалобами на компанию, так и, реже, с похвалой.

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

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

«Сегодня быть хорошим лидером означает больше слушать и требовать откликов, а не закрываться от них, — продолжает он. — Раньше служащие могли бояться говорить то, что думают, сегодня же отзывы и предложения поощряются, а не игнорируются. Истинные лидеры не станут просто требовать и указывать, они ищут способы наладить контакт со служащими и заказчиками, чтобы дать им возможность помочь вашему бизнесу».

Сопереживание помогает уменьшить текучку

Руководители с высоким эмоциональным IQ лучше справляются с одной из главных трудностей компаний на современном высококонкурентном рынке труда — с удержанием персонала, особенно дефицитных квалифицированных специалистов, уверен Джим Повек, руководитель Padgett Performance Group.

«Порядка 80% работников могли бы назвать своего непосредственного начальника главной “причиной” ухода с работы, — считает он. — Когда ИТ-директора, менеджеры по найму и высшее руководство жалуются на текучку и невозможность удержать хороших специалистов на ключевых ролях, первое, что они должны сделать, — посмотреть в зеркало, вся ответственность лежит на них самих».

Как определить эмоциональный IQ

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

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

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

Не пренебрегайте проверкой кандидатов

«Поразительно, но, несмотря на высокую точность методов оценки вроде метода Harrison Assessment, только около 20% менеджеров по найму пользуются подобными инструментами, — сетует Повек. — Озадачивает, что при всем нынешнем внимании к средствам прогнозной аналитики эти инструменты не применяются шире. По сути, в процессе такой оценки люди сами рассказывают вам, как удержать их на работе, каковы их цели и как вы сможете извлечь максимум пользы из их способностей. Так почему же не пользоваться этим активнее?»

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

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

«Затраты — это вообще не оправдание, поскольку подобные средства тестирования на самом деле ускоряют процесс найма, — добавляет он. — А потери из-за приема на работу не того человека или ухода ценного специалиста будут гораздо выше». Повек говорит, что, по его опыту, эмоциональным IQ обладают около 80% из тех, кто лучше всего справляется со своими обязанностями по работе.

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

- Sharon Florentine. Top Leadership Quality Isn't What You'd Expect. CIO. July 29, 2014