- PVSM.RU - https://www.pvsm.ru -
Качество должно быть на первом месте при работе над проектом, если вы хотите, чтобы люди пользовались вашими услугами и высоко их оценивали. За качество ответственен каждый член вашей команды — работа людей, которые создают сервис, определяет его качество. Каждый сотрудник, который трудится над вашим проектом, должен способствовать максимальному увеличению качества и решению возникающих проблем.
Разными людьми в команде качество будет пониматься по-разному. В целом качество — это уровень обслуживания пользователей, от начала транзакции до ее завершения, что включает в себя:
«Технический долг» — это популярный термин в сфере разработки программного обеспечения, и у него есть множество определений. В целом, «техническим долгом» обычно называют компромиссные решения, принимаемые для завершения разработки программного продукта, когда нет возможности сделать это должным образом. Это означает, что требуется некоторая доработка, несмотря на то, что создание программы в целом завершено.
Невозможно разработать программу, не накопив «технического долга», поэтому люди вашей команды должны делиться друг с другом опытом правильной его обработки. Большой объем «технического долга» будет замедлять дальнейшую работу над проектом. Вам необходимо знать его объем для организации своей работы таким образом, чтобы сократить его и постепенно уменьшать в будущем.
Качество обслуживания играет роль не только при тестировании программного продукта. Также за качество отвечает не какая-то малая группа сотрудников. Качество любой системы обеспечивается людьми, которые ее создают.
Ваши сотрудники должны уметь замечать любые возникающие проблемы качества вашей системы. Каждый из них должен способствовать повышению качества и решению проблем.
Вы не сможете понять, насколько удачен ваш программный продукт, и отвечает ли он вашим требованиям, не проведя тестирование — как при нормальных, так и при нестандартных условиях работы. Стоит ознакомиться с книгой Дилана Роберта «Learning From First Responders [2]», чтобы узнать, как проводится тестирование программного обеспечения и проверка работы команды в условиях высоких нагрузок (в данном случае, во время завершающего этапа президентских выборов 2012 года).
За качество любых цифровых услуг отвечают все члены команды, однако окончательная ответственность лежит на сервис-менеджере. Важно чтобы он непосредственно взаимодействовал с остальной частью команды. В противном случае существует риск того, что ваши сотрудники не будут понимать, какие меры им необходимо предпринимать для обеспечения качества. Вашим сотрудникам необходимо учитывать вопросы качества при составлении пользовательских историй и использовать время и ресурсы для:
Привлечение специалистов и использование специальных инструментов очень полезно для обеспечения эффективности тестирования и уместно при тестировании защиты от несанкционированного доступа — привлечение сотрудников, не входящих в команду разработчиков для выполнения этой задачи позволяет проверить эффективность решений и выявить слабости системы, предоставляя полезный взгляд на проблемы со стороны.
И приеме на работу специалистов по обеспечению гарантии качества — они смогут правильно скоординировать все мероприятия, связанные с качеством, организовать систему тренингов и предоставления ресурсов, необходимых для создания высококачественного обслуживания, путем:
Мы обсудили данный материал с рядом стартапов Акселератора ФРИИ [3]:
Вопросы: Как вы работаете с техническим долгом? Используете ли вы это понятие в работе над своим проектом? Если да, то как вы подсчитываете его объем? Существуют ли какие-то особенные внутрикомандные правила по его ликвидации?
Сейчас мы сталкиваемся с более незначительными «техническими долгами». Все необходимые функции и доработки мы описываем в Assembla и разбиваем все по релизам. То, что можно реализовать на существующей платформе мы делаем, что-то решаем «костылями», если это нужно сделать быстрее. Но есть ряд тех «долгов», которые остаются и ждут нового релиза с переписыванием логики.
Обычно все делается иначе – просто пишутся «костыли», которые позволяют проекту держаться, но при наборе критической массы этих костылей всё равно делается рефакторинг, что в итоге достаточно дорого.
Наши публикации на основе материалов Gov.uk:
Автор: frii_fond
Источник [8]
Сайт-источник PVSM.RU: https://www.pvsm.ru
Путь до страницы источника: https://www.pvsm.ru/agile/86697
Ссылки в тексте:
[1] Image: http://megamozg.ru/company/friifond/blog/11574/
[2] Learning From First Responders: http://www.oreilly.com/webops-perf/free/learning-from-first-responders.csp
[3] Акселератора ФРИИ: http://www.iidf.ru/startups/accel/
[4] Работаем с User stories: Руководство Gov.uk: http://megamozg.ru/company/friifond/blog/8686/
[5] Gov.uk: базовые аспекты методологии agile: http://habrahabr.ru/company/friifond/blog/243723/
[6] Проектирование продукта с ориентацией на пользователя: http://habrahabr.ru/company/friifond/blog/243099/
[7] Управление ретроспективой или взгляд в прошлое: http://megamozg.ru/company/friifond/blog/10870/
[8] Источник: http://megamozg.ru/post/11574/
Нажмите здесь для печати.