Ведение IT-проектов. Что учитывать заказчикам при внедрении новых инструментов?

Внедрение любого решения — это проект. Управлять проектами гораздо сложнее, чем управлять процессами. Процесс — многократное повторение одних и тех же действий. Проект — индивидуальная история, реализация уникальной идеи.

При внедрении новых инструментов, подходов заказчики часто совершают ошибки, которые приводят к печальным результатам. Рассказываем, где «лежат грабли» и как на них не наступить.

5 ошибок заказчиков при запуске ИТ-проекта

1. Отсутствие четкой цели

Предположим, что существует компания А, которая делает бизнес на стройматериалах. Долгое время компания работала продуктивно: руководитель ставил перед сотрудниками задачи, а те их быстро выполняли. Но со временем штат разросся с 10 до 55 человек и начался хаос: отделы стали косячить, зашиваться в рутинных задачах.

И вот руководитель компании Иван Иваныч услышал от зама, что продается волшебная CRM «охрененно», которая быстро наводит порядок в компании.

Окрыленный Иван Иваныч полетел к интегратору, и их общение было таким:

– Внедрите мне CRM «охрененно».

– Какова цель, какие задачи хотите решить?

– Что за странный вопрос? Я просто хочу автоматизировать работу компании.

Иван Иваныч нарисовал у себя в голове некое будущее, в котором компания «будет жить и петь по-новому», а цели и задачи внедрения не определил. Что он получит? Решение, которое не будет закрывать проблемы компании или будет закрывать их частично.

Согласно легенде, римский император Карл Великий был неграмотным и использовал книги в качестве подушек, чтобы научиться читать. Сегодня некоторые компании поступают также: внедряют новое решение, надеясь, что все по волшебству заработает. 

Некоторые интеграторы, к которым обращаются заказчики, также не погружаются в проблемы клиента. Они долго бьются вокруг ТЗ, вокруг цены. Потом ТЗ реализуют, а клиенту это не надо. И начинается: «Ой, нужен эджайл, потому что там заказчик и подрядчик работают вместе, потому что бизнес меняется, требования меняются!» Чуваки, а вы выяснили, что на самом деле клиенту нужно? Исследовали причины, почему у компании появился запрос на интеграцию? Нет! 

Вытаскивают из заказчиков клиентскую проблему те интеграторы, которые настроены на долгосрок, а не на работу в моменте. Такие подрядчики понимают, что если будет клиентское «мне не надо», то они потеряют заказчика.

2. Обращение к бизнес-аналитикам

Некоторые заказчики обращаются к бизнес-аналитикам, которые должны выявлять проблемы бизнеса и предлагать их решения. Но, как правило, это выбрасывание денег на ветер: только четверть из них погружается в проблемы компаний и задает вопрос «Зачем?» Остальные — переводчики, которые трансформируют язык бизнеса в язык программеров, что не имеет никакого смысла, так как программеры могут сделать это сами. 

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

3. Раздувание объема проекта

Часто, когда определены границы ИТ-проекта, заказчику вселяется в голову какая-то блажь и он начинает бегать к интегратору с бесконечным новыми идеями: «Добавь то, добавь это. Сделай кнопку круглой, квадратной, в виде зайчика!» 

А если интегратор сопротивляется хотелкам заказчика, говорит, что это дополнительные траты, то заказчик встает на дыбы, топает ногами, так как хочет получить решение за прежние деньги.

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

4. Игнорирование ограничений

Представим, что нужно провести воду до соседнего населенного пункта. Мы соорудили водопровод из элементов трубы с разным диаметром: где-то толщина трубы несколько сантиметров, где-то полметра. Насколько эффективно будет работать водопровод? Будет ли пропускная способность трубопровода равна среднему диаметру труб?

Пропускная способность труб будет равна пропускной способности самых узких участков, и водопровод начнет работать эффективно только в том случае, если их расширить. 

Этот пример отражает главную идею теории ограничений (ТОС) — методологии управления производством, созданной в 1980-е годы Элияху Голдраттом. Она заключается в том, что если найти ключевое ограничение, самое узкое место системы и его устранить, то система начнет работать гораздо эффективнее.

ТОС предусматривает 5 шагов:

1. Поиск ограничения. Ищем операцию, которая снижает производительность команды.
2. Устранение ограничения с помощью текущих ресурсов. Убираем препятствия в узком месте, которые мешают работать.
3. Преобразование других элементов системы. После устранения ограничения многие бизнес-процессы требуют трансформации.
4. Расширение ограничения. На этом этапе как раз идет речь о внедрении. Если ограничение устранили, но это не увеличило эффективность работы, то вкладываются ресурсы в новое оборудование.
5. Поиск нового ограничения. Если на предыдущих этапах ограничение устранено, то возвращаемся к первому этапу: ищем и преодолеваем новое ограничение.

Проблема некоторых руководителей в том, что они перескакивают через первые три этапа и сразу кидаются расширять ограничение: «Ой, нам не хватает ресурсов, давайте что-то внедрять!» А ты уже оптимизировал управление текущими ресурсами? Они уже работают с максимальной скоростью? 

Есть метод управления проектом — метрики, которые позволяют отслеживать эффективность процессов, работу сотрудников. С ними можно прийти к команде и сказать: «Ребята, сейчас производительность низкая. Проект в красной зоне. Найдите ограничение, ключевую проблему. Думайте, что можно сделать, чтобы вернуть проект в зеленую зону».

Все, мы принесли сотрудникам метрики, которые наглядно демонстрируют низкую эффективность работы. Дальше они обсуждают и ищут. Даже такая простая штука может ускорить работу команды в несколько раз. 

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

5. Экономия на качестве проектирования, качестве реализации

Некоторые заказчики покупают у интегратора решения и говорят: «А дальше мы сами». Т. е. они относятся к интегратору как к поставщику софта, железа. 

Но внедрение — это не просто поставка, но и проект организационных изменений: консалтинг + айтишка. И именно так к нему нужно подходить. Только эта история принесет пользу компании.

Да, можно зажать деньги на сторонние ресурсы и попытаться сделать все самим, но чаще всего экономия на внедрении приводит к тому, что компания получает не оптимальное, а проблемное решение. Низкое качество, дефект

Что делать заказчикам, чтобы внедрение было успешным?

1. Упорядочить текущую работу команды

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

Один из способов найти ограничения — построить дерево текущей реальности (инструмент методологии ограничений). Подробную инструкцию можно найти здесь.

Стандартизация и описание процессов — также важное условие успешного внедрения. Пока в работе команды не будет четкой логики, ни о какой автоматизации не может идти и речи. Об описании и стандартизации процессов читайте здесь.

2. Не пытаться все делать собственными ресурсами

Часто компании пытаются полностью закрыть внедрение собственными ресурсами, хотя их сотрудники не обладают нужными компетенциями и опытом. Для управления проектом нужно обладать технической экспертностью, знать методологии управления, уметь разрабатывать схему перехода…

Подумайте над тем, чтобы привлечь внешних специалистов, у которых есть необходимый опыт. Главная ценность сторонних консультантов — возможность посмотреть на бизнес-процессы со стороны, увидеть те косяки, которые не замечают внутренние ребята.

3. Определить, для чего нужно решение

Перед запуском ИТ-проекта четко сформулируйте, какие именно проблемы вы хотите решить, что вам нужно исправить в работе команды.

Если вы выбрали решение, то убедитесь (самостоятельно или с помощью консультантов), что приобретаемые ПО, железки способны решить ваш круг проблем. Не нужно покупать систему только потому, что вам кто-то рассказал, что она волшебная.

4. Четко сформулировать требования к внедрению

Когда к заказчику приходит интегратор, его встречает РП — руководитель проекта со стороны клиента. И часто на просьбу интегратора встретиться с руководителем РП отвечает: «Я здесь главный, я отвечаю за проект. Иван Иваныч меня во всем поддерживает. Он очень занят, не нужно его беспокоить». 

Проходят месяцы внедрения и на заключительном этапе вдруг появляется Иван Иваныч, который делает круглые от удивления глаза и говорит: «А что вы вообще сделали? Мне это не нужно!»

Чтобы такая история не произошла, в основе требований к внедрению должны лежать ожидания реального заказчика (гендира, владельца бизнеса), который будет оценивать результаты.

5. Не раздувать границы проекта

Не закладывайте ничего на перспективу: сейчас этот функционал не нужен, но вдруг что-то поменяется? Все «вдруг» нужно сразу отметать. Чтобы внедрение было успешным, нужно четко определять границы и за них не выходить. 

Это можно сделать с помощью устава — одного из инструментов управления проектом. Для составления устава команде нужно ответить на 10 вопросов:

1. Какое решение внедряем?
2. Для чего нужно это внедрение?
3. Как определим, что проект закончился?
4. Как определим, что проект успешен?
5. Какими свойствами будет обладать результат?
6. В каких условиях выполняется проект?
7. Что поставит под угрозу достижение цели?
8. Кто участвует, кто может помочь в достижении цели? Здесь нужно подумать, будет ли достаточно усилий участников проекта. Возможно есть люди, которые могут чем-то помочь. Например, контактами.
9. Сколько времени уйдет на проект?
10. Какими ресурсами мы располагаем?

Устав должен висеть в публичном месте, например, в кофе-точке. Это нужно для того, что если кому-то захочется раздуть объем проекта, ткнуть его в устав носом и спросить: «Какую характеристику помогает закрыть твоя классная идея?».

Сначала достигаем цель, которая определена, потом все остальное. Все дополнительные идеи выносим в другой проект.

6. Составлять дерево перехода

Дерево перехода — еще один инструмент из методологии ограничений. По сути, это детальный план внедрения, который позволяет определить порядок действий, препятствия и пути их преодоления.

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

Не составляйте дерево перехода в программах. В них делайте понятные производственные истории. Дерево перехода для нового проекта создавайте всей командой с помощью стикеров на стене.

7. Уделять внимание точности планирования

Показатель точности планирования — разница между прогнозируемым и реально затраченным временем. Он нужен для того, чтобы определить сроки выполнения проекта командой.

Если точность планирования низкая, то возможно только грубое прогнозирование сроков завершения проекта. В итоге буфер проекта становится большим и внедрение идет медленно. 

При оценке задач, целей нужно применять ковбойский метод: мы не ищем оптимальную оценку, а определяем, сколько минимум и максимум времени понадобится, чтобы дойти до следующей цели.

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

Так у нас появляются средние показатели точности планирования. Например, мы поняли, что делаем работу на 30% дольше. Берем наш рабочий план и увеличиваем временные показатели на 30%. Все это пересчитываем в рабочие недели и получаем надежный срок исполнения проекта. 

Чем больше разница между максимумом и минимумом, тем больше угроз содержит цель. В цели с большой разницей оценок нужно включать механизм анализа угроз:

1. Выявляем угрозы с помощью вопроса: что угрожает достижению цели? 
2. Задаем вопрос: какую цель нужно достичь для снижения этой угрозы?
3. Cоздаем цепочку снижения угроз.

Цепочка снижения угроз — это алгоритм планирования. Как только мы снизим угрозы, уменьшится оценка и проект пойдет быстрее. 

Цепочка снижения угроз, как и дерево перехода, выстраивается с помощью стикеров на стене.