Несмотря на то, что Крылов вкладывал негативный смысл в басню про воз и трех героев, я хочу проиллюстрировать свой рассказ именно этой картинкой, так как в управлении IT есть три силы, которые тянут компанию в разные стороны.
Лебедь стремится вверх – в IT это производственный блок. Он витает в стратосфере новых технологий. Для производственника реализовать современный алгоритм, попробовать инновационную идею или девайс намного интересней, чем соблюсти сроки проекта. Люди с техническим складом ума склонны к обобщениям и универсализации предлагаемых решений. Сделать «некрасивую» реализацию задуманного проекта для производственника смерти подобно. Все характеристики в споре «чем пожертвовать – сроками, бюджетом или качеством» дают для него однозначный ответ: «Чем угодно, только не качеством!».
Щука тянет вниз – в IT это проектный блок. Каждый проект должен быть конечен по времени – это одно из важнейших его отличий от операционной (процессной) деятельности. Поэтому менеджеры в этой сфере склонны максимально бороться за сроки. В условиях ограниченного бюджета – а он всегда ограничен: не рублем, так трудовым ресурсом – основной претендент на «выбывание» в споре – это качество.
Рак тянет назад – в IT это эксплуатационный блок (в который входит служба поддержки). Эти ребята находятся на «передовой» – именно они принимают на себя удар пользователей «у меня не работает» или «почему я не могу это сделать». В споре «чем жертвовать» они однозначно склоняются к фиксации качества, но понимают его иначе, чем производственный блок. У первых в показателях может быть устойчивость архитектуры к изменениям и прохождение автоматизированных тестов. Вторые же за качество принимает отсутствие инцидентов (как компромисс – инциденты по известным проблемам) и простоту обслуживающих процессов. Исходя из этого, эксплуатационщики склонны сопротивляться всем изменениям продукта, к проблемам и процессам обслуживания которого они уже привыкли.
Сильная команда – это когда ее участники своими сильными сторонами уравновешивают слабые стороны других членов коллектива. Понимая причины склонности той или иной силы к тем или иным решениям, мы имеем отличную возможность построить устойчивую систему, так как направление «вперед» – это баланс между всеми тремя векторами. «Щука – менеджер проекта» не даст «лебедю-архитектору» улететь в заоблачные выси инновационных технологий, напоминая, что кушать хочется «здесь и сейчас». «Рак – эксплуатационщик» не позволит лебедю и щуке разогнать компанию до такой скорости изменений, что они оторвутся от реальных требований заказчика (или потребностей в выбранном сегменте рынка). Лебедь, в свою очередь, не дает организации застыть на месте.
Теперь, когда мы поняли, чем можно управлять, давайте поговорим о том, как это делать. Самое главное правило – не сосредотачивайте все векторы в одних руках. Даже объединение двух направлений под руководством одного начальника вызовет серьезный перекос, который вряд ли получится компенсировать третьей силой. Причем будет именно искажение, а не «усредненной значение» – в зависимости от характера менеджера будет отдаваться явный приоритет одной деятельности. Например, сосредоточение управление проектами и производственными подразделениями под «крылом» одного зама вызовет, в зависимости от его склонности, либо частые нарушения по срокам в угоду качеству, либо постоянную высокую стоимость исходного продукта при хорошем соблюдении сроков, либо отсутствие результата с повторяемым (одноуровневым) качеством. Оговорюсь, что такое жесткое условие по разделению ответственности должно соблюдаться для компании, в которой именно IT является основной деятельностью. Для организаций, где IT выполняет сервисную функцию (основной бизнес не связан с IT), можно объединять производство с эксплуатацией в одной штатной единице, проследив, что есть явное разделение на два направления. Но проектное управление ни в коем случае не должно входить в IT-блок.
Непосредственно модель менеджмента удобнее всего строить на основе системы сбалансированных показателей. Про нее, уверен, знает каждый. Но, как показывает мой опыт, большинство делает акцент на слове «показатель», в то время как «соль» метода кроется в слове «сбалансированный». Для того чтобы уравновешивать, давайте определим сначала «локальные» (действующие только для одного направления) параметры. Мы их будем расставлять на основе «сильных» сторон каждого направления, ведь именно они являются естественными мотиваторами. И проверить правильность (работоспособность) показателя можно очень легко: если при его отмене у подразделения зажигается «огонь» в глазах: «Ух, сейчас мы заживем, именно этого нам и не хватало», – значит, параметр выделен верно.
Сильная сторона производства – борьба за «внутреннее» качество и новые технологии. Значит, имеет смысл регулировать процент времени, которое тратится на исправление ошибок относительно сроков на первоначальную разработку, уровень покрытия выпускаемого продукта технической документацией, рискованность (процент повторного использования решений или технологий), количество изменений ядра системы и тому подобное.
Сильная сторона проектного блока – борьба за соблюдение сроков и понимание финансовых схем. Имеет смысл фиксировать отклонение по времени (в любую сторону от плана, в целом, плохо), следование бюджету (соответствие реальной выработке планируемой нагрузке, графикам платежей), удовлетворенность заказчика (на уровне деятельности компании, а не одного проекта).
Сильная сторона эксплуатации – понимание проблем и потребностей конечного пользователя, ограничения его инфраструктуры и лимиты продукта в целом, борьба за «внешнее» качество. Их показатели – непрерывность предоставления услуги (количество инцидентов, процент время безаварийной работы за отчетный период), качество на выходе (соответствие документации, количество ошибок, найденных заказчиком, на этапе приемочного тестирования).
Первый этап балансировки заключается в том, что мы максимально честно (какие некрасивые цифры бы ни получались) должны расставить фактические значения каждого из параметров. Чем искреннее мы будем, тем проще будет управлять. Только признанные проблемы можно решать. Пока вопросы находятся в состоянии «это не ошибка, это особенность», работать над их исправлением невозможно. Второй шаг – задание целевых показателей для одного направления и соответствующая корректировка параметров другого направления. Важно помнить о балансе трех сил – сроках, финансах и качестве: один увеличивается, второй не меняется, третий ухудшается. Например, если вы ужесточаете требования к качеству и не хотите потерять в бюджете – ослабьте показатели по срокам. Ведь для достижения нового качества нужны какие-то мероприятия. Если новых ресурсов привлечь нельзя (бюджетные показатели остались прежними), то на них будет тратиться часть времени прежних ресурсов, что приведет к падению показателей по срокам. Если же вы хотите улучшать параметры сразу трех направлений, вам не обойтись без внешних инвестиций (это могут быть и финансы, и трудовые ресурсы, и новые процессы (процедуры) работы, которые внедряются без оглядки на предыдущий опыт). Именно в нахождении реально достижимого равновесия между показателями и проявляется вся сила системы сбалансированных показателей.
Также важным фактором успеха при управлении с помощью этой модели является фиксация методики расчета во времени – это позволит гарантировать достоверность сравнения. При необходимости изменить схему расчета (например, если обнаружены ошибки или необходимо использовать иной способ сбора исходных данных) очень важно пересчитать старые показатели (как минимум, последний, чтобы было с чем сравнивать следующий показатель) по новой методике. И это необходимо сделать до начала ее эксплуатации, особенно если для расчета требуется применить экспертную оценку. Например, ввод интеграции двух систем позволяет автоматически получать время, которое тратилось специалистами на решение одного инцидента. Ранее показатель считался на основе ручной обработки данных одной из них. Для того чтобы иметь возможность сравнить данные, необходимо пересчитать как минимум последнее значение по новой методике. Очевидно, что для этого придется вручную (экспертно) оценить влияние данных из второй системы на показатель из первой. Такая оценка должна проводиться до того, как будет получено следующее значение. Иначе, вероятнее всего, новые данные всегда будут лучше, чем старые.
Итого, если кратко резюмировать, для успешного управления IT-компанией, необходимо:
1. Разделение ответственности за производственную, проектную и эксплуатационную деятельность;
2. Наличие показателей деятельности каждого направления, которые можно считать и сравнивать во времени;
3. Балансировка всех параметров при необходимости изменения показателей одного направления;
4. Пересчет значений по новой методике перед ее внедрением.
При соблюдении данных условий вы будете обладать и актуальной информацией о текущем состоянии, и возможностями по изменению положения дел.
Источник
изображения: pixabay.com
Очередная попытка ввести читателя в заблуждение. Модели как таковой нет, пресловутые параметры четко не определены, управляющее воздействие - тем более. Разочарован. Менеджмент на уровне общих слов?
Прикольно, что фирма работает «сама на себя», а пользователь, для которого по идее предназначена продукция фирмы, полностью исключён из схемы. Одни техногенно самовыражаются, другие борются за соблюдение сроков, третьи тормозят изменения… Самое удивительное, что такие компании всё ещё существуют во втором десятилетии XXI века…
Вообще-то, все эти вопросы должны быть отрегулированы на фазе концепции проекта... разработаны концепции управления и предметной областью, и временем, и стоимостью, и качеством, и изменениями... это стандартные требования и PMI, и IPMA...