?

Log in

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:34 (UTC) (Link)
Либо придумать, как изменить их подход к работе, чтобы от них была польза.

Например, их обязанности можно попробовать "склеить" с технической поддержкой. Это неплохое сочетание.
Lost In Paradox
localstorm at 2011-06-19 12:36 (UTC) (Link)
Знаю, такой опыт есть. Пока не получается, ибо смотреть в код не хотят. А зачастую -- это единственный способ ответить на вопрос "почему".
Gaperton
gaperton at 2011-06-19 12:44 (UTC) (Link)
В таких случаях техподдержка открывает на разработку в трекере тикет типа "исследование" или "вопрос", который связан с тикетом, соответствующим вопросу пользователя. В котором внятно формулирует вопрос. Не надо ей уметь код читать.

Использование трекера радикально упрощает горизонтальное взаимодействие разных команд.
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. Они дают нам сайнофф и мы идем в лайв.
Lost In Paradox
localstorm at 2011-06-19 12:49 (UTC) (Link)
Теоретически -- все так. На практике у меня есть две саппорт команды первого и второго уровня, которые сами практически ничего не делают, кроме эскалации до девелопмента. Это при том, что мы им написали очень подробное руководство по эксплуатации, написали как исследовать логи, написали FAQ, написали примеры алёртов и что они значат... Но вот хрен бы там, часто все равно проваливается на нас то, что они сами могут делать.

Это просто в качестве иллюстрации, что саппорт -- это тоже нетривиально и просто так каких-то людей на него не посадишь. В т.ч. QA. Как, например, они будут работать под давлением со стороны бизнеса, мне не очень понятно.
Gaperton
gaperton at 2011-06-19 12:57 (UTC) (Link)
> На практике у меня есть две саппорт команды первого и второго уровня, которые сами практически ничего не делают, кроме эскалации до девелопмента.

Они не консультируют пользователя по непонятным вопросам?

Они не пытаются воспроизводить ошибки, которые появились у пользователя, чтобы их локализовать, и не задают пользователю допвопросов?

Они не умеют отличать Severity, и прописывать его в переданную ошибку?

Они не тестируют исправления ошибок и доработки, которые они передали в разработку?

Они не сообщают пользователю, что все ок, и он может проверять?

Если они не делают перечисленного, то это странная какая-то поддержка. Надо там руководителя заменить.

Если делают - то это уже немало, на самом деле.

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

Ну так можно на это посмотреть. :)
Lost In Paradox
localstorm at 2011-06-19 13:01 (UTC) (Link)
хе-хе. Да надо бы кого-нибудь заменить, это факт.

Ну там северити обычно определяется по тайтлам людей, которые пришли в саппорт. Если это Managing Director, то это catastrophe :)) Ну а если серьезно, то для них есть два северити -- "будим разработчика ночью" и "подождет до утра".
Gaperton
gaperton at 2011-06-19 12:59 (UTC) (Link)
А вообще поддержка еще много чего может делать.

Например - проводит регламентные процедуры на серверах. Выполняет простую админку - пользователя завести, права раздать. Мониторят производительность и состояние серверов. Уведомляют пользователей о сбоях и регламентных процедурах.
Lost In Paradox
localstorm at 2011-06-19 13:01 (UTC) (Link)
Вот кстати все из перечисленного тут они делают. Нужно отдать должное.
Previous Entry  Next Entry