Токсичный руководитель: 6 способов сохранить себя (из практики медиатора)

Что делать, если в команде есть токсичный человек? А если это — руководитель?
В этой статье — живые кейсы, чёткие признаки и пошаговый план, как сохранить себя и не дать команде выгореть

Токсичность — не про характер, а про влияние

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

(далее…)

Что значит бонус и денежная мотивация

Почему это иногда работает, и где этим стоит пользоваться.

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

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

(далее…)

Как мы ускорили разработку в 320 раз с помощью модульной архитектуры

Топ-10 антипаттернов в разработке ПО, которых стоит избегать

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

(далее…)

Простите, я разрушил вашу компанию

Скрытые языки: как инженеры передают информацию внутри команды, избегая документации

Технические команды часто избегают лишней документации, но информация всё равно каким-то образом передаётся, сохраняется и развивается. В этой статье — попытка разобрать скрытые механизмы общения внутри инженерных команд: как выстраиваются негласные соглашения, каким образом рождаются «внутренние диалекты» и зачем вообще всё это, если есть JIRA, Confluence и куча других инструментов. Много примеров, блоков кода на разных языках и немного личного опыта.

(далее…)

Размышления архитектора

Серия псевдофилософских мини-эссе о работе функционального архитектора.

Про записи архитектурных решений

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

Делать это нужно в каждой ситуации дуальности. Даже если в моменте принятое решение кажется вам очевидным.

(далее…)

Я думал, что в IT нет офисных интриг. Ошибся

Мой друг-программист уже месяц жалуется на парочку токсичных коллег. Сценарий всегда одинаковый: Вася просит помощи на полдня, а в итоговом отчёте вдруг оказывается, что всё сделал он один; Петя слизывает идею, которой мой друг поделился «у кулера», и оперативно реализует её сам; кто-то отпускает колкие комментарии на дейликах или распускает сплетни за спиной.

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

(далее…)

А так ли необходимо техническое собеседование разработчику и как оценить опыт работы разработчика?

Трудно попасть на работу из-за собеседований

Трудно попасть на работу из-за собеседований

Вступление

(далее…)

Event Storming: как построить модель вокруг событий

­­­Какие предметы вам нравились в школе? Я очень любила математику.  Меня завораживали цифры, формулы и логические рассуждения. А самое главное, даже если решать задачу несколькими разными способами – единственно верный ответ всегда будет один. И проверив его, можно быть уверенным, что задача решена правильно.

Сейчас, проектируя программные системы, я тоже решаю задачи, но они принципиально отличаются от математических, где всегда есть единственно верное решение. Если в школе небольшого условия задачи было достаточно, при проектировании это не так. Как говорил итальянский программист Альберто Брандолини: (далее…)