Як заохотити клієнта зробити тестування в домашньому якості?

Оновлення / уточнення Мій клієнт розуміє необхідність їх внутрішнього тестування, і він / він завжди клянеться, що «зробить краще» (тобто зробить щось), але цього просто не відбувається. Вони не мають бюджету на зовнішнє тестування. Напевно, я запитую (смутно, я визнаю) про те, що могло б привести до "тестування рано, тестування часто, тестування на етасі цільових машин?"

Запитання: як заохотити користувачів витратити час на те, щоб явно перевірити та повідомити про проблеми з новими випусками, а не для "тестування" у виробничих проектах.

Передумови: У мене є невеликий клієнт, для якого я написав набір засобів мультимедійної презентації. Вони приємний клієнт і у нас хороші стосунки. Проект триває, додаючи функції, як ми йдемо далі.

У мене є два питання:

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

2. Практично не проводиться тестування якості на їх завершення.

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

У нас було багато дискусій про все це, але мені вдалося лише трохи їх підштовхнути (наприклад, ми використовуємо github для відстеження проблем - хоча в основному я його використовую). Основні причини двоякі: вони невелика консалтингова компанія і не мають (або не думаю, що у них) ресурсів для тестування (ані бюджету, щоб передати її на аутсорсинг). І культурні: хоча вони вважають себе "розробниками", вони насправді є лише користувачами мультимедійного програмного пакету. (наприклад, вони не мають жодної нав'язливої ​​неврозу уваги до деталей "справжніх" розробників).

Це впливає на мене так, як ви очікували: без зворотного зв’язку я не можу сказати, чи функція завершена (див. №1), чи є інші наслідки. Це також робить мене трохи ледачим.

у них немає жодної нав'язливої ​​уваги до неврозу до деталей "справжніх" розробників

Передмова : Мова, яку ви тут використовували, як правило, для мене є червоним прапором. Коли я чую, як люди розмовляють про "справжніх" розробників або про (єдиний) "правильний" спосіб виконання справ, я починаю думати про тунельних бачених розробників вантажних культів .

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

Відповідь

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

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

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

Бізнес часто хоче оптимізувати такі речі, як дострокове вивільнення на ринок та короткострокова економія витрат. При цьому їм може знадобитися пожертвувати такими предметами, як QA, Досвід користувачів, довгострокова економія витрат та інші речі, які змушують розробників поставити галочку.

Це погано? Ну, не обов’язково. Я не можу говорити про всі підприємства, але, на моєму досвіді, мої клієнти роблять це для того, щоб збільшити власну рентабельність інвестицій (рентабельність інвестицій). Такі речі, як QA, удосконалення UX та довгострокове планування, пропонують їм знизити рентабельність інвестицій. Ще гірше, що багато підприємств мають інвестиційні структури, які винагороджують лише короткострокові виграші на відміну від стійких підходів та довгострокових виграшів.

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

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

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

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

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

Таке приймальне тестування, яке проводиться клієнтом, є окремим від інших форм тестування:

• одиничні тести
• тести системної інтеграції
• тести на зручність
• навантажувальні випробування
• тести перед випуском

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

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

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

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

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

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

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

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

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

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

2. Оскільки трекери помилок, якими ми користувалися, не підтримували копію-вставлення зображень, я фактично написав тривіальну програму, яка копіює поточне зображення буфера обміну на диск (як Посібник), а потім копіює Посібник у буфер обміну. Після мінімальної підготовки користувач може приєднати зображення до буфера обміну до проблем, просто натиснувши на екран друку, натиснувши кнопку, а потім вставити в діалогове вікно вибору файлів інструменту подання помилок.

Скріншот (можливо, відредагований у MS Paint з анотаціями) та 1-2 речення достатньо, щоб визначити більшість функцій / помилок.

Обидві ці пропозиції орієнтуються на точки тертя, які я відчував, і обидві ці пропозиції збільшили звітність в 10 разів. Однак вам потрібно буде орієнтуватися на власні точки тертя.

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

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

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

Надання окремої "бета-версії" змусить вас встановити належний контроль версій / конфігурації версій, тож ви можете керувати виробничою гілкою та відділенням бета-тестування поруч без клопоту. Але оскільки ви працюєте з Github, я думаю, ви вже використовуєте щось на зразок GIT, що робить таке управління дуже простим.