Kitobni o'qish: «Практическое Руководство ИТ-Лидера»
Предисловие
На огромном пространстве информационных технологий и их применимых областей, пробираясь сквозь их сложности и нюансы, я часто чувствую себя сродни пересечению неизведанных территорий. В течение многих лет я пытался найти ориентир в постоянно меняющемся ландшафте ИТ. Именно во время этих поисков мне посчастливилось познакомиться с замечательным литературным компаньоном, книгой, которая не только оправдала, но и превзошла мои ожидания - настольной книгой под названием «Практическое руководство для ИТ-руководителей».
На страницах этого полезного руководства, автором которого является выдающаяся личность, чей опыт известен в этой области, находится сокровищница мудрости, ожидающая пытливые умы. Что поразило меня больше всего, так это то, как само название заключало в себе суть книги, служа маяком ясности среди огромного моря информации. Это действительно справочник в чистом смысле этого слова – всеобъемлющее руководство, которое выходит за рамки конкретных областей и стилей управления.
Что отличает эту книгу, так это ее универсальная применимость. Независимо от того, являетесь ли вы новичком, стремящимся разобраться в тонкостях ИТ, или опытным профессионалом, стремящимся отточить свои лидерские навыки, содержание этой книги предлагает дорожную карту к успеху. Для меня очень полезна глава «Собери свою команду». От основ информационных технологий до продвинутых тем, таких как «Зеленые ИТ», роль ИИ и его влияние, каждый аспект ИТ-сферы находит тщательное рассмотрение на этих страницах.
Одной из самых похвальных особенностей этой книги является ее универсальность. Вам больше не придется перебирать горы литературы, чтобы найти практически применимые советы. Вместо этого вы можете просто перейти к главам, которые соответствуют вашим конкретным потребностям и стремлениям. Вот почему я повторюсь что эта книга очень практична. Будь то овладение искусством управления проектами или углубление в тонкости кибербезопасности, богатство знаний, представленных здесь, служит путеводной звездой в стремлении к совершенству. Это подталкивает любого, кто интересуется ИТ, улучшить то, что он ищет.
По моему скромному мнению, я рекомендую эту книгу с большим вниманием. Она выходит за рамки знаний и личного опыта, предлагая бесценную информацию, которая актуальна для людей на каждой ступени ИТ-лестницы. Всем, кто хочет уверенно и профессионально ориентироваться в лабиринтах информационных технологий, я рекомендую отправиться в это познавательное путешествие и открыть для себя преобразующую силу, которая заключена на страницах «Практического руководства для ИТ-лидера».
Сиам Маусени - Ответственный за развитие и поддержку IN/VAS (MEA), Orange Group. Более 25 лет опыта работы в области стратегии и управления на уровнях «С-Level» в области информационных технологий в разных странах.
Почему появилась эта книга?
Каждый день мы сталкиваемся с историями неудач: многие стартапы терпят крах, а устоявшиеся корпоративные компании терпят неудачу в разных ситуациях - от запуска продуктов до инцидентов с защитой данных.
«Примерно 75% венчурных стартапов терпят неудачу. Эту цифру трудно определить, и некоторые оценки предполагают, что она может быть еще выше».
Элизабет Поллман (исследование о причинах неудачи стартапа)
Эти неудачи часто возникают по разным причинам: нехватка денег, внутренние проблемы в команде, недостатки в разработке продукта или бизнес-модели, жесткая конкуренция, отсутствие потребностей рынка или меняющиеся обстоятельства.
Столкнувшись с этими историями, мы можем отреагировать следующим образом:
Чувство страха: «А что, если это случится со мной?»
Самоуверенность – «Со мной этого не случится».
Критическое размышление: «Каковы общие факторы этих неудач, и как мы можем выявить и исправить наши ошибки до того, как они приведут к катастрофе?»
Это побуждает нас посмотреть под другим углом: а все ли наши действия правильны и эффективны? Действительно ли мы сосредоточены на принятии правильных решений и предпринимаем необходимые шаги для прогресса, хорошей работы и исправления своих ошибок?
Многие неудачи связаны с ИТ-проектами и продуктами, с участием команд, независимо от их размера, от команд с 2-3-я энтузиастами, до больших департаментов международных корпораций. Этот недооцененный многими ИТ-лидерами факт побудил к созданию этой книги.
Основная цель этой книги подробно изложена на следующих страницах, но суть такова - я стремлюсь расширить возможности сегодняшних лидеров и менеджеров. Делая все правильно сегодня, мы прокладываем путь к правильному будущему, что приводит к успешными командам, результаты проектов, успешным компаниям и личными достижениям каждого члена команды и компании.
Краткий обзор моего опыта работы
За годы работы я накопил обширный опыт в различных областях ИТ, включая администрирование разных систем, управление базами данных, сетевое администрирование, программирование, архитектуру, а также тонкости инженерной поддержки. Моя карьера была «путешествием» непрерывного роста и глубоко укоренившегося желания добиться позитивных изменений.
Переход от роли ИТ эксперта к таким ролям, как руководитель команды, ИТ-менеджер, менеджер проектов и, в итоге, CIO (директор ИТ) / CTO (технический директор), каждая новая должность приносила не только лучшее вознаграждение и условия, но и новые вызовы. Этот рост потребовал фундаментального прорыва в мышлении; Технический опыт уже был, а вот опыта в процессах, в руководстве и в других моментах уже явно не хватало. Появились новые управленческие обязанности, включая составление бюджета, руководство командами, разрешение конфликтов и многое другое.
Несмотря на то, что у меня была должностная инструкция, я стремился к всестороннему пониманию своих обязанностей. Как я могу внести свой вклад в улучшение и стабильность компании? Как я могу возглавить мотивированную команду, которая осознает свою роль в более широкой бизнес-стратегии, выходящей за рамки отдельных задач?
Перематывая время вперед...
Имея более чем двадцатилетний опыт работы в области управления ИТ и Технологическими командами, я чувствовал себя обязанным превратить собранные мною знания в четкие, действенные рекомендации для других. Эта книга призвана стать ценным ресурсом для любого ИТ-руководителя, предлагая прочную основу для преодоления сложностей вашей роли и стремления к совершенству и успеху как в команде, так и в компании.
Когда я отправлялся в свое путешествие много лет назад, я стремился к исчерпывающему списку элементов, которые могли бы служить надежным руководством, гарантируя, что ни один важный аспект не будет упущен из виду.
Очень важно заложить фундамент, основанный на практическом опыте, и это именно то, что я стремлюсь обеспечить в этой книге.
Для кого эта книга?
Эта книга рассчитана на самую разную аудиторию, независимо от вашей текущей роли в ИТ-сфере.
В этой книге я использую термин «ИТ-лидер» как синоним термина «ИТ-руководитель», «ИТ-менеджер», «ИТ-директор», «Руководитель ИТ-отдела», «Менеджер ИТ-проектов» или «Технический директор».
Вступление в роль ИТ-руководителя сопряжено с определенными проблемами или ситуациями, обусловленными конкретными обстоятельствами:
Новая компания, новая ИТ-команда: возможно, вы присоединяетесь в качестве руководителя новой ИТ-команды в недавно созданной компании или являетесь самым первым ИТ-сотрудником! Возникает вопрос: С чего начать? Как заложить прочный фундамент для ИТ-команды и/или отдела?
Рост компании, расширение ИТ-потребностей: В компании, которая расширяется, некогда маленькая и эффективная ИТ-команда теперь нуждается в расширении. Эта фаза роста требует тщательного планирования, развития команды, установления правил и процессов, делегирования полномочий и эффективного руководства, независимо от того, есть ли у вас уже команда с необходимой экспертизой или вам только предстоит увеличить команду.
Переход в качестве нового ИТ-руководителя: Смена предыдущего ИТ-руководителя, независимо от того, получили ли вы повышение внутри компании или наняты извне, сопряжена с уникальным набором задач и вызовов. Вы можете перенять ценные ресурсы, документацию и аналитическую информацию у предыдущего руководителя, если таковые имеются, или начать с нуля.
Независимо от сценария, существует общая потребность — потребность в четкой отправной точке и определенном пункте назначения. Эта книга призвана дать вам практические знания, предлагая идеи и стратегии для успешной работы в качестве ИТ-лидера, создания устойчивой ИТ-команды и её управления, а также создания ИТ-среды, приносящей пользу как компании, так и ее сотрудникам.
Кроме того, эта книга предлагает ценную информацию:
Для опытных ИТ-руководителей, которые ищут новый взгляд на свои обязанности.
Для ИТ-специалистов, стремящихся к карьере директора или руководителя ИТ- или Технических департаментов, отделов и команд.
Независимо от вашей текущей должности, вашей ситуации в компании или состояния самой компании, эта книга предназначена для того, чтобы провести вас через ваш путь, служа исчерпывающим навигатором и руководством для того, чтобы стать успешным ИТ-лидером.
Глава 1. Ваш путь в качестве ИТ-лидера
«Идеи даются легко. Исполнение
-это всё».
Джон Дорр
«Парадокс ИТ-директора — это совокупность противоречий, лежащих в основе ИТ-лидерства. Этот парадокс заключает в себе повседневные проблемы, с которыми сталкиваются ИТ-директора, и именно это делает эту роль такой сложной и такой интересной».
Марта Хеллер
«Продуктивность не имеет смысла, если вы не знаете, какова ваша цель».
Элияху М. Голдратт и Джефф Кокс
В этой главе дается краткое изложение тем, которые мы рассмотрим в этой книге. В каждой последующей главе мы будем углубляться в каждую тему, а также будем рассматривать случаи из реальной жизни. В книге вы найдете различные шаблоны, которые можно использовать для разных процессов.
Независимо от вашего пути к роли ИТ-Лидера, следующие шаги необходимы каждому руководителю ИТ. Они помогут создать прочную основу и обеспечить постоянную поддержку бизнес подразделениям в также стать их верным партнером.
«Современные ИТ-руководители должны быть в первую очередь бизнес-лидерами с четким пониманием стратегических целей организации, рыночного контекста и бизнес-процессов». Джилл Дайч
Реальная история: как я начал работать на позиции директора по технологиям в новой компании.
Я взял на себя роль руководителя технического департамента в молодой и быстро развивающейся компании, отвечая за разработку и поддержку программных продуктов в рамках нашего бизнеса. Несмотря на то, что команда не была большой, успех компании полностью зависел от разработки, качества и общей эффективности технической команды.
Через короткое время после начала работы я заметил следующую ситуацию: команды были практически завалены работой, в повторяющихся циклах, то решая проблемы в проектах дорожной карты, то решая проблемы связанные с частыми инциденты, одновременно с этим пытаясь оптимизировать продукты… но почти все эти действия практически не приносили пользы. Старшие разработчики часто разрывались между разрешением инцидентов и проектами. В проектах практически отсутствовала четкая формализация, а это приводило к постоянным переделкам.
Последствия сказывались на всей компании: снижение доступности продуктов и качества сервиса (SLA - Service Level Agreement), инциденты с длительным временем решения и бурное недовольство со стороны бизнеса. На сроки и качество бизнес-проектов также негативно повлиял фокус технической команды на частых инцидентах, что вызывало дополнительное недовольство.
Этот цикл напоминал тупик, где отдельные задачи выполнялись, но преобладала общая неудовлетворенность, отражающаяся на плохих результатах компании.
И еще один момент - развивающийся технологический ландшафт требовал от команд изучения новых тенденций и внедрения новейших, оптимизированных, безопасных и стабильных решений… но этого также не происходило.
В результате общая удовлетворенность бизнес команд а также команды разработчиков оставалась низкой.
Вы можете сказать - "это нормальная ситуация во многих компаниях", "в чем конкретно проблема", или, может быть, проблема в "слишком много задач или проектов"...
Я бы сказал, что да – к сожалению это считается «нормой» во многих компаниях, и я бы сказал «нет» – это ненормальная ситуация в компании, которая хочет быть успешной!
Проблема не была связана с количеством проектов или задач. Но если задачи и проекты оставлены без контроля, это тоже может привести к подобным кризисам.
Для понимания проблемы в целом я постоянно общался с людьми моей команды и с бизнес коллегами. Многие из них считали эту ситуацию нормой. При обсуждении таких проблем, как инциденты, длительные сроки разработки, неудовлетворенность бизнесом или отсутствие внедрения новых технологий, ответы варьировались от «у нас сейчас нет на это времени» до обвинений других в том, что «мы не можем выполнить работу вовремя, потому что нам что-то не было предоставлено» или «другой отдел или команда не понимают наших проблем, поэтому у нас так много инцидентов». Еще одна частая жалоба касалась совещаний (meetings); Совещаний было много и не было определенного формата ни по времени, ни по структуре – а это мешало сосредоточиться на работе и приводило к разрозненным усилиям, напрямую влияя на результаты и на качество.
Любой, кто читает эту книгу, вероятно, встречал в своей жизни подобные ситуации.
Теперь давайте рассмотрим, что я сделал, и результаты, которые за этим последовали.
Мои цели, составленные совместно с генеральным директором, заключались в том, чтобы в первую очередь сосредоточиться на повышении вовлеченности технических команд, оптимизации разработки проектов дорожной карты, минимизации инцидентов и повышении стабильности наших продуктов, то есть улучшении SLA.
Основываясь на своем предыдущем опыте, при решении критических вопросов или запуске новых инициатив я провел тщательную оценку масштаба – чтобы понять нашу текущую ситуацию!
Чтобы получить целостную картину ситуации, я инициировал серию встреч со всеми заинтересованными сторонами, как со стороны бизнеса, так и техническими коллегами. Вот детали того, что я именно хотел обсудить и понять:
С техническими командами: Глубокое погружение в рабочий процесс, анализ ошибок, частоту развертывания, выбор архитектуры, использование инструментов и многое другое. В процессе обсуждения мы не ограничивались только ключевым техническим персоналом, но охватывали всю команду. Встречи были либо командными, либо в формате индивидуальных встреч для обсуждения критических случаев.
С бизнес коллегами: Я изучал их процессы, собрал их ожидания от технической команды, обсудил их стратегию, цели и все нюансы, связанные с этими целями.
После нескольких раундов встреч и обмена информацией я составил карту: «Анализ текущей ситуации» — это мы назвали пункт «А», а цели обозначили как пункт назначения «Б».
Затем началась роль «штурмана» – прокладывание курса из точки «А» в точку «Б».
Если проблема заключалась в качестве продуктов, был создан специальный рабочий процесс для повышения качества.
Если проблема заключалась в реализации проекта, то по одному из проектов был инициирован пошаговый процесс для тщательного изучения реального хода проектного процесса.
И так было сделано по каждому процессу, который не давал нужные результаты либо работал неэффективно.
В результате проделанной работы был разработан план действий, направленный на решение выявленных проблем и улучшение ситуации в целом по всем направлениям. Этот план получил поддержку команды, а также был утвержден бизнес-коллегами. И мы начали его реализацию.
Важно понимать, что решение любой проблемы требует системного взгляда на весь процесс. Одних только технических улучшений недостаточно без учета требований проекта, тестирования или стратегии запуска.
Вот действия, которые мы инициировали:
Фокус на качестве продукта: это включало в себя повышение качества продуктов, устранение инцидентов, улучшение SLA, внедрение новых технологий и повышение вовлеченности команды:
Анализ первопричин инцидентов: ключевые сотрудники уделяют первоочередное внимание пониманию основных причин инцидентов, уделяя время обсуждениям, анализу журналов и планируют действия для тестирования в тестовой среде. В случае происшествия были предприняты совместные усилия по сбору всей необходимой информации для тщательного исследования.
Исследование новых технологий: каждый руководитель команд назначал работника, либо работник делал это по собственной инициативе – задача была, в определенное время в течении недели или двух, выделить половину рабочего дня каждую неделю, на анализ и тесты какой-то технологии, напрямую или косвенно связанной с нашим технологическим стеком. Эта работа была включена в регулярный график, а результаты были представлены этим работником команде или командам. Также нововведение было оценено на предмет применимости.
Решение проблемы перегруженности собраниями: чтобы смягчить последствия чрезмерных совещаний, особенно при выполнении длительных задач, было введено такое понятие как «день без совещаний», первоначально на экспериментальной основе, а затем принятый на постоянной основе из-за его эффективности. В эти дни (2 дня в неделю - Вторник и Пятница), совещания между бизнес и техническими командами не организовывались, за исключением критических ситуаций.
Усовершенствования дорожной карты: для повышения эффективности были внесены улучшения как в проектные, так и в технические процессы внесения исправлений (Project Management, Change Management):
Создание единой дорожной карты: объединенная бизнес и техническая дорожная карта предоставила четкое представление обо всех проектах, приоритетах и ресурсах, оптимизируя управление проектами и изменениями. Всё стало прозрачно - стало ясно что делать, когда и кто именно вовлечен.
Четкие правила запуска проекта: Преждевременное начало проекта было исключено за счет тщательного первоначального анализа спецификаций и доведению до ясности всех требований. Это привело к лучшему распределению ресурсов и минимизации доработок.
При этом были согласованы и утверждены основополагающие принципы для всей компании:
Неизменная приверженность качеству: Качество остается нашей первостепенной задачей, не подлежит обсуждению и никакие компромиссы с качеством неуместны.
Непрерывное обучение и технологический прогресс: «держать руку на пульсе» касаемо новых технологий, при этом вовлекая всех сотрудников компании или организации.
Единая дорожная карта: Проекты не делятся на бизнес- и технические. Все усилия команд консолидированы и сфокусированы на достижение совершенства наших продуктов.
Ясность перед началом: Четкое понимание ожиданий гарантируют, что проекты не будут тянуться, а будут реализованы в срок и с надлежащим качеством.
Данные подходы, являющиеся частью нашего общего видения, ценностей и стратегии, будут обсуждаться в последующих главах.
Мониторинг реализации этих процессов осуществлялся в течение трех месяцев. Это подчеркивало важность сохранения фокуса на ключевых элементах, не отвлекаясь на другие приоритеты. Этот фокус является важнейшим аспектом ИТ-лидерства. Он требовал от меня и технической команды тесного сотрудничества с бизнес-коллегами, и подчеркивало важность скорейшего решения критических проблем. Это также приносило преимущества для разработки новых решений благодаря, в том числе, улучшенным процессам.
Вот основные результаты и выводы (по разным направлениям):
Улучшение качества:
Системный подход к устранению инцидентов, включая изменения архитектуры, и улучшение коммуникации между техническими и ИТ-командами привели к значительному снижению инцидентов уже через 3 месяца.
Внедрение дополнительных метрик для системы мониторинга для выявления предупредительных показателей до того, как состояние систем или модулей может привести к инциденту. Это помогло предотвратить многие инциденты и улучшить контроль над работой всем систем в целом.
Усовершенствования, уже сделанные в продуктах и архитектуре послужили основой для повышения качества новых продуктов уже с момента начала разработки.
Вовлечение всех работников :
Поощрение непрерывного обучения и освоения новых технологий повысило вовлеченность и удовлетворенность сотрудников.
Сотрудники посвящали часть рабочего времени обучению, что приводило к повышению мотивации по мере того, как они становились свидетелями личностного и профессионального роста.
Усовершенствование дорожной карты:
Первоначальные трудности в реализации дорожной карты были решены путем изменения подхода к спецификациям: работа над изменением или новым продуктом начинается только тогда, когда требования будут полностью определены и поняты как бизнес, так и техническими командам.
Пошаговый подход к требованиям и к процессу обсуждались между техническими и бизнес-командами - это привело к четкому соглашению о распределении ресурсов и о сроках. Это привело к более эффективному планированию и сокращению задержек.
Улучшение ясности спецификаций и исчерпывающие ответы на вопросы всех специалистов способствовали более легкому планированию ресурсов и снижению потребности в доработках - что привело к повышению качества продуктов и, следовательно, к более быстрому и качественному запуску для финальных клиентов.
Важный аспект: несмотря на достижение желаемых улучшений, наши усилия не прекращались. Мы понимали, что, если мы вернемся к прошлым методам работы, те же проблемы неизбежно всплывут снова.
В последующий период мы ежемесячно анализировали наши результаты, постоянно стремились улучшить наши рабочие процессы. Чем больше улучшений мы внедряли, тем менее напряженной становилась рабочая среда, что позволяло членам команды больше сосредоточиться на разработке и качестве, а не на решении повторяющихся проблем или повторяющихся доработок.
~~конец истории~~
Важное: необходимо постоянно стремиться к улучшению эффективности.
Эффективность лежит в основе большей части работы ИТ. Это требует анализа процессов и работ, ориентированного на выявление и преодоление препятствий.
Этот подход должен укорениться в нашей повседневной деятельности: недостаточно просто быть открытыми к изменениям — мы, как ИТ-лидеры, должны активно руководить и управлять ими.
Без такой упреждающей позиции большая часть усилий команды может оказаться напрасной, как показано на изображении.
Рисунок 1: Мы слишком заняты... совершенствоваться.
Давайте теперь подробно рассмотрим роли и обязанности ИТ-руководителя.
«Ваше путешествие только началось».
1.1 Оценка текущего состояния – IT Assessment
Понимание текущей ситуации похоже на определение местоположения GPS. Пренебрежение тщательной оценкой того, где вы находитесь сегодня, может привести к отклонениям как в стратегии, так и в реализации стратегии.
В этой книге я сравниваю работу ИТ-лидера с путешествием. Давайте кратко рассмотрим, какие существуют сходства и насколько они важны:
Каждый человек сталкивался с планированием поездками из точки А в точку Б: из дома в школу, из офиса в магазин, а затем обратно домой, или более сложные поездки и путешествия.
На первый взгляд это кажется простым делом, когда все пункты назначения находятся поблизости — ваш дом находится рядом со школой, офисом или магазином. Однако на самом деле эти места часто могут находиться далеко друг от друга, или могут существовать препятствия.
Таким образом, чтобы добраться из дома в офис, нам нужно знать, когда мы приедем (или придем) в пункт назначения. Для этого мы должны сначала узнать нашу отправную точку. Звучит просто, но на самом деле это важнейший аспект начала нашего путешествия. В начальной точке (точка А) у вас может быть автомобиль, или вы можете использовать велосипед с выделенными полосами для велосипедистов, или может быть доступна автобусная остановка или станция метро. Не определив свою отправную точку, вы не можете быть уверены, сможете ли вы добраться до пункта назначения (точки Б) вовремя и с теми ресурсами, которые у вас есть.
Точно так же, если вы, как ИТ-руководитель, не знаете точно, где находится ваша команда сегодня, какого состояние технологий, систем и ресурсов которыми вы управляете, планирование и достижение будущих целей для устойчивого, эффективного и инновационного ИТ становится практически невозможным.
В качестве ориентира для этой критической оценки может быть использован шаблон оценки состояния ИТ, представленный в главе 2 (таблица 1).
Предоставленный шаблон оценки ИТ не охватывает все отрасли бизнесов. Определенные сектора, такие как банковское дело, здравоохранение, телекоммуникации и т. д., могут иметь свои уникальные требования. Но это не проблема - их можно добавить исходя из ваших требований, перечислив их отдельно или включив в один или несколько существующих разделов или под-разделов.
Также использование ИТ-оценки становится важным начальным шагом и непрерывным эталоном, который вы можете использовать регулярно в течение долгого времени. Например, ежегодное проведение внутренней оценки позволяет проанализировать аспекты роста или изменений, добавив столбец для текущей даты проверки. Это позволит получить четкое представление о прогрессе вашей ИТ команды. По мере роста вашего бизнеса (организации) и ИТ-ландшафта, дополнительные элементы могут быть легко интегрированы в данный пример оценки.
1.2 Создайте свою стратегию
Разработка стратегии — это не разовое усилие, а циклический, повторяющийся процесс. Кропотливо работая над своей стратегией, вы стремитесь добраться из точки А (результат вашей оценки) в точку Б за Х месяцев/год (лет).
Я не могу не подчеркнуть, насколько важно убедиться, что ваша стратегия ясна! Она должна быть основана на очень простых принципах, таких как, к примеру, принципы SMART (расшифровывается как Specific, Measurable, Achievable, Relevant, and Time-bound), и должна быть прозрачно согласована с вашими бизнес-командами и генеральным директором а также с вашей командой.
В главе 3 мы подробно расскажем о том, как создать свою стратегию. Тут я хочу подчеркнуть ее важность и необходимость того, чтобы она была понятна вам, вашей команде и заинтересованным сторонам.
Сравнивая это с путешествиями, мы помним, что Стратегией считается точка Б, пункт назначения. Представьте, что вы объявляете о планах поехать в «хороший город» к концу следующего месяца, что требует от команды тщательной подготовки. Для вас таким «хорошим городом» может быть Париж, Рим или Лос-Анджелес. Однако для члена команды это может быть его родной город, Токио или Стамбул.
Помня об этом, вам нужно быть четким и ясным, и учитывать сложности планирования поездки. Каждая страна имеет свои визовые правила, стоимость поездки варьируется в зависимости от пункта отправки и пункта назначения, а также необходимо учитывать культуру и климат разных стран.
Поэтому, если вы не знаете, куда должна двигаться команда, все усилия - ваши и команды - могут оказаться напрасными. Вы и ваши товарищи по команде можете оказаться в «разных местах», что приведет к разочарованию и путанице.
Точно так же крайне важно выстроить четкую стратегию: «Наша команда должна расшириться на 2 старших инженера и 1-го администратора среднего звена к концу второго квартала». Эта цель является точной, что позволяет команде сосредоточиться на достижении этой конкретной цели и достижению к конкретной дате.
Обратитесь к примеру ИТ-стратегии, основанной на бизнес-стратегии, приведенному в главе 3 (Построение стратегии).
1.3 Создание и управление дорожной картой – реализация стратегии
После того, как мы разработали Стратегию (помните - это "точка Б", где мы хотим оказаться на определенном участке времени), необходимо построить план исполнения! Этот план должен включать задачи, обязанности для каждого направления и команды, принципы последующих действий и четкую информацию о том, какими средствами можно достичь цели. Перечень действий по реализации Стратегии, как правило, объединяется в Дорожную карту (Roadmap). Четко определенная дорожная карта позволяет разбить сложные задачи на управляемые компоненты. Для справки см. пример плана реализации ИТ-стратегии — дорожная карта в следующих главах (глава 4 - Дорожная Карта Реализации Вашей Стратегии).
1.4 Управление внутренними и внешними процессами
Почему я придаю такое значение процессам? Многие воспринимают процессы как обыденные, нагруженные правилами процедуры, которые душат инновации и творчество. Другие называют процессы бюрократией.
Однако, на мой взгляд, процесс – это далеко не «скучная процедура или бюрократия». Это взаимосогласованная последовательность шагов, коммуникаций, обратной связи и задач, направленных на достижение чего-то полезного для компании. Каждое событие в нашей жизни и на нашем рабочем месте является процессом, независимо от того, определено ли оно явно или нет. Таким образом, если мы стремимся выделять время и ресурсы на инновации и свежие идеи, задачи, схожие по исполнению, должны быть оформлены в документированный процесс. Это гарантирует, что каждый сотрудник (участник процесса) будет знать свои обязанности, как выполнять задачи, как решать проблемы, сколько на то или иное действие отведено времени, как предлагать или обрабатывать обратную связь и т. д.
