Группы руководство it специалиста

Приветствую в это нелегкое время. Я продолжаю цикл статей для предпринимателей и несколько следующих хочу посвятить краеугольному камню любого IT проекта или продукта — команде.

Специфика IT

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

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

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

Все эти аспекты необходимо будет учитывать как при формировании своей команды, так и при работе со сторонней компанией.

Структура команды

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

Во главе продукта стоит Product manager или Product owner. Разница есть, но для нас она не существенная. Он работает с рынком, общается с пользователями и инвесторами, определяет вектор развития продукта, генерирует гипотезы и пользовательские истории, приоритезирует их и много другое. Если упростить, он на основе данных решает, какие потребности и в каком порядке необходимо закрыть.

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

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

Development team

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

Project manager

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

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

Analysts

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

Бизнес-аналитики составляют бОльшую часть всех аналитиков в рамках стартапов, поэтому разберу именно их. Компетенции БА я разделяю на две больших области: продуктовая аналитика и формирование требований.

О продуктовой аналитике, которую необходимо провести до начала реализации, я писал в прошлых двух статьях: Есть идея IT-продукта. Что делать дальше? и Зачем нужен MVP. Помимо описанных там анализа ЦА, конкурентов и рынка, проведения проблемных и решенческих интервью, арсенал продуктового аналитика включает в себя большой спектр инструментов, позволяющих находить точки роста. Итогом этой части работы становятся пользовательские истории — формулировки вида “как покупатель, я хочу фильтровать товары, чтобы выбирать только среди релевантных” с различными дополнениями и ограничениями вроде названий фильтров или максимально рентабельной стоимости разработки. Это своего рода условия задачи.

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

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

Leads

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

Лиды определяют “правила игры” в своем отделе: какие инструменты, подходы, технологии и тд будут использоваться. Если каждый сотрудник в направлении будет делать по-своему, об эффективности можно забыть.

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

Designers

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

Работу дизайнера можно условно разделить на 3 части:

Tech Lead

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

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

Принцип работы приложений

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

Клиент — веб или мобильное приложение — эта та часть, которую видит пользователь. Например, пользователь интернет-магазина, находясь в разделе кроссовки, выбрал в фильтре по бренду Nike. Тогда клиент посылает запрос на сервер, говоря “пришли мне все кроссовки Nike”. Сервер получает и обрабатывает этот запрос: команда проекта заранее определила, что пользователям должны показывать только товары, которые есть в наличии. Сервер обращается к базе данных, которая формально может быть как на этом, так и на другом сервере: “пришли мне все кроссовки с брендом Nike, которые есть в наличии”. В ответ сервер получает список товаров, но, если отправить все сразу, страница у пользователя может грузиться очень долго. Поэтому на сервере товары дробятся на страницы, а на клиент приходит ответ: “Всего нашлось 147 товаров, я разделил их на 8 страниц по 20 товаров, держи первые 20”. В итоге у пользователя отображаются первые 20 кроссовок Nike.

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

Front-end developers

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

В процессе работы он больше всего взаимодействует с дизайнерами по вопросу макетов и с серверными разработчиками(back-end developers) по обмену данными.

Mobile developers

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

Мобильных разработчиков по используемым технологиям можно разделить на нативных и кроссплатформенных. Первые пишут приложения для конкретной ОС(iOS или Android), вторые сразу под обе.

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

Back-end developers

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

QA

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

Итоговая цель любого тестировщика — обеспечить высокое качество продукта.

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

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

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

Заключение

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

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

УТВЕРЖДАЮ:

_______________________________

[Наименование должности]

_______________________________

_______________________________

[Наименование организации]

_______________________________

_______________________/[Ф.И.О.]/

«______» _______________ 20___ г.

ДОЛЖНОСТНАЯ ИНСТРУКЦИЯ

Руководителя группы разработки (управление процессами и проектами по созданию (модификации) информационных ресурсов)

1. Общие положения

1.1. Настоящая должностная инструкция определяет и регламентирует полномочия, функциональные и должностные обязанности, права и ответственность руководителя группы разработки [Наименование организации в родительном падеже] (далее — Компания).

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

1.3. Руководитель группы разработки подчиняется непосредственно [наименование должности непосредственного руководителя в дательном падеже] Компании.

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

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

1.6. Руководитель группы разработки отвечает за:

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

1.7. Руководитель группы разработки должен знать:

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

1.8. Руководитель группы разработки в своей деятельности руководствуется:

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

1.9. В период временного отсутствия руководителя группы разработки его обязанности возлагаются на [наименование должности заместителя].

2. Должностные обязанности

Руководитель группы разработки выполняет следующие должностные обязанности:

2.1. Планирование процесса разработки программного продукта.

2.2. Контроль исполнения планов разработки программного продукта.

2.3. Принятие управленческих решений о корректировке планов.

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

2.5. Инициирование разработки проектной и технической документации.

2.6. Контроль и оценка качества разработанной проектной и технической документации.

2.7. Принятие управленческих решений по результатам контроля и оценки качества разработанной проектной и технической документации (решение о приемке разработанной документации или возврате на доработку).

2.8. Анализ и согласование архитектуры ИР с заинтересованными сторонами.

2.9. Распределение заданий на проектирование ИР, структуры базы данных, программных интерфейсов.

2.10. Оценка качества проектирования ИР, структуры базы данных, программных интерфейсов.

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

2.12. Структурная декомпозиция работ.

2.13. Определение критериев (показателей) оценки сложности, трудоемкости, сроков выполнения работ.

2.14. Мониторинг и оценка по выбранным критериям (показателям) сложности, трудоемкости и сроков выполнения работ.

2.15. Принятие управленческих решений.

2.16. Распределение задач на проверку работоспособности ИР между исполнителями.

2.17. Оценка качества разработанных процедур отладки программного кода.

2.18. Оценка качества разработанных процедур сбора диагностических данных.

2.19. Оценка качества разработанных процедур измерения требуемых характеристик программного обеспечения.

2.20. Оценка качества тестовых наборов данных в соответствии с выбранной методикой.

2.21. Оценка результатов проверки работоспособности программного обеспечения.

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

2.23. Осуществление экспертной оценки архитектуры ИР.

2.24. Проведение технических советов по оценке вариантов архитектуры.

2.25. Выдача экспертных заключений по вариантам архитектуры ИР.

2.26. Выработка вариантов архитектурных решений на основе накопленного опыта.

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

3. Права

Руководитель группы разработки имеет право:

3.1. На все предусмотренные законодательством Российской Федерации социальные гарантии.

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

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

3.4. Подписывать и визировать документы в пределах своей компетенции.

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

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

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

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

3.9. Повышать свою профессиональную квалификацию.

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

3.11. Иные права, предусмотренные трудовым законодательством Российской Федерации.

4. Ответственность и оценка деятельности

4.1. Руководитель группы разработки несет административную, дисциплинарную и материальную (а в отдельных случаях, предусмотренных законодательством РФ, — и уголовную) ответственность за:

4.1.1. Невыполнение или ненадлежащее выполнение служебных указаний непосредственного руководителя.

4.1.2. Невыполнение или ненадлежащее выполнение своих трудовых функций и порученных ему задач.

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

4.1.4. Недостоверную информацию о состоянии выполнения порученной ему работы.

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

4.1.6. Не обеспечение соблюдения трудовой дисциплины.

4.2. Оценка работы руководителя группы разработки осуществляется:

4.2.1. Непосредственным руководителем — регулярно, в процессе повседневного осуществления работником своих трудовых функций.

4.2.2. Аттестационной комиссией предприятия — периодически, но не реже 1 раза в два года на основании документированных итогов работы за оценочный период.

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

5. Условия работы

5.1. Режим работы руководителя группы разработки определяется в соответствии с правилами внутреннего трудового распорядка, установленными в Компании.

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

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

6. Право подписи

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

С инструкцией ознакомлен ___________/____________/ «____» _______ 20__ г.

(подпись)

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

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

Итак, какие же есть должности в ИТ и кто за что отвечает? 

Техническая IT структура  

Для начала разберемся в более прозрачном и понятном, а именно в технической структуре компании. 

В разработке продукта могут принимать участие совершенно разные по назначению разработчики. Рядовые девелоперы обычно условно (или нет) делятся на:

• Junior- начинающих специалистов, опыт работы в среднем от полугода
• Middle- разработчик с опытом, но еще не профи, здесь практический опыт уже обычно 2-3 года
• Senior- ребята со стажем от 4-6 лет и до бесконечности. 

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

Ок, с джунами, мидлами и сеньорами приблизительно все понятно. А что же дальше?

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

Топ 10 самых востребованных IT специальностей в России в 2023 году: кого чаще всего нанимают, а кому больше всех платят

Team Lead

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

Tech Lead

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

СТО

Должность СТО (Chief Technical Officer) появляется либо в крупных ИТ компаниях, либо в мелких стартапах, но тогда без тимлидов и техлидов. В таком случае один человек  просто руководит всеми разработчиками и носит гордое, но неоправданное название СТО. Однако СТО все же это должность менеджерская и в полноценном объеме проявляется в крупных бизнесах, где сотни или даже тысячи разработчиков трудятся над десятками проектов, каждым из которых управляет техлид. 

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

Chief Architect

Должность появляется в действительно больших бизнесах со своей “историей”. Под последним подразумевается множество технических подходов и стеков, используемых для реализации продукта. На каждом этапе разработки может появится техлит или другой руководитель, который скажет: “Здесь будем делать так и никак иначе”, но проблема в том, что техлид другой части проекта ранее уже решил выбрать другой стек. И здесь начинается проблема, как же потом все это собрать в одно целое. А таких техлидов в крупных компаниях может быть не 2, а 2 десятка. Помимо этого сама разработка развивается, на смену старым приходят новые технологии и языки программирования и впоследствии все стеки наслаиваются и могут дублировать части проекта. В общем и целом проблем такого рода может быть много, и решать их как раз дело Chief Architect.

Architect

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

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

Профессии в сфере IT. Кто такие айтишники, чем они занимаются и сколько зарабатывают?

Продуктовая структура в ИТ компании

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

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

• дизайнеры
• аналитики
• маркетологи
• HR

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

Руководящие роли в продуктовой ИТ структуре

Project Manager (РМ)

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

Product Manager (РМ)

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

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

Product-менеджер и project-менеджер: в чем различие профессий простыми словами. Обязанности двух PM-ов

CPO

Chief Product Officer- позиция актуальна для действительно крупных бизнесов, где одновременно может разрабатываться и внедряться несколько взаимосвязанных продуктов. Эта должность считается побратимой СТО только для продуктовой части. СРО контролирует и синхронизирует работу всех менеджеров по продукту, а также делает все, чтобы никто из них со своей командой не “перетягивали одеяло на себя” в ущерб всему бизнесу. 

Product Owner

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

Топ менеджмент

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

СЕО

Chief Executive Officer- главный исполнительный директор, генеральный директор или директор всех директоров. Руководит всеми подразделениями в компании, отчитывается только перед советом директоров. 

CFO

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

COO

Chief Operations Officer- операционный директор. Руководит повседневными процессами и деятельностью организации.

СМО

Chief Marketing Officer- директор по маркетингу. В обязанности этого топа входит разработка и утверждение маркетинговой стратегии компании и ее новых продуктов. В подчинении у СМО все маркетологи, продажники, пиарщики и пр.

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

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

На кого переучиться в 2023 году, чтобы работодатели выстроились в очередь

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

Группы ролей

Роли в ИТ можно разделить по нескольким срезам:

• по активности;
• по ответственности;
• по загруженности.

Разделение по активности

• производители;
• управленцы;
• проверяющие.

Разделение по ответственности

• без ответсвенности
• с ответственностью за качество
• с финансовой ответственностью

Разделение по назначению

• нанимаемые на позицию;
• взращиваемые в коллективе.

Описание ролей

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

Developer

Характеристики:

• занимается производством программных алгоритмов;
• не несёт ответственности за применение результата и по финансовым рискам;
• нанимается на позицию.

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

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

Данная роль часто сегментируется по разделению ответственности:

• Back-end developer — разработчик программно-аппаратной части комплексного ПО;
• Front-end developer — разработчик клиентской стороны пользовательского интерфейса к программно-аппаратной части.

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

• Web;
• Mobile;
• Server-Side;

и так далее.

User Experience Designer (UX)

Характеристики:

• занимается производством карт пользовательского опыта;
• несёт ответственности за применение результата, но не несёт ответственность по финансовым рискам;
• нанимается на позицию.

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

Ошибочно эту руль путают, а порою и совмещают с ролью UI Designer (см. ниже). UX vs UI Designer отличаются не только предметной областью, но и спецификой мышления. UX Designer больше про про аналитику и систематизацию, чем про эргономику и эстетику.

User Interface Designer (UI)

Характеристики:

• занимается производством графической составляющей интерфейсов;
• не несёт ответственности за применение результата и по финансовым рискам;
• нанимается на позицию.

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

Quality Assurance (QA)

Характеристики:

• занимается проверкой результата
• не несёт ответственности за применение результата и по финансовым рискам;
• нанимается на позицию.

QA занимается тестированием всего, как бы странно это не звучало.

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

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

Human Resource (HR)

Характеристики:

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

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

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

Team Leader

Характеристики:

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

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

Разберём стериотипы и ошибки:

1. Team Leader всегда взращивается в среде, это единственный способ заработать авторитет в группе людей; нет авторитета, никто не будет слушать Team Leader, процессы будут идти своим путём;
2. Можно процесс взращивания ускорить, наняв одного из опытных Team Leader, но в коллектив он должен попасть сперва как рядовой специалист, заработать авторитет, только потом перейти на целевую позицию;
3. Роль больше не про управление командой, не про производство, а про решение проблем в работе команды, налаживание коммуникации внутри команды, выстраивание комфортных условий производства;
4. Team Leader обязан обладать аналитическими навыками и системным взглядом; просто делать, чтобы всем было “хорошо” не достаточно, основная задача — постоянное измерение внутренних метрик команды, как социальных, так и производственных, изменение процессов для повышение результативности.

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

Tech Leader

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

Особенностей всех ролей, в названии которых есть слово Leader, является то, что все они взращиваются в коллективе (см. выше).

Но данную роль я решил выделить, так как, на практике, её чаще всего путают с ролью Team Leader.

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

Tech Leader касается следующих аспектов работы команды:

1. Ответственный выбор стороннего ПО для проекта;
2. Рекомендация по выбору конкретного алгоритма или архитектурного решения при производстве ПО;
3. Определение технических особенностей в процессах производства.

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

Scrum Master

С появление терминов Scrum, Agile, KanBan, гибкие методологии, и прочие теоретические знания, которые крайне бесполезны без практики/опыта, к командам разработки стали прикреплять роль Scram Master.

Характеристики:

• отвечает за грамотный применения той или иной гибкой методологии (бывает, что даже той, которая не касается Scrum вообще);
• несёт частичную ответственность за результат, но не несёт ответственность по финансовым рискам;
• нанимается на позицию.

Почему я решил описать данную роль? Так сложилось, что эту роль часто путают с Project Manager.

Давайте проясним ситуацию. Scrum Master — это специалист, который помогает команде применять методологию Scrum правильно, объясняет правиал методологии, контролирует их выполнение.

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

Project Manager (PjM)

Характеристики:

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

Эта роль классического управленца процессами. Работа над проектом начинается с Project Manager`а, ведётся (ставятся задачи), контролируется (контроль качества и эффективности), и сдаётся тоже им. В большинстве компаний Project Manager управляет проектным фондом. Когда скорость реализации быстрее планируемых сроков проекта, проектный фонд утилизируется не полностью, остаётся часть денег, которые по результату успешной сдачи проекта распределяется на премии участников. Распределением также занимается Project Manager.

Станислав Триерс

эксперт программы для студентов Moove от бизнес-школы «Сколково» и МТС, гендиректор компании Tess Technology

Лучше всего рассматривать структуру команды в компаниях от 10 человек. В ней, как правило, также есть и второстепенные функции (бухгалтерия, юристы, клининг и т. д.). Их чаще всего отдают на аутсорс. Кроме того, в компании должны быть продавцы, маркетологи и HR.

На начальном этапе директор может справляться с частью функций сам (продавать, продвигать услуги, искать и нанимать сотрудников). Такая ситуация характерна, прежде всего, для стартапов, где команда может брать на себя все функции сразу. Так как это недавно запущенный проект, и его цель – окупить инвестиции и получить прибыль в максимально короткие сроки, директор может быть и продавцом, и разработчиком, и курьером. Однако чаще всего там уже есть деление на сферы ответственности. Например, в команде LICA (разрабатывают ИТ-продукт по подбору станков и тканей для текстильной промышленности), которую я курирую на программе Moove, кто-то взял на себя роль CEO, кто-то — CTO, а кто-то занялся продажами и общением с клиентами.

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

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

Этапы создания ПО:

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

На каждом этапе должен быть свой отдел со своими задачами:

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

Основной состав группы — это специалисты, полностью занятые в создании нового программного продукта:

• менеджеры проекта;
• программисты;
• тестировщики;
• разработчики документации;
• инженерные психологи;
• технологи по разработке ПО.

Вспомогательная группа — это специалисты, не занимающиеся созданием программ, но, тем не менее, играющие важную роль в реализации проекта:

• группа менеджмента и маркетинга продукта;
• специалисты по технической поддержке ПО;
• администраторы бета-тестирования.

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

Developer

Занимается производством программных продуктов.

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

по разделению ответственности:

• Backend developer — разработчик программно-аппаратной части комплексного ПО;
• Frontend developer — разработчик клиентской стороны пользовательского интерфейса к программно-аппаратной части.

по платформам:

• Web;
• Mobile;
• Server-Side;
• и так далее.

User Experience Designer (UX)

Занимается производством карт пользовательского опыта.

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

Эту роль ошибочно путают, а порою и совмещают с ролью UI Designer. UX и UI Designer отличаются не только предметной областью, но и спецификой мышления. UX Designer больше про аналитику и систематизацию, чем про эргономику и эстетику.

User Interface Designer (UI)

Занимается производством графической составляющей интерфейсов.

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

Quality Assurance (QA)

Занимается проверкой результата.

QA занимается тестированием всего, как бы странно это ни звучало.

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

Human Resource (HR)

Занимается первичным подбором кандидатов.

Он обеспечивает прозрачное прохождение всех этапов собеседований при трудоустройстве.

Team Leader

Отвечает за работу группы специалистов.

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

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

Tech Leader

Отвечает за грамотный аргументированный выбор технических решений:

1. Ответственный выбор стороннего ПО для проекта;
2. Рекомендация по выбору конкретного алгоритма или архитектурного решения при производстве ПО;
3. Определение технических особенностей в процессах производства.

Scrum Master

Scrum, Agile, KanBan, гибкие методологии, и прочие теоретические знания, которые крайне бесполезны без практики и опыта.

Scrum Master — это специалист, который помогает команде применять методологию Scrum правильно, объясняет правила методологии, контролирует их выполнение. Сейчас к командам разработки стали прикреплять роль Scram Master. Он отвечает за грамотное применение той или иной гибкой методологии (бывает, что даже той, которая не касается Scrum вообще).

Project Manager (PjM)

Отвечает за старт, ведение и сдачу проектных работ.

Эта роль классического управленца процессами. Работа над проектом начинается с Project Manager’а, ведётся (ставит задачи), контролируется (контроль качества и эффективности) и сдаётся тоже им. В большинстве компаний Project Manager управляет проектным фондом.

Архитектор (Architect)

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

Бизнес Аналитик (Business Analyst)

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

Системный аналитик (System Analyst)

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

Технический писатель (Technical writer)

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

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

Как устроены матричные структуры ИТ-компаний

Андрей Жикин, директор по информационным технологиям Yota

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

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

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

Организовать коммуникацию нам помогают несколько инструментов:

• На верхнем уровне помогает канбан портфеля проектов — доска, на которой в онлайн-формате регулярно синхронизируются задачи по ИТ, бизнесу, проработке проблем и прочим кейсам. Этот инструмент значительно повышает прозрачность, позволяет вовремя находить слабые места, а также выравнивать ожидания всех участников.
• На уровне проектного управления — Big Picture в Jira. Это инструмент для структуризации задач и объединения их в проекты, визуализированные диаграммами Ганта.
• На техническом уровне — описания в виде контрактов по API. Каждый проект перед стартом реализации получает описание, которое команды должны учитывать в рамках производства. Это упрощает коммуникацию на стадии разработки, так как ожидаемый результат описан достаточно четко и понятно.
• На уровне общих коммуникаций мы используем MS Teams как средство видеосвязи и «ТамТам» как мессенджер для кросс-функционального общения. Также взаимодействие сотрудников происходит в корпоративной группе во «ВКонтакте», через почтовые рассылки и реже через физические письма.

---

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

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

---

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

● MS Office 365 — отличное облачное решение для основных корпоративных потребностей;

● Jira — для структуризации задач;

● Confluence — база знаний;

● Trello/Miro — доска для Канбана.

Для управления проектами мы используем микс водопада и Agile. Например, Kanban используется как для внутренней работы команды, так и для управления портфелем проектов. Этот инструмент применяется также на уровне топ-менеджмента для внедрения глобальных изменений в компании. При этом для сохранения прогнозируемости и управляемости производства используются классические инструменты с диаграммами Ганта.

Микросервисная архитектура: каждому продукту своя команда

Игорь Калинин, основатель компании TWIN

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

Всего в штате компании 34 специалиста: большая их часть занимается разработкой, но в команде также есть тестировщики и Scrum-мастера, которые ставят задачи и контролируют их выполнение. В целом, Scrum — один из главных рабочих инструментов, но не единственный. Так, DevOps-команда и часть телефонистов используют Kanban. Мы стараемся комбинировать разные продукты, чтобы максимально эффективно организовать работу. Для коммуникации в команде используем одновременно и Telegram, и Slack, поскольку там удобно работать с кодом. А переговоры проводим в Google Meet.

В TWIN установлены довольно строгие правила отбора специалистов: отдаем предпочтение разработчикам senior-уровня и редко берем джуниоров. Большая часть команды — 80% — это старшие специалисты. Они же выступают в роли наставников для новичков, благодаря этому новый сотрудник быстрее прокачивает навыки — он одновременно обучается и тут же решает реальные рабочие задачи. Это большой стимул для роста и развития.

Деление на индустрии: точки соприкосновения и неформальное общение

Эдгарс Пузо, генеральный директор Atos в России и СНГ

Мы реализуем переход компании на организационную структуру по индустриям. В процессе перехода было выделено шесть индустрий: финансовые услуги и страхование, здравоохранение, промышленность, государственный сектор, ресурсы и услуги, телекоммуникации и СМИ. Кроме того, в компании развиваются такие технические направления, как Microsoft, SAP, Digital Workplace, Cloud и другие, которые закрепляются в практики. В России формат деления на практики на данный момент находится на фазе становления, но на глобальном уровне он уже успешно работает.

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

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

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

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

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

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

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

Для мотивации сотрудников существует программа Accolade — система признания внутри компании. Несколько раз в год награждаются сотрудники, которые достигли выдающихся результатов сверх стандартной работы. В программе предусмотрены разные уровни наград в зависимости от достижений: bronze, silver, gold. Иерархия должностей позволяет каждому сотруднику увидеть, в каких направлениях можно расти. А корпоративная культура, включающая в себя мероприятия, конкурсы, призы, а также всевозможные активности на платформе для геймификации, позволяет мотивировать сотрудников на более неформальном уровне.

Agile-команды: свобода принятия решений и открытые синки

Евгения Христолюбская, руководитель направления по работе с сотрудниками «Учи.ру»

У нас матричная структура компании: есть вертикали основных специализаций и гибкие продуктовые команды. Таких команд — около 15.

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

Такие команды обладают достаточной свободой принятия решений и (иногда) собственным бюджетом. Каждая развивает собственный «участок» платформы. Основная коммуникация ведется в почте и в Slack. Когда наша компания перешла на удаленку, мы приобрели платную версию, которая позволяет совершать звонки и хранит всю историю переписки. Для видеозвонков мы используем Zoom и Google Meet. Кроме того, на удаленке организовывать встречи стало удобнее: коллеги стали доступнее, лучше соблюдается тайминг и даже большие встречи организовывать теперь легко.

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

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

Особенное внимание в «Учи.ру» мы уделяем мотивации и обучения сотрудников. Для этого используются несколько инструментов:

• Регулярные АМА-сессии для сотрудников на YouTube (AMA, Ask Me Anything, от англ. «спроси меня о чем угодно» — «Хайтек»).
• Обучающие, поддерживающие, развивающие материалы на корпоративном портале.
• Регулярные email-рассылки с рекомендациями и предложениями по досугу и обучению.
• Квизы, фотоконкурсы и онлайн-корпоративы, организация активностей на праздники.
• Митапы в рамках программы #УЧИвУЧИ.
• Еженедельная сводка новостей держит сотрудников в курсе того, что происходит в компании и разных отделах.

Команды с уникальными компетенциями в разных частях страны

Константин Коногорский, заместитель директора по разработке ПО ВИСТ (входит в ГК «Цифра»)

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

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

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

Из сервисов для коммуникации мы используем Microsoft Teams, Jira и корпоративную почту. Но на самом деле это просто наши корпоративные инструменты для общения. В действительности же люди пользуются любыми инструментами, через которые им удобно вести коммуникацию.

Для распределения задач между командами и внутри команд мы используем современные Agile-методологии. Команды разработки работают по Scrum, а команды тестирования и DevOps — Kanban, в силу их немногочисленности.

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

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

---

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

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

Создана первая точная карта мира. Что не так со всеми остальными?

На них держится Вселенная: как работают четыре главные силы природы

Время на прочтение
4 мин

Количество просмотров 53K

Доброго времени!
У нас вышло 2-е издание книги «Путь аналитика. Практическое руководство IT-специалиста».

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

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

Об авторах

Андрей Дмитриевич Перерва
41 год. Master of Business Administration/Master of Business Information.
Опыт работы в индустрии разработки программного обеспечения — более 18 лет. На руководящих должностях — семь лет, из них три года в топ-менеджменте. В настоящее время специализируется на вопросах стратегического и тактического планирования, операционном управлении и управлении проектами компании по разработке ПО.

В своем карьерном развитии прошел все возможные позиции в сфере разработки ПО: работал программистом, проектировщиком и разработчиком БД, бизнес-аналитиком, системным аналитиком, архитектором, менеджером проекта, начальником отдела бизнес- и системного анализа. Принимал участие и руководил разработкой таких информационных систем, как система управления потоками работ (Workflow), Boeing Reference Engineering Data Automated Retrieval System, Customer Relationship Management System, система управления предприятием (Enterprise Management System), корпоративные порталы и системы комплексной автоматизации бизнеса. Имеет опыт организационного проектирования, создания функциональных отделов анализа с нуля, построения и развития команды, проведения обучающих тренингов для сотрудников и менеджеров компании.

Имеет практический опыт создания системы менеджмента качества (QMS) компании, построения процесса разработки ПО (SDLC) в соответствии с методологиями и стандартами RUP, Iconix, Agile, PMBOK, CMMI, ISO9001.

Вера Алексеевна Иванова
Опыт работы в ИT-сфере — 17 лет. Первые семь лет работала программистом в государственных учреждениях. Приобрела опыт разработки прикладного ПО с использованием СУБД, системного администрирования, технической поддержки пользователей. Участвовала во внедрении и сопровождении автоматизированных систем финансового учета регионального уровня.

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

Для кого эта книга

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

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

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

Чего вы не найдете в этой книге

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

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

Более подробно с книгой можно ознакомиться на сайте издательства
Оглавление
Отрывок

Для Хаброжителей скидка 25% по купону — Путь аналитика

Должностная инструкция руководителя группы (отдела) внедрения ИС (руководителя группы (отдела) сопровождения ИС)

(профессиональный стандарт «Специалист по информационным системам»)

1. Общие положения

1.1. На должность руководителя группы (отдела) внедрения ИС принимается лицо:
1) имеющее высшее образование — специалитет, магистратура, прошедшее повышение квалификации по программам обучения, рекомендованным производителем ИС;
2) имеющее опыт работы не менее полутора лет на предыдущем квалификационном уровне.
1.2. К работе в должности руководителя группы (отдела) внедрения ИС (или: руководителя группы (отдела) сопровождения ИС) допускается лицо, прошедшее обязательный предварительный (при поступлении на работу) и периодические медицинские осмотры (обследования), а также внеочередные медицинские осмотры (обследования) в порядке, установленном законодательством Российской Федерации.
1.3. Руководитель группы (отдела) внедрения ИС должен знать:
1) инструменты и методы управления требованиями;
2) технологии межличностной и групповой коммуникации в деловом взаимодействии, основы конфликтологии;
3) устройство и функционирование современных ИС;
4) современные стандарты информационного взаимодействия систем;
5) программные средства и платформы инфраструктуры информационных технологий организаций;
6) современные подходы и стандарты автоматизации организации (например, CRM, MRP, ERP… ITIL, ITSM);
7) основы теории систем и системного анализа;
методики описания и моделирования бизнес-процессов, средства моделирования бизнес-процессов;
9) системы классификации и кодирования информации, в том числе присвоение кодов документам и элементам справочников;
10) отраслевую нормативную техническую документацию;
11) источники информации, необходимой для профессиональной деятельности;
12) современный отечественный и зарубежный опыт в профессиональной деятельности;
13) формирование и механизмы рыночных процессов организации;
14) основы менеджмента, в том числе менеджмента качества;
15) основы финансового учета и бюджетирования;
16) основы управления взаимоотношениями с клиентами и заказчиками (CRM);
17) основы теории управления;
18) современные инструменты и методы управления организацией, в том числе методы планирования деятельности, распределения поручений, контроля исполнения, принятия решений;
19) методологию ведения документооборота в организациях;
20) инструменты и методы определения финансовых и производственных показателей деятельности организаций;
21) основы организационной диагностики;
22) инструменты и методы моделирования бизнес-процессов организации;
23) основы реинжиниринга бизнес-процессов организации;
24) диаграмму Ганта, метод «набегающей волны», типы зависимостей между работами;
25) оценку (прогнозирование) бюджетов и графиков: метод аналогов, экспертные оценки;
26) управление содержанием проекта: документирование требований, анализ продукта, модерируемые совещания;
27) управление качеством: контрольные списки, верификацию, валидацию (приемо-сдаточные испытания);
28) управление коммуникациями в проекте: базовые навыки управления (в том числе проведение презентаций, проведение переговоров, публичные выступления);
29) культуру речи;
30) правила деловой переписки;
31) методы оценки объемов и сроков выполнения работ;
32) технологии выполнения работ в организации;
33) каналы коммуникаций;
34) модели коммуникаций;
35) инструменты и методы управления заинтересованными сторонами;
36) инструменты и методы управления заинтересованными сторонами проекта;
37) основы информационной безопасности организации;
38) отчетность по проекту: подготовка отчетов об исполнении;
39) виды отчетности в проектах;
40) технологии подготовки и проведения презентаций;
41) ключевые возможности ИС;
42) управление изменениями;
43) архитектуру, устройство и функционирование вычислительных систем;
44) коммуникационное оборудование;
45) сетевые протоколы;
46) основы современных операционных систем;
47) основы современных систем управления базами данных;
48) основы налогового законодательства Российской Федерации;
49) основы управленческого учета;
50) основы международных стандартов финансовой отчетности (МСФО);
51) основы управления торговлей, поставками и запасами;
52) основы организации производства;
53) основы управления персоналом, включая вопросы оплаты труда;
54) основы управления организационными изменениями;
55) инструменты и методы моделирования бизнес-процессов в ИС;
56) инструменты и методы анализа функциональных разрывов;
57) предметную область автоматизации;
58) инструменты и методы выявления требований;
59) инструменты и методы выдачи и контроля поручений;
60) инструменты и методы анализа требований;
61) методы верификации требований к ИС;
62) инструменты и методы согласования требований;
63) инструменты и методы проектирования архитектуры ИС;
64) инструменты и методы верификации архитектуры ИС;
65) теорию баз данных;
66) системы хранения и анализа баз данных;
67) основы программирования;
68) современные методики тестирования разрабатываемых информационных систем;
69) основы менеджмента проектов;
70) инструменты и методы проектирования и дизайна ИС;
71) инструменты и методы верификации структуры программного кода;
72) инструменты и методы проектирования структур баз данных;
73) инструменты и методы верификации архитектуры и дизайна ИС;
74) современные методики тестирования разрабатываемых ИС. Инструменты и методы модульного тестирования, инструменты и методы тестирования нефункциональных и функциональных характеристик ИС;
75) инструменты и методы разработки пользовательской документации;
76) регламенты развертывания ИС;
77) управление коммуникациями в проекте: базовые навыки управления (в том числе проведение презентаций, проведение переговоров, публичные выступления);
78) инструменты и методы интеграции ИС;
79) форматы обмена данными;
80) интерфейсы обмена данными;
81) инструменты и методы оценки качества и эффективности ИС;
82) инструменты и методы оптимизации ИС;
83) основы управления изменениями в проектах;
84) управление договорными отношениями, в том числе управление претензиями;
85) управление изменениями в проектах;
86) юридические основы взаимоотношений между контрагентами;
87) основы системного администрирования;
88) основы финансового планирования;
89) стандарты в области качества, применимые к предметной области;
90) технологии выполнения работ по созданию (модификации) и сопровождению ИС;
91) инструменты и методы проведения аудитов качества;
92) инструменты и методы проведения приемо-сдаточных испытаний (валидации) ИС;
93) стандарты качества, применимые в предметной области;
94) рынок поставщиков товаров и услуг для создания (модификации) и ввода ИС в эксплуатацию;
95) методы управления несоответствующей продукцией;
96) основы конфигурационного управления;
97) инструменты и методы идентификации конфигурации;
98) системы контроля версий и поддержки конфигурационного управления;
99) инструменты и методы отчетности по статусу конфигурации;
100) инструменты и методы аудита конфигураций;
101) типы (формы) договоров;
102) методы разрешения конфликтов;
103) основы управления качеством;
104) инструменты и методы согласования документации в проектах;
105) методы организации обучения;
106) методы формирования команды;
107) групповую динамику команд;
108) методы управления конфликтами;
109) методы мотивации персонала;
110) методы оценки эффективности работы персонала в проекте;
111) основные этапы проведения организационных изменений;
112) основы управления проектами;
113) основы общего управления организацией;
114) управление коммуникациями в проекте: базовые навыки управления (в том числе проведение презентаций, ведение переговоров, публичные выступления);
115) возможности ИС;
116) иностранный язык (чтение и понимание технической литературы);
117) ……………. (другие требования к необходимым знаниям)
1.4. Руководитель группы (отдела) внедрения ИС должен уметь:
1) проводить переговоры;
2) планировать работы;
3) выдавать поручения и контролировать их выполнение;
4) разрабатывать регламентные документы;
5) анализировать входную информацию;
6) проводить презентации;
7) работать с записями по качеству (в том числе с корректирующими действиями, предупреждающими действиями, запросами на исправление несоответствий);
анализировать исходную документацию;
9) распределять работы и выделять ресурсы;
10) контролировать исполнение;
11) разрабатывать регламентную документацию;
12) проектировать архитектуру ИС;
13) проверять (верифицировать) архитектуру ИС;
14) тестировать результаты прототипирования;
15) проверять (верифицировать) архитектуру и дизайн ИС;
16) разрабатывать документацию;
17) устанавливать права доступа к файлам и папкам;
18) планировать движение денежных средств;
19) знать основы финансового планирования;
20) анализировать исходные данные;
21) анализировать входные данные;
22) контролировать выполнение поручений;
23) знать основы конфигурационного управления;
24) устанавливать права доступа на файлы и папки;
25) использовать системы контроля версий;
26) осуществлять коммуникации;
27) разрабатывать проектную документацию;
28) знать основы управления качеством;
29) проводить рабочие и формальные согласования документации в проектах;
30) управлять персоналом;
31) ……………. (другие навыки и умения)
1.5. Руководитель группы (отдела) внедрения ИС в своей деятельности руководствуется:
1) ……………. (наименование учредительного документа)
2) Положением о ……………. (наименование структурного подразделения)
3) настоящей должностной инструкцией;
4) ……………. (наименования локальных нормативных актов, регламентирующих трудовые
функции по должности)
1.6. Руководитель группы (отдела) внедрения ИС подчиняется непосредственно ……………. (наименование должности руководителя)
1.7. ……………. (другие общие положения)

2. Трудовые функции

2.1. Выполнение работ и управление работами по сопровождению и проектами создания (модификации) ИС, автоматизирующих задачи организационного управления и бизнес-процессы:
1) организационное и технологическое обеспечение определения первоначальных требований заказчика к ИС и возможности их реализации в ИС;
2) организационное и технологическое обеспечение инженерно-технической поддержки подготовки и согласования коммерческого предложения с заказчиком;
3) организационное и технологическое обеспечение планирования коммуникаций с заказчиками при выполнении работ;
4) идентификация заинтересованных сторон в больших проектах и программах проектов;
5) создание инструментов и методов распространения информации о ходе выполнения работ;
6) управление заинтересованными сторонами проекта в больших проектах и программах проектов;
7) разработка инструментов и методов документирования существующих бизнес-процессов организации заказчика (реверс-инжиниринга бизнес-процессов организации);
разработка инструментов и методов проектирования бизнес-процессов заказчика;
9) разработка инструментов и методов адаптации бизнес-процессов заказчика к возможностям ИС;
10) планирование управления требованиями;
11) организационное и технологическое обеспечение выявления требований;
12) разработка инструментов и методов анализа требований;
13) организационное и технологическое обеспечение согласования и утверждения требований;
14) экспертная поддержка разработки архитектуры ИС;
15) экспертная поддержка разработки прототипов ИС;
16) организационное и технологическое обеспечение проектирования и дизайна ИС;
17) организационное и технологическое обеспечение разработки баз данных ИС;
18) подтверждение исправления дефектов и несоответствий в архитектуре и дизайне ИС;
19) организационное и технологическое обеспечение создания пользовательской документации к ИС;
20) организационное и технологическое обеспечение развертывания ИС у заказчика;
21) организационное и технологическое обеспечение интеграции ИС с существующими ИС у заказчика;
22) организационное и технологическое обеспечение оптимизации работы ИС;
23) планирование управления изменениями;
24) организационное и технологическое обеспечение анализа запросов на изменение;
25) согласование запросов на изменение в проекте;
26) проверка реализации запросов на изменение в проекте;
27) принятие мер по неразглашению информации, полученной от заказчика;
28) принятие мер для своевременной оплаты заказчиками работ по созданию (модификации) и сопровождению ИС;
29) планирование качества выполнения работ по созданию (модификации) и вводу ИС в эксплуатацию;
30) организационно-технологическая поддержка процесса обеспечения качества;
31) организационное и технологическое обеспечение процесса контроля качества;
32) организационное и технологическое обеспечение проведения приемо-сдаточных испытаний ИС;
33) организационное и технологическое обеспечение закупок;
34) планирование конфигурационного управления;
35) организационное и технологическое обеспечение идентификации конфигурации;
36) организационное и технологическое обеспечение ведения отчетности по статусу конфигурации ИС;
37) организационное и технологическое обеспечение аудита конфигурации ИС;
38) организация репозитория проекта создания (модификации) ИС;
39) управление выпуском релизов ИС;
40) планирование управления договорами на выполняемые работы, связанные с ИС;
41) организационное и технологическое обеспечение заключения договоров на выполняемые работы;
42) организационное и технологическое обеспечение мониторинга и управления исполнением договоров на выполняемые работы;
43) организационное и технологическое обеспечение заключения дополнительных соглашений к договорам на выполняемые работы;
44) организационное и технологическое обеспечение закрытия договоров на выполняемые работы;
45) организационное и технологическое обеспечение регистрации запросов заказчика;
46) организационное и технологическое обеспечение заключения договоров сопровождения ИС;
47) организационное и технологическое обеспечение обработки запросов заказчика по вопросам использования ИС;
48) организационное и технологическое обеспечение инициирования работ по реализации запросов, связанных с использованием ИС;
49) организационное и технологическое обеспечение выполнения запросов заказчика;
50) планирование управления документацией;
51) организация согласования документации в проектах;
52) организация утверждения документации в проекте;
53) управление распространением документации в проекте;
54) организационное обеспечение командообразования и развития персонала;
55) управление эффективностью работы персонала в проекте;
56) разработка и согласование регламентов и процедур для офиса управления проектами;
57) формирование предложений по развитию офиса управления проектами в организации;
58) …………….
2.2. ……………. (другие функции)

3. Должностные обязанности

3.1. Руководитель группы (отдела) внедрения ИС исполняет следующие обязанности:
3.1.1. В рамках трудовой функции, указанной в пп. 1 п. 2.1 настоящей должностной инструкции:
1) планирует работы по определению первоначальных требований заказчика к ИС и возможности их реализации в ИС;
2) назначает и распределяет ресурсы;
3) контролирует исполнение.
3.1.2. В рамках трудовой функции, указанной в пп. 2 п. 2.1 настоящей должностной инструкции:
1) планирует работы по подготовке коммерческого предложения в части объема и сроков выполнения работ по созданию (модификации) и вводу ИС в эксплуатацию и согласованию коммерческого предложения с заказчиком;
2) назначает и распределяет ресурсы;
3) контролирует исполнение.
3.1.3. В рамках трудовой функции, указанной в пп. 3 п. 2.1 настоящей должностной инструкции:
1) производит выбор и разработку инструментов и методов управления коммуникациями с заказчиками;
2) осуществляет выбор и разработку инструментов и методов разработки стратегии управления заинтересованными сторонами в проекте.
3.1.4. В рамках трудовой функции, указанной в пп. 4 п. 2.1 настоящей должностной инструкции:
1) анализирует заинтересованные стороны в больших проектах и программах проектов;
2) создает реестр заинтересованных сторон;
3) осуществляет экспертную поддержку по вопросам идентификации заинтересованных сторон в проектах и программах проектов.
3.1.5. В рамках трудовой функции, указанной в пп. 5 п. 2.1 настоящей должностной инструкции:
1) разрабатывает типовые инструменты и методы распространения информации о ходе выполнения работ;
2) разрабатывает рекомендации по выбору каналов коммуникаций;
3) разрабатывает формы отчетности и адаптирует их для конкретных проектов;
4) разрабатывает типовые инструменты и методы получения обратной связи от заинтересованных сторон.
3.1.6. В рамках трудовой функции, указанной в пп. 6 п. 2.1 настоящей должностной инструкции:
1) управляет ожиданиями заинтересованных сторон проекта в больших проектах и программах проектов;
2) инициирует запросы на изменения (в том числе запросы на корректирующие действия, на предупреждающие действия, на исправление несоответствий) в больших проектах и программах проектов.
3.1.7. В рамках трудовой функции, указанной в пп. 7 п. 2.1 настоящей должностной инструкции:
1) разрабатывает инструменты и методы сбора исходных данных у заказчика;
2) разрабатывает и выбирает инструменты и методы описания бизнес-процессов.
3.1.8. В рамках трудовой функции, указанной в пп. 8 п. 2.1 настоящей должностной инструкции:
1) разрабатывает инструменты и методы сбора исходных данных у заказчика;
2) разрабатывает и выбирает инструменты и методы проектирования бизнес-процессов.
3.1.9. В рамках трудовой функции, указанной в пп. 9 п. 2.1 настоящей должностной инструкции:
1) разрабатывает инструменты и методы сбора исходных данных у заказчика;
2) разрабатывает и выбирает инструменты и методы моделирования бизнес-процессов в ИС;
3) разрабатывает и выбирает инструменты и методы анализа функциональных разрывов.
3.1.10. В рамках трудовой функции, указанной в пп. 10 п. 2.1 настоящей должностной инструкции:
1) разрабатывает план управления требованиями;
2) согласовывает план управления требованиями с заинтересованными сторонами;
3) утверждает план управления требованиями.
3.1.11. В рамках трудовой функции, указанной в пп. 11 п. 2.1 настоящей должностной инструкции:
1) организует сбор данных о запросах и потребностях заказчика;
2) организует анкетирование представителей заказчика;
3) организует интервьюирование представителей заказчика;
4) контролирует качество документирования собранных данных.
3.1.12. В рамках трудовой функции, указанной в пп. 12 п. 2.1 настоящей должностной инструкции:
1) разрабатывает и выбирает инструменты и методы анализа требований;
2) осуществляет экспертную поддержку анализа требований.
3.1.13. В рамках трудовой функции, указанной в пп. 13 п. 2.1 настоящей должностной инструкции:
1) организует согласование и утверждение требований заказчиком;
2) назначает и распределяет ресурсы;
3) контролирует исполнение.
3.1.14. В рамках трудовой функции, указанной в пп. 14 п. 2.1 настоящей должностной инструкции:
1) осуществляет экспертную оценку предложенных вариантов архитектуры ИС;
2) проводит технические советы по оценке вариантов архитектуры;
3) выдает экспертные заключения по вариантам архитектуры ИС;
4) вырабатывает варианты архитектурных решений на основе накопленного опыта.
3.1.15. В рамках трудовой функции, указанной в пп. 15 п. 2.1 настоящей должностной инструкции:
1) проводит экспертную оценку предложенного прототипа ИС;
2) проводит технические советы по оценке прототипа ИС;
3) выдает экспертные заключения по прототипам ИС;
4) вырабатывает варианты реализации прототипов ИС на основе накопленного опыта.
3.1.16. В рамках трудовой функции, указанной в пп. 16 п. 2.1 настоящей должностной инструкции:
1) обеспечивает соответствие проектирования и дизайна ИС принятым в организации или проекте стандартам и технологиям;
2) назначает и распределяет ресурсы;
3) контролирует исполнение.
3.1.17. В рамках трудовой функции, указанной в пп. 17 п. 2.1 настоящей должностной инструкции:
1) обеспечивает соответствие баз данных ИС и процесса их разработки принятым в организации или проекте стандартам и технологиям;
2) назначает и распределяет ресурсы;
3) контролирует исполнение.
3.1.18. В рамках трудовой функции, указанной в пп. 18 п. 2.1 настоящей должностной инструкции:
1) проверяет результат внесенных исправлений дефектов и несоответствий в архитектуре и дизайне ИС;
2) фиксирует в системе учет факта внесения исправлений в архитектуре и дизайне ИС.
3.1.19. В рамках трудовой функции, указанной в пп. 19 п. 2.1 настоящей должностной инструкции:
1) обеспечивает соответствие пользовательской документации к ИС и процесса ее разработки принятым в организации или проекте стандартам и технологиям;
2) назначает и распределяет ресурсы;
3) контролирует исполнение.
3.1.20. В рамках трудовой функции, указанной в пп. 20 п. 2.1 настоящей должностной инструкции:
1) обеспечивает соответствие процесса развертывания ИС у заказчика принятым в организации или проекте стандартам и технологиям;
2) назначает и распределяет ресурсы;
3) контролирует исполнение;
4) осуществляет экспертную поддержку развертывания ИС у заказчика.
3.1.21. В рамках трудовой функции, указанной в пп. 21 п. 2.1 настоящей должностной инструкции:
1) обеспечивает соответствие процесса интеграции ИС у заказчика принятым в организации или проекте стандартам и технологиям;
2) назначает и распределяет ресурсы;
3) контролирует исполнение;
4) осуществляет экспертную поддержку интеграции ИС с существующими ИС заказчика;
5) осуществляет экспертную поддержку разработки технологий обмена данными между ИС и существующими системами.
3.1.22. В рамках трудовой функции, указанной в пп. 22 п. 2.1 настоящей должностной инструкции:
1) обеспечивает соответствие процесса оптимизации работы ИС принятым в организации или проекте стандартам и технологиям;
2) назначает и распределяет ресурсы;
3) контролирует исполнение;
4) осуществляет экспертную поддержку оптимизации работы ИС.
3.1.23. В рамках трудовой функции, указанной в пп. 23 п. 2.1 настоящей должностной инструкции:
1) разрабатывает план управления изменениями;
2) согласовывает план управления изменениями с заинтересованными сторонами проекта;
3) утверждает план управления изменениями.
3.1.24. В рамках трудовой функции, указанной в пп. 24 п. 2.1 настоящей должностной инструкции:
1) обеспечивает соответствие процесса анализа изменений принятым в организации или проекте стандартам и технологиям;
2) назначает и распределяет ресурсы;
3) контролирует исполнение;
4) осуществляет экспертную поддержку анализа запросов на изменение.
3.1.25. В рамках трудовой функции, указанной в пп. 25 п. 2.1 настоящей должностной инструкции:
1) представляет результаты анализа влияния запрошенных изменений на основные параметры проекта заинтересованным сторонам проекта;
2) согласовывает необходимость внесения изменений с ключевыми заинтересованными сторонами и спонсором проекта.
3.1.26. В рамках трудовой функции, указанной в пп. 26 п. 2.1 настоящей должностной инструкции:
1) проверяет фактическое внесение изменений в проект;
2) изменяет статус проверенных запросов на изменение в проекте в системе учета.
3.1.27. В рамках трудовой функции, указанной в пп. 27 п. 2.1 настоящей должностной инструкции:
1) разрабатывает договоры о неразглашении информации, полученной от заказчика;
2) согласовывает договоры о неразглашении информации, полученной от заказчика;
3) подписывает у ответственных лиц договоры о неразглашении информации, полученной от заказчика;
4) разграничивает права доступа к репозиторию проекта.
3.1.28. В рамках трудовой функции, указанной в пп. 28 п. 2.1 настоящей должностной инструкции:
1) планирует и согласовывает финансирование работ по созданию (модификации) и сопровождению ИС с заказчиком;
2) контролирует своевременность поступления оплаты за выполненные работы.
3.1.29. В рамках трудовой функции, указанной в пп. 29 п. 2.1 настоящей должностной инструкции:
1) определяет стандарты в области качества, которым необходимо следовать при выполнении работ;
2) разрабатывает регламенты по управлению качеством;
3) согласовывает регламенты по управлению качеством с заинтересованными сторонами;
4) утверждает регламенты по управлению качеством.
3.1.30. В рамках трудовой функции, указанной в пп. 30 п. 2.1 настоящей должностной инструкции:
1) разрабатывает планы проведения аудитов;
2) разрабатывает регламенты обеспечения качества;
3) обеспечивает соответствие процесса проведения аудитов принятым стандартам и технологиям;
4) назначает и распределяет ресурсы;
5) контролирует исполнение.
3.1.31. В рамках трудовой функции, указанной в пп. 31 п. 2.1 настоящей должностной инструкции:
1) производит выбор и разработку инструментов и методов контроля качества исполнения процессов и внесенных изменений;
2) внедряет инструменты и методы контроля качества;
3) назначает и распределяет ресурсы;
4) контролирует исполнение.
3.1.32. В рамках трудовой функции, указанной в пп. 32 п. 2.1 настоящей должностной инструкции:
1) производит выбор и разработку инструментов и методов проведения приемо-сдаточных испытаний ИС;
2) внедряет инструменты и методы проведения приемо-сдаточных испытаний ИС;
3) назначает и распределяет ресурсы;
4) контролирует исполнение.
3.1.33. В рамках трудовой функции, указанной в пп. 33 п. 2.1 настоящей должностной инструкции:
1) разрабатывает регламенты планирования закупок для создания (модификации) и ввода ИС в эксплуатацию;
2) разрабатывает и согласовывает перечни предпочитаемых поставщиков ИТ-продуктов;
3) разрабатывает критерии выбора поставщиков;
4) обеспечивает соответствие процесса выбора поставщиков принятым в организации или проекте стандартам и технологиям;
5) осуществляет экспертную поддержку выбора поставщиков;
6) обеспечивает соответствие процесса исполнения закупок принятым в организации или проекте стандартам и технологиям;
7) осуществляет экспертную поддержку исполнения закупок;
обеспечивает соответствие процесса закрытия закупок принятым в организации или проекте стандартам и технологиям;
9) осуществляет экспертную поддержку закрытия закупок.
3.1.34. В рамках трудовой функции, указанной в пп. 34 п. 2.1 настоящей должностной инструкции:
1) разрабатывает план и регламенты конфигурационного управления;
2) разрабатывает правила именования и версионирования базовых элементов конфигурации;
3) разрабатывает правила использования репозитория проекта;
4) разрабатывает план резервирования и архивирования репозитория проекта.
3.1.35. В рамках трудовой функции, указанной в пп. 35 п. 2.1 настоящей должностной инструкции:
1) производит выбор и разработку инструментов и методов идентификации конфигурации;
2) внедряет инструменты и методы идентификации конфигурации;
3) назначает и распределяет ресурсы;
4) обеспечивает соответствие процессов идентификации конфигурации ИС принятым в организации или проекте стандартам и технологиям.
3.1.36. В рамках трудовой функции, указанной в пп. 36 п. 2.1 настоящей должностной инструкции:
1) производит выбор и разработку инструментов и методов отчетности по статусу конфигурации;
2) внедряет инструменты и методы представления отчетности по статусу конфигурации ИС;
3) назначает и распределяет ресурсы;
4) обеспечение соответствия процессов представления отчетности о статусе конфигурации ИС принятым в организации или проекте стандартам и технологиям.
3.1.37. В рамках трудовой функции, указанной в пп. 37 п. 2.1 настоящей должностной инструкции:
1) производит выбор и разработку инструментов и методов аудитов конфигурации ИС;
2) внедряет инструменты и методы аудитов конфигурации ИС;
3) назначает и распределяет ресурсы;
4) контролирует исполнение.
3.1.38. В рамках трудовой функции, указанной в пп. 38 п. 2.1 настоящей должностной инструкции:
1) создает репозиторий для хранения базовых элементов конфигурации НС проекта создания (модификации) ИС;
2) определяет права доступа для репозитория проекта создания (модификации) ИС.
3.1.39. В рамках трудовой функции, указанной в пп. 39 п. 2.1 настоящей должностной инструкции:
1) определяет состав релизов ИС и разрабатывает план выпуска релизов ИС;
2) согласовывает план выпуска релизов ИС с заказчиком;
3) изменяет план выпуска релизов ИС на основе одобренных запросов на изменения;
4) обеспечивает выполнение плана выпуска релизов ИС;
5) контролирует состав выпущенных релизов ИС.
3.1.40. В рамках трудовой функции, указанной в пп. 40 п. 2.1 настоящей должностной инструкции:
1) определяет перечень и типы договоров на выполняемые работы, которые необходимо заключить;
2) разрабатывает график заключения договоров на выполняемые работы;
3) планирует денежные потоки, необходимые для выполнения условий договоров на выполняемые работы.
3.1.41. В рамках трудовой функции, указанной в пп. 41 п. 2.1 настоящей должностной инструкции:
1) разрабатывает типовые формы договоров на выполняемые работы и регламентов заключения договоров на выполняемые работы;
2) обеспечивает соответствие процессов заключения договоров в организации или проекте принятым формам и регламентам;
3) осуществляет экспертную поддержку работ по заключению договоров на выполняемые работы.
3.1.42. В рамках трудовой функции, указанной в пп. 42 п. 2.1 настоящей должностной инструкции:
1) производит выбор и разработку инструментов и методов мониторинга и управления договорами на выполняемые работы;
2) внедряет инструменты и методы мониторинга и управления договорами на выполняемые работы;
3) обеспечивает соответствие процессов мониторинга и управления договорами на выполняемые работы принятым в организации или проекте стандартам и технологиям;
4) осуществляет экспертную поддержку в решении спорных вопросов.
3.1.43. В рамках трудовой функции, указанной в пп. 43 п. 2.1 настоящей должностной инструкции:
1) разрабатывает регламенты заключения дополнительных соглашений к договорам на выполняемые работы;
2) обеспечивает соответствие процессов заключения дополнительных соглашений к договорам в организации или проекте принятым формам и регламентам;
3) осуществляет экспертную поддержку работ по заключению дополнительных соглашений к договорам на выполняемые работы.
3.1.44. В рамках трудовой функции, указанной в пп. 44 п. 2.1 настоящей должностной инструкции:
1) разрабатывает регламенты закрытия договоров на выполняемые работы;
2) обеспечивает соответствие процессов закрытия договоров в организации или проекте принятым формам и регламентам;
3) осуществляет экспертную поддержку в урегулировании проблем.
3.1.45. В рамках трудовой функции, указанной в пп. 45 п. 2.1 настоящей должностной инструкции:
1) производит выбор и разработку инструментов и методов регистрации запросов заказчика;
2) внедряет инструменты и методы регистрации запросов заказчика;
3) обеспечивает соответствие процессов регистрации запросов заказчика принятым в организации или проекте стандартам и технологиям.
3.1.46. В рамках трудовой функции, указанной в пп. 46 п. 2.1 настоящей должностной инструкции:
1) разрабатывает типовые формы договоров сопровождения ИС и регламентов заключения договоров сопровождения ИС;
2) обеспечивает соответствие процессов заключения договоров сопровождения ИС в организации или проекте принятым формам и регламентам;
3) осуществляет экспертную поддержку работ по заключению договоров сопровождения ИС.
3.1.47. В рамках трудовой функции, указанной в пп. 47 п. 2.1 настоящей должностной инструкции:
1) разрабатывает регламенты обработки запросов заказчика по вопросам использования ИС;
2) обеспечивает соответствие процессов обработки запросов заказчика в организации или проекте принятым формам и регламентам;
3) осуществляет экспертную поддержку обработки запросов заказчика по вопросам использования ИС.
3.1.48. В рамках трудовой функции, указанной в пп. 48 п. 2.1 настоящей должностной инструкции:
1) разрабатывает регламенты инициирования работ по реализации запросов, связанных с использованием ИС;
2) обеспечивает соответствие процессов инициирования работ по реализации запросов в организации или проекте принятым формам и регламентам;
3) осуществляет экспертную поддержку инициирования работ по реализации запросов, связанных с использованием ИС.
3.1.49. В рамках трудовой функции, указанной в пп. 49 п. 2.1 настоящей должностной инструкции:
1) разрабатывает регламенты закрытия запросов заказчика;
2) обеспечивает соответствие процессов закрытия запросов заказчика в организации или проекте принятым формам и регламентам.
3.1.50. В рамках трудовой функции, указанной в пп. 50 п. 2.1 настоящей должностной инструкции:
1) разрабатывает план управления документацией;
2) согласовывает план управления документацией с заинтересованными сторонами проекта;
3) утверждает план управления документацией.
3.1.51. В рамках трудовой функции, указанной в пп. 51 п. 2.1 настоящей должностной инструкции:
1) проводит рабочие согласования документации в проектах;
2) проводит формальные согласования документации в проектах.
3.1.52. В рамках трудовой функции, указанной в пп. 52 п. 2.1 настоящей должностной инструкции:
1) утверждает документацию в команде проекта;
2) утверждает документацию у заказчика.
3.1.53. В рамках трудовой функции, указанной в пп. 53 п. 2.1 настоящей должностной инструкции:
1) обеспечивает использование актуальных версий документов;
2) обеспечивает заинтересованные стороны проекта необходимыми документами;
3) оповещает о выпуске новых и обновлении существующих документов в проекте.
3.1.54. В рамках трудовой функции, указанной в пп. 54 п. 2.1 настоящей должностной инструкции:
1) производит выбор и разработку инструментов и методов командообразования и развития персонала;
2) внедряет инструменты и методы командообразования и развития персонала;
3) оказывает консультационную поддержку командообразования и развития персонала.
3.1.55. В рамках трудовой функции, указанной в пп. 55 п. 2.1 настоящей должностной инструкции:
1) осуществляет оценку работы персонала в проекте;
2) проводит оценку эффективности мероприятий по развитию персонала в проекте;
3) инициирует изменения в планах управления персоналом в проекте.
3.1.56. В рамках трудовой функции, указанной в пп. 56 п. 2.1 настоящей должностной инструкции:
1) разрабатывает и согласовывает процессы и инструкции по выполнению работ в проектах создания (модификации) ИС для офиса управления проектами;
2) разрабатывает и согласовывает шаблоны рабочих документов проектов создания (модификации) ИС для офиса управления проектами;
3) разрабатывает и согласовывает механизмы мониторинга и контроля выполнения работ в проектах для офиса управления проектами.
3.1.57. В рамках трудовой функции, указанной в пп. 57 п. 2.1 настоящей должностной инструкции:
1) инициирует корректирующие и предупреждающие действия в отношении системы управления компанией;
2) разрабатывает предложения по совершенствованию системы управления компанией в рамках инициированных корректирующих и предупреждающих действий.
3.1.58. В рамках выполнения своих трудовых функций исполняет поручения своего непосредственного руководителя.
3.1.59. ……………. (другие обязанности)
3.2. ……………. (другие положения о должностных обязанностях)

4. Права

4.1. Руководитель группы (отдела) внедрения ИС имеет право:
4.1.1. Знакомиться с проектами решений директора организации, касающихся деятельности направления (подразделения).
4.1.2. Подписывать и визировать документы в пределах своей компетенции.
4.1.3. Инициировать и проводить совещания по производственно-хозяйственным и финансово-экономическим вопросам.
4.1.4. Запрашивать и получать от структурных подразделений необходимую информацию, документы.
4.1.5. Проводить проверки качества и своевременности исполнения поручений.
4.1.6. Требовать прекращения (приостановления) работ (в случае нарушений, несоблюдения установленных требований и т.д.), соблюдения установленных норм, правил, инструкций; давать указания по исправлению недостатков и устранению нарушений.
4.1.7. Вносить на рассмотрение руководства организации представления о приеме, перемещении и увольнении работников, о поощрении отличившихся работников и о применении дисциплинарных взысканий к работникам, нарушающим трудовую и производственную дисциплину.
4.1.8. Требовать от руководства организации оказания содействия в исполнении своих должностных обязанностей и прав.
4.2. ……………. (иные права)

5. Ответственность

5.1. Руководитель группы (отдела) внедрения ИС привлекается к ответственности:
— за ненадлежащее исполнение или неисполнение своих должностных обязанностей, предусмотренных настоящей должностной инструкцией, — в порядке, установленном действующим трудовым законодательством Российской Федерации, законодательством о бухгалтерском учете;
— правонарушения и преступления, совершенные в процессе своей деятельности, — в порядке, установленном действующим административным, уголовным и гражданским законодательством Российской Федерации;
— причинение ущерба организации — в порядке, установленном действующим трудовым законодательством Российской Федерации.
5.2. ……………. (другие положения об ответственности)

6. Заключительные положения

6.1. Настоящая должностная инструкция разработана на основе Профессионального стандарта «Специалист по информационным системам», утвержденного Приказом Министерства труда и социальной защиты Российской Федерации от 18.11.2014 N 896н, с учетом ……………. (реквизиты локальных нормативных актов организации)
6.2. Ознакомление работника с настоящей должностной инструкцией осуществляется при приеме на работу (до подписания трудового договора).
Факт ознакомления работника с настоящей должностной инструкцией подтверждается …………….
(подписью в листе ознакомления, являющемся неотъемлемой частью настоящей инструкции (в журнале ознакомления с должностными инструкциями); в экземпляре должностной инструкции, хранящемся у работодателя; иным способом)
6.3. ……………. (другие заключительные положения)

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

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

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

4. Свобода в разработке стратегии компании в области информационных технологий, в организации и проведении аудитов. В ведении CIO таким образом находятся все аспекты развития организации в этой сфере и контроль за выполнением требований специалистами отдела.

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

   

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

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

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

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

Ответственность сотрудника

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

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

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

• Любые нарушения правил внутреннего трудового распорядка, трудовой дисциплины, правил техники безопасности и противопожарной безопасности.

9 основных принципов работы директора по управлению информационными технологиями

Рассмотрим базовые принципы, на которые должен опираться CIO в своей работе.

1. Бизнес-ориентированность

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

2. Архитектурная целостность

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

3. Системность

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

   

4. Измеримость

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

5. Экспертиза

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

   • изучить вопрос самостоятельно, то есть потратить массу времени и не быть уверенным в конечном результате;

   • выслушать мнение специалистов собственной компании;

   • обратиться к сторонним профессионалам и получить квалифицированное экспертное заключение.

6. Инновационность

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

   

7. Публичность

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

8. Единоличная ответственность

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

   • результат работ будет на порядок хуже, ведь каждый старается справиться со своим этапом и не видит общей картины;

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

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

9. Справедливость

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

8 типов специалистов такого рода

Сегодня сложно найти сферы бизнеса, в которых не применялись бы современные цифровые технологии. Следовательно, и руководители IT-служб вынуждены брать на себя несколько смежных обязанностей. Аналитики компаний Deloitte, KPMG и Gartner выделили основные типажи директоров таких подразделений:

Надежный исполнитель

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

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

Бизнес-соавтор

Начальники службы информатизации, которые не боятся брать на себя ответственность за определение направления развития предприятия, входит в 36 % руководителей IT-службы, названных компанией Deloitte бизнес-соавторами. Они активно налаживают взаимодействие между возглавляемой ими службой и собственниками бизнеса, стремясь приносить реальную пользу.

Посредник

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

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

Интегратор

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

Дирижер

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

Зачинщик перемен

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

ИТ-директор+

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

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

Лидер

Будущее за такими руководителями информационных подразделений, которым удалось занять в компании позицию топ-менеджера — инициатора внедрения современных цифровых технологий. Для этого IT-директор должен уметь доказывать необходимость применения тех или иных инноваций, обосновывать бюджет на их освоение и в целом ориентировать предприятие на использование технологических новинок в работе каждого подразделения. По итогам аналитики Deloitte, такими способностями обладают не более 10 % действующих начальников службы информатизации.

Уровень заработной платы IT-директора

Большинство вакансий (96 %) предполагает полную занятость. Есть работодатели, которые ищут претендентов на должность руководителя информационного отдела для выполнения отдельных проектов (2 %) и на сокращенный день (2 %). Соответственно виду занятости предлагается различный уровень дохода.

В среднем IT-директорам платят около 110 тысяч рублей в месяц, причем оклад варьируется в зависимости от опыта работы:

• От 1 до 3 лет — 60 тыс. руб.

• От 3 до 6 лет — 95 тыс. руб.

• Более 6 лет — 133 тыс. руб.

Если говорить о минимальной и максимальной ежемесячной ставке, то в России это 39 и 520 тысяч рублей соответственно.

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

Требования к директору по информационным технологиям

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

В числе наиболее распространенных требований, предъявляемых к соискателям:

• Высшее образование.

• Сертификаты об окончании дополнительных курсов.

• Знание методов защиты информации.

• Умение разбираться в сетевых технологиях и протоколах.

• Навыки разработки программного обеспечения, а также администрирования Windows- и *nix-систем.

• Умение использовать в работе современные методики и практики организации IT-деятельности.

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

  

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

• Умение взаимодействовать с внешней бизнес-средой.

• Навыки создания IT-архитектуры в соответствии со стандартами.

• Знание основ разработки технической документации.

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

• Задатки лидера.

• Аналитический склад ума.

• Умение организовать работу отдела.

• Способность к прогнозированию.

• Знание азов психологии для взаимодействия с персоналом.

• Коммуникабельность.

• Креативность.

• Стрессоустойчивость.

• Высокий уровень самоорганизации.

• Умение выделять главное.

• Ответственность.

• Целеустремленность.

• Способность к быстрому освоению новых знаний.

Поиски компетентного специалиста

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

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

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

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

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

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

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

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

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

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

10 признаков не готовых к эффективной работе кандидатов

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

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

1. Кандидат работал на каждом из предыдущих мест 1-2 года

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

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

2. Речь соискателя переполнена профессиональными терминами

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

3. Вместо «я» говорит «мы»

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

4. Имеет опыт управления в самых разных отраслях

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

5. Допускает грубые ошибки в тексте резюме

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

   

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

6. Игнорирует типовые правила составления резюме

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

7. Непоследовательно излагает информацию

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

8. Уверяет, что знает абсолютно все системы

   Если кандидат заявляет, что одинаково блестяще разбирается в FreeBSD, Photoshop, Windows, Word, Active Directory, AutoCad, SQL и Delphi, перед вами самоуверенный новичок. Работник с опытом хорошо понимает, в чем он силен, а о чем знает лишь в общих чертах. Претендент на должность руководителя, имеющий достаточный опыт деятельности в IT-сфере, никогда не станет делать подобных заявлений. От него требуется правильно организовать работу подчиненных, используя их профессиональный потенциал.

   

9. Указывает в резюме конкретные модели оборудования

   Такой шаг оправдан только в одном случае: речь идет об уникальных проектах, где используется по-настоящему редкое техническое и программное оснащение. Если соискатель пишет, что «настраивал Cisco 851 и D-Link 1100», это говорит о его компетентности не более чем фраза «выдавливал сок из апельсина при помощи кухонного комбайна Bosch MUM48SL». Важен не опыт использования конкретного оборудования, а понимание принципа его функционирования.

10. Не способен назвать измеримые результаты своего труда на предыдущем месте

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

Основные KPI для директора по информационным технологиям

KPI (Key Performance Indicators — ключевые показатели эффективности) позволяют оценить степень достижения поставленных целей в количественном выражении. Для IT-сферы эта система подведения итогов деятельности используется весьма активно, благодаря ей результаты работы CIO и его подчиненных можно измерить при помощи числовых индикаторов.

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

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

Для оценки эффективности деятельности CIO применяют несколько универсальных индикаторов.

Критерий SLA

SLA (Service Level Agreement) переводится с английского как «соглашение об уровне сервиса». Этот показатель отмечает, в какой степени оказываемые IT-службой услуги соответствуют требованиям топ-менеджмента компании. Для этого используется конкретное числовое значение: к примеру, вот эта система в рабочее время должна быть доступна на 99,9 %. Оговаривается и временной промежуток, за который производится измерение. Так, для 99,9 %, в зависимости от периода, простой не должен превышать:

• 8,76 ч./год;

• 43,2 мин./месяц;

• 10,1 мин./неделю.

Это значит, что при определении контрольного промежутка «раз в месяц» нарушением условий соглашения будет 45-минутный простой за 30 дней.

Умение руководителя работать с персоналом

Для оценки этого качества IT-директора могут применяться следующие показатели:

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

• доля специалистов, прошедших сертификацию (40 % и выше);

• число сотрудников организации, деятельность которых обеспечивается одним работником департамента информационного обеспечения. Многие компании придерживаются показателя 1:150, однако многое зависит от специфики бизнеса, количества филиалов и уровня автоматизации бизнес-процессов.

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

Контроль соблюдения бюджета

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

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

Удовлетворенность пользователей

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

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

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

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

Соответствие целям компании

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

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

Расчет KPI осуществляется ежегодно. За меньший период сложно сделать выводы об эффективности работы IT-директора. Для установления планируемых показателей берут KPI предыдущего руководителя информационного подразделения и прибавляют к ним 20 %.

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

Облако тегов

Понравилась статья? Поделитесь: