Главное Свежее Вакансии Образование
Выбор редакции:
😼
Выбор
редакции
3 365 2 В избр. Сохранено
Авторизуйтесь
Вход с паролем

Как мы перестали работать по ТЗ клиента и стали зарабатывать больше

Как выстроить работу с клиентом так, чтобы впоследствии избежать миллиона правок и многочасовых переделок? Знаем, умеем, практикуем! Будет полезно бойцам, находящимся по обе стороны ТЗ. Спойлер: основываться только на «хотелках» клиента опасно для жизни!

Добрый день! На связи компания INVO Group. Мы занимаемся внедрением облачных решений для автоматизации малого и среднего бизнеса и на данный момент являемся официальным золотым партнером компании Битрикс24.

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

Небольшой спойлер: те, кто дочитает эту статью до конца, узнает рецепт создания dream team, благодаря которой работа с клиентом упростится в разы!

Осторожно, техническое задание!

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

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

— вы просто потратите уйму времени и сил впустую, внося очередную «последнюю» правку;

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

— рискуете испортить отношения с клиентом, да вообще и плохо повлиять на свою репутацию.

Учились на своих ошибках

С этой проблемой сталкиваются многие компании. Признаемся, мы тоже не стали исключением из правил. Раньше специалисты INVO Group работали по схеме, описанной в самом начале этой статьи: ТЗ от заказчика — согласование — работа — «а я хотел все по-другому, давайте переделаем». Можно было, конечно, придерживаться позиции «не виноватая я, вы сами так все прописали», но мы предпочитали идти навстречу клиенту.

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

b_5d78af33c81c0.jpg

Источник: https://pikabu.ru/story/a_chto_tyi_khotel_6564949

Если хочешь сделать что-то хорошо, то сделай это сам

И вот какую интересную закономерность удалось выявить:

• Клиент сказал что хочет, все сделали по его указаниям — получили #жизньболь, потратив кучу ресурсов на переделки;

• Выслушали пожелания клиента, провели аудит, сами составили ТЗ с полным описанием будущего продукта, эскизами интерфейсов, сценариями работы пользователей и программы, согласовали, только после этого приступили к работе — на выходе получается то что надо!

Да, во втором варианте сроки согласования увеличились в 2 раза. Но при этом количество времени, необходимого на реализацию проекта, сократилось в 4 раза!

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

Выигрываем ли от этого мы? Разумеется, оптимизация расходов и экономия нервных клеток очевидна. Да и отзывы от заказчиков стали получать исключительно положительные.

Вы еще кипятите? Тогда мы идем к вам!

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

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

А) помогает заказчику сформировать запрос и функциональные требования по будущему продукту;

Б) проектирует будущее приложение. На выходе получается документ, представляющий собой детально проработанное ТЗ;

В) после разработки продукта подготавливает User Guide (руководство пользователя) и при необходимости проводит с вашими сотрудниками дистанционное онлайн-обучение.

Следующим действующим лицом является архитектор. Он:

А) участвует в подготовке ТЗ и продумывает оптимальную архитектуру будущего решения с точки зрения технической реализации;

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

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

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

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

«Сердце» всей команды и связующее звено с клиентом — проектный менеджер. Он:

А) координирует работу всей команды и следит за сроками;

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

«Мне кажется, что задействовано слишком много людей. И зачем платить больше? Сейчас найду какого-нибудь фрилансера, дешево и сердито все сделает», — невзначай подумает потенциальный заказчик после ознакомления со схемой работы и стоимостью услуг. Правда, он еще не осознает, что в этом случае на его плечи взваливается сбор требований к системе, подготовка архитектурного решения, написание пресловутого ТЗ для программистов и взаимодействие с ними в процессе работы, тестирование системы и выявление ошибок… Задачка выходит непростая, особенно когда отсутствуют соответствующие знания. Есть два варианта развития событий:

а) ничего не работает, да и гори оно синим пламенем;

б) работает по принципу «и так сойдет».

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

Вместо заключения

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

А как вы выстраиваете работу с клиентом/заказчиком? Может у вас есть свои секреты составления ТЗ? Или просто очень хочется поделиться какой-то «забавной» историей из своей практики?

Ждем ваши вопросов и рассказов в комментариях!

+2
В избр. Сохранено
Авторизуйтесь
Вход с паролем
Комментарии
Бидюков Денис
Не знаю, я давно уже выбрасываю все ТЗ. Сначала допытываю заказчика чтобы тот грамотно поставил цель, а потом под эту цель уже ставятся задачи. И заказчик потом радуется когда все по нотам, и я тащусь от отсутствия лишней работы.
Ответить
Миша Чернявский
классная технология !
Ответить
Выбрать файл
Блог проекта
Расскажите историю о создании или развитии проекта, поиске команды, проблемах и решениях
Написать
Личный блог
Продвигайте свои услуги или личный бренд через интересные кейсы и статьи
Написать

Spark использует cookie-файлы. С их помощью мы улучшаем работу нашего сайта и ваше взаимодействие с ним.