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

Термин «выгорание» вошёл в мою жизнь как-то неожиданно. Работал я. Работал много лет: сначала кодил, потом свои проекты делал, команды собирал, бизнес налаживал… И тут — Бац! Куча мемов на эту тему во всех связанных с IT-ресурсах. Не знаю, то ли я в какой-то тундре жил, то ли тундра жила во мне. Но да ладно: мемы почитал, поржал и забыл. А тут неожиданно этот термин вошёл в обиход моих ребят. Где-то как бы в шутку, где-то в серьёз. А мы все знаем: в каждой шутке есть доля шутки, а остальное — чистая правда. 

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

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

«Вот я в своё время по 10 часов работал без выходных и отпусков. Скучные проекты пилил, ночью на проде хотфиксил и т.д. и т.п. У ребят же условия другие: график нормированный (авралы, конечно, бывают, но всё в рамках), переработки оплачиваются х1,5-х2 (всё по ТК), проекты интересные. Премии! Отпуска! Работа, блин, командная! Не как дурак сидишь и всё в одного пилишь, а в коллективе ответственных товарищей. Какое, мол, выгорание? Я вам сейчас расскажу про выгорание!» Ну и прочая блаж в том же духе.

Данная статья рискует стать моей самой короткой статьей. В общем виде ответы на эти вопросы очень простые. Выглядят они примерно так:

Тезис 1. Чтобы стать сеньором надо иметь интересные проекты, на которых ты можешь вырасти и уметь внимательно читать документацию. 

Тезис 2. Гарантировано отличить джуна от мидла и сеньора может ваш тимлид, отправьте специалиста к нему на собеседование. 

Ничего нового в этом смысле в данной статье не будет. Собственно всё :)

И так, вот команда растёт, растёт и дорастает хотя бы до 15+ человек. В этот момент вы неожиданно понимаете, что у вас 3 бекенд-разработчика или даже 5. Здесь возникает неудержимое желание сделать одного из них Самым-Главным-Бекенд-Разработчиком-Проекта. Это желание понятно, и даже логично...

В статье “Сколько должен получать разработчик?”, я обещал рассказать, как предпринимателю заработать на весь этот праздник жизни с джавой и докерами. Если вы ожидаете от этой статьи готовых бизнес-моделей или мотивационных тезисов, можете смело её закрывать. Она просто не про это, а про базовые и по-настоящему важные вещи.

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

Итак, сегодня мы поговорим о самой интимной для любого специалиста теме - его зарплате. Именно из-за интимности этот простой вопрос способен вызвать холивар, бунт или даже маленькую войну. Всё потому, что как и в любой интимной теме люди легко радикализируются и бьются на две противоположные секты. Обзовём их “Адепты бесконечной зарплаты” и “Свидетели отсутствия мотивации”. Рассмотрим идеологию этих сект подробнее.

Как техдир должностные обязанности искал. Спойлер - нашел.

В прошлой статье я упоминал о четырёх уровнях осознанности техдира. Приведу эти 4 этапа, пройденные мной лично, ниже:

1. Ответственность за программирование;

2. Ответственность за технологическую часть продажи;

3.Ответственность не только за тех. процессы (аналитика, тестирование, менеджмент – на выбор)

4. Ответственность за полный цикл производства продукта, удерживая в фокусе внимания все связанные с производством процессы.

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

Как построить успешную IT-компанию, которая:

• Делает топовые проекты по производительности и безопасности?
• Работает на федеральном уровне и зарубежных рынках?
• Имеет одну из лучших систем организации труда?
• Подготовила сотню специалистов, которые вышли на IT-рынок?

Это все вещи, которые удались мне и моему партнёру. Конечно, простого ответа на заданные вопросы не существует (кто бы мог подумать! :)) Однако есть ряд правил, которые помогли нам добиться этих результатов. И я решил, что пора о них писать. Потому что невозможно слушать и читать ту ахинею, которую несут коучи, “Бизнес молодость” и прочие инфоцыгане.