Да, про управление проектами все уже 100 раз написали.
Совершенно верно, про управление проектами с использованием разных методологий еще не написал только ленивый.
Поэтому мы не будем обсуждать общие ситуации и прелести разных методик.
Но мы расскажем вам о нескольких случаях, когда риски сработали, несмотря на использование некоторых методологий управления проектами, и как мы вышли из проблемной ситуации.
Типичные трудности
Сначала о главном и самом интересном – о проблемах с точки зрения подрядчика-исполнителя проекта автоматизации.
Все методологии должны помогать избавляться от проблем до того, как они — сложности — возникнут. Но в жизни так не бывает. 
Вот типичные трудности, с которыми мы чаще всего сталкиваемся на проектах:
- Рассинхронизация действий в сложных проектах с участием нескольких подрядчиков.
Проект стартовал, бюджеты утверждены, но по каким-то причинам один из исполнителей уходит из проекта или отстает от сроков.
Всем остальным в этот момент приходится перераспределять ресурсы и вкладывать больше усилий в проект. Хорошо, если заказчик еще не выплатил всю сумму подрядчику, который вышел из проекта, не выполнив свою задачу, и в бюджете проекта есть деньги, чтобы компенсировать оставшимся подрядчикам дополнительные усилия.
У нас были ситуации, когда нам приходилось сильно менять структуру управления проектами, переходить от водопадной методологии к гибридной, буквально жертвовать дополнительными лицензиями и интегрировать не запланированные заранее модули платформы Форвард, чтобы закрыть дыры в функционале из-за отставание одного из смежных подрядчиков и вовремя сдать проект в опытную эксплуатацию.
- Неправильный выбор CRM-системы для телеком.
Зачастую заказчик выбирает CRM по косвенным признакам, посмотрев презентации и оценив красоту интерфейса и отчетов.
Но при этом он упускает, какие стандартные процессы есть в выбранной CRM и насколько она соответствует специфике телекоммуникационной отрасли.
Например, при продаже нужно проверить техническую возможность подключения по выбранному адресу, понять, есть ли свободные порты и какова нагрузка на сегмент сети в целом.
А выбранная CRM даже не знает о существовании такого процесса.
Когда становится понятно, сколько будет стоить настройка CRM под бизнес-процессы телекома, возникает вопрос: «А не проще/дешевле сразу внедрить готовую и специализированную систему управления взаимоотношениями с клиентами телекомаЭ»
- «Бесплатные» решения с открытым исходным кодом.
Если ИТ-специалисты заказчика возьмут на себя реализацию какой-то части ИТ-ландшафта, задействованной в комплексной автоматизации, то может возникнуть проблема понимания объемов трудозатрат и бюджетов.
ИТ-специалист говорит менеджеру: «давайте возьмем open-source, это бесплатно», то есть платить вендору за лицензии не нужно.
Менеджер слышит что-то вроде «давайте быстро установим эту штуку и она сразу заработает, и вам не придется никому платить!» Есть пробел.
Руководитель считает, что со стороны его ИТ-службы задача практически выполнена.
Фактически, это может потребовать интеграции открытого исходного кода с другими информационными системами, обширной настройки и изменений в бизнес-процессах клиента.
В результате проект тормозится, и мы попадаем в ситуацию из пункта 1 этого списка.
- Ожидания по времени.
Раньше подбор информационных систем для биллинга осуществляла ИТ-служба предприятия.
В настоящее время выбор все чаще делают отделы, отвечающие за продажи и маркетинг.
Отсутствие технической подготовки, распространение облачных сервисов и рост общей информатизации жизни создают иллюзию простоты.
Никто не думает, что для нынешней комфортной работы в Gmail, бесплатном для обычных пользователей, потрачены ресурсы огромной организации на многие годы.
Поэтому мы постоянно слышим, что ожидания внедрения биллинга — 3-4 месяца.
Редко когда заказчик оценивает объем работы в полгода-год.
- CRM,
- Служба поддержки,
- Технический учет/инвентаризация.
Все совпадения с реальными людьми следует считать случайными.
Во время съемок этого фильма ни один утконос не пострадал.
Когда водопад поворачивает назад
Жил-был интернет-провайдер, но не простой, а состоящий из множества юридических лиц, которые предоставляли услуги в разных городах.В каждом городе юридическое лицо имело свой собственный исторический биллинг, поддержку, местное управление и многое другое, необходимое для работы бизнеса.
.
Поэтому основное юрлицо провайдера решило объединить всех в одну систему, считать деньги и трафик в одном месте, а не оставлять это отдельным историческим системам.
Для всего этого руководитель компании объявляет тендер и выбирает поставщика средств автоматизации.
Мы изучаем тендерную документацию.
Мы видим, что соответствуем требованиям, участвуем в тендере и являемся счастливыми победителями.
Проблемы начинаются
И тогда все становится интереснее.Получается, что руководитель юридического лица хочет заключить проект сразу для всех юридических лиц, жестко фиксируя сроки и общий бюджет. Вырисовывается чистая вода классического водопада.
Мы общаемся с сотрудниками, ответственными за проведение тендера, записываем BPI (базовый план реализации) проекта, изучаем предоставленную подробную информацию и документируем все требования.
Подписана куча бумаг, мы входим в проект. И мы столкнулись с жестокой реальностью в виде несоответствия ранее предоставленной документации реальной ситуации на местах в городах, где работает провайдер.
Мы получаем триггерные риски:
- Продление сроков реализации.
- Увеличение трудозатрат на проект.
- Неясна степень ответственности организаторов тендера в ситуации, когда они не управляют историческими системами на месте.
- Отсутствие заинтересованности в переходе на единый биллинг у местных юридических лиц.
Перезапуск
Очевидный разрыв между формальными требованиями и реальной ситуацией в городах присутствия провайдера заставляет пересчитывать сроки и бюджет. Предоставьте эту информацию клиенту.
При этом мы закладываем в бюджет дополнительные трудозатраты на изучение исторических систем.
Нам предстоит провести большую переговорную работу с представителями материнской компании.
Мы торгуемся.
Головная компания очень хочет единого биллинга, поэтому для каждого города полюбовно подписывается дополнительное соглашение.
Общий результат проекта положительный.
Трудности при входе в проект были решены, переход на новый единый биллинг для группы компаний прошел без происшествий.
Следование классической методике не помогло выявить недостатки технического задания, и пришлось полностью перерабатывать все договоры с заказчиком и переписывать всю проектную документацию.
Согнутый в корне
К нам обратился клиент с желанием запустить своего виртуального оператора.Мы просчитали проект запуска MVNO с разной степенью независимости от MNO. Клиент рассматривал проект как диверсификацию бизнеса и не имел достаточного опыта работы в сфере телекоммуникаций.
Бюджетирование проекта планировалось осуществлять на основе средств, высвободившихся от основного бизнеса.
При этом владелец хотел работать исключительно по Agile, считая эту методологию наиболее прогрессивной и подходящей для запуска нового бизнеса.
Было решено разбить задачи по запуску оператора на небольшие работы и работать спринтами, привлекая для каждого спринта имеющиеся у нас свободные ресурсы, достаточные для освоения бюджета.
Активацию следовало провести по результатам спринта.
Результат — то, чем нельзя гордиться.
Проблемы, которые изначально были предсказуемы, проявились во всей красе:
- Нестабильность средств на выполнение работ.
- Временной лаг между появлением бюджета и выделением специалистов для его исполнения.
- У владельца возникает соблазн потратить накопленные на проекте средства вместо того, чтобы дождаться окончания спринта и оплаты по акту.
В результате между окончанием спринта, подписанием акта и оплатой возникает временной лаг.
Выход из проекта, следовательно, тоже результат, хотя и не положительный.
Без достаточной мотивации заказчика на достижение результата гибкая методология может лишь минимизировать наши неактивированные и неоплаченные трудозатраты.
Но работа в таком режиме сильно обескураживает и отвлекает ресурсы от реализации более прибыльных проектов.
Это негативный опыт, и мы не будем запускать проекты с подобными условиями.
Agile с ограничениями по срокам, бюджету и функциональности — WTF?!
Да, есть такое.Заказчик может хотеть работать по Agile, но при этом строго фиксировать сроки, бюджет и функционал.
Это вызывает у нас диссонанс.
Для нас работа в чистом Agile с клиентом означает, что мы предоставляем команду, а клиент берет на себя значительную долю трудозатрат по управлению проектом.
Мы отвечаем за выполнение спринта и управление оперативными задачами.
Менеджер проекта со стороны заказчика фактически несет ответственность за общий результат проекта.
Наш опыт говорит, что для получения приемлемого результата/MVP, проверки гипотез по какой-то функциональной области будущей информационной системы необходимо 3-4 спринта.
Это достаточно длительный период времени и трудозатрат. Помните, мы ранее говорили, что ожидаемый срок автоматизации теперь составляет 3-4 месяца? Нет, мы в целом не против, мы умеем работать в такие сроки, но не без помощи команды клиента.
У заказчика, который воспринимает Agile как прогрессивную методологию, потому что она известна, другое понимание.
Он хочет, чтобы мы назвали конкретные сроки, конкретный бюджет, чтобы мы управляли всем ОБЪЕМом проекта, но в то же время, чтобы все это происходило «по agile».
Редко встречаются заказчики-менеджеры, готовые взять на себя ответственность за результаты проекта.
Чаще происходит подмена понятий — «agile» называют почти классическим водопадом, только с презентациями и показами промежуточных результатов каждые две недели.
И здесь мы плавно переходим к следующему случаю гибридной методологии.
Спасает ли гибрид?
Ситуация аналогична предыдущему случаю — владелец хочет запустить Full MVNO в дополнение к основному виду бизнеса.У клиента сжатые сроки, а проект запуска MVNO привязан к нескольким смежным внутренним проектам автоматизации.
Заказчик устанавливает существенные ограничения по бюджету, срокам реализации проекта и требует интеграции систем Форвард с внутренними информационными системами с использованием СУБД Oracle. Помимо этого, поскольку запущен Full MVNO, требуется покупка, установка и настройка телекоммуникационного оборудования.
Работа будет осуществляться совместно с ИТ-командой заказчика и несколькими командами других подрядчиков.
Проект стартует, у нашей команды очень большая нагрузка.
Приходится работать сверхурочно и очень тесно общаться с коллегами.
Состав задач в спринтах меняется очень динамично, заказчик вовлекается в проект и флексит столько задач, сколько добавляет. Результат проекта положительный.
Было тяжело и очень напряженно, но минимальный функционал для запуска MVNO был реализован в кратчайшие сроки, указанные заказчиком в техническом задании.
Жесткие временные и бюджетные ограничения, высокая вовлеченность клиентов и гибкий подход к формированию пула задач для спринтов — хороший фундамент для успешного завершения проекта.
Ключевая особенность этого проекта — синхронизация спринтов всех команд, работающих в системе автоматизации.
Какие проекты мы не берем?
Низкая дизайнерская грамотность.
Для нас проектная грамотность выражается прежде всего в наличии опыта реализации проектов у сотрудников клиента, функциональных заказчиков, лиц, принимающих решения, и RP на стороне клиента.
Производим оценку на начальном этапе переговоров.
Мы стараемся общаться с лицами, принимающими решения, и RP лично.
Если опыт не ясен из общения, то можно спросить напрямую.
Иногда у ЛПР нет ИТ-бэкграунда, он плохо понимает, что такое разработка программного обеспечения, интеграция разного ПО друг с другом, но при этом у ЛПР много амбиций.
Такое лицо, принимающее решения, может считать, что автоматизация — это просто, быстро и дешево, но поставщик и интегратор берут деньги за воздух.
В ходе переговоров такое отношение довольно легко заметить.
Важно, есть ли вокруг ЛПР компетентные люди и насколько они могут повлиять на ЛПР.
Если есть люди с опытом работы в ИТ и ЛПР прислушивается к ним и доверяет им, то это увеличивает шансы, что мы присоединимся к проекту.
Вы можете работать с теми, кто не имеет проектного опыта, но заинтересован в результате, вникает в задачи и использует опыт коллег и подрядчиков.
Нельзя работать с менеджерами, которые упрямы, горды и глухи к советам.
Неадекватные требования
На этапе предварительного проектирования и подготовки технического задания можно понять, насколько требования адекватны заявленному бюджету.Неадекватное отношение к срокам и деньгам — важный тревожный сигнал и управленческие риски, которые затем перерастут в проектные риски, поскольку ожидания заказчика не оправдаются.
Очень сложно хорошо завершить такой проект. Реальный кейс: мы год готовились к продаже, выполнили предварительный проект и подготовили документацию.
Но заказчик неожиданно объявил на тендере условия, при которых риски выполнения работ слишком велики, и мы отказались от участия в конкурсе поставщиков.
Мы потеряли значительное количество времени на предварительные работы, но рисковать и вступать в проект на условиях, заявленных в тендере, было неправильно.
Другой пример: запущен MVNO, требования к функционалу информационной системы составляют несколько тысяч позиций.
Эти требования составлены на основе опыта операторов по всему миру и не совсем соответствуют бизнес-среде конкретного оператора.
При этом владельцы подразумевают, что запуск MVNO — это своего рода стартап, в который не планируется вкладывать большие средства.
Наш опыт показывает, что нормальным в этой ситуации будет список из более чем 100 требований.
Просто перебрать эти тысячи требований и дать ответ на каждое со ссылкой на документацию на платформе Форвард — трудозатраты, которые не окупятся, судя по увиденному нами отношению заказчика к бюджетированию проектов.
Низкая квалификация технических специалистов заказчика
Квалификация ИТ-отдела заказчика сама по себе не является проблемой, если этого достаточно для функционирования бизнеса.Проблемы возникают, когда критически важные задачи в проекте автоматизации поручают низкоквалифицированным людям, обосновывая это тем, что «у нас есть своя ИТ-команда, пусть работают».
Если повезет, в результате проекта ИТ-отдел заказчика повысит свои компетенции и справится с поставленными задачами.
Но, возможно, вам не повезет. Но не всегда возможно тесно пообщаться с рядовыми исполнителями, понять их способности и мотивацию на этапе первичных переговоров.
Низкая квалификация команды заказчика не является блокирующим фактором, но является серьезным поводом задуматься и переоценить все условия взаимодействия с клиентом.
Следующая статья о рисках
Крупные корпоративные проекты всегда сопряжены с финансовыми и репутационными рисками.Итак, мы выпустим вторую часть статьи и поговорим о рисках с точки зрения компании-подрядчика по автоматизации.
А пока предлагаем вам поделиться в комментариях своим опытом о трудностях и проблемах в проектах! Теги: #Управление проектами #agile #Биллинговые системы #телеком #проект #водопад #биллинг #технология проекта #технология проекта
-
Linux Для Домашних Пользователей
19 Oct, 24 -
Удаленная Работа Как Угроза
19 Oct, 24 -
Корпоративная Анатомия
19 Oct, 24 -
Таблица Дроидов. Выпуск 19
19 Oct, 24
