Взаимопонимание между заказчиком и подрядчиком при составлении ТЗ

Павел Радченко, предприниматель

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

1) К нашему превеликому сожалению, в IT-отрасли нет кнопки «сделать все», а если она и есть, то уж точно она не работает как надо, или только по осредненному алгоритму.

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

Все приходится делать самим, а все информационное (CRM, ERP…) нам в этом помогает.

Пара типичных бесед

Одной из особенностей отечественной IT-индустрии по-прежнему является небрежное отношение к проявлениям «бюрократии» вроде технического задания, пояснительных записок, документации, подробных актов сдачи-приемки и другим скучным бумажкам. Логичное следствие – разговоры такого плана:

Заказчик: Сделайте нам что-нибудь для улучшения бизнеса.

Исполнитель: Вообще без проблем, это наше призвание.

Заказчик: Отлично! Погодите… Эй, а что это вы нам сделали?!

Исполнитель: Как и просили, «что-нибудь».

Заказчик: Нам это не подходит. Переделайте.

Исполнитель: Гм. Ну, тогда давайте еще денег.

Заказчик: Что значит еще? Мы недовольны, переделывайте!

Исполнитель: Был заказ, он оплачен и выполнен. До свидания.

Как правило, в такой ситуации обе стороны особой конструктивностью и гибкостью в переговорах не отличаются. Исполнитель действительно мог потратить свои ресурсы на разработку и/или внедрение «чего-нибудь», и считает, что работу выполнил. Заказчик осознал, что ему было нужно, только получив то, чего было не нужно. Возможно, у него до сих пор нет четкого понимания своих задач. Это тупиковая ситуация, все выходы из которой для участников убыточны. Вопрос только в том, кто понесет дополнительные расходы и в каком объеме. Если заказчику очень нужно решение, сроки горят, он может доплатить – и получит в итоге решение за двойную, фактически, цену. Или подрядчик зависит от результатов сильнее, тогда он берется за новый комплект «хотелок» клиента, а рентабельность проекта летит под откос.

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

Другая типичная беседа с часто встречающимся видом IT-подрядчиков: красивый современный сайт, внешне адекватное предложение, быстрые четкие ответы, договор – и нулевой опыт практической деятельности, полное отсутствие понимания отраслевой специфики, вообще никакого представления о том, что происходит на метр дальше их коммерческого предложения.

Заказчик: Нам нужно сделать вот это.

Исполнитель: Ок. Еще добавим печать напрямую, для удобства.

Заказчик: Прекрасно. То, что нужно!

Исполнитель: Готово. Печать напрямую по Ctrl+Alt+P.

Заказчик: Про печать понятно, а как нам…

Исполнитель: Не, по бизнес-процессам ничего не знаем.

Заказчик: Что же нам делать?

Исполнитель: Почитайте документацию, может, там есть.

Заказчик: Вы что, даже не прочитали документацию к продукту?!

Исполнитель: У нас узкая специализация и мало времени. Пока!

Понятно, что через некоторое время такой исполнитель подучит матчасть, научится нормально общаться с клиентами и обращать внимание на их пожелания и просьбы. Либо вылетит с рынка. Но пока это случится, несколько жертв останутся один на один с непонятными бумажками, – в которых, кстати, может и не оказаться нужных им ответов. Самое обидное, что в России увеличение затрат на проект не означает улучшения качества. Размер IT-компании – тоже не всегда гарантия хорошего качества. Буквально – как повезет.

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

Три хорошие приметы при выборе IT-подрядчика

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

• Осознать текущую ситуацию;
• Понять, что именно хочется изменить;
• Оценить, как эти изменения скажутся на смежных бизнес-процессах, подразделениях, конкретных сотрудниках, клиентах;
• Сформулировать задачу.

Это кажется настолько банальным, что неловко даже упоминать. Тем не менее, самый большой риск многих отечественных IT-проектов заключается в том, что постановкой задачи начинают заниматься не на нулевом, подготовительном этапе – а где-нибудь после оплаты товаров/услуг подрядчика, внедрения, обучения, доработок, и вдруг (неожиданно, всегда интрига) выясняется, что это совсем не то. Или не того качества. Или плохо интегрируется с уже используемым софтом.

Первая хорошая примета – задача сформулирована заранее, четко, однозначно, и ни в коем случае не изолированно, а с учетом бизнес-процессов компании и вектора ее развития. На этой стадии очень пригодится мнение не только специалистов заказчика, но и IT-компании. Потому что бизнес знает (должен знать, по крайней мере) свои реальные потребности, но далеко не всегда адекватно оценивает решения. Перегибы возможны в обе стороны.

Многие заказчики ищут «волшебную кнопку», однократное нажатие которой приведет их к вечному процветанию. Зато другие переоценивают сложность, не верят в то, что вообще это можно сделать, тем более быстро и в рамках бюджета. Обсуждение с IT-специалистами нужно для уточнения «берегов», прояснения ожиданий. Желательно не ограничиваться одним и даже несколькими мнениями. Как раз сейчас, например, мы завершили проект, который другой местный исполнитель считал «невозможным».

На верхнем уровне детализации задача должна быть связана с бизнес-интересами компании заказчика. Например:

• Удержать существующих клиентов;
• Контролировать производство;
• Повышать эффективность;
• Прояснить себестоимость;
• Увеличить прозрачность таких-то бизнес-процессов.

На нижнем уровне детализации задача должна быть выражена в терминах, от которых легко перейти к выбору конкретных решений. Например:

• Создать систему лояльности;
• Автоматизировать контроль качества продукции;
• Внедрить систему ключевых показателей;
• Детализировать финансовую отчетность;
• Развить документооборот с определенными выгрузками.

Заметьте, что сначала речь необязательно идет о детально проработанном плане. Техническое задание (ТЗ) нужно, разумеется, но его наличие – это уже вторая хорошая примета. Потому что ТЗ самое важное, оно решает все. ТЗ может быть на листке бумаги из пяти пунктов (в случае внедрения существующих прикладных программ) или иметь вид многостраничного текста, в котором учтены все мелочи, вплоть до схемы укладки проводов по Фен-Шую. Техническое задание позволяет прояснить и синхронизировать взаимопонимание участников, они четко видят единую конечную цель. Соответственно, только на основании ТЗ можно определить и конечную стоимость проекта.

К слову, качественная разработка ТЗ составляет ощутимую часть этой стоимости. В зависимости от сложности, техническое задание «весит» от 10 до 40% бюджета проекта! Многие управленцы в России упорно отказываются понимать этот факт. Точнее, не получается донести его до заказчиков достаточно твердо, чтобы перейти от печальных вздохов украдкой к нормальной, общемировой практике – и рентабельности, соответственно, а также риск-менеджменту.

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

Есть очень простое правило: все, что не учтено в ТЗ, будет оплачиваться отдельно и выполняться в дополнительные сроки. Достаточно подумать об этом с такой точки зрения, чтобы понять – заказчик ничуть не меньше исполнителя заинтересован в качественном техническом задании.

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

1) Сразу нет любым решениям, привязанным к разработчикам-индивидуалистам. Потому что они болеют, переезжают, наглеют, уходят в армию, загул или депрессию – другими словами, с ними может произойти все, что угодно. Серьезный проект могут хорошо реализовать компании с опытом. Аргументов в пользу такого вывода много, его подтверждают практически все следующие пункты этого списка.

2) Подрядчик должен обладать практическим опытом – успешным, разумеется, и строго по рассматриваемой нише. Например, компания «1С:Франчайзи» за многолетний опыт внедрений и поддержки различных продуктов может ни разу не столкнуться с 1С:CRM. При обращении клиент с большой вероятностью получит заверения в том, что все будет отлично – но шансы на успех в реальности довольно низкие. Возможно, в штате подрядчика вообще не окажется специалистов с нужными знаниями. Проект, конечно, завершат. С каким качеством – вопрос. Проблемы будут, не сомневайтесь. Всего наперед не просчитать, да это и не нужно. Главное, адекватно оценить бюджет и сроки, взять хороший запас и передать оперативное управление специалистам.

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

4) Сданная и принятая информационная система – это не просто программный код, работающий на компьютерах, а инструменты, которые соответствуют бизнес-процессам компании, понятные сотрудникам и проверенные в действии. Внедрение без обучения – деньги на ветер.

5) Кроме того, моральное устаревание системы начнется ровно в тот момент, когда стартует ее промышленная эксплуатация. Поэтому обновления должны входить в комплект, и это правило распространяется на информационную поддержку тоже. Неизбежно потребуются еще и доработки по вашим собственным новым требованиям – скорее всего, задолго до завершения внедрения, и потом еще неоднократно. Это тоже нужно отразить в бюджете, а также учитывать при выборе подрядчика.

Итак

Резюмируя, хочется посоветовать – подходите к делу без лишних иллюзий, но и без чрезмерной паранойи. Переход на новое IT-решение потребует больше ресурсов и времени, чем можно предположить без опыта внедрений. Но это окупается. Современный бизнес немыслим без IT. Он в значительной степени состоит из программного обеспечения, коммуникаций, различных продуктов и сервисов. Это динамическая, беспокойная и слабо прогнозируемая среда. Тем не менее, она дает уникальные преимущества, которые другими способами никак не обеспечить.

Большая часть IT-инструментов – западные технологии. Многие «лучшие практики», которые содержат эти решения тоже западные, и на отечественный бизнес-ландшафт ложатся не очень гладко. Поэтому их лучше не слепо копировать, а использовать в качестве основы, адаптируя под местные особенности и задачи. Тогда российская «неохота», в которой часто вязнут чужеземные информационные комбайны, из фактора риска перейдет в категорию полезного скептического отношения к новинкам. Используйте ее на полную катушку при постановке задачи и выборе решений. А потом настойчиво добивайтесь результатов – и они обязательно будут.

Редактор рубрики «IT для бизнеса» – Сергей Соловьев