Как понять, что подрядчик не надежен: мои лайфхаки и советы

Обсудить

Этот текст написан в Сообществе, в нем сохранены авторский стиль и орфография

И снова всех приветствую. Сразу уточню, что под системами BA я подразумеваю системы бизнес-автоматизации (Business Automatization System).

Итак, вопрос: как часто вы сталкивались с недобросовестными подрядчиками в IT-сфере? Если судить по моему опыту, такая история весьма частая и достаточно болезненная для бизнеса.

Здесь коротко поведаю историю одного из заказчиков, обратившегося к нашей компании, итак далее — с его слов:

«Понимаете, я устроился работать сюда 10 месяцев назад, когда этот подрядчик уже был здесь. Как я понял, они пообещали нашим предшественникам поставить и настроить современную ERP-систему за 10-12 миллионов рублей. Уже услышав это, понял, что будет что-то не то. И не прогадал. Вот смотрите, есть такая кнопка «Записать», так вот, у нас их две. И знаете, какая из них работает? Правильно, никакая!»

Сектор BA весьма сумбурен, как минимум из-за наличия 223-ФЗ, который обязывает многие компании вести деятельность через тендеры, где зачастую главное правило — кто дешевле сделает, того и тапки. Вы мерно попиваете чаёк, глядя, как сильные подрядчики состязаются в цене, ждёте итогов, как на сцену врывается молодая компания, где сидит 2,5 землекопа. Они уверены в себе и демпингуют, ваши волосы встают дыбом.

«Что делать?», — судорожно связываетесь с топами, которые крутят у виска пальцем и желают вам удачи. Ну а дальше — по классике: сорванные сроки, суды, банкротство подрядчика и приходит понимание, что нужно делать всё сначала.

Бывает история и печальней, когда IT-директор неделями убеждает руководство, что брать самую дешёвую компанию на рынке слишком рискованно, а иногда приходится убеждать, что подрядчик необходим.

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

Как понять, что с подрядчиком не всё в порядке?

1) Документирование. Многие компании надеются сэкономить на этом блоке и сильно обжигаются. Поверьте, существуют кейсы, когда заказчик ежемесячно оплачивает счета, не видя никаких документов. Если коротко говорить, то у 1С существует «технология корпоративного внедрения», которую используют для внедрения BA-систем.

Всё внедрение делится на блоки:

  1. Обследование
  2. Моделирование
  3. Проектирование и разработка
  4. Подготовка к опытно-промышленной эксплуатации
  5. Опытно-промышленная эксплуатация.

(С высоко-нагруженными системами — добавляются функциональное и нагрузочное тестирование.)

Итак, по своему опыту скажу: первые два блока компаниям кажутся излишеством. За что платить деньги? У нас всё просто, не нужны нам эти ваши дорожные карты, отчёты об обследовании. Давайте как-нибудь побыстрее и подешевле!

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

Недобросовестный подрядчик будет вас уверять, что в этом нет необходимости, как говорится: «И так сойдёт».

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

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

В-четвёртых, почти все компании, занимающиеся на топовом уровне BA, имеют схожую базу документации, что позволит вам «скормить» документы другому подрядчику.

И ещё один момент: документация создаётся не только в рамках методологии Waterfall, но и в Agile. Поэтому, если ваш подрядчик утверждает, что при использовании гибких методологиях нет необходимости в документировании, не стоит верить ему.

2) Вы не проводите статус-встречи. Стоит понимать, что любое внедрение систем-BA — стресс для компании, когда ключевым пользователям приходится отвлекаться на назойливых аналитиков, которые так и снуют туда-сюда, выпытывая последовательность действий в вашей работе. Когда приходится выделять ответственных за приёмку работ, зачастую не имеющих ни малейшего представления о том, что, собственно, происходит. И здесь отсутствие статус-встреч по ходу проекта кажется нормальным.

"Что нам там делать, всё одно — ничего не поймём", однако стоит понимать что это в любом случае необходимо. Вы сможете увидеть структуру подрядчика, кто руководит и дирижирует (и есть ли вообще такой человек или они погрязли в kanban-анархии), сможете следить за ходом выполнения проекта и за планированием последующих спринтов.

3) Вам пытаются продать самодельные конфигурации. Многие подрядчики занимаются созданием своих конфигураций, которые, естественно, захотят вам продать. «Зачем вам дорабатывать и что-то дописывать? Это дороже, давайте мы вам предоставим готовое решение!»

Звучит здорово? Да, здорово, ведь так можно уменьшить издержки на разработку! Правда? Да, конечно же правда. Издержки действительно уменьшатся, но есть несколько подводных камней:

  1. Компании имеют свойство банкротиться. Как вы думаете, будет ли в таком случае кто-то заниматься поддержкой и обновлением такой конфигурации? Вопрос риторический.
  2. Конфигурация может оказаться нерентабельной для разработчика. Поддержание и обновление её может оказаться сложнее и дороже, нежели выгода от её продаж. Что дальше? См. пункт 1.
  3. Вы становитесь заложником подрядчика. Представим рынок специалистов, к примеру, 1С, где находится около 20-30 тысяч специалистов.
  4. Большинство из них будут работать с типовыми конфигурациями. Согласно данным Infostart — из всей плеяды специалистов — лишь 16% работают с нетиповыми и кастомными конфигурациями, Коих — великое множество, можете для интереса открыть Price-лист 1C.
  5. (В большинстве своём — написанные и переписанные ими самими для конкретного предприятия, поддерживаемого внутренним штатом, учитывая что по данным того же Infostart — лишь 23% работаю в фирмах-франчайзи, профессионально занимающихся внедрением).

Глядя на всю эту история — подумайте, насколько велик шанс, что вы найдёте специалистов, которые не просто сталкивались, но и имеют реальный опыт работы в такой системе? И что вы будете делать, если с нынешним подрядчиком придётся разбежаться?

4) Вы не понимаете кто работает над вашим проектом. С вами постоянно связываются какие-то люди. То один, то второй, то третий. Кто они? Хочу сразу пояснить: если менеджер меняется каждые пару-тройку месяцев, это вполне нормальная практика. Однако если меняются руководители проекта, это может вызывать беспокойство.

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

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

Можно запросить резюме по этим специалистам, увидеть их на статус-встречах, а также о чём они говорят. Если этого понимания нет — будьте начеку.

5) Общие нюансы и советы:

  1. Проверяйте наличие статусов, таких как ISO 9001-2015.
  2. Запрашивайте декомпозицию выполняемых работ.
  3. Возьмите план с декомпозицией вашего подрядчика и пройдитесь по другим компаниям, дайте посмотреть его им и запросите их оценку и комментарии.
  4. Разбейте проект на отдельные части. Обычно уже на этапе обследования можно сделать выводы о квалификации и качестве работы подрядчика. Если по результатам этого этапа у вас возникнут сомнения, запросите всю необходимую документацию. На основе полученной информации пообщайтесь с другими компаниями.
  5. Если есть необходимость в аукционе — указывайте антидемпинговую оговорку.