Предположим, что вы примерно определились, что хотите развиваться в сторону программирования. Но допустим вот такое уточнение: на программиста вы не тянете, тестировщиком ПО вас на работу не берут, до аналитика ой как далеко, а про менеджмент пока что вообще молчим. Везде нужен опыт. И точнее сказать, не опыт именно работы на каком-то предприятии, а прежде всего ваши знания и умения.
На заре информатизации нашей страны специализаций в IT-сфере было гораздо меньше, чем сейчас, если не сказать, что вообще только две: админ и программист. И это была стезя «избранных». «Компьютерщики» приравнивались к полубогам и их было не так много. Время идет, ситуация меняется, и сегодня IT-специалист - это более обширное понятие.
Итак, в поисках работы вы начинаете бороздить соответствующие ресурсы в просторах интернета и вынуждены мониторить примерно следующие IT-вакансии:
· Специалист технической поддержки
· Консультант пользователей
· Технический писатель
Что-то в этом духе…
В поиске проходит какое-то время и случается так, что вы приняты специалистом техподдержки в команду по внедрению какого-нибудь продукта фирмы 1С. Вы пока что слабо себе представляете, чем именно вам придется заниматься, а все то, на что вы подписались во время собеседования – консультирование пользователей, разработка технической документации, возможно тестирование разработанного функционала – вы вот всё это понимаете как-то по-своему и думаете: «Ну уж я то это всё знаю, нам в институте рассказывали и сейчас я покажу им настоящий класс….».
И хорошо, если так. Но в случае с начинающими дело, как правило, обстоит по-другому…
Несомненно, что как-то работать вы начнете. Худо-бедно начнете консультировать пользователей. И даже напишете несколько инструкций по работе. И будете думать, что вы отличнейший специалист. И чтобы развеять определенную иллюзорность, давайте в формате «проблема-решение» внесем немного ясности. Итак, что же от вас требуется или какое ваше поведение будет развивать вас в этом направлении.
Учет своих задач. Как не забыть все обращения?!
Это один из самых первых вопросов к вам. Ибо команда доросла до уровня, когда выделен отдельный человек, на которого заводятся все звонки. Сделано это ввиду эффективности такой схемы организации работы службы разработки\сопровождения ПО. Стоимость задач, которые может решать разработчик гораздо выше стоимости задач консультанта. Ну а пока вы не разработчик, а консультант спектр действий, который от вас требуется следующий:
1. Зафиксировать обращение пользователя в используемой в команде системе HelpDеsk. Обращение\задача должны быть зафиксированы.
2. Попытаться решить вопрос самостоятельно, что называется "на первой линии": исходя из личного опыта консультирования, либо найти ответ в имеющейся внутренней документации на продукт или инструкции или в официальном описании продукта, интернет в конце концов никто не отменял.
3. Если не получилось решить вопрос на своем уровне, то передать вопрос на вторую линию.
Вот собственно все, что от вас требуется в части консультирования пользователей. Дальше дело ваших личных стремлений и вашей эффективности.
При этом нужно помнить, что первая линий консультаций – это, как ни крути, лицо группы разработки. Все в принципе то понимают, что консультант это консультант и что он способен решать более простые вопросы. Но, так или иначе, команда держит именно этого консультанта и оценка всей команды может формироваться исходя из впечатления от работы с консультантом.
Поэтому вам, как консультанту и в случае если вы хотите расти над собой как специалист, крайне важно обладать, ну или хотя бы стремиться к тому, следующими знаниями:
Знание предметной области, по которой вы оказываете консультационные услуги. Т.е. если вы консультируете по складскому учету, то вы сами прекрасно должны понимать всю цепочку документооборота и особенности заполнения каждого документа из этой цепочки.
А это значит, что у вас должно быть Знание конфигурации 1С, с которой вы работаете. Ну а тут уж фирма 1С постаралась: пользовательская документация более чем исчерпывающая, а система помощи в самой конфигурации также весьма хороша.
Вообще, если вы связываете свою жизнь с продуктами фирмы 1С, то недурно знать методологию учета в решениях 1С. Она универсальна от решения к решению и тоже хорошо документирована.
Ну и совершенно стыдно консультанту не знать от корки до корки желтую книжку: «Руководство пользователя». Ее нужно знать на очень приличном уровне. И более того, нужно обладать на уровне опытного пользователя навыками работы с основными объектами конфигурации.
Идем дальше.
Ваш рост как профессионала не может состояться без знания основных бизнес-процессов предприятия в той отрасли, в которой вы работаете. Это знание частично пересекается со знанием предметной области, но в данном случае здесь более детально рассматривается вопрос. Т.е. если вы работаете на предприятии, которое продает и ремонтирует автомобили, то вы должны прекрасно понимать что есть как минимум такие процессы как «Продажа новых автомобилей клиентам», «Сервисное обслуживание гарантийных автомобилей клиентов» ну и т.д. И естественно, вы должны понимать: что, кем и как делается в рамках этого процесса.
Все озвученные знания отнесем к базовым, минимально необходимым для того, чтобы более менее сносно решать повседневные задачи и не выглядеть кисло в глазах пользователей, которые к вам обращаются.
Итак, вы работаете уже полгода, консультируете пользователей и ждете повышения заработной платы. А ваш начальник в этом вопросе не торопится. Что же ему, вашему начальнику, может не нравиться в вашей работе?! Вы консультируете с каждым месяцем все больше пользователей, казалось бы – прямой показатель вашей производительности, а он, начальник, не особо торопится дополнительно за это платить.
А на самом то деле ему нужно от вас не увеличение количества проконсультированных пользователей. Начальник, если хоть и не поставил такую задачу, все же ждет от вас анализа обращений пользователей на предмет выявления проблем. Ведь если пользователь или группа пользователей с завидной стабильностью обращаются в техподдержку с одним и тем же вопросом, то тут есть над чем задуматься…
В данном случае нужно, прежде всего, проанализировать зафиксированные факты обращений: кто и по каким вопросам обращался, какие были приняты решения проблем и сколько времени на их решение было потрачено. Здесь, конечно, itil в помощь... Ну и дальше в зависимости от контекста нужно работать по одному из следующих направлений:
1. генерировать предложения по автоматизации,
2. выносить проблемный вопрос на обучение,
3. описывать ситуацию в документации (руководстве пользователя).
И идеально, если эту работу, собственно анализ, будет выполнять консультант – это будет положительно говорить о его аналитических способностях, что ему будет только в плюс. И вот тогда начальник будет видеть что вы работаете эффективно и конструктивно. И именно это будет вас продвигать вперед, а не количество консультаций…
Начальнику скорее наоборот интересно снижение количества обращений пользователей в службу техподдержки. Но не в ущерб удовлетворенности пользователей процессом консультирования, а за счет повышения уровня знаний пользователей, которое достигается путем увеличения количества обучений по проблемным вопросам и объема документирования разработок.
И вот мы плавно подошли к документированию. Но тут все просто, от вас требуется всего лишь:
· Знание и использование в своей речи\письме терминологии 1С.
· Навык изложения своих мыслей техническим языком.
Эти навыки, они или есть или их нет. Они, конечно, развиваются. Но, во-первых не кардинально и во-вторых - очень долго. Хотя, может быть, я ошибаюсь…
Ну и дальше парочка таких общих универсальных советов для начинающих.
Когда вам ставят задачу или задают вопрос, вы должны четко представлять что хочет клиент (пользователь). Нет, вы должны понять не то что он просит вас сделать, а то для чего ему это нужно. Поэтому если вам его просьба непонятна в контексте бизнес-процесса, в рамках которого действует клиент, то первый вопрос, который вы должны ему задать: «Зачем?!». Зачем ему это надо?! Я ничего не хочу сказать плохого, но зачастую клиент просит вас сделать что-то, что, по его мнению, решит его проблему. Если вы тут же без каких-либо уточнений приступили к выполнению, вы потратите время, сдадите ему задачу и окажется что это решение не привело клиента к ожидаемому результату. Потом вы станете с клиентом разбираться и окажется, что постановка была изначально некорректна и никогда не могла бы привести к нужному результату. А решение, собственно, вот оно. Вы о нем прекрасно знали, но пользователь предложил вам свой вариант и вы на него бездумно согласились.
Всегда при общении с клиентом включайте голову: пытайтесь себя поставить на место клиента и посмотреть на проблему его глазами. Если вы не понимаете зачем клиенту то, что он просит вас сделать - задавайте ему вопрос: «Зачем?!». Этот простой совет сэкономит кучу времени и нервов в вашей жизни.
А второй совет я хочу преподнести в виде пословицы: «Аккуратно обходя разложенные грабли мы теряем драгоценный опыт». Но чтобы вы правильно трактовали эту пословицу я приведу еще одну мысль:
Если вы «косячите» один раз – это случайность. Два раза – совпадение. Три – это уже система.
Вот как то так: все просто и сложно одновременно.
А дальше дело за вами: если вы будете развиваться в озвученных выше областях, то ваш бэкграунд будет крепнуть от задачи к задаче. А с таким подходом если вы будете проявлять непомерную прыть, то вам открыта дорога и в тестировщики, и в разработчики, и даже в аналитики. А может и до руководителя группы разработки дойдете… Было бы желание…
Дерзайте, друзья.
