Обновление / разъяснение. Мой клиент понимает необходимость их внутреннего тестирования, и он / они всегда клянется, что «сделают лучше» (то есть сделают что-то), но этого просто не происходит. У них нет бюджета для внешнего тестирования. Я предполагаю, что спрашиваю (смутно, признаю), что могло бы привести к «раннему тестированию, частому тестированию, тестированию на идеале целевых машин»?
Вопрос: как побудить пользователей тратить время на явное тестирование и сообщать о проблемах с новыми выпусками, а не «тестировать как они» в производственных проектах.
Предыстория: у меня есть небольшой клиент, для которого я написал набор инструментов для мультимедийных презентаций. Они хороший клиент, и у нас хорошие отношения. Проект продолжается, добавляя новые функции по мере продвижения.
У меня есть две проблемы:
Определение функции выполняется на лету, часто по телефону, может быть изменено, изменено, изменено. (что-то вроде «Кеннеди» «Мы поедем на Луну и будем заниматься другими делами» - меня всегда удивляла эта «другая вещь»)
Практически не проводится тестирование качества с их стороны.
Я могу иметь дело с # 1, более или менее. Это не клиент, который даже прочитал бы спецификацию перед встречей, не говоря уже о том, чтобы написать ее. Я привык к этому. У меня проблема с пунктом 2: они не тестируют или не будут тестировать новые версии. Что они делают, так это используют их для производства, поэтому, когда появляются ошибки, они либо находят обходной путь и не сообщают об этом, либо они так торопятся приступить к проекту, что сообщения об ошибках расплывчаты.
У нас было много дискуссий обо всем этом, но мне удалось лишь слегка их подтолкнуть (например, мы используем github для отслеживания проблем - хотя в основном я использую его). Коренные причины двояки: они являются небольшой консалтинговой компанией и не имеют (или не думают, что у них есть) ресурсы для тестирования (и бюджет для его аутсорсинга). И культурный: хотя они думают о себе как о «разработчиках», на самом деле они просто пользователи мультимедийного программного пакета. (например, у них нет навязчивого невроза внимания к деталям «настоящих» разработчиков).
Это влияет на меня, как и следовало ожидать: без обратной связи я не могу сказать, завершена ли функция (см. # 1), или есть другие последствия. Это также делает меня немного ленивым.
источник
Ответы:
Предисловие : Тип языка, который вы здесь используете, обычно для меня красный флаг. Когда я слышу, как люди говорят о «настоящих» разработчиках или (единственном и единственном) «правильном» способе ведения дел, я начинаю думать о разработчиках культового видения с туннельным видением .
Я не говорю, что вы определенно один из этих разработчиков (у меня нет достаточных доказательств, чтобы утверждать это), но если да, то вам может пригодиться этот ответ.
Ответ
Похоже, вы и ваш клиент оптимизируете под разные вещи. К сожалению, в разработке программного обеспечения часто не всегда совпадают потребности бизнеса и желания разработчиков.
Разработчики программного обеспечения часто страстные люди с акцентом на улучшение. Им нравится повышать производительность программного обеспечения, процесс разработки, бизнес-процессы, методы коммуникации и т. Д. И это здорово. Сосредоточение внимания на этих вещах - это то, что отделяет мастеров и ремесленниц от бездумных клавишников.
Но ваш клиент не специалист по программному обеспечению. Ваш клиент - это бизнес с совершенно другим набором приоритетов. И иногда эти приоритеты выглядят нелепо для нас, мастеров-программистов ... но это только потому, что мы оптимизируемся под разные вещи.
Бизнес часто хочет оптимизировать для таких вещей, как ранний выход на рынок и краткосрочная экономия средств. При этом им, возможно, придется пожертвовать такими вещами, как QA, пользовательский опыт, долгосрочная экономия средств и другие вещи, которые заставляют разработчиков тикать.
Это плохо? Ну, не обязательно. Я не могу говорить от имени всех компаний, но, по моему опыту, мои клиенты делают это, чтобы увеличить собственную рентабельность инвестиций (возврат инвестиций). Такие вещи, как QA, UX-совершенствование и долгосрочное планирование, предлагают им более низкую рентабельность. Хуже того, многие компании имеют инвестиционные структуры, которые вознаграждают только краткосрочные выигрыши, а не устойчивые подходы и долгосрочные выигрыши.
Таким образом, хотя вы можете попытаться продать идею QA своему клиенту, вы можете тратить свое время и напрягать свои отношения с ними. В лучшем случае вы получите кого-то, кто хочет опробовать ваши идеи (маловероятно). В худшем случае вам придется убедить всю компанию переделать свои стимулирующие структуры, чтобы вознаградить долгосрочные инвестиции, такие как обеспечение качества. В любом случае ваши шансы на успех невелики.
источник
Интересным является вопрос, когда вам платят, а не проводит ли ваш клиент какие-либо собственные тесты.
Проблема в том, как вы можете узнать, когда клиент примет программное обеспечение и заплатит вам. Это явно не работает, когда клиент постоянно дополняет проект неопределенными новыми запросами. Если это означает, что день оплаты всегда откладывается - и становится менее вероятным при каждом запросе - это становится для вас несостоятельным.
Фиксированный контракт, который тщательно определяет все функции и определяет, при каких условиях клиент будет принимать эти функции, явно очень неудобен, но он позволяет планировать проект заранее (также следующий проект). Это также гарантирует, что вы получите свои деньги за программное обеспечение, которое вы поставили, если оно соответствует спецификации. В таком сценарии единственная ответственность клиента лежит на этапе определения контракта и в конце для приемочного тестирования .
Такое приемочное тестирование, проводимое клиентом, отделено от других форм тестирования:
Насколько это возможно, вы ожидаете приемочные испытания и выполняете их самостоятельно, прежде чем предоставлять функциональность, чтобы избежать каких-либо затруднений. Помимо приемочных испытаний (которые измеряют только выполнение контракта , а не качество программного обеспечения ), вся ответственность за обеспечение качества лежит на вас. В частности, ваш клиент не обязательно имеет образ мышления QA, необходимую техническую подготовку или договорное обязательство выполнять QA. Кроме того, я нахожу аутсорсинговую охоту на клиента совершенно непрофессиональной.
Это не значит, что ошибок не будет. Предполагая, что у вас есть клиентские отношения на основе проекта, вы захотите пройти границу между вежливостью и быстрым предоставлением исправлений и объяснением того, что они приняли текущий выпуск как достаточный для своих нужд - большие изменения требуют нового контракта. Если у вас есть постоянный контракт на поддержку, вам, конечно, придется придерживаться вашего согласованного уровня обслуживания.
В гибких условиях реагирование на потребности клиентов ценится больше, чем соблюдение буквы контракта, но вы все равно хотите получать оплату. Поэтому многие методологии гибкого проектного проекта ценят тесное взаимодействие с клиентом до такой степени, что клиент может стать частью команды. Затем вы всегда можете поговорить с этим «владельцем продукта», чтобы уточнить любые необходимые моменты. Поскольку у ПО есть право предоставлять вам время для работы с любой функцией, которая окажется ему полезной, это может сработать, даже если вы начинаете с неопределенных потребностей клиента. Если у вас нет такого тесного общения, вам нужно будет придерживаться более формального подхода.
Все клиентские запросы должны быть представлены в письменной форме, чтобы вы могли выставить счет. Это защищает их от выставления счетов за то, над чем вы только что работали - например, переписывание всего интерфейса при запросе выравнивания кнопки по-другому.
Много общения может быть сделано лично или по телефону, но в конце вы захотите лист бумаги, чтобы документировать, что клиент хотел, чтобы вы работали над этими требованиями. В простых случаях может быть достаточно повторить телефонный звонок и отправить им электронное письмо, чтобы проверить, что они просили вас сделать.
Сообщения об ошибках всегда сложны. Если ваши клиенты сами разработчики, это должно помочь, так как они могут понять ваши потребности: иметь четкие шаги для воспроизведения. Простой способ получить глубокое понимание - включить регистрацию в развернутом программном обеспечении. При условии, что проблемы конфиденциальности данных могут быть решены, требуя, чтобы к каждому отчету об ошибках был прикреплен текущий журнал, не только гарантируется некоторая письменная связь, но также и сообщается вам, что на самом деле сделал пользователь (в отличие от того, что они думали, что пытались сделать) ,
источник
Способ поощрения сообщения об ошибках заключается в поощрении частой, детальной передачи функций. Если вы обучаете компанию, что они могут просить что-либо с нулевой церемонией, они будут использовать эту функцию и для мелких ошибок. Откажитесь от изменения рабочего процесса вашего клиента, если эти изменения не облегчат его жизнь.
Заставить вашего клиента выполнить внутреннее тестирование довольно сложно, но заставить его фактически сообщать об ошибках не так сложно, как кажется. Чтобы получить больше откликов, нужно уменьшить трения пользователей ... даже если это означает, что некоторые из этих трений нужно передать себе.
Используйте более простые инструменты, даже если эти инструменты неадекватны и не подходят. Например, BaseCamp - довольно ужасный трекер ошибок (потому что он предназначен для управления проектами), но люди на самом деле хотят его использовать.
Поскольку используемые нами средства отслеживания ошибок не поддерживают копирование и вставку изображений, я на самом деле написал тривиальную программу, которая копирует текущее изображение буфера обмена на диск (как Guid), а затем копирует Guid в буфер обмена. После минимального обучения пользователь может прикреплять изображения буфера обмена к проблемам, просто нажимая на экран печати, нажимая кнопку, а затем вставляя в диалоговое окно выбора файлов инструмента отправки ошибок.
Снимок экрана (возможно, отредактированный в MS Paint с аннотациями) и 1-2 предложения достаточно, чтобы определить большинство функций / ошибок.
Оба эти предложения нацелены на точки трения, которые я испытал, и оба эти предложения увеличили количество сообщений более чем в 10 раз. Однако вам нужно нацеливать свои собственные точки трения.
источник
Сделайте тестирование для вашего клиента легким, но сделайте так, чтобы вашему клиенту было очень трудно использовать какие-либо новые функции в непроверенной версии в производстве. Это можно сделать следующим образом:
Всякий раз, когда вы предоставляете новую функцию, вы сначала внедряете ее в «бета-версию», четко помеченную знаком «не для производства». Вы делаете эту бета-версию доступной для тестирования клиенту. Вы также предоставляете последнюю «рабочую версию», которую он будет использовать для реальной работы (без новых функций, но с последними исправлениями ошибок), и вы отказываетесь переносить новые бета-функции в рабочую версию, пока не получите отзыв о том, что кто-то клиентская сторона по крайней мере попробовала это сначала.
Если клиент начинает использовать бета-версию на своих реальных производственных данных, хотя он всегда показывает большое сообщение «Не для производственного использования» всякий раз, когда он запускает программу, вы не можете ему помочь, но по крайней мере вы дали понять, что всякий раз, когда он теряет производство работать, потому что он использовал бета-версию для неправильных целей, что это явно его вина. Если клиент не извлекает уроки из этого, вы можете отключить возможность использования клиентом «бета» в производственной среде, отключив некоторые важные функции, такие как сохранение результатов на диск в «бета», если это необходимо.
Предоставление отдельной «беты» заставит вас установить надлежащий контроль версий / управление конфигурацией, чтобы вы могли без проблем управлять производственным отделением и отделом бета-тестирования. Но так как вы работаете с Github, я думаю, вы уже используете что-то вроде GIT, что делает этот вид управления очень простым.
источник