60

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Всем пис.

P.S.

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

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

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

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

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

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

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

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

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

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

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

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

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

С какой стороны проще войти в ИТ (не тестирование) IT, Программирование, Длиннопост

И так далее - до 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
Отличная работа, все прочитано!