development vs support

Так получилось, что в компании Индекс-арт я примерно равное время отработала в качестве разработчика программного обеспечения и в качестве сотрудника отдела сопровождения того же программного продукта.  И хотя в обоих случаях запись в моей трудовой книжке гласила, что я — «программист», и  работала я постоянно с одной и той же программой и с одними и теми же клиентами,  тем не менее разница в моей повседневной деятельности оказалось разительной.  Чем же разработка  отличается от саппорта? Какие требования предъявляются к специалистам, занимающимся тем или другим видом деятельности?

Ключевые, как мне кажется, отличия работы в сопровождении от разработки (не в  порядке значимости, а в порядке, удобном мне для изложения):

1. Тесное общение с клиентом.

Разработчик, как правило, имеет дело с техническим заданием, которое предоставил ему менеджер проекта или аналитик или другой сотрудник в штате производителя, отвечающий за донесение в формальном виде требований клиента до конечного исполнителя. Клиента разработчик, вероятнее всего, в глаза не видывал, голоса не слыхивал и как звать не знает. Всё, что есть  у программиста-разрабочика — уже формализованные требования заказчика.

Сотрудник сопровождения в своей ежедневной работе тесно контактирует с клиентом, вникает в его нужды и беды; тех. поддержка сама себе и менеджер, и постановщик задачи, и аналитик, и психолог при необходимости. Да, психолог, потому что просто так в тех. поддержку не обращаются, и процентов 40%  обращений выглядят как: «а-а-а, всё пропало, ничего не работает, как теперь жить?!?», — и первые 10 минут сотрудник сопровождения потратит на то, чтобы убедить клиента выдохнуть, успокоиться и объяснить толково, что именно и где не работает.

Именно тесный контакт с «неадекватными» и «тупыми» клиентами часто отталкивает программистов от работы в поддержке. Действительно, чтобы работать с людьми нужно и терпение, и такт, и стрессоустойчивость, и умение читать мысли,  и еще целый ряд особых качеств, без которых, возможно, удастся обойтись в чистой разработке.

С другой стороны, неопосредованное взаимодействие с клиентом несет и положительные стороны для саппорта. Например то, что результаты своей работы видишь сразу. В разработке же как:  ты написал программу, и где-то ее с удовольствием используют; но ты можешь об этом и не узнать, лично тебя никто не похвалит — не потому, что не хотят, а потому что тебя не знают.  А в сопровождении: ответил ты клиенту на его вопрос, поправил косяк, внес столь нужные для клиента правки — и тебе тут же скажут лично и прямо, как к тебе относятся, и что про твою работу думают. А относятся иной раз с благодарностью, и думают как о профессионале своего дела. Правда-правда. 😉

2. Быстрая смена заданий в широком диапазоне.

Разработчик может неделями и месяцами работать над одним и тем же проектом. Он может планировать ход работ, этапы выполнения и примерные сроки этих этапов. Он знает, чем он будет заниматься  и через час, и завтра, и на следующей неделе.

Сотрудник сопровождения начинает настраивать систему для одного клиента — приходит задание от другого клиента,  требующее немедленного реагирования, а третий клиент тем временем решает, что настал подходящий момент  пообсуждать в скайпе долгосрочные перспективы постепенных модификаций программы.  Бывают дни, когда приходит по 30-40 обращений, и по факту за день не выполняется ни одно — все только фиксируются, уточняются и ставятся в очередь. Потом затишье, очередь обращений постепенно разгребается — но в любой момент может вклиниться неотложная задача, из-за которой приходится перекраивать всё расписание на день или иначе перераспределять обращения между сотрудниками.

Сотрудник сопровождения в один момент времени работает с клиентом, у которого простая базовая версия программы, а через 2 минуты может понадобиться отвечать другому клиенту на вопрос по настройке дополнительного пакета; еще через 10 минут придется  вникнуть в совсем уж уникальную доработку третьего клиента. Разработчик прекрасно ориентируется в написанном им модуле — сопровождение обязано знать (или уметь получить информацию) обо всех доработках и настройках любого модуля любого  из клиентов.

Разработчик разбирается уже, саппорт — шире. Разработчик работает в удобном для него темпе, сопровождение постоянно подгоняют клиенты, заставляя ежеминутно пересматривать очередность задач. От сопровождения требуется больше гибкости в планировании рабочего времени.

3.  Изменения вносятся в уже эксплуатируемый проект.

Представьте, что вы купили квартиру с черновой отделкой (базовую версию программного продукта). Теперь вы хотите отделать квартиру на свой вкус (сконфигурировать и, возможно, доработать программу под свои специфические требования).  Вы нанимаете бригаду строителей, которые строят вам дополнительные перегородки,  выравнивают стены, настилают полы, покрывают стены отделочным материалом, устанавливают сантехнику и прочее, и прочее.  Бригада строителей, которую вы задействовали на данном этапе, и есть команда программистов-разрабочиков.

Ремонт окончен, вы вселяетесь, живет — год, два, пять. Как бы был продуман и качественно выполнен первоначальный ремонт, с течением времени квартира начинает терять свою былую красоту и функциональность: дети изрисовали стены в прихожей, шурин уронил гирю в унитаз, или просто новая кофточка  жены не подходит по цвету к старым обоям. Вы снова обращаетесь к строителям — заменить унитаз, покрасить стены, поставить счетчики на воду и тому подобные точечные правки. И вот эти новые рабочие, выполняющие вам мелкий ремонт, и есть аналог сопровождения.

Конечно, если ремонт был сделан некачественно изначальными «разработчиками», если неверно были выбраны материалы или нарушены технологии, то никаким косметическим ремонтом не помочь. Поэтому к разработчикам выше требования к качеству кода, к структуре, а еще раньше (это даже не разработчиков, а начальника их компетенция) — к выбору средств и методов.  Если неверно спроектировали, если неаккуратно реализовали — сопровождение бессильно, штукатурка всё равно рано или поздно отвалится, как ни крась.

С другой стороны, что сложнее: сломать стену и перенести ее на 30 см левее или переклеить в комнате обои, не вынося мебель и вообще никак и ничем не беспокоя хозяев? Трудно ли заменить стояк, ни на час, ни на полчаса не отключая в квартире воду?  Сопровождение  фактически делает ремонт в жилой квартире, жильцы из которой не только не съезжают на время ремонта, но и очень сердятся, когда какие-то действия рабочих сказываются на их повседневной жизни. Тут приходится иной раз фокусником быть,  чтоб «и цветок сорвать, и бабочку, на нем сидящую, не потревожить».


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

Далеко не каждый разработчик сможет справиться с сопровождением — и это говорит отнюдь не в пользу легкости работы в тех. поддержке. Разработка и сопровождение — совершенно разные виды деятельности, требующие каждая своих особых профессиональных навыков и личных качеств. В наших реалях, пожалуй, безболезненнее президента с премьером  поменять местами, чем разработчика со службой тех. поддержки.

Где сложнее работать  — в разработке или сопровождении? Я даже для самой себя не знаю ответа.  В сопровождении я психологически сильнее уставала: утомляет быстрая смена заданий, выматывает сливаемый на нас негатив клиентов. В разработке для меня спокойнее — и скучнее: по сравнению с саппортом не хватает драйва и эмоций. 😉 Если говорить о результате, то вроде как успешно справлялась и там, и там. Так что сейчас на неком перепутье — даже не знаю, что бы для себя в будущем предпочла.

Коментарии