Внедрение Crm Без Тз: Дорога В Никуда

Модификация стандартного ПО под требования заказчика – обычное дело, если оно правильно организовано.

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

Что происходит в конце? Обе стороны загоняют себя в яму, которую сами выкопали.

Разработчик не подозревает, что он будет вынужден выполнять объем работ, во много раз больший, чем предполагалось, и рано или поздно он прекратит эту работу, напившись завышенных аппетитов заказчика, которые будут расти в геометрической прогрессии, без формальных ограничений.

.

В такой ситуации застройщик рискует так и не завершить работу, а заказчик – не получить желаемого результата.

На ранних этапах развития компании мы несколько раз посещали эту яму, поэтому представляем вторую часть наших рассказов о технических характеристиках – когда ее там нет.



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

Мы разработчики CRM. Наш РегионСофт CRM — достаточно мощное профессиональное решение для бизнеса.

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

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

Плюс есть еще особенности реализации, например, распределенные офисы, филиалы, настройка телефонии, торгового оборудования и т.д. В частности, для CRM, да и вообще для любого корпоративного ПО, подойдет следующая схема: лицензии + доработки + внедрение.

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

Он может покупать лицензии, заказывать модификации, а все остальное сделает сисадмин.

Или он может купить лицензии и заказать внедрение.

Ну, комбинация всех трех элементов также возможна.

Итак, этапы доработки и внедрения всегда требуют подготовки технического задания, в котором будет пошагово указаны все работы, сроки, цены и другие условия.

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

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

• И так всё понятно – зачем терять время?
• Здесь все просто! Да, я объясню на пальцах.

• Я не знаю, как его составить.

• Почему я должен платить за то, что будет включено в следующий выпуск?
• Вы за деньги пишете ТЗ?!

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

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

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

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

Также устные договоренности впоследствии могут быть легко истолкованы кем угодно как удобно.

А если техзадание объемное и требует длительного периода реализации, кто тогда точно вспомнит, какими именно формулировками пользовались стороны, оговаривая требования к доработке?

Бывает, что мы берем на себя разработку целых модулей или программного решения, дополняющего CRM (как мы это сделали, например, с Геомонитор И РегионСофт Ритейл ).

У клиента есть бизнес, который он хочет автоматизировать.

У него есть набор задач, которые должна решить эта автоматизация: увеличить продажи, оптимизировать процессы, сократить время на рутину, сделать прозрачными транзакции и склад и т. д. Мы понимаем, как работает наше программное обеспечение, а клиент понимает, как функционирует его бизнес.

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

Ошибка многих вендоров в том, что они предлагают решение и не хотят вникать в проблему заказчика.

Ошибка клиента – видеть проблему более масштабной, чем она есть на самом деле, и требовать «все переделать».

Составление технического задания – это тот самый процесс, в ходе которого можно соотнести требования и возможные решения.

При этом чаще всего доработки по техническому заданию будут стоить дешевле за счет того, что программисты не будут тратить на проект бесконечное количество человеко-часов.

Как понять друг друга при работе над техническим заданием?

• Говорить на общепонятном русском (другом) языке.

  Вряд ли каждому клиенту понятны фразы «сделаем резервную копию базы на резервный сервер» или «выкатим обновление в продакшен».

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

• Составьте техническое задание поэтапно: разбейте предстоящие работы на блоки, указав объем и сроки выполнения каждой группы работ.
• Лучше всего, если со стороны заказчика в процессе примет участие техник или человек, знающий процесс до мельчайших этапов.

  При всем уважении, стандартный офисный маркетолог не станет внедрять CRM.

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

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

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

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

Более того, он наверняка это загуглил или ему сказали, что это делается в нескольких десятках строк кода.

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

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

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

Я не знаю, как это составить

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

Это можно сделать в абстрактной форме, а детали обсудить устно.

Но в конечном итоге техническое задание составляется застройщиком исходя из ваших требований и с учетом всех деталей.

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

Верно?

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

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

Техническое задание не обязательно должно быть 100 страниц (хотя иногда и 400, ну это в больших интеграционных проектах), оно может быть пару пунктов, но они должны быть.

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

Ну или наоборот.

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

Комментарий разработчика: Никто заранее не знает, войдет ли заказанная вами модификация в стандартное решение в будущих выпусках.

Это определяется гораздо позже на совете разработчиков при подготовке глобальных обновлений.

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

Это право разработчика и не обсуждается.

Кто видел РегионСофт CRM Присмотревшись, можно заметить, насколько он функционален и глубок в своем спектре возможностей.

Это достигается именно за счет постоянного внедрения новых функций, в том числе по запросам клиентов.

Но вопрос совершенно некорректный - во-первых, не факт, что доработка войдет в релиз.

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

Релиз вашей фичи может произойти через год-полтора, потому что бэклог большой — обычно впереди пара крупных релизов.

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

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

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

Комментарий разработчика : Понимают или нет программисты продаж, это не имеет никакого отношения к необходимости составления технического задания.

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

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

  со стороны клиента очень хорошо — иначе бы просто никто не проектировал столько функций, не понимая, как они могут работать внутри бизнес-процессов.

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

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

Вы за деньги пишете ТЗ?!

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

Это непростая работа.

Иногда от продуманного и грамотно написанного технического задания зависит весь успех проекта.

А вот за остальное нужно платить в рамках проекта.

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

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

  Соответственно, это работа.

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

• То, что дается бесплатно, не ценится – клиент относится к документу как к необязательной бюрократической формальности.

  Пока это должен быть основной рабочий документ.

Но это не значит, что составив техническое задание, вы не можете больше давать никаких комментариев.

Может. Предварительно внеся дополнительные работы в существующие технические условия.

Я имел в виду другое!

Комментарий разработчика: Человеческие мысли непостижимы.

Сегодня я хочу зеленого чая, а завтра мне захочется кофе.

Если нет технического задания, то невозможно предсказать, что имел в виду заказчик, когда говорил, например, что «по нажатию на зеленую кнопочку должна произойти интеграция с 1С».

Что это значит? Трактовок может быть много.

Может быть, вам нужно загрузить платежи из 1С в CRM? Или, может быть, скачать счета? Или вам нужно вывести отчет по складским остаткам? Технические характеристики должны быть однозначными.

А также доказать, что клиент должен платить за переделку всего, что ему преподносят. Но отсутствие технического задания делает беззащитным не только застройщика, но и самого заказчика.

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

Это не обиды и не ссора – это оптимизация работы и бизнеса.

Сам клиент должен быть заинтересован в быстрой реализации проекта – ведь автоматизация бизнеса – это конкурентное преимущество и рабочий инструмент. Чем быстрее вы это получите, тем быстрее вы выйдете на новый уровень организации труда, производительности и, в конечном итоге, рентабельности.

Бизнес-аналитики и технические задания

SAP ввела моду на бизнес-аналитиков.

И это очень влиятельные ребята из SAP по всему миру с сильным техническим, финансовым и управленческим опытом.

Саповцы, особенно заграничные, прекрасно знают цену времени, срокам, техническим заданиям.

В России мне иногда кажется, что переняли только давление в общении, прессинги и слова типа встреча, звонок, обратная связь, продолжение (общайтесь при случае - бизнес-аналитики - классные ребята!).

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

Это продавцы на стероидах.

И вот они выступают юристами сделки и обязуются составить техническое задание.

Здесь возможны варианты.

Всё готово – бери и делай! В моей практике есть несколько десятков случаев, когда люди приходили с готовыми большими спецификациями, подготовленными сторонними консультантами.

Однако ни одно из них так и не было реализовано.

В обсуждении этой большой технической спецификации все было грязно.

Это был конец.

В этом случае техническое задание вам пишет совершенно незнакомый человек, который знает, как ведет себя CRM в бизнесе вообще (фактически стерильные лабораторные условия), но совершенно не знает, как выбранная вами программа поведет себя в вашем собственном бизнесе.

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

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

системы и дополнив ее недостающими возможностями.

Вот в 2010 году у нас хотели купить CRM, технические характеристики валялись.

Старая техническая спецификация — это мертвая техническая спецификация.

Изменились бизнес-процессы, другие кураторы проектов, модернизировалась ИТ-инфраструктура, повысился уровень CRM-систем.

7 лет для бизнеса и ИТ-сферы – это существенный срок, как и год-два, поэтому старое ТЗ просто не актуально.

Мы взяли техническое задание у наших партнёров, они его недавно внедрили.

Очень странный подход. Не бывает двух одинаковых компаний и одинаковых процессов внутри них.

Кроме того, если была внедрена другая CRM-система (другое программное обеспечение), то о принятии данного технического задания в работу не может быть и речи – технологии сильно различаются от вендора к вендору (даже если системы написаны на одном языке программирования и визуально похожи друг на друга).

Наиболее подходящим вариантом является клиент приходит с бизнес-аналитиком .

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

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

Команда разработчиков достаточно профессиональна, чтобы понять ваши требования.

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

• Техническое задание должно быть составлено для любой модификации и любой реализации.

• Над техническими спецификациями всегда работают две стороны.

• Составление технического задания выгодно как заказчику, так и подрядчику.

• Круг ведения не должен быть формальностью или элементом бюрократии.

• Техническое задание — главный инструмент команды программистов.

• Старое, шаблонное, чужое техническое задание никак не поможет вашему проекту.

• Составление технического задания существенно ускоряет сроки сдачи всего проекта.

От него зависит, насколько быстро и качественно команда выполнит работу, а заказчик получит желаемое программное обеспечение, работающее как часы.

За рубежом появилось много приверженцев работы без спецификаций, они ратуют за свободу творчества и доверительные отношения, вокруг слова «требования» (Документ о требованиях к продукту) разворачиваются войны.

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

Вам нужно уметь договариваться.

И поля ТЗ – лучшее место для этого.

С 1 по 15 декабря - 15% и крутые условия рассрочки и аренды.

-70% и -90% у нас нет, потому что мы держим цену на лицензии экономически обоснованной, а не берём её на ровном месте.

Просим вас ответить на вопросы в простой форме – их всего 10 плюс 3 для тех, кому интересно узнать о нас больше.

Пожалуйста, заполните опрос до конца; просто пропустите все, что вам не нужно.

Пройдите опрос здесь Теги: #Управление разработкой #Управление продуктом #ERP-системы #CRM-системы #crm #техническое задание #crm-система #техническое задание на программирование #регионсофт #регионсофт #без спецификации

• Ценность Предложения По Обновлению До Windows 8, Когда Windows 7 Находится В Пике

  19 Oct, 24

• Резервное Копирование Игр Для Xbox 360 — Что Вам Нужно Знать

  19 Oct, 24

• Positive Hack Days: Главное С Конференции По Защите Промышленных Предприятий От Киберугроз

  19 Oct, 24

• Наса: Люди Создали Вокруг Земли Радиококон Из Сверхдлинных Волн, Защищающий От Космического Излучения

  19 Oct, 24

• Очень Странный Тренинг

  19 Oct, 24

• Темная Сторона Программирования Для Начинающих, В Том Числе Php

  19 Oct, 24

• Мой Вариант Замены Вкладок Для Firefox

  19 Oct, 24

• Позиционирование Плагина Jquery

  19 Oct, 24

• Предприятие 2.0: Что Готовит «Им» Наступающий Год?

  19 Oct, 24

• Samsung Galaxy S4 И Htc One Доступны Для Заказа В Google Play

  19 Oct, 24