Группы руководство 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)

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

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

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

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. ……………. (другие заключительные положения)

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

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

Человека, возглавляющего подразделение по информационным технологиям, в российских компаниях нередко называют IT-директор (от английского Information Technology Director). За рубежом используется аббревиатура CIO (Chief Information Officer), то есть «главный по вопросам информации».

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

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

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

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

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

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

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

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

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

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

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

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