Первая часть о том, как составлять техническое задание — по ссылке.
Мы — разработчики 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 для тех, кому интересно узнать о нас больше. Просьба дойти опрос до конца, ненужные вам пункты просто пропустить.
Пройти опрос тут
Комментарии (14)
AVI-crak
23.11.2016 15:15У меня такой-же велосипед получается по ТЗ заказчика, прямо таки копия.
RegionSoft
23.11.2016 15:31Вы анализировали причины, почему так вышло: расплывчатые требования, неграмотное ТЗ или всё сразу?
Ugrum
23.11.2016 18:50+3Тут у нас в 2010 году CRM покупать хотели, ТЗ завалялось.
Любимый вариант многих госструктур, неважно о чём идет речь, о ПО, об оборудовании.
Регулярно выкладывают тендеры на железки снятые с пр-ва 5-6-7-8 лет тому назад.
DRDOS
25.11.2016 17:24-2Внедрять CRM без расписаных бизнес процессов, это заранее обрекать клиента на неудачу!
Тех. задание это выдуманный документ, в большинстве случаев «высосаный из пальца».
Он никогда не будет отражать действительность.
Так же необходимо участие специалиста по «системе менеджмента качества» стандарта 9001.
RegionSoft
25.11.2016 17:29+1А кто вам сказал, что описание бизнес-процессов взаимоисключается с ТЗ? Это не выдуманный документ, это ключевой документ при внедрении — если хотите, дорожная карта. И если его составить грамотно, то он не просто отражает действительность, он и есть действительность. А вот бизнес-процессы иногда описывают бизнес-консультанты ради описания процессов, на большее они просто неспособны, увы(
Что касается СМК, то поясните для Хабра, с какого масштаба нужен такой специалист и зачем?
DRDOS
26.11.2016 21:57-2ТЗ не опирающиеся на бизнес-процессы, это возможность распила средств, путем введения ненужных, порой тупиковых идей, которые изначально не будут использоваться, но позволят увеличить бюджет.
А вот специалист по CMK может оптимизировать ваше тех задание, согласуя его с реальными бизнес процессами.
Причем если работа предприятия не оптимизирована по стандарту ISO 9001, то внедрение CRM может не дать ожидаемого эффекта. А порой и усложнить, казалось бы простую работу.
А вот что бы бизнес процессы соответствовали реальному положению вещей тут просто НЕОБХОДИМ специалист аудитор по СМК. Который будет отвечать за эту оптимизацию.Analitik_Telecom
27.11.2016 00:20+1Очень зависит от масштаба компании. Что-то вы не по делу усложняете. Я работал в компании с ISO 9001, так это гигант. И все равно все было проформа, а по сути бардак бардаком. И СМК-шники просыпались только во время очередного подтверждения. Любой адекватный вендор наладит соответствие без лишних помощников. Я понимаю, обидно такое о себе слышать, но такие аудиторы в 90% случаев не нужны абсолютно.
DRDOS
27.11.2016 14:46+1Да я с вами согласен, видел такое же где сделали стандарт, ISO 9001, а бардак остался, по тому как они изначально его же и оптимизировали :) А нужно было сначала сделать оптимальные бизнес процессы и ре инжениринг. Я просто скомкано все изложил.
AlexPepper
28.11.2016 19:25хорошая статья, спасибо! пожалуй все кейсы описаны — нечего добавить
что есть ТЗ в вашем случае — это формальный документ, который «цементируется» подписями вендора и заказчика? Или это документ, который разработал вендор, а затем с заказчиком обсудили и неформально согласовали?
RegionSoft
28.11.2016 19:38Спасибо за отзыв!
ТЗ в нашем случае, конечно, оформленный и подписанный сторонами документ, со сроками, ценами, подписями. Короче, полноценное приложение к договору — никаких договорённостей и неформальных согласований. Иначе вся работа может пойти насмарку(
Vrankevich
Пост крутой. Но! Не понимаю, чем же вам чужое ТЗ не угодило — там же требования изложены уже. Возьмите, смотрите только на них — и делов. Почему вы так против?
RegionSoft
Спасибо. Дело в том, что ТЗ как правило выглядит уже не как свод требований, а как требования, наложенные на решения в конкретной системе, с учётом её архитектуры, сроков разработки, возможностей и т.д. И от вендора к вендору эти возможности сильно отличаются — начиная от механизма развёртывания и заканчивая инструментами разработки.
Это как книгу по ремонту автомобиля взять от Жигулей и принести владельцу Тойоты — ну это же всё автомобиль: кузов, двигатель, 4 колеса, руль, трансмиссия. Но суть в том, что взаимодействует это всё по-разному, где-то больше тонкостей с электроникой и т.д. Так и в любом софте — ТЗ должно писать именно с учётом программы, которую вы внедряете.
Gray_Wolf
Так-же можно договориться изменить ТЗ с учётом возможностей вашей системы, это делается гораздо быстрее и дешевле чем составлять ТЗ с 0.
RegionSoft
Если ТЗ больше описывает требования, чем реализацию и ничего «не проталкивает», почему нет? Мы же откроем его и посмотрим с готовностью общаться, а не дадим с размаху от ворот поворот. Но пока такого не встречалось.