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

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

Максим Никитин IT-директор, CIO, Москва

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

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

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

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

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

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

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

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

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

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

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

Но проектное управление ни за что не должно входить в IT-блок.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Йога по-взрослому.:) направления и Стили.


К прочтению:

самые интересные статьи, подобранные как раз для Вас:

spacer