Есть мнение, что “войти в айти” легче через тестирование. Будучи на третьем курсе, я part-time подрабатывала асессором. Тогда я впервые попробовала себя в тестировании, увидела первые чек-листы (я еще не знала, что они так называются). “Войти в айти” не было моей целью, потому что я уже и так училась на программиста, но сама идея тестирования меня очень увлекла. Так на последнем курсе я устроилась на стажировку в Kolesa Group.
Месяц подготовки: чтение пресловутого Романа Савина “Тестирование дот ком”, просмотр роликов на YouTube и практика в создании тест-кейсов. Этого мне хватило, чтобы начать свой джедайский путь в тестировании.
Чтение книг != тестированию реальных продуктовых задач. Так, в ходе работы я сталкивалась с интересными кейсами и проблемами. Теперь, уже будучи миддлом, я рефлексирую и вижу паттерны поведения, которые тормозили мое развитие в профессии. Ошибки, на которые, будучи джуном, я не обращала внимания, но которые позже стали моей болью. Ошибок было куда больше чем три, но именно эти я повторяла из раза в раз, не отдавая себе отчета.
0. Не просить помощи
Когда я была стажером, мне очень хотелось показать себя, потому что от этого зависело, возьмут ли меня на работу. Но даже после успешного прохождения испытательного срока я взяла свои стажерские “наклонности” в junior-позицию. Я могла работать над парой задач в то время, когда еще парочка висела в бэклоге. И в тот же момент я частенько пыталась решить какие-то сторонние вопросы и проблемы. Итог: несколько висящих в воздухе задач, ожидающих меня, в то время как другой тестировщик мог быть свободен.
Я не говорю, что стараться и делать больше, чем нужно, — это плохо. Плохо — неразумно оценивать свои возможности и строить из себя героя в попытках сделать все. Не сделаешь. А если и сделаешь, то не так качественно, как мог бы. Просить помощи не зазорно. Грамотно делегировать нагрузку и задачи — круто. Своевременные релизы и тщательно проверенные фичи — лучшее, что может быть для продукта и бизнеса.
Вывод: проси помощь. Все мы люди и иногда нуждаемся в ней. Не успеваешь — делегируй, но не злоупотребляй. Грамотно оценивай свои возможности и время.
1. Бояться задавать вопросы или задавать слишком много вопросов
Я интроверт, к тому же время от времени страдаю синдромом самозванца, поэтому когда у меня возникали вопросы, очень стеснялась подходить к старшим товарищам. Мне казалось, что мои вопросы глупые и вообще я сама могу найти на них ответы.
В большинстве случаев так и есть, ответы на какие-то вопросы легко можно найти после пары минут гугления или поиска в stack overflow. Вопросы, связанные с бизнес-логикой, особенностями архитектуры и различными workflow, можно найти в документации (если в компании она, конечно же, ведется). Но сейчас я говорю о специфических вопросах, ответы на которые можно узнать лишь у коллег. Я могла тратить до 30 минут своего времени на гугл-поиски, поиски в документации компании, просмотр кода и даже иногда пыталась сама додумать ответ на свой вопрос (кстати, так делать не стоит). Итог: много потраченного на поиски времени и, возможно, так и не найденный ответ. Помочь избежать этого могли 5–10 минут общения с коллегами.
Но у этой медали есть обратная сторона — задавать слишком много вопросов. Даже не так. Задавать вопросы без предварительно проведенного самостоятельного исследования. Бывают случаи, когда человеку легче подходить каждые пять минут с новыми вопросами, в то время как ответы на них можно было бы найти самому.
Вывод: иногда действительно продуктивнее просто спросить у коллег то, чего ты не знаешь. Но перед этим всегда нужно самому провести небольшой поиск ответа на вопрос и собрать все вопросы, которые возникли по ходу.
Так можно получить новые знания и закрепить ранее приобретенные. А когда ты подойдешь с вопросом к коллеге, ему будет приятно осознавать, что ты проделал хоть какую-то работу сам, прежде чем бомбардировать вопросами его/ее.
2. Не брать на себя ответственность
Когда ты джун, ты получаешь простые задачи и несешь меньше ответственности. Ты понимаешь, что есть более опытные коллеги, которые в случае чего придут на помощь и решат проблему. Например, при релизе забаганной фичи ты знаешь, что откат к предыдущей версии сделает кто-то другой. И так во многих вещах. Но для роста нужно научиться брать на себя ответственность и решать проблемы самому, брать инициативу и просить более сложные задачи, быть в эпицентре и помогать во время факапов. При совершении ошибок признавать их и искать пути решения. Брать ответственность не только за свои задачи, но и за качество продукта в целом.
Вывод
Через принятие ответственности можно выйти на новый уровень задач и новые челленджи, которые помогут в твоем профессиональном росте. Не бойся ответственности — она твой друг.
Это были ошибки, которые я совершала не раз. Если быть честной на 100 %, я даже сейчас их иногда совершаю. Но это абсолютно нормально. Осознание проблемы — первый шаг на пути к ее решению.