Технология Клиент-Сервер 2002'3 |
|||||||
|
В чем заключается побочный эффект от чтения чужих статей? Читая их, невольно прикладываешь их тезисы к себе и начинаешь обобщать и свой личный опыт.
Рассмотрим управление проектами в рамках компании, занимающейся крупными западными ERP-системами. Почему это интересно? Потому, что в таких компаниях получается наиболее интересное и сочетание разных типов проектов.
Во-первых, долговременное существование таких систем (часто 15-20-30 лет) накладывает отпечаток некоей «историчности» происходящего. В нашей быстроменяющейся отрасли, где смена поколений занимает 2-3 года, а накопление знаний и опыта является серьезной проблемой, такой срок является почти уникальным.
Во-вторых, такое время существования накладывает особые и жесткие требования к правильному выбору стратегии развития продукта – с одной стороны нужно не растерять наработанные полезные функции и достигнутые преимущества, а с другой стороны необходимо быстро и эффективно развивать продукт, чтобы соответствовать современным требованиям. Таким образом, требуется четко продуманная стратегия развития, тщательный выбор инструментария для проектирования и создания ПО, а также жесткость и последовательность в реализации планов.
В третьих, происходит внедрение ERP-системы у заказчиков, а это цепь более мелких проектов, длительностью от нескольких месяцев до нескольких лет, у которых совершенно другие законы жизни и управления. Кроме того, часто возникают потребность в написании заказного ПО для заказчика, а это уже классический проект по созданию ПО.
В четвертых, при внедрении ERP-системы у заказчика затрагиваются буквально все области жизнедеятельности предприятия. Практически ни одна из служб и подразделений не остается той же, что и раньше. А это работа с самыми разнообразными службами и структурами предприятия – от директора до охраны.
Таким образом, получается полное разнообразие задач. И, соответственно, методик их реализации. Причем ясно, что для каждого проекта методика реализации проекта чаще всего разрабатывается индивидуально, да еще корректируется в процессе исполнения.
В идеале, конечно, должно быть так: есть всего две основных методологии и технологии - создания ПО и внедрения. Одни люди занимаются глобальными и стратегическими задачами определяя развитие компании и ее программных продуктов, другие проводят эту задачи в жизнь в краткосрочной и среднесрочной перспективе, третьи работают с заказчиком и внедряют продукт. Все это провязано обратными связями, итеративными процессами и т.д. Все красиво, разложено по полочкам, но работает плохо. Или работает хорошо, но медленно. Или работает не очень хорошо, не очень быстро и очень дорого. Комбинации могут быть разные. Получается это потому, что, как только эта схемы сталкивается с жизнью, начинаются корректировки и исключения из правил, которые либо ломают всю схему, либо делают ее нежизнеспособной. А почему появляются исключения? Да потому, что в проектах участвуют не квадратики и стрелочки с методологических схем, а живые люди. Которые своей волей (или безволием), своими эмоциями и другими человеческими качествами могут провалить или наоборот вытянуть любую методологию и любой проект.
Какие же сложности возникают при управлении проектами в рамках такой компании?
О первой сложности уже сказано выше. Компания часто находится в состоянии параллельного выполнения нескольких проектов, не считая собственного развития. И в этих проектах чаще всего используются разные методологии. К сожалению (а может быть и к счастью), мы работаем в условиях постоянного дефицита квалифицированных специалистов и каждый специалист на счету. И получается, что чаще всего специалисты участвуют в нескольких проектах. Отсюда вытекает несколько неприятных последствий.
Тяжело переключаться между проектами. В моменты «пиковых нагрузок» приходится работать с полным напряжением сил и в такие моменты возникновение даже несложных вопросов по другому проекту может приводить к серьезной потере производительности. Мне могут возразить, что нужно избегать «пиковых нагрузок», но мы все же реалисты и решаем реальные проблемы, а в жизни «пиковые периоды» – скорее норма, нежели исключение.
Ведущим специалистам приходится постоянно принимать решения исходя из разных, зачастую противоположных посылок. Как, например, соотнести стратегические требования развития ПО с сиюминутными требованиями клиента? Или требования простоты и «сопровождаемости» программного продукта с одной стороны с требованиями повышения функциональности и современными темпами развития программных технологий?
Вы пробовали работать по двум методикам одновременно? Не советую. Очень неприятно. А приходится.
Другой сложностью исполнения проектов является трудность построения правильных отношений с заказчиком. В чем заключаются эти сложности?
Слабый менеджмент на предприятии заказчика. Тут бывает обычно две крайности – либо полный бардак, либо тот же бардак, но зажатый в тиски административно-волюнтаристского управления. Между этими крайностями – полный спектр вариантов. Т.к. известный постулат гласит, что бардак автоматизировать нельзя, в процессе внедрения происходит еще и искоренение бардака. При этом руководитель проекта должен найти на предприятии те силы, которые все же заинтересованы в наведении порядка, и, опираясь на них, добиться своей цели.
Сложность формализации отношений с заказчиком. При старте проекта заказчик не совсем понимает, что он хочет получить в результате, что при этом должен делать он сам и что должен требовать от исполнителей. Поэтому трудно однозначно сформулировать и закрепить на бумаге взаимные обязательства. И еще труднее достичь взаимного удовлетворения к концу процесса внедрения. Здесь невозможно решить проблемы без взаимных уступок и компромиссов.
Недостаток квалифицированного персонала у заказчика. Если уж существует дефицит специалистов у исполнителя, то у заказчика он обычно десятикратно острее. Обычно спектр взаимоотношений в начале тоже очень широкий – от простого ожидания, что поставят программу, которая «все сама будет делать», до горячего желания делать все самостоятельно. Единственно разумным путем все же является создание совместной рабочей группы исполнителя и заказчика, которая работает над проектом. Успех формирования такой группы во многом зависит от группы внедрения исполнителя, которая должна стать ядром совместной группы. По мере развития проекта растет квалификация персонала заказчика, вокруг большого дела группируются наиболее способные люди. Здесь возникает обратная задача – группа внедрения должна постепенно «выйти» из проекта, оставив после себя работоспособное ядро сотрудников заказчика для поддержки проекта.
Резюмируя все вышесказанное, можно сказать, что на первый план выходят люди и взаимоотношения между людьми. «Кадры решают все». Можно по-разному относиться к менеджеру, сформулировавшему эту мысль, но он руководил крупнейшим в ХХ веке проектом. И провалился этот проект только через 30 лет после его смерти.
Я часто читаю размышления о том, какую выбрать ERP-систему. Для меня ответ более, чем очевиден. Я бы выбирал не продукт, а команду внедренцев. Естественно, при прочих равных.
Так каким же образом должна быть построена работа в компании, занимающейся требованиями? Далее я буду рассматривать слагаемые не в порядке их значимости, а в произвольном порядке – каждый может расставить их так, как считает правильным...
В этой статье мы только слегка затронули такую важную тему, как организация работы в проекте с точки зрения отношений между людьми. За рамками статьи остались такие важные вопросы, как:
Организация работы с заказчиком.
Организация групп для работы над проектом.
Влияние личных качеств, привычек, культуры на место человека в проекте.
Изменение ролей людей в проекте с течением времени.
Влияние личных отношений на процесс принятия решения.
И отдельный интересный вопрос – о руководителях проекта.
Но эта тема неисчерпаема, как всякий процесс взаимодействия групп людей. К сожалению даже за границей ей уделяется меньше внимания, чем она заслуживает. А у нас в стране и подавно. Общая беда современного общества – пренебрежение к человеку, недостаточное внимание к отношениям между людьми и группам людей. Поэтому давайте по крайней мере на работе стараться выстроить отношения в коллективе таким образом, чтобы работать более эффективно за счет создания и поддержания нормальных отношений между людьми.
Copyright © 1994-2016 ООО "К-Пресс"