Источник: ain.ua
Разработчик и генеральный директор компании DevSquad Фил Алвес написал колонку о том, почему разработчику нужно уметь говорить «нет» клиентам в некоторых случаях.
Когда я был разработчиком, менеджером проектов, а затем стал генеральным директором консалтинговой IT-компании, я пришел к одной вещи.
Я понял, что попытка угодить каждому желанию и нужде заказчика ограничивает мои возможности непосредственно в разработке и решении проблем.
Вот несколько причин, почему для достижения лучшего результата при написании ПО для клиента вам нужно научиться говорить «нет».
Не каждый клиент подходит вашей команде
Недавно потенциальный клиент сказал мне, что не хочет платить аванс. В ответ я предложил ему отказаться от проекта без дополнительной оплаты.
В конце концов, он не подписал контракт. Хотя это было не лучшее решение в плане заработка, это был лучший шаг для моей команды и моего бизнеса.
Все потому что мы выстроили проверенные процессы и не можем адаптироваться под каждого клиента, чтобы оставаться прибыльными и масштабируемыми.
Этот вопрос касался денег, но это же относится ко всем аспектам нашего бизнеса. Если клиенты хотят получить лучший результат, они должны подходить нам.
Клиенты платят вам за вашу экспертизу, а не за то, что вы будете соглашаться с ними
Многие норовят всегда говорить «да» из-за страха потерять клиента или получить плохой отзыв.
Но количество таких ситуаций будет только расти, если вы будете соглашаться делать то, что находится очень далеко за зоной комфорта вашей команды.
Вы не пойдете в итальянский ресторан, награжденный мишленовской звездой, и не будете жаловаться, если вам там не подадут индийское карри.
Так и я со своей командой очень четко понимаю, какие услуги я предлагаю, а какие нет.
Клиенты платят за ваши услуги, потому что вы можете сделать что-то лучше и быстрее, чем они сами.
Проблема, с которой мы часто встречаемся, заключается в том, что клиенты хотят создать слишком много функций или интеграций, что, по их мнению, поможет добиться лучшего результата.
В таких ситуациях наша задача — объяснить им, что это не так и показать, как мы можем добиться результата в максимально упрощенной, удобной для пользователя форме.
Еще одна распространенная проблема заключается в том, что клиенты хотят подождать, пока продукт не станет идеальным, прежде чем они начнут привлекать клиентов.
Мы настаиваем на обратном и хотим, чтобы люди начались пользоваться продуктом как можно раньше, чтобы мы могли начать тестировать и находить ошибки.
Есть такие вещи, как сильное и слабое вовлечение клиента
Раньше многие разработчики могли потратить три года на создание первой версии продукта, а потом понять, что он не соответствует целям.
Сейчас, я верю, что работающую версию любого сервиса можно сделать за три месяца — работая спринтами.
Но такая модель подразумевает активное участие клиента в процессе.
Мы отказываемся работать с клиентами, которые уделяют нам мало времени, пропадают на длительные сроки, но все же требуют готовый продукт.
Вместо этого, мы работаем в тесном сотрудничестве.
В то же время некоторые клиенты слишком сильно вовлекаются в процесс. Это может отвлекать разработчиков и замедлять разработку. Поэтому мы присылаем обновления клиентам два раза в неделю.
Важно, что коммуникацией с ними занимается только эккаунт-менеджер, чтобы не отвлекать разработчиков.
В конце концов, клиент нанял вас, потому что не хочет сам заниматься подбором разработчиков. Если вы позволите им направлять проект в любом направлении, то разрушите саму суть соглашения.
И хотя любой человек не хочет часто слышать «нет», если вы хотите обеспечить лучший сервис, вам нужно взять на себя ответственность и знать, когда не стоит соглашаться.
Самые актуальные новости - в 
