Существуют десятки фреймворков и методологий, которые применяются в проектной работе. Уже не осталось людей, которые бы не слышали про agile, scrum, канбан и прочие подходы. Каждый из них обещал стать серебряной пулей, которая поможет эффективно запускать и развивать IT-продукты. Но на практике только грамотная работа с рисками позволяет доводить проекты до конца любой ценой.
В этой статье мы постараемся рассмотреть самые важные риски, которые могут встать на вашем пути. Материал будет полезен всем, кто задействован в проектной работе.
Параметры успешности
Принято выделять следующие критерии, которым должен соответствовать проект, чтобы считаться успешным:
- запущен в срок;
- без превышений бюджета;
- с минимальным количеством дефектов;
- работает как задумано;
- люди им пользуются;
- решает цели, которые перед ним ставились;
- удовлетворяет бизнес-требованиям ключевых стейкхолдеров;
- дает изначально обещанную ценность бизнесу.
На деле эти параметры соблюдаются крайне редко. С небольшой разницей в оценках исследования от the Standish Group, Project Management Institute, Gartner, Wellingtone и других респектабельных организаций говорят нам, что треть IT-проектов оказываются провальными, а половина испытывает трудности. Просто задумайтесь, это ошеломляющая статистика.
Сложно сказать, какого уровня инициативы участвовали в выборках, но давайте предположим, что это крупные истории вроде провальной модернизации ИТ-инфраструктуры сети магазинов KMart за $ 1,2 млрд, которая стала одним из ключевых факторов банкротства компании.
Значит ли это, что небольшие системы, которые делают российские веб-студии, не подвержены таким же проблемам? Если почитать отзывы на популярных агрегаторах, мы увидим, что даже в случае с типовыми лендингами и шаблонными интернет-магазинами вышеперечисленные критерии успешности соблюдаются редко:
«Заказывали разработку и дизайн сайта в 2015 году. Дизайн сделали быстро, но не сказать, что качественно. Разработку внедряли по 2017-й год да так и не внедрили»
«Сайт после такой работы пришлось полностью переделывать, сначала, конечно, работа пошла активно и показалось, что все хорошо. Но потом стали замечать, что одно и тоже задание мы повторяем на протяжении месяца, в итоге отвечать на вопросы практически перестали. В итоге получились в огромном минусе, потому что пришлось нанимать другого поставщика»
«Несколько раз переносили сроки реализации сайта дополнительными соглашениями. В итоге все согласованные сроки были также сорваны и разработка сайта заняла 1,5 года. На выходе получили сырой продукт, которым невозможно пользоваться. Пришлось отдавать сайт на доработку в другую студию»
Что же говорить об индивидуальной, более масштабной разработке? Ведь чем комплекснее система, тем больше она рискует не дожить до запуска в эксплуатацию. Поэтому перед любым заказчиком и исполнителем должен стоять вопрос — как не попасть на кладбище незавершенных проектов.
Давайте разбираться, что может пойти не так при заказной разработке, и что с этим делать:
Риск 1. Недостаточная квалификация подрядчиков
Здесь проблема в том, как устроена заказная разработка. Часто не понятно, кому доверять контракт, ведь на каждом углу обещают полный цикл разработки и выполнение работ под ключ.
Решив оцифровать часть бизнеса, компания обращается в веб-студию (aka диджитал агентство / веб-интегратор). Обслуживание проходит в формате одного окна, где просят заполнить бриф, а дальше на его основе составляют ТЗ. Если система сложная и требует опытных программистов, то разработку отдают аутсорс-продакшну.
От субподрядчика требуют выполнять работы по некачественно составленному ТЗ. Если продукт доживает до релиза, то часто оказывается, что он не решает задачи компании, никто им не хочет пользоваться.
Это проблема рынка — подрядчик неадекватно оценивает собственные силы, принимает неправильные решения и в итоге ничем не помогает.
Метод избежания
Как ни банально, самое важное — это разобраться в задаче. Мы не жалеем ресурсы на погружение в бизнес заказчика. Готовы организовать командировку и на месте пообщаться не только со стейкхолдерами, но и с людьми, которые будут использовать финальный продукт. Мы не начнем тратить выделенный бюджет, пока не убедимся, что во всем разобрались.
В веб-студии ТЗ составляют аналитики, которые еще вчера работали тестировщиками. Не понимая тонкостей разработки, они создают документ, который описывает элементы интерфейса, но при этом практически игнорирует сложные интеграции и алгоритмы, которые скрываются за этими элементами.
Когда речь идет об автоматизации работы предприятия, такой подход неверен. Недостаточно нарисовать макеты и описать их в ТЗ. Поэтому этап аналитики лучше доверить системным архитекторам, которые понимают, что скрывается «под капотом».
Риск 2. Исчерпание бюджета до выпуска продукта
На рынке диджитал услуг доминируют фиксированные бюджеты и постоплата. Поэтому аккаунты и сейлзы стараются скорее согласовать смету и заключить договор. Если веб-студия некорректно составила ТЗ, провела неполное осмечивание и на разработку привлекла субподрядчика, то может случиться производственный ад.
Объем работ окажется больше, генеральный подрядчик начнет защищать свои интересы и продавливать конечных исполнителей, чтобы те уложились в бюджет. У обеих сторон срабатывает извращенная логика, каждый придумывает себе оправдание поступить чуть хуже, чем оппонент: «Предоставили плохое ТЗ, и теперь увеличивают объем? Тогда не учтем часть замечаний!» / «Мы уже пообещали клиенту, куда они денутся, доделают или не получат деньги!».
Эти политические войны скрыты от конечного заказчика. Он не догадывается, о том сколько звеньев в цепочке, и как проходит процесс разработки — партнеры веб-студии подписали NDA. В итоге разработчик жертвует качеством продукта, чтобы не работать в убыток, а веб-студия думает только о том, как скорее подписать акты и получить оплату. Никто не заботится о пользе продукта.
Метод избежания
При составлении сметы веб-студии ограничиваются только общими этапами работ: аналитика, дизайн, верстка, программирование. В то время как грамотный исполнитель внесет в смету все функциональные элементы разрабатываемой системы.
Невозможно на основе пятиминутного разговора оценить объем работ по цифровой трансформации бизнеса. Поэтому работа со сметой сама по себе требует нескольких этапов, и без аналитики получить финальную стоимость разработки не получится.
Мы предлагаем сомневающимся клиентам рассчитать стоимость по нашей детализации. Еще пока никто из конкурентов не соглашался, хотя и встречались студии, которые обещали сделать дешевле.
Но даже проработанное ТЗ и смета не защитят от дисбаланса в производственном графике. Как только такая угроза возникает, важно не только предупредить всех заинтересованных, но и предложить альтернативный план действий и оптимизацию состава работ. Нельзя умалчивать и надеяться «авось пронесет».
Риск 3. Изменения посредине проекта
Разработка комплексной информационной системы в среднем длится не меньше года. За это время может произойти что угодно.
Может случится так, что в середине пути клиент изменил способ ведения бизнеса, или появились более совершенные технологии, а может что-то просто поменялось в мире.
Например, разрабатывали систему курьерской доставки, но из-за политической ситуации поменялся рынок, крупные агрегаторы снизили свои комиссии, и продукт уже не решает те цели, которые перед ним ставились. В таких условиях абсолютно нормально, если заказчик начнет менять задачи, не дожидаясь завершения разработки. С этим нужно уметь работать.
Метод избежания
Если заказчик предлагает что-то изменить, то в первую очередь следует разобраться, зачем это, и какие обстоятельства привели к такому решению, выйти на откровенный разговор, чтобы понять причины.
Только после этого оценить, пойдут ли эти изменения на пользу, и постараться предусмотреть сопутствующие риски, в том числе превышение бюджета. Дальше найти оптимальный подход по внедрению этих изменений и предложить его. Но выбор должен оставаться за клиентом.
Риск 4. Потеря интереса со стороны владельца
Когда в мире что-то меняется, заказчик может увлечься другим направлением бизнеса, а про текущий проект забыть. Потеря интереса приводит к тому, что исполнителя либо просят полностью свернуть работы, либо, что хуже, оставляют в подвешенном состоянии. Ожидание решения приводит к простою команды и издержкам.
Но чаще интерес пропадает, когда на стороне заказчика происходят серьезные изменения в оргструктуре, на проекте сменяются люди. Как правило, эти люди не владеют полным контекстом, и следовательно, не видят ценности разработки. Их мотивация довести продукт до запуска крайне низка.
Метод избежания
Чтобы постоянно сохранять интерес, мы показываем все промежуточные результаты. Крупные системы обычно состоят из набора сервисов, поэтому в результате каждой итерации разработки мы стремимся демонстрировать полностью готовый функционал отдельного сервиса, которым уже можно пользоваться. Так клиент видит, что продукт решает его бизнес-задачи.
В ходе разработки проверяем, не изменились ли цели бизнеса, и регулярно с ними сверяемся. Проводим дополнительную аналитику и собираем обратную связь от целевой аудитории. Вовлекаем представителей заказчика в процесс разработки и поддерживаем оценки перспектив в актуальном состоянии.
Риск 5. Заказчик не выделяет время на участие
Сотрудники на стороне клиента не дают нужную информацию, руководитель медленно отвечает и всё тормозит. При этом мы точно знаем, что создаваемое решение нужно, интерес не утрачен, сроки по-прежнему целесообразные.
К сожалению, так случается часто. Неопытный исполнитель в таком случае начнет обижаться, понижать приоритеты задачам и в конечном итоге переключит всю команду на другой проект. Логика исполнителя здесь понятна, никто не хочет простоев из-за неоправданно долгих согласований. Это приводит испорченным отношениям, проект не доводится до конца.
Метод избежания
Лично договариваемся с заказчиком об определении ответственных лиц. Обсуждаем их статус и степень ответственности. Фиксируем их функции и обязанности в графике работ.
Как только замечаем, что ответственные лица столкнулись с какими-то ограничениями, вместе ищем решение, как устранить эти помехи и продолжить процесс разработки. Если назначенные люди не соблюдают договоренностей в полной мере, предлагаем назначить на их место других.
Риск 6. Затянувшиеся корректировки / доработки
Заказчик не всегда достаточно компетентен, чтобы оценить степень готовности программы. Это нормально. Гораздо хуже, когда исполнитель не понимает, готова ли система. Запуск в эксплуатацию часто откладывается из-за необоснованных правок. Это приводит к тому, что обе стороны теряют время и деньги.
Ситуация часто связана с тем, что правки предлагают те, кто не несет ответственности за конечный результат. Если заранее не позаботиться о фиксации ответственных лиц, то замечания будут поступать от неквалифицированных людей, которые владеют неполным контекстом. Бывает так, что их подключают на позднем этапе, и поэтому они не знают ничего об ограничениях и целях проекта.
Неопытный подрядчик будет либо бесконечно оспаривать эти правки, чтобы не делать их за свой счет либо наоборот учитывать абсолютно все замечания. Все это пагубно сказывается на достижении первоначальных целей.
Метод избежания
Если замечания поступают от человека, который не несет ответственности, то мы их фиксируем и обсуждаем с теми, кто ответственен напрямую. Прежде чем выполнять какие-либо правки, мы пытаемся понять, как эти изменения помогут общим целям. Если правки не помогают, а только мешают — высказываем свои опасения.
В случае, когда правки просит внести владелец продукта, мы предупреждаем, что это отсрочит запуск. Предлагаем компетентное решение по оптимизации состава работ с учетом новых вводных. Вместе с клиентом выясняем, что случится, если выпустить продукт в том виде, который есть. Когда четких негативных последствий нет, предлагаем отложить правки на последующие этапы.
Риск 7. Неготовность инфраструктуры для запуска
Препятствовать запуску в эксплуатацию может и то, что на стороне клиента не готова инфраструктура, не оформлены юридические нюансы, отсутствуют партнерские соглашения.
Например, система задумана для работы на SSD-дисках, а текущая инфраструктура использует HDD, или бизнес запускает новое направление, но оно еще не получило разрешения от государственного ведомства.
Исполнитель в такой ситуации порой продолжает вести работу, игнорируя проблемы. Потому что ему комфортно не выходить за пределы своей зоны ответственности. Формально поставщик делает как надо, проблема на стороне заказчика. Но какой толк от продукта, который будет невозможно запустить, какую пользу он принесет?
Метод избежания
Перед стартом работ обсуждаем с заказчиком необходимые для запуска ресурсы. Даем рекомендации о том, каких людей нанять и какое оборудование докупить. Если решение нестандартное, просим проконсультироваться с юристами и убедиться, что при запуске не будет проблем со стороны законодательства.
На этапе формирования ТЗ проверяем возможности для интеграций и другие технические аспекты работоспособности финального продукта.
Все риски так или иначе связаны между собой. Одна вовремя не устраненная проблема может вызвать эффект снежного кома. Но как показывает опыт, есть три универсальных способа для профилактики и минимизации последствий рисков:
- Фиксация потенциальных рисков;
- План действий по их избежанию;
- Готовность к смене курса и поиск альтернативных решений.
Правильно мыслить не проектами, а клиентами. Постоянно общаться и работать с ожиданиями. Ничего не скрывать и помогать увидеть всю полноту ситуации.
За каждым описанным риском стоят реальные случаи из практики Work Solutions. Благодаря прозрачности в отношениях, у нас есть клиенты, с которыми мы работаем больше шести лет, и для которых выгрузили десятки тысяч коммерческих часов. За столь продолжительное время сотрудничества возникали различные риски, но мы всегда старались вовремя о них сообщать и предлагать способы их решения. Поэтому мы верим, что грамотная работа с рисками гарантирует доведение работ до конца.
