Почему «без ТЗ результат ХЗ». Разбираем на примере CRM-систем
К нам пришел клиент, который уже пробовал внедрять CRM-систему, и принес наработки предыдущих интеграторов. У него была вроде бы работающая система, но никто ей не пользовался. В статье разберемся, почему так получается, и как делать так, чтобы такого не было.
120120 показов
18K18K открытий
55 репостов
Не так оно всё радужно, как написано) Был участником и свидетелем внедрения множества систем в том числе по описанной методологии и вот что не так (применимо для среднего и крупного бизнеса, в мелком может быть иначе, не сталкивался).
1. Наличие ТЗ не слишком сильно влияет на успех самого внедрения. В плюс-минус большом проекте ваш документ будут читать несколько человек и каждый поймёт его по своему. На десятом цикле правок и согласований, половина из согласующих перестанет читать документ, потому что они на это не подписывались и будут либо морозиться, либо принимать его не глядя. Потом они же вполне могут заявлять, что продукт сырой, многие требования не покрыты и так далее. Подписанное сторонами ТЗ немного увеличивает шансы на выигранное дело в суде, но не думаю что небольшая компания-интегратор мечтает судиться с условной Икеей.
2. ТЗ в 20-30 страниц это немного наивно) Даже задание на создание небольшого внутрекорпоративного сервиса с внятным описанием внутренней логики и интерфейсов занимает минимум 60-70 страниц с тенденцией уходить в бесконечность, а с серьезными системами с кучей интеграций всё обстоит еще хуже.
3. Вы не пишете ТЗ из воздуха, вы пытаетесь анализировать бизнес-процессы клиента (в идеале конечно). А для этого вы общаетесь с сотрудниками клиента, один из которых как назло в отпуске, второй вечно в командировке, третий не понимает чего вы от него хотите, четвёртый не может понятно ответить на вопросы и вечно уходит в пространные объяснения, перемежая их байками из жизни. В результате в ТЗ попадает процесс в некоторой степени похожий на настоящий. С интеграциями и ролями та же история, всегда есть какая-нибудь Маша, которую забыли занести в матрицу ролей, но без которой ни черта работать не может и не будет.
4. Следствие из п.3. На анализ, беседы, согласования правок, слёзы, панику и финализирование ТЗ легко может уйти от 3х месяцев до полугода (а в случае какого-нибудь ERP и год не удивит). За это время анализируемый бизнес немножко изменится 😊Кто-то внедрит новую систему с которой вам нужно будет в последний момент интегрироваться, кто-то чуть-чуть переделает смежный процесс, кто-то из числа ваших респондентов уволится и не сможет рассказать что он имел ввиду, когда описывал как должна работать фича. Факт в том, что ТЗ устаревает через день после его написания.
Есть еще куча подводных камней, которые тянут на полноценную статью, но резюмируя – имхо, ТЗ это в очень маленькой степени гарантия успеха внедрения или разработки. Это скорее фильтр при входе в проект для обоих сторон. Если заказчик может внятно сформулировать и написать что, как ему сейчас кажется, ему нужно – это плюсик к тому чтобы входить в проект. Для этого в целом и юзер-стори подходят, их внятно описать тоже не каждый в состоянии. Гораздо больше проекту помогут грамотная работа с клиентом (очень редкая штука в наших краях), риск- менеджмент и седовласый ПМ, который заработал первый инфаркт в 27 лет на проекте в ДальГазСтройАвтоматизации и спустя годы имеет чуйку на проблемы и способы их решения. Но в век аджайла все почему-то верят в ТЗ)
Типичное внедрение в малом бизнесе.
Действующие лица: В - владелец или гендир, М - менеджер верхнего звена (комдир, РОП и т.д.)
В: Нам нужно увеличить продажи.
М: Отлично! Я подготовил план. Для этого нам нужно внедрить CRM чтобы не терять клиентов, IP телефонию, чтобы фиксировать звонки и совершать больше звонков, настроить отправку e-mail и т.д. А еще нужно интегрировать 1С с сайтом.
Вот я нашел специалистов, которые внедрят CRM, интеграторов по 1С.
В: А тебе я за что плачу? Сам не можешь установить программу с CRM? У них на сайте все расписано, как это делается.
- IP вообще подключается одним кликом, я видел.
- Какие триггерные письма? Рассылайте всем наши прайсы.
- Мы что еще должны платить кому-то?
- Какие-то левые люди увидят нашу деятельность?
Иди лучше напряги менеджеров, да и сам сделай еще несколько звонков клиентам.
Вчера запретил выполнять задание клиента, потому что никто не отвечает на вопросы со стороны заказчика. Т.е. вместо ТЗ уже подсовывают ХЗ, но потом начнет "мы не это имели ввиду". Конечно всего не распишешь, но ТЗ помогает не приплетать к делу то, чего не было изначально и в этом иногда разница закончишь ты вообще этот проект или нет.
Александр, согласен с вами почти по всем пунктам, но прошу правильно интерпретировать. Ни в коем случае, я не говорил о том что это панацея, которая спасет от всех болезней.
По сути ТЗ это своего рода минимально необходимая гигиена, которая позволяет защищать интересы сторон.
А что касается сроков написания и изменений все так, и на больших масштабах наиболее целесообразно дробить работы на этапы, по возможности. Что бы ускорять процесс. Иначе можно пилить как продукты SAPа, по 5 лет, а потом понять что вообще в принципе это уже и не очень нужно. (Речь о больших продуктах, а не о новых направлениях которые заточены на более короткий цикл внедрения).
Как человек, участвующий в написании ТЗ со стороны заказчика, скажу больше - эту бумажку читают наискосок, дай бог если. Один из подрядчиков мне вообще выдал: мне некогда было читать, что вы там написали, времени не было.
Или, к примеру тебе нужно указать задачу, которую должно решать данная интеграция, но путей несколько и от тебя разрабы требуют решить, через какую задницу пойдет путь, но при этом понятия не имеют, какие сложности при этом будут. и ты такой О_о
так что ТЗ исправно пишу, но в общем виде. Ибо нахрен оно никому не сдалось, все равно все будет через классическую опу