Семь пунктов, которые стоит проверить до работы с китайским разработчиком ПО

Смотреть надо не на порядок ведения проекта, а на содержание поставщика

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

Поэтому проверка делится на два уровня. Верхний — управление проектом. Нижний — пригодность поставщика. Статья посвящена нижнему уровню: семи пунктам, которые показывают содержание компании до принятия обязательств. Письменно ответить на все семь могут немногие, и именно поэтому список удобно использовать для сокращения короткого списка кандидатов.

Семь пунктов проверки до подписания договора

• ① Опыт работы на производственном объекте, а не только портфель ИТ-подрядов — спрашивайте про ПЛК, промышленные шины и электроавтоматику, а не про список сданных приложений. Снять данные с оборудования — работа другого рода, чем разработка веб-системы. Спросите, на каких объектах — водоканал, энергетика, промышленная площадка — и по каким протоколам подключались контроллеры, и наличие опыта станет понятно сразу.
• ② Язык переписки и язык документации — вопрос не в том, будет ли на встрече переводчик, а в том, передаются ли техническое задание и руководство оператора на русском языке. Документ, который оператор не читает, после запуска не используется. Уточните, есть ли русскоязычное окно связи, сохраняющееся на весь проект, и был ли опыт выпуска рабочей документации более чем на одном языке.
• ③ Образуют ли передаваемые документы систему — нужен полный перечень от запуска проекта до сопровождения, а не один документ по проектированию. Проектное предложение, техническое соглашение, спецификация, таблица распределения входов-выходов, таблица адресов, схема сети, описание экранов, руководство оператора, описание таблиц базы данных, описание интерфейсов обмена, отчёт о тестировании, комплект приёмки, перечень работ по сопровождению, годовой отчёт по сопровождению — различие проявляется в том, готов ли поставщик показать такой перечень заранее.
• ④ Как организованы информационная безопасность и обращение с данными — способ подключения (VPN или выделенный канал), управление правами доступа, хранение журналов действий, место хранения исходного кода и чертежей, остаются ли данные на вашей стороне или размещаются и у поставщика. Помимо формулировок соглашения о конфиденциальности проверьте, может ли исполнитель описать это как повседневную рабочую процедуру.
• ⑤ Возможен ли пилот в узком объёме — вместо заказа всего объёма сразу спросите, возьмётся ли исполнитель за пилот на одной единице оборудования или одной линии. Поставщик, который отказывается от пилота или не может объяснить соотношение стоимости пилота и полного проекта, вероятно, не привык очерчивать границы объёма. Заодно уточните, можно ли использовать результат пилота как основу для основного этапа без переделки.
• ⑥ Можно ли внести критерии приёмки в техническое соглашение — не «реализовать функциональность», а измеримые условия: верхняя граница задержки данных, методика расчёта каждого отчёта, полнота данных после восстановления связи. Компания, которая сразу отвечает «да, это можно записать», находится в другом положении, чем та, что даёт только устные гарантии.
• ⑦ Как фиксируются сопровождение и время реакции после сдачи — окно обращений, время реакции, состав работ годового обслуживания, порядок действий при изменении линии, периодичность отчётов. Если у поставщика уже есть типовой договор годового сопровождения и форма отчёта по обслуживанию, видно, что длительная поддержка у него реальная практика.

Из семи пунктов ① ② ③ — это свойства поставщика, а ④ ⑤ ⑥ ⑦ — то, что можно проработать в договоре. Если сторона свойств не закрыта, то насколько бы аккуратно ни был составлен договор, нагрузка на вашу собственную команду не снизится.

Чем отличается чистый ИТ-подряд от поставщика с производственным опытом

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

Таблица сопоставляет тенденции, а не оценивает конкретные компании; на практике встречаются поставщики, совмещающие оба характера. Основанием для решения служит не категория, а содержание ответов на пункты с ① по ⑦.

Перечень документов фиксируется до подписания, а не потом

Трения в промышленной системе обычно возникают в момент, когда после запуска обнаруживается, что какого-то документа нет. Смена ответственного, модернизация оборудования, расширение второй очередью — в каждом из этих случаев объём документов на руках равен объёму работ, которые можно выполнить самостоятельно. Документация — не приложение к результату, она сама является результатом.

Проверка простая: до подписания попросите поставщика перечислить документы, которые он передаст. Если перечень не появляется или в ответ звучит «предоставим обычный комплект», системы за этим, скорее всего, нет. Компания, у которой система есть, может показать перечень примерно в такой разбивке.

• Планирование и договор: проектное предложение, техническое соглашение, спецификация — документы, определяющие объём и условия приёмки
• Проектирование: таблица распределения входов-выходов, таблица адресов, схема сети, описание экранов — документы, определяющие источник каждого сигнала и способ его отображения
• Эксплуатация: руководство оператора, описание таблиц базы данных, описание интерфейсов обмена — документы, которыми после запуска пользуются служба эксплуатации и ИТ-отдел
• Верификация: отчёт о тестировании, комплект приёмки — документы, подтверждающие достижение согласованных критериев
• Сопровождение: перечень работ по сопровождению, годовой отчёт — документы, фиксирующие объём работ после сдачи и фактически выполненные действия

Пять наблюдений, которые даёт пилот в узком объёме

Даже получив письменные ответы по всем семи пунктам, невозможно заранее понять, как сложится совместная работа. Пилот с очерченными границами за несколько недель показывает то, чего не видно ни в одном пакете документов. Компании, работающие системно, ведут проекты по этапам — диагностика, пилот, внедрение, приёмка, сопровождение, расширение, — поэтому заказ только этапа пилота для них выполнимая просьба.

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

• Характер вопросов — уточняют ли условия на объекте или принимают документ требований как данность и идут дальше
• Скорость и форма ответа — остаются ли ответы устными или фиксируются документами и схемами
• Детализация документов — читаемы ли материалы пилотного этапа, когда возвращаешься к ним позже
• Как обрабатываются изменения — сообщают ли сначала об области влияния или молча переделывают
• Фактическое качество русскоязычных документов — похожи ли они на вывод машинного перевода или читаются как текст, понятный оператору