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

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

Безусловно, среда больших компаний, поощряющая «книжное» воспроизведение методологий со всеми ритуалами и колоссальными затратами времени, позволяет придумать что-то новое и стоящее. У обычного разработчика может родиться гениальная идея, распространяемая на всю компанию или даже привносимая в практику мирового скрама. Но мелкие фирмы не могут позволить выделить время на подобные организационные моменты. Вам же, как новичку, также ценнее заниматься техническими задачами, а не проводить полдня на встречах. Это расслабляет, сбивает ритм, нарушает глубокое погружение и способность отрешенной концентрации, делает шокирующим приход в более мелкую компанию, где каждая потраченная минута подотчетна и за каждый рабочий час с вас будет спрошено сполна. Решив, что часовые обсуждения значений сторипойнтов и составление презентаций для демо – это норма, вы с немалым трудом адаптируетесь к более суровым условиям: напрягать мозг, решать сложные технические неурядицы, оперативно собираться с мыслями и фиксить баг в проде, когда счет идет на минуты и репутация, а вместе с тем и доходы, стабильность и будущее фирмы непростительно страдают.