Почему твой ПО тебя ненавидит

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

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

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

Согласны с моим описанием или у вас другое видение? Делитесь в комментариях.

Александра Шаламова
#agile_который_работает

Как достучаться до ПО?

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

https://youtu.be/6ADYqwvcoYc

Да не заботитесь вы о команде!

Я часто слышу от ребят: “я забочусь о команде”, ”я переживаю о проекте” и тому подобное. А потом идет какое-то “но” или еще что-то, что человеку мешает. Сейчас я в разговорах концентрируюсь на первой части и всегда спрашиваю, а что ты сделал в рамках своей заботы / беспокойства / ответственности?

Заботишься о выгорании команды? А что сделано для улучшения планирования?
Заботишься о качестве проекта? А что сделано для улучшения этого качества?
И т.д. и т.п. Моя задача не утопить людей, а понять одну важную вещь: готовы ли они действовать или это просто слова и оправдание. Я могу им помочь, найти время, отстоять сроки и т.д. Но они сами должны этим заниматься и брать ответственность, иначе я просто вовремя не узнаю о проблеме.

Хотите разгрузить команду? Берите меньше задач, требуйте делать лучше постановку задач, работайте с ожиданиями - совершайте действия, чтобы исправить то, что вас беспокоит. Я готов помочь своим ребятам на каждом этапе, но только тогда, когда они заранее проанализировали, поняли, где проблемы, и тогда уже пришли за помощью, или они решают проблему, но их начали продавливать и им нужна помощь отстоять позиции. Сидеть и ждать, что за тебя все сделают, не сработает. Заботиться и команде, проекте и прочем, и ничего не делать для улучшения - не забота, это удобное оправдание для своей совести.

Максим Шаламов
#руководителю

Как проблемы в ИТ могут раком поставить весь бизнес? А вот так!

https://youtu.be/iX64kzEGL78

О чем мы писали в мае

Май подходит к концу, пора вспомнить, о чем мы с вами весь месяц говорили:

Почему важно думать о решении задачи заранее, а не в процессе

Видео "Что такое сторипоинты?"

Почему твой ПО тебя ненавидит

Видео "Как достучаться до ПО"

Да не заботитесь вы о команде!

Видео "Из-за ошибки ИТ СДЭК не работает 3 дня"

Спасибо, что были с нами этот май, оставайтесь на связи, мы готовим еще много материалов в следующем месяце. Не забывайте, что можете задать вопрос в нашего бота, чтобы мы его разобрали. Может быть у вас есть проблемы на работе? Или вы не можете решить куда двигаться дальше? Не знаете. как наладить работу в отделе или общение с коллегами? Пишите вопрос прямо сейчас и мы напишем разбор вашей проблемы.

💯 Стопроцентный способ убить проект

Столкнулась тут с мнением:
"Это всяким там Яндексам и Сберам нужны метрики, у них бюджеты большие, пользователей много, планирование сложное, а на нашем маленьком проекте, который еле выживает, какие метрики? Они все только усложнят. Мы работаем на драйве и доверии, а не на метриках."

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

Если Google выделит миллион на пиар-компанию и она провалится, он это переживет, исправит проблему и пойдет дальше. Если маленький стартапер, который взял кредит на разработку, потратит 100 000р на пиар-компанию и она провалится, его бизнес закроется. Если Amazon перенесет кнопку "купить" в неудобное место, у него конечно может упасть конверсия, но люди скорее всего, все равно найдут, как им купить эту злосчастную сковородку. Если приложение с 100-200 пользователями, о котором никто никогда не слышал, перенесет кнопку "скачать" на своем сайте-визитке, никто не будет ее там искать, все просто уйдут.

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

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

Александра Шаламова
#agile_который_работает #agile #метрики

4 признака, что тебе не стать руководителем

Мы тут с Максимом разговорились и подсчитали, что примерно 40% ребят в его команде, которые пробуют стать руководителями, не справляются с новой позицией и возвращаются к разработке. Я попросила Максима назвать главные причины, которые мешают его подчиненным перестроится на работу управленцем. Четыре самых главных из них вы найдете в видео:

https://youtu.be/fiq26llSdyQ

#руководителю

Ты хочешь чего-то стоить или просто уволиться?

Ребят, ну серьезно, меня бомбит от таких комментариев: "зачем мне чета делать, проще уволиться". Так и хочется ответить: "ну и сиди, как лох, когда ребята, которым не лень оторвать жопу от дивана говорят, что тебе делать, пока их не переманят в место поприкольнее, да в проект поинтереснее".

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

Или ты все таки хочешь быть тем человеком, который реально что-то может в своем деле? Который берет и делает круто, как никто другой не может. К которому прислушиваются коллеги. Который, не важно с какой позиции, говорит и команда делает, потому что понимает, что лучше его все равно никто не знает. К которому бизнес САМ приходит спросить "а стоит ли так делать или это плохая идея", потому что помнит, что прошлый раз именно ты их спас от провала. Неужели не хочется забыть про все эти выгорания и постоянное ощущение бессмысленности того, что ты делаешь, и хоть немного получать удовольствие от своей работы, хоть немного гордиться тем, что ты сам из себя представляешь? Но видимо не хочется, ведь проще уволится.

Александра Шаламова
#разработчику #крикдуши

Как я понял, что необходимо растить людей

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

Было время, когда мы втроем запускали проекты, делая все руками с минимальной помощью от остальных участников команды. Проекты росли и становились сложнее и интереснее. Стало понятно, что мы не можем сделать все, а с рынка взять много готовых мотивированных профессионалов не получится. Так мы начали инвестировать в людей и получили отличные результаты.

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

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

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

Максим Шаламов
#руководителю

Не бойся выглядеть дураком, бойся им быть

Вы знаете, я человек такой, люблю свое мнение говорить, поэтому вечно со всеми спорю. А что человек первым делом хочет сказать, если он с тобой не согласен? Правильно, что ты дурак. Ну а как иначе? Он что-ли не прав, а ты умный? Такого же не может быть. И вот сегодня мне в разговоре сказали очень интересную фразу: "Это надо знать, чтобы не выглядеть дурой!". Я так долго смеялась, что решила поделиться с вами мыслями.

Любое обучение требует времени и сил. Вы вливаете в себя какую-то информацию, а объем поглощаемых данных за день вполне себе ограничен. Кратковременная память не резиновая. Поэтому нельзя бездумно поглощать информацию, будет перегруз, мы устанем и что-то важное из головы вылетит. Чтобы с этим бороться, нужно осознанное потребление информации. Всякий мусор - лесом. Полезное запоминаем.

Так вот. Есть такие категории знаний, которые нужны только для того, чтобы ими понтоваться. Подобные знания преподносятся, как "база", их "стыдно не знать", но на деле они являются информационным мусором, вместо которого в вашей голове могло бы быть что-то полезное. А нужны они только для того, чтобы тешить свое эго, если больше нечем. Ну типа, ты подходишь к человеку и тебе хочется быть круче его, надо для этого его как-то унизить и ты говоришь "ты что не знаешь столицу Гондураса / седьмого президента США / имя третьей кошки Черчилля? Ты что серьезно? Ты что дурак?". Главное из 100500+ фактов выбрать именно тот, который он не знает, а ты знаешь (а можешь и не знать, просто скажи, что ты такую элементарную информацию даже говорить не собираешься, пусть гуглит).

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

Очень интересно узнать, что вы думаете по этому поводу? Обязательно делитесь в комментариях!

Александра Шаламова
#советы

Сменить работу не значит решить проблему

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

Собственно к чему это все? Многие бегают с работы на работу и каждый раз попадают в одни и те же проблемы. В итоге, удовлетворенность от работы на любом месте низкая, карьера идет не так, как хочется. Виноваты все вокруг, пойду вон к тем, там все по-другому. На самом деле, чтобы прийти к чему-то другому, нужно поменять себя. Тогда вы будете выбирать коллег и компании по-другому, смотреть на другие вещи и сможете решать типовые проблемы. А решать проблемы придется всегда, на любой позиции. Повышения, интересные задачи, новые вызовы, зоны роста - все это нужно уметь стабильно получать, уметь где-то подождать, а где-то с опытом понимать, что твоих сил изменить компанию недостаточно и тогда действительно идти дальше.

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

Максим Шаламов
#советы #разработчику #руководителю

Вышел подкаст "Люди и Код" с участием Максима про кадровый голод в ИТ. Много говорили про найм, курсы для разработчиков, советы начинающим и опытным айтишникам и многое другое.

117-й выпуск подкаста

Кадровый голод в IT: насколько он силён и почему десятки тысяч джунов не могут его утолить

Слушать:
YouTube
Яндекс.Музыка
mave
Apple
Castbox
Google Podcasts
VK

⚠️ Осторожно: акустические помехи!

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

Содержание

— Насколько силён кадровый голод в IT
— Как в «Сбере» решают эту проблему
— «Люди не понимают, куда они пришли»: что не так с курсами по программированию и почему, по мнению гостей, многие их выпускники не готовы к работе
— С одной стороны, отечественные компании жалуются на нехватку специалистов, с другой — тысячи джунов не могут найти работу. Почему бы не решить одну проблему за счёт другой?
— Про неоправданные ожидания от работы в IT и враньё в резюме
— Советы тем, кто ищет первую работу
— Что дешевле — найти специалиста на рынке или вырастить его самому?
— Проблемы в коммуникациях между HR и понимающими разработчиками
— Как наладить HR-процессы, чтобы хантить лучших специалистов
— Помогает ли бренд «Сбера» в поиске сотрудников
— Советы опытным айтишникам

Гости:

Максим Шаламов
IT-лидер трайба управления зарплатными проектами в «Сбере», ex-CTO ТАСС.
Управляет IT-командами и подбирает специалистов более 10 лет.

Максим Корнилов
Head of Ops в ДИТ «Сети продаж» «Сбера». Занимается организацией процессов сопровождения SRE/DevOps. В отрасли более 20 лет.

Вы не должны перерабатывать, чтобы хорошо работать

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

Хорошо работать у большинства ассоциируется с переработками. Да есть у нас такое ошибочное мышление, если Вася работал в выходные, значит он хороший работник, надо его повысить. Но "много" не имеет ничего общего с "хорошо". А даже наоборот. Чем хуже вы что-то сделали, тем больше вам прилетает дополнительной работы: правки, баги, доработки. В итоге, именно "плохо работал" обычно превращается в "много работал". Хотите работать мало? Делайте сразу нормально и думайте наперед. Лучше сделать чуть больше в первый раз, чтобы следующие похожие задачи шли быстрее, чем сделать быстро одну, но повторять все тоже самое еще 10 раз.

Поверьте, никому ни разу еще не позвонили в 3 часа ночи, чтобы сказать: "чувак, ты так хорошо и надежно написал свой код, что он все еще работает без проблем, так что давай вставай и смотри с нами, как он хорошо работает". А вот если вы написали так, что все развалилось, вот тогда вам точно придется вставать и все исправлять, а утром снова тащиться на работу, чтобы снова сделать хреново и снова потом сидеть в нерабочее время исправлять. И не надоедает ведь.

Не согласны? Тогда жду в комментариях.

Александра Шаламова
#советы #разработчику

Отличный способ стать лучшим специалистом за июль

Почему наша книга "Гибкие методологии на практике" это отличное вложение в свою карьеру? Вы знаете, сейчас Agile популярен, его внедряет большинство крупных ИТ-компаний, Яндекс, ВК, Сбер, Авито - куда не придешь, везде будут стендапы, планирования, ретро, канбан-доски и другая Agile-атрибутика. Мы все это используем каждый день и вроде все это уже настолько нам знакомо, что каждый знает, что нужно делать.

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

Насмотревшись на все это годами и набив шишки, приводя в порядок работу в собственных командах, мы с Максимом собрали решения самых ходовых проблем Agile-команд и разобрали их в том виде, в котором они реально работают на практике. Так и появилась наша книга "Гибкие методологии на практике".

Кому она будет полезна? Да буквально всем, кто хоть как-то работает в Agile-среде. Она помогает из человека, не понимающего, зачем его таскают на какие-то бесполезные встречи и не дают работать, превратиться в эксперта по ведению процессов, который не тратит свое и чужое время, а использует каждый инструмент Agile максимально эффективно. Тем, кто уже хорошо разбирается в теме, книгу можно использовать, как справочник по основным техникам работы с задачами, планирования, приоритезации и метрикам. А еще книга научит не позволять собой манипулировать с помощью цитирования Agile-манифеста (да, к сожалению, так часто делают, заставляя вас перерабатывать, где не надо).

Купить книгу можно у нас на сайте. А на Boosty вы можете посмотреть пример главы с объяснением, как строится приоритезация задач. Готовы за июль стать лучшим специалистом, чем были в июне? Тогда вперед!

2 главных секрета успешной карьеры

Понедельник - самое время начать добиваться своих целей! 💪

https://youtu.be/HtR_vPya_0A?si=i7DdWcWgKnhk1d9Q

Почему не надо 10 лет работать разработчиком, чтобы стать руководителем разработки?

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

Погружение в специфику нужно
Давайте сделаю отступление, что в любом случае, став руководителем команды, нужно какое-то погружение в специфику работы и проекта, понимать общие вещи и способы решать проблемы. Есть места, где просто не выделяют отдельно такую роль / позицию, и там вариантов вообще нет. Это полезно, но не будет критичным.

Управление – другая профессия
Давайте я объясню, что не так в целом с мнением, что сначала нужно отработать 10 лет в разработке. Первое, управление командой это просто другая работа. Руководить кем-то или чем-то это не тоже самое, что выполнять задачи в этой же сфере. Поэтому хоть 50 лет проведи разработчиком, руководить ты от этого не научишься.

Все технологии отдела выучить невозможно
У нас сейчас тенденция к полнофункциональным командам, то есть там будут специалисты разных областей знаний. Никакой жизни не хватит все учить по 10 лет, да и остальное уже будет не актуально через 10 лет.

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

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

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

А что учить вместо 10 лет разработки?
Если хотите стать руководителем, то нужно набираться именно управленческих знаний. Как раз для таких случаев я писал свой учебник для начинающих руководителей технических команд, чтобы дать всю нужную начальную информацию разработчику, который решил перейти в управление, но еще не знает, как это сделать. Если задумываетесь об управлении, то берите учебник – не пожалеете.

Максим Шаламов
#разработчику #руководителю

Стрессоустойчивость правда так важна для руководителя?

Часто встречаю истории, что руководитель, получая негативную обратную связь, проблемы на проекте, проблемы с сотрудниками или какие-то подковерные игры, теряет аппетит, сон и настроение. В итоге: потеря мотивации, выгорание, увольнение. Такая ситуация большая проблема и большой вызов для любого руководителя. Всегда что-то идет не так, всегда кто-то не доволен, что-то ломается (можно дойти до состояния, когда работает как положено и все равно исключений будет много).

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

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

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

Максима Шаламов
#руководителю

Учу бизнес управлять разработкой, как скотом

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

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

Во-вторых, руководитель действительно иногда может не иметь возможности дать вам другой должность или больше денег прямо сейчас. Это зависит от огромного количества факторов: финансовое положение компании и конкретного отдела в данный момент, бюджет на разработку до конца года кончился, проект не приносит прибыли и т.д и т.п. Но! Есть огромная разница между сказать вам "денег нет, но вы держитесь" или предложить альтернативу. Предложить другие задачи, новые обязательности, неформальных подчинённых и т.д. Первое значит, что вы нафиг тут не нужны, по крайней мере дороже, чем есть. Второе, что в вас заинтересованы, вас ценят и готовы вам что-то давать взамен! Если вас не ценят, никто не будет и пальцем шевелить что-то для вас придумывать.

Чем это отличается от манипуляции? Это не пустые обещания, это реальные действия, которые дают вам реальную пользу. Да, вы не получили должность, которую вы хотели. Но если вы без опыта начнёте искать работу, вам будет сложно, а если вы пол-года поработаете на новых задачах этой должности, делая все тоже самое, просто не имея формальной лычки, вы сможете и на вопросы ответить на собеседовании и в резюме это спокойно написать. Берите, когда вам дают и пользуйтесь. Поверьте, вокруг вас тысячи людей, которым никогда ничего не предлагали взамен отказа.

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

Александра Шаламова
#советы