Что спросить у IT-подрядчика при внедрении – взгляд подрядчика
Этот чек-лист написан кровью менеджеров, которые в своё время не задавали клиентами подобных вопросов.
Зато теперь у них есть свой длинный чек-лист, чтобы точно всё предусмотреть. А я поделюсь той его частью, которую может использовать сам заказчик — ведь никогда не знаешь, насколько опытный провайдер тебе попался.
Не будем касаться очевидных вещей: сметы, референсов и длинного списка бухгалтерских документов, которые потребуют закупщики. Обратимся к сути – она часто остаётся за кадром.
Стоимость внедрения И ВЛАДЕНИЯ
Про внедрение вы спросите однозначно. А вот о стоимости владения часто забывают, хотя это важный момент: как купить машину и не задумываться о бензине и техобслуживании. В стоимость владения может входить подписка на лицензии (100%-ная или частичная), условия поставки обновлений, резерв часов на доработки, а также…
Принцип индексации цен в будущем
Всегда хочется зафиксировать навечно первоначальные ставки, особенно если они со скидкой — для первого контракта. Но рынок на месте не стоит, инфляция растёт, зарплаты… тоже неуправляемо себя ведут, а, значит, в тот момент, когда вы вспомните о продлении ежегодной подписки на сопровождение, цена может оказаться выше той, что забюджетировали год назад. Спрашивайте, сколько будут стоить услуги в 1-й, 2-й, 3-й год — и станет ясно, какую индексацию провайдер закладывает на рост цен.
Уровень техподдержки, SLA
Будет ли она «24/7 первая линия», или «вторая линия 5/2 с 10 до 19 по Москве», или у вас уже есть собственный SLA, который провайдер должен соблюдать — всё это будет влиять на конечную цену проекта, как в 1-й год внедрения, так и в будущем (см.пункт про индексацию).
Какие нужны доступы
Иногда информация о том, что доступов на сервера, куда всё должно быть установлено, настроено и интегрировано с другими корпоративными системами, не будет, всплывает уже после подписания контракта. Несмотря на то, что в договоре есть отдельный пункт, свидетельствующий о том, что доступы быть должны. Но — се-ля-ви — могут и не дать. Этот вопрос, скорее, к внутренним ИТ и ИБ, но у подрядчика необходимо узнать, КАКИЕ конкретно доступы понадобятся.
Кто устанавливает апдейты для On Premise внедрений
Круто, если подрядчик всё внедрит, а потом раз в месяц будет накатывать обновления самостоятельно на вашем внутреннем сервере, а внутренние ИТ этой темы касаться не будут. В мечтах — это прекрасно, по факту — такая услуга увеличит стоимость проекта. Чаще используется схема, при которой проверять и устанавливать апдейты будут внутренние сотрудники, и их ещё необходимо об этом оповестить.
Принцип оценки доработок
Наверняка по дороге понадобятся какие-нибудь незапланированные решения — новые функции, другие сценарии интеграций. Как именно провайдер будет осуществлять оценку доработок? Насколько глубоко он раскроет свою внутреннюю кухню? Или выкатит цену, которая «такова и больше никакова»?
Хороший подход, когда вы просите подробно расписать принцип оценки одной небольшой функции.
Подробно — значит, с раскладкой по типам работ — аналитика, дизайн, фронт, бэк, тестирование, отчёты, мобильная разработка, интеграции, установка обновлений, управление проектом, риски… продолжите список.
Как вы видите карту внедрения?
Что нужно будет со стороны заказчика? Кто и на каких этапах будет подключаться со стороны исполнителя?
IT-проекты — игра командная, требующая активного участия обеих сторон. По крайней мере, в точках согласования промежуточных результатов, которые очень часто оказываются причиной сдвига сроков: кто-то важный уехал в отпуск или заболел, и сроки согласования уехали следом.
Что будете делать, если всё пойдёт «не так»?
Коварный вопрос, задавать который надо глаза в глаза (можно онлайн, но с камерой). Правильного ответа — нет, но вы увидите, и ЧТО провайдер ответит, и КАК он ответит.
Плохой знак — если провайдер говорит, что ничего пойти «не так» не может. Значит, это неопытный и слишком самоуверенный провайдер.
Опытный знает — в IT, как в мореходстве: что может сломаться — обязательно сломается, а что не может — сломается тоже. Поэтому у опытных PM-ов в IT всегда есть планы B, C и D на случай шторма, штиля или нападения пиратов. Кстати, в этой точке неплохо заключить джентльменское соглашение, что если что-то случится, то провайдер не будет «заметать под ковёр», а сразу придёт к заказчику с информацией о рисках, чтобы как можно скорее совместными усилиями их демпфировать.