Качество: Руководство Gov.uk

Что понимается под этим словом, как оценить качество и как его поддерживать.

Качество: Руководство Gov.uk - 1

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

Определение качества

Разными людьми в команде качество будет пониматься по-разному. В целом качество — это уровень обслуживания пользователей, от начала транзакции до ее завершения, что включает в себя:

  • Обеспечение доступа для (максимально широкого круга) пользователей к оптимальному набору устройств.
  • Достаточную простоту использования того или иного устройства
  • Возможность максимально быстро предоставлять техническую и информационную поддержку пользователям
  • Безопасность и удобство хранения, а также использования данных
  • Эффективность и безопасность основного программного обеспечения и ИТ-инфраструктуры.
  • Полную работоспособность программного кода.
  • Высокую скорость работы сервиса при взаимодействии с большим количеством пользователей одновременно (необходимо тестирование нагрузки).
  • Наличие всех условий для быстрого повышения возможностей сервиса при необходимости обработки большего объема трафика.
  • Возможность команды быстро добавлять или редактировать функциональные возможности сервиса в соответствии с изменениями требований или настроек.

Пара слов о «техническом долге»

«Технический долг» — это популярный термин в сфере разработки программного обеспечения, и у него есть множество определений. В целом, «техническим долгом» обычно называют компромиссные решения, принимаемые для завершения разработки программного продукта, когда нет возможности сделать это должным образом. Это означает, что требуется некоторая доработка, несмотря на то, что создание программы в целом завершено.

Невозможно разработать программу, не накопив «технического долга», поэтому люди вашей команды должны делиться друг с другом опытом правильной его обработки. Большой объем «технического долга» будет замедлять дальнейшую работу над проектом. Вам необходимо знать его объем для организации своей работы таким образом, чтобы сократить его и постепенно уменьшать в будущем.

За качество ответственны все

Качество обслуживания играет роль не только при тестировании программного продукта. Также за качество отвечает не какая-то малая группа сотрудников. Качество любой системы обеспечивается людьми, которые ее создают.
Ваши сотрудники должны уметь замечать любые возникающие проблемы качества вашей системы. Каждый из них должен способствовать повышению качества и решению проблем.

Вы не сможете понять, насколько удачен ваш программный продукт, и отвечает ли он вашим требованиям, не проведя тестирование — как при нормальных, так и при нестандартных условиях работы. Стоит ознакомиться с книгой Дилана Роберта «Learning From First Responders», чтобы узнать, как проводится тестирование программного обеспечения и проверка работы команды в условиях высоких нагрузок (в данном случае, во время завершающего этапа президентских выборов 2012 года).

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

  • тестирования создаваемой программы;
  • упрощения программы и регулярной проверки ее доступности для пользователей;
  • анализа сценариев возникновения ошибок и разработки плана необходимых действий.

Привлечение специалистов и использование специальных инструментов очень полезно для обеспечения эффективности тестирования и уместно при тестировании защиты от несанкционированного доступа — привлечение сотрудников, не входящих в команду разработчиков для выполнения этой задачи позволяет проверить эффективность решений и выявить слабости системы, предоставляя полезный взгляд на проблемы со стороны.

И приеме на работу специалистов по обеспечению гарантии качества — они смогут правильно скоординировать все мероприятия, связанные с качеством, организовать систему тренингов и предоставления ресурсов, необходимых для создания высококачественного обслуживания, путем:

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

Мы обсудили данный материал с рядом стартапов Акселератора ФРИИ:

Вопросы: Как вы работаете с техническим долгом? Используете ли вы это понятие в работе над своим проектом? Если да, то как вы подсчитываете его объем? Существуют ли какие-то особенные внутрикомандные правила по его ликвидации?

Дмитрий Соколов, основатель и руководитель проекта Pocket.DJ

CTO продумывает реализацию задач так, чтобы минимизировать технический долг. Он персонально за него отвечает и он его контролирует. Каждый 20-й и 21-й рабочий день посвящены рефакторингу. Если заранее видно опасность технического долга — CTO обязан уведомить об этом команду при планировании таймлайна.

Алексей Федорищев, руководитель проекта HappyCart.co

Полагаю, что это – маркетинговая штука. Нам проще мерять в «фичах» и отслеживать их реализацию. Про ответственность за качество: да, она всеобщая (как и полагается стартапу из 4-7 человек). И арбитром в вопросах качества выступает клиент, голосующий своим рублем.

Сергей Свечников, руководитель проекта StartExam

Мы не работаем с техническим долгом. Команда небольшая – в основном не full-time. Исходя из этого, пока не регламентируем подобные правила.

Владимир Ковалев, основатель проекта Timeviewer

Пользуемся, но так не называем. Изначально мы столкнулись с этим и вынуждены были заново переписать и спроектировать платформу и структуру нашего сервиса, для этого мы взяли в команду Игоря Рабиновича, у которого большой опыт работы в проектирование систем, которые обладают сложной логикой и умеют оперативно работать с большим количеством устройств.

Сейчас мы сталкиваемся с более незначительными «техническими долгами». Все необходимые функции и доработки мы описываем в Assembla и разбиваем все по релизам. То, что можно реализовать на существующей платформе мы делаем, что-то решаем «костылями», если это нужно сделать быстрее. Но есть ряд тех «долгов», которые остаются и ждут нового релиза с переписыванием логики.

Александр Калошин, основатель и руководитель проекта Lastbackend

У нас высокотехнологичный продукт, и нам нельзя было делать его «наспех». Существует 2 основные причины этому: риск при запуске – при наплыве аудитории, проекты с техническим долгом имеют огромные риски с возможными падениями и отсутствием устойчивости; и тот факт, что проекты с техническим долгом нужно в любом случае приводить в порядок и (скорее всего) переписывать с нуля. Всвязи с этим, было решено сразу делать «правильно». И мы ликвидировали эту проблему до её появления.

Обычно все делается иначе – просто пишутся «костыли», которые позволяют проекту держаться, но при наборе критической массы этих костылей всё равно делается рефакторинг, что в итоге достаточно дорого.

Наши публикации на основе материалов Gov.uk:

Автор: frii_fond

Источник

Оставить комментарий