Офис или удаленка? Личный опыт.

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

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

Дак как так случилось, если эксперимент получился удачным? Начну лично с моих проблем, а потом перейду к общим для команды.

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

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

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

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

А какой у вас был опыт удаленной работы? Какие были проблемы, а что понравилось больше, чем в офисе?

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

Стоит ли часто менять работу?

Современный рынок труда в ИТ - весьма конкурентное место с одной стороны и переполнено предложениями с другой. Какой же подход более оправдан для построения успешной карьеры, часто менять места работы или выбрать стабильность на одном месте?

Что говорит статистика?
Начнем с того, что разработчики на одном месте не проводят более 1.5 - 2 лет. Рынок вполне позволяет быть мобильным и переходить с ростом. Позиции, начиная с лидов и выше, работают несколько по-другому, но сейчас не будем на этом останавливаться. Я глобально не готов ругать или хвалить какой-то из подходов, но расскажу какие плюсы и минусы я нашел, попробовав оба.

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

Плюсы и минусы частых переходов между компаниями
Я выделили следующие плюсы:

- переходишь обычно с ростом дохода, в итоге может и небольшими (а иногда и большими) шагами прирастаешь по зарплате.

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

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

- обычно выгореть вы не успеете. Большая проблема современности - выгорание. При таком подходе с ней столкнуться труднее (хотя и года бывает вполне достаточно).

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

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

Плюсы и минусы продолжительной работы на одном месте
Плюсы:

- вы получаете возможность расти в глубину. Конечно это здорово попробовать много всего и разного, но не менее увлекательно копать в глубь. Например, только осев в компании надолго, я смог на практике разобраться в тонкостях работы с проектами под разными типами нагрузки, хорошо разобрался в том, как работает postgres и elasicsearch и т.д. Этот опыт для меня оказался ценнее, чем поверхностные изучения кучи разных технологий.

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

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

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

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

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

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

Особенности работы руководителя, которыми она отличается от разработки

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

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

Будьте готовы к прямолинейной обратной связи
Первое, к чему обычно не готовы, это к более прямой обратной связи. Ваши чувства значительно меньше щадят и думают о вашей ранимой душе, и высказывают все, как есть. Я за максимально прямые и честные коммуникации, поэтому меня это устраивает. Многих сильно это ломает и демотивирует в начале перехода на новую позицию. Я поясню, речь идет не про личные оскорбления или угрозы, а про то, что могут прямо сказать “ты пролюбил это и это, что встанет тебе вот таким боком”. Это будет не повод грустно пойти плакаться в угол, а повод либо принять к сведению и исправить, либо скорректировать руководителя, дав полный расклад. Еще раз, личные оскорбления недопустимы, угрозы, особенно переходящие в уголовщину, естественно тоже. Но прямая и честная обратная связь обижает многих, к этому надо просто быть готовым.

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

Умение отделять свои задачи от задач команды
Придется учиться отделять свои личные задачи и задачи всей команды. Что я имею ввиду? У вас скорее всего будет распланированный спринт / месяц / квартал и вы дружно идете по этому пути всей командой по выбранной вами методологии. Но также у вас будут и другие задачи, которые никак с этим не связаны. Ну например, составить описание вакансии требуемых вам людей, подготовить презентацию вашей команды или отдела, помочь руководителю по какому-то направлению и т.д. и т.п. Эти задачи упадут лично на вас и работа команды страдать не должна. Очень важно не путать то, за что отвечаете лично вы, с задачами команды, особенно в общении с руководством и отчетах заинтересованным лицам. Если команда хорошо идет по своим задачам и все успевает, а вы свои личные задачи не успеваете, то к проблемам команды это не относится. Частой ошибкой бывают жалобы руководителя на то, что в команду вкидывается слишком много задач, когда речь идет о его личных задачах, а не задачах команды. Такие ситуации нужно разбирать отдельно, не вмешивая команду. Как справляться с каждой такой задачей, нужно смотреть на конкретной проблеме. Вам нужно либо сразу отказываться от задачи, если вы не успеваете, либо искать возможности, а не оправдания. Желающим расти, всегда отказываться нельзя, но и силы надо оценивать адекватно. Также такие задачи обычно имеют дедлайн и никакие гибкие методологии, используемые в команде, вам тут не помогут.

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

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

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

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

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

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

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

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

#разработчику

Как я выбираю людей

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

Ответственность
Основная идея в том, что ты лично должен хотеть и быть готовым отвечать за результат доверенных тебе задач. Сюда входит и готовность искать пути решения, вовремя задать вопрос, высказать сомнение, если кажется, что выбран плохой вариант, проверить, что все работает, как нужно и т.д. Классическая проблема это перекладывание ответственности, когда люди сдают работу, особо не проверяя и не сверяя ее с требованиями. Естественно, ведь кто-то другой должен удостовериться, что все работает как надо. В результате, это приводит либо к затягиванию выкатки (из-за постоянных возвратов), либо к драматическому падению качества продуктов. Для понимания, я не призываю тут работать за других, но ты должен сделать все, чтобы довести задачу до требуемого уровня качества, привлечь, где нужно, коллег или руководство.

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

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

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

Субординация
Под этим пунктом я не имел ввиду парадигму “я начальник, ты дурак”. Тут заложен смысл о том, что все внутренние договоренности должны соблюдаться, пока они не были изменены. И ты не ставишь свое мнение выше мнения команды, а работаешь в рамках этой команды. Убедил всех - молодец. Также за начальником остается последнее слово в случаи спорных ситуаций (за моими я естественно тоже оставляю право финального слова). Если говорить о себе, то я не люблю залезать в те решения, которые на мой взгляд должны приниматься не мной. Но, если я вижу критичную проблему или есть неразрешимый спор, то беру это на себя.

Каждый сам ставит приоритеты и идет по ним, я поделился своим видением. Надеюсь вам было полезно.

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

Проявление силы в переговорах

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

Что я бы предложил в таких ситуациях:

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

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

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

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

Максим Шаламов
#советы

В чем смысл требовать опыт 1-2 года, если есть технические знания?

Столкнулась с таким вопросом в одном из чатов разработчиков: “Зачем в вакансиях требуют опыт 1-2 года, если у человека есть достаточно технических знаний, хоть он и не работал никогда?”. Давайте попробуем разобраться.

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

У меня на практике была одна очень показательная история. Я работа ведущим фронтенд-разработчиком на проекте. У меня в команде были мидл/джун разработчики. Одному из них пришла задача сделать в многострочном блоке в конце троеточие. Из коробки такая задача не делается, такой технической возможности нет. Если начать гуглить решения люди всячески изгаляются, но у всех решений есть минусы. Человек в итоге зашел в тупик и пришел ко мне с этой проблемой. Я решила проблему просто: придумала альтернативное решение - заменить троеточие на градиент внизу блока, который делается элементарно, мы сходили и договорились с дизайнером о новом подходе к отображению блоков, объяснив ситуацию.

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

Умение договариваться и аргументировать, почему надо сделать не так, а иначе, особенно с ребятами из бизнеса, тоже приходит с опытом, после десятков споров и обсуждений. Никогда нельзя забывать, что наши коллеги из бизнеса не могут знать какие там точки где не получится поставить. А это еще очень просто объяснить, обычно все намного сложнее. Как-то раз, я битый час объясняла начальнику-бэкендеру, к которому пришла за помощью ПМ, которая вообще ничего не могла понять, почему отрисовка слишком длинного списка может повлиять на производительность браузера. Ему никак не удавалось понять, в чем у меня проблема перебрать значения в массиве и вывести этот злосчастный бесконечный список, который просит ПМ. А ведь он тоже разработчик, ребята из бизнеса - люди вообще никак не связанные с разработкой, попробуйте им такое объяснить (ПМ тогда просто стояла и беспомощно хлопала глазами, мне ее был честно жаль). Тем не менее, наша задача, как разработчиков, вовремя вмешаться в задачу и умело донести, что вот так делать не надо, это будет плохо, а сделать лучше вот так. И иногда это бывает очень сложно. Мы собрали целый список подобных примеров с разборами, как и в какой ситуации объяснить ПО или ПМу, почему что-то нужно сделать так, а не иначе, ознакомиться можно тут.

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

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

Чем занят руководитель?
Очевидным ответом для многих является “ничем”, так же, как и очевидно, что все проблемы связаны с руководителем, а победы общие. Я видел достаточно руководителей, которые реально очень мало вкладывались в свою работу, но обычно все несколько сложнее.

Задачи руководителя
Что на мой взгляд делает руководитель:
- добывает необходимые ресурсы для достижения результата. И тут речь обо всем: от денег до людей.
формирует цели и метрики для команд и/или проектов (детали зависят от уровня руководителя и специфики).
- занимается ростом и развитием команды, напрямую растит -1 и частично -2.
- выстраивает процесс работы в рамках своей зоны ответственности (как минимум формулирует, что должно быть и добивается того, чтобы по факту это так и работало)
- подключается к решению нестандартных проблем и ситуаций, либо когда вообще не ясно, что делать, либо когда нужна помощь организовать или договориться.

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

Если про загруженность говорить в проектах, где до отлаженности еще далеко, то можно на основе своего календаря и людей, которых я знаю примерно смоделировать день руководителя.

Типичный день руководителя
Есть регулярная текучка, сюда входят встречи с руководством, встречи со смежниками, обсуждения и проработка участия в разных инициативах компании и т.д. Если вы склонны посещать только необходимые мероприятия и стараетесь делегировать там, где это уместно, то, допустим, со временем ваш календарь будет занят этим на 40% (я ставлю в календарь встречи для самого себя, когда хочу уделить время какой-то задаче). Дальше, я надеюсь, вы хотите понимать, как дела обстоят в ваших проектах и командах, сюда уходит еще 20% вашего времени (это при условии, что вы активно не перестраиваете команды или проекты). Конечно постоянно нужно работать с разными запросами и проблемами от команд: перемещение людей между командами, повышения, споры между командами, участие в согласовании больших релизов, работа с целями команд и т.д. Ну допустим это еще 15% отнимет, если повезет.

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

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

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

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

Что делать, если выбыл разработчик в середине спринта или релиза

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

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

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

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

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

1. Первое, что вам нужно сделать, это посмотреть на приоритеты своих задач в спринте,

2. Посмотрите на цель своего спринта, проверьте не страдает ли она из-за того, что выбыл разработчик.

3. Определить какие задачи были на выбывшем человеке, их приоритеты и их статус.

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

5. Обязательно оповестите своего владельца продукта и всех заинтересованных, о том, что выбыл человек, поэтому вместимость команды в этом спринте уменьшилась. Расскажите какие конкретно задачи из-за этого пострадали и не будут сделаны. Обязательно упомяните, что цель спринта не пострадала и все задачи с более высоким приоритетом будут готовы в срок.

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

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

Выгорание у джунов до старта работы - миф или реальность?

У каждого разработчика настает однажды такой момент, когда его все задолбало и хочется на дачу жарить шашлыки или пару недель позалипать в компьютерные игры. Ну вот кто нынче не выгорал? Но оказывается, чтобы выгореть не обязательно даже начинать работать. Пошла такая тенденция, что джуны, иногда даже без опыта работы, уже приходят на собеседование с историями о выгорании. Уже не раз слышала и от обучающихся еще разработке ребят: "что делать, помогите, три месяца учусь программированию, больше не могу...". Честно вам скажу, ребята, первая моя реакция на такое была в стиле "да что ты, сосунок, знаешь о выгорании?!". Но все не так просто. Разберемся с основными причинами, тем более, что они общие для всех.

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

Второе, это умение организации времени. Согласитесь, что даже опытные ребята не всегда это умеют, а что говорить про тех, кто только начал. Большинство гордиться своим умением сидеть за компом не вставая по 5-8-12 часов. Признаюсь, я сама через такую проблему прошла, к счастью Максим мне помог осознать свою проблему и теперь я сажусь за задачи с будильником, иначе не умею вовремя оторваться и сделать перерыв. Даже если вам кажется, что вы можете 5 часов не вставать и не отдыхать, поверьте, ваш организм не может. Не мучайте его и тоже заведите себе будильник. Заметите как стали меньше уставать и больше и качественнее работать. По циклу работы тут нужно подбирать под себя, но по классике в "методе помидора" цикл длится пол часа: 25 минут работа и 5 перерыв. Но делать цикл больше 90 минут я бы не советовала. И учтите, что чем длиннее шаг цикла, тем дольше нужен перерыв.

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

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

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

Многоэтапные собеседования - зачем?

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

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

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

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

Как я делегирую принятия решений о найме подчиненным
Лично я очень просто подхожу к вопросу делегирования принятия решений, я хожу какое-то время с выбранными ребятам на собеседования. В начале собеседования веду я, объясняю, что и зачем я спрашиваю, как принимаю решения, что важно на какую позицию и как правильно задавать вопросы и интерпретировать ответы. Потом я хожу в режиме слушателя, проверяю все ли ребята делают правильно. Затем я перестаю ходить на собеседования, но мы проводим разборы в случае найма неудачных кандидатов, если видна проблема или непонимание, повторяем цикл. Если говорить о своем старте лидом, то в Рамблере мне просто приводили людей, такой был процесс. В Сбере уже таких проблем не было, я сам отбирал себе людей и, с учетом самых высоких требований к кандидатам, за мной другие обычно не перепроверяли.

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

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

Зачем нужны спринты

Спор нужны ли вообще технической команде спринты далеко не нов. Кто-то живет вообще без них и прекрасно справляется. Так зачем тогда вообще нужны спринты? Что они дают команде?

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

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

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

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

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

Продолжение в следующем посте ⤵️

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

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

Должен ли руководитель уметь сам проверить работу каждого?

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

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

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

В целом, если вы рассматриваете работу лида как что-то лишнее и неинтересное, это история не для вас. А так работы вам хватит с горкой, еще будете искать кому ее делегировать.

Еще статьи по теме задач руководителя, которые уже есть на канале:

Нужны ли руководителю технические знания

Чем занят руководитель

Чем отличается руководитель от разработчика

Задачи тимлида и техлида

Мой путь от разработчика к СТО


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

Что делать, если тебя не уважают

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

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

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

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

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

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

Если хотите получать больше уважения от бизнеса, учитесь применять эти подходы. Больше про методы формирования уважения, представления своей работы и идей перед бизнесом, вы найдете в нашей документации к работе с PO и PM.

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

Как руководителю заставить подчинённых и коллег себя уважать

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

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

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

Подача
Подача себя. На встречах и в общении вы должны быть уверены в себе и последовательны. Высказывайте свое мнение, убеждайте в своей правоте, не бойтесь спорить (но не переходите на грубость и споры ради спора). Если вы не можете высказать и отстоять свое мнение (а для подчиненных и их в большинстве случаев тоже), то доверие и уважение внушать вы не сможете.

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

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

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

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

Говнокод или ступень роста

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

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

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

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

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

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

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