Як ви відповідаєте на запитання клієнтів "З моменту оновлення ..."? [зачинено]

Починаючи з оновлення, люди постійно дзвонять і говорять: "З моменту оновлення X, Y і Z повільно, погано і виходять з ладу"

Це траплялося з самого світанку оновлень.

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

Можливо, ви ніколи не чули цього від клієнта, можливо ви знаходитесь у коледжі чи програмі FLOSS Dev, який може поширити провину на понад 5 чи 6 хлопців, можливо, ви перевірите свій код, можливо, ви не в такій цікавій ситуації де клієнти насправді телефонують вам, запитуючи точний час дня, ви випустите сьогоднішній виправлення (я б хотів це зробити в Microsoft) або, можливо, ви шкодуєте сина-бісквіта, як я, який щойно відправив новий оновився і поїхав додому і боїться повернутися до роботи завтра.

У будь-якому випадку, ти все одно розумніший за мене. Як ви на місцях критикуєте в образі "Ви повинні бути поганим програмістом, тому що ви погіршуєте програмне забезпечення"?

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

1. Чи розробляєте ви базу даних, що має такий же розмір (приблизно), як і виробництво? Якщо ні, то у вас завжди будуть такі проблеми, оскільки запити, які відповідають дрібним наборам даних, часто є собаками з великими.
2. Чи завантажуєте ви тест в якості? Те, що добре працює з одним тестуванням користувача, сильно відрізняється від того, як реагуватимуть 1000 користувачів, які намагаються робити це одночасно.
3. Чи вважаєте ви, що сприйняття користувача неправильне, і ставитесь до них так, як вони дурні за скарги? Якщо так, то ваше ставлення викликає більше скарг, не зменшуючи їх.
4. Ти добре робиш тестування? Ви не змінюєте функції тесту регресії, щоб побачити, чи впливають вони на зміну? Вам навіть байдуже, скільки часу триватиме, поки вони не потрапляють у продаж
5. Ви звертаєте увагу на те, коли настав час для користувачів, коли ви розгортаєтесь, чи ви весело розгортаєте зміну в обліковій системі, коли працює заробітна плата за день, і цікавитеся, чому користувачі сердяться на сповільнення?
6. Чи є у вас екологічні відмінності між розробниками та виробниками. Іноді такі нестабільні відмінності в операційних системах або версіях бази даних також спричиняють такі проблеми. Найчастіше гарна ідея мати постановочну середовище, яка точно нагадує prod, деяке обладнання тієї ж операційної системи, ту саму базу даних з dat, яка максимально наближена до даних prod. Це використовується для тестування вашого розгортання. Спершу запустіть його на цьому сервері, і деякі користувачі або тестери перейдуть на нього і пройдуть деякі тести.
7. Наскільки хороший ваш процес розгортання, ви часто пропускаєте кроки? Чи може ним керувати хтось інший, ніж розробник, оскільки зрозуміло, який код йде у гілку, яку ви розгортаєте? Ми отримали набагато краще в розгортанні коду, коли отримали команду управління конфігурацією, і ніхто не мав прав сидіти з prod і няня, вносячи зміни в "oopsie". Автоматизація вашої збірки може допомогти надзвичайно. Ніхто не повинен здогадуватися про те, що потрібно робити, тому що він повинен був перейти до забезпечення якості та спочатку інсценізувати будь-які проблеми з недостатністю. Зміни бази даних сценаріїв також є ключовими. Вони повинні бути в сценаріях та в керуванні джерелами, тому процес збирання може забрати їх, не маючи при цьому пам'ятати, о так, нам потрібно змінити довжину стовпця B на 241 з 50.

Як ви на місцях критикуєте в образі "Ви повинні бути поганим програмістом, тому що ви погіршуєте програмне забезпечення"?

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

Робити помилки є людьми, і це нікого не робить «поганим програмістом», тому не сприймайте критику особисто (я б ніколи не сприймав жодної професійної критики з боку колеги всерйоз). Просто подякуйте замовнику за повідомлення про проблему та виправте це, як тільки зможете. Це ваша робота як хорошого програміста.

Що ж, на роботі ми не сильно взаємодіємо з клієнтами, тому мені доведеться відповісти на це з особистої роботи над проектом. Я пишу ігровий движок, який люди можуть використовувати для створення власних ігор. Це все ще в пре-альфа, але у мене є кілька зацікавлених користувачів, а іноді я отримую помилки.

Коли я отримую подібний звіт від користувача, я намагаюся використовувати особисту інформацію. Я не хотів вводити помилок, і я хочу, щоб вони мали гарний досвід роботи з моїм двигуном, тому мені потрібно змусити їх повірити в це. По-перше, дістаньтеся до чату, щоб ми могли поговорити Я запитаю користувача про їхній проект і спробую отримати його копію. Це набагато полегшує розмноження. Запитайте у них, що вони робили, коли стався глюк. Тим часом я відкрив двигун у налагоджувальній машині, і я налагоджую це питання, поки ми говоримо.

Якщо це виняток, зазвичай це досить просто. Відтворіть проблему, і налагоджувач захопить її та переведе вас прямо до місця помилки з повним слідом стека, і очевидно, що відбувається. Якщо це низька продуктивність або неправильна поведінка, це може зайняти трохи більше часу. Але в більшості випадків я можу підготувати виправлення протягом перших 20 хвилин, вершини. Я зашпилюю його і відправляю їм на тестування. "Гаразд, я думаю, я це зрозумів. Подивіться, чи працює це у вашому кінці?"

Відповідь майже універсальна - це суміш здивування та вдячності, адже більшість розробників (читайте: програмні компанії) просто не виправляють помилок і не відпускають це швидко. І тоді, якщо це насправді виправлено, я перетворив потенційного критика у фанат. Це дійсно гарна техніка; Я просто хочу, щоб більше розробників прийняло це.

Я особисто сприймаю проблему позитивно. Я весь час взаємодію з великою кількістю зберігачів, і я все ще кодуюсь.

Коли вони завантажують новий реліз і кажуть мені щось подібне, я завжди кажу щось подібне:

Дякуємо, що повідомили про цю помилку. Можливо, це було введено разом, всі нові функції, які ми додали. Виправимо це якнайшвидше.

Насправді замовник - ваш справжній начальник. Якщо досвід з вами поганий, це погано і для вас.

Навіть якщо він не правий, ви, як частина компанії, повинні скористатися цією можливістю:

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

Деталі, подробиці, подробиці. Я запитую, що вони робили і коли, будьте конкретні. Це може бути щось, а може бути просто так, що відео Justin Beaber щойно вийшло на YouTube. В обох випадках файли журналу - ваш друг.

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

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

Крок 1 полягає в тому, що ви повинні прийти з розуму, що це (оновлення порушує інші речі) не є нормальним. Оновлення не повинно порушувати або сповільнювати інші частини програми. Це не нормально, цього не можна очікувати, і це не вина користувача, коли вони скаржаться на це. Ви повинні зробити тестування, наскільки це можливо, щоб спробувати запобігти. Коли це трапляється, у вас є проблема, і термінова.

Крок 2 - ви повинні знати, що ви зробили. Можливо, ваша система управління джерелом може допомогти вам, або якась система відстеження роботи, але ви повинні мати можливість сказати в хвилину, коли ви отримаєте одну з цих скарг "добре, я додав стовпець до цієї таблиці, змінив цю сітку для обчислення нові податки, додані ці два нові звіти ... "тощо.

Крок 3 полягає в тому, що у вас повинен бути досвід пошуку проблем та збоїв у швидкості, тож ви знаєте, які речі можуть викликати їх, і ви зможете дістатись до проблеми відразу. Ця річ розпочалася, і ви повинні швидко знайти проблему та отримати виправлення. Зміна звіту не може сповільнити частину програми, яка не використовує звіт. Ви зараз перебуваєте в аварійному режимі і мусите розібратися, де помилка і що з цим робити - не порушуючи іншої частини програми в процесі.

Крок 4 - для кожної з цих бід, ви повинні вивчити урок, який ви перевірите наступного разу. Ви станете "тим хлопцем", який заперечує проти певних конструкцій, оскільки "це буде жахливо, коли буде 10 000 записів".

Ще трохи на фронті "це нормально". Я запускаю (серед усього іншого, що ми зараз робимо) спритний проект для зовнішнього замовника. Ми робимо випуски приблизно кожні 6 тижнів протягом двох-трьох років. І так, випуск запланований на хвилину. Ми щойно зробили його о 8 ранку вчора. І приблизно кожного 4-го чи 5-го випусків (один-два рази на рік, іншими словами) щось виходить з ладу, і ми переходимо до дії і робимо це правильно як можна швидше. Незважаючи на те, що ми перевіряємо і тестуємо перед випуском. Тоді ми розповідаємо їм, що сталося. "У червневому розгортанні була невелика помилка, яка дозволила пустувати це поле, але ми цього не помітили, тому що ми не використовували значення в той час. Потім у цьому розгортанні, коли ми почали використовувати поле, ті, які були порожніми, викликали те повідомлення про помилку, яке ви бачили. Виправили помилку, щоб вони не могли бути порожніми, ввели значення в погані записи та підтвердили, що вона більше не підірвана. Наші вибачення ". Або" Ця надзвичайна зміна, яку ви просили, лише за два дні до звільнення, мала наслідки, про які ми не думали і не перевіряли. Пам’ятайте, чому ми чинимо опір екстреним змінам? "Я, можливо, не поганий програміст, що погіршив його з оновленням, але я, безумовно, зробив погану справу. І мені потрібно зробити це правильно. Я, можливо, не поганий програміст, що погіршив його з оновленням, але я, безумовно, зробив погану справу. І мені потрібно зробити це правильно. Я, можливо, не поганий програміст, що погіршив його з оновленням, але я, безумовно, зробив погану справу. І мені потрібно зробити це правильно.

Просто для висвітлення іншого аспекту:

Ми зберігаємо список клієнтів, які заявляють про це, коли виявилося не так. Незважаючи на те, що програмне забезпечення є баггі, часто дуже баггі, багато наших клієнтів будуть стверджувати, що "почали з оновлення", щоб отримати швидку увагу, не усвідомлюючи, що це втрачає час для всіх, коли ми підемо дельти за вказаною особливістю, шукаючи проблему. Якщо замовник говорить правду, це прагне швидко знайти його. Якщо клієнт занадто багато разів потрапляє в неправдивий список, ми не турбуємось, оскільки не любимо витрачати час.

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