Елена Правдина - Говорят, в IT много платят. Как построить успешную карьеру разработчика, оставаться востребованным и не выгорать [litres]

Однажды мне довелось поработать с менеджером, отличавшимся свежестью взглядов, искренней энергией и готовностью перевернуть мир. При этом он не давил на разработчиков, проявлял максимальную лояльность и позитивное отношение. Для него хотелось делать задачи быстрее, хотя он об этом даже не просил. Одна из его коронных фраз: «Кто понял жизнь, тот не спешит», – запомнилась мне на все последующие годы и, сама не знаю почему, часто служила мне источником умиротворения в напряженные минуты. Он сделал немало для наших продуктов, выглядел успешным, и потому его уход стал для меня полной неожиданностью. На попытки выяснить причины он привел так полюбившуюся мне впоследствии врачебную аналогию. «Понимаешь, – сказал он, – я здесь, как лекарь-самоучка в деревне. А на этом месте нужны нейрохирурги».

Входные данные

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

Где?

Дома, в метро, на улице, в свое свободное и ночное время.

Сроки

Как правило, довольно сжатые. Давление со стороны заказчика. Риски переделок, последующей поддержки и затрат времени больше ожидаемого.

Ответственность

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

Источники знаний

Google, самообучение, унаследованный код, фидбеки заказчика.

Уровень обратной связи

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

На выходе

Опыт бизнес-разработки, работы на заказ, общения с клиентом, продажи себя.

Попробовать фриланс хотя бы раз – стоит, но надо понимать разницу подобной деятельности с «настоящим», серьезным, и использовать ее не более чем для первичного опыта в отрасли на заре вашей карьеры.

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

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

Здесь быстрее внедрение новых технологий. Актуальнее инструменты, ближе к востребованности на рынке. Реже встречается большой объем легаси-кода, проще договориться о его переделке или хотя бы написании новых частей на современном стеке. Вы свободнее в проявлении инициативы по применению свежих подходов. Конечно же, при адекватном техлиде. Но ведь вы же постараетесь прощупать нужную вам почву еще при найме, верно?

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

Помимо технологического стека в таких компаниях гибче процесс разработки. Суровые реалии выживаемости в бизнесе не позволяют играть мелким фирмам в пустые формальности. Несколько лет работы в «Инвентосе» я участвовала в ряде встреч: ежедневные пятиминутки, встречи по итогам релиза с разбором проблем, обсуждения новых крупных фич. Признаться, иногда мне они казались избыточными, отрывали от работы и вызывали раздражение. Целых 15 минут идти озвучить, что я сделала, – как неэффективно. Да я за это время лишний баг бы пофиксить могла!Однако всё то время я понятия не имела, что вышеупомянутые встречи – это адаптированная под наши нужды теория Scrum-методологии. Безусловно, знала, что у нас Agile, но не слышала о таких столпах, как Ретро, Демо и Рефайнмент. И только оказавшись в Яндексе, благодаря проводимым там тренингам, я постигла все принципы и артефакты теории данной методологии. Целых два дня мы слушали лекции, проводили тематические игры, рисовали плакаты, обсуждали детали Scrum-подхода. Непривычное мне расточительство времени, жалевшей 15 минут на, как я осознала позже, одну из самых полезных встреч. И если здесь, в крупной компании, ресурсы позволяют внедрять многие вещи «как есть», соблюдая все виды артефактов, имея шансы внутри каждой команды далеких от управления разработчиков зародить порядок из хаоса, то мелкие фирмы просто не могут позволить себе таких трат и вынуждены продумывать любое мелкое изменение руководящими умами. Мы не проводили рефайнментов, потому что гораздо эффективнее было не отрывать от работы всю команду. Скажем, присутствие 6 сотрудников на совещании суммарно равно убытку почти одного рабочего дня в человеко-часах. Вместо этого разработчик и менеджер садились рядом и разгребали нужное по приоритетам. Никто официально не нарекался скрам-мастером. Его функции совмещали в себе менеджеры и руководство компании. Мы не вводили и не калибровали сетку сторипойнтов – все оценки давались в реальных часах работы. Никакого покера – оценки под твою личную ответственность. Ошибся – работай вечерами, в выходные и изволь объяснить, почему задача заняла больше запланированного. Ответственность, прививаемая пусть таким, казалось бы, жестким в современном IT-мире способом, позволяла компании выживать – каждый заявленный час мог быть оплачен заказчиком и объяснен ему. Без лишних затрат времени на конвертацию в сторипойнты и чувств коллективной безответственности и расслабленности, порождаемых покером. Не говоря уже о лишних 4–5 человеко-часах (половина рабочего дня компании!), затрачиваемых на данную активность. Демо – сложно даже представить себе, чтобы разработчиков небольшой фирмы сажали за столь низкоквалифицированную для их оплаты работу, как составление презентаций, и заставляли их выступать перед заказчиком, в красивых картинках показывая, что полезного было сделано каждые две недели. Нужные фичи будут увидены – ведь они заказывались клиентом, а часы разработчика слишком дороги и ценны для активностей, непосредственно завязанных на получении прибыли: разработки новых фич или правки багов. Стендапы и ретро присутствовали в своей адаптации и под другими названиями – короче, по делу, без лишних формальностей и соблюдения артефактов.