Комментарии 25
Всегда?
Помимо минусов есть и плюс, если программист на саппорте получает горячие багрепорты.
Это только в том случае, если багрепорты не в том виде, когда хочется обратившегося послать кое куда, чтобы там медведи делали с посылаемым кое что.
Общение программиста с конечным пользователем часто может открыть глаза на качество и удобство продукта, понимать для кого пишется код, но делать регулярные дежурства это просто нецелесообразно.
А в чём смысл статьи? В том что программист и саппорт бывают в одном лице?
Странная какая-то статья. Я — один из двух программистов на одном проекте и один из трёх на втором, конкретные технические проблемы конечных пользователей предпочитаю решаю сам — постоянно мониторю почтовый ящик, куда падают багрепорты. Вижу, что где плохо работает, исправляю. Вижу, что люди просят, расставляю приоритеты. Повозможности сразу же исправляю ошибки и отправляю тому, кто зарепортил, новую версию программы. В итоге у меня половина пользовательской базы — добровольные бета-пользователи :)
Лучше программиста никто не знает проект и не разберётся в проблеме, и уж тем более не исправит. Меня иногда начинает напрягать, когда на письма отвечаю весь день и не пишу ни строчки кода, но всё равно не жалуюсь. Это не вызывает сильного неприятия.
Лучше программиста никто не знает проект и не разберётся в проблеме, и уж тем более не исправит. Меня иногда начинает напрягать, когда на письма отвечаю весь день и не пишу ни строчки кода, но всё равно не жалуюсь. Это не вызывает сильного неприятия.
Предположим, вы устроитесь в Microsoft разрабатывать Excel.
Сколько багов вы успеете починить, если будете читать почтовый ящик с жалобами пользователей Microsoft Excel и разбираться с ними?
Сколько жалоб из обработанных вами окажутся именно багами Excel, а не безграмотностью пользователей?
Все, написанное в статье просто описывает среднюю ситуацию по больнице — понятно, что нужно смотреть по конкретному проекту, его задачам и масштабам.
Сколько багов вы успеете починить, если будете читать почтовый ящик с жалобами пользователей Microsoft Excel и разбираться с ними?
Сколько жалоб из обработанных вами окажутся именно багами Excel, а не безграмотностью пользователей?
Все, написанное в статье просто описывает среднюю ситуацию по больнице — понятно, что нужно смотреть по конкретному проекту, его задачам и масштабам.
В моей практике 8 из 10 — безграмотность. Хорошо бы иметь отдельного человека на такие случаи, конечно. Но он должен очень хорошо знать проект.
Совсем не обязательно.
Если клиентов очень много, а софт не 1-2 страничный сайт, то есть огромное количество простых вопросов, на которые может отвечать специально тренированный студент, и перенаправлять сложные вопросы на следующий уровень поддержки.
Вплоть до того, что на определенном уровне поддержка будет разбираться с проблемой на уровне воспроизведения проблемы у себя локально, и создавать баг в багтрекере со скриншотами и описанием, так что клиент вообще никогда не будет контактировать лично с разработчиками.
В крупном проекте, даже мегаразработчик может не знать ВЕСЬ проект очень хорошо.
А в мелком проекте весь проект очень хорошо знать, разрабатывать и поддерживать может сам царь директор, из которого состоит вся компания.
Если клиентов очень много, а софт не 1-2 страничный сайт, то есть огромное количество простых вопросов, на которые может отвечать специально тренированный студент, и перенаправлять сложные вопросы на следующий уровень поддержки.
Вплоть до того, что на определенном уровне поддержка будет разбираться с проблемой на уровне воспроизведения проблемы у себя локально, и создавать баг в багтрекере со скриншотами и описанием, так что клиент вообще никогда не будет контактировать лично с разработчиками.
В крупном проекте, даже мегаразработчик может не знать ВЕСЬ проект очень хорошо.
А в мелком проекте весь проект очень хорошо знать, разрабатывать и поддерживать может сам царь директор, из которого состоит вся компания.
Совершенно согласен, что нужна многоуровневая поддержка, и чем сложнее проект — тем больше уровней. Первый уровень — это отдельный человек для сортировки багрепортов и решения простейших проблем. А я, получается, — на уровне 0.
Но конкретно в моей компании в 10% случаев (которые не безграмотность) только я и могу разобраться. Плюс — преимущества прямого контакта с конечным пользователем.
Зарекаться не буду, но планирую и впредь работать исключительно в маленьких продуктовых компаниях.
Но конкретно в моей компании в 10% случаев (которые не безграмотность) только я и могу разобраться. Плюс — преимущества прямого контакта с конечным пользователем.
Зарекаться не буду, но планирую и впредь работать исключительно в маленьких продуктовых компаниях.
«Плюс — преимущества прямого контакта с конечным пользователем.»
Хм. А в чем состоит такое преимущество, если вы не являетесь совладельцем компании, и не влияете на рост продаж софта?
Если только в том, что не нужно нанимать дополнительного сотрудника, и за этот счет можно увеличить ЗП — то да.
А так — грамотный саппортер, который пообщается с клиентом, поговорит по душам, создаст в багтрекере четко описанный баг со скриншотами и описанием, и разработчик потратит на изучение бага не 1 час разговоров, а 5 минут чтения тикета — по-моему в этом преимущества лучше?
Хм. А в чем состоит такое преимущество, если вы не являетесь совладельцем компании, и не влияете на рост продаж софта?
Если только в том, что не нужно нанимать дополнительного сотрудника, и за этот счет можно увеличить ЗП — то да.
А так — грамотный саппортер, который пообщается с клиентом, поговорит по душам, создаст в багтрекере четко описанный баг со скриншотами и описанием, и разработчик потратит на изучение бага не 1 час разговоров, а 5 минут чтения тикета — по-моему в этом преимущества лучше?
Это если в Microsoft, но у нас зачастую это конторы/отделы в 2-5 разработчика, где нет возможности выделить отдельный сапорт.
Полезно только если в наказание — чтобы меньше багов делать(
Любому разработчику нужно понимать, что он выпускает продукт и им будут пользоваться люди.
А мне иногда даже нравится.
Я думаю ощущения сильно зависят от того какой проект, какие пользователи.
Прямой контакт может дать очень много.
Я думаю ощущения сильно зависят от того какой проект, какие пользователи.
Прямой контакт может дать очень много.
Когда программист пользуется творением других программистов. И вместо того, что бы получить грамотную поддержку того, за что он заплатил деньги, ему посылают совершенно некомпетентных менеджеров, которые только и могут кидаться фразами типа: «я это уточню у наших инженеров, подождите». И в конечном итоге между двумя программистами стоит это нечто. Понятно что программисту работать на поддержке не легко, но когда этот программист не может решить проблему через менеджера, а политика компании не позволяет общаться с ним на прямую, то появляется дикое желание разбить кому-то лицо. И этот кто-то далеко не 1 человек. Пример из жизни, уже 2 недели нас отсылают к совершенно разного рода проблемам, которых на нашей стороне нет и быть не может. И вместо того что бы работать над чем-то своим — я уже две недели пытаюсь заставить этих кретинов хоть как-то шевелиться. В ответ всегда, я вам напишу или перезвоню и опять по новой. И начинаешь каждому новому менеджеру рассказывать проблему, которой он не понимает и понимать не хочет. Так что у статьи есть обратная сторона медали.
Ведущим просто необходимо заниматься тех. поддержкой. Это позволит «почувствовать» всю боль пользователя. На практике очень часто сталкивался с тем, что команда пишет софт без детального понимания того, как продуктом пользуются люди. В результате образуется пропасть между представлением в головах и реальным использованием.
На практике очень часто сталкивался с тем, что команда пишет софт без детального понимания того, как продуктом пользуются люди.
Но это вообще-то работа продакт-менеджера, архитектора и UX, но никак не рядового кодера.
Вы просто априори думаете что большая доля запросов в техподдержку это запросы качающиеся программы а не вцелом тупизны пользователя. А это не всегда так.
Иногда из-за специфики программы — ей пользуются в основном более менее компетентные люди, которые могут сформулировать. А бывает и случаи — что шквал обращений в службу поддержи будут: с темой обращения не соответствующему проблеме, запросы от людей переспрашивающих «а www тоже писать?» и еще с кучей путаницы — которая не принесет разработчику «баг-репорт» — а будет еще одним «расследованием» — которое нужно будет проводить… :(
Иногда из-за специфики программы — ей пользуются в основном более менее компетентные люди, которые могут сформулировать. А бывает и случаи — что шквал обращений в службу поддержи будут: с темой обращения не соответствующему проблеме, запросы от людей переспрашивающих «а www тоже писать?» и еще с кучей путаницы — которая не принесет разработчику «баг-репорт» — а будет еще одним «расследованием» — которое нужно будет проводить… :(
НЛО прилетело и опубликовало эту надпись здесь
Кто-то поддерживает, а кто-то держит. Кто-то многозадачный, кто-то нет. Кому-то вредно, а кому-то полезно. Кто-то тыжпрограммист, а кто-то объясняет кто он по профессии и призванию. Развели понимаешь ромашка…
Прочитал наискосок, потом внимательнее и всё-равно не понял мысли автора.
В нормальной компании-вендоре ПО всегда есть специальный отдел ТП, в котором как минимум 1 линия, а часто и 2 и, даже, 3.
И если инцидент доходит до разработчика, то часто уже в виде конкретного проблемного поведения, которое надо исправить ( т.е. ему поступает максимум информации о проблеме: логи, полученные отделом ТП, привычное описание ошибки от тестера, описание правильно работающего функционала от бизнес-аналитика) — т.е. часто он решает не только инцидент, но и проблему
И разработчик НИКОГДА не общается напрямую с клиентом
Если в компании достаточно большой и сложный продукт, а разработчики напрямую общаются с клиентом и нет специально обученных инженеров ТП, то и все остальные процессы в компании вряд ли хорошо организованы, кроме продаж =)
А если в компании 2 разработчика, 1 тестер и 3 менеджера, то тогда разработчик мастер на все руки и разработчик должен понимать, что клиенты рядом и он будет общаться с ними, решая их проблемы.
С другой стороны, если разработчик не решает в том или ином виде проблемы клиента, особенно если он ведущий/старший и т.п. — то есть риск, что он будет жить в своём мире, совершенно не представляя, как клиенты используют и как они МОГУТ использовать продукт.
В нормальной компании-вендоре ПО всегда есть специальный отдел ТП, в котором как минимум 1 линия, а часто и 2 и, даже, 3.
И если инцидент доходит до разработчика, то часто уже в виде конкретного проблемного поведения, которое надо исправить ( т.е. ему поступает максимум информации о проблеме: логи, полученные отделом ТП, привычное описание ошибки от тестера, описание правильно работающего функционала от бизнес-аналитика) — т.е. часто он решает не только инцидент, но и проблему
И разработчик НИКОГДА не общается напрямую с клиентом
Если в компании достаточно большой и сложный продукт, а разработчики напрямую общаются с клиентом и нет специально обученных инженеров ТП, то и все остальные процессы в компании вряд ли хорошо организованы, кроме продаж =)
А если в компании 2 разработчика, 1 тестер и 3 менеджера, то тогда разработчик мастер на все руки и разработчик должен понимать, что клиенты рядом и он будет общаться с ними, решая их проблемы.
С другой стороны, если разработчик не решает в том или ином виде проблемы клиента, особенно если он ведущий/старший и т.п. — то есть риск, что он будет жить в своём мире, совершенно не представляя, как клиенты используют и как они МОГУТ использовать продукт.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Когда разработчику вредно совмещать программирование и техническую поддержку ПО