В проектной работе используются десятки фреймворков и методологий.
Больше не осталось людей, которые не слышали об agile, scrum, kanban и других подходах.
Каждый из них обещал стать серебряной пулей, которая поможет реализовать проекты так, чтобы они соответствовали всем параметрам успеха.
Но на практике только грамотная работа с рисками позволяет довести проекты до завершения любой ценой.
В этой статье мы постараемся рассмотреть наиболее важные риски, которые могут встать на вашем пути.
Материал будет полезен всем, кто участвует в работе над проектом.
Итак, какие проекты считаются успешными? Принято выделять следующие параметры:
- проект был сдан в срок;
- без превышения бюджета;
- с минимальным количеством дефектов;
- работает по назначению;
- люди этим пользуются;
- решает цели, которые перед ним были поставлены;
- удовлетворяет бизнес-требования ключевых заинтересованных сторон;
- приносит первоначально обещанную ценность для бизнеса.
Расскажи нам что треть ИТ-проектов терпит неудачу, а половина испытывает трудности.
Подумайте об этом, это ошеломляющая статистика.
Сложно сказать, какого уровня проекты попали в выборку, но давайте предположим, что это крупные истории вроде провального обновления ИТ-инфраструктуры сети магазинов KMart за $1,2 млрд, ставшего одним из ключевых факторов роста компании.
банкротство.
Означает ли это, что небольшие проекты российских веб-студий не сталкиваются с такими же проблемами? Если вы читаете Отзывы клиентов на популярном агрегаторе мы увидим, что даже в случае стандартных лендингов и шаблонных интернет-магазинов указанные выше критерии успеха встречаются редко:
«Мы заказывали разработку и дизайн сайта в 2015 году.Дизайн сделали быстро, но нельзя сказать, что качественно.
Разработка реализовывалась до 2017 года и так и не была реализована».
«После такой работы сайт пришлось полностью переделывать; поначалу, конечно, работа шла активно и казалось, что все хорошо.Но потом мы стали замечать, что на протяжении месяца повторяем одно и то же задание, и в результате практически перестали отвечать на вопросы.
В конце концов мы оказались в невыгодном положении, потому что нам пришлось нанять другого поставщика».
«Несколько раз сроки реализации объекта переносились дополнительными соглашениями.Что мы можем сказать об индивидуальном, более масштабном развитии? В конце концов, чем крупнее проект, тем больше вероятность, что он не доживет до завершения.В результате все оговоренные сроки также были сорваны и разработка сайта заняла 1,5 года.
Конечным результатом стал сырой продукт, который невозможно было использовать.
Пришлось отправить сайт на доработку в другую студию».
Поэтому перед любым заказчиком и подрядчиком должен встать вопрос, как не оказаться на кладбище незавершенных проектов.
Давайте разберемся, что может пойти не так в заказном проекте разработки и что с этим делать:
Риск 1. Недостаточная квалификация подрядчиков
Проблема здесь в том, как структурирована заказная разработка.Клиент часто не понимает, кому он доверяет проект, ведь на каждом шагу обещают полный цикл разработки и работу под ключ.
Решив оцифровать часть бизнеса, компания обращается к веб-студии (она же digital-агентство/веб-интегратор).
Услуга предоставляется в формате «одного окна».
Клиенту предлагается заполнить бриф, на основании которого затем составляется техническое задание.
Если проект сложный и требует опытных программистов, то разработка передается на производство.
Субподрядчик обязан выполнить работы по техническому заданию, составленному некомпетентными людьми.
Если проект доживает до релиза, зачастую оказывается, что продукт не решает проблем компании; никто не хочет его использовать.
Это проблема рынка – подрядчик неадекватно оценивает свои силы, но при этом берет проекты в производство, принимает неверные решения и в итоге ничем не помогает. Клиент страдает.
Метод избегания
Как ни банально, самое главное понять проблему.Мы не жалеем ресурсов для погружения в бизнес клиента.
Мы готовы организовать командировку и пообщаться на месте не только со стейкхолдерами, но и с людьми, которые будут использовать конечный продукт. Мы не начнем расходовать бюджет проекта, пока не будем уверены, что все просчитали.
В веб-студии технические задания составляют аналитики, которые еще вчера работали тестировщиками.
Не разбираясь в тонкостях разработки, они создают документ, описывающий элементы интерфейса, но практически игнорирующий сложные интеграции и алгоритмы, которые скрываются за этими элементами.
Реальный пример формулировки, на основании которой генподрядчик требует рассчитать окончательную стоимость разработки.
Генподрядчик просит рассчитать стоимость разработки на примере схожих по формату услуг, но реализованных совершенно по-разному.
«Делайте что хотите, по ходу разберемся» Когда речь идет об автоматизации работы предприятия, такой подход неправильный.
Недостаточно нарисовать макеты и описать их в техническом задании.
Поэтому этап аналитики лучше доверить системным архитекторам, которые понимают, что скрывается «под капотом».
Риск 2: исчерпание бюджета до выпуска продукта
На рынке цифровых услуг преобладают фиксированные бюджеты и постоплата.Поэтому бухгалтеры и продавцы стараются быстро согласовать смету и заключить договор.
Если веб-студия неправильно составила техническое задание, провела неполную оценку и привлекла субподрядчика для разработки, на проекте может случиться производственный ад. Объем работ станет больше, генподрядчик начнет защищать свои интересы и подталкивать конечных подрядчиков к тому, чтобы они уложились в бюджет. Извращенная логика работает с обеих сторон, каждый придумывает повод сделать чуть хуже оппонента: «Плохое техническое задание предоставили, а теперь наращивают объемы? Тогда мы не будем принимать во внимание некоторые комментарии!» / «Мы уже пообещали клиенту, куда он пойдет, достроят или не получат деньги!» Эти политические войны скрыты от глаз клиента.
Он понятия не имеет, кто участвует в проекте и как идет процесс разработки — партнеры веб-студии подписали NDA. В результате продюсерская компания жертвует качеством продукта, чтобы не работать в убыток, а веб-студия думает только о том, как побыстрее подписать документы и получить оплату.
Никого не волнует выгода для клиента.
Метод избегания
При составлении сметы веб-студии ограничиваются лишь общими этапами работы: аналитика, дизайн, верстка, программирование.А грамотный подрядчик включит в смету все функциональные элементы разрабатываемой системы.
Невозможно оценить объем работы по цифровой трансформации бизнеса на основе пятиминутного разговора с клиентом.
Поэтому сама работа со сметой требует нескольких этапов, и без аналитики получить окончательную стоимость разработки не получится.
Сомнительным клиентам мы предлагаем рассчитать стоимость проекта по нашим реквизитам.
Пока никто из конкурентов не согласился, хотя были студии, обещавшие сделать дешевле.
Но даже при наличии хорошо проработанного технического задания и сметы проект не застрахован от перекосов производственного графика.
При возникновении такой угрозы важно не только предупредить клиента, но и предложить альтернативный план действий и оптимизацию объема работ. Нельзя молчать и надеяться «авось пройдет».
Риск 3: Изменения в середине проекта
В среднем проекты разработки цифровых систем длятся не менее года.За это время может случиться что угодно.
Могло случиться так, что в середине проекта клиент изменил способ ведения бизнеса, или стали доступны более совершенные технологии, или, может быть, что-то просто изменилось в мире.
Например, мы разрабатывали систему курьерской доставки, но из-за политической ситуации рынок изменился, крупные агрегаторы снизили свои комиссии, и проект больше не достигает тех целей, которые перед ним ставились.
В таких условиях абсолютно нормально, если клиент начинает менять задачи, не дожидаясь завершения разработки.
Вам нужно уметь с этим работать.
Метод избегания
Если клиент предлагает что-то изменить, то в первую очередь следует разобраться, почему это происходит и какие обстоятельства привели к такому решению.Выведите клиента на откровенный разговор, чтобы понять его боль.
Только тогда мы сможем оценить, принесут ли эти изменения пользу проекту, и попытаться предвидеть связанные с этим риски, включая перерасход средств.
Далее найдите оптимальный подход к реализации этих изменений в продукте и предложите его.
Но выбор должен оставаться за клиентом.
Риск 4. Потеря интереса со стороны собственника
Когда что-то меняется в мире, клиент может увлечься другой сферой бизнеса и забыть о текущем проекте.Потеря интереса приводит к тому, что исполнителя либо просят полностью свернуть работу, либо, что еще хуже, оставляют в подвешенном состоянии.
Ожидание решения приводит к простою команды и затратам.
Но чаще всего интерес пропадает, когда происходят серьезные изменения в организационной структуре на стороне клиента и на проекте заменяются люди.
Обычно эти люди не имеют полного контекста и поэтому не видят ценности проекта.
Их мотивация выпустить продукт крайне низка.
Метод избегания
Чтобы постоянно поддерживать интерес к проекту, мы показываем клиенту все промежуточные результаты.Большие проекты обычно состоят из набора сервисов, поэтому в результате каждой итерации разработки мы стремимся продемонстрировать полностью готовый функционал отдельного сервиса, который уже можно использовать.
Таким образом клиент видит, что продукт решает его бизнес-задачи.
В ходе разработки мы проверяем, изменились ли цели проекта, и регулярно сверяемся с ними.
Проводим дополнительную аналитику и собираем обратную связь от целевой аудитории.
Мы привлекаем представителей заказчика к процессу разработки и держим оценки перспектив проекта в актуальном состоянии.
Риск 5. Заказчик не выделяет время на участие в проекте
Сотрудники на стороне клиента не предоставляют необходимую информацию, менеджер отвечает медленно и все тормозит. При этом мы точно знаем, что проект нужен клиенту, интерес не потерян, а сроки по-прежнему разумные.К сожалению, это случается часто.
В этом случае неопытный подрядчик начнет обижаться, снизит приоритеты задач клиента и в конечном итоге переключит всю команду разработчиков на другой проект. Логика подрядчика здесь понятна; никто не хочет простоя команды из-за неоправданно долгих согласований.
Это приводит к испорченным отношениям с клиентом.
Проект не завершается.
Метод избегания
Мы лично договариваемся с клиентом об определении ответственных лиц.Обсуждаем их статус и степень ответственности.
Фиксируем их функции и обязанности в графике работы.
Как только мы замечаем, что ответственные лица столкнулись с некоторыми ограничениями, мы вместе с клиентом ищем решение, как устранить эти препятствия и продолжить процесс разработки.
Если назначенные люди не полностью соответствуют договору, мы предлагаем назначить на их место других сотрудников.
Риск 6. Длительные корректировки/переделки
Клиент не всегда достаточно компетентен, чтобы оценить степень готовности проекта.Это отлично.
Гораздо хуже, когда исполнитель не понимает, готов ли проект. Ввод в эксплуатацию часто задерживается из-за необоснованных изменений.
В результате обе стороны теряют время и деньги.
Зачастую ситуация связана с тем, что правки предлагают люди, не несущие ответственности за конечный результат. Если не позаботиться заранее о фиксации ответственных лиц, то комментарии будут поступать от неквалифицированных людей, имеющих неполный контекст. Бывает, что они участвуют на поздней стадии, и поэтому ничего не знают об ограничениях и целях проекта.
Неопытный подрядчик будет либо бесконечно оспаривать эти изменения, чтобы не вносить их за свой счет, либо, наоборот, учитывать абсолютно все замечания.
Все это пагубно влияет на достижение первоначальных целей проекта.
Метод избегания
Если комментарии приходят от лица, не несущего ответственности, то мы их записываем и обсуждаем с теми, кто несет непосредственную ответственность за проект. Прежде чем вносить какие-либо изменения, мы пытаемся понять, как изменения помогут достижению общих целей проекта.Если правки не помогают, а только мешают, выражаем обеспокоенность.
В случае, если изменения запрашивает владелец продукта, предупреждаем, что это задержит запуск.
Мы предлагаем грамотное решение по оптимизации объема работ с учетом новых вводимых ресурсов.
Вместе с клиентом мы выясняем, что будет, если выпустить продукт в том виде, какой он есть.
При отсутствии явных негативных последствий мы предлагаем перенести правку на последующие этапы.
В этом случае выбор всегда остается за клиентом.
Риск 7. Инфраструктура не готова к запуску
Затруднить запуск проекта может также то, что инфраструктура на стороне клиента не готова, юридические нюансы не оформлены и нет партнерских соглашений.Например, система предназначена для работы на SSD-накопителях, но в текущей инфраструктуре используются HDD, или бизнес запускает новый бизнес, но еще не получил разрешения государственного органа.
В такой ситуации подрядчик иногда продолжает работу, игнорируя проблемы на стороне клиента.
Потому что ему комфортно не выходить за пределы своей зоны ответственности.
Формально подрядчик делает то, что должен, проблема на стороне заказчика.
Но какой прок от продукта, который невозможно будет запустить, какую пользу он принесет?
Метод избегания
Перед началом работы мы обсуждаем с заказчиком ресурсы, необходимые для запуска проекта.Даем рекомендации, каких людей нанять и какое оборудование купить.
Если проект нестандартный, проконсультируйтесь с юристами и убедитесь, что при запуске не возникнет юридических проблем.
На этапе формирования технического задания мы проверяем возможности интеграций и другие технические аспекты исполнения конечного продукта.
Заключение
Все риски так или иначе взаимосвязаны.Одна проблема, не решенная вовремя, может вызвать эффект снежного кома.
Но как показывает опыт, есть три универсальных способа предотвратить и минимизировать последствия рисков:
- Фиксация потенциальных рисков;
- План действий по их предотвращению;
- Готовность изменить курс и поиск альтернативных решений.
Постоянно общайтесь и работайте с ожиданиями клиентов.
Ничего не скрывайте и помогите увидеть всю полноту ситуации.
За каждым описанным риском стоят реальные случаи из опыта Work Solutions. Не всегда это были истории со счастливым концом; некоторые из них обошлись компании в миллионы рублей.
Но все усилия, которые мы вкладываем в построение доверительных партнерских отношений с клиентами, зачастую окупаются, пусть и не быстро.
Благодаря прозрачности наших отношений у нас есть клиенты, с которыми мы работаем уже более шести лет и для которых мы загрузили десятки тысяч рекламных часов.
За столь длительный период сотрудничества перед проектом возникали различные риски, но мы всегда старались своевременно о них сообщить и предложить пути их решения.
Поэтому мы считаем, что грамотная работа с рисками гарантирует завершение проектов.
В комментариях предлагаю вам поделиться историями из своего опыта, когда проекты не были реализованы.
Было ли это связано с каким-либо из 7 рисков, которые мы описали? Или причина была в чем-то другом? В опросе могут участвовать только зарегистрированные пользователи.
Войти , Пожалуйста.
С какими из следующих трудностей вы столкнулись на проекте? 15,38% Недостаточная квалификация подрядчиков 2 7,69% Исчерпание бюджета до выпуска продукта 1 38,46% Изменения в середине проекта 5 7,69% Потеря интереса со стороны владельца 1 0% Заказчик не выделяет время на участие в проекте 0 23,08% Длительные корректировки/доработки 3 0% Неготовность инфраструктуры к запуску 0 0% Более одного риска 0 7,69% Другое 1 Проголосовали 13 пользователей.
7 пользователей воздержались.
Теги: #Управление разработкой #Управление проектами #Управление персоналом #Управление продуктом #риски программных проектов
-
Производительность И Эргономика
19 Oct, 24 -
Какой Быстрый Набор Вы Предпочитаете?
19 Oct, 24 -
Как Получить Больше От Тренингов И Семинаров
19 Oct, 24
