Что понимается под этим словом, как оценить качество и как его поддерживать.
Качество должно быть на первом месте при работе над проектом, если вы хотите, чтобы люди пользовались вашими услугами и высоко их оценивали. За качество ответственен каждый член вашей команды — работа людей, которые создают сервис, определяет его качество. Каждый сотрудник, который трудится над вашим проектом, должен способствовать максимальному увеличению качества и решению возникающих проблем.
Определение качества
Разными людьми в команде качество будет пониматься по-разному. В целом качество — это уровень обслуживания пользователей, от начала транзакции до ее завершения, что включает в себя:
- Обеспечение доступа для (максимально широкого круга) пользователей к оптимальному набору устройств.
- Достаточную простоту использования того или иного устройства
- Возможность максимально быстро предоставлять техническую и информационную поддержку пользователям
- Безопасность и удобство хранения, а также использования данных
- Эффективность и безопасность основного программного обеспечения и ИТ-инфраструктуры.
- Полную работоспособность программного кода.
- Высокую скорость работы сервиса при взаимодействии с большим количеством пользователей одновременно (необходимо тестирование нагрузки).
- Наличие всех условий для быстрого повышения возможностей сервиса при необходимости обработки большего объема трафика.
- Возможность команды быстро добавлять или редактировать функциональные возможности сервиса в соответствии с изменениями требований или настроек.
Пара слов о «техническом долге»
«Технический долг» — это популярный термин в сфере разработки программного обеспечения, и у него есть множество определений. В целом, «техническим долгом» обычно называют компромиссные решения, принимаемые для завершения разработки программного продукта, когда нет возможности сделать это должным образом. Это означает, что требуется некоторая доработка, несмотря на то, что создание программы в целом завершено.
Невозможно разработать программу, не накопив «технического долга», поэтому люди вашей команды должны делиться друг с другом опытом правильной его обработки. Большой объем «технического долга» будет замедлять дальнейшую работу над проектом. Вам необходимо знать его объем для организации своей работы таким образом, чтобы сократить его и постепенно уменьшать в будущем.
За качество ответственны все
Качество обслуживания играет роль не только при тестировании программного продукта. Также за качество отвечает не какая-то малая группа сотрудников. Качество любой системы обеспечивается людьми, которые ее создают.
Ваши сотрудники должны уметь замечать любые возникающие проблемы качества вашей системы. Каждый из них должен способствовать повышению качества и решению проблем.
Вы не сможете понять, насколько удачен ваш программный продукт, и отвечает ли он вашим требованиям, не проведя тестирование — как при нормальных, так и при нестандартных условиях работы. Стоит ознакомиться с книгой Дилана Роберта «Learning From First Responders», чтобы узнать, как проводится тестирование программного обеспечения и проверка работы команды в условиях высоких нагрузок (в данном случае, во время завершающего этапа президентских выборов 2012 года).
За качество любых цифровых услуг отвечают все члены команды, однако окончательная ответственность лежит на сервис-менеджере. Важно чтобы он непосредственно взаимодействовал с остальной частью команды. В противном случае существует риск того, что ваши сотрудники не будут понимать, какие меры им необходимо предпринимать для обеспечения качества. Вашим сотрудникам необходимо учитывать вопросы качества при составлении пользовательских историй и использовать время и ресурсы для:
- тестирования создаваемой программы;
- упрощения программы и регулярной проверки ее доступности для пользователей;
- анализа сценариев возникновения ошибок и разработки плана необходимых действий.
Привлечение специалистов и использование специальных инструментов очень полезно для обеспечения эффективности тестирования и уместно при тестировании защиты от несанкционированного доступа — привлечение сотрудников, не входящих в команду разработчиков для выполнения этой задачи позволяет проверить эффективность решений и выявить слабости системы, предоставляя полезный взгляд на проблемы со стороны.
И приеме на работу специалистов по обеспечению гарантии качества — они смогут правильно скоординировать все мероприятия, связанные с качеством, организовать систему тренингов и предоставления ресурсов, необходимых для создания высококачественного обслуживания, путем:
- принятия на себя конкретных обязанностей и взаимодействия с командой, и таким образом, повышения качества всего, что они делают, вместо того, чтобы просто проводить оценку хода выполнения проекта в контрольных точках.
- принятия на себя обязанностей лишь на короткое время и предоставления вашим сотрудникам возможности самим управлять качеством в рамках стандартного процесса разработки и улучшения сервиса.
Мы обсудили данный материал с рядом стартапов Акселератора ФРИИ:
Вопросы: Как вы работаете с техническим долгом? Используете ли вы это понятие в работе над своим проектом? Если да, то как вы подсчитываете его объем? Существуют ли какие-то особенные внутрикомандные правила по его ликвидации?
Сейчас мы сталкиваемся с более незначительными «техническими долгами». Все необходимые функции и доработки мы описываем в Assembla и разбиваем все по релизам. То, что можно реализовать на существующей платформе мы делаем, что-то решаем «костылями», если это нужно сделать быстрее. Но есть ряд тех «долгов», которые остаются и ждут нового релиза с переписыванием логики.
Обычно все делается иначе – просто пишутся «костыли», которые позволяют проекту держаться, но при наборе критической массы этих костылей всё равно делается рефакторинг, что в итоге достаточно дорого.
Наши публикации на основе материалов Gov.uk:
- Работаем с User stories: Руководство Gov.uk
- Gov.uk: базовые аспекты методологии agile
- Проектирование продукта с ориентацией на пользователя
- Управление ретроспективой или взгляд в прошлое
Автор: frii_fond
