Чем индивидуальный подход к клиенту отличается от имитации индивидуального подхода и в каких случаях имитация позволяет получить лучший результат.
Настоящий индивидуальный подход к проблеме клиента заключается в том, что специалисты компании выслушивают проблему клиента и разрабатывают под него индивидуальные решения, которые будут полностью соответствовать ожиданиям клиента. Это очень сложный путь, который обходится достаточно дорого исполнителю и в подавляющем большинстве случаев до первого положительного результата проходит множество итераций.
Мы рассматриваем эту ситуацию с точки зрения разработки программного продукта, но в большинстве случаев это применимо и к любым другим сферам.
Ожидания вашего клиента
В подавляющем большинстве случаев заказчик хочет получить с первой попытки рабочий продукт, который будет соответствовать всем его индивидуальным требованиям. При этом, как правило, заказчик крайне негативно реагирует на любые ошибки в продукте и несоответствия, которые точно будут в случае с индивидуальной разработкой.
Опытные специалисты могут закидать меня помидорами, ибо расскажут то, что настоящий профи не делает ошибок, но так подумает только человек без реального опыта разработки индивидуальных решений.
Ошибки могут быть технические, но гораздо чаще встречаются логические ошибки, которые появляются на этапе разработки при изучении технического задания, которое содержит “пробелы” в описании. Именно по этой причине важно детально прорабатывать техническое задание для исполнителя для исполнителя.
Очень часто клиенту просто лень детально описывать то, что он хочет получить.
Я часто сталкивался с тем, когда клиент описывает задачу весьма поверхностно, а уже после реализации начинаются претензии к отдельным элементам логики готового продукта, т.к. с точки зрения заказчика ему кажется очевидным то, что неописанные особенности являются очевидными. При этом, как правило, для исполнителя, который за свой трудовой опыт успел выполнить сотни различных проектов, как правило, ничто не кажется очевидным. После определенного количества выполненных проектов по индивидуальном требованиям в голове начинается каша, которая содержит в себе отрывки требований и виденье сотни клиентов, которые считают исключительно правильной только свое виденье реализации.
Таким образом мы выделили первую весомую проблему в индивидуальном подходе к разработке решений под клиентов – правильное техническое задание, которое нужно детально прорабатывать с заказчиком, который в большинстве случаев не хочет тратить на это силы и время. Люди намного более ленивы, чем кажется.
Вторая большая проблема появляется уже после реализации. Если решение действительно было индивидуально разработано под клиента, то оно требует углублённого тестирования, к которому клиент не готов. Клиент ожидает получить сразу продукт, который будет работать без ошибок технических и логических. Даже если вы предупреждаете клиента о возможных ошибках, то он все равно будет крайне недоволен при появлении ошибок, даже если это будет логическая ошибка, которая появилась в следствии неверного описания задачи, которое вам изначально и предоставил клиент.
С точки зрения, как правило, при появлении ошибок Вы виновны в любом случае. Если же все работает, то вы просто сделали свою работу.
В совокупности всего описанного выше, мы получаем более длительный период разработки, который может затягиваться на неопределенный период, ибо количество доработок и дополнительных пожеланий может быть неограниченное.
После у разработчиков появляется дилемма: исправлять ли баги в рамках ранее согласованной стоимости проекта, либо выставлять дополнительный счет. Даже если проблемы появились в следствии того, что клиент сам не описал определенную логику действий. Если спросить самого клиента, то с его точки зрения он всегда прав и всё описал изначально. А если он что-то не описал, то это логично и элементарно.
Индивидуальный подход к разработке программных продуктов под клиента, как правило, всегда достаточно конфликтный путь. Нередко он более затратный, чем если просто продавать готовый продукт, который не потребуется дорабатывать по требованию клиента, который сам даже отдаленно не понимает все сложности реализации.
Все еще больше осложняется, если вы пытаетесь работать в таком форме с мелким бизнесом, ибо для них и так это дорого, а тут еще заказчик получает на первом этапе неполностью рабочий продукт и требуется дополнительное время и деньги на доработку. Получить положительный отзыв в таких условиях, как правило, очень сложно. Большинство клиентов из мелкого бизнеса очень далеки от разработки. Если бы они знали все тонкости разработки, то сделали бы все сами, ибо для них это слишком дорого.
К счастью, есть вариант с имитацией индивидуального подхода (разработка индивидуальных решений на базе готовых шаблонов). Это делает разработку продукта существенно дешевле, вероятность ошибок в конечном продукте сведена к минимуму, а а шансы получить негативный отзыв кратно уменьшаются.
Суть этого подхода заключается в том, что у компании-разработчика должно быть большое количество заготовок, которые можно вариативно менять под требования клиента. При этом важно понимать то, что любые заготовки имеют свои ограничения, поэтому важно сделать так, чтобы конечное техническое задание гибко подстраивалось под все эти ограничения.
Индивидуальная разработка без применения готовых шаблонов имеет смысл только в том случае, если под решение клиента нет даже близко готовых решений, а бюджет клиента позволяет заняться не только разработкой, но и тестированием. Если клиент не воспринимает индивидуальную разработку так, как долгосрочный проект, то в подавляющем большинстве случаев он не останется доволен конечным результатом.
При обработке технического задания важно помнить то, что итоговый результат должен принести максимум пользы клиенту. Поэтому не нужно писать программу ради того, чтобы была программа. Отталкивайтесь от бизнес-задач клиента и подбирайте оптимальные решения. Изучайте лучшие практики из сферы деятельности клиента. Например, вам точно не будет лишним ознакомиться со статьей про организацию базы данных и реализацию коллтрекинга, если ваш клиент работает с физическими лицами и хочет отладить работу с потоком заявок.
Если в индивидуальном подходе в разработке ведущим в написании технического задания был сам клиент, то при имитации индивидуального подхода ведущим является специалист от компании исполнителя, который будет заниматься разработкой и согласованием технического задания для клиента. Он общается с клиентом, выясняет его потребности и подбирает под него готовые решения, собирая конечный продукт так, как ребенок собирает конструктор.
Это лучшая схема для работы с небольшими компаниями. На это есть несколько причин:
- Процесс разработки значительно упрощается и становится быстрее.
- Вероятность ошибки снижается, т.к. ничего не разрабатывалось полностью индивидуально с нуля, а собиралось из готовых решений.
- В первой версии клиент получает рабочий продукт, который не содержит критических ошибок.
- Клиент получает более низкую стоимость, чем если бы решение полностью разрабатывали по его ТЗ с нуля.
- Со стороны клиента требовалось минимум усилий для написания ТЗ и тестирования.
- Конечное ТЗ составлено грамотно и учитывает самый лёгкий путь реализации.
Из минусов для клиента в этой схеме только то, что конечный продукт может закрывать потребности клиента не 1в1 так, как он себе это представлял.
Из минусов для исполнителя только то, что для успешной реализации нужен очень опытный менеджер, который будет не только хорошо подкован технически (хорошее понимание тонкостей доработки и всех готовых шаблонных решений), но и максимально коммуникабельный, ибо ему нужно будет показать и доказать клиенту то, что предложенное решение так же успешно закрывает его потребности, но в конечной реализации все получится гораздо практичнее и удобнее именно в таком виде.
При всем этом у заказчика не должно создаться впечатление того, что ему пытаются продать полностью шаблонный продукт.
В общем, далеко не каждый менеджер сможет заставить думать клиента так, что именно он придумал это техническое задание и детально описал то, что уже практически реализовано.
Если человек подумает о том, что покупает шаблонный продукт, то он сразу представит то, что разработчик вообще ничего не делал. Для человека, который никогда не пробовал написать строчку кода, как правило, сборка решения из заготовок является чем-то похожим на установку игр на домашнем ПК. Именно по этой причине, как мне кажется, клиенту лучше не знать все тонкости процесса разработки конечного продукта.
Даже если решение собирается из заготовок, то это все равно большой объём работ, который требует прохождения всех этапов разработки, но большинство клиентов это просто не поймет.
В каких случаях стоит соглашаться на разработку персональных решений с нуля?
Тут не будет универсального ответа, т.к. многое зависит от опыта вашей компании. Если у вас нет наработанной базы шаблонных решений, то без разработки они и не появятся, поэтому первые заказы придется делать индивидуально.
Так же стоит задумываться о индивидуальных разработке в том случае, если клиент крупный и ваши отношения с ним могут быть долгосрочными.
Если клиент обладает весомым именем в своей сфере, то в дальнейшем при соответствующих договоренностях вы сможете использовать этот проект для своего портфолио, что выгодно подчеркнет ваш профессионализм. Многие небольшие копании будут обращаться к вам лишь за тем, чтобы вы сделали для них аналогичный проект, т.к. в их понимании это обеспечит успех и им.
В каких случаях стоит отказываться от индивидуальных доработок?
Если клиент четко не понимает то, какой результат он хочет получить и какие инструменты ему нужны, то стоит отказаться от сложных разработок. К сожалению, большинство ваших клиентов не будут знать то, что они хотят получить, поэтому такие клиенты задушат ваш бесконечными правками.
В подавляющем большинстве случаев намного эффективнее таких клиентов уговорить на решение предложенное вами.
Если клиент постоянно занижает ценность вашего труда, но при этом не хочет соглашаться на решения предложенные вами, то лучше отказаться от работы с таким клиентом.
Я сотни раз слышал то, что поправить что-то под новую потребность клиента займет минут пять (по словам клиента), но в большинстве случаев даже незначительные правки требовали минимум несколько часов дополнительный работы. Такие слова из уст клиента значат лишь то, что он обесценивает ваш труд. В подавляющем большинстве случаев, если клиент сказал то, что “там дополнить минут за пять можно”, то он уверен на все 100% в том, что дополнять проект под его новую “хотелку” вы должны бесплатно.
Клиент может хотеть научить слона кататься на двухколесном велосипеде, но любой специалист по слонам точно знает то, что для слона это будет непосильная задача в силу его физиологии.
Не нужно идти на поводу у клиентов, пытаясь реализовать заведомо провальные идеи.
В исключительных случаях доработки можно делать бесплатно, но лишь в том случае, если клиент наконец-то сформировал свое представление о конечном результате.
Я знаю то, что многие компании уже используют описанный подход с имитацией индивидуального подхода к разработке продукта под потребности клиента. Я не вижу в этом ничего плохого в том случае, если в конечном результате клиент остается относительно доволен.