Отправляет email-рассылки с помощью сервиса Sendsay
  Все выпуски  

Постановщик задачи - теория и практика


Информационный Канал Subscribe.Ru

Здравствуйте, уважаемые подписчики!

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

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

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

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

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

К чему я клоню? У любого проекта, у любой задачи, которую надо реализовать на практике, есть РЕСУРСЫ. Ресурсы временные, а время и деньги, как водится, имеют прямую пропорцию. То есть, чем больше времени (по своей или вашего Заказчика вине - все равно) вы потратите на проект против запланированного срока, тем больше "проедите" денег. Или, что еще реальнее, просто останетесь при фиксированной сумме при большем интервале времени, что в переводе также означает работу себе в убыток. Следовательно, если вы совмещаете функцию постановщика задачи с функцией руководителя проекта (а это происходит довольно часто в небольших организациях), то на приближенную к действительности оценку бюджета проекта время придется потратить. Но при этом попытка просто "задрать" цену в качестве собственной подстраховки способна "сдуть" клиента с ваших горизонтов в сторону ваших же конкурентов. А посему придется сделать вывод о том, что и в этом деле, равно как и во всех других, крайне важно соблюдать "золотую середину".

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

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

...На сегодня пока все. Продолжим в следующем выпуске.

Пишите, обсуждайте, спрашивайте - dznak@km.ru. С удовольствием и благодарностью включу ответы на ваши вопросы в следующие выпуски рассылки.

Желаю удачи!

Вера Хомичевская,

бизнес-консультант, психолог, инженер, бухгалтер, преподаватель.


http://subscribe.ru/
E-mail: ask@subscribe.ru
Адрес подписки
Отписаться

В избранное