?

Log in

No account? Create an account
November 2016   01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30
cartoon

Миф о документации, продолжение

Posted on 2011.06.18 at 23:06

Comments:


Gaperton
gaperton at 2011-06-19 12:49 (UTC) (Link)
Такая практика, вообще, нормальна. У поддержки должно быть несколько уровней. Смысл первого уровня в том, чтобы фильтровать простые и типовые вопросы. Смысл последнего уровня - разбирать совсем ацкие вещи, которые никто не смог решить, обычно это лучшие разработчики или архитектора.

Если какой-то уровень не в состоянии обработать запрос - он запрашивает следующий уровень.

К примеру, наша техподдержка первой линии не умеет читать код, что не мешает ей обрабатывать 75-80% всех обращений пользователей самостоятельно.
Lost In Paradox
localstorm at 2011-06-19 12:53 (UTC) (Link)
Да, это понятно. Но это идеал. Куда как проще свалить все на разработчика. И если нет инициативы со стороны самой команды саппорта в том, чтобы действительно прошарить и приносить пользу, то сдвинуть ситуацию с мертвой точки со стороны разработчиков бывает трудно.

Если же перед третьим уровнем саппорта (собственно девелоперы), воткнуть ещё QA, то либо они действительно должны делать классно эту работу, либо к разработчику будет приходить проблема за проблемой, а время ответа пользователю увеличится. Потому что на каждом уровне есть свой пайплайн, свои приоритеты, свои нехватки по ресурсам.
Gaperton
gaperton at 2011-06-19 13:02 (UTC) (Link)
> Если же перед третьим уровнем саппорта (собственно девелоперы), воткнуть ещё QA, то либо они действительно должны делать классно эту работу...

Перед третьим втыкать QA не надо. Слишком много уровней получится, маразм какой-то. Их можно слить со вторым уровнем, расширив его полномочия.

Хотя я понятия не имею, почему именно их там у вас два перед разработчиками, а не один.
Lost In Paradox
localstorm at 2011-06-19 13:05 (UTC) (Link)
Да я согласен, что второй, что первый -- один хрен. Но так уж повелось, кто я такой, чтобы клиенту говорить, что у него есть лишние сотрудники. Плюс к тому, второй уровень каверит вроде как больше приложений, в то время как есть несколько команд первого уровня, которые каверят разные бизнеслайны.

Все весьма запутанно, согласен. То бишь фичка в чем? Саппорт на стороне клиента, а девелопмент и QA внешние.
Gaperton
gaperton at 2011-06-19 13:08 (UTC) (Link)
Ясно. Тогда можно попробовать QA поставить в качестве первой линии у себя. Чтобы они ошибки воспроизводили и локализовывали, перед тем, как программеров дергать. И - тестировали их исправление.

Всяко польза будет. Наверно. ХЗ на самом деле :).
Lost In Paradox
localstorm at 2011-06-19 13:09 (UTC) (Link)
Ага. Сам вот чешу лоб..
Gaperton
gaperton at 2011-06-19 13:16 (UTC) (Link)
По крайней мере, так они хотя-бы исправление ошибки протестировать будут в состоянии. В противном случае - это невозможно, не смогут толком.

Кроме того, ты сможешь поручить им составление иерархического фичлиста (на верхнем уровне - независимые группы функций), и собрать статистику, скока где каких ошибок, ну хоть примерно.

После чего, они смогут помочь с разработкой тест-плана на автоматическую регрессию, будет достаточно информации.

Естественно, они не перестают тестировать новые фичи.

Я бы попробовал.
Lost In Paradox
localstorm at 2011-06-19 13:22 (UTC) (Link)
Ну саппорт запрягать смысла тут точно нет. Как я уже говорил, не шарят они. Не могут составить они никакого списка фич, потому что пользователи приходят к ним, тычут в какие-то свои проги и говорят, что ничерта данные из системы не идут в другую систему.

На что саппорт понимает, откуда и куда должны были идти данные и вспоминает, что софт, который за это отвечает -- мой. Дальше -- понятно.

То есть фичи в терминах моей софтины им восстановить сложно. Как впрочем и нам. Но мы хоть код посмотреть можем.

А исправления тестируют сами пользователи. Называем мы это UAT. Они дают нам сайнофф и мы идем в лайв.
Previous Entry  Next Entry