Что подразумевается под этим словом, как оценить качество и как его сохранить.
Качество должно стоять на первом месте при работе над проектом, если вы хотите, чтобы люди пользовались вашими услугами и ценили их.
Каждый член вашей команды несет ответственность за качество — труд людей, создающих сервис, определяет его качество.
Каждый сотрудник, работающий над вашим проектом, должен способствовать максимизации качества и решению возникающих проблем.
Определение качества
Качество будет по-разному пониматься разными людьми в команде.В целом качество — это уровень пользовательского опыта от начала транзакции до ее завершения, который включает в себя:
- Обеспечение доступа (самого широкого круга) пользователей к оптимальному набору устройств.
- Достаточное удобство использования конкретного устройства
- Возможность максимально быстрого оказания технической и информационной поддержки пользователям.
- Безопасность и простота хранения и использования данных
- Эффективность и безопасность основного программного обеспечения и ИТ-инфраструктуры.
- Полная функциональность программного кода.
- Высокая скорость работы сервиса при одновременном взаимодействии с большим количеством пользователей (необходимо нагрузочное тестирование).
- Наличие всех условий для быстрого увеличения возможностей сервиса при необходимости обработки большего объема трафика.
- Возможность команды быстро добавлять или редактировать функционал сервиса в соответствии с изменениями требований или настроек.
Несколько слов о «техническом долге»
«Технический долг» — популярный термин в индустрии разработки программного обеспечения, и он имеет множество определений.В общем, «технический долг» обычно относится к компромиссам, на которые приходится идти для завершения разработки программного продукта, когда нет возможности сделать это должным образом.
Это означает, что требуется некоторая работа, даже если программа в целом завершена.
Невозможно разрабатывать программное обеспечение без накопления технического долга, поэтому члены вашей команды должны делиться друг с другом своим опытом правильного обращения с ним.
Большой объем «технического долга» замедлит дальнейшую работу над проектом.
Вам необходимо знать его объем, чтобы организовать свою работу таким образом, чтобы сократить его и постепенно сокращать в дальнейшем.
Каждый несет ответственность за качество
Качество обслуживания играет роль не только при тестировании программного продукта.Кроме того, качество – это ответственность не только небольшой группы сотрудников.
Качество любой системы обеспечивают люди, которые ее создают. Ваши сотрудники должны быть в состоянии обнаружить любые возникающие проблемы с качеством вашей системы.
Каждый из них должен способствовать улучшению качества и решению проблем.
Вы не сможете понять, насколько успешен ваш программный продукт и соответствует ли он вашим требованиям, не протестировав его – как в нормальных, так и в нестандартных условиях эксплуатации.
Стоит прочитать книгу Дилана Роберта.
Обучение у служб быстрого реагирования ", чтобы узнать, как осуществляется тестирование программного обеспечения и производительность команды в условиях высокой нагрузки (в данном случае, на заключительном этапе президентских выборов 2012 года).
Все члены команды несут ответственность за качество любых цифровых услуг, но окончательная ответственность лежит на менеджере сервиса.
Важно, чтобы он напрямую взаимодействовал с остальной частью команды.
В противном случае есть риск, что ваши сотрудники не поймут, какие меры им необходимо предпринять для обеспечения качества.
Вашим сотрудникам необходимо учитывать вопросы качества при написании пользовательских историй и использовать время и ресурсы для:
- тестирование созданной программы;
- упрощение программы и регулярная проверка ее доступности для пользователей;
- анализ сценариев ошибок и разработка плана необходимых действий.
, предоставляя полезный взгляд на проблемы со стороны.
А при приеме на работу специалистов по обеспечению качества они смогут должным образом координировать всю деятельность, связанную с качеством, организовать систему обучения и предоставить ресурсы, необходимые для создания качественного сервиса путем:
- брать на себя конкретные обязанности и взаимодействовать с командой и, таким образом, улучшать качество всего, что они делают, а не просто оценивать ход проекта по контрольным точкам.
- брать на себя обязанности лишь на короткий период времени и позволять вашим сотрудникам самостоятельно управлять качеством в рамках стандартного процесса разработки и улучшения услуг.
Акселератор ФРИИ : Вопросы: Как вы справляетесь с техническим долгом? Используете ли вы эту концепцию в работе над своим проектом? Если да, то как рассчитать его объем? Есть ли какие-то особые внутренние правила команды по его устранению? Дмитрий Соколов, основатель и руководитель проекта Pocket.DJ Технический директор продумывает реализацию задач таким образом, чтобы минимизировать технический долг.
Он несет за это личную ответственность и контролирует это.
Каждый 20-й и 21-й рабочий день посвящен рефакторингу.
Если опасность технического долга видна заранее, технический директор обязан уведомить об этом команду при планировании сроков.
Алексей Федорищев, руководитель проекта HappyCart.co Я думаю, это маркетинговый ход. Нам проще измерять в «фичах» и отслеживать их реализацию.
Про ответственность за качество: да, она универсальная (как и положено стартапу из 4-7 человек).
А арбитром в вопросах качества является клиент, который голосует своим рублем.
Сергей Свечников, руководитель проекта StartExam Мы не занимаемся техническим долгом.
Коллектив небольшой – в основном не полный рабочий день.
Исходя из этого, мы пока не регулируем подобные правила.
Владимир Ковалёв, основатель проекта Timeviewer Мы его используем, но не называем его так.
Изначально мы с этим столкнулись и были вынуждены переписать и перепроектировать платформу и структуру нашего сервиса.
Для этого мы взяли в команду Игоря Рабиновича, который имеет большой опыт проектирования систем, имеющих сложную логику и способных быстро работать с большим количеством устройств.
Сейчас мы столкнулись с более незначительным «техническим долгом».
Описываем все необходимые функции и улучшения в Assembla с разбивкой по выпускам.
Делаем то, что можно реализовать на существующей платформе, что-то решаем «костылями», если нужно сделать быстрее.
Но ряд «долгов» остался и ждет нового релиза с переписыванием логики.
Александр Калошин, основатель и руководитель проекта Lastbackend У нас высокотехнологичный продукт, и мы не могли сделать его «на скорую руку».
На это есть 2 основные причины: риск при запуске — при наплыве аудитории проекты с техническим долгом имеют огромные риски с возможными провалами и отсутствием устойчивости; и то, что проекты с техническим долгом все равно нужно приводить в порядок и (скорее всего) переписывать с нуля.
В связи с этим было решено немедленно поступить «правильно».
И мы устранили эту проблему до того, как она появилась.
Обычно все делается иначе — просто пишут «костыли», позволяющие проекту держаться, но при достижении критической массы этих костылей все равно делается рефакторинг, что в итоге обходится довольно дорого.
Наши публикации по материалам Gov.uk:
- Работа с историями пользователей: Руководство Gov.uk
- Gov.uk: основные аспекты гибкой методологии
- Дизайн продукта, ориентированный на пользователя
- Ретроспективный менеджмент или взгляд в прошлое
-
Гипотетический Полет К Далеким Мирам
19 Oct, 24 -
Википедия Собирается Обновить Свою Лицензию
19 Oct, 24 -
Релиз Livestreet 0.4
19 Oct, 24 -
Mail.ru Обогнал Rambler По Рентабельности
19 Oct, 24
