60

Ответ на пост «С какой стороны проще войти в ИТ (не тестирование)»

Я системный аналитик в ИТ (контора имеет свой продукт: есть коробка, есть проектная команда, которая дорабатывает коробку под нужды заказчика). Я работаю в проектной команде. Есть кадровый дефицит как аналитиков, так и тестировщиков.

Речь про тестировщиков пойдет.

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

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

По той задаче на которую выходил новый тестировщик я уже подготовил ПМИ, подготовил рыбу протокола тестирования, соответственно задачей тестировщика являлось на стороне заказчика, на DEV стенде прогнать задачу и убедиться что она работает, заполнить протокол тестирования.

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

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

В процессе знакомства с тестером я утонял его опыт и узнал, что он где-то учился, где-то работал и прошел целый яндекс-практикум по тестированию (в моменте когда он мне это рассказывал, я улыбнулся в душе, но вида не подал).

В целом я с ПМ были настроены очень позитивно и потратили примерно полдня на подробнейший рассказ как что создавать и что делать. Снабдили товарища ТЗ и документацией по общему функционалу и отправили работать. Тут можно заметить, что я лично сказал, чтобы он звонил мне при любом затруднении, т.к. я очень заинтересован чтобы у нас был тестер, который снимет с меня часть нагрузки. Он даже задал в ходе остального дня несколько вопросов и мы созванивались с ним, я показывал ему лично как и что делать на примерах и даже прошли пару кейсов. Договорились что условно вечером созвонимся еще раз чтобы уточнить нужна ли помощь и какие он видит сроки завершения своей работы.

Наступает вечер, звоню ПМ с вопросом - "Будем созваниваться?". И тут он мне сообщает, что тестер отказывается работать и вообще заявляет что он будет увольняться. На мой вопрос - "Как так?", был получен ответ, что он не ожидал что ему нужно будет еще бэкэнд тестировать, и он вообще рассчитывал, что он будет тестировать только фронт.... типа что он не должен создавать тестовые данные и вот это вот все.

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

Судя по всему товарищ понимал тестирование как тыкание в кнопки и фиксирование результата без создания тестовых данных, без анализа источника ошибки (ну или хотя бы понимания в каком объекте она может возникать), без подготовки кейсов и протоколов.

К сожалению (или к счастью) не знаю его дальнейшую судьбу (остался он или уволился), но весь пост был вот к чему.

Многие считают, что в ИТ работать - это манна небесная, типа делать там особо нечего (мешки грузить условно не надо), поэтому любой может пойти и без труда начать работать тестировщиком (для начала).

Считаю что в таком общественном понимании "легкого входа в ИТ" виноваты в основном долбанные курсы от Яндекса и прочих провайдеров, коих расплодилось дохрена и больше. Они транслируют такое виденье, т.к. собственно от этого зависит их бизнес и денежки слушателей, которые бегут за сладкими обещаниями легких денег.

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

Я лично готов поставить памятник некоторым нашим разрабам, которые превращали слова в работающий функционал по моим задачам, т.к. знаю каких трудов стоит реализовать написанное ТЗ (не всегда идеальное, к сожалению), и с какими сложностями им приходится сталкиваться.

В общем, резюмируя все вышесказанное.

Не хотел никого пугать. Но работа в ИТ в любой роли это сложная и ответственная работа, к которой необходимо относится серьезно. Это не легкая прогулка, как многим бы этого хотелось, и деньги тут зарабатываются тоже нелегко.

Всем пис.

P.S.

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

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

Ответ на пост «С какой стороны проще войти в ИТ (не тестирование)»
Показать полностью 1
11

С какой стороны проще войти в ИТ (не тестирование)

Нетерпеливым - прыгайте в середину статьи. ОЧЕНЬ много букв. Как и везде в ИТ.

Так часто получаю вопрос "как войти в ИТ" от знакомых, что проще один раз написать и всем давать ссылку на серию статей. Возможно, кому-то еще помогу сделать шаг или снять розовые очки и лапшу с ушей.

Со всех сторон рекламируют курсы тестировщиков, где обещают трудоустройство и неприлично большие зарплаты. Хочу показать какие еще есть двери в ИТ и где очередь поменьше.

0. Введение в ИТ

Прежде чем начать, нужно понимать что происходит между словами "нужна программа" и "вхуж! оно работает!".

Так или иначе, все в ИТ движется по общему циклу:

Идея -> формализация идеи-> проектирование -> реализация -> тестирование ->внедрение и эксплуатация. Затем собирают обратную связь и заново идут генерировать идеи.

Если проект маленький и в команде один "многорукий многоног" - можно увидеть только разработку и внедрение, а остальные этапы происходят в голове разработчика.

В больших проектах появляется специализация. Чем больше проект, чем больше людей - тем сильнее специализация. 10 "универсальных солдат" всегда менее эффективны чем 10 специалистов, знающих детально только 1 этап.

С какой стороны проще войти в ИТ (не тестирование)

И так далее - до 10 ролей и более доходит во многих крупных компаниях.

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

Отсюда следует два варианта:

  1. учить все и сразу, ориентируясь на средние компании.

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

Далеко не везде нужно программировать. Через некоторые двери зайти проще.

Самое важно:

  • проще попасть в ИТ-проект на любую роль куда берут, а потом переместиться внутри на желаемую.

  • новичкам без опыта крайне сложно найти работу на конкурентные роли. Даже если вам обещали на курсах.

Итак, какие двери есть в ИТ:

1. Заказчик (Владелец продукта)

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

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

Бухгалтерия дает прогноз, когда возможно (или невозможно) сделать. Не успели, сделали не то - вы высказываете свое недовольство.

Входные требования:

опыт работы руководителем проекта в любой области. Не обязательно разбираться в ИТ, достаточно понимать как программа вам поможет решить задачу бизнеса. Всю нагрузку по работе с ИТ может взять менеджер проекта (если, конечно же, он тоже не "искал вход в ИТ")

Что делает:

просчитывает имеющийся бюджет проекта, сроки, окупаемость.

За что отвечает:

успешность решения (это может быть выручка, социальный эффект, оптимизация чего-то и тд)

Возможность переквалификации: во время работы можно выбрать направление, изучить, забрать на себя часть работы, затем перейти целиком. Например, изучить основы языка программирования, начать делать простые задачи по проекту, а потом постепенно "мигрировать" в разработчики.

2. Менеджер проекта

Контролирует все этапы, потому не отобразил на схеме. Одним словом, руководство "покупает" у менеджера проекта результат работы. Еще одна хорошая точка входа для начальников отделов.

Входные требования:

  • проектное управление в ИТ (т.е. для “войти в ИТ” подойдет, только если есть опыт проектного управления). Agile, Scrum, Ci/Cd -нужно понимать что это и как работает. Объема знаний в виде курсов 20 часов по каждому направлению достаточно для входа.

  • управление коллективом

Что делает:

  • составляет план работ и контролирует соблюдение

  • управляет распределением ресурсов команды

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

За что отвечает:

  • срок выполнения. Уволился/заболел/ушел в отпуск разработчик или вся команда - это его ответственность. Нужно было учесть при планировании.

  • качество работ. Не успели протестировать, нашли критичный баг, ошиблись и недооценили задачу - спрос с менеджера.

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

С одной стороны будет давить руководство: "нужно быстрее/дешевле/качественнее", с другой разработка: "так не делается! или быстро или качественно!". Для тех, кто был начальником производственного отдела ничего нового.

Возможности переквалификации: в менеджеры проекта. Реже - в любые другие роли.

3. Бизнес-аналитик (технический писатель)

Переводчик с языка заказчика "хочу" на язык разработчиков "что будем создавать". Есть разделение - бизнес-аналитик и системный аналитик.

Бизнес-аналитик описывает как пользователь работает с системой - какие кнопки нажимает, как реагирует система, какие окна открываются и тд.

Входные требования:

Предметная область в деталях. Например, знание всех деталей по оформлению кредита в банке достаточно для работы в этой роли. Естественно, со стороны банка.

Что делает:

переводит слова заказчика с "хочу чтобы клиент смог оформить заявку с телефона" на язык "открыть сайт, ввести определенные данные, затем данные передаются в отдел А, он делает с ними Б, передает в С" и т.д. Описывает все что видит и вводит каждый участник - какие окошки на мониторе, какие прикладываются документы и тд.

За что отвечает:

чтобы разработчик сделал то, что хотел заказчик.

Переквалификация:

  • В менеджеры проектов.

  • Реже в системные аналитики или тестировщики.

  • Вариант развития - бизнес-архитектор (редкая, но сытная должность).

4. Системный аналитик

Продолжает работу бизнес-аналитика, но действует “на этаж ниже”. Если бизнес-аналитик написал "пользователь нажимает кнопку А", то системный аналитик детально описывает как должна реагировать система, по каким протоколам идут данные, в каких форматах и что происходит внутри после нажатия кнопки.

Очень высокий порог входа для не "ИТшников", переподготовиться из бизнес-аналитика или тестировщика - дело 1 года.

Входные требования:

Особенности системы, протоколы взаимодействия внутри, форматы данных и тд. Чистое ИТ без программирования.

Что делает:

Переводит слова бизнес-аналитика "нужно чтобы отобразилась кнопка" в слова компьютеров "при запросе по протоколу Х в компоненте Y вызывается функция Z и возвращает результат XYZ..."

За что отвечает:

Система работает именно так, как описал бизнес-аналитик.

Переквалификация:

  • в менеджера проектов.

  • реже - в разработчика или тестировщика.

  • вариант развития в системного архитектора лет через 5-10.

5. Разработчик

Требуется отдельная статья, очень много нюансов и самая сложная для входа дверь в ИТ.

6. Тестировщик

Еще его называют QA (quality assurance) - ответственный за качество решения.  Направлений очень много, рассмотрим только ручное тестирование как простейшее для входа.

Входные требования:

  • особенности программ, которые планируется тестировать. Или, как минимум, чего-то похожего.

  • бизнес компании. Если устраиваетесь в финтех и слова "идентификация" вам неизвестно - шансы на успех сильно падают.

  • дотошность и готовность к рутине. Одни и те же кнопки придется нажимать каждый день много раз. Очень много раз. И описывать это.

Что делает:

  • принимает работу у разработчиков

  • сверяет требования заказчика с тем, что принесли разработчики

  • проверяет и. описывает все найденные расхождения

За что отвечает:

Число багов/ошибок, дошедших до клиента. За соответствие технического задания и разработанного результата.

Возможности переквалификации:

  • специализированное тестирование - автотесты, нагрузочное и тд (конкуренция ниже, зарплаты больше),

  • системные аналитики

  • разработчики.

7. Эксплуатация (секретная и свободная дверь!)

Или техническая поддержка. Не самый очевидный и прямой путь, но кому-то может подойти лучше. Пока самая "секретная" дорожка.

Входные требования:

Опыт работы с клиентами или опыт поддержки на второй линии.

Что делает:

принимает запросы от пользователей, следит за работой системы, исправляет простые проблемы (как правило, по готовым инструкциям), передает обратную связь разработчикам.

За что отвечает:

  • пользователи довольны

  • система работает или руководитель знает, что и почему не работает

Возможности переквалификации:

  • в бизнес-аналитики

  • в тестировщики. Можно устроиться работать в поддержку, подключиться к тестированию и со временем попроситься в тестировщики.

Сократил и все равно много получилось. Готов развернуто отвечать на интересующие вопросы.

p.s. @Simulacris, блога все еще нет, но вопрос помню :)

p.s.2 За время работы в ИТ входил, выходил, входил снова с другой стороны и тд. Нанимал, обучал, переквалифицировал коллег.

Показать полностью 1
Отличная работа, все прочитано!

Темы

Политика

Теги

Популярные авторы

Сообщества

18+

Теги

Популярные авторы

Сообщества

Игры

Теги

Популярные авторы

Сообщества

Юмор

Теги

Популярные авторы

Сообщества

Отношения

Теги

Популярные авторы

Сообщества

Здоровье

Теги

Популярные авторы

Сообщества

Путешествия

Теги

Популярные авторы

Сообщества

Спорт

Теги

Популярные авторы

Сообщества

Хобби

Теги

Популярные авторы

Сообщества

Сервис

Теги

Популярные авторы

Сообщества

Природа

Теги

Популярные авторы

Сообщества

Бизнес

Теги

Популярные авторы

Сообщества

Транспорт

Теги

Популярные авторы

Сообщества

Общение

Теги

Популярные авторы

Сообщества

Юриспруденция

Теги

Популярные авторы

Сообщества

Наука

Теги

Популярные авторы

Сообщества

IT

Теги

Популярные авторы

Сообщества

Животные

Теги

Популярные авторы

Сообщества

Кино и сериалы

Теги

Популярные авторы

Сообщества

Экономика

Теги

Популярные авторы

Сообщества

Кулинария

Теги

Популярные авторы

Сообщества

История

Теги

Популярные авторы

Сообщества