Внедрение CRM без ТЗ: дорога в никуда

    Доработка типового программного обеспечения под требования заказчика — это обыденное дело, если оно правильно организовано. Однако часто можно встретить примеры, когда разработчики берутся выполнить работы без ТЗ (технического задания) по настоянию заказчика. Что происходит в итоге? Обе стороны загоняют себя в яму, которую выкопали сами. Разработчик не подозревает, что он будет вынужден выполнить объем работ во много раз больше предполагаемого, и рано или поздно остановит эти работы, нахлебавшись раздувшихся аппетитов заказчика, которые будут расти в геометрической прогрессии, не имея формальных ограничений. В такой ситуации разработчик рискует никогда не завершить работу, а заказчик — никогда не получить нужного результата. На ранних этапах развития компании мы в этой яме побывали неоднократно, поэтому представляем вторую часть наших историй о ТЗ — когда его нет.



    Первая часть о том, как составлять техническое задание — по ссылке.

    Мы — разработчики CRM. Наша RegionSoft CRM — довольно мощное профессиональное решение для бизнеса. Система десктопная и нам очень часто достаются клиенты, которым нужен полноценный проект внедрения с заточкой под индивидуальные особенности клиентов. У кого-то это особый цикл продаж, кому-то нужно отслеживать транспорт, третьим необходимы особые отчёты, настройка системы KPI или бизнес-процессов. Плюс, ещё встречаются особенности внедрения, например, распределённые офисы, филиалы, настройка телефонии, торгового оборудования и т.д.

    В частности для CRM, а в целом для любого корпоративного программного обеспечения подходит схема: лицензии + доработки + внедрение. Клиент может купить лицензии, установить ПО, самостоятельно взять документацию, разобраться и начать работать. Может купить лицензии, заказать доработку, а остальное сделает сисадмин. А может купить лицензии и заказать внедрение. Ну и связка из всех трёх элементов также возможна. Так вот, этапы доработки и внедрения всегда требуют составления технического задания, в котором будут поэтапно указаны все работы, сроки, цены и прочие условия.

    Мы бы не вздыхали и не поднимали проблему работы с ТЗ ещё раз, а пилили бы и пилили код всей командой разработки, если бы не камень преткновения, с которым мы встречаемся очень часто — клиенты не хотят составлять техническое задание на доработку. Не хотят ТЗ, то есть фактически находят верный способ никогда не подписать акт. Вот самые распространённые причины.

    • И так всё понятно — зачем тратить время?
    • Здесь всё просто! Да я на пальцах объясню.
    • Я не умею его составлять.
    • Почему я должен платить за то, что войдёт в следующий релиз?
    • Вы составляете ТЗ за деньги?!

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

    ТОП-6 фраз клиентов — верный способ разозлить разработчика


    И так всё понятно — зачем тратить время?


    Комментарий разработчика: Чтобы определить четкие задачи и цели, формализовав их на бумаге. Ведь то, что оговаривается устно, нельзя использовать в качестве прямого указания к действию. Также, устные договоренности впоследствии легко трактовать кому как удобно. А если ТЗ объемное и требует длительного срока реализации, кто потом будет вспоминать о том, какие именно формулировки использовали стороны, когда оговаривали требования к доработке?

    У нас есть базовое решение — CRM, к ней есть требования по доработке. Бывает, мы берёмся за разработку целых модулей или дополнительного к CRM программного решения (как у нас вышло, например, с GeoMonitor и RegionSoft Retail). У клиента есть бизнес, который он хочет автоматизировать. У него есть набор проблем, которые эта автоматизация должна решить: повысить продажи, упорядочить процессы, сократить время на рутину, сделать прозрачными сделки и склад и т.д. Нам понятно, как работает наш софт, клиенту — как функционирует его бизнес. И когда мы встречаемся, то должны понять друг друга.

    Ошибка многих вендоров в том, что они предлагают решение и не хотят вникнуть в проблему заказчика. Ошибка клиента — видеть проблему большей, чем она есть на самом деле и требовать «переделать всё». Составление технического задания — тот самый процесс, в ходе которого удаётся соотнести требования и возможные решения. Более того, чаще всего доработка по ТЗ обойдётся дешевле ввиду того, что программисты не будут тратить бесконечное количество человеко-часов на проект.

    Как понять друг друга, работая над ТЗ?

    • Говорить на общепонятном русском (другом) языке. Вряд ли каждый клиент поймёт фразы «бэкапить базу на резервный сервер» или «накатим апдейт на продакшене». Нужно выслушать обе стороны: рассказ вендора о возможностях софта, рассказ клиента о нуждах бизнеса, задать вопросы и приступить к составлению ТЗ именно по тем фичам, которые реально нуждаются в доработке.

    • Делать техническое задание поэтапным: разделить предстоящие работы на блоки с указанием суммы и сроков по каждой из групп работ.

    • Лучше всего, если от заказчика в процессе будет принимать участие технарь или человек, знающий процесс до самой мелкой вехи. При всём уважении, стандартный офисный маркетолог CRM не внедрит.

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

    Здесь всё просто! Да я на пальцах объясню


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

    Заказчику кажется, что изменить цикл продаж, создать один отчёт или прикрутить диаграмму Ганта — просто. Более того, наверняка он погуглил или ему рассказали, что это делается в несколько десятков строк кода. Да, сам код перечисленных сущностей опытным программистам по плечу, но заказчик не догадывается о том, что всё это нужно встроить в архитектуру основной программы и ради «ну там небольшой доработочки» придётся основательно менять логику какого-либо модуля или системы.

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

    Я не умею его составлять


    Комментарий разработчика: Но Вы же можете на простом языке озвучить требования к функционалу, которые должны быть созданы. Это можно сделать в тезисном виде, а детали оговорить устно. Но в итоге, ТЗ составляет разработчик на основе Ваших требований и с учетом всех деталей. Ведь Вы не вправе рассчитывать на то, что Вам будут сделаны работы, не оговоренные в ТЗ! Вы за них даже не платили… Верно?

    Получается, главное — донести требования. ТЗ — это рабочий документ для того, чтобы понять назначение, цели и видение продукта. По нему будет подписываться акт, по нему же будут вести разработку программисты из команды вендора. Для них это — инструкция, согласно которой они продвигаются в разработке. ТЗ — совсем не обязательно 100 страниц (хотя бывает и 400, ну это в крупных интеграционных проектах), это может быть и пара пунктов, но они обязательно должны быть. Клиент, в свою очередь, сможет принять работы, сверяясь с техническим заданием — и в случае коллизий показать разработчику на то, что сделано не так. Ну или наоборот.

    Почему я должен платить за то, что войдёт в следующий релиз?


    Комментарий разработчика: Никто заранее не знает, войдет ли доработка, заказанная Вами, в типовое решение в будущих релизах. Это определяется гораздо позже на совете разработчиков при подготовке глобальных обновлений. Однако действительно, любая доработка при её полезности для широкого круга потребителей, может быть включена в типовое решение. Это право разработчика и оно не обсуждается.

    У нас есть такая практика — лучшие решения и доработки мы вводим в релиз. Кто видел RegionSoft CRM поближе, могли заметить, насколько она функциональна и глубока по набору возможностей. Это достигается именно за счёт непрерывного внедрения новых функций, в том числе из клиентских запросов.

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

    Да программисты ничего не понимают в продажах (бизнесе, складе, бухгалтерии и т.д.)!


    Комментарий разработчика: Понимают или нет программисты в продажах — никак не коррелирует с необходимостью составления ТЗ. Оно составляется для того, чтобы отдел разработки мог выполнить конкретные реализации задач и сдать заказчику готовые механизмы.

    Здесь даже стоит развернуть ответ по пунктам:

    • Программист может участвовать в обсуждении, но составляет ваше ТЗ и будущую архитектуру доработки/логику внедрения инженер/главный разработчик (он может называться и тимлидом, и продакт-менеджером, и продакт-овнером), который прекрасно знает бизнес со стороны клиента — иначе бы просто никто не запроектировал столько функций, не понимая, как они смогут работать внутри бизнес-процессов.

    • Заказчик сам — консультант вендора, и когда он понимает, что хочет, разработчику гораздо легче.

    • Вендор разбирается в бизнесе хотя бы в силу того, что он сам по себе бизнес и работает со своими же продуктами как клиент. Например, у нас в Регионсофт у всех сотрудников стоит RegionSoft CRM — мы её используем по всем сценариям: как инструмент продаж, обзвона, рассылок, багтрекер, журнал корреспонденции, интегрируем с 1С, ставим задачи, планируем, оцениваем KPI и проч. Соответственно, есть чёткое представление о том, как работает средний клиент. Кстати, отличный способ тестирования программы.

    Как правило, компания-разработчик всегда эксперт в той отрасли, для которой она разрабатывает. Без этого можно писать отдельные скрипты и модули, но ни в коем случае не комплексные системы.

    Вы составляете ТЗ за деньги?!


    Комментарий разработчика: Для того, чтобы составить ТЗ, необходимо выполнить определенный объем работ. Это могут сделать только специалисты с достаточно большой квалификацией, которые знают систему изнутри и понимают желания заказчика. Это непростая работа. Порой от продуманного и качественно составленного ТЗ зависит весь успех реализации проекта.

    Конечно, за простенькое ТЗ из двух-трёх пунктов деньги не берутся. А вот за остальное нужно платить как за часть проекта. И тут есть ряд экономических, функциональных и даже психологических причин, о которых стоит рассказать подробнее.

    • Сотрудники, которые составляют ТЗ на стороне разработчика (как правило, это 2 человека и более), тратят на него своё рабочее время, сдвигая другие задачи. Соответственно — это работа.

    • После составления ТЗ клиент может уйти к конкуренту с готовым «подарком» — почему мы должны им оплачивать этот этап работы?

    • ТЗ — это часть интеграционного проекта, и определённые функциональные работы проводятся ещё на этапе его составления.

    • То, что дано бесплатно, не ценится — клиент относится к документу как к необязательной бюрократической формальности. В то время, как это должен быть основной рабочий документ.

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

    Я подразумевал другое!


    Комментарий разработчика: Мысли человека неисповедимы. Сегодня я хочу зеленый чай, а завтра меня потянет на кофе. Если нет ТЗ, то невозможно спрогнозировать, что заказчик подразумевал, когда говорил, например, что «по нажатию на зелененькую кнопочку должна происходить интеграция с 1С». Что это означает? Трактовок может быть масса. Может нужно загрузить оплаты из 1С в CRM? А может выгрузить счета? Или нужно вывести отчет о складских остатках? В ТЗ должна быть однозначность.

    Если вендор идёт на уступки и соглашается работать без технического задания, то он, скорее всего, услышит именно это возражение, когда настанет момент подписывать акт выполненных работ. И возразить, извините за тавтологию, ему будет нечего. Равно как и доказать, что клиент должен платить за переделывание всего, что ему представлено. Но отсутствие ТЗ делает беззащитным не только разработчика, но и самого клиента.

    Обычно после нескольких итераций того, что подразумевал клиент без ТЗ, получается примерно так

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

    Бизнес-аналитики и ТЗ


    Это настолько хрестоматийная и невыносимо ужасная история, что ей обязательно стоит посвятить отдельный блок поста. Моду на бизнес-аналитиков ввёл SAP. И они у SAP по всему миру очень мощные ребята с сильным техническим, финансовым и менеджерским бэкграундом. Саповцы, особенно за границей, отлично знают цену времени, срокам, ТЗ. В России, мне иногда кажется, они переняли только напор в общении, отглаженные костюмы и слова типа митап, колл, фидбэк, фоллоу-ап (пообщайтесь при случае — бизнес-аналитики прикольные ребята!). У нас я встречал бизнес-аналитиков с гуманитарным образованием, с незаконченным высшим и даже без знания основ работы с ПК. Это такие продажники на стероидах. И вот они выступают адвокатами сделки и берутся составлять ТЗ. Тут возможны варианты.

    Всё же готово — берите и делайте! На моей практике есть несколько десятков случаев, когда люди приходили с готовыми большими ТЗ, подготовленными сторонними консалтерами. Однако ни одно из них так и не дошло до реализации. Все грязло в обсуждении этого большого ТЗ. На этом и заканчивалось. В данном случае ТЗ вам пишет совершенно посторонний человек, который знает, как ведёт себя CRM в бизнесе в общем случае (фактически стерильные лабораторные условия), но совершенно не знает, как поведёт себя выбранная вами программа в вашем собственном бизнесе. Или же он составит вам ТЗ таким образом, чтобы под него подошла не та программа, которая вам нужна, а одна из тех, которую ему нужно продать за процент от сделки.

    Вот тут же всё про CRM! Люди приходят опять же от бизнес-аналитиков с готовым ТЗ, которое совершенно не согласовано с нашим ПО и для его реализации нужны огромные деньги, поскольку требуется перепиливать сложные механизмы системы, вместо того, чтобы адаптироваться к системе и дополнить ее недостающими возможностями.

    Тут у нас в 2010 году CRM покупать хотели, ТЗ завалялось. Старое техническое задание — это мёртвое техническое задание. Бизнес-процессы изменились, кураторы проекта уже другие, модернизировалась ИТ-инфраструктура, вырос уровень CRM-систем. 7 лет для бизнеса и ИТ-сферы — это значительное время, равно как год или два, поэтому старое ТЗ попросту не актуально.

    Мы взяли ТЗ у наших партнёров, они недавно внедрили. Очень странный подход. Не бывает двух одинаковых компаний и одинаковых процессов внутри них. К тому же, если было внедрение другой CRM-системы (иного софта), то не может быть и речи о том, чтобы принять это ТЗ в работу — технологии от вендора к вендору сильно отличаются (даже, если системы написаны на одном языке программирования и визуально друг друга напоминают).

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

    Итак, подведём итог рассуждениям.

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

    Техническое задание — первая и важная часть интеграционного или внедренческого проекта. Именно от него зависит, насколько быстро и качественно команда справится с работой, а заказчик получит желаемое ПО, работающее, как часы. За границей появилось много адептов работы без ТЗ, они ратуют за свободу творчества и доверительные отношения, войны разворачиваются вокруг слова «требования» (Product Requirements Document). На самом деле, это холивар ради холивара — работать без технического задания в корпоративной сфере как заказчику, так и вендору невозможно. Нужно уметь договариваться. И поля ТЗ — лучшее место для этого.



    Весь декабрь мы даём скидки на RegionSoft CRM и весь софт собственной разработки. С 1 по 15 декабря — 15% и крутые условия рассрочки и аренды. У нас не бывает -70% и -90%, потому что мы держим экономически обоснованную цену на лицензии, а не берём её с потолка.


    И мы просим тех, кто не прошёл, пройти опрос о CRM, о результатах которого обязательно расскажем перед самым Новым годом — в том числе о механике опроса и своих косяках. Просим вас ответить на вопросы в простенькой форме — их всего 10 плюс 3 для тех, кому интересно узнать о нас больше. Просьба дойти опрос до конца, ненужные вам пункты просто пропустить.

    Пройти опрос тут

    RegionSoft Developer Studio

    88,40

    CRM-система, программное обеспечение для бизнеса

    Поделиться публикацией
    Комментарии 14
      +1
      Пост крутой. Но! Не понимаю, чем же вам чужое ТЗ не угодило — там же требования изложены уже. Возьмите, смотрите только на них — и делов. Почему вы так против?
        +2
        Спасибо. Дело в том, что ТЗ как правило выглядит уже не как свод требований, а как требования, наложенные на решения в конкретной системе, с учётом её архитектуры, сроков разработки, возможностей и т.д. И от вендора к вендору эти возможности сильно отличаются — начиная от механизма развёртывания и заканчивая инструментами разработки.
        Это как книгу по ремонту автомобиля взять от Жигулей и принести владельцу Тойоты — ну это же всё автомобиль: кузов, двигатель, 4 колеса, руль, трансмиссия. Но суть в том, что взаимодействует это всё по-разному, где-то больше тонкостей с электроникой и т.д. Так и в любом софте — ТЗ должно писать именно с учётом программы, которую вы внедряете.
          +2
          Дело в том, что ТЗ как правило выглядит уже не как свод требований, а как требования, наложенные на решения в конкретной системе, с учётом её архитектуры, сроков разработки, возможностей и т.д.
          Если ТЗ писал человек который работал только с 1 системой или-же задача стояла протолкнуть 1 систему то это будет так, в других же случаях описание будет довольно вольным, с чётким описанием требуемых функций, но без явного указания способа их реализации.

          Так-же можно договориться изменить ТЗ с учётом возможностей вашей системы, это делается гораздо быстрее и дешевле чем составлять ТЗ с 0.
            +1
            Если ТЗ больше описывает требования, чем реализацию и ничего «не проталкивает», почему нет? Мы же откроем его и посмотрим с готовностью общаться, а не дадим с размаху от ворот поворот. Но пока такого не встречалось.
        0
        У меня такой-же велосипед получается по ТЗ заказчика, прямо таки копия.
          0
          Вы анализировали причины, почему так вышло: расплывчатые требования, неграмотное ТЗ или всё сразу?
          +3
          Тут у нас в 2010 году CRM покупать хотели, ТЗ завалялось.

          Любимый вариант многих госструктур, неважно о чём идет речь, о ПО, об оборудовании.
          Регулярно выкладывают тендеры на железки снятые с пр-ва 5-6-7-8 лет тому назад.
            –2
            Внедрять CRM без расписаных бизнес процессов, это заранее обрекать клиента на неудачу!
            Тех. задание это выдуманный документ, в большинстве случаев «высосаный из пальца».
            Он никогда не будет отражать действительность.
            Так же необходимо участие специалиста по «системе менеджмента качества» стандарта 9001.

              +1
              А кто вам сказал, что описание бизнес-процессов взаимоисключается с ТЗ? Это не выдуманный документ, это ключевой документ при внедрении — если хотите, дорожная карта. И если его составить грамотно, то он не просто отражает действительность, он и есть действительность. А вот бизнес-процессы иногда описывают бизнес-консультанты ради описания процессов, на большее они просто неспособны, увы(

              Что касается СМК, то поясните для Хабра, с какого масштаба нужен такой специалист и зачем?
              –2
              ТЗ не опирающиеся на бизнес-процессы, это возможность распила средств, путем введения ненужных, порой тупиковых идей, которые изначально не будут использоваться, но позволят увеличить бюджет.
              А вот специалист по CMK может оптимизировать ваше тех задание, согласуя его с реальными бизнес процессами.
              Причем если работа предприятия не оптимизирована по стандарту ISO 9001, то внедрение CRM может не дать ожидаемого эффекта. А порой и усложнить, казалось бы простую работу.
              А вот что бы бизнес процессы соответствовали реальному положению вещей тут просто НЕОБХОДИМ специалист аудитор по СМК. Который будет отвечать за эту оптимизацию.
                +1
                Очень зависит от масштаба компании. Что-то вы не по делу усложняете. Я работал в компании с ISO 9001, так это гигант. И все равно все было проформа, а по сути бардак бардаком. И СМК-шники просыпались только во время очередного подтверждения. Любой адекватный вендор наладит соответствие без лишних помощников. Я понимаю, обидно такое о себе слышать, но такие аудиторы в 90% случаев не нужны абсолютно.
                  +1
                  Да я с вами согласен, видел такое же где сделали стандарт, ISO 9001, а бардак остался, по тому как они изначально его же и оптимизировали :) А нужно было сначала сделать оптимальные бизнес процессы и ре инжениринг. Я просто скомкано все изложил.
                0
                хорошая статья, спасибо! пожалуй все кейсы описаны — нечего добавить

                что есть ТЗ в вашем случае — это формальный документ, который «цементируется» подписями вендора и заказчика? Или это документ, который разработал вендор, а затем с заказчиком обсудили и неформально согласовали?

                  0
                  Спасибо за отзыв!
                  ТЗ в нашем случае, конечно, оформленный и подписанный сторонами документ, со сроками, ценами, подписями. Короче, полноценное приложение к договору — никаких договорённостей и неформальных согласований. Иначе вся работа может пойти насмарку(

                Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                Самое читаемое