Как вы отвечаете на вопросы клиентов «С момента обновления ...»? [закрыто]

После обновления люди продолжают звонить и говорить: «С тех пор, как обновление X, Y и Z работают медленно, плохо и вылетает»

Это случилось с рассвета обновлений.

Чего ожидают люди? Гамма приходит после беты, и гамма-тестирование всегда превращает наших пользователей в Невероятных Халков ...

Возможно, вы никогда не слышали об этом от клиента, возможно, вы учитесь в колледже или разработчике FLOSS, который может распространять вину более чем на 5 или 6 парней, возможно, вы тестируете свой код модулем, возможно, вы не в такой интересной ситуации когда клиенты на самом деле звонят вам с просьбой указать точное время суток, когда вы будете выпускать сегодняшний патч (я бы хотел сделать это для Microsoft), или, возможно, вы извините, как я, который только что отправил новый Обновление и пошел домой и боится возвращаться на работу завтра.

Во всяком случае, ты все равно умнее меня. Как вы критикуете в рамке: «Вы должны быть плохим программистом, потому что вы делаете свое программное обеспечение хуже»?

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

1. Разрабатываете ли вы базу данных такого же размера (примерно), как и производство? Если нет, то у вас всегда будут эти проблемы, потому что запросы, которые подходят для небольших наборов данных, часто являются собаками с большими.
2. Вы загружаете тест в QA? То, что хорошо работает при тестировании одним пользователем, сильно отличается от того, как будут реагировать 1000 пользователей, пытающихся сделать что-то одновременно.
3. Считаете ли вы, что восприятие пользователя неправильно, и относитесь к ним, как будто они глупы для жалоб? Если так, то ваше отношение вызывает больше жалоб, а не уменьшает их.
4. Вы делаете хорошую работу по тестированию? Не изменились ли функции регрессионного тестирования, чтобы увидеть, не повлияло ли на них изменение? Тебе вообще безразлично, сколько времени уйдет, пока они не начнут биться?
5. Обращаете ли вы внимание на то, когда для пользователей самое подходящее время при развертывании, или вы с радостью внедряете изменения в систему учета в день расчета заработной платы и задаетесь вопросом, почему пользователи злятся на замедление?
6. Есть ли у вас экологические различия между dev и prod. Иногда такие неприятные различия в операционных системах или версиях базы данных также могут вызывать подобные проблемы. Часто хорошей идеей является наличие промежуточного окружения, точно такого же, как prod, некоторого оборудования с той же операционной системой, той же базы данных с данными, которая максимально приближена к данным prod. Это используется для проверки вашего развертывания. Сначала запустите его на этом сервере, и пусть некоторые пользователи или тестеры зайдут на него и проведут некоторые тесты.
7. Насколько хорош ваш процесс развертывания, вы часто пропускаете шаги? Может ли он быть запущен кем-то кроме разработчика, потому что ясно, какой код идет в ветке, которую вы развертываете? Мы стали намного лучше в развертывании кода, когда у нас появилась команда управления конфигурацией, и никто не имел права сидеть с prod и присматривать за ним, внося «упс» изменения. Автоматизация вашей сборки может очень помочь. Никто не должен догадываться, что нужно делать, чтобы продвигаться, как это должно было пойти в QA, и сначала ставить, и решать любые проблемы с депиляцией. Сценарии изменений базы данных также являются ключевыми. Они должны быть в сценариях и в управлении исходным кодом, поэтому процесс сборки может подобрать их без необходимости помнить, о да, нам нужно изменить длину в столбце B на 241 с 50.

Как вы критикуете в рамке: «Вы должны быть плохим программистом, потому что вы делаете свое программное обеспечение хуже»?

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

Делать ошибки - это человек, и это не делает кого-то «плохим программистом», так что не принимайте критику лично (в любом случае, я бы никогда не воспринял профессиональную критику со стороны не-коллеги). Просто поблагодарите клиента за сообщение о проблеме и устраните ее, как только сможете. Это твоя работа как хорошего программиста.

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

Когда я получаю такой отчет от пользователя, я пытаюсь использовать личный контакт. Я не хотел вводить ошибки, и я хочу, чтобы они имели хороший опыт работы с моим двигателем, поэтому я должен заставить их поверить в это. Во-первых, получите ручку чата, чтобы мы могли поговорить. Я спрошу пользователя об их проекте и постараюсь получить его копию. Это делает воспроизведение намного проще. Спросите их, что они делали, когда произошел сбой. Тем временем, у меня открыт двигатель в отладчике, и я думаю о проблеме, пока мы разговариваем.

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

Ответ почти всегда представляет собой смесь изумления и благодарности, потому что большинство разработчиков (читай: компании-разработчики программного обеспечения) просто не исправляют ошибки и выпускают их так быстро. И потом, если это действительно исправлено, я превратил потенциального критика в фаната. Это действительно хорошая техника; Я только хотел бы, чтобы больше разработчиков приняло это.

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

Когда они скачивают новую версию и говорят мне что-то подобное, я всегда говорю что-то вроде этого:

Спасибо, что сообщили мне об этой ошибке. Может быть, это было введено вместе, будут все новые функции, которые мы добавили. Мы исправим это как можно скорее.

На самом деле, клиент - ваш настоящий начальник. Если опыт с тобой плохой, это плохо и для тебя.

Даже если он не прав, вы, как часть компании, должны воспользоваться этой возможностью, чтобы:

• учитесь у него, собирая потенциальные улучшения, которые вы могли бы внести в продукт.
• превратить несчастного клиента в счастливого, настолько счастливого, что он будет говорить о вас (включая вашего босса)
• гордиться тем, что ты делаешь

Детали, Детали, Детали. Я спрашиваю, что они делали и когда, будьте конкретны. Это может быть что-то или просто видео Джастина Бибера, только что выпущенное на YouTube. Файлы журналов - ваш друг в обоих случаях.

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

Работа Тень. Не могу подчеркнуть это достаточно. Если вам повезло, что рядом есть пользователи, просто наблюдайте за их работой во времени. Я часто нахожу, что они игнорируют вопиющие проблемы и никогда не сообщают о них. Они часто будут жаловаться только тогда, когда знают, что что-то новое или изначально замечают проблему.

Шаг 1 заключается в том, что вы должны исходить из того, что это (обновление ломает другие вещи) не является нормальным. Ваше обновление не должно нарушать или замедлять работу других частей приложения. Это не нормально, этого не следует ожидать, и это не вина пользователя, когда они жалуются на это. Вы должны делать как можно больше испытаний, чтобы попытаться предотвратить это. Когда это происходит, у вас есть проблема, и срочно.

Шаг 2 заключается в том, что вы должны знать, что вы сделали. Ваша система контроля версий может помочь вам, или какая-то система отслеживания работы, но вы должны быть в состоянии сказать, в ту минуту, когда вы получите одну из этих жалоб "хорошо, я добавил столбец в эту таблицу, изменил эту сетку для расчета новые налоги, добавили эти два новых отчета ... "и так далее.

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

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

Еще немного о «это нормально». Я управляю (помимо прочего) гибким проектом для внешнего клиента. Мы делали релизы примерно каждые 6 недель в течение двух или трех лет. И да, релиз запланирован до минуты. Мы только что сделали один в 8 утра вчера. И примерно каждый четвертый или пятый выпуск (другими словами, один или два раза в год) что-то ломается вживую, и мы начинаем действовать и делаем это как можно быстрее. Хотя мы тестируем и тестируем и тестируем перед выпуском. Тогда мы расскажем им, что случилось. «В июньском развертывании была небольшая ошибка, из-за которой это поле было пустым, но мы никогда не замечали, потому что мы не использовали значение в то время. Затем в этом развертывании, когда мы начали использовать поле, те, которые были пустыми, вызывали это сообщение об ошибке, которое вы видели. Мы мы исправили ошибку, чтобы они не могли быть пустыми, поместили значения в плохие записи и подтвердили, что она больше не взрывается. Приносим свои извинения ». Или« Это экстренное изменение, о котором вы просили, всего за два дня до релиза, имело последствия, о которых мы не думали и не проверяли. Помните, почему мы сопротивляемся экстренным изменениям? »Я не могу быть плохим программистом, чтобы ухудшить ситуацию с обновлением, но я наверняка сделал плохую вещь. И мне нужно сделать это правильно. Возможно, я не плохой программист, чтобы ухудшить ситуацию с обновлением, но я, безусловно, поступил плохо. И мне нужно сделать это правильно. Возможно, я не плохой программист, чтобы ухудшить ситуацию с обновлением, но я, безусловно, поступил плохо. И мне нужно сделать это правильно.

Просто чтобы охватить другой аспект:

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

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