Pull to refresh

Comments 3

Статья на 5+, по моему личному мнению. Надо давать читать как клиентам, так и сотрудникам IT контор. Доводилось работать с одним сайтом, который делала команда, ну, как умела, при минимальном бюджете и мега-придирчивом заказчике. Сделали, вроде приняли работу и даже оплатили.Техподдержку решили отдать другой компании, не той, что делала проект и знала его особенности. Но! У конторы-заказчика есть свой IT отдел. Правда, сайт он не поддерживает, но сервера — в их компетенции. Так вот, чтобы техподдержка могла что-то сделать с сайтом, им надо написать ребятам заказчика, которые, может быть, сразу дадут доступ к серверу. А может, и через пару часов дадут… В итоге создается видимость того, что техподдержка работает плохо и медленно… Все недовольны… Такой вот испорченный телефон, которого можно было бы запросто избежать, используя описанные выше методы.
техническая поддержка — это боль и слёзы рынка веб-разработки. Самые слёзные жалобы к нам поступают с просьбой забрать какой-то проект на доделки.
Сначала слёзно просят, потом просто просят, потом требуют и недовольны.
Если заказчик адекватный — его не бросают. А раз он переходит в другую организацию, то тут можно задуматься.
«Желание творить крупными мазками, а не кропотливо доводить детали.» — это пять :)

Из своей практики: есть проблема перекоса объема задач в сторону поддержки из-за большого количества проектов из прошлогопри. при этом есть один-два вновь разрабатываемых проектов, и всё это в рамках одной команды разработчиков. Планирование, оценки часто-густо теряют смысл из-за непрогнозируемого количества тикетов и мелких запросов. Актуальным решением может быть создание отдельных команд или одной команды тех поддержки. Но здесь проблема — документации, кроме начальных документов, на проектах нет. Вот здесь и возникает вопрос: «Что делать?».
Sign up to leave a comment.

Articles