Когда у молодого специалиста что-то не получается, он занимается самокопанием и начинает думать, что вообще ничего не сможет сделать.
Поскольку люди часто склонны видеть корень зла в своем окружении – обстоятельствах/начальстве/коллегах – времени на поиск причин внутри себя не остается.
Но, мне кажется, оба подхода не совсем верны.
В начале карьеры мы склонны воспринимать любые неудачи на работе на свой счет, что в конечном итоге приводит к демотивации и неуверенности в себе.
Нечто подобное случилось и со мной в свое время.
Возможно, это случилось с вами или даже происходит сейчас.
Поэтому я просто расскажу свою историю смены специальности – надеюсь, она послужит кому-то недостающим толчком к действию.
Кто я вообще? Сейчас работаю тестировщиком в Яндекс.
Деньгах.
Мне 23 года, и моя специальность «Информатик-экономист» (и это не «информатик» минус «экономист»).
Она начала работать еще на первом курсе университета, хотя это была скорее подработка: репетитор по математике, оператор в отделе бронирования паромной компании.
А перед последним курсом университета я работал инженером службы поддержки в крупной японской туристической корпорации.
Это не была обычная «первая линия поддержки», которая обычно регистрирует запросы и пересылает их ответственным инженерам.
Администрировали внутреннюю систему документооборота, настроили рабочие места, систему безопасности, разобрались с сетевыми проблемами, запросами, связанными с офисными продуктами, VPN и т.д. Вообще таких специалистов в народе называют «шивами».
Как попасть в справочную службу после иллюзорной университетской практики Во время учебы в университете я всячески старался получить новый опыт, чтобы после окончания учебы найти достойную работу: участвовал в научных конференциях (это меня быстро разочаровало, так как такие конференции содержат мало науки, в основном пересказы существующих работ) , писал научные статьи и занимался внештатной работой.
, прошел обязательную ежегодную практику.
В общем, классика «учись на отлично – и все у тебя будет».
Вообще практика – это всегда интересная история.
Когда вы поступаете в вуз, волонтеры в приемной комиссии рассказывают вам о крупных компаниях, с которыми сотрудничает учебное заведение, и о предоставлении рабочих мест. Вы ждете лета, чтобы быстрее начать применять все свои знания на практике, познакомиться с реальными рабочими процессами и задачами, даже простыми.
Но на самом деле мест для стажировки очень мало, а вуз предлагает летнюю работу на кафедре, причем не для всех, поэтому все придется искать самостоятельно.
Однажды летом я работал и стажировался в отделе бронирования паромной компании.Через год я устроился на стажировку в банк.Они только что завершили внедрение новой ИС, которая на тот момент вела себя нестабильно.
Удивительно, но всех радовал тот факт, что система падала несколько раз в день, а при попытке что-то сохранить появлялись ошибки, потому что работа усложнялась.
Я попытался описать условия появления ошибок и отнес их в ИТ-отдел.
На тот момент мне и в голову не пришло, что этим занимаются тестировщики.
Тогда мне это казалось невероятным, ведь отбор был серьезный.
Несколько собеседований, тестов, много кандидатов.
Перед началом работы сотрудники банка (рекрутеры, будущие менеджеры, специалисты по информационной безопасности) запросили подробный план и цели практики.
Помню, как я им тогда что-то рассказал про «описание ключевых бизнес-процессов в модных обозначениях, описание ИТ-архитектуры, как рекомендует TOGAF».
В первый день практики нас (стажеров) посадили в кабинет руководителя вырезать ножницами устаревшие рекламные буклеты.
Мы сделали это.
В последующие дни нам поручили более ответственную работу.
Распределение судебных дел клиентов по алфавиту.
Задача, конечно, сложная и долгая, но я ввел имена всех клиентов в Excel, отсортировал их (прикладная информатика), а потом просто разложил стопки папок по списку.
Никто не ожидал, что мы так быстро справимся, поэтому пришлось придумать другое задание.
В итоге меня устроили на работу в БИС (банковскую информационную систему), опыт взаимодействия с такими системами у меня был в университете, было интересно.
В банке внедрялся новый модуль анализа, и я нашел ошибки, которые потом отправил в виде предложений по доработке.
На тот момент я еще ничего не знал о тестировании вообще и о существовании такой специальности в частности, но уже был во всем этом задействован.
Что будет, если сделать «что логичнее» Приближался последний курс университета, у меня было много времени и мало опыта, поэтому я пошел работать инженером Service Desk. В первые месяцы работы я сразу заметил, что в ИТ-инфраструктуре компании не все гладко.
Например, у всех инженеров в силу специфики работы в международной компании графики были разные (для поддержки офисов в Китае или Америке некоторые работали ночью, а на следующий день после ночной смены отдыхали и были недоступны) .
ИТ-сотрудники были разбросаны по всему миру (операции в Санкт-Петербурге, ИТ-директор в Копенгагене, разработчики в Индии и еще множество местных сотрудников службы поддержки во всех офисах).
По этим причинам иногда было сложно найти быстрое решение или человека, ответственного за выполнение определенных задач.
Я взял на себя несколько проектов по улучшению и оптимизации процессов, поэтому мне приходилось много общаться со всеми сотрудниками и руководителями, собирать их пожелания, писать документацию и решать возникающие проблемы.
Также у меня была возможность рисовать интерфейсы и составлять четкие и понятные для разработчиков технические задания.
Иногда все это занимало много времени, поэтому я начал писать код сам, чтобы быстрее реализовать некоторые свои идеи.
Помимо таких задач я часто делал выгрузки и анализ инцидентов.
Мне хотелось понять, где узкое место в работе, каких знаний не хватает, какие специалисты нужны.
Так получилось, что все в ИТ-отделе привыкли «тушить пожары», а не предотвращать их.
Попутно я рассказывал своим коллегам об ITIL и ITSM, на словах всем очень понравилось, но мало кто горевал желанием поддержать изменения.
Так прошло чуть больше года, за счет работы на энтузиазме задач прибывало все больше, а на мои мини-проекты времени уже не оставалось.
Из-за неправильно выстроенных процессов количество задач ничуть не уменьшилось.
Было ощущение энергичной, но бесполезной деятельности.
В это время в компании произошли серьезные инциденты с безопасностью, и личные данные клиентов оказались в сети.
Японцы с этим очень строги, компания получила предупреждение от правительства, и следующий подобный инцидент может привести к закрытию компании.
Я стал инженером группы информационной безопасности, и в компании приходилось внедрять различные системы информационной безопасности.
Так получилось, что новых профильных специалистов решили не нанимать и бремя новых задач легло на имеющийся персонал.
И что еще интереснее, не было еще и четкого представления о конкретных ожиданиях и задачах.
Не хватило опыта, чтобы на чём-то остановиться и приступить к делу: читаешь описание системы, уточняешь детали у продавцов, а на деле получаешь два абсолютно одинаковых решения, отличающихся названием и ценой.
И, конечно же, тонкие технические особенности реализации, понятные отсутствующим профильным специалистам.
Долго топтавшись на месте, отсутствие результатов привело к мысли, что ЭТО не для меня.
Совсем.
Иногда нужно просто взять и бросить Большинство моих друзей тоже из ИТ, системные администраторы, разработчики, специалисты по ИТ-консалтингу.
Общаясь с друзьями, я понял, что в других сферах все устроено совершенно иначе, чем в эксплуатации.
Проекты развития почти всегда вытекают из стратегических целей компании или миссии компании перед пользователями.Стать разработчиком за короткое время казалось невозможным, хотя я писал код на разных языках, но в основном для решения прикладных задач — без использования фреймворков и конвенций.Они завязаны на маркетинге, в отличие от эксплуатации, разработка не может не реализовать в срок то, что уже заявлено в прессу.
К тому же разработка — дорогое удовольствие, а значит, ей уделяется больше внимания.
В общем, я хотел присоединиться к «команде А».
Мне хотелось быстрее уйти с работы, а всякие курсы «Стань Java Junior Developer за 9 часов» не внушали доверия.
Разработчик должен знать алгоритмы, фреймворки, шаблоны и особенности языка.
Если вы разработчик в Agile-команде, вы часто выступаете еще и системным архитектором, а это требует опыта.
Мой друг посоветовал мне пройти тестирование, и я решил попробовать.
Прочитал пару книг по тестированию, посмотрел известных QA-инженеров, а также курсы Яндекс.
Денег и Mail.ru. Меня впечатлили два совершенно разных подхода: одни учат администрированию, техническим особенностям того, с чем вам придется работать, базовому языку ИТ, другие учат общим понятиям, анализу, дизайну тестов, планированию, покрытию, оптимизации.
Все это было на словах, но мне хотелось больше практики в тестировании веб-сервисов.
Поэтому для подготовки я решил написать собственное небольшое веб-приложение на Java (спасибо ресурсу StackOverFlow), с несколькими «ручками» и базой данных, а затем протестировать это приложение по «правилам».
Этот опыт помог мне узнать больше об архитектуре веб-сервисов и инфраструктуры, а также рабочих инструментах.
Я использую эти знания каждый день при тестировании или подготовке тестовых сред. Теперь я тестировщик Уже прошло около семи месяцев, как я счастливый тестер.
Передо мной всегда есть список задач, расставленных менеджером проекта по приоритетам и вытекающих из общих целей.
Я знаю, куда движется продукт и команда, и вижу результаты нашей работы.
Проверяю внутренний инструмент для сотрудников службы поддержки - Контакт-центр.Моя работа требует от меня взаимодействия с разработчиками, поэтому я изучаю множество тонкостей разработки.Как Тимур уже писал в предыдущая статья , тестировщик в команде занимается как бекенд-, так и фронтенд-задачами.
Кроме того, я пишу автотесты, помогаю пользователям инструмента с возникающими вопросами и трудностями, участвую в создании технических решений.
Также я приобретаю опыт организации и контроля работы, ведь многие вещи (баги, например) сначала проходят через наш отдел:
- тестировщики первыми настраивают новые возможности в тестовых средах (кстати, здесь очень помогают навыки администрирования);
- находить подводные камни и периодически предоставлять ценные рекомендации, которые следует учитывать при развертывании приложения в рабочей среде.
Непрошеный совет Если говорить о советах, которые я, исходя из своего опыта, могу дать молодым специалистам, то я бы выделил следующие:
- Если вам кажется, что работа вам не подходит, скорее всего, это не так.
Не нужно бояться менять род деятельности; лучше попробовать пораньше, чем осознать, что уже много лет занимаешься чем-то «не своим».
Никто за вас не сделает вашу жизнь лучше.
- Относитесь к каждой задаче как к прекрасной возможности получить новый опыт. Даже если кажется, что сейчас этот опыт бесполезен, а задача скучна и неинтересна, вы не знаете, чем она обернется в будущем.
- Не пытайтесь бездумно тянуть ношу, а контролируйте свой вклад в работу и отдачу от нее.
Если что-то не так, то это повод пересмотреть деятельность или вообще сменить ее, пока не поздно.
- «Руководство для практикующих специалистов по проектированию тестов программного обеспечения», Ли Коупленд;
- «Программа базового уровня», ISTQB;
- «Java для тестировщиков», Алан Ричардсон.
-
Загрузите Драйверы Бесплатно И Прямо Онлайн
19 Oct, 24 -
Отпуск Для Слабаков
19 Oct, 24 -
Acer A100 - 7 Дюймов, Но Сколько Помощи!
19 Oct, 24 -
Аваст! Удаляет Calc.exe Как Вирус (2:0)
19 Oct, 24 -
Видео С Дня Открытых Дверей Jetbrains
19 Oct, 24
