Менеджмент айти – MBA Информационный менеджмент (CIO) — программа обучения по специальности информационные менеджмент в Школе IT-менеджмента РАНХиГС | Школа IT-менеджмента РАНХиГС | MBA CIO (МБА)| IT менеджмент

Содержание

Кто такой IT-менеджер? — Актуальные новости сферы Информационных технологий на портале ITMozg

2013-10-10

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

По сей день можно встретить недоумение в среде российских разработчиков в стиле: «Да зачем он нужен, этот менеджер?»

Давайте разберёмся: а действительно, зачем?

Здесь уместно вспомнить классическую книгу Фредерика Брукса «Мифический человеко-месяц, или Как создаются программные системы». В этой книге выводится основной закон Брукса:

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

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

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

Под IT-менеджментом, как правило, понимаются люди, известные в англоязычной среде как PM: продукт-менеджеры и проект-менеджеры.

Существует всего две категории людей, занятых в IT-менеджменте:

А) люди, имеющие опыт программирования/разработки/инжиниринга

Б) люди, не имеющие опыт программирования/разработки/инжиниринга.

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

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

Уровень требуемого технического понимания во-многом зависит от компании. Скажем, в компаниях, создающих технически нагруженные инфраструктурные продукты (например, Heroku, Appcelerator, Akamai Technologies, Inc.), требуются технически подкованные менеджеры. А нужны ли серьёзные технические навыки менеджерам компаний, фокусирующихся на связях между пользователями (Twitter, Quora, Tumblr)?

Итак, перед нами встают два вопроса:

Должен ли IT-менеджер иметь опыт разработки?
Какие навыки нужны IT-менеджеру?

Для начала следует определиться с функциями IT-менеджера.

Чем занимается IT-менеджер?

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

Основная задача IT-менеджера сводится к планированию, прогнозированию, маркетингу отдельного продукта компании на всех стадиях его разработки.

Что из вышеперечисленного требует опыта в программировании?

Ни-че-го.

Можно даже пойти дальше и сказать, что для IT-менеджера лучше не иметь опыта программирования совсем, чем «уметь кое-что и чуть-чуть». Почему? Если у человека нет опыта разработки, на те идеи, которые рождаются у него в голове, не будет срабатывать триггер «это трудно или невозможно сделать». Эти вопросы пусть решает не менеджер, а команда разработки. Задача менеджера – определить, что нужно пользователям от продукта.

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

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

Поэтому ещё раз: все вопросы по реализации решает команда разработчиков!

Каких нетехнических знаний может не хватать технократу, выбравшему путь IT-менеджмента?

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

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

Сферический менеджер в вакууме: какой он?

Если собрать общую картину, мы получим следующие навыки, которыми желательно обладать идеальному IT-менеджеру:

1. Нетехнические навыки:

Понимать значение пользовательской среды/пользовательского интерфейса (UX/UI). Хотя бы на бытовом уровне. Где лучше расположить кухню в имеющейся квартире? А если это кафе? Где должна быть кнопка регистрации в приложении? Это вопросы одной категории.
Уметь планировать, составлять графики и документацию.
Быть эмоционально зрелым. Уметь мотивировать. Выстраивать взаимоотношения. Быть честным. Контролировать свои эмоции.
Знать методологии Agile и Lean.
Иметь опыт в маркетинге и продажах.
Иметь представле

ние о бюджете и его планировании.
Быть лидером.

2. Технические навыки:

Понимать общие принципы программирования (переменные, классы, подклассы, методы и т.д.), принципы построения архитектуры программных решений. HTML, CSS, PL-SQL не должны быть чуждыми аббревиатурами.
Иметь представление о API, непрерывной интеграции, автоматическом тестировании, A/B-тестировании, модульном тестировании.
Иметь представление о нескольких фреймворках для веб-разработки (Django, jQuery, Rails, Symphony) и платформах для мобильной разработки (PhoneGap, Titanium).

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

В качестве итога

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

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

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

IT-менеджеры — это люди, которые не допускают вот этого:

Отсюда можно сделать лишь один вывод. Давайте жить дружно! (с)

Автор: Люся Ширшова. Подготовлено по отзывам и советам из Quora и из жизни.

Читайте также:

Какие языки программирования сводят разработчиков с ума?

Закончится ли «золотая эра программистов»?

О чём никто не расскажет: тёмная сторона разработки ПО

itmozg.ru

Роль ИТ-менеджмента в современном бизнесе / Управление и менеджмент / DBanking

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

Что такое ИТ-менеджмент?

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

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

ИТ-инфраструктура

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

Преимущества использования ИТ-услуг:

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

Реализация ИТ-стратегии включает:

1. Привлечение специалистов, чьи знания, компетенция и опыт позволят осуществить данную стратегию. Формирование команды.

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

3. Определение целей ИТ-отдела. Уточнение, доработка, утверждение ИТ-стратегии;

4. Разработку, рассмотрение и утверждение программы выполнения ИТ-стратегии;

5. Внедрение программы через ИТ-менеджеров и их проекты.

ИТ-менеджеры

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

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

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

Совместные задачи бизнеса и ИТ

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

www.dbanking.biz

Чем занимается ИТ-менеджер? | LINK Academy

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

Каковы задачи будущего ИТ-менеджера?

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

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

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

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

Каковы характеристики ИТ-менеджера?

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

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

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

3 способа получения работы с великолепной зарплатой

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

Есть ли свободные места? Ведется зачисление!

www.link-academy.eu

Ответы@Mail.Ru: чем занимается It менеджер

IT-менеджер — это глава IT-отдела (Information Technology — информационные технологии) , его функция заключается в управлении этим отделом. IT-отдел занимается всем, что связано с компьютерами. От размера компании зависит и количество сотрудников отдела, и функции менеджера. В маленькой фирме IT-менеджер делает все «от и до» . Не исключено, что в этом отделе он — единственный сотрудник.

Чем больше фирма, тем больше IT-отдел. У менеджера появляются подчиненные, которым он делегирует часть своих полномочий (исполнительских) . Один бегает, подключает компьютеры и телефоны, другой устанавливает и обеспечивает функционирование необходимых в работе программ (например, бухгалтерской 1C) и помогает пользователям, если что-то не работает. А сам IT-менеджер их контролирует и консультирует, так как является экспертом в этих областях.

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

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

otvet.mail.ru

от командной строки к командной работе / Блог компании RegionSoft Developer Studio / Хабрахабр

Мир IT сегодня не похож ни на одну из других отраслей — над кодом приложений, игр, корпоративных решений, сервисов работают увлечённые, грамотные ребята. Программисты и инженеры, дизайнеры и тестировщики, системные администраторы и новомодные DevOps превращают идеи в программное обеспечение, которым пользуются миллионы людей. Они вдохновенно пишут код, разрабатывают алгоритмы, готовят макеты и соединяют это в работоспособные полезные механизмы. Мы, пользователи Хабра, часто говорим о разработке, администрировании, новых технологиях и языках программирования, зарубаемся в жарких спорах о преимуществах одного стека над другим, но забываем о важном звене в любой IT-компании — менеджерах проектов и продуктов. А между тем не факт, что завтра именно вам не предложат отойти от дел программерских и стать менеджером. Мотивация? Стоит ли? Потолок? Карьерный тупик? Новый горизонт? Давайте разбираться.

Менеджер в айти, бэклог его ити…

Мы внедряем свою CRM-систему и поэтому имеем не только опыт развития своих собственных менеджеров (это, в основном, гибриды с програмистами — ближе к тимлидам) в RegionSoft Developer Studio, но и встречаемся с чужими менеджерами ИТ-проектов (и не ИТ тоже, но это другая история). За много лет нам удалось выявить ряд типичных признаков менеджеров «с плохим характером».

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

Работа без цели, плана и этапов проекта. Такая ситуация может возникнуть, если менеджер плохо представляет себе этапы разработки и вообще процесс создания программного обеспечения, то есть фактически ему просто трудно адекватно планировать. Сумбурная работа, метание от задачи к задаче, постоянно изменяющиеся требования выматывают всех членов команды, приводят к увольнениями и профессиональному выгоранию.
Изменение проекта на лету — ещё одна ненавистная черта менеджера. Вы легко узнаете этот тип работника: услышав на конференции или очередном митапе о новой технологии или модных моделях управления, он возвращается в компанию с горящими глазами и начинает активно продавливать новинку на старом проекте. Причём это не эксперимент с лучшими практиками, а именно тотальное и безоглядное погружение во что-то новое. По ощущениям — больше макание. Приводит к срывам срока проекта и резкому падению качества и скорости разработки. Если горе-новатор умудряется заручиться поддержкой топ-менеджмента — пиши пропало.
Стратегия любой ценой — девиз менеджеров ИТ-проектов, работающих на свой собственный бонус, но не на благо команды. Такие ребята готовы на всё ради KPI и ROI и исключают любые риски, лишь бы не потерять заветные значения коэффициентов. Самый опасный вариант, когда менеджер лоббирует внедрение в матрицы показателей коэффициенты, связанные с «нетрудовыми» достижениями — такие как коэффициент лояльности, показатель внутренней мотивированности и оценочный уровень взаимодействия с коллегами. Как правило, профессионалы-интроверты сквозь это решето не проходят и остаются без премий. А там и без мотивации, и… без работы.
Непонимание принципов разработки — бич менеджеров-нетехнарей. Не зная особенности создания кода, скорость работы программистов, принципы тестирования, сроки выведения продукта в продакшен, крайне трудно прийти к общему знаменателю с R&D и стать настоящим связующим звеном внутри проекта. Именно такие менеджеры любят заучить несколько словечек ИТ-тематики и говорить: «Успеешь фичу до пятницы?», «Отрефакторь код, чтобы быстрее работало», «Да там всего две строчки поменять. Зачем весь билд тестировать?».
Некоторые менеджеры так и думают, что на входе какая-то идея, на выходе величайшее в мире ПО, а посередине — магия. Не-а, обычно великая идея, долгая-нудная-сложная разработка и продукт, который ещё и конкуренты опередили. И вот как раз классный менеджер и толковые разработчики этот продукт ведут к GREAT 🙂
Совещания без конца — отличный способ имитировать деятельность, не достигая при этом результата. Главное, чтобы был календарь резервирования переговорок (желательно, публичный), а сам менеджер с важным видом заслушивал состояние дел на проекте и давал комментарии. Если постараться, то можно назвать эту имитацию Scrum или Agile. Но тогда обязательно должна быть доска с цветными бумажками. Это менеджер-совещанец усвоил.
Клиент всегда прав, даже когда точно не прав. Почему-то волшебная формула «клиент всегда прав» из ритейла и сервиса перекочевала в том числе в разработку. Менеджер, призванный работать в том числе на стороне клиента, превращается не в адвоката клиентских интересов, а в кивающего божка, таскающего самые бредовые задачи от клиента с пометкой срочно-важно. И, конечно же, без составленного и подписанного ТЗ.
Игнорирование личностных аспектов — ошибка, которую может допустить любой менеджер, в том числе технарь. Ни в коем случае не стоит игнорировать тот факт, что вы работаете в окружении людей — а значит, в окружении личности, характера, настроения, мотивации. И если не учитывать эти особенности внутри команды, можно получить эффект ядерной мини-бомбы внутри коллектива. Заденет всех.
Неумение расставлять приоритеты приводит к однозначным срывам сроков проекта, сумбурности в разработке, брошенным делам, неразобранному бэклогу и переполненному багтрекеру. Разработка как любое инженерное дело не терпит хаоса.
Тотальный контроль и микроменеджмент — болезни управления, которые могут напасть на каждого. Нет ничего хуже, чем менеджер. стремящийся заменить каждого на рабочем месте и готовый влезть в каждый этап разработки.
Отсутствие ретроспектив — отличный способ снизить мотивацию команды и качество разработки. Если менеджер по какой-то причине избегает анализа ошибок, проделанной работы, боится похвалить или призвать к качественным изменениям, он неизбежно получит команду, не знающую, каким курсом она движется.
Игнорирование лучших практик. Чужие успехи, находки и преимущества порой трудно признать. Однако в работе подобное поведение фатально — если не принимать во внимание лучшие практики, можно отстать от конкурентов и по сути потерять все преимущества. Если менеджер боится признать лучшее и активно внедрять это, проект обречён.
Есть ещё один аспект работы менеджера, приводящий к негативным последствиям, — стремление создать дружную команду даже в ущерб эффективности и продуктивности. В погоне за комфортным психологическим климатом в коллективе и полной неконфликтности менеджер загоняет проект в ранг «дружеской посиделки», на которой всем хорошо, но работа не делается. Рано или поздно это обязательно приводит к конфликтам и глубокому управленческому кризису.

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

Из программистов в менеджеры — путь самурая

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

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

Особое мнение — главный разработчик RegionSoft Developer Studio рассказывает о своём опыте работы с менеджерами и программистами.

На мой взгляд, программисты и менеджеры — это совершенно разные сущности, которые практически противоположны друг другу. Я не знаю ни одного программера, который стал бы хорошим менеджером. Руководителем отдела разработки, тимлидом — да, а чтобы работать в том числе на продвижение и работу с клиентами — не знаю таких. Программисты действительно достаточно пассивны в плане общения — нередко молчаливые, упёртые, суровые интроверты, немногословные, не любят, когда их дергают и сами дергаться тоже не любят. Менеджер должен быть экстравертом, любить общаться, решать задачи, планировать и проявлять инициативу — конечно, рядом с психотипом большинства программистов, это категорически разные типы.
Но есть одна важная фишка. Если в человеке сочетаются черты и программиста, и менеджера — то из такого сотрудника получается идеальный руководитель проектов или даже менеджер экспертного уровня. Но такое встречается крайне редко.
Менеджер экспертного уровня — это всегда звезда в любой команде, потому что он и умеет работать «продвиженцем» и знает предмет вопроса изнутри. Это как Королев, когда он возглавил КБ для разработки ракеты. Если бы он сам эти детские ракетки и самолёты не запускал и не конструировал, он бы никогда не смог управлять целым КБ и не создал бы ракету, способную покорить космос.
От менеджера нужны лидерские качества, чтобы сплотить вокруг себя команду и суметь ей управлять, ставить задачи, планировать достижение промежуточных результатов и т.д. И, безусловно, в разработке ПО, в технической сфере это особенно важно.
Так что, если программирование — ваше всё и душа не лежит к менеджерской работе, не переходите. Хороший, талантливый разработчик всегда найдёт точки роста внутри любимого дела и своего проекта.

Переход из разработчиков в менеджеры разработки — это карьерный рост с точки зрения и общества, и руководителя, и коллектива. Это повышение заработной платы, новые задачи и новая ответственность. Но разработчик не всегда готов забросить код и приступить к новым обязанностям — хотя бы просто потому что программировать ему нравится гораздо больше. Эта позиция заслуживает огромного уважения (и повышения зарплаты — да-да, господа руководители, это свидетельство почти что патологической лояльности продукту и оно дорого стоит!), но мы всё же остановимся на более распространённой ситуации: зарплата манит, новые задачи будоражат и вы почти согласны стать менеджером, но с чего начать? Как встать на этот путь и стать на нём эффективным, а не попасть в ловушку принципа Питера?

Менеджер в ИТ — это почти всегда человек-оркестр. Но всегда ли слаженно он играет?

Что нужно осознать?

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

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

Как по мне, нет причин для беспокойства

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

С автоматизацией можно перестараться. В теории. На практике ощущается вечная недоавтоматизация.

И да, вам придётся столкнуться с этой картинкой в жизни 🙂

Главное — очень-очень любить свой продукт. Иногда, конечно, вопреки 🙂

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

Что придётся принять?

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

Самый большой страх

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

Как научиться быстро

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

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

Самая дешёвая и вполне адекватная возможность — найти наставника в компании, который позволит вам войти в новую колею. Это может быть глава департамента, опытный менеджер или даже генеральный директор, особенно в небольшой компании. Сотрудник, зная свою сторону работы, быстро освоится и изначально будет знать о проблемных точках проекта.
Углубиться в книги, блоги, материалы, заняться самообразованием. Отличное решение, но оно займёт много времени и будет иметь теоретическую основу. Скорее, это обязательное дополнение к любому из перечисленных способов.
Пойти на второе высшее, в магистратуру, на сложные курсы. Ну, если у вас есть время и деньги… На самом деле, это довольно затратно и не всегда эффективно — фишечка вузов, понимаете ли: есть учебный план и неприкаянные преподаватели, поэтому кроме нужных вещей вы будете изучать разную -логию. Впрочем, если вы студент последних курсов или хотите войти в ИТ уже не просто джуниором, но и подающим надежды молодцом, можете попробовать свои силы.
Получить степень МВА. Дорого, сложно, жрёт много времени, региональных работодателей не впечатляет. К тому же, хороших программ в России мало. Обычно на MBA решаются топы или почти готовые топы крупных корпораций, в которых это добавляет веса. Но, по нашему опыту, в ИТ-сфере ценятся несколько иные навыки: мозги, опыт, умение работат.

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

Внимание, Нижний Новгород, мы ищем менеджера!Нижний Новгород, мы ищем таланты! Мы разрабатываем и внедряем RegionSoft CRM. Порой это очень (ОЧЕНЬ) сложные и длинные внедрения и интеграционные проекты. Нам нужен менеджер с навыками программирования. Проще говоря, ищем толкового парня, который сечёт в разработке, умеет выбивать из людей требования, составлять ТЗ, убеждать, что для облёта поля пшеницы 4 кв. км нужен кукурузник, а не «Боинг», даже если есть деньги на этот Боинг 🙂 Возраст значения не имеет, опыт — имеет, и огромное. Записывайтесь на собеседование по адресу [email protected] и приходите поговорить. Территориально Сормово, удалёнка невозможна. Работа суровая, не говорите, что не предупреждали. Люди хорошие, руководитель адекватный.

Наш пока живой Телеграм-канал BizBreeze. Всякое про CRM и бизнес, по уму, без копипаста и на 90% без рекламы. Подписывайтесь.

habr.com

Как стать руководителем проектов в IT / Хабрахабр

Привет, друзья!

Так получается, что со мной периодически связываются мои знакомые и знакомые моих знакомых, которым меня порекомендовали, с примерно одним и тем же вопросом: «Как мне стать project manager’ом в IT, если до этого я работал(-а) на похожей позиции, но не в IT?».

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

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

Поехали?

Как обычно выглядит запрос:

Алексей, добрый день! Меня зовут <…>. Мне посоветовал к Вам обратиться <…>. Нужен Ваш экспертный совет. Буду благодарна Вам за подсказку. Нашла тренинг для проектных менеджеров, который Вы читаете. Хотела бы спросить стоит ли проходить мне его. Кратко о моей ситуации: <…> хотела бы себя попробовать дальше развивать в проектном направлении, но уже в IT-сфере. Уже проходила несколько собеседований, но пока безуспешных (работодатели часто ссылаются на то, что нет опыта в IT). В связи с этим у меня возникла мысль о том, как заставить все-таки поезд тронуться. Буду очень благодарна за совет по поводу курсов. Возможно есть смысл посмотреть что-то смежное к менеджеру проекта, если нет шансов, чтобы взяли в IT-сферу на такую позицию? Буду благодарна за любую обратную связь.

Варианты обращений отличаются только предыдущим опытом работы в неких не-IT областях.

Что я могу посоветовать?

Сначала напугаю и сгущу тучи.

1. Действительно, почти всегда отказывают ровно потому, что для project manager’a в IT крайне важно разбираться не только в project management’e как таковом, но еще и в IT. Это требуется ровно для двух вещей: а) для нахождения общего языка с подчиненными (тестировщики, аналитики и разработчики, которые все айтишники) и соответственно понимания сути диалогов, спецификаций, проблем и прочего, и б) для нахождения общего языка с представителями заказчика, которые зачастую точно также имеют в основном айтишный background. Конечно, есть некоторые небольшие шансы убедить будущего работодателя, что понимания специфики IT-области не критично для данной позиции. Важно помнить, что эти шансы очень и очень небольшие. Все-таки наниматель лучше знает, что ему надо, и убедить его в другом — довольно сложно. Особенно работодателей в IT — они уж точно знают, какой именно сотрудник им нужен. В то же время, никто не запрещает пробовать убеждать. Вдруг получится?

2. В IT очень важным является понимание этапов разработки продуктов (SDLC — Software Development Life Cycle). Работая в НЕ-айтишных организациях это понимание полностью получить, увы, невозможно. Есть моменты специфичные для IT-отрасли. А раз project manager в IT отвечает за разработку продукта/кода/функционала к заданному сроку, с заданным качеством и в заданных рамках по качеству/функционалу, то ему обязательно понимать, как же достичь всего этого теми средствами, которыми он обычно располагает в IT-сфере. В других отраслях могут быть свои нюансы, отличающиеся от IT в ту или иную сторону.

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

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

Итак, какие же параметры получились?

1. Владение техническим IT-шным языком. Понимание, к примеру, что вообще такое FTP, Signoff, Sprint, ASAP, Regression, XML, Database request, Deadline, FYI, Client-Server Architecture, Redline, Smoke Test, FTE, Release… Список можно продолжать бесконечно. Быть супер специалистом в некоторых упомянутых вещах — совсем не требуется. Требуется понимание сути, что это такое вообще, что за термины, что они обозначают, что за ними стоит, иначе бы будете как слепой в мире зрячих.

2. Знание SDLC (Software Development Life Cycle) — этапов разработки программных продуктов. И не просто знание, а понимание, почему именно такие этапы, почему именно в таком порядке, где и почему можно перескакивать с одного этапа на другой и можно ли двигаться по этим этапам в обратную сторону, и если да, то когда и при каких условиях.

3. Методологические навыки управления проектами и людьми (PM Hard Skills). Сюда входят знания методологий, принципов управления и процессов по областям. Таких как Agile, Scrum, Kanban, Waterfall, Communication management, Specification & Requirements management, Change management, Risk management, Reporting и т.п. Хорошая новость — всему этому так или иначе можно научиться на соответствующих тренингах, вебинарах и множестве доступных онлайн материалов.

4. Личностные навыки управления проектами и людьми (PM Soft Skills). Сюда входят Team & Client management skills, Ability to solve complex tasks, Presentation skills, Conflict management skills, Communication skills, Feedback skills, Ability to hear, listen & understand, Openness to other points of view, Ability to admit own mistakes and to correct them, Self-criticism, Leadership skills, Coaching/Mentoring skills, Ability to explain, Professional culture (quality of speech, emails, calls), Ability to make decisions and take responsibility for it, Pro-activity, Task management skills, Delegation skills, Execution control skills, Personal effectiveness, Time management skills. Вторая хорошая новость — всему этому тоже можно научиться на соответствующих тренингах.

Составим сводную таблицу, в которой будут присутствовать три кандидата:

внешний без знания IT-отрасли
внешний со знанием IT-отрасли
внутренний со знанием IT-отрасли и специфики компании

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

Мое мнение, что без погружения в IT-среду невозможно овладеть IT-шным языком хотя бы на уровне понимания. Таким образом с первым пунктом конкурировать нет смысла. Вы (внешний не IT кандидат) тут гарантированно проиграете. Остальные три области — вполне поддаются конкуренции. Причем если вторая (знание SDLC) тоже требует погружения в среду для полного понимания, то хотя бы примерно разбираться в ней не работая в IT — научиться можно. Недостаток знаний SDLC можно компенсировать за счет знаний толкового технического-лида, архитектора да и вообще любого технически грамотного человека из вашей будущей команды. А вот чтобы найти с таким человеком общий язык и получить его помощь — нужны очень серьезные навыки в PM Soft Skills.

Остаются PM Hard Skills и PM Soft Skills — и это ровно те области, где не IT-кандидат может значительно переиграть кандидата из IT-отрасли. Почему я так считаю? Многие руководители из IT — выросли из разработчиков, аналитиков, тестировщиков. Да, среди них есть очень крутые специалисты. Многие такие кандидаты в менеджеры из IT отрасли — они в глубине души остаются теми же самыми программистами, аналитиками и тестировщиками. А это говорит о том, что как раз PM Hard и Soft Skills у них могут быть развиты слабее, чем у внешнего кандидата. Ведь обе эти области (PM Hard Skills и PM Soft Skills) не зависят от IT специфики. Их можно и нужно развивать независимо от области, где вы сейчас работаете.

В итоге, что получается? Какой может быть наша сводная табличка, чтобы у внешнего кандидата ранее не работавшего в IT появился шанс?

План действий, который может помочь (а может и не помочь). Но если совсем ничего не делать — не поможет гарантированно.

1. Поговорить с кем-то из ТОЛКОВЫХ знакомых айтишников (разработчиков, тестировщиков, аналитиков, а еще лучше тим-лидов или менеджеров) про SDLC. Дополнительно почитать об этом в Интернет. Возможно, стоит поговорить не раз и даже не два.

2. Попробовать выбрать роль ассистента project manager’a в IT, либо роль младшего PMO-специалиста (там важнее знание процессов управления, чем знание этапов и нюансов и терминов разработки). Попав на любую из этих ролей — необходимо будет уже изнутри изучать терминологию и специфику IT, если действительно есть сильное желание двигаться и развиваться именно в этой области.

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

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

Резюмируя. Чтобы конкурировать с ребятами, которые разбираются в IT и тоже стремятся стать project manager’ами — необходимо серьезно превосходить их в PM Soft Skills.

P.S.: оригинал этой статьи (и другие интересные материалы) можно прочесть в моем блоге: consultpm.com
P.P.S.: мне резонно заметили, что IT не ограничивается разработкой. Это верно. В таком случае второй пункт (знание SDLC) будет менее значим, либо совсем заменен на какой-то свой, специфичный именно для вашего направления.

Поделитесь этой статьей с друзьями.
Спасибо и успехов вам!

habr.com

Методологии ITSM (IT Service Management) и ITAM (IT Asset Management), преимущества в управлении ИТ-деятельностью

Запись вебинара «Методологии ITSM (IT Service Management) и ITAM (IT Asset Management), их преимущества в управлении ИТ-деятельностью» можно прослушать на нашем сайте по ссылке:

http://www.academy.it.ru/deals/activity/seminars/metodologii-itsm-i-itam/

Бесплатно и без регистрации.

Ведущий: Андрей Боганов, тренер ITSM/ITAM. Эксперт совета itSMF Россия.

Вебинар ориентирован на:

Технических директоров.
ИТ-руководителей подразделений/групп поддержки (1-й и 2-й линии поддержки).
Менеджеров процессов поддержки (управления инцидентами, проблемами, изменениями, конфигурациями, релизами и др.)
ИТ-руководителей, отвечающих за расходы по ИТ-деятельности.
Руководителей ИТ-подразделений, отвечающих за учет ИТ-активов и взаимодействие с другими подразделениями (с бухгалтерией, финансистами, закупками, складом, поставщиками).

В рамках вебинара мы рассказываем о методологиях ITSM (IT Service Management) и ITAM (IT Asset Management), преимуществах при построении управления ИТ, обеспечивающих эффективную, результативную и финансово измеримую ИТ-деятельность. Обсудим, как сделать ИТ-активы надежным фундаментом основной деятельности организаций.

Важно, на вебинаре дается краткий обзор учебных курсов Академии АйТи по методологиям ITSM и ITAM. Программы являются авторскими и построены на основе изучения ведущих мировых источников знаний (ITIL, Cobit, IBPL, ISO и др.), а также собственного проектного опыта автора курса по внедрению решений по управлению ИТ в различных российских организациях.

Обсуждаем темы:

Управление ИТ-сервисами (ITSM) – основные понятия.
Из истории рождения подхода ITSM на основе мировых практик, ознакомления с библиотекой ITIL.
Обзор книг и процессов ITIL.
Обзор курсов по ITSM.
Управление ИТ-активами (ITAM) – основные понятия.
Из истории рождения подхода ITAM в российской действительности (на основании опыта автора).
Краткий обзор мировых практик.
Обзор подхода по организации управления ИТ-активами.
Процессная модель.
Обзор курсов по ITAM.

По результатам прослушивания вебинара вы ознакомитесь с :

Методологией ITSM (IT Sеrvice Management), сервисным подходом организации работы и управления ИТ-деятельностью
Ведущим мировым источником знаний в области ITSM библиотекой ITIL v3.
Книгами и перечнем процессов управления ИТ, изложенными в ITIL.
Методологией ITAM (IT Asset Management), пониманием задач управления ИТ-активами.
Пониманием подхода к контролю ИТ-активов на протяжении всего жизненного цикла от закупки до вывода из эксплуатации.
Мировыми источниками знаний по управлению ИТ-активами.
Процессной модели управления ИТ-активами, актуальной для российской действительности.
Пониманием возможностей, предоставляемых методологией ITAM для проведению любых финансовых расчётов по ИТ-деятельности (стоимости владения ИТ-активами, TCO; затрат по ИТ-активам; расчёта возврата инвестиций, ROI и др.).
Перечнем курсов Академии АйТи по тематикам ITSM и ITAM.

Опыт преподавателя (автора курсов) Андрея Боганова:

Эксперт itSMF Россия.
Преподаватель: РАНХиГС, МФТИ, РЭУ Плеханова, МИИТ МВА, РШУ, УЦ R-Style, Cleverics, Академии АйТи.
15 лет работы в ИТ сфере по внедрению ITSM и ITAM решений.
10 лет работы директором департамента ITSM решений, который реализовывал одни из первых проектов по управлению ИТ-активами в России.
Сертификат Certified Hardware Asset Management Professional (IAITAM).
Сертификат IT Service Manager (EXIN).
Личный опыт участия в нескольких проектах по управлению ИТ-сервисами и ИТ-активами.
Линейка курсов по процессам управления ИТ-сервисами (ITSM).
Подготовка первого русскоязычного курса по управлению ИТ-активами в России.
Курс по управлению ИТ-активами был создан на базе опыта внедрения ITAM-решений в российской действительности.

www.academyit.ru

РубрикаПолезно знать