Занимательный менеджмент в IT, или Как лебедь, рак и щука управляют компанией

krylov.jpg

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

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

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

Рак тянет назад – в IT это эксплуатационный блок (в который входит служба поддержки). Эти ребята находятся на «передовой» – именно они принимают на себя удар пользователей «у меня не работает» или «почему я не могу это сделать». В споре «чем жертвовать» они однозначно склоняются к фиксации качества, но понимают его иначе, чем производственный блок. У первых в показателях может быть устойчивость архитектуры к изменениям и прохождение автоматизированных тестов. Вторые же за качество принимает отсутствие инцидентов (как компромисс – инциденты по известным проблемам) и простоту обслуживающих процессов. Исходя из этого, эксплуатационщики склонны сопротивляться всем изменениям продукта, к проблемам и процессам обслуживания которого они уже привыкли.

Сильная команда – это когда ее участники своими сильными сторонами уравновешивают слабые стороны других членов коллектива. Понимая причины склонности той или иной силы к тем или иным решениям, мы имеем отличную возможность построить устойчивую систему, так как направление «вперед» – это баланс между всеми тремя векторами. «Щука – менеджер проекта» не даст «лебедю-архитектору» улететь в заоблачные выси инновационных технологий, напоминая, что кушать хочется «здесь и сейчас». «Рак – эксплуатационщик» не позволит лебедю и щуке разогнать компанию до такой скорости изменений, что они оторвутся от реальных требований заказчика (или потребностей в выбранном сегменте рынка). Лебедь, в свою очередь, не дает организации застыть на месте.

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

Непосредственно модель менеджмента удобнее всего строить на основе системы сбалансированных показателей. Про нее, уверен, знает каждый. Но, как показывает мой опыт, большинство делает акцент на слове «показатель», в то время как «соль» метода кроется в слове «сбалансированный». Для того чтобы уравновешивать, давайте определим сначала «локальные» (действующие только для одного направления) параметры. Мы их будем расставлять на основе «сильных» сторон каждого направления, ведь именно они являются естественными мотиваторами. И проверить правильность (работоспособность) показателя можно очень легко: если при его отмене у подразделения зажигается «огонь» в глазах: «Ух, сейчас мы заживем, именно этого нам и не хватало», – значит, параметр выделен верно.

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

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

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

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

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

Итого, если кратко резюмировать, для успешного управления IT-компанией, необходимо:

1. Разделение ответственности за производственную, проектную и эксплуатационную деятельность;
2. Наличие показателей деятельности каждого направления, которые можно считать и сравнивать во времени;
3. Балансировка всех параметров при необходимости изменения показателей одного направления;
4. Пересчет значений по новой методике перед ее внедрением.

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

Источник изображения: pixabay.com

Эта публикация была размещена на предыдущей версии сайта и перенесена на нынешнюю версию. После переноса некоторые элементы публикации могут отражаться некорректно. Если вы заметили погрешности верстки, сообщите, пожалуйста, по адресу correct@e-xecutive.ru
Комментарии
Преподаватель, Москва

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

Управляющий директор, Эстония

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

CIO, Москва
Очередная попытка ввести читателя в заблуждение. Модели как таковой нет, пресловутые параметры четко не определены, управляющее воздействие - тем более. Разочарован. Менеджмент на уровне общих слов?
Владимир, я специально привожу конкретные показатели, которые можно считать для направлений - на основании сильных сторон. Посмотрите, пожалуйста, на абзацы, которые начинаются со слов ''Сильная сторона...''. Даже если Вы запустите систему управления только с ними - Вы уже сможете почувствовать разницу. Выделять более конкретные показатели можно только для каждой конкретной компании, познакомившись с ее процессами. А уж тем более назначать какие-то конкретные значения. ''Управляющие воздействия не определены'' - если Вы имеете ввиду механизмы исполнения (административные, мотивационные, организационные), то да, статья посвящена не этому.
Прикольно, что фирма работает «сама на себя», а пользователь, для которого по идее предназначена продукция фирмы, полностью исключён из схемы.
Иван, в данном случае мы управляем компанией. Пользователи могут влиять на целеполагание, а на механизмы достижения этих не могут. Например, неужели Вы пустите пользователя в процесс создания методики оценки юзабельности пользовательского интерфейса? Или позволите выбирать, с помощью какого софта Вы будете оптимизировать документооборот в компании?
Директор по развитию, Екатеринбург

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

CIO, Москва
Вообще-то, все эти вопросы должны быть отрегулированы на фазе концепции проекта...
Вадим, описанная модель не подходит для управления проектом. Банально - пока проект не реализован в нем нем эксплуатации как таковой. А эксплуатация готовой системы - не проект: нет ни ограничения по срокам, ни уникального результата. Это модель тактического управления компанией. По сути, ответ на вопрос ''как достичь стратегических целей компании''.
Исполнительный директор, Москва
Максим Никитин пишет: Это модель тактического управления компанией. По сути, ответ на вопрос ''как достичь стратегических целей компании''.
Ну, уважаемый, это Вы ЗРЯ сделали такое заявление!! Это потому ЗРЯ, что сначала Ваша статья воспринимается как некоторая шутка юмора на тему … И в такой шутливой статье допустимы неточности ошибки и всякая дребедень … Но заявляя о том, что написанное есть модель «…тактического управления» и «…достижения стратегических целей» нужно отвечать «за базар» ;-)). А «базар» в том, что многие сентенции в Ваше статье как минимум спорные, а некоторые НЕ ВЕРНЫЕ. На таком базисе утверждать о модели «тактического управления» и, даже страшно сказать, «..достижения стратегических целей» не серьезно. Все мои высказывания ограничены следующим: 1. Анализируется компания по производству Программных продуктов и Услуг. 2. Точка зрения – директор компании. 3. Место наблюдения – внутри компании. При таких ограничениях я заявляю: 1. Цитата: [COLOR=blue=blue]«Лебедь стремится вверх – в IT это производственный блок. Он витает в стратосфере новых технологий»[/COLOR] [COLOR=red=red]Это не верно![/COLOR] Производство – это процессная часть компании, работающая по жестким технологическим правилам. Шаг в сторону – расстрел. Только через жесткие технологические правила и процедуры можно управлять качеством разработки ПП (программных продуктов) 2. Цитата: [COLOR=blue=blue]« Поэтому менеджеры в этой сфере склонны максимально бороться за сроки. В условиях ограниченного бюджета – а он всегда ограничен: не рублем, так трудовым ресурсом – основной претендент на «выбывание» в споре – это качество».[/COLOR] [COLOR=red=red]Это не верно[/COLOR] в части «выбывание» в споре – это качество! На нашем рынке жесткой конкуренции «качество» есть основное конкурентное преимущество. В основном компании, о которых я говорю, жертвуют БЮДЖЕТОМ. Значительно выгоднее получить «убыток» на одном проекте, но потом получить с рынка еще 5 (пять) проектов. 3. Цитата:[COLOR=blue=blue] «Рак тянет назад – в IT это эксплуатационный блок (в который входит служба поддержки)»[/COLOR]. Аллегория с Раком, пятившимся назад [COLOR=red=red]совершенно не уместна[/COLOR]. Службы внедрения и сопровождения вместе с маркетологами определяют ТЕНДЕНЦИИ рынка. С ними тесно работает аккаунт-менеджеры. Этот отряд, я считаю ПЕРЕДОВОЙ отряд, сильно влияет на тактику поведения на рынке и естественно на управление компанией. Мне кажется, что Вам следует говорить не о компании производящей Программные продукты и услуги , а о подразделении Информационных технологий в какой то Другой по профилю компании. И говорить от имени Руководителя этим подразделением. В моей парадигме это: 1. Анализируется «подразделение IT» компании не связанной с производством и продажей IT-услуг. 2. Точка зрения – руководитель подразделения 4. Место наблюдения – внутри компании. Хотя и при этих ограничениях, по-моему, следует действовать по-другому.
CIO, Москва
Валерий, спасибо за Ваш комментарий. Попробую если не возразить, то рассказать о причинах, которые подвигли меня именно к таким выводам. Ограничения для модели я рассматривал такие же, как приведены у Вас в начале: отдельная ИТ-компания, директор компании, внутри компании.
1. Цитата: «Лебедь стремится вверх – в IT это производственный блок. Он витает в стратосфере новых технологий» Это не верно! Производство – это процессная часть компании, работающая по жестким технологическим правилам. Шаг в сторону – расстрел. Только через жесткие технологические правила и процедуры можно управлять качеством разработки ПП (программных продуктов)
Любые нормы и правила нарабатываются не один год. Их цель - постоянно на выходе получать продукт заданного качества. Если данный регулятор убрать, то у нас есть два основных варианта развития событий: 1. Мы будем получать продукт с качественными характеристиками, сильно превышающими текущие потребности, в ущерб срокам 2. Мы будем получать продукт низкого качества, за счет чего сроки выхода той или иной функциональности будут увеличиваться Это говорит о том, что основная ценность, которую привносят производственники (системные аналитики, архитекторы, программисты, тестировщики) - это именно качество. Теперь посмотрим на первый вариант развития событий. Из-за чего он возможен? Из-за того, что производственники нацелены на постоянное улучшение ради улучшений. К примеру, вопрос ''сделать костыль или переписать ядро'' у производственников практически всегда имеет однозначный ответ: ''переписать ядро''. При этом анализа целесообразности данного выбора в конкретной текущей ситуации не происходит.
2. Цитата: « Поэтому менеджеры в этой сфере склонны максимально бороться за сроки. В условиях ограниченного бюджета – а он всегда ограничен: не рублем, так трудовым ресурсом – основной претендент на «выбывание» в споре – это качество». Это не верно в части «выбывание» в споре – это качество! На нашем рынке жесткой конкуренции «качество» есть основное конкурентное преимущество. В основном компании, о которых я говорю, жертвуют БЮДЖЕТОМ. Значительно выгоднее получить «убыток» на одном проекте, но потом получить с рынка еще 5 (пять) проектов.
Я не уверен, что именно менеджер проекта имеет полномочия решать ''профукать данный проект ради будущих свершений или нет''? Наверняка это решение человека, близкого по иерархии к директору компании. Следовательно, принимается исходя из того баланса ''сроки-качество-бюджет'', которое характерно для конкретного момента. Банально - если ЗП сотрудников привязана к конкретному проекту, то вариант ''сдать этап с меньшим качеством, но сдать'' достаточно вероятен. Второй пример из реальной жизни - все проекты, которые не закрываются до конца года, встают на ''паузу'', так как у заказчика переход неизрасходованных средств с одного года на другой - только через защиту данного переноса на бюджетом комитете. А это - доп затраты и риски. Следовательно, выбор тоже не однозначен. Но более важным фактором ''в мою пользу'' является факт, что все эти решения принимаются не на уровне менеджера проектов или руководителя проектного офиса. Если мы опустимся на уровень менеджера, то, согласитесь, он будет пытаться любой ценой именно уложиться в сроки (или в бюджет), если только не придет разнарядка сверху.
3. Цитата: «Рак тянет назад – в IT это эксплуатационный блок (в который входит служба поддержки)». Аллегория с Раком, пятившимся назад совершенно не уместна. Службы внедрения и сопровождения вместе с маркетологами определяют ТЕНДЕНЦИИ рынка. С ними тесно работает аккаунт-менеджеры. Этот отряд, я считаю ПЕРЕДОВОЙ отряд, сильно влияет на тактику поведения на рынке и естественно на управление компанией.
Валерий, в данном вопросе для того, чтобы оппонировать Вам мне, по всей видимости, не хватает опыта. Я анализировал опыт примерно 10 компаний, где либо сам работал, либо имел возможность близкого общения. Ни в одной компании я не видел подобной деятельности от эксплуатации. Видел как раз наоборот - ''оплот надежности в вашем дурацком море изменений''. Следовательно, как только я увижу описываемую Вами схему, пойму, как она работает и за счет чего управляется, я обязательно перестрою модель с учетом новых знаний.
Мне кажется, что Вам следует говорить не о компании производящей Программные продукты и услуги , а о подразделении Информационных технологий в какой то Другой по профилю компании. И говорить от имени Руководителя этим подразделением.
Я считаю, что моя модель плохо подходит для ИТ внутри не-ИТ бизнеса. Для такого подразделения намного больше подходит классический сервисный подход. В нем собранные мной силы, по сути, выраждаются. Итого, когда мы выбрали стратегическую цель - ''через 5 лет доля потерь из-за пеней за невовремя выполненные проекты не будет превышать 0,5% от суммы проектной выручки''- наметили стратегию: ''первый год - регламентируем производство, чтобы получать управляемый уровень качества, второй год - повышаем мастерство проектного блока в части методов оценки сроков, третий год - сокращаем количество инцидентов...'', то мы все время балансируем показателями трех сил. В первый год мы готовы пожертвовать сроком, если у нас в производственном блоке будет внедрена та или иная практика, во второй год мы готовы пожертвовать бюджетом, но получить обученный персонал и т.д. И все это на основе показателей, которые, опять таки, характерны каждому направлению. Поэтому я имею неосторожность говорить о ''модели тактического управления''. Еще раз спасибо за интересный комментарий, буду рад, если Вы продолжите дискуссию.
Оставлять комментарии могут только зарегистрированные пользователи
Статью прочитали
Обсуждение статей
Все комментарии
Дискуссии
4
"АЛИМУЖИК"
Михаил Лурье
Для "Алибаба" + "Майл.ру возможен же внешний сервис, как он есть например для Yandex и Google - ...
Все дискуссии
Цифры и факты
Астронавты МКС не повреждали

Факт дня: Командир МКС Эндрю Фойстел заявил, что астронавты NASA не имеют отношения к повреждению корабля.

Сбербанк проводит учения

Факт дня: Сбербанк опроверг информацию о захвате заложников.

Дальний Восток: еще одна нацпрограмма

Факт дня: Путин поручит правительству создать национальную программу развития Дальнего Востока.

«Роснефть» построит газовые заправки

Тренд дня: «Роснефть» и Beijing Gas планируют строить в России газовые автозаправки.