Начало поста

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

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

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

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

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

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

⬆️ Начало поста

Стендапы, как средство быстрого поиска проблем

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

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

На этом все с первой темой марафона. Если остались вопросы, обязательно пишите в комментариях! Сделаем отдельный разбор, если наберется достаточно вопросов. А также ждем ваших реакций и отзывов о первом дне, нам очень важна ваша обратная связь!

Вторая тема марафона "Успеть до Нового Года"
Как поставить точные сроки, в которые все таки уложишься

Видео: https://youtu.be/eHaBoYTHoro
Дополнительная тема: "Как проводить экспертную оценку для долгосрочного планирования"

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

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

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

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

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

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

- Ориентируйтесь на критерии I.N.V.E.S.T. Они помогут достигнуть правильного уровня декомпозиции и независимости задачи и сделать описание, готовое к оценке.

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


Как выполнить критерии I.N.V.E.S.T., создать уникальные для команды критерии готовности задачи к разработке и использовать формат пользовательских историй мы подробно с примерами рассказывали в своей книге “Гибкие методологии на практике”.

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

⬆️ Начало поста

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

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

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

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

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

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

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

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

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

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

На этом все со второй темой марафона. Если остались вопросы, обязательно пишите в комментариях! Сделаем отдельный разбор, если наберется достаточно вопросов.

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

Итоги недели и пара новостей

Мы с вами большие молодцы: закончили первую неделю марафона! Все оставшиеся материалы у нас уже везде запланированы и готовы к выходу, хотя иногда мы все таки что-то меняем в последний момент. На пример, мы видим по статистике и отзывам, что объем для Telegram получился слишком большой, поэтому 3 и 4 тема выйдут здесь только тезисами. Полностью можно будет прочитать на нашей сайте, а еще лучше посмотреть видео, там много примеров, которых нет в тексте.

Честно скажу, в марафон было вложено много труда и в подготовку материала и в съемки, и просто выложить все везде и нигде не запутаться это та еще задачка оказалась😄 И все это конечно же имеет смысл, только если мы видим, что материал вам полезен и получаем вашу обратную связь, которой нам, кстати, катастрофически не хватает. Поэтому я добавила вам вариантов реакций в канале, чтобы вы могли выражать больше разных эмоций под каждым постом. Теперь вам доступны: ❤️👌🏻🤷🏼‍♀️🤷‍♂️👍🏻👎🏻✍🏻🔥😡🥱😴🤔💩 Пользуйтесь на здоровье и конечно же, мы всегда очень ждем вас в комментариях и стараемся на каждый отвечать. Поверьте каждая ваша реакция, даже отсутствующая, влияет на то, что мы будем писать в будущем.

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

Всех с пятницей! 🎉

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

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

Видео: https://youtu.be/DISZbAebgC0

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

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

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

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

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

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

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

Что делать, если вы не знаете, как договориться с бизнесом и руководством? Эту тему мы разобрали отдельно на нашем Boosty: “Как убедить бизнес и руководство изменить состав релиза и что делать, если они не согласны?”.

Также на Boosty Максим разобрал реальный пример релиза и показал, что он обычно выносит из первой выкатки, если времени на все не хватает: "Пример, как СТО сокращает объем работ на релизе".

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

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

Четвертая тема марафона "Успеть до Нового Года"
Твои сроки срываются из-за соседнего отдела: что делать?

Видео: https://youtu.be/f-TtJFVWHvA

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

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

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

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

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

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

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

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

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

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

На этом мы заканчиваем наш марафон по работе со сроками! 🎉 Ждем ваших отзывов в комментариях, что было полезным, чего не хватило? Обязательно пишите, нам важно ваше мнение, оно повлияет на будущий контент на канале!

Мои уроки 2023 года

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

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

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

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

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

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

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

Максим Шаламов

Почему люди уходят из компании

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

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

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

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

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

Менее однозначные проблемы
Дальше пойдем к менее однозначным пунктам.

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

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

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

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

Что мешает хорошим технарям стать руководителями?

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

Начну с себя. Когда я развивался, как разработчик, для меня было очень важно умение погружаться в задачу и концентрироваться на ней. Это то, что многие называют состоянием “потока”. Одна из причин, по которой у меня хорошо получалось, это то, что я мог по 3-4 часа работать непрерывно, а в целом по дню выдавать до 7-8 часов именно написания кода. Делая отступление в сторону, не сильно рекомендую так делать, весьма выматываюший режим. Это была одной из причин, по которым я обычно успевал сделать очень много. И я привык так работать.

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

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

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

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

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

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

Допустим ли микроменеджмент? Какие последствия?

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

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

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

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

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

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

https://youtu.be/fOfnvP1NHp8

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

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

Разбор управленческого кейса Моники Геллер: что делать, если над тобой издевается собственная команда?

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

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

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

Все, что вы знали об Agile неправда

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

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

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

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

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

Как получить оффер: мои фишки прохождения собеседования

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

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

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

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

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

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

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

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

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