Чи патчі є поганим знаком для клієнта? [зачинено]

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

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

Клієнти, які отримали ці пластири, сильно відрізняються один від одного. Деякі насправді чекали патча, де інші насправді не піклувались, але всі вони отримали однакові патчі. Час на оновлення програмного забезпечення для клієнтів становить менше 30 секунд, тому я не очікую проблем із часом. Однак їх потрібно вийти.

Тож моє запитання більш докладно: Чи часто оновлюються повідомлення, що надсилають одержувачу "негативне" повідомлення

Звичайно, я міг би попросити клієнтів, але я не в такому становищі і не хочу «Пробуджувати сплячих собак».

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

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

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

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

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

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

Все більше і більше компаній слідують крокам Chrome і все частіше випускають клієнтів.

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

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

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

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

Патчі, спеціально для клієнтів, які виявили проблему, очевидно, повинні вийти якнайшвидше.

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

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

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

Google chrome вирішує проблему шляхом автоматичного оновлення дуже часто, вони також вимагають від вас переключити програму (перезавантажити хром або у вашому випадку вийти). Зараз вони зробили звичайну практику для браузерів, і люди вже навіть не думають про це. Але не всі можуть бути Google.

Програми SaaS обходять всю проблему, роблячи оновлення у фоновому режимі.

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