Управленческий консалтинг
и автоматизация
pra.ru
+7(495)539-36-90
+7(812)329-40-04
ОСТАВИТЬ ВОПРОС
Введите код с картинки:

Нельзя изменить систему, не изменив себя в системе

 

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

И так начнем. Что же такое «Проект»? Если порыться в литературе, то найдем множество определений, заумных и не очень. Поэтому повторять их в рамках данной статьи я не буду. Каждый может подобрать себе такое определение, которое ему ближе и понятнее. Главное на мой взгляд, это то, что проект имеет начало и окончание. И то что в конце проекта должен быть получен определенный, заранее оговоренный результат и что данный результат должен быть получен в пределах определенного бюджета.

Если же обобщить все определения и жизненный опыт, то можно определить, что любой проект – это перевод некой системы из состояния (точки) «А» в состояние (точку) «Б».  Почему именно системы? Потому что с чем бы мы не имели бы дело у нас всегда будет набор взаимосвязанных сущностей. Если это строительство дома, то для его создания нужен учесть грунты, транспортную инфраструктуру, климат, мнения окружающих людей. Если это бизнес проект, то надо учесть рыночную ситуацию, финансы, потребителей и т.д.

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

 

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

А теперь вернемся к точкам «А» и «Б».

Точка «А» - это текущее состояние системы. Точка «Б» - желаемое, т.е. то, которое является целью проекта. Момент очень важный. Цель проекта – система, обладающая новым качественными характеристиками. Если мы не получаем в результате проекта никаких новых качеств, то стоит задуматься, а нужен ли такой проект?

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

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

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

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

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

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

А цели могут быть:

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

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

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

Теперь к переходу из «А» к «Б»

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

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

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

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

 

Продолжение следует…

 

Комментарии (0)
Введите код с картинки:
Карта сайта