Что вы делаете как разработчик с клиентскими запросами, не являющимися ошибками, например небольшое исправление в пользовательском интерфейсе?

Question

Я только один человек, работающий над проектом - поэтому я разработчик без PM выше меня. Я закончил портал, клиент hovewer время от времени нападает на меня с таким запросом, как " увеличить шрифт " или поменяйте поля в css или make, чтобы получить "xxx и yyy". Есть простые задачи, иногда всего за несколько кликов, но это занимает мое время, и я ненавижу делать такие задачи. С другой стороны, я понимаю этих людей, хотя иногда небольшое исправление помогает им в работе. Что говорят их по коммуникаторам - их сложно игнорировать. Является ли отключение коммуникаторов лучшим решением, но оно мне нужно для общения с коллегами. Что вы делаете в таких ситуациях?

Answer 1

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

Из-за этого вы получаете запросы по каналу связи, который вы регулярно проверяете, вы можете попытаться отодвинуть его в сторону.

Отключение связи НИКОГДА не является хорошим решением. Кроме того, я бы формализовал процесс и график, когда вы получите эти типы запросов. Я нашел большой успех с этим простым подходом.

Answer 2

Если вы работаете на себя, ваши клиенты - ваша самая важная причина, по которой вы там работаете. Это ваше дело! Поэтому всегда полезно держать их счастливыми.

Как говорится ...

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

Чем меньше открытых концов, тем лучше.

Впоследствии, внедрение системы для управления / обработки запросов клиентов для каждого из реализованных вами проектов / веб-сайтов также может быть очень полезным. Такие инструменты, как FogBugz одного из основателей этого сайта, отлично справляются с взаимодействием с клиентом и обнаруживают ошибки / функции Запросы. Проверьте это.

Answer 3

Хотя это не техническая «ошибка», удобство использования клиентом является самой важной ошибкой для пользователя. Если вы хотите продолжить бизнес с клиентом, нужно поработать над мелочами.

исправление мелких ошибок == счастье клиента == больше работы == больше $$

Answer 4

Разверните систему для отслеживания ошибок и отслеживания запросов на изменение (в моем офисе мы используем MKS, который также используется для обеспечения целостности исходного кода). Затем, когда у пользователя есть запрос, он входит в систему отслеживания и вводит запрос как соответствующий тип. В идеале они также должны иметь возможность прикрепить к нему индикатор серьезности / приоритета, чтобы можно было ранжировать невыполненные запросы. Затем вы можете войти и просмотреть все невыполненные запросы и расставить их приоритеты. Поскольку они не отправляются вам напрямую, вы не будете чувствовать себя заваленными запросами, и пользователи обнаружат, что им легче отслеживать состояние своих запросов, чем позвонив вам и спросив "когда будет сделано мое исправление?" & Quot;

Для себя вы можете проверять список несколько раз в день и посмотреть, есть ли какие-либо проблемы с высоким приоритетом для работы. Затем запланируйте некоторое время на регулярной основе (один день в неделю или час, в зависимости от того, что кажется разумным) для работы над вопросами с более низким приоритетом.

Answer 5

Я думаю, что вы должны рассмотреть ваши постоянные отношения с вашим клиентом. Если клиент время от времени тратит несколько минут вашего времени, вы можете посчитать, что стоимость для вас минимальна, и выгоды от контакта могут в любом случае перевесить стоимость.

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

Answer 6

Не меняйте путь при каждом запросе функции, который вы получаете. Некоторое время собирайте запросы функций, затем назначайте приоритеты запросам, затем выбирайте те, которые имеют смысл, и затем работайте над следующим выпуском.

По моему мнению, хорошо следовать некоторому фиксированному графику выпуска: это делает процесс разработки более управляемым, улучшает качество программного обеспечения, и ваши клиенты знают, чего ожидать.