Почему «без ТЗ результат ХЗ». Разбираем на примере CRM-систем
К нам пришел клиент, который уже пробовал внедрять CRM-систему, и принес наработки предыдущих интеграторов. У него была вроде бы работающая система, но никто ей не пользовался. В статье разберемся, почему так получается, и как делать так, чтобы такого не было.
К нам пришла компания с внедренной CRM-системой. Компания клиента давно существует на рынке. Несмотря на то, что ее процессы не описаны «на бумаге» — они работают довольно хорошо, но не системно.
Предыдущий интегратор никак не проработал его процессы. Они отрисовали процессы на верхнем уровне. Условно вот пришел лид: он либо успешен либо нет, если успешен, то вот продажу заводим. Cказали, что детальнее разберемся «по пути».
Кроме верхнеуровневой схемы процессов клиенту не сделали никакого ТЗ. По BPMN этот уровень называется согласовательным, ниже развернем, какие еще бывают.
Внутренности статьи
Как обычно заказывают внедрение системы
Часто клиенты не могут описать задачу так, чтобы её можно было сразу оценить. В компании может есть свой бизнес-аналитик, но не всегда даже он может сформулировать задачи интеграторам.
Дефолтный интегратор обычно проводит оценку по ощущениям в формате: три бизнес-процесса + пару интеграций, ну дальше погружаться не буду. Получается дешевая оценка на до конца не понятный по масштабу проект.
Клиент со своей стороны хочет быстрее получить КП, чтобы показать руководству свою эффективность.
Поэтому закидывает запросы сразу куче интеграторов и ждет ответа от всех — чтобы сделать анализ. А если клиенту говорят, что для нормальной оценки надо ТЗ, то он говорит, что нет на это времени.
Сотруднику, который занимается сбором предложений, нельзя ошибиться перед своим руководством, но они не могут объяснить, зачем нужно ТЗ, и просят простую поверхностную оценку, а сверху просто закладывают бОльший бюджет на ошибки (в лучшем случае).
Интеграторы, чтобы не терять клиентов делают предложение наобум, лишь бы вписаться в проект и заработать денег.
В итоге они начинают делать проект вместе. Но в моменте, когда часы запланированные на проект уже закончились, не реализована еще даже половина проекта. Просто потому что оценка была «на отвали».
Прежде чем выбирать по цене — нужно понять, как интегратор делал оценку. Как минимум вы потеряете время, как максимум —деньги.
Иногда разработчики предлагают работать без оценки, по часам. Еще это называют Time&Material. Работает это так: есть согласованная ставка — прилетает задача — делаем — сколько потратили, столько потратили.
Это нормальная практика, но не все умеют ей пользоваться. Такой подход полезен, когда в проекте есть постоянная коммуникация и настрой на создание лучшей версии системы. Обсуждение всех деталей помогает создать проект, который будет эффективно решать задачи компании и иметь перспективу для дальнейшего развития.
Почему интеграторы делают то, что не поможет клиенту
Проблема в том, что на нашем рынке много кто решает задачи на «пофиг». Например, крупный производственный холдинг приходит ставить себе CRM, чтобы управлять закупками. А на самом деле для этого нужна SRM.
Часто интеграторы не пытаются узнать, зачем клиент хочет сделать ту или иную задачу: что решает проект, как он повлияет на финансы компании?
Большинство подрядчиков работают лишь бы сдать проект и не задумываются о бизнес-целях клиента. По честному — они просто хотят заработать денег.
Разберем типовые проблемы, которые возникают из-за отсутствия ТЗ.
Проблема № 1 — Недополученная прибыль
Когда бизнес работает давно, и ему нужно внедрить систему — нет права на ошибку. Пару лет назад мы делали CRM, и параллельно клиент у себя делал систему учета (ERP). Но из-за того, что процессы не были формализованы, не получилось их оцифровать.
Когда запустили ERP-систему — она заблокировала работу из-за отсутствия нужных сценариев. Отгрузки встали.
Запуск проектов внедрения без ТЗ — это удел стартапов. В стабильном устоявшемся бизнесе — это способ потерять деньги.
Проблема № 2 — Бесконечный цикл внедрения
Это очень опасно, как для клиента, так и для интегратора. Расскажем на нашем примере проекта по фиксированной стоимости.
В начале проекта написали короткое описание проекта и договорились с клиентом, что будем уточнять детали на последующих итерациях. Но требования сильно корректировались в процессе, к тому же один из участников фокус группы сам придумывал новые кейсы на каждой итерации, чтобы доказать, что проект нежизнеспособен.
Проект растянулся на 2 года по времени и ушел в бесконечный цикл правок. По итогу мы поняли, что мы накосячили с тем, что не прописали четкое ТЗ в самом начале, и решили прекратить работу по проекту.
4 млн рублей
Проблема № 3 — Ожидания ≠ результат
Заказчик отдает задачу в работу → мы делаем, и потом ожидания не сходятся. В такой порочный круг попадает много компаний.
С одной стороны — клиент в постоянной «запаре» и не может четко понять, что именно ему нужно сделать. С другой — интегратор, который делает все четко по словам клиента и не понимает, почему каждый раз приходится все переделывать.
Чтобы этого не допускать нужно помогать клиенту в формализации его задач и четко прописывать их в ТЗ. В потоке операционных задач не все могут посмотреть на процессы со стороны и понять главные цели и требования.
ТЗ — защищает интересы интегратора при работе и поддерживает его маржинальность. Но не надо упираться в этот документ при любом разногласии с клиентом. Нужно балансировать между ТЗ и хорошими взаимоотношениями.
Например, если доработка занимает 1 час времени — то не нужно ругаться из-за этого с клиентом. И уж тем более выставлять доп.счета — лучше преподнесите это, как бонус.
Главная задача ТЗ — сформулировать у клиента четкое понимание того, что он получит в конечном итоге.
Требования могут менять и это нормально, ведь бизнес — это живой организм. Но ТЗ должно покрывать хотя бы 80-90% кейсов, а все изменения нужно документировать, чтобы потом не потеряться.
Проблема № 4 — Непонятная стоимость проекта
Когда не зафиксированы требования — стоимость проекта может расти бесконечно. Чем четче вы представляете конечный результат, тем меньше денег вы потратите и быстрее к нему придете.
Тут отлично подходит аналогия с ремонтом по дизайн-проекту. Когда вы делаете ремонт сами, то должны быть готовы к большому перерасходу, так как строители не смогут сказать вам точную смету на старте.
Чтобы этого избежать делают дизайн-проекты и описывают все схемы прокладки электрики, сантехники и материалов. Это помогает точнее предсказать объем работ и материалов для вашего проекта. Такая аналогия из мира стройки подходит и для всех остальных крупных проектов.
Но проблем достаточно, давайте разберемся, как их избежать.
Этап № 0. Бизнес-цели
Это самый важный этап, именно от него зависит то, куда пойдет проект. Тут мы проводим встречи с топ-менеджерами, чтобы узнать глобальные задачи, который ставят перед системой.
Сначала определяем, что хотим получить на выходе и как это коррелируется со стратегией компании. Делаем так, чтобы это не было внедрением ради внедрения. Очень важно проработать ожидания на этом этапе, так как именно от них зависит будет ли итоговый проект считаться успешным или нет.
Пример хорошей бизнес цели. Компания достаточно большая (серьезный игрок на рынке), ей нужно вырасти в 3-5 раз за следующие 5 лет.
Для этого нужно запустить новые продукты и новые процессы под них. Внутри у нее стоит простая CRM — она не сможет поддержать эти изменения и обеспечить адекватное управление на таких масштабах. Чтобы покрыть новые продукты и их процессы — нужно перейти на новую более функциональную систему.
Важно сделать изменения в первый год, чтобы в оставшиеся 4 года обеспечивать этот рост. А возможно после первого года приоритеты изменятся и задачи поменяются.
Кстати, для наших клиентов мы бесплатно проводим встречи для определения бизнес-целей. Можно забронировать такую встречу по ссылке.
Этап № 1. Сроки и бюджеты
Возвращаясь к нашему примеру — сроки мы уже определили (1 год).
На задачу нужен бюджет. Он формируется из того, что потенциальный рост даст нам дополнительные N млн выручки, и примерно треть мы готовы потратить на этот рост.
Бюджет на интеграцию новой системы стоит считать исходя из ее потенциальной пользы, а не из того, какие сейчас есть ресурсы при текущих процессах.
Представим, что наш потенциал роста — 15 млн. Значит бюджет проекта может составить 5 млн. Но вообще, ваши финансисты подскажут подробнее.
Этап № 2. Требования
Далее идут функциональные требования связанные с ожиданиями от системы: интеграция с телефонией, построение авто-воронок и тд. Все то, что система должна уметь. Требования должны быть приоритезированы — это важно, чтобы правильно сравнивать системы на этапе подбора.
Пример функциональных требований:
- система должна прогнозировать продажи на основании текущих данных из воронки
- у системы должен быть портал самообслуживания для клиентов
- система должна поддерживать возможность работы нескольких менеджеров с одним контрагентом (несколько ответственных)
- система должна поддерживать контроль выполнения плановых показателей на каждом этапе воронки: количество звонков, количество КП, количество продаж
Нефункциональные требования — это те требования, которые не отражает прямой функционал системы. Например:
- Поддержка системы 24/7;
- Коробочное или облачное решение;
- Брендированный корпоративный портал;
- Минимальная скорость интернета для работы системы.
Этап № 3. Ролевые модели, объекты системы и данные
Ролевая модель — это описание набора ролей сотрудников, которая описывает набор полномочий пользователей или групп. Каждый сотрудник может иметь одну или несколько ролей, а каждая роль может содержать от одного до множества полномочий, которые разрешены пользователю в рамках этой роли.
Роль — активно действующая в системе абстрактная сущность, с которой связан ограниченный, логически связанный набор полномочий, необходимых для осуществления определенной деятельности.
При использовании ролевой политики управление доступом осуществляется в две стадии:
- Для каждой роли указывается набор полномочий, представляющий набор прав доступа к объекту.
- Каждому пользователю назначается список доступных ему ролей.
Ролевая модель — описание полномочий сотрудников в системе. Это важно прописать в ТЗ, чтобы заранее понимать функционал пользователей системы и количество уровней доступа.
Описание объектов системы — информация о том, какие поля должны быть в объектах системы, какого они должны быть типа, какой должен быть набор значений, правила обязательности, редактируемости и т.д., а также их взаимосвязей между собой.
Для чего нужно. Чтобы иметь представление о всех данных, которые будут задействованы в системе и том, как они будут храниться и использоваться.
Отдельно еще важно упомянуть про миграцию данных. Нужно описать процесс перехода информации из текущей системы в будущую: из какой системы в какую мигрируем и какую глубину данных (за год или за последние 10 лет) мы забираем.
Далее составляем карты маппинга — старая система → новая система
Этап № 4. Моделирование процессов «как есть»
Это очень важный этап. В нем важно сделать графическое и текстовое описание процессов того, как именно сейчас работают сотрудники.
Зачем это нужно
- Наглядное описание текущего состояния процессов;
- Формирования у всех единого представления о текущих процессах.
- Получение материалов для объективного управления процессами:
– Поиска узких мест;
– Разработки планов по оптимизации процессов; - Составление плана по разработке и внедрению изменений, чтобы перейти от текущей ситуации к той, к которой хотим прийти.
Мы описываем процессы с использованием BPMN, но можно использовать и простые блок-схемы. Обычно выделяют 3 уровня моделирования процессов:
- согласовательный;
- аналитический;
- исполняемый.
Адаптация схемы под уровень моделирования и включение дополнительных деталей на каждом уровне помогут вам избежать проблем при согласовании и сэкономят много времени.
Согласовательный уровень — это уровень для руководства, которое заинтересовано в улучшении процесса. Как правило, руководителям интересны: результаты; основные задачи; исполнители и KPI процесса. Тут схема должна быть максимально простой и понятной.
Аналитический уровень. Нужен для непосредственных участников процесса и аналитика. Схема такого уровня может быть ежедневной инструкцией. Для аналитиков из такой схемы интересны:
- логичность процесса в целом;
- разделение задач между системами и пользователями;
- потенциальная возможность улучшения процесса за счёт оптимизации или автоматизации.
Пример нотации аналитического уровня
Исполняемый уровень. Модель этого уровня нужна для разработчика. Она похожа на аналитическую модель, но должна быть дополнена следующей информацией:
- данные процесса;
- группы и роли;
- бизнес-правила;
- пользовательский интерфейс;
- KPI;
- скрипты и сервисные задачи.
Этап № 5. Моделирование процессов «как должно быть»
Тут мы отображаем то, как должны будут работать сотрудники с учетом запланированных изменений.
Зачем нужно
- Наглядное понимание работы нового процесса;
- Формулирование дополнительных требований к системе на основании требуемого состояния процессов;
- Улучшение процессов за счет оптимизации и устранения узких мест.
Этап № 6. Точки интеграции
Точки интеграции — это формализованное описание систем, с которыми необходимо будет интегрироваться, и способов их интеграции. Нужно для того, чтобы:
- Детально проработать способы интеграции с необходимыми сервисами и предусмотреть все риски;
- Подготовить «контракты интеграции» — какие данные, в каком формате передаем или получаем;
- Найти и устранить узкие места при интеграции или выработать обходные решение;
- Обеспечить требования по информационной безопасности.
Итоговое ТЗ
По итогу все этапы могут занять от 10 до 30 дней, и больше, все зависит от количества процессов, интеграций и формализованности текущих процессов. В любом случае, не пренебрегайте написанием ТЗ, ведь чем лучше вы подготовитесь на этом этапе, тем качественнее проект у вас получится.
Если расписать все эти этапы, то получится документ на 20-30 страниц А4. Для примера — можете посмотреть пример такого ТЗ на нашем сайте.
Не так оно всё радужно, как написано) Был участником и свидетелем внедрения множества систем в том числе по описанной методологии и вот что не так (применимо для среднего и крупного бизнеса, в мелком может быть иначе, не сталкивался).
1. Наличие ТЗ не слишком сильно влияет на успех самого внедрения. В плюс-минус большом проекте ваш документ будут читать несколько человек и каждый поймёт его по своему. На десятом цикле правок и согласований, половина из согласующих перестанет читать документ, потому что они на это не подписывались и будут либо морозиться, либо принимать его не глядя. Потом они же вполне могут заявлять, что продукт сырой, многие требования не покрыты и так далее. Подписанное сторонами ТЗ немного увеличивает шансы на выигранное дело в суде, но не думаю что небольшая компания-интегратор мечтает судиться с условной Икеей.
2. ТЗ в 20-30 страниц это немного наивно) Даже задание на создание небольшого внутрекорпоративного сервиса с внятным описанием внутренней логики и интерфейсов занимает минимум 60-70 страниц с тенденцией уходить в бесконечность, а с серьезными системами с кучей интеграций всё обстоит еще хуже.
3. Вы не пишете ТЗ из воздуха, вы пытаетесь анализировать бизнес-процессы клиента (в идеале конечно). А для этого вы общаетесь с сотрудниками клиента, один из которых как назло в отпуске, второй вечно в командировке, третий не понимает чего вы от него хотите, четвёртый не может понятно ответить на вопросы и вечно уходит в пространные объяснения, перемежая их байками из жизни. В результате в ТЗ попадает процесс в некоторой степени похожий на настоящий. С интеграциями и ролями та же история, всегда есть какая-нибудь Маша, которую забыли занести в матрицу ролей, но без которой ни черта работать не может и не будет.
4. Следствие из п.3. На анализ, беседы, согласования правок, слёзы, панику и финализирование ТЗ легко может уйти от 3х месяцев до полугода (а в случае какого-нибудь ERP и год не удивит). За это время анализируемый бизнес немножко изменится 😊Кто-то внедрит новую систему с которой вам нужно будет в последний момент интегрироваться, кто-то чуть-чуть переделает смежный процесс, кто-то из числа ваших респондентов уволится и не сможет рассказать что он имел ввиду, когда описывал как должна работать фича. Факт в том, что ТЗ устаревает через день после его написания.
Есть еще куча подводных камней, которые тянут на полноценную статью, но резюмируя – имхо, ТЗ это в очень маленькой степени гарантия успеха внедрения или разработки. Это скорее фильтр при входе в проект для обоих сторон. Если заказчик может внятно сформулировать и написать что, как ему сейчас кажется, ему нужно – это плюсик к тому чтобы входить в проект. Для этого в целом и юзер-стори подходят, их внятно описать тоже не каждый в состоянии. Гораздо больше проекту помогут грамотная работа с клиентом (очень редкая штука в наших краях), риск- менеджмент и седовласый ПМ, который заработал первый инфаркт в 27 лет на проекте в ДальГазСтройАвтоматизации и спустя годы имеет чуйку на проблемы и способы их решения. Но в век аджайла все почему-то верят в ТЗ)
Типичное внедрение в малом бизнесе.
Действующие лица: В - владелец или гендир, М - менеджер верхнего звена (комдир, РОП и т.д.)
В: Нам нужно увеличить продажи.
М: Отлично! Я подготовил план. Для этого нам нужно внедрить CRM чтобы не терять клиентов, IP телефонию, чтобы фиксировать звонки и совершать больше звонков, настроить отправку e-mail и т.д. А еще нужно интегрировать 1С с сайтом.
Вот я нашел специалистов, которые внедрят CRM, интеграторов по 1С.
В: А тебе я за что плачу? Сам не можешь установить программу с CRM? У них на сайте все расписано, как это делается.
- IP вообще подключается одним кликом, я видел.
- Какие триггерные письма? Рассылайте всем наши прайсы.
- Мы что еще должны платить кому-то?
- Какие-то левые люди увидят нашу деятельность?
Иди лучше напряги менеджеров, да и сам сделай еще несколько звонков клиентам.
Вчера запретил выполнять задание клиента, потому что никто не отвечает на вопросы со стороны заказчика. Т.е. вместо ТЗ уже подсовывают ХЗ, но потом начнет "мы не это имели ввиду". Конечно всего не распишешь, но ТЗ помогает не приплетать к делу то, чего не было изначально и в этом иногда разница закончишь ты вообще этот проект или нет.
Александр, согласен с вами почти по всем пунктам, но прошу правильно интерпретировать. Ни в коем случае, я не говорил о том что это панацея, которая спасет от всех болезней.
По сути ТЗ это своего рода минимально необходимая гигиена, которая позволяет защищать интересы сторон.
А что касается сроков написания и изменений все так, и на больших масштабах наиболее целесообразно дробить работы на этапы, по возможности. Что бы ускорять процесс. Иначе можно пилить как продукты SAPа, по 5 лет, а потом понять что вообще в принципе это уже и не очень нужно. (Речь о больших продуктах, а не о новых направлениях которые заточены на более короткий цикл внедрения).
Как человек, участвующий в написании ТЗ со стороны заказчика, скажу больше - эту бумажку читают наискосок, дай бог если. Один из подрядчиков мне вообще выдал: мне некогда было читать, что вы там написали, времени не было.
Или, к примеру тебе нужно указать задачу, которую должно решать данная интеграция, но путей несколько и от тебя разрабы требуют решить, через какую задницу пойдет путь, но при этом понятия не имеют, какие сложности при этом будут. и ты такой О_о
так что ТЗ исправно пишу, но в общем виде. Ибо нахрен оно никому не сдалось, все равно все будет через классическую опу
Мне однажды в ответ на вопрос:
- У вас готово ТЗ?
написали:
- Вам изложить нашу Точку Зрения, или что?
ахахха... кажется время собрирать тру стори)
Самое развернутое объяснение "пословицы"))
Ахаха... мы старались)
примерно в ту же тему https://pikabu.ru/story/chuzhoy_kod_5762938
аахах... отличный пример)
Для таких "коллег по цеху" есть отдельный котёл в аду)
Рынок, что с него взять🤷🏽♂️
Добрый день!
Я что-то не понял. Вы начали рассказывать как к Вам пришёл бизнес у которого была кривая срм, а потом километр теории, и нет конца истории про бизнес в начале. Что с ним стало? Он закрылся из-за кривой срм или Вы поработали, и всё стало ок?
А это мы оставили специально для комментариев😈 Надо же вас всех как-то в диалог в тянуть😂
Ну а если серьезно, там написали детальное тз, по нему сделали и в итоге пользуются счастливые и довольные.
Да.
Для того чтобы написать правильное ТЗ, заказчик как минимум должен понимать как у него устроены процессы в компании и возможности современных информационных систем, а таких людей ещё поискать. Туда же в копилку понимание, как можно поменять привычные бизнес-процессы, переводя их в цифру и автоматизируя при внедрении. Владелец живёт в вакууме, чаще всего с устаревшим пониманием всего. Генеральный - наемный сотрудник с желанием заработать и минимумом свободного времени, он может понимать ценность, но не детали в виде ТЗ. Маркетолог каждый месяц новый, ибо его забота в поиске рекламу настраивать, а такой каждый пятый на рынке труда. Директор по продажам сам в формате выполнения плана. Это про средний бизнес. Про малый вообще молчу, им до ТЗ ещё расти и расти.В общем вы думайте внимательнее, прежде чем работу предыдущих специалистов обсирать и себя героями выставлять, адресуйте посыл не всем участникам рынка, а взрослым компаниям. Единственный результативный путь для остальных - гибкое внедрение с промежуточными целями. И даже после такого главная проблема контроля останется. "Внедрить твою за ногу" - меньше половины дела. Контроль работы в CRM, соблюдение правил ведения, создание цифровых рабочих мест и офиса с автоматизацией, отчётность и автоотчетность, маркетинговые активности. В общем всё то что должно дать результат и принести пользу, требует контроля. Вы внедряете по ТЗ, сдаёте проект, клиент думает что после внедрения всё работает само по себе, а через полгода идёт к новому интегратору...
Ну во первых, интегратора мы не "обсирали", а лишь говорили о проблемах имеющихся на рынке.
Во вторых, что касается проблемы ожиданий, тут все зависит от того как вы продаете, если вы кричите на каждом углу "Увеличим продажи за счет внедрения CRM" то на пресейле все красиво и продавать легко, а на деле понятно дело говно, потому что завышены ожидания.
Решается предельно простым способом, берем и на пресейле говорим:
1. У вас станет больше работы в первое время, систему нужно изучать и вести;
2. Сами сотрудники не начнут работать в системе, надо будет реализовать ряд мероприятий со стороны менеджмента, причем как до запуска проекта, так и после, что бы это все зашуршало;
3. То что мы сделаем, надо будет еще докручивать и поддерживать и снова платить за это.
4. И т.д. и т.п.
А потом спрашиваем, а оно вообще вам надо? Вы это понимаете и готовы к этому?
Вот тогда у заказчика формируется правильное представление о том что ему предстоит, но правда продажи падать начинают, ведь вокруг бегает толпа интеграторов которые пихают "волшебную таблетку".
Подписываюсь под каждым словом.
Ох, опять эти продавцы ТЗшек. То, что вы описали - это ваша поделка, а не Техническое Задание. Её можно с огромной натяжкой назвать результатом джун BA (junior Business Analysis), но никак не Техническим Заданием. Этот документ стандартизирован как по ГОСТ (там для современных систем много избыточного), так и по IEEE (ближе к реальности, чтобы что-то выкинуть - нужно сильно постараться).
Где в вашей поделке нормальные нефункциональные требования, а не "облако-коробка"? Где в нем требования заинтересованных лиц, да и вообще их наличие минимум на трех уровнях? Если вы застряли на нижнем уровне на кого будете эскалировать? Ну я даже не говорю про один из важнейших блоков "ограничения системы", отсутствие которого на этапе приемки часто вылезает боком. Условно, у вас ограничение по железу на 100 сотрудников, а компания вводит в систему еще пару департаментов, сотрудников становится 300 и система начинает лагать.
Справедливости ради, то за то безобразие, которое вы привели в самом начале от других "интеграторов" - за такое надо руки отрубать и в причинное место вставлять. Причем можно прямо на законодательном уровне.
И, кстати, BA никак не противоречит Agile, любая методология разработки или внедрения отлично вписывается, это всего лишь Plan Driven или Change Driven подход, который уже отлично откатан.
А вообще, вы молодцы, что смотрите хоть немного глубже огромного количества самоделкиных на нашем непростом рынке!
Эдуард, спасибо за конструктив, есть над чем подумать.
Однако хочу пояснить, данный материал делался для решения определенных задач. А в их контексте не совсем целесообразно обращаться к стандартам, ибо они существенно усложнят восприятие информации целевой аудиторией и скорее всего просто попадут в закладки которые когда то открывают что бы показать кому-нибудь как надо, но не более того.
Проблемы две. Если ТЗ пишет заказчик, то это нереально сделать. Если ТЗ пишет интегратор, то это не надо заказчику.
Вывод один: забить на интеграторов, нанять кодеров и писать в реальном времени то, что нужно.
И заметьте. Никакой фейсбук, гугл и прочие - никто не использует никаких интеграторов. Иначе они бы давно обанкротились. Везде свои отделы разработки.
И кстати, если посчитать, то свои программисты (или фриланс, что даже выгоднее) - это даже тупо дешевле. Я уж не говорю про то, что надежнее и точно будет результат.
А работа с интеграторами выгодна только айтишникам, которые пилят, и самим интеграторам. В этой формуле заказчика нету.
Не знаю какой был у вас опыт, но смею предположить что не очень обширный. На чем и основывается ваше суждение.
Во первых, если раскопать внутрь, то почти все корпорации используют услуги не только инхаус разработки.
Во вторых, компания у которой классический бизнес, зачастую даже не интересна крутым специалистам в IT, потому что там совсем другая ментальность.
В третьих, нормально сделанное ТЗ, решает именно проблему того что бы это отвечало задачам бизнеса и было реализуемо. А если происходит как в вашем примере, то там точно один из участников процесса "не оч", а может и оба🤷🏽♂️
Если интегратор напишет ТЗ, которое клиенту не надо, клиент это не купит.
Почему в вашем уравнении нет варианта с интегратором, который вникнет в процессы клиента и сделает качественное ТЗ, которое будет понятным и клиенту и разработчику?
Не каждому бизнесу нужен инхаус отдел разработки
Не согласен. Многие крупные ИТ компании, даже стартапы заказывают разработку части своих функций на стороне. Это очень видно на Европейском/Американском рынке. Иногда - так быстрее, чем найти человека с нужными компетенциями, иногда - так проще, когда задача на несколько месяцев. Например, для одного стартапа (ну как стартапа, уже инвестиций за 100+млн$) мы помогали в небольшой частной задаче, но эта задача была прямо одной из ключевых функций сервиса.
Хорошая статья. Жаль что ЛПР и ЛДПР ( не партия) их не читают, а их специалисты которым они поручают проекты запускать на стороне заказчика не могут/хотят им объяснить эти прописные истины.
Также многие заказчики просто не готовы выделять бюджет на проработку требований и ТЗ, ведь их реклама накрутила лозунгами "внедрим систему ща месяц за xx рублей".
Или "CRM это просто".
Ну вот мы как раз для этого и писали, что бы она оказывалась перед глазами у нужных людей. Особенно если мы не имеем к ним доступа)
Отлично написано, прямо в рамочку можно вставлять с заголовком "Как надо делать".
Вопрос - создание такого детализованного и покрывающего ТЗ, процесс не быстрый и достаточно сложный/затратный.
Как заказчику объяснить, что ТЗ денег стоит? Ведь в итоге, ТЗ это не гарантия реализации проекта.
Главное донести клиенту, что в его же интересах чтоб ТЗ было сделано. Если понимание важности ТЗ уже есть, но остался вопрос стоимости (почему так дорого), тогда следует позаботиться о том, чтоб донести клиенту какой объём работы будет проделан, желательно на готовых примерах.
Также личный опыт показал, что психологически проще клиенту согласиться на ТЗ, если включить его в стоимость проекта. Т.е. финальную стоимость до утверждения ТЗ не называем, можно дать вилку, но предупредить что от итоговой цены отнимется стоимость реализации ТЗ
Хороший вопрос, рецепта наверное нет, ну или я его не знаю🤷🏽♂️
Но тут мне кажется в первую очередь надо смотреть на адекватность заказчика. Ещё мы активно используем составление плана графика работ, что бы максимально подробно разделить и расписать все задачки. А дальше уже глядя на задачки вроде начинают понимать откуда такая цена.
Спасибо за крутую статью. То чувство, как будто вы написали историю нашего проекта которого еще не закончили. Все примеры и блок-схемы которые показаны, на 80% похожи ). Но учитывая те этапы которые приведены в статье, мы на правильном пути (благодаря нашим интеграторам), несмотря на те сложности которые в начале выглядели заблуждениями или ошибками.
Р.С. А те кто хотят подробное ТЗ по всем стандартам, рекомендую книгу Карла Вигерса 😉
Ну все совпадения случайны) А так спасибо за теплые слова и успехов в реализации проекта)
Крутая статья! Дам студентам почитать как пример
Спасибо, даже не ожидал что настолько хорошо вышло)
Статья интересная и правильный посыл прорабатывать ТЗ.
НО! Как это часто и бывает, подрядчики любят оценивать возможности клиента, чтобы обосновать вложения. И как правило, не корректно, оперируя показателем «выручка». Правильнее использовать хотя бы «грязную прибыль». У одних компаний рентабельность 5%, у других 40%. От какого прироста выручки вы предлагаете выделить на проект 1/3? Надеюсь, не от годовой, которая ПОТЕНЦИАЛЬНО может увеличиться благодаря новым внедрениям?
Тут смотрите, цифры приведены для примера. Поэтому на них ориентироваться не стоит... будем рады если дадите рекомендации как с этим работать, мы там просто отправили к финансистам)
Мне тоже очень интересно как считаются условные 15млн руб за счет возможного роста? Я кучу статей перерыл, сам многократно пытался посчитать эффекты от внедрения CRM - близко к невозможному, это все подгонка под желаемый результат. Например, стало больше продаж тк меньше отказов. Это благодаря CRM? А может пришел классный менеджер, который все отказы прорабатывает или компания заказала правильный тренинг? Или маркетолог запустил кампанию на другую целевую аудиторию, и она априори готова лучше покупать?
И еще - а как дают 1/3 от выгоды? То есть условно, мы когда внедряем CRM для большой компании (на 1000 пользоватлей) выгода допустим измеряется в сотнях миллионах рублей. То проект должен стоить те же 33% от теоретически рассчитанного роста? Круто было бы )
Статья пушка-ракета 🚀
Приятно слышать😜
Спасибо за статью! Отправил заказчику)), иначе прям пошагово из вашей статьи действия " как не надо делать" будут выполняться
ахаха... отлично, надеюсь поможет вам)
Не знаю как для ТЗ CRM, но для Т3 сайтов точно есть хороший тул Октопус
Это для создания структуры сайта, я правильно понял?
Интересно, изучим)
Какое ещё ТЗ? А как же Скрам, Аджайл, Канбан?
А вы для канал "Клиент" случайно не пишите?😂
Ссылка для тех кто не в теме: https://t.me/yourtypicalclient
У вас ошибки в схеме 5го этапа. Вот так нельзя
Справедливое замечание, спасибо!
Интересная статья, спасибо
Бросил читать после , в "Скажите, стоимость внедрения".
Это вы для себя такую пометку сделали? Или что-то донести хотели авторам?