Бизнес структура it компании

Оглавление

Введение

Уже много лет назад, в статье «Ненужная ИТ-служба» (CIO, N1-2, 2011), был высказан провокационный вопрос: «А может ИТ-служба совсем не нужна?».

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

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

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

СТРУКТУРА И БИЗНЕС-ПРОЦЕССЫ

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

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

Источники информации по оргструктуре ИТ

Есть ряд методик проектирования оргструктур предприятий в целом. А вот литературы по оргструктурам ИТ-служб почти нет.

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

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

1. Оргструктура ИТ-службы: что надо рассмотреть для ее планирования на 1 год и более

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

Какой должна быть структура небольшой компании (короткая версия)

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

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

Требования бизнеса к оргструктуре ИТ-службы

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

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

2. Взаимоотношения ИТ-службы с пользователями: кто прав, кто виноват, где ослы? Реальная история про безымянного программиста и товарища Суслова, члена Политбюро ЦК КПСС

Взаимоотношения с пользователями можно рассмотреть с трех сторон:

а) Взгляд на ИТ со стороны пользователей;

Ох, я вырасту быком, пойду волком выти”

Борис Гребенщиков, “Максим-Лесник”

б) Взгляд на пользователей со стороны ИТ;

в) Взгляд на ИТ со стороны руководства компании.

а) Взгляд на ИТ со стороны пользователей

• Все время у них что-то ломается;
• Приходится все выяснять самим;
• Вовремя ничего не дождешься;
• На ИТ уходит слишком много денег.

Вот типовая точка зрения пользователей об ИТ-службе (см. Рис. 1):
Рис. 1. Типовая картина взаимоотношений с ИТ (точка зрения пользователей)

б) Взаимоотношение ИТ-службы и пользователей

А вот точка зрения сотрудников ИТ на взаимоотношение с пользователями:

• Сами не знают, чего хотят, слишком часто меняют свои требования;
• Руки кривые;
• Инвестиции в ИТ недостаточны.

Рис. 2. Типовая картина взаимоотношений с пользователями (точка зрения сотрудников ИТ)

Но если вместо “ИТ-службы” написать “Бухгалтерия” или ”Отдел маркетинга”, то суть претензий будет такой же.

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

Смотрят в окно на белый свет.

А в нашем полку — все камикадзе,

Кто все успел — того здесь нет.

Борис Гребенщиков, «Центр Циклона»

На рядовых пользователей сильное впечатление производила схема инфраструктуры, особенно когда на нее накладывали схему программ. Пользователи смотрели и говорили: «Да, мы все понимаем чисто по-человечески».

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

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

в) Взгляд на ИТ со стороны руководства компании

Как руководители предприятия могут видеть ИТ-службу и пользователей ИТ (см. Рис. 3):

Я точно такой же, только хуже,
И я говорю то, что знаю — Козлы!

Борис Гребенщиков, «Козлы»

• Очень высоки риски ИТ: если что-то сломается, полкомпании потом работать не может;
• У пользователей ИТ и руки кривые, и «хотелок» многовато;
• Плохая поддержка ИТ, разработка – еще хуже;
• Затраты на ИТ высоки и не прогнозируемы.

Рис. 3. Взгляд на ИТ со стороны руководства компании

К вопросу об оценке ИТ со стороны руководства

(история встречи рядового програмиста, АЦПУ и товарища Суслова, члена Политбюро ЦК КПСС)

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

Итак, вот история о товарище Суслове и АЦПУ. Произошла она в 1970-х годах, когда рассказчик этой истории сам был молодым специалистом, которого по распределению отправили работать в важный государственный Вычислительный Центр (впрочем, других тогда и не было).

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

Зачем приехал тов. Суслов, уже никто не помнит, но показуху готовили долго и серьезно.

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

К приходу в ВЦ тов. Суслова запустили тест компьютера. Это была ЕС ЭВМ размером с несколько шкафов. На этих шкафах мигали разноцветные лампочки, как гирлянды на елке в Новый год, несколько АЦПЦ одновременно печатали дамп памяти. Кто не знает что такое «дамп памяти», то это уже не важно.

Делегация обошла весь ВЦ, после чего тов. Суслов один подошел к АЦПУ, возле которого с деловым видом стоял наш молодой сотрудник ИТ, и сказал ему:

«Вы — молодой человек. Мне не хотелось бы портить Вашу карьеру, да и начальника ВЦ снимать…».

Молодой сотрудник смертельно побледнел. Кто жил при власти коммунистов, его поймет.

«Я надеюсь, Вы исправите этот недостаток, и такого больше не повторится».

Молодой сотрудник увидел лучик света в своем ожидаемом беспросветно черном будущем.

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

После этих слов тов. Суслов удалился, а сотрудник выдохнул, но запомнил этот случай на всю жизнь. Начальник ВЦ понимал, как работает АЦПУ и никаких взысканий не сделал. Хотя и премию не дал.

P.S. Если кто не понял, в чем было дело: тогдашние АЦПУ печатали не на страницах, а на рулоне бумаги. При этом с каждой стороны рулона по 5-10 см (сколько точно, я сам уже не помню) использовались для протяжки бумаги, и на них ничего нельзя было напечатать в принципе. Важное лицо государства этого не знало, но оргвыводы сделало быстро и легко.

Примечание. АЦПУ: Алфавитно-Цифровое Печатающее Устройство. Так назывались принтеры еще лет 20 назад.

3. Тенденции развития оргструктур ИТ-служб

Далее рассмотрены некоторые общие тенденции в области оргструктур ИТ-служб [все эти тенденции относятся к ИТ-службам предприятий, а не к ИТ-компаниям, для которых ИТ является основным бизнесом]:

1. Централизация ИТ-служб;
2. Использование процессных и проектных подходов;
3. Переход от поддержки технических средств к оказанию ИТ-сервисам;
4. Постепенное перемещение сотрудников ИТ в аутсорсинговые компании.

Рассмотрим эти тенденции более подробно.

Централизация ИТ

Эволюция ИТ-служб начиналась от централизации ИТ в рамках вычислительных центров. С появлением персональных компьютеров начался период децентрализации. Сейчас опять наблюдается тренд к централизации ИТ. (см. Рис. 4).

Рис. 4. Одним из трендов развития ИТ является централизация ИТ

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

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

Использование процессных и проектных подходов

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

Рис. 5. В ИТ-службах используется и функциональная, и проектная, и процессная организация работ

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

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

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

б) проектный подход: сотрудники работают по конкретным проектам, как правило, по внедрению программного обеспечения;

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

Переход от поддержки технических средств и информационных систем к ИТ сервисам

За последние тридцать лет ИТ-службы как в США и ЕС, так и в России перешли от понимания своей основной задачи как поддержки работоспособности технических средств к предоставлению ИТ сервисов (см. Рис. 6)
Как сейчас помню, во времена СССР чуть ли не половина усилий сотрудников ИТ уходила на поддержание работоспособности компьютера (большие ЕС ЭВМ или Mainframe, как их сейчас называют). В штате ИТ-служб, которые я видел в конце 80-х годов, электронщиков было больше, чем программистов (кто не знает, электронщики – это инженеры по поддержке аппаратной части компьютеров, сейчас почему-то их чаще называют «электрониками», звучит странно, особенно, если вы смотрели фильм «Приключения Электроника». На одну ЕС ЭВМ требовалось 5-10 электронщиков, только для работы в одну смену).
Широко известная (хотя и только в узких кругах ИТ-шников) методология ITIL как раз и олицетворяет этот тренд.

Рис. 6. Одним из трендов развития ИТ является постепенный переход к управлению ИТ как бизнесом

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

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

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

4. Типовые подразделения ИТ-служб

Желательно, чтобы подразделения ИТ-службы соответствовали основным направлениям работ по ИТ:

• поддержка ИТ;
• разработка и внедрение информационных систем;
• планирование и управление.

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

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

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

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

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

Большинство руководителей знает, что стили управления различными подразделениями могут отличаться. Например, опоздание на работу оператора службы поддержки ИТ, даже минут на 10 надо пресекать. Как, впрочем, и задержки на работе сотрудников службы поддержки, скорее всего, совсем ни к чему (если, конечно, авралов нет).

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

Типовые подходы к управлению различными подразделениями ИТ-службы приведены на Табл. 1:

Табл. 1. Подходы к управлению различными подразделениями ИТ-службы

Источник: www.info-strategy.ru

Организационная структура ИТ: Типы, примеры и советы

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

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

Что такое организационная структура ИТ?

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

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

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

• Цели: Знание того, какие проблемы решает ИТ-команда в рамках бизнеса, может показать, какую структуру следует использовать.

• Бизнес-цели: Эффективные организационные структуры ИТ обычно согласуются с общими целями бизнеса и способствуют повышению эффективности и прибыли.

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

• Техническая поддержка
• Кибербезопасность
• Архитектура предприятия
• Администрирование сети
• Операции по разработке (DevOps)

Преимущества организационной структуры в ИТ

Существуют различные причины, по которым организационная структура полезна для ИТ-команд, в том числе:

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

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

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

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

Типы организационных структур ИТ

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

Функциональная организационная структура

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

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

Структура независимых сервисных линий

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

Рычажная структура

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

Гибридная структура

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

Централизованная vs. децентрализованные организационные структуры

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

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

Примеры организационных структур ИТ

Здесь приведены примеры организационных структур ИТ на рабочем месте:

Пример 1

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

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

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

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

Пример 2

Николас — ИТ-менеджер, который контролирует команду из 12 ИТ-специалистов. У каждого члена команды своя роль: три специалиста занимаются установкой оборудования, четыре специалиста — сетевым администрированием, а пять специалистов работают в качестве техников справочной службы для решения проблем с программным обеспечением и вопросов по всей организации. Команда также работает вместе для поддержки различных технологических потребностей проектов в масштабах всей организации. Например, они могут создавать веб-сайт для маркетинговой команды, находить и устанавливать программное обеспечение для финансовой команды и заниматься аудиовизуальными потребностями при проведении презентаций.

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

Советы по внедрению организационной структуры ИТ

Вот несколько советов, которые вы можете рассмотреть при использовании организационных структур ИТ в вашем отделе:

Назначьте конкретные функции

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

Создание более мелких команд

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

Облегчение процедур эскалации

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

Ключевые слова:

• indeed.com

Источник: hr-portal.ru

Не только разработчики: типичная структура компании по разработке ПО

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

Источник: James Harrison / Unsplash

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

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

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

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

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

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

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

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

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

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

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

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

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

Developer

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

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

1. По разделению ответственности:

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

2. По платформам:

• 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)

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

Читайте статью в первоисточнике: tproger.ru

Источник: www.skolkovo.ru