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

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

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

Как грамотно подойти к составлению технического задания перед запуском IT-проекта? Что нужно учесть до перевода аванса? Павел Радченко растолковывает, как функционировать клиенту, дабы достигнуть согласия с исполнителем и нужных результатов.

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

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

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 для бизнеса» – Сергей Соловьев

Соглашение подряда между предприятием и гражданином


К прочтению:

самые интересные статьи, подобранные как раз для Вас: