Если вы работаете в крупной или даже средней компании, у вас наверняка есть сформулированные миссия и ценности, по которым живет и работает предприятие. Эти принципы объединяют сотрудников, объясняя им смысл существования компании в этом мире, и задают общий вектор движения. Все сотрудники в своей деятельности соблюдают (по крайней мере, так считается) общие ценности и стремятся к достижению миссии.

Считаем для простоты, что у нас компания, в которой слова не расходятся с делом, и сотрудники действительно верят в общую цель. Эдакая, Apple-2.

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

В своей книге «Начни с вопроса «Почему?» Саймон Синек приводит множество примеров, когда успех компании зависел в первую очередь от правильной последовательности вопросов. Нужно в начале объяснить, ПОЧЕМУ мы делаем то, что делаем. Затем объясняем КАК, и только в конце уже говорим ЧТО. Многие же действуют наоборот, рассказывая ЧТО делать. Могут объяснить КАК. Но крайне редко – ПОЧЕМУ.

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

И я задался вопросом – а ПОЧЕМУ ИТ директор идет утром на работу? Что им движет? Если спросить любого руководителя ИТ-подразделения, то скорее всего, мы получим ответы типа «обеспечить ИТ-поддержку бизнеса», «внедрить новые сервисы» и так далее. Мы слышим в ответ ЧТО ИТ-руководитель делает. Но не слышим, ПОЧЕМУ. Даже если представить, что причиной является банальное получение заработной платы, то это тоже не совсем ответ ПОЧЕМУ. Ведь деньги - это инструмент для достижения чего-то. Деньги ради денег не имеют смысла.

Так что же движет ИТ-директором? По Синеку основным ответом на вопрос ПОЧЕМУ является вера. Вера в то, что ты можешь что-то изменить. Стив Джобс верил в свои идеалы, Илон Маск - верит в свои. И они смогли действительно повлиять на ход истории. Естественно, что все не могут быть Джобсами. Но на мой взгляд, именно стремление изменить что-то и подталкивает ИТ-директора вперед. Вера в прогресс, в технологии. Что с их помощью можно не только построить очередной отчет для бухгалтерии, а поднять работу своего предприятия на новую высоту. А КАК, с помощью каких инструментов, внедрив какие проекты – это уже второй вопрос.

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

PS. Данная заметка – результат размышлений на довольно сложную тему. Поэтому приглашаю всех в комментарии высказать свое мнение.

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

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

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

По мере роста производительности сетевого оборудования, стали появляться конвергентные решения. В них используются программно-определяемые хранилища данных (software-defined storages), в которых в отказоустойчивый массив объединяются не дисковые элементы, а целые серверы. При этом используется специализированное программное обеспечение, формирующее такое решение и представляющее для потребителя готовые ресурсы через локальную сеть.

Преимущества такого решения очевидны: 

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

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

В итоге, мы получаем следующие преимущества:

•     Существенное упрощение конфигурации
•     Возможность применения относительно недорогих серверных блоков вместо дорогостоящих СХД
•     Упрощается развертывание и обслуживание системы

Недостатки:

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

В каких случаях лучше применять гиперконвергентные решения

•     Филиалы или небольшие предприятия, где нужно быстро развернуть недорогое решение с высоким уровнем надежности. Гиперконвергентные системы позволяют из двух обычных серверов собрать отказоустойчивый кластер. В итоге, относительно простое в обслуживании решение позволит обеспечить надежными ресурсами потребителя.
•     Частные облака, когда не требуется непропорционально высокий объем тех или иных ресурсов. В целом, типовая организация с доменом, почтой, порталом, сетевыми хранилищами вполне попадает под такой профиль и может использовать гиперконвергентные решения. На сегодняшний день даже такие тяжеловесные системы как SAP успешно применяются на гиперконвергентных платформах.
•     Облачные провайдеры. Такие решения являются идеальными для предоставления услуг публичного облака. Большинству заказчиков необходимы типовые виртуальные машины со средним объемом ресурсов. Что прекрасно обеспечивается гиперконвергентным облаком.

Когда же подобное решение будет неприемлемо

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

Действительно ли за гиперконвергентными решениями будущее?

По данным компании IDC, за 2017 год рынок таких решений вырос в среднем на 68%

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

Провал проекта стоит дорого. В то время как Институт Управления Проектами (PMI) отрапортовал о снижении количества провалов проектов на 20% в прошлом году, суммы убытков по-прежнему ошеломляющие. В среднем 97 млн долларов из каждого миллиарда инвестиций уходят в пустоту.

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

1.Культура сопротивления изменениям

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

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

2. Спонсоры, которые редко доступны

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

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

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

3. Больше вопросов чем ответов

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

4. Разрозненная или не заинтересованная команда проекта

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

5. Отсутствие доверия к менеджеру проекта

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

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

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

1. Привязка к поставщику

Поставщики заманивают вас низкими ценами и бесчисленными посулами, но, поймав вас в свои сети, уже не отпускают.

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

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

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

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

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

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

2. Излишне усердное составление финансовых обоснований

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

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

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

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

3. Найм специалистов с меньшим профессиональным уровнем, чем у вас

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

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

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

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

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

4. Продвижение по службе неподходящего внутреннего кандидата

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

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

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

5. Применение методологии agile с основными системами

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

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

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

Чтобы избежать проблем, ИТ-директор должен четко разграничить системы, которые можно быстро менять, и системы, которым быстрая замена противопоказана. При этом подчеркнем: универсального подхода здесь нет.

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

6. Слишком часто произносимое «да»

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

Часто бывает, что от ИТ-директора или руководителя по безопасности начальство требует доступа к закрытому ресурсу. А различные отделы организации «уходят в самоволку», самостоятельно внедряя новые облачные сервисы без согласования с отделами ИТ и безопасности.

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

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

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

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

7. Сокрытие проблем

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

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

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

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

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

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

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

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

Да, мир меняется. На заре промышленной революции в XIX веке, луддиты также противились внедрению новых технологий. Профессии появляются и исчезают. Это нормально. И торговля, возможно, одно из таких направлений.

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

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

Главная же причина, на мой взгляд, кроется как раз в том самом «Почему» Саймона Синека. Люди любят личное участие. Они хотят, чтобы им точно также объяснили «почему» они должны купить ту или иную вещь в магазине бытовой техники. И чем дороже/сложнее товар, тем важнее личное участие.

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

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

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

И на этом этапе в CIO возникает выбор:

• Строить полностью свою систему на базе собственных серверов
• Использовать облачную инфраструктуру и облачные решения
• Совместить два предыдущих пункта

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

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

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

Например, электронная почта на базе Microsoft Exchange штатно позволяет объединить наземную и облачную инфраструктуры в единую прозрачную конфигурацию. Администратор легко может перемещать ящики с земли в облако и обратно для оптимизации затрат и нагрузки. Аналогично существуют решения для миграции виртуальных машин на базе продуктов Microsoft System Center.

Что получает предприятие при использовании гибридного решения:

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

Минусы у гибридных решений также имеются:

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

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

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

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

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

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

Иллюзия № 1. Мы ориентируем ИТ на бизнес.

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

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

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

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

Иллюзия № 2. Единственная причина обновления программного обеспечения обусловлена реализацией в новой версии важных ценностей бизнеса.

Это не просто звучит убедительно, а принимается как руководство к действию. Явно, что ИТ-директор, проводящий такую политику, ориентирован на бизнес (и соответствие его целям) и его никак нельзя обвинить в тратах на технологии ради самих технологий.

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

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

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

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

Вот как обычно развиваются события.

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

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

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

Желтый уровень. Это состояние проекта, при котором отставание от сроков становится настолько существенным, что никакого пути к спасению уже нет, но при этом до сдачи остается еще немало времени и отрицание проблем по-прежнему подменяет собой реальность. Когда проект переходит в такую стадию, ловкие менеджеры начинают действовать в двух направлениях. Во-первых, они сокращают продолжительность тестирования. Проект вновь возвращается в зеленый статус (и тот же оттенок приобретают лица людей, работающих над ним).

А во-вторых, начинают подыскивать себе работу, пока проваленный проект еще не погубил их репутацию.

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

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

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

Иллюзия № 4. Мы придерживаемся методологии ITIL.

Это может показаться придиркой, но «придерживаться» ITIL невозможно. ITIL — это библиотека инфраструктуры ИТ, как терпеливо объясняют ее сторонники всем, кто готов слушать.

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

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

Иллюзия № 5. Мы исповедуем agile-разработку.

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

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

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

Иллюзия № 6. Мы придерживаемся DevOps.

Ничего подобного. Вы не придерживаетесь даже agile-проектирования. И удосужились ли прочесть все то, что было написано ранее?

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

Вот что DevOps добавляет в гибкое проектирование.

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

Третий момент связан с DevOps, а не с другими вариантами гибкого проектирования и уж, конечно, не с водопадной методологией. Дело в том, что программное обеспечение находится в состоянии постоянного развертывания (deployable). Нет, нет, не deplorable (в плачевном виде), а deployable. Наряду с многочисленными неудобствами для большинства сторонников гибкой разработки это означает, что DevOps и Scrum не являются полностью совместимыми. Kanban работает лучше.

Иллюзия № 7. У нас есть культура обслуживания клиентов.

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

Впрочем, это неважно, ведь когда культура есть, ИТ-директор считает, что весь бизнес является его клиентом.

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

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

ИТ-директор должен воспитывать в ИТ-службе культуру обслуживания.

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

Иллюзия № 8. Наша информационная безопасность на высоте

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

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

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

Иллюзия № 9. Наш процесс управления ИТ гарантирует реализацию только тех проектов, которые имеют высокую ценность для бизнеса

Давайте опять вернемся к соответствию целям бизнеса.

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

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

Сюда следует добавить и еще одну неприятную деталь: проекты, цель которых заключается в сокращении расходов, будут приоритетнее, чем проекты, направленные на увеличение доходов. Почему? Сокращение расходов бизнес может контролировать. Если все идет по плану, расходы будут сокращаться.

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

Какой же вывод можно сделать? Если вы в чем-либо уверены, то почти наверняка ваша уверенность ошибочна. И если, будучи ИТ-директором, вы готовы записать в свой актив девять перечисленных пунктов (или каких-то других), задайте себе простой вопрос: почему? И постарайтесь на него ответить.

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

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

Что изменилось? После отмены сетевой нейтральности, провайдеры США могут любым способом регулировать или ограничивать любое движение трафика по своим сетям.

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

Противники сетевого нейтралитета основным аргументом приводят недопустимость вмешательства государства в конкуренцию. Что рынок сам урегулирует все вопросы.

Чем это может грозить другим странам?

Мы все пользуемся сервисами, родина которых находится в США — Google, YouTube, Facebook, и так далее. Соответственно, нам не безразлично, как эти сайты будут работать. Пока отложим в сторону момент, что у всех этих крупных компаний есть датацентры и в других регионах. Следовательно, на нас это решение вообще никак не повлияет. Допустим, мы пользуемся каким-то сайтом, который находится только в Штатах.

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

Минутку, а что сейчас у нас происходит?

Сетевой нейтралитет — это исключительно особенность США. Ни в одной другой стране такой нормы в законах нет.

В Украине этот принцип также не соблюдается.

• Есть блокировки доступа к определенным сайтам.

• Крупные сотовые провайдеры предлагают бесплатный трафик к различным сервисам, в том числе и своего производства.

• Провайдеры кабельных сетей настраивают приоритеты внутри своих сетей для экономии каналов или предоставления приоритетов крупным клиентам.

Блокировку сайтов в данном случае логичнее вынести за скобки, так как даже в США есть ряд законов, определяющих цензуру в Сети. В остальном же мы видим обычную конкуренцию на рынке, когда клиент может выбрать провайдера, предлагающего наилучшие условия или дополнительные услуги. И никому в голову не приходит обвинить какого-то сотового оператора в лоббировании интересов Facebook, предоставляя бесплатный трафик.

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

Вместе с новым порталом управления облаком Microsoft Azure появилось и множество других изменений. Многие из которых кардинально изменяют подход к работе с облачными сервисами. Естественно, в лучшую сторону. Но любые изменения – это новый принцип работы, новые правила. А это не всегда удобно. Давайте попробуем разобраться, что же у нас добавилось, и стоило ли оно того?

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

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

У нас есть виртуальная машина, учетная запись хранения данных и виртуальная сеть. Каждая виртуальная машина должна относиться к какому-то облачному сервису, который имеет реальный IP адрес. Все. Никаких более параметров у вас нет. Сетевой интерфейс и сетевой адрес жестко привязаны к виртуальной машине. Если вы удаляете машину – все правила безопасности, настройки портов и так далее, удаляются.

Теперь посмотрим, как выглядит аналогичная конфигурация уже в ресурсном подходе:

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

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

Также хочется добавить, что Microsoft добавил кроме PowerShell, еще и отдельную консоль командной строки для управления облаком. Консоль кросс-платформенная, и может устанавливаться и на Mac и на Linux. Если бы мне кто-то сказал такое еще несколько лет назад – я бы точно не поверил!

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

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

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

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

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

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

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