Вступление

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

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

Вы ответственный человек — человек, на которого можно положиться, который сделает всё, что от него ожидается и даже больше. Поздравляю! Тут есть ещё кое-какая работа для вас.

Без правильной обратной связи в команде даже успешные компании могут недополучать до 22% выручки. К такому выводу пришли исследователи из Gallup и Workplace Medicine. Культура продуктивного фидбэка внедряется по двум направлениям: постоянное обучение сотрудников правилам обратной связи и организация системы обратной связи.

в последние годы компании начинают внедрять системы непрерывной обратной связи. Среди крупных компаний пионерами были Deloitte и Adobe. В результате в Adobe снизилось количество увольнений по собственному желанию, руководители и сотрудники стали чувствовать себя комфортнее, а благодаря увеличению вовлеченности в работу выросла и эффективность. Еще одно интересное следствие — люди, которые регулярно дают обратную связь, чаще становятся успешными лидерами.

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

— Личная производительность может повыситься на 39%.

— Количество прогулов может снизиться на 41%, а текучка — на 59%.

— Эффективность руководителей может вырасти на 71%.

— Удовлетворенность клиентов — на 10%.

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

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

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

Все понимают, что shit happens — и чаще всего не если, а когда. У нас может быть много девяток в SLA, но 100% ни у кого нигде никогда не бывает. Поэтому, когда этот SHIT все-таки HAPPENS, есть два пути. 

Путь первый — проблему можно скрыть, сделав выводы для себя. Под ковер замели — никто ничего не заметил. А тому, кто заметил, сказать: «Да вам показалось, все нормально!» Можно пойти по второму пути: не врать и не бояться. Для этого, конечно, нужна уверенность в себе и своей компетенции. Тогда мы спокойно тушим пожар, а не прикрываем пятую точку (может, даже не свою). 

Я — за второй путь. На конференции HighLoad++ Весна 2021 я рассказал, что можно сделать уже сейчас, чтобы спасение прода прошло максимально безболезненно и почему доверие пользователей — это важно. Видео выступления можно посмотреть здесь, а под катом вы найдете, как заранее подготовиться к инцидентам.

Пользователи всегда узнают о проблеме. И будет лучше, если от вас. Потому что, как сказал Чак Паланик: «То, что мы не понимаем, мы можем понимать, как нам угодно». Если мы получаем обрывки информации о какой-то недоступности, мы трактуем ее как угодно, делая выводы, далекие от правды. После чего, понятно,  мы уже не доверяем.

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

На конференции HighLoad++ Весна 2021 я рассказал, как выстроить коммуникации, чтобы пользователи были на вашей стороне и не отвлекали вас от «пожарного» спасения прода. По мотивам доклада выпустил первую часть, а сегодня поговорим о том, как вести коммуникацию с пользователями, зачем это нужно и о чем говорить, когда вроде бы не о чем  Видео выступления можно посмотреть здесь.

Когда всё падает — это нормально. Особенно в IT. Даже Марку Цукербергу периодически приходится извиняться, когда сбой в работе соцсетей приводит к миллиардным потерям. Надеемся, что у вас таких потерь не будет, поэтому поговорили с разработчиками, тимлидами и менеджерами. Спросили, что и как нужно делать, когда всё плохо, чтобы не навредить карьере. 

Кто-то говорит, что в компании главный актив и ресурс — люди, кто-то — средства производства, прагматичные ребята всё сводят к деньгам. И только самые умудрённые опытом знают точно: в компании всё решает доверие. Если его нет, не сложатся отношения с людьми, будут неэффективно использованы средства производства, а деньги станут причиной постоянных споров и раздоров. Только давайте прямо с первого абзаца не будем путать доверие, вседозволенность, раздолбайство и слабую волю руководителя. Доверие — это взаимное чувство уважения, осознание возможностей друг друга и отсутствие страха и стыда перед чужими поступками, перед потенциально неосторожными действиями. 

Казалось бы, как просто: ты доверяешь сотрудникам, они — тебе, вы активно работаете над общими целями и задачами, совместно находите самые успешные решения, каждый получает по труду, все довольны, никто не обижен. (Ой, кажется, я переизобрёл социализм, где моя борода?) Но идеальным сущностям не суждено случиться: увы, обжегшийся один раз руководитель теряет доверие даже к преданным сотрудникам и восстановить его сложно. Порой почти невозможно.

Фраза “Мы живем в удивительные времена” стала грустноватым клише. И некоторое время назад многие работники IT-сферы серьезно задумались о миграции (утверждение, написанное в мае 2022, сейчас звучит еще наивнее).

Сам миграционный топик довольно серьезно исследован на хабре - можно найти массу прекрасных историй об успешных (и не очень) переездах, о компаниях и странах. Мое личное мнение состоит в том, что миграция - сложное решение с длинным списком плюсов и минусов. Думаю, многие согласятся: даже при смене компании есть множество подводных камней и рисков. Если же к этому добавить смену страны/культуры, то все становится еще более веселым. Но чего же, все-таки, стоит ожидать? В этой статье я попробую дать комментарии по разным аспектам рабочих процессов “у нас” и “у них”.

Все мы стараемся сделать качественный сервис и хотим гордиться своим проектом. И для этого прибегаем к техническим решениям: автотестам на разных уровнях, оценке покрытия, сбору и анализу метрик. Это отличные активности, которые помогают проекту стать лучше. 

Но помимо hard-инструментов есть и soft-составляющая. Она не столь очевидна, но тоже помогает повысить качество сервиса. Меня зовут Николай Котов, я старший QA-инженер в Тинькофф и сегодня расскажу, как социальные связи влияют на качество проекта, и поделюсь советами по укреплению этих связей.

Забота об атмосфере в команде в большей степени лежит на тимлиде или продакт-менеджере, но работать над ее улучшением могут все. Если вам интересна эта тема, предлагаю вместе в ней разобраться.