It технологии разработки компании руководство

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

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

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

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

Жизненный цикл разработки IT-продукта

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

• Планирование

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

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

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

• Дизайн

После планирования наступает черед UX/UI дизайнеров — специалистов, которые проектируют пользовательские интерфейсы. Дизайнеры занимаются изучением поведения пользователей и выстраиванием понятного человеку интерфейса. Визуальный вид продукта — также результат работы дизайнеров.

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

• Разработка

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

Итерации в Agile называются спринтами, и в один спринт входят работы по всем направлениям: планирование, дизайн, разработка, тестирование.

• Тестирование

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

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

• Поддержка

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

Этап 1: Идея

Заказчик — печатная компания из штатов. По всему миру эта индустрия переживает не лучшие времена, но в США печатные компании остаются на плаву благодаря инновационным технологиям. Печатная компания обратилась к нам с просьбой разработать приложение для дополненной реальности — Augmented Reality, AR.

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

Этап 2: Контакт

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

Этап 3: Планирование

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

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

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

Комментарий менеджера проекта Александра:
«Я отвечаю за непрерывный ход проекта. Я выбрал Scrum-методологию, чтобы быстро реагировать на запросы заказчика и рынка. Scrum помогает нам развивать продукт, учитывать потребности пользователей в каждом релизе продукта, и использовать в разработке самые современные технологии».

Этап 4: Дизайн

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

Этап 5: Разработка и тестирование

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

На первом этапе разработки команда состояла из:

• Менеджера проектов, который также выполнял задачи бизнес-аналитика;
• UX/UI дизайнера;
• команды разработчиков.

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

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

• Менеджер проектов;
• Бизнес-аналитик с более широким кругом задач, чем были у менеджера до этого;
• UX/UI дизайнер;
• разработчики;
• руководитель команды разработчиков (Team Lead);
• Системный архитектор, разработавший структуру продукта;
• Специалист по тестированию;
• DevOps — связующее звено между разработкой и эксплуатацией, работал с сетью и развертыванием продукта.

Руководитель команды разработчиков Игорь внес свои нововведения:
«В этом проекте я отвечаю за выполнение задач проекта, провожу рецензию кода, планирую спринты (итерации в разработке), ввожу новые задачи. Я предложил проводить юнит-тесты с помощью GitFlow и создавать код при помощи AWS Lambda. Я также ввожу в курс дела новых членов команды, отвечаю за их адаптацию”.

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

Бизнес-аналитик Флор рассказывает:
“Благодаря организации проекта, моя работа была предельно ясной и эффективной. Я обрабатывал запросы клиентов и в понятном и технически точном виде передавал их команде разработчиков. Я работал в тандеме с UX/UI дизайнером, а наш проект менеджер был ответственным за переговоры, что дало мне возможность сфокусироваться на моих основных задачах»,

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

Этап 6: Поддержка

Поддержка обычно осуществляется на 3 уровнях:

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

Существует также нулевой уровень поддержки через брошюры и руководства по эксплуатации.

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

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

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

Генрик Мкртчян — сооснователь и генеральный директор агентства веб-разработки «Кодеры», рассказал, как под ключ организовать процесс разработки в компании: от постановки задач до релиза продукта.

У нас есть два основных принципа:

1. Команда делает проекты качественно, в срок и с прибылью для компании;
2. Большинство решений, связанных с реализацией проектов, команда принимает самостоятельно, так как основные процессы в компании автоматизированы и прозрачны.

Проект любого масштаба мы разделяем на семь обязательных этапов.

1. Выбираем методологию

От этого зависит состав команды, порядок и даже график работы. Можно выбрать классическую (waterfall) или гибкую (agile). 

При классической методологии:

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

При гибкой методологии:

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

Если вам нужно быстро запустить MVP-версию продукта и понять, в каком направлении его развивать – выбирайте гибкую методологию.

2. Определяем роли и состав команды

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

Классический отдел разработки состоит из следующих сотрудников:

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

• frontend- и backend-разработчик/fullstack-разработчик: первые занимаются визуальной и вычислительной частью проекта, а второй, как универсальный солдат, владеет знаниями разных технологий;

• тестировщик: обеспечивает качество программного продукта с самого начала разработки и до его финальной сдачи;

• тимлид: декомпозирует и делегирует задачи, проводит код-ревью и поддерживает боевой дух команды;

• дизайнер: определяет внешний вид продукта, его интерфейс и юзабилити;

• аналитик: проектирует и оптимизирует процессы, руководит внедрением новых IT-систем и адаптирует систему работы к новым задачам;

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

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

3. Проводим CustDev, собираем требования с клиентов, пишем техническое задание

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

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

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

4. Обеспечиваем команду техническими инструментами

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

Настройте:

• репозиторий для кодовой базы проекта;
• общие инструменты организации процесса разработки, если они нужны – например, таск-трекер (Jira, Redmine, Trello и другие);
• рабочее окружение: сервисы и приложения, от которых будет зависеть ваш продукт (например, Swagger для документации API).

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

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

---

Читайте также:
Разработка мобильного приложения: как создать прототип и зачем нужен MVP
Кроссплатформенная и нативная разработка мобильных приложений в 2021 году
12 шагов к успешному запуску детского приложения

---

5. Планируем работу команды

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

Составляя график, учитывайте сдвиг сроков задач (например, увеличение сроков из-за исправлений ошибок) и продумайте, как одна задача зависит от другой.

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

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

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

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

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

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

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

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

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

---

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

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

---

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

---

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

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

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

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

Приветствую в это нелегкое время. Я продолжаю цикл статей для предпринимателей и несколько следующих хочу посвятить краеугольному камню любого 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 человек, и проседание любого из них сильно ухудшит итоговый результат команды. Это делает рекрутинг одним из важнейших факторов успеха.

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

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

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

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

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

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

   

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

   

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

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

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

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

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

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

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

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

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

   

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Посредник

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

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

Интегратор

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

Дирижер

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

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

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

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

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

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

Лидер

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

   

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

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

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

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

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

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

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

   

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

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

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

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

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

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

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

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

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

Критерий SLA

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

• 8,76 ч./год;

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Облако тегов

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