Доработка типового программного обеспечения под требования заказчика — это обыденное дело, если оно правильно организовано. Однако часто можно встретить примеры, когда разработчики берутся выполнить работы без ТЗ (технического задания) по настоянию заказчика. Что происходит в итоге? Обе стороны загоняют себя в яму, которую выкопали сами. Разработчик не подозревает, что он будет вынужден выполнить объем работ во много раз больше предполагаемого, и рано или поздно остановит эти работы, нахлебавшись раздувшихся аппетитов заказчика, которые будут расти в геометрической прогрессии, не имея формальных ограничений. В такой ситуации разработчик рискует никогда не завершить работу, а заказчик — никогда не получить нужного результата. На ранних этапах развития компании мы в этой яме побывали неоднократно, поэтому представляем вторую часть наших историй о ТЗ — когда его нет.
Первая часть о том, как составлять техническое задание — по ссылке.
Мы — разработчики CRM. Наша RegionSoft CRM — довольно мощное профессиональное решение для бизнеса. Система десктопная и нам очень часто достаются клиенты, которым нужен полноценный проект внедрения с заточкой под индивидуальные особенности клиентов. У кого-то это особый цикл продаж, кому-то нужно отслеживать транспорт, третьим необходимы особые отчёты, настройка системы KPI или бизнес-процессов. Плюс, ещё встречаются особенности внедрения, например, распределённые офисы, филиалы, настройка телефонии, торгового оборудования и т.д.
В частности для CRM, а в целом для любого корпоративного программного обеспечения подходит схема: лицензии + доработки + внедрение. Клиент может купить лицензии, установить ПО, самостоятельно взять документацию, разобраться и начать работать. Может купить лицензии, заказать доработку, а остальное сделает сисадмин. А может купить лицензии и заказать внедрение. Ну и связка из всех трёх элементов также возможна. Так вот, этапы доработки и внедрения всегда требуют составления технического задания, в котором будут поэтапно указаны все работы, сроки, цены и прочие условия.
Мы бы не вздыхали и не поднимали проблему работы с ТЗ ещё раз, а пилили бы и пилили код всей командой разработки, если бы не камень преткновения, с которым мы встречаемся очень часто — клиенты не хотят составлять техническое задание на доработку. Не хотят ТЗ, то есть фактически находят верный способ никогда не подписать акт. Вот самые распространённые причины.
Давайте рассмотрим эти вопросы в деталях, потому что одним абзацем списка явно не обойтись.
У нас есть базовое решение — CRM, к ней есть требования по доработке. Бывает, мы берёмся за разработку целых модулей или дополнительного к CRM программного решения (как у нас вышло, например, с GeoMonitor и RegionSoft Retail). У клиента есть бизнес, который он хочет автоматизировать. У него есть набор проблем, которые эта автоматизация должна решить: повысить продажи, упорядочить процессы, сократить время на рутину, сделать прозрачными сделки и склад и т.д. Нам понятно, как работает наш софт, клиенту — как функционирует его бизнес. И когда мы встречаемся, то должны понять друг друга.
Ошибка многих вендоров в том, что они предлагают решение и не хотят вникнуть в проблему заказчика. Ошибка клиента — видеть проблему большей, чем она есть на самом деле и требовать «переделать всё». Составление технического задания — тот самый процесс, в ходе которого удаётся соотнести требования и возможные решения. Более того, чаще всего доработка по ТЗ обойдётся дешевле ввиду того, что программисты не будут тратить бесконечное количество человеко-часов на проект.
Как понять друг друга, работая над ТЗ?
В общем, правило такое: чтобы всем всё было понятно, все фичи, подлежащие доработке, должны быть проговорены устно и формализованы на бумаге.
Заказчику кажется, что изменить цикл продаж, создать один отчёт или прикрутить диаграмму Ганта — просто. Более того, наверняка он погуглил или ему рассказали, что это делается в несколько десятков строк кода. Да, сам код перечисленных сущностей опытным программистам по плечу, но заказчик не догадывается о том, что всё это нужно встроить в архитектуру основной программы и ради «ну там небольшой доработочки» придётся основательно менять логику какого-либо модуля или системы.
Поэтому важно внимательно изучить базовую функциональность программы, сопоставить её с потребностями бизнеса и понять, чего действительно не хватает. Сделать это просто: ставите основным пользователям демо-версию и работаете в системе несколько дней, фиксируя в отдельном документе, чего не хватает вашей команде. Затем в списке нужно расставить приоритеты, исключить пересечения подразделений, ещё раз сформировать документ и обратиться с этим списком к вендору, который совместно с заказчиком приступит к составлению ТЗ.
Получается, главное — донести требования. ТЗ — это рабочий документ для того, чтобы понять назначение, цели и видение продукта. По нему будет подписываться акт, по нему же будут вести разработку программисты из команды вендора. Для них это — инструкция, согласно которой они продвигаются в разработке. ТЗ — совсем не обязательно 100 страниц (хотя бывает и 400, ну это в крупных интеграционных проектах), это может быть и пара пунктов, но они обязательно должны быть. Клиент, в свою очередь, сможет принять работы, сверяясь с техническим заданием — и в случае коллизий показать разработчику на то, что сделано не так. Ну или наоборот.
У нас есть такая практика — лучшие решения и доработки мы вводим в релиз. Кто видел RegionSoft CRM поближе, могли заметить, насколько она функциональна и глубока по набору возможностей. Это достигается именно за счёт непрерывного внедрения новых функций, в том числе из клиентских запросов.
Но вопрос совершенно некорректен — во-первых, не факт, что доработка войдёт в релиз. Во-вторых, вам она нужна сейчас, вы её инвестор и она будет реализована для вас в кратчайшие сроки, протестирована на ваших данных и внедрена вам. Релиз же именно с вашей фичей может случиться через год-полтора, потому что беклог большой — обычно на пару мажорных релизов вперёд. Причём все задачи из беклога в обязательном порядке обсуждаются внутри команды на предмет актуальности и необходимости внесения функциональности в релиз. Наконец, даже если крутая доработка попадает в новый релиз, она глубоко рефакторится, подвергается универсализации и, вполне возможно, будет значительно отличаться от Вашей реализации.
Здесь даже стоит развернуть ответ по пунктам:
Как правило, компания-разработчик всегда эксперт в той отрасли, для которой она разрабатывает. Без этого можно писать отдельные скрипты и модули, но ни в коем случае не комплексные системы.
Конечно, за простенькое ТЗ из двух-трёх пунктов деньги не берутся. А вот за остальное нужно платить как за часть проекта. И тут есть ряд экономических, функциональных и даже психологических причин, о которых стоит рассказать подробнее.
Кстати, «инвестирование» в ТЗ чаще всего приводит к гораздо большей, чем его стоимость, экономии: вы платите только за точные, обоснованные доработки. Но это не значит, что составив ТЗ, нельзя больше внести ни одного замечания. Можно. Внеся предварительно дополнительные работы в существующее техническое задание.
Если вендор идёт на уступки и соглашается работать без технического задания, то он, скорее всего, услышит именно это возражение, когда настанет момент подписывать акт выполненных работ. И возразить, извините за тавтологию, ему будет нечего. Равно как и доказать, что клиент должен платить за переделывание всего, что ему представлено. Но отсутствие ТЗ делает беззащитным не только разработчика, но и самого клиента.
Обычно после нескольких итераций того, что подразумевал клиент без ТЗ, получается примерно так
Формулируя задачи и меняя их на лету без документа в основании, заказчик фактически подписывается на бесконечный проект. Из-за высокой неопределённости команда вендора не будет видеть конца и края исполнению всех требований и сотни оговорок к ним, а значит, постепенно начнёт откладывать доработку и внедрение в пользу более чётко обозначенных задач. Это не обиды и не ссора — это оптимизация труда и бизнес. Сам же клиент должен быть заинтересован в быстрой реализации проекта — поскольку автоматизация бизнеса это конкурентное преимущество и это рабочий инструмент. Чем быстрее вы его получите — тем быстрее вы выйдете на новый уровень организации труда, производительности и, в конечном итоге, доходности.
Это настолько хрестоматийная и невыносимо ужасная история, что ей обязательно стоит посвятить отдельный блок поста. Моду на бизнес-аналитиков ввёл SAP. И они у SAP по всему миру очень мощные ребята с сильным техническим, финансовым и менеджерским бэкграундом. Саповцы, особенно за границей, отлично знают цену времени, срокам, ТЗ. В России, мне иногда кажется, они переняли только напор в общении, отглаженные костюмы и слова типа митап, колл, фидбэк, фоллоу-ап (пообщайтесь при случае — бизнес-аналитики прикольные ребята!). У нас я встречал бизнес-аналитиков с гуманитарным образованием, с незаконченным высшим и даже без знания основ работы с ПК. Это такие продажники на стероидах. И вот они выступают адвокатами сделки и берутся составлять ТЗ. Тут возможны варианты.
Всё же готово — берите и делайте! На моей практике есть несколько десятков случаев, когда люди приходили с готовыми большими ТЗ, подготовленными сторонними консалтерами. Однако ни одно из них так и не дошло до реализации. Все грязло в обсуждении этого большого ТЗ. На этом и заканчивалось. В данном случае ТЗ вам пишет совершенно посторонний человек, который знает, как ведёт себя CRM в бизнесе в общем случае (фактически стерильные лабораторные условия), но совершенно не знает, как поведёт себя выбранная вами программа в вашем собственном бизнесе. Или же он составит вам ТЗ таким образом, чтобы под него подошла не та программа, которая вам нужна, а одна из тех, которую ему нужно продать за процент от сделки.
Вот тут же всё про CRM! Люди приходят опять же от бизнес-аналитиков с готовым ТЗ, которое совершенно не согласовано с нашим ПО и для его реализации нужны огромные деньги, поскольку требуется перепиливать сложные механизмы системы, вместо того, чтобы адаптироваться к системе и дополнить ее недостающими возможностями.
Тут у нас в 2010 году CRM покупать хотели, ТЗ завалялось. Старое техническое задание — это мёртвое техническое задание. Бизнес-процессы изменились, кураторы проекта уже другие, модернизировалась ИТ-инфраструктура, вырос уровень CRM-систем. 7 лет для бизнеса и ИТ-сферы — это значительное время, равно как год или два, поэтому старое ТЗ попросту не актуально.
Мы взяли ТЗ у наших партнёров, они недавно внедрили. Очень странный подход. Не бывает двух одинаковых компаний и одинаковых процессов внутри них. К тому же, если было внедрение другой CRM-системы (иного софта), то не может быть и речи о том, чтобы принять это ТЗ в работу — технологии от вендора к вендору сильно отличаются (даже, если системы написаны на одном языке программирования и визуально друг друга напоминают).
Самый адекватный вариант — клиент приходит с бизнес-аналитиком. Тут хотя бы можнопосмотреть ему в глаза оценить его уровень и приступить к обсуждению, просто с участием ещё одного лишнего человека. Но по опыту, толку от бизнес-аналитика очень мало — он либо будет вас сманивать на ту (те) программу, которая ему приплачивает, либо окажется третьим лишним и платным в отношениях между вами и вендором. Команда разработчика достаточно профессиональна, чтобы понять ваши требования.
Итак, подведём итог рассуждениям.
Техническое задание — первая и важная часть интеграционного или внедренческого проекта. Именно от него зависит, насколько быстро и качественно команда справится с работой, а заказчик получит желаемое ПО, работающее, как часы. За границей появилось много адептов работы без ТЗ, они ратуют за свободу творчества и доверительные отношения, войны разворачиваются вокруг слова «требования» (Product Requirements Document). На самом деле, это холивар ради холивара — работать без технического задания в корпоративной сфере как заказчику, так и вендору невозможно. Нужно уметь договариваться. И поля ТЗ — лучшее место для этого.
Весь декабрь мы даём скидки на RegionSoft CRM и весь софт собственной разработки. С 1 по 15 декабря — 15% и крутые условия рассрочки и аренды. У нас не бывает -70% и -90%, потому что мы держим экономически обоснованную цену на лицензии, а не берём её с потолка.
И мы просим тех, кто не прошёл, пройти опрос о CRM, о результатах которого обязательно расскажем перед самым Новым годом — в том числе о механике опроса и своих косяках. Просим вас ответить на вопросы в простенькой форме — их всего 10 плюс 3 для тех, кому интересно узнать о нас больше. Просьба дойти опрос до конца, ненужные вам пункты просто пропустить.
Пройти опрос тут
Первая часть о том, как составлять техническое задание — по ссылке.
Мы — разработчики CRM. Наша RegionSoft CRM — довольно мощное профессиональное решение для бизнеса. Система десктопная и нам очень часто достаются клиенты, которым нужен полноценный проект внедрения с заточкой под индивидуальные особенности клиентов. У кого-то это особый цикл продаж, кому-то нужно отслеживать транспорт, третьим необходимы особые отчёты, настройка системы KPI или бизнес-процессов. Плюс, ещё встречаются особенности внедрения, например, распределённые офисы, филиалы, настройка телефонии, торгового оборудования и т.д.
В частности для CRM, а в целом для любого корпоративного программного обеспечения подходит схема: лицензии + доработки + внедрение. Клиент может купить лицензии, установить ПО, самостоятельно взять документацию, разобраться и начать работать. Может купить лицензии, заказать доработку, а остальное сделает сисадмин. А может купить лицензии и заказать внедрение. Ну и связка из всех трёх элементов также возможна. Так вот, этапы доработки и внедрения всегда требуют составления технического задания, в котором будут поэтапно указаны все работы, сроки, цены и прочие условия.
Мы бы не вздыхали и не поднимали проблему работы с ТЗ ещё раз, а пилили бы и пилили код всей командой разработки, если бы не камень преткновения, с которым мы встречаемся очень часто — клиенты не хотят составлять техническое задание на доработку. Не хотят ТЗ, то есть фактически находят верный способ никогда не подписать акт. Вот самые распространённые причины.
- И так всё понятно — зачем тратить время?
- Здесь всё просто! Да я на пальцах объясню.
- Я не умею его составлять.
- Почему я должен платить за то, что войдёт в следующий релиз?
- Вы составляете ТЗ за деньги?!
Давайте рассмотрим эти вопросы в деталях, потому что одним абзацем списка явно не обойтись.
ТОП-6 фраз клиентов — верный способ разозлить разработчика
И так всё понятно — зачем тратить время?
Комментарий разработчика: Чтобы определить четкие задачи и цели, формализовав их на бумаге. Ведь то, что оговаривается устно, нельзя использовать в качестве прямого указания к действию. Также, устные договоренности впоследствии легко трактовать кому как удобно. А если ТЗ объемное и требует длительного срока реализации, кто потом будет вспоминать о том, какие именно формулировки использовали стороны, когда оговаривали требования к доработке?
Комментарий разработчика: Чтобы определить четкие задачи и цели, формализовав их на бумаге. Ведь то, что оговаривается устно, нельзя использовать в качестве прямого указания к действию. Также, устные договоренности впоследствии легко трактовать кому как удобно. А если ТЗ объемное и требует длительного срока реализации, кто потом будет вспоминать о том, какие именно формулировки использовали стороны, когда оговаривали требования к доработке?У нас есть базовое решение — CRM, к ней есть требования по доработке. Бывает, мы берёмся за разработку целых модулей или дополнительного к CRM программного решения (как у нас вышло, например, с GeoMonitor и RegionSoft Retail). У клиента есть бизнес, который он хочет автоматизировать. У него есть набор проблем, которые эта автоматизация должна решить: повысить продажи, упорядочить процессы, сократить время на рутину, сделать прозрачными сделки и склад и т.д. Нам понятно, как работает наш софт, клиенту — как функционирует его бизнес. И когда мы встречаемся, то должны понять друг друга.
Ошибка многих вендоров в том, что они предлагают решение и не хотят вникнуть в проблему заказчика. Ошибка клиента — видеть проблему большей, чем она есть на самом деле и требовать «переделать всё». Составление технического задания — тот самый процесс, в ходе которого удаётся соотнести требования и возможные решения. Более того, чаще всего доработка по ТЗ обойдётся дешевле ввиду того, что программисты не будут тратить бесконечное количество человеко-часов на проект.
Как понять друг друга, работая над ТЗ?
- Говорить на общепонятном русском (другом) языке. Вряд ли каждый клиент поймёт фразы «бэкапить базу на резервный сервер» или «накатим апдейт на продакшене». Нужно выслушать обе стороны: рассказ вендора о возможностях софта, рассказ клиента о нуждах бизнеса, задать вопросы и приступить к составлению ТЗ именно по тем фичам, которые реально нуждаются в доработке.
- Делать техническое задание поэтапным: разделить предстоящие работы на блоки с указанием суммы и сроков по каждой из групп работ.
- Лучше всего, если от заказчика в процессе будет принимать участие технарь или человек, знающий процесс до самой мелкой вехи. При всём уважении, стандартный офисный маркетолог CRM не внедрит.
В общем, правило такое: чтобы всем всё было понятно, все фичи, подлежащие доработке, должны быть проговорены устно и формализованы на бумаге.
Здесь всё просто! Да я на пальцах объясню
Заказчику кажется, что изменить цикл продаж, создать один отчёт или прикрутить диаграмму Ганта — просто. Более того, наверняка он погуглил или ему рассказали, что это делается в несколько десятков строк кода. Да, сам код перечисленных сущностей опытным программистам по плечу, но заказчик не догадывается о том, что всё это нужно встроить в архитектуру основной программы и ради «ну там небольшой доработочки» придётся основательно менять логику какого-либо модуля или системы.
Поэтому важно внимательно изучить базовую функциональность программы, сопоставить её с потребностями бизнеса и понять, чего действительно не хватает. Сделать это просто: ставите основным пользователям демо-версию и работаете в системе несколько дней, фиксируя в отдельном документе, чего не хватает вашей команде. Затем в списке нужно расставить приоритеты, исключить пересечения подразделений, ещё раз сформировать документ и обратиться с этим списком к вендору, который совместно с заказчиком приступит к составлению ТЗ.
Я не умею его составлять
Получается, главное — донести требования. ТЗ — это рабочий документ для того, чтобы понять назначение, цели и видение продукта. По нему будет подписываться акт, по нему же будут вести разработку программисты из команды вендора. Для них это — инструкция, согласно которой они продвигаются в разработке. ТЗ — совсем не обязательно 100 страниц (хотя бывает и 400, ну это в крупных интеграционных проектах), это может быть и пара пунктов, но они обязательно должны быть. Клиент, в свою очередь, сможет принять работы, сверяясь с техническим заданием — и в случае коллизий показать разработчику на то, что сделано не так. Ну или наоборот.
Почему я должен платить за то, что войдёт в следующий релиз?
У нас есть такая практика — лучшие решения и доработки мы вводим в релиз. Кто видел RegionSoft CRM поближе, могли заметить, насколько она функциональна и глубока по набору возможностей. Это достигается именно за счёт непрерывного внедрения новых функций, в том числе из клиентских запросов.
Но вопрос совершенно некорректен — во-первых, не факт, что доработка войдёт в релиз. Во-вторых, вам она нужна сейчас, вы её инвестор и она будет реализована для вас в кратчайшие сроки, протестирована на ваших данных и внедрена вам. Релиз же именно с вашей фичей может случиться через год-полтора, потому что беклог большой — обычно на пару мажорных релизов вперёд. Причём все задачи из беклога в обязательном порядке обсуждаются внутри команды на предмет актуальности и необходимости внесения функциональности в релиз. Наконец, даже если крутая доработка попадает в новый релиз, она глубоко рефакторится, подвергается универсализации и, вполне возможно, будет значительно отличаться от Вашей реализации.
Да программисты ничего не понимают в продажах (бизнесе, складе, бухгалтерии и т.д.)!
Здесь даже стоит развернуть ответ по пунктам:
- Программист может участвовать в обсуждении, но составляет ваше ТЗ и будущую архитектуру доработки/логику внедрения инженер/главный разработчик (он может называться и тимлидом, и продакт-менеджером, и продакт-овнером), который прекрасно знает бизнес со стороны клиента — иначе бы просто никто не запроектировал столько функций, не понимая, как они смогут работать внутри бизнес-процессов.
- Заказчик сам — консультант вендора, и когда он понимает, что хочет, разработчику гораздо легче.
- Вендор разбирается в бизнесе хотя бы в силу того, что он сам по себе бизнес и работает со своими же продуктами как клиент. Например, у нас в Регионсофт у всех сотрудников стоит RegionSoft CRM — мы её используем по всем сценариям: как инструмент продаж, обзвона, рассылок, багтрекер, журнал корреспонденции, интегрируем с 1С, ставим задачи, планируем, оцениваем KPI и проч. Соответственно, есть чёткое представление о том, как работает средний клиент. Кстати, отличный способ тестирования программы.
Как правило, компания-разработчик всегда эксперт в той отрасли, для которой она разрабатывает. Без этого можно писать отдельные скрипты и модули, но ни в коем случае не комплексные системы.
Вы составляете ТЗ за деньги?!
Конечно, за простенькое ТЗ из двух-трёх пунктов деньги не берутся. А вот за остальное нужно платить как за часть проекта. И тут есть ряд экономических, функциональных и даже психологических причин, о которых стоит рассказать подробнее.
- Сотрудники, которые составляют ТЗ на стороне разработчика (как правило, это 2 человека и более), тратят на него своё рабочее время, сдвигая другие задачи. Соответственно — это работа.
- После составления ТЗ клиент может уйти к конкуренту с готовым «подарком» — почему мы должны им оплачивать этот этап работы?
- ТЗ — это часть интеграционного проекта, и определённые функциональные работы проводятся ещё на этапе его составления.
- То, что дано бесплатно, не ценится — клиент относится к документу как к необязательной бюрократической формальности. В то время, как это должен быть основной рабочий документ.
Кстати, «инвестирование» в ТЗ чаще всего приводит к гораздо большей, чем его стоимость, экономии: вы платите только за точные, обоснованные доработки. Но это не значит, что составив ТЗ, нельзя больше внести ни одного замечания. Можно. Внеся предварительно дополнительные работы в существующее техническое задание.
Я подразумевал другое!
Если вендор идёт на уступки и соглашается работать без технического задания, то он, скорее всего, услышит именно это возражение, когда настанет момент подписывать акт выполненных работ. И возразить, извините за тавтологию, ему будет нечего. Равно как и доказать, что клиент должен платить за переделывание всего, что ему представлено. Но отсутствие ТЗ делает беззащитным не только разработчика, но и самого клиента.
Обычно после нескольких итераций того, что подразумевал клиент без ТЗ, получается примерно так
Формулируя задачи и меняя их на лету без документа в основании, заказчик фактически подписывается на бесконечный проект. Из-за высокой неопределённости команда вендора не будет видеть конца и края исполнению всех требований и сотни оговорок к ним, а значит, постепенно начнёт откладывать доработку и внедрение в пользу более чётко обозначенных задач. Это не обиды и не ссора — это оптимизация труда и бизнес. Сам же клиент должен быть заинтересован в быстрой реализации проекта — поскольку автоматизация бизнеса это конкурентное преимущество и это рабочий инструмент. Чем быстрее вы его получите — тем быстрее вы выйдете на новый уровень организации труда, производительности и, в конечном итоге, доходности.
Бизнес-аналитики и ТЗ
Это настолько хрестоматийная и невыносимо ужасная история, что ей обязательно стоит посвятить отдельный блок поста. Моду на бизнес-аналитиков ввёл SAP. И они у SAP по всему миру очень мощные ребята с сильным техническим, финансовым и менеджерским бэкграундом. Саповцы, особенно за границей, отлично знают цену времени, срокам, ТЗ. В России, мне иногда кажется, они переняли только напор в общении, отглаженные костюмы и слова типа митап, колл, фидбэк, фоллоу-ап (пообщайтесь при случае — бизнес-аналитики прикольные ребята!). У нас я встречал бизнес-аналитиков с гуманитарным образованием, с незаконченным высшим и даже без знания основ работы с ПК. Это такие продажники на стероидах. И вот они выступают адвокатами сделки и берутся составлять ТЗ. Тут возможны варианты.
Всё же готово — берите и делайте! На моей практике есть несколько десятков случаев, когда люди приходили с готовыми большими ТЗ, подготовленными сторонними консалтерами. Однако ни одно из них так и не дошло до реализации. Все грязло в обсуждении этого большого ТЗ. На этом и заканчивалось. В данном случае ТЗ вам пишет совершенно посторонний человек, который знает, как ведёт себя CRM в бизнесе в общем случае (фактически стерильные лабораторные условия), но совершенно не знает, как поведёт себя выбранная вами программа в вашем собственном бизнесе. Или же он составит вам ТЗ таким образом, чтобы под него подошла не та программа, которая вам нужна, а одна из тех, которую ему нужно продать за процент от сделки.
Вот тут же всё про CRM! Люди приходят опять же от бизнес-аналитиков с готовым ТЗ, которое совершенно не согласовано с нашим ПО и для его реализации нужны огромные деньги, поскольку требуется перепиливать сложные механизмы системы, вместо того, чтобы адаптироваться к системе и дополнить ее недостающими возможностями.
Тут у нас в 2010 году CRM покупать хотели, ТЗ завалялось. Старое техническое задание — это мёртвое техническое задание. Бизнес-процессы изменились, кураторы проекта уже другие, модернизировалась ИТ-инфраструктура, вырос уровень CRM-систем. 7 лет для бизнеса и ИТ-сферы — это значительное время, равно как год или два, поэтому старое ТЗ попросту не актуально.
Мы взяли ТЗ у наших партнёров, они недавно внедрили. Очень странный подход. Не бывает двух одинаковых компаний и одинаковых процессов внутри них. К тому же, если было внедрение другой CRM-системы (иного софта), то не может быть и речи о том, чтобы принять это ТЗ в работу — технологии от вендора к вендору сильно отличаются (даже, если системы написаны на одном языке программирования и визуально друг друга напоминают).
Самый адекватный вариант — клиент приходит с бизнес-аналитиком. Тут хотя бы можно
Итак, подведём итог рассуждениям.
- Техническое задание должно составляться на любую доработку и любое внедрение.
- Над техническим заданием всегда работают две стороны.
- Составлять ТЗ выгодно и заказчику, и подрядчику.
- Техническое задание не должно быть формальностью или элементом бюрократии.
- ТЗ — основной инструмент команды программистов.
- Старые, шаблонные, чужие ТЗ ничем не помогут вашему проекту.
- Составление ТЗ значительно ускоряет сроки сдачи всего проекта.
Техническое задание — первая и важная часть интеграционного или внедренческого проекта. Именно от него зависит, насколько быстро и качественно команда справится с работой, а заказчик получит желаемое ПО, работающее, как часы. За границей появилось много адептов работы без ТЗ, они ратуют за свободу творчества и доверительные отношения, войны разворачиваются вокруг слова «требования» (Product Requirements Document). На самом деле, это холивар ради холивара — работать без технического задания в корпоративной сфере как заказчику, так и вендору невозможно. Нужно уметь договариваться. И поля ТЗ — лучшее место для этого.
Весь декабрь мы даём скидки на RegionSoft CRM и весь софт собственной разработки. С 1 по 15 декабря — 15% и крутые условия рассрочки и аренды. У нас не бывает -70% и -90%, потому что мы держим экономически обоснованную цену на лицензии, а не берём её с потолка.
И мы просим тех, кто не прошёл, пройти опрос о CRM, о результатах которого обязательно расскажем перед самым Новым годом — в том числе о механике опроса и своих косяках. Просим вас ответить на вопросы в простенькой форме — их всего 10 плюс 3 для тех, кому интересно узнать о нас больше. Просьба дойти опрос до конца, ненужные вам пункты просто пропустить.
Пройти опрос тут
