Инструкция по выживанию: чему мы научились, проведя 200+ проектов по внедрению корпоративного ПО
Руководитель корпоративных практик ALP Group Александр Казеннов делится советами по навигации в сложном мире заказной разработки ERP-систем и по работе с крупнейшими корпорациями страны.
За четверть века в интеграторском бизнесе мы повидали многое. Пришло время передать опыт «молодым»…
1. Протоколируйте всю коммуникацию с заказчиком
Как говорил доктор Хаус, все лгут. Каким бы замечательным и распрекрасным ни был клиент, случается всякое — человеческий фактор никто не отменял. Чтобы потом не пришлось доказывать, что ты не верблюд, лучше сразу обезопасить себя от «переобуваний» заказчика и взять привычку письменно фиксировать даже мельчайшие договоренности. Еще лучше — если за это отвечает отдельный человек (например, проджект-менеджер). И здесь не нужно бояться писать официальные письма. Личный контакт с заказчиком и непринужденное общение в чатах — это, конечно, хорошо, но о сроках сдачи этапов проекта и тому подобных вещах лучше сообщать по электронной почте. Бывает, что скандальную ситуацию на уровне среднего управленца можно решить просто показав переписку по проекту топ-менеджменту.
2. Составляйте карту рисков
По моему личному опыту ведения крупных корпоративных проектов, около 80% рисков, которые могут произойти, обязательно происходят. То уволится ключевой сотрудник, отвечающий за реализацию проекта на стороне заказчика, то появится новое требование, которое затянет оговоренные сроки внедрения системы, то новый руководитель увидит себе всё по-другому… Исследования показывают, что средний ИТ-проект превышает изначальный бюджет на 27%, а каждый шестой проект превращается в потенциальную катастрофу с перерасходом средств на 200% и превышением сроков на 70%. Чтобы не оправдать эту статистику, все возможные риски лучше продумывать заранее, а затем закладывать вместе с заказчиком дельту на изменения по времени и бюджету (примерно 30% — для участков проекта с высоким риском и примерно 10% — для всех остальных). Подробнее о том, как правильно управлять рисками, на VC уже рассказывала моя коллега.
3. Следите за финансовой подушкой безопасности
Учитывая критичность и длительность проектов внедрения корпоративных систем, их разработка почти всегда начинается раньше, чем в наличии будет подписанное техзадание. Больше того, на таких проектах, как правило, платят уже после сдачи работы. В таких условиях компании-интегратору обязательно нужно иметь бюджет на выплату зарплат своим сотрудникам. Когда сроки выплаты затягиваются, ключевые сотрудники увольняются, и проект идет под откос. Я видел, как некоторые товарищи по цеху оказывались таким образом на грани банкротства.
4. Обучайте своих сотрудников регламентам работы заказчика
Еще до полноценного вхождения в проект стоит изучить принятые у заказчика регламенты работы. В первую очередь, так вы сможете отобрать сотрудников в проектную команду — некоторые специалисты могут отказаться работать в определенных условиях. Например, на крупных корпоративных проектах у подрядчика зачастую нет доступа к продуктивным данным. Это значит, что команде придется работать с симулированными обезличенными базами, а это не всем подходит. Кроме того, обучив сотрудников регламентам заказчика, вы обезопасите себя от потенциальных скандалов и нарушений. На моей памяти был такой трагикомичный случай: один специалист отсканировал на корпоративном сканере свой паспорт и отправил его себе на почту. Заказчик об этом узнал (мониторинг переписок — нормальная практика у крупных корпораций), и компании прилетел штраф.
5. Не бойтесь смешивать методологии
Очень важно сразу выстроить правильный конвейер разработки. Опыт показывает, что в отношении крупных проектов внедрения лучше всего работает гибридная методология управления Agile + Waterfall. Основную разработку можно вести по классическому «водопаду», но при появлении новой сложной задачи не нужно стесняться решить ее с помощью Agile-подхода.
6. Предлагайте заказчику новое
Очень часто интеграторы работают исключительно в рамках своих систем и боятся предложить клиенту нестандартное решение. Но адекватный клиент непременно оценит, если вы предложите ему что-то действительно стоящее. Бывают ситуации, когда лучше вообще поменять вектор автоматизации. Даже если компания-интегратор специализируется, скажем, на внедрении систем из продуктовой линейки 1С, она может предложить заказчику реализовать на конкретном участке другое решение. Одним из таких участков может быть решение задач с интегральными уравнениями — область вычислений, с которой 1С справляется пока не достаточно оптимально.
7. Ведите детальную техническую документацию
На отечественном рынке есть не самые добросовестные интеграторы, которые пишут очень обтекаемую входную документацию без каких-либо подробностей. Это не ошибка, а намеренный ход, чтобы привязать заказчика к себе. Если только один подрядчик знает, какие метаданные есть в системе, значит, клиент не сможет прийти к другому интегратору и каким-то образом доработать решение. В случае смены подрядчика неудачную систему придется сносить и разрабатывать с нуля. На мой взгляд, замкнуть все знания на себе — хоть и эффективный, но грязный прием.
Если все интеграторы будут следовать этим, казалось бы, очевидным советам, глядишь — взаимодействия даже с самыми строптивыми заказчиками будут приносить гораздо меньше головной боли.