https://youtu.be/fOfnvP1NHp8
Ребята, мы тут обычно ничего не постим по коду, но на нашем YouTube и Дзене выходят периодически фронтовые видео. А это видео с примером декомпозиции проекта вообще может быть полезно всем.
Сейчас мы делаем наш новый проект и за одним планируем снимать много видео с процессом разработки на Vue, если вам эта тема интересна, то приходите смотреть. Во вторник, на пример, выйдет видео по подключению нестандартных шрифтов к сайту.
Ребята, мы тут обычно ничего не постим по коду, но на нашем YouTube и Дзене выходят периодически фронтовые видео. А это видео с примером декомпозиции проекта вообще может быть полезно всем.
Сейчас мы делаем наш новый проект и за одним планируем снимать много видео с процессом разработки на Vue, если вам эта тема интересна, то приходите смотреть. Во вторник, на пример, выйдет видео по подключению нестандартных шрифтов к сайту.
YouTube
С чего начать фронтовый проект? Пример декомпозиции по дизайну.
Показываю на примере, как имея только дизайн проекта составить план работ. Хороший способ перейти от прокрастинации к первой задаче.
Телеграм: https://t.me/+AVC7LV1SLnA3NWFi
Наши обучающие материалы: https://oros-it.ru/courses?utm_source=youtube
Телеграм: https://t.me/+AVC7LV1SLnA3NWFi
Наши обучающие материалы: https://oros-it.ru/courses?utm_source=youtube
Разбор управленческого кейса Моники Геллер: что делать, если над тобой издевается собственная команда?
Помните, как Моника из сериала "Друзья" стала шеф-поваром ресторана "Алессандро" и над ней издевалась вся команда? Многие в принципе не хотят становиться руководителями, боясь, что окажутся в подобной ситуации. Насмешки и чувство собственного бессилия могут напугать любого. А ведь личные качества Моники, которые привели к этой ситуации, есть у многих из нас. И если кетчупом в ИТ-компании вас вряд ли обольют, то неуправляемая команда и отсутствие уважения к руководителю, может коснуться каждого.
На примере Моники мы разобрали, что стало причиной такого отношения и как справляться с подобной ситуацией на практике. Разбор получился очень подробным и полностью объясняет, как из неуправляемого нечто сделать отлично работающую команду.
Найти разбор вы можете на нашем Boosty по подписке для дополнительных материалов. Такие разборы на Boosty мы планируем делать раз в месяц, пишите, кого еще вам хотелось бы разобрать?
Помните, как Моника из сериала "Друзья" стала шеф-поваром ресторана "Алессандро" и над ней издевалась вся команда? Многие в принципе не хотят становиться руководителями, боясь, что окажутся в подобной ситуации. Насмешки и чувство собственного бессилия могут напугать любого. А ведь личные качества Моники, которые привели к этой ситуации, есть у многих из нас. И если кетчупом в ИТ-компании вас вряд ли обольют, то неуправляемая команда и отсутствие уважения к руководителю, может коснуться каждого.
На примере Моники мы разобрали, что стало причиной такого отношения и как справляться с подобной ситуацией на практике. Разбор получился очень подробным и полностью объясняет, как из неуправляемого нечто сделать отлично работающую команду.
Найти разбор вы можете на нашем Boosty по подписке для дополнительных материалов. Такие разборы на Boosty мы планируем делать раз в месяц, пишите, кого еще вам хотелось бы разобрать?
Все, что вы знали об Agile неправда
Первое, что я в своей жизни узнала из Agile, были ежедневные стендапы в Яндексе в 2013 году. До этого я работала только в небольших отделах, которые вообще не пытались что-то делать с процессами, а работали как придется. Думаю большинство из нас именно так училось работать с задачами, повторяя за коллегами постарше и впитывая процессы своей текущей компании. Меня ни раз спрашивали на собеседованиях, какую последнюю книгу по разработке я прочитала, на какие ресурсы для разработчиков я подписана, но ни разу никто не интересовался, как я получаю знания об умении работать.
Мне тоже долго время казалось, что процессы это итак всем очевидная вещь. Однако, я начала что-то подозревать, когда об этих очевидных вещах мы с коллегами часами спорили на каждой встрече (Подумайте сколько стоит компании всего лишь один час споров о том, что такое цели спринта 10 человек? А во сколько бы вы оценили час своей собственной жизни?). Постоянные изменения условий задач во время разработки, переработки, огромное количество встреч, из-за которых некогда делать свою работу, систематическое нарушение сроков и переделки задач - это тоже все признаки непонимания, как работать с процессами, и их можно встретить практически в любой компании. В свое время я и вовсе разочаровалась в Agile, потому что видела, что компании, которые его применяют, работают неэффективно и мне самой не нравится так работать. Но все изменилось, когда я поняла в чем реальная суть и ценность Agile.
Проблема в том, что все обучения, которые проводятся в наших компаниях по процессам не стыкуются с той реальностью, которую мы каждый день наблюдаем. Мы вроде бы изучаем техники, но они постоянно конфликтуют с тем, что мы делаем на практике, все время остаются вопросы, что-то не сходится. В какой-то момент, мы с Максимом начали смотреть более глубоко информацию по Agile, в том числе, как он применяется в иностранных компаниях и расшифровывается гуру гибких методологий. Мы пытались выяснить: правда ли сама методология не работает или у нас неправильные вводные. Внезапно, мы обнаружили, что в большинстве наших компаний мы используем Agile вообще не так, как он задуман. И что ответы на те вопросы, которые нам мешают работать, уже есть, их просто нужно взять и использовать. Большинство команд передают друг другу или получают на обучениях лишь знания о конкретных техниках, они берут эти техники и натягивают их на свое привычное мышление и ежедневные проблемы, получая монстра, который не работает. А что мы получаем в результате, лично для себя, работая в таких командах? Мы работаем неэффективно, мы выматываемся, мы устаем от проекта, мы выгораем, мы увольняемся, а в новой компании все повторяется по кругу. В итоге мы разочаровываемся и виним технологию, а надо искать ее правильное применение в нашей каждодневной жизни.
В общем-то это одна из основных причин, по которой появился этот канал, чтобы рассказать о том, как взять правильное мышление и рабочие подходы, и применить их к нашей жизни и нашей реальности. Потому что она тоже отличается от международной и не все подходит нам из коробки. Именно по этой причине мы написали свою книгу про гибкие методологии, чтобы собрать и упорядочить то, что реально опробовано и работает в наших живых командах. Командах со своими вопросами, своими проблемами и своим менталитетом, уникальным для каждой отдела. Да, этому не учится каждый первый, возможно каждому первому это и не нужно (кого-то же должны использовать бизнес и компании, как им вздумается), этому не научишься за один день, но тот, кто встал на этот путь, откроет для себя дверь на новый уровень, недоступный большинству. А там уже каждому решать за себя, каким путем ему идти.
Александра Шаламова
#agile_который_работает
Первое, что я в своей жизни узнала из Agile, были ежедневные стендапы в Яндексе в 2013 году. До этого я работала только в небольших отделах, которые вообще не пытались что-то делать с процессами, а работали как придется. Думаю большинство из нас именно так училось работать с задачами, повторяя за коллегами постарше и впитывая процессы своей текущей компании. Меня ни раз спрашивали на собеседованиях, какую последнюю книгу по разработке я прочитала, на какие ресурсы для разработчиков я подписана, но ни разу никто не интересовался, как я получаю знания об умении работать.
Мне тоже долго время казалось, что процессы это итак всем очевидная вещь. Однако, я начала что-то подозревать, когда об этих очевидных вещах мы с коллегами часами спорили на каждой встрече (Подумайте сколько стоит компании всего лишь один час споров о том, что такое цели спринта 10 человек? А во сколько бы вы оценили час своей собственной жизни?). Постоянные изменения условий задач во время разработки, переработки, огромное количество встреч, из-за которых некогда делать свою работу, систематическое нарушение сроков и переделки задач - это тоже все признаки непонимания, как работать с процессами, и их можно встретить практически в любой компании. В свое время я и вовсе разочаровалась в Agile, потому что видела, что компании, которые его применяют, работают неэффективно и мне самой не нравится так работать. Но все изменилось, когда я поняла в чем реальная суть и ценность Agile.
Проблема в том, что все обучения, которые проводятся в наших компаниях по процессам не стыкуются с той реальностью, которую мы каждый день наблюдаем. Мы вроде бы изучаем техники, но они постоянно конфликтуют с тем, что мы делаем на практике, все время остаются вопросы, что-то не сходится. В какой-то момент, мы с Максимом начали смотреть более глубоко информацию по Agile, в том числе, как он применяется в иностранных компаниях и расшифровывается гуру гибких методологий. Мы пытались выяснить: правда ли сама методология не работает или у нас неправильные вводные. Внезапно, мы обнаружили, что в большинстве наших компаний мы используем Agile вообще не так, как он задуман. И что ответы на те вопросы, которые нам мешают работать, уже есть, их просто нужно взять и использовать. Большинство команд передают друг другу или получают на обучениях лишь знания о конкретных техниках, они берут эти техники и натягивают их на свое привычное мышление и ежедневные проблемы, получая монстра, который не работает. А что мы получаем в результате, лично для себя, работая в таких командах? Мы работаем неэффективно, мы выматываемся, мы устаем от проекта, мы выгораем, мы увольняемся, а в новой компании все повторяется по кругу. В итоге мы разочаровываемся и виним технологию, а надо искать ее правильное применение в нашей каждодневной жизни.
В общем-то это одна из основных причин, по которой появился этот канал, чтобы рассказать о том, как взять правильное мышление и рабочие подходы, и применить их к нашей жизни и нашей реальности. Потому что она тоже отличается от международной и не все подходит нам из коробки. Именно по этой причине мы написали свою книгу про гибкие методологии, чтобы собрать и упорядочить то, что реально опробовано и работает в наших живых командах. Командах со своими вопросами, своими проблемами и своим менталитетом, уникальным для каждой отдела. Да, этому не учится каждый первый, возможно каждому первому это и не нужно (кого-то же должны использовать бизнес и компании, как им вздумается), этому не научишься за один день, но тот, кто встал на этот путь, откроет для себя дверь на новый уровень, недоступный большинству. А там уже каждому решать за себя, каким путем ему идти.
Александра Шаламова
#agile_который_работает
Как получить оффер: мои фишки прохождения собеседования
Хочу рассказать вам подходы к собеседованиям на разработчика, которые помогают мне получать оффер с большинства встреч. Я расскажу со стороны кандидата, что именно мне помогает.
Правильный настрой
Самое самое важное, что у вас должно быть на собеседовании это правильный настрой. Все знания и подготовка пойдут коту под хвост, если вы правильно не настроитесь. Поверьте, ваш настрой виден и создает впечатление о вас. Поэтому я стараюсь максимально сосредоточится и откинуть все мысли о результате и страхе опозориться, вы все это переживете. Вы идете показать себя и посмотреть на других, вам не обязательно быть идеалом, вы можете ошибиться, дайте себе на это право и максимально расслабьтесь. Это поможет вам выдать свой максимум.
Подготовка
Как-то у нас сменилось начальство в компании, мы все по очереди увольнялись и обсуждали с коллегами подготовку к собеседованиям. Один коллега посмотрел на нас удивленными глазами и спросил: "а вы что готовитесь к собеседованиям? Типа как к экзамену, что-ли?". Да, чтобы хорошо пройти собеседование туда, куда вам нужно, вам надо к нему готовится. Особенно в начале карьеры это просто необходимо. Но даже разработчик с опытом может забыть элементарные вещи, если не будет их повторять. Как готовится? На самом деле в интернете давно есть списки вопросов, можно начать с них. Потом записывать каждый вопрос с собеседования, на который вы не смогли ответить и разбирать его. Так вы накопите свою базу и закроете свои пробелы. Кстати, отличная возможность общаться с другими увольняющимися коллегами, узнаете, что сейчас в моде спрашивать заранее.
Правильный отбор компаний
Мы уже ни раз писали про то, как выбирать компании на собеседовании(тут и тут), но самый начальный отбор нужно делать вообще до собеседования. Если вы видите, что компания вообще не вашего уровня, что их требования или проекты не совпадают с вашими интересами, просто не тратьте свое время. Разговор не пойдет, если вы изначально ориентируетесь на разное. Полезно сходить в компании, к которым вы стремитесь, но еще не готовы, но к тем, которые вы уже переросли смысла идти нет.
Представление себя
Подумайте, как вы себя преподносите потенциальному работодателю. Начинайте еще с резюме: изложите все свои достижения на каждом месте работы, расскажите, чем конкретно вы занимались, какие крупные задачи можете отметить. В идеале, по вашему опыту не должно быть вопросов после прочтения резюме, но кто ж его будет читать... Поэтому обязательно подготовьте устный рассказ о своем прошлом опыте. Выберите лучшие примеры и смело рассказывайте, как вы себя проявили. Также к собеседованию подберите подходящую одежду, выглядите опрятно, но не переборщите.
Уважение к прошлым работодателям
Осторожно отвечайте на вопросы почему вы ушли с предыдущих мест работы. Не стоит откровенно ругать прошлого работодателя, иначе новый решит, что про них вы будете потом рассказывать что-то подобное. Однако, это хороший момент, чтобы выяснить, отличается ли новая компания от предыдущей. Корректно опишите основную причину и задайте вопросы, как это работает у них в компании.
Спрячьте свое эго
Да, мы все тут крутые ребята, и каждый лучше всех знает свою работу. Но забудьте об этом на время собеседования. Отслеживайте надменность и самодовольство, и старайтесь их избегать. Если на собеседовании возник спор по поводу кода, хороший вариант попросить проверить решение на компьютере. Но скорее всего вас все равно после этого уже не позовут. Мало кто готов признать свою неправоту и продолжить работать с человеком, который ущемил его эго. Если не готовы отказываться от оффера ради спора, то просто уверено скажите ваше правильнее решение и оставьте человеку право ошибаться. Но помните, что это хорошая возможность оценить будущих коллег, ведь вам с ними тоже еще работать.
Если вы уже задумались над очередной сменой работы, для начала посмотрите наш мини-курс по борьбе с рутиной. Он поможет разогнать скуку на текущем месте и оставаться классным, востребованным специалистом.
Александра Шаламова
#разработчику #советы
Хочу рассказать вам подходы к собеседованиям на разработчика, которые помогают мне получать оффер с большинства встреч. Я расскажу со стороны кандидата, что именно мне помогает.
Правильный настрой
Самое самое важное, что у вас должно быть на собеседовании это правильный настрой. Все знания и подготовка пойдут коту под хвост, если вы правильно не настроитесь. Поверьте, ваш настрой виден и создает впечатление о вас. Поэтому я стараюсь максимально сосредоточится и откинуть все мысли о результате и страхе опозориться, вы все это переживете. Вы идете показать себя и посмотреть на других, вам не обязательно быть идеалом, вы можете ошибиться, дайте себе на это право и максимально расслабьтесь. Это поможет вам выдать свой максимум.
Подготовка
Как-то у нас сменилось начальство в компании, мы все по очереди увольнялись и обсуждали с коллегами подготовку к собеседованиям. Один коллега посмотрел на нас удивленными глазами и спросил: "а вы что готовитесь к собеседованиям? Типа как к экзамену, что-ли?". Да, чтобы хорошо пройти собеседование туда, куда вам нужно, вам надо к нему готовится. Особенно в начале карьеры это просто необходимо. Но даже разработчик с опытом может забыть элементарные вещи, если не будет их повторять. Как готовится? На самом деле в интернете давно есть списки вопросов, можно начать с них. Потом записывать каждый вопрос с собеседования, на который вы не смогли ответить и разбирать его. Так вы накопите свою базу и закроете свои пробелы. Кстати, отличная возможность общаться с другими увольняющимися коллегами, узнаете, что сейчас в моде спрашивать заранее.
Правильный отбор компаний
Мы уже ни раз писали про то, как выбирать компании на собеседовании(тут и тут), но самый начальный отбор нужно делать вообще до собеседования. Если вы видите, что компания вообще не вашего уровня, что их требования или проекты не совпадают с вашими интересами, просто не тратьте свое время. Разговор не пойдет, если вы изначально ориентируетесь на разное. Полезно сходить в компании, к которым вы стремитесь, но еще не готовы, но к тем, которые вы уже переросли смысла идти нет.
Представление себя
Подумайте, как вы себя преподносите потенциальному работодателю. Начинайте еще с резюме: изложите все свои достижения на каждом месте работы, расскажите, чем конкретно вы занимались, какие крупные задачи можете отметить. В идеале, по вашему опыту не должно быть вопросов после прочтения резюме, но кто ж его будет читать... Поэтому обязательно подготовьте устный рассказ о своем прошлом опыте. Выберите лучшие примеры и смело рассказывайте, как вы себя проявили. Также к собеседованию подберите подходящую одежду, выглядите опрятно, но не переборщите.
Уважение к прошлым работодателям
Осторожно отвечайте на вопросы почему вы ушли с предыдущих мест работы. Не стоит откровенно ругать прошлого работодателя, иначе новый решит, что про них вы будете потом рассказывать что-то подобное. Однако, это хороший момент, чтобы выяснить, отличается ли новая компания от предыдущей. Корректно опишите основную причину и задайте вопросы, как это работает у них в компании.
Спрячьте свое эго
Да, мы все тут крутые ребята, и каждый лучше всех знает свою работу. Но забудьте об этом на время собеседования. Отслеживайте надменность и самодовольство, и старайтесь их избегать. Если на собеседовании возник спор по поводу кода, хороший вариант попросить проверить решение на компьютере. Но скорее всего вас все равно после этого уже не позовут. Мало кто готов признать свою неправоту и продолжить работать с человеком, который ущемил его эго. Если не готовы отказываться от оффера ради спора, то просто уверено скажите ваше правильнее решение и оставьте человеку право ошибаться. Но помните, что это хорошая возможность оценить будущих коллег, ведь вам с ними тоже еще работать.
Если вы уже задумались над очередной сменой работы, для начала посмотрите наш мини-курс по борьбе с рутиной. Он поможет разогнать скуку на текущем месте и оставаться классным, востребованным специалистом.
Александра Шаламова
#разработчику #советы
О чем мы писали в январе
Если что-то пропустили в этом месяце, вот о чем мы писали:
Почему люди уходят из компании
Что мешает хорошим технарям стать руководителями?
Допустим ли микроменеджмент? Какие последствия?
Все, что вы знали об Agile неправда
Как получить оффер: мои фишки прохождения собеседования
Также добавили дополнительный материал на нашем Boosty с разбором кейса руководителя, которого не слушаются и над которым надсмехаются собственные подчиненные.
Уже готовим новый материал для февраля, так что оставайтесь с нами, чтобы ничего не пропустить! Всем удачных выходных!
#итогимесяца
Если что-то пропустили в этом месяце, вот о чем мы писали:
Почему люди уходят из компании
Что мешает хорошим технарям стать руководителями?
Допустим ли микроменеджмент? Какие последствия?
Все, что вы знали об Agile неправда
Как получить оффер: мои фишки прохождения собеседования
Также добавили дополнительный материал на нашем Boosty с разбором кейса руководителя, которого не слушаются и над которым надсмехаются собственные подчиненные.
Уже готовим новый материал для февраля, так что оставайтесь с нами, чтобы ничего не пропустить! Всем удачных выходных!
#итогимесяца
Как я выбираю руководителей
Я уже рассказывал, на что я смотрю на собеседовании. Но там не поднималась отдельно тема руководителей, которых тоже нужно нанимать. Для простоты я не буду особенно вдаваться в градацию и акценты в зависимости от этого. К руководителям, в данном контексте, относятся и тимлиды и лидеры компетенций отделов (например лидеры направления Python, Go, JS и т.д.).
Умение излагать мысли
Первое, на что я смотрю, это умение излагать свои мысли ясно и четко. Такие позиции подразумевают тесное общение с людьми и чем выше, тем больше. Поэтому, если человек не умеет внятно излагать свои мысли, это большой минус.
Прошлый опыт и причины решений
Дальше я смотрю на опыт человека, причем мы не просто зачитываем резюме, а человек рассказывает о своей работе. Меня интересуют решения, которые он принимал и мотивация, с который он это делал. Если человек не может объяснить зачем он делал или внедрял что-то, то для руководителя это огромный минус. Если какие-то вещи спускались сверху, но были неразумными, то обсуждаем, что он делал в этих ситуациях.
Умение себя подать
Дальше я смотрю насколько человек умеет себя подать и расположить к себе. С какой командой он сможет работать, а с какой нет. В идеале, человек должен мочь возглавить любую команду, но обычно это не так и это становится ограничением при выборе.
Какая мотивация
Очень важно для меня понять мотивацию человека. Причем не только по работе, но и по желанию быть руководителем. Если это то, что тебе нравится и в чем ты хочешь развиваться, то это хорошо. А если так вышло, получилось и денег чуть больше платят, то мне этой мотивации не достаточно.
Практические вопросы
После этого я прошу рассказать человека, как он хотел бы организовать работу своей команды / направления, что бы он делал, как бы проверял результат, что важно, а что нет. В основном я слушаю, после чего задаю вопросы для уточнения (например: “а как бы фиксировали цели?”, “какими шагами бы шли к ее выполнению?” и т.д.). На этом этапе мне важно увидеть, что человек понимает свою позицию. Что он расскажет и о целях и о работе с людьми, а главное о том, как все сделать прозрачно для руководства и подчиненных. Этот этап для меня самый важный, потому что предыдущих пунктов недостаточно. Если говорить о человеке на вырост, то я с большей вероятностью буду растить кого-то внутри. Нанимая руководителя, хочется получить усиление сразу, а не в перспективе. Хотя бывают и исключения.
В целом, как и в любом деле, опирайтесь на свои потребности и свое понимание задач и позиций. А идя на собеседование, помните, что главное это хороший и позитивный настрой.
Если хотите лучше подготовиться к подобному собеседованию, то советую посмотреть мой учебник для тимлидов. Там я разобрал все основы работы с командой, которым учу своих собственных подчиненных.
Максим Шаламов
#руководителю
Я уже рассказывал, на что я смотрю на собеседовании. Но там не поднималась отдельно тема руководителей, которых тоже нужно нанимать. Для простоты я не буду особенно вдаваться в градацию и акценты в зависимости от этого. К руководителям, в данном контексте, относятся и тимлиды и лидеры компетенций отделов (например лидеры направления Python, Go, JS и т.д.).
Умение излагать мысли
Первое, на что я смотрю, это умение излагать свои мысли ясно и четко. Такие позиции подразумевают тесное общение с людьми и чем выше, тем больше. Поэтому, если человек не умеет внятно излагать свои мысли, это большой минус.
Прошлый опыт и причины решений
Дальше я смотрю на опыт человека, причем мы не просто зачитываем резюме, а человек рассказывает о своей работе. Меня интересуют решения, которые он принимал и мотивация, с который он это делал. Если человек не может объяснить зачем он делал или внедрял что-то, то для руководителя это огромный минус. Если какие-то вещи спускались сверху, но были неразумными, то обсуждаем, что он делал в этих ситуациях.
Умение себя подать
Дальше я смотрю насколько человек умеет себя подать и расположить к себе. С какой командой он сможет работать, а с какой нет. В идеале, человек должен мочь возглавить любую команду, но обычно это не так и это становится ограничением при выборе.
Какая мотивация
Очень важно для меня понять мотивацию человека. Причем не только по работе, но и по желанию быть руководителем. Если это то, что тебе нравится и в чем ты хочешь развиваться, то это хорошо. А если так вышло, получилось и денег чуть больше платят, то мне этой мотивации не достаточно.
Практические вопросы
После этого я прошу рассказать человека, как он хотел бы организовать работу своей команды / направления, что бы он делал, как бы проверял результат, что важно, а что нет. В основном я слушаю, после чего задаю вопросы для уточнения (например: “а как бы фиксировали цели?”, “какими шагами бы шли к ее выполнению?” и т.д.). На этом этапе мне важно увидеть, что человек понимает свою позицию. Что он расскажет и о целях и о работе с людьми, а главное о том, как все сделать прозрачно для руководства и подчиненных. Этот этап для меня самый важный, потому что предыдущих пунктов недостаточно. Если говорить о человеке на вырост, то я с большей вероятностью буду растить кого-то внутри. Нанимая руководителя, хочется получить усиление сразу, а не в перспективе. Хотя бывают и исключения.
В целом, как и в любом деле, опирайтесь на свои потребности и свое понимание задач и позиций. А идя на собеседование, помните, что главное это хороший и позитивный настрой.
Если хотите лучше подготовиться к подобному собеседованию, то советую посмотреть мой учебник для тимлидов. Там я разобрал все основы работы с командой, которым учу своих собственных подчиненных.
Максим Шаламов
#руководителю
Баланс скорости и качества
Вопрос по нахождению баланса скорости и качества самый часто задаваемый, да и в работе обсуждение этого баланса происходят постоянно. Видел много крайностей от полной работы в угоду заказчику, до полного отрицания нужд заказчика в угоду качества. Не возьмусь за всех говорить, как правильно, скажу, как я с этим работаю в своих командах.
Мы, технари, отвечаем за качество
Главное, что надо понимать, что за качество, как технический руководитель и/или специалист, отвечать будете вы (да, бизнес вертикали по голове настучат в любом случае, но в итоге это ваша ответственность), но также с вас спросят и за сроки. Поэтому, поиск баланса заложен уже в систему требований и оценивания результата. Если говорить про меня, то у меня есть как и большое желание выпускать продукт, который будет лучше и востребованнее, так и толика нездорового перфекционизма, что не упрощает ситуацию.
Конфликт между заказчиком и исполнителями
Пока не ушел дальше, обсудим самый насущный в этом месте вопрос, а именно конфликты между заказчиком и исполнителями, когда бизнесу надо получить результат здесь и сейчас, а вы пытаетесь сделать, чтоб оно работало. Если боитесь конфликтов, то работа руководителя не для вас, но и конфликт ради конфликта не имеет смысла. Не надо настраиваться ни на конфликт, ни на уступки, настраивайтесь на достижение целей. Только в таком настрое можно пытаться найти какой-то баланс, потому что ожидаемое качество тоже должно быть внесено в цели.
Ставим цели
В итоге, основой для поиска баланса являются ваши цели и их достижение. В такой постановке к целям нужно подходить серьезно и основательно, они должны быть и амбициозны и достижимы. В то же время, там должно быть и что-то о качестве, а не только набор нового функционала. Тогда вы, договариваясь о целях, придете, в рамках их постановки, к пониманию баланса. Выделите критичные вещи, которые нельзя переносить или отменять. Причем, в ряде случаев, качество или технические работы, могут быть также обязательны и несдвигаемы, как и выпуск нового функционала.
Постановкой целей только себе дело не ограничивается, цели нужно донести и поставить своей команде. Самое сложное это поставить цели своим смежникам, от которых вы зависите, так, чтобы они были заинтересованы в выполнении совместных задач. Тут придется привлекать и свои переговорные умения и руководство.
Следите, чтобы ваши цели стыковались с целями вашего руководства. Иначе это будет тот вид конфликта, который вы вряд ли выиграете.
Как идти на компромисс
В любом случае, будут ситуации, отклоняющиеся от намеченного плана, новые вводные и задачи. Тут всегда надо понимать, что есть ситуации, где спорить нет смысла, нужно делать, принимая технический долг. Но также надо понимать, что это игра в две стороны, приняли тех. долг - нашли время его потом поправить. В такой парадигме это ситуация, где конструктивно можно идти на компромиссы. Но она требует выстроенных отношений между бизнесом и ИТ, это сложно, но возможно. Если конструктива мало и у бизнеса всегда позиция “дай” и “надо”, придется учится самому видеть ситуации, где нельзя отказать, а где нужно идти по принятым стандартам. Это сложно и неприятно, но более чем реально.
В целом, советую всегда идти от ваших целей. Это будет помогать вам понимать правильность своих решений и оценивать, что вам мешает, а что помогает. Что и станет ориентиром при выборе.
Больше о том, как работать с бизнесом и получать от него нужные вам сроки, материалы, время на технический долг и т. д., есть в нашем мини-продукте "Документация для работы с ПО и ПМ". Там все основные моменты, которыми я пользуюсь для урегулирования различных ситуацией с бизнесом в своих командах. Также есть отдельный раздел по донесению важности качества продукта.
Максим Шаламов
#советы
Вопрос по нахождению баланса скорости и качества самый часто задаваемый, да и в работе обсуждение этого баланса происходят постоянно. Видел много крайностей от полной работы в угоду заказчику, до полного отрицания нужд заказчика в угоду качества. Не возьмусь за всех говорить, как правильно, скажу, как я с этим работаю в своих командах.
Мы, технари, отвечаем за качество
Главное, что надо понимать, что за качество, как технический руководитель и/или специалист, отвечать будете вы (да, бизнес вертикали по голове настучат в любом случае, но в итоге это ваша ответственность), но также с вас спросят и за сроки. Поэтому, поиск баланса заложен уже в систему требований и оценивания результата. Если говорить про меня, то у меня есть как и большое желание выпускать продукт, который будет лучше и востребованнее, так и толика нездорового перфекционизма, что не упрощает ситуацию.
Конфликт между заказчиком и исполнителями
Пока не ушел дальше, обсудим самый насущный в этом месте вопрос, а именно конфликты между заказчиком и исполнителями, когда бизнесу надо получить результат здесь и сейчас, а вы пытаетесь сделать, чтоб оно работало. Если боитесь конфликтов, то работа руководителя не для вас, но и конфликт ради конфликта не имеет смысла. Не надо настраиваться ни на конфликт, ни на уступки, настраивайтесь на достижение целей. Только в таком настрое можно пытаться найти какой-то баланс, потому что ожидаемое качество тоже должно быть внесено в цели.
Ставим цели
В итоге, основой для поиска баланса являются ваши цели и их достижение. В такой постановке к целям нужно подходить серьезно и основательно, они должны быть и амбициозны и достижимы. В то же время, там должно быть и что-то о качестве, а не только набор нового функционала. Тогда вы, договариваясь о целях, придете, в рамках их постановки, к пониманию баланса. Выделите критичные вещи, которые нельзя переносить или отменять. Причем, в ряде случаев, качество или технические работы, могут быть также обязательны и несдвигаемы, как и выпуск нового функционала.
Постановкой целей только себе дело не ограничивается, цели нужно донести и поставить своей команде. Самое сложное это поставить цели своим смежникам, от которых вы зависите, так, чтобы они были заинтересованы в выполнении совместных задач. Тут придется привлекать и свои переговорные умения и руководство.
Следите, чтобы ваши цели стыковались с целями вашего руководства. Иначе это будет тот вид конфликта, который вы вряд ли выиграете.
Как идти на компромисс
В любом случае, будут ситуации, отклоняющиеся от намеченного плана, новые вводные и задачи. Тут всегда надо понимать, что есть ситуации, где спорить нет смысла, нужно делать, принимая технический долг. Но также надо понимать, что это игра в две стороны, приняли тех. долг - нашли время его потом поправить. В такой парадигме это ситуация, где конструктивно можно идти на компромиссы. Но она требует выстроенных отношений между бизнесом и ИТ, это сложно, но возможно. Если конструктива мало и у бизнеса всегда позиция “дай” и “надо”, придется учится самому видеть ситуации, где нельзя отказать, а где нужно идти по принятым стандартам. Это сложно и неприятно, но более чем реально.
В целом, советую всегда идти от ваших целей. Это будет помогать вам понимать правильность своих решений и оценивать, что вам мешает, а что помогает. Что и станет ориентиром при выборе.
Больше о том, как работать с бизнесом и получать от него нужные вам сроки, материалы, время на технический долг и т. д., есть в нашем мини-продукте "Документация для работы с ПО и ПМ". Там все основные моменты, которыми я пользуюсь для урегулирования различных ситуацией с бизнесом в своих командах. Также есть отдельный раздел по донесению важности качества продукта.
Максим Шаламов
#советы
Ваш руководитель мешает вам работать?
В нашей подписке с дополнительными материалами на Boosty мы разобрали вопрос подписчика о навязчивом руководителе, который мешает работать. Вот сам вопрос:
“Недавно я устроился синьор разработчиком на новое место. Компания новая дочка крупного банка, открылась пол года назад. Мой руководитель совсем недавно перешла на должность лидера команды. Собеседовала очень долго, гоняла по архитектуре, вроде ей все понравилось. Но когда я вышел на работу начала работать со мной, как с джуном. Каждую задачу со мной обсуждает вплоть до мельчайших деталей реализации. Постоянно интересуется, как идёт процесс, перепроверяет сама, если я говорю, что какое-то решение нам не подходит. При этом ее занятость иногда блокирует мою работу, потому что она требует согласования всего, а встречу с ней поставить не можем, потому что у нее времени нет. Моего опыта достаточно, чтобы работать полностью самостоятельно, мой стаж даже больше, чем у нее. Как разрешить такую ситуацию, чтобы избавиться от мега опеки лида и работать спокойно на своем уровне?”
Действительно, с такой ситуацией, в том или ином виде, сталкиваются многие разработчики. В разборе вы найдете возможные причины такого поведения руководителя и техники, которые вы сможете применить, чтобы исправить ситуацию.
Чтобы получить разбор, переходите по ссылке и подписывайтесь на уровень с доп. материалами. При подписке вы также получите дополнительные материалы за предыдущий месяц с разбором руководителя, над которым издевается собственная команда.
Свой вопрос для разбора вы можете прислать в нашего бота. Задавшему вопрос разбор пришлем без платной подписки.
В нашей подписке с дополнительными материалами на Boosty мы разобрали вопрос подписчика о навязчивом руководителе, который мешает работать. Вот сам вопрос:
“Недавно я устроился синьор разработчиком на новое место. Компания новая дочка крупного банка, открылась пол года назад. Мой руководитель совсем недавно перешла на должность лидера команды. Собеседовала очень долго, гоняла по архитектуре, вроде ей все понравилось. Но когда я вышел на работу начала работать со мной, как с джуном. Каждую задачу со мной обсуждает вплоть до мельчайших деталей реализации. Постоянно интересуется, как идёт процесс, перепроверяет сама, если я говорю, что какое-то решение нам не подходит. При этом ее занятость иногда блокирует мою работу, потому что она требует согласования всего, а встречу с ней поставить не можем, потому что у нее времени нет. Моего опыта достаточно, чтобы работать полностью самостоятельно, мой стаж даже больше, чем у нее. Как разрешить такую ситуацию, чтобы избавиться от мега опеки лида и работать спокойно на своем уровне?”
Действительно, с такой ситуацией, в том или ином виде, сталкиваются многие разработчики. В разборе вы найдете возможные причины такого поведения руководителя и техники, которые вы сможете применить, чтобы исправить ситуацию.
Чтобы получить разбор, переходите по ссылке и подписывайтесь на уровень с доп. материалами. При подписке вы также получите дополнительные материалы за предыдущий месяц с разбором руководителя, над которым издевается собственная команда.
Свой вопрос для разбора вы можете прислать в нашего бота. Задавшему вопрос разбор пришлем без платной подписки.
Как правильно принимать обратную связь
Поговорим сегодня о том, как правильно принимать обратную связь (о том, как давать обратную связь мы уже говорили). Сразу уточним, есть люди, которые под обратной связью подают любое свое мнение в любом формате. Вроде как я тебя помоями облил, а ты стой слушай - принимай обратную связь. Обвинения и ругань это некорректная обратная связь. Их все равно бывает полезно послушать, это может быть показателем того, что у человека что-то чрезмерно накипело, и об этом полезно узнать и задуматься, что стоит делать дальше. А теперь давайте обсудим, как работать с корректной обратной связью.
Обратная связь от коллег
Обязательно выслушайте, не перебивайте. Задайте вопросы, если что-то непонятно. Если согласны, то так и скажите, обсудите варианты исправления ситуации. Если не согласны, расскажите свою позицию и предложите обдумать варианты, как улучшить. В любом случае поблагодарите за мнение. Даже если вы не согласны с позицией своего коллеги, вы узнали, как он воспринимает ситуацию, и это поможет вам в дальнейшей работе.
Обратная связь от руководителя
Выслушайте. Уточните детали, обсудите, где произошло расхождение в понимании задач, целей и так далее. Поделитесь тем, как вы это видели и почему что-то делали. Обсудите изменения и то, что больше не будете делать. Главное, идите от проблемы и желания прийти к пониманию, как работать и как вас оценивают.
Обратная связь от подчиненного
Дайте высказаться, запишите все пункты. Ответьте на каждый сразу или подготовьтесь и назначьте встречу на другой день. Ответьте на все так, как оно есть, или должно быть, даже если человеку это не нравится. Выписанные проблемы, с которыми согласны, берите в работу. Поблагодарите подчиненного за смелость. Помните, что не каждый решится сказать свою обратную связь руководителю. Добывать информацию, когда вам не хотят ее рассказывать, намного сложнее, поэтому цените это. При появлении желания высказаться у подчиненного обязательно выслушайте его и обсудите услышанное. Не оставляйте вопросов, которые потом будут мешать человеку делать свою работу.
Обратная связь от бизнеса
Еще один очень важный раздел работы с обратной связью - обратная связь от бизнес команды. Умение с ней работать крайне важно для выстраивания работы и корректировки проблем в команде и личной работе. Даже если вами полностью доволен ваш технический руководитель, но бизнес команда не получает от вас то, что ей нужно, это непременно скажется на вашем будущем в компании. Подробно работу с обратной связью от бизнес команды мы разбираем в нашей “Документации по работе с ПО и ПМ”. Там вы в целом найдете все знания по работе с бизнес-командой просто необходимые техническому специалисту любого уровня.
#советы
Поговорим сегодня о том, как правильно принимать обратную связь (о том, как давать обратную связь мы уже говорили). Сразу уточним, есть люди, которые под обратной связью подают любое свое мнение в любом формате. Вроде как я тебя помоями облил, а ты стой слушай - принимай обратную связь. Обвинения и ругань это некорректная обратная связь. Их все равно бывает полезно послушать, это может быть показателем того, что у человека что-то чрезмерно накипело, и об этом полезно узнать и задуматься, что стоит делать дальше. А теперь давайте обсудим, как работать с корректной обратной связью.
Обратная связь от коллег
Обязательно выслушайте, не перебивайте. Задайте вопросы, если что-то непонятно. Если согласны, то так и скажите, обсудите варианты исправления ситуации. Если не согласны, расскажите свою позицию и предложите обдумать варианты, как улучшить. В любом случае поблагодарите за мнение. Даже если вы не согласны с позицией своего коллеги, вы узнали, как он воспринимает ситуацию, и это поможет вам в дальнейшей работе.
Обратная связь от руководителя
Выслушайте. Уточните детали, обсудите, где произошло расхождение в понимании задач, целей и так далее. Поделитесь тем, как вы это видели и почему что-то делали. Обсудите изменения и то, что больше не будете делать. Главное, идите от проблемы и желания прийти к пониманию, как работать и как вас оценивают.
Обратная связь от подчиненного
Дайте высказаться, запишите все пункты. Ответьте на каждый сразу или подготовьтесь и назначьте встречу на другой день. Ответьте на все так, как оно есть, или должно быть, даже если человеку это не нравится. Выписанные проблемы, с которыми согласны, берите в работу. Поблагодарите подчиненного за смелость. Помните, что не каждый решится сказать свою обратную связь руководителю. Добывать информацию, когда вам не хотят ее рассказывать, намного сложнее, поэтому цените это. При появлении желания высказаться у подчиненного обязательно выслушайте его и обсудите услышанное. Не оставляйте вопросов, которые потом будут мешать человеку делать свою работу.
Обратная связь от бизнеса
Еще один очень важный раздел работы с обратной связью - обратная связь от бизнес команды. Умение с ней работать крайне важно для выстраивания работы и корректировки проблем в команде и личной работе. Даже если вами полностью доволен ваш технический руководитель, но бизнес команда не получает от вас то, что ей нужно, это непременно скажется на вашем будущем в компании. Подробно работу с обратной связью от бизнес команды мы разбираем в нашей “Документации по работе с ПО и ПМ”. Там вы в целом найдете все знания по работе с бизнес-командой просто необходимые техническому специалисту любого уровня.
#советы
Влияете ли вы на результат?
Давно обратил внимание, что многие люди думают, что для влияния на результат своей работы, нужны какие-то особые условия или позиции. Конечно, глупо спорить, что с ростом позиции растет и влияние. Но я видел немало директоров, которые очень мало влияли на процесс и принимаемые решения, и не знали, что делать. В то же время немало разработчиков обладают огромным влиянием на процессы и результаты по тем или иным причинам.
Так в чем же собственно дело? Я считаю, что главное тут настрой и готовность преодолевать трудности. Из всех 11 компаний, где я работал, у меня не получалось влиять на процессы и результат только в одной, и то лично мне там не хотелось сильно в это вкладываться. В остальных местах возможности находились, где-то в рамках своих зон влияния, где-то больше и приводило к росту. Но везде мне было не плевать и я считал, что должен и могу влиять на процесс и результат своей работы. Я искал варианты, собирал встречи, проводил пилоты, убеждал людей и потихоньку ситуация менялась. Главное это хотеть и делать. Ждать, что вам дадут влиять очень глупо. Всегда будет большая инерция и сопротивление изменениям. С первого раза многие вещи не получатся, будут происходит откаты и конфликты. К этому нужно быть готовым.
Проблема ожидания определенных позиций, чтобы начать на что-то влиять, заключается в том, что, получив заветное место, вы не научитесь продвигать свои идеи. Не научитесь видеть проблемы и искать решение, которое устроит не только вас, но и всю команду.
Если вы хотите влиять, то, кроме как начать это делать, предложить нечего. Начинайте с малого. Выпишите проблемы в работе, которые вы видите. Подумайте, что с каждой проблемой вы могли бы сделать и кого это заденет. Оформите максимально понятно ваши идеи и соберите всех участников процесса, представьте им свои идеи. Обязательно отталкивайтесь от проблемы, которую вы решаете, и делайте акцент на плюсах идеи, которую вы предлагаете. Готовьтесь работать с возражениями. Готовьтесь, что основные проблемы по внедрению ваших идей будут лежать на вас, предложить идею и не участвовать в ее реализации не получится, провальный результат гарантирован. Более подробно алгоритм внедрения изменений мы разбираем в мини-продукте по борьбе с рутиной.
Показывая готовность участвовать в изменениях и тащить их на себе, вы зарабатываете себе репутацию. У руководства в том числе. Со временем, вес ваших слов и идей будет расти и вам будет становиться все проще.
В общем, вопрос влияния для меня больше заключен в желании, настойчивости и терпении. Обычно не могут влиять те, кто не готов в это вкладываться, либо сводят все общение к конфликту. Пробуйте, не теряйте настрой и все у вас получится на любой позиции.
Максим Шаламов
#советы
Давно обратил внимание, что многие люди думают, что для влияния на результат своей работы, нужны какие-то особые условия или позиции. Конечно, глупо спорить, что с ростом позиции растет и влияние. Но я видел немало директоров, которые очень мало влияли на процесс и принимаемые решения, и не знали, что делать. В то же время немало разработчиков обладают огромным влиянием на процессы и результаты по тем или иным причинам.
Так в чем же собственно дело? Я считаю, что главное тут настрой и готовность преодолевать трудности. Из всех 11 компаний, где я работал, у меня не получалось влиять на процессы и результат только в одной, и то лично мне там не хотелось сильно в это вкладываться. В остальных местах возможности находились, где-то в рамках своих зон влияния, где-то больше и приводило к росту. Но везде мне было не плевать и я считал, что должен и могу влиять на процесс и результат своей работы. Я искал варианты, собирал встречи, проводил пилоты, убеждал людей и потихоньку ситуация менялась. Главное это хотеть и делать. Ждать, что вам дадут влиять очень глупо. Всегда будет большая инерция и сопротивление изменениям. С первого раза многие вещи не получатся, будут происходит откаты и конфликты. К этому нужно быть готовым.
Проблема ожидания определенных позиций, чтобы начать на что-то влиять, заключается в том, что, получив заветное место, вы не научитесь продвигать свои идеи. Не научитесь видеть проблемы и искать решение, которое устроит не только вас, но и всю команду.
Если вы хотите влиять, то, кроме как начать это делать, предложить нечего. Начинайте с малого. Выпишите проблемы в работе, которые вы видите. Подумайте, что с каждой проблемой вы могли бы сделать и кого это заденет. Оформите максимально понятно ваши идеи и соберите всех участников процесса, представьте им свои идеи. Обязательно отталкивайтесь от проблемы, которую вы решаете, и делайте акцент на плюсах идеи, которую вы предлагаете. Готовьтесь работать с возражениями. Готовьтесь, что основные проблемы по внедрению ваших идей будут лежать на вас, предложить идею и не участвовать в ее реализации не получится, провальный результат гарантирован. Более подробно алгоритм внедрения изменений мы разбираем в мини-продукте по борьбе с рутиной.
Показывая готовность участвовать в изменениях и тащить их на себе, вы зарабатываете себе репутацию. У руководства в том числе. Со временем, вес ваших слов и идей будет расти и вам будет становиться все проще.
В общем, вопрос влияния для меня больше заключен в желании, настойчивости и терпении. Обычно не могут влиять те, кто не готов в это вкладываться, либо сводят все общение к конфликту. Пробуйте, не теряйте настрой и все у вас получится на любой позиции.
Максим Шаламов
#советы
“Я просто делаю, что мне говорят” - зачем разработчику уметь в процессы?
Мы много говорим о важности построения правильных взаимоотношений между разработкой и бизнесом. Конечно, в основном, этим занимаются руководители команд. Они должны задавать правила игры и следить, чтобы их выполняли обе стороны. Но влияет ли простой исполнитель на то, как происходит работа между ним и бизнесом? Или он человек подневольный и просто делает то, что говорят руководитель и бизнес-лидер?
Ломаем работу своего руководителя
Представьте ситуацию, руководитель отдела договаривается с бизнес-командой, что все работают по процессу, не приносят изменения в уже идущий спринт, формируют продуктовый бэклог заранее и т.д. Проходит много споров, но, в итоге, все соглашаются. В первый день спринта у владельца продукта происходит внезапная продажа клиентам не существующего функционала и созревает дикая необходимость втащить задачу не него “вот прям щас”. Приходит владелец продукта в команду, руководитель в это время на встрече, под руку попадается разработчик. Разработчику рассказывается, в какой ужасной ситуации мы все будем, если не сделаем эту задачу, что на кону репутация компании и срыв договора с клиентом, о том, как он подведет свою команду, да и вообще всю компанию, если сейчас же не сядет делать пол часа назад проданую клиенту задачу.
К моменту прихода руководителя с многочисленных встреч разработчик уже бросил все свои дела и сидит делает мега срочную задачу от владельца продукта. Если руководитель не дергает своих подчиненных почем зря, узнает он о ситуации только на следующем стендапе, то есть когда уже потеряны примерно сутки из спринта (для недельного спринта это очень много). Таким нехитрым способом разработчик пускает коту под хвост массу работы, сделанной его руководителем, и отменяет все договоренности с бизнес-командой, потому что они только что нашли лазейку, через которую будут ходить, когда им вздумается, ломая все процессы.
А что надо было делать?
Вы, возможно, спросите, а что надо было дать владельцу продукта сорвать контракт с клиентом? Во-первых, нужно знать основы работы с процессами, чтобы понять, когда они нарушаются и знать, как правильно вести себя в этой ситуации. Во-вторых, если кто-то нарушает процессы, то вы либо эскалируете проблему своему руководителю, который выстраивал эти договоренности, либо стоите на своих процессах, о которых вы все договорились, и тогда бизнесу самому придется идти к вашему руководителю и договариваться с ним, если он конечно вообще решится на это.
На любом уровне нужно помнить, что, если бизнес будет знать, что вы прогнетесь, когда ему нужно, он никогда не будет работать по процессам, потому что соблазн слишком велик. Он никогда не будет думать, что нужно спросить о сроках разработки прежде, чем давать кому-то обещания, что нельзя продавать то, чего не существует в проекте, и что техническая команда вообще является частью системы принятия решений (а она является, иначе техническое качество она обеспечивать не сможет). Найдутся единицы, которые сами понимают важность процессов, но с ними у вас эта ситуации и вовсе не возникнет.
Нарушая эти принципы, даже один разработчик может быть причиной отсутствия порядка в работе целой команды. Так мы зарабатываем собственные переработки и делаем проекты под переписывание, из которых сами же потом и увольняемся. Как этого избежать? Не ждать, когда руководитель ударит по шапке, если ты вот так ошибся и уже все сломал, а учиться, как должны работать процессы и работа с бизнесом заранее. Кроме изучения необходимых всем гибких методологий, где есть все и сразу, можете посмотреть наш более узкий мини-продукт по работе с бизнесом. Там мы как раз разбираем, как обычный разработчик должен правильно участвовать в работе с бизнесом, чтобы не стрелять себе же в ногу.
Александра Шаламова
#agile_который_работает
Мы много говорим о важности построения правильных взаимоотношений между разработкой и бизнесом. Конечно, в основном, этим занимаются руководители команд. Они должны задавать правила игры и следить, чтобы их выполняли обе стороны. Но влияет ли простой исполнитель на то, как происходит работа между ним и бизнесом? Или он человек подневольный и просто делает то, что говорят руководитель и бизнес-лидер?
Ломаем работу своего руководителя
Представьте ситуацию, руководитель отдела договаривается с бизнес-командой, что все работают по процессу, не приносят изменения в уже идущий спринт, формируют продуктовый бэклог заранее и т.д. Проходит много споров, но, в итоге, все соглашаются. В первый день спринта у владельца продукта происходит внезапная продажа клиентам не существующего функционала и созревает дикая необходимость втащить задачу не него “вот прям щас”. Приходит владелец продукта в команду, руководитель в это время на встрече, под руку попадается разработчик. Разработчику рассказывается, в какой ужасной ситуации мы все будем, если не сделаем эту задачу, что на кону репутация компании и срыв договора с клиентом, о том, как он подведет свою команду, да и вообще всю компанию, если сейчас же не сядет делать пол часа назад проданую клиенту задачу.
К моменту прихода руководителя с многочисленных встреч разработчик уже бросил все свои дела и сидит делает мега срочную задачу от владельца продукта. Если руководитель не дергает своих подчиненных почем зря, узнает он о ситуации только на следующем стендапе, то есть когда уже потеряны примерно сутки из спринта (для недельного спринта это очень много). Таким нехитрым способом разработчик пускает коту под хвост массу работы, сделанной его руководителем, и отменяет все договоренности с бизнес-командой, потому что они только что нашли лазейку, через которую будут ходить, когда им вздумается, ломая все процессы.
А что надо было делать?
Вы, возможно, спросите, а что надо было дать владельцу продукта сорвать контракт с клиентом? Во-первых, нужно знать основы работы с процессами, чтобы понять, когда они нарушаются и знать, как правильно вести себя в этой ситуации. Во-вторых, если кто-то нарушает процессы, то вы либо эскалируете проблему своему руководителю, который выстраивал эти договоренности, либо стоите на своих процессах, о которых вы все договорились, и тогда бизнесу самому придется идти к вашему руководителю и договариваться с ним, если он конечно вообще решится на это.
На любом уровне нужно помнить, что, если бизнес будет знать, что вы прогнетесь, когда ему нужно, он никогда не будет работать по процессам, потому что соблазн слишком велик. Он никогда не будет думать, что нужно спросить о сроках разработки прежде, чем давать кому-то обещания, что нельзя продавать то, чего не существует в проекте, и что техническая команда вообще является частью системы принятия решений (а она является, иначе техническое качество она обеспечивать не сможет). Найдутся единицы, которые сами понимают важность процессов, но с ними у вас эта ситуации и вовсе не возникнет.
Нарушая эти принципы, даже один разработчик может быть причиной отсутствия порядка в работе целой команды. Так мы зарабатываем собственные переработки и делаем проекты под переписывание, из которых сами же потом и увольняемся. Как этого избежать? Не ждать, когда руководитель ударит по шапке, если ты вот так ошибся и уже все сломал, а учиться, как должны работать процессы и работа с бизнесом заранее. Кроме изучения необходимых всем гибких методологий, где есть все и сразу, можете посмотреть наш более узкий мини-продукт по работе с бизнесом. Там мы как раз разбираем, как обычный разработчик должен правильно участвовать в работе с бизнесом, чтобы не стрелять себе же в ногу.
Александра Шаламова
#agile_который_работает
О чем мы писали в феврале
Чтобы вы не пропустили ничего интересного, напомню о чем мы писали в феврале:
Как СТО выбирает руководителей для своих отделов
Как соблюдать баланс между скоростью и качеством
Как правильно принимать обратную связь
Как влиять на результат
Помимо этого мы разобрали кейс, как избавиться от излишнего контроля руководителем. Кейс доступен по подписке для дополнительных материалов на Boosty. При оформлении подписки, вы также получите доступ к кейсу января с разбором руководителя, над которым издеваются подчинные. А уже скоро выйдет новый интересный разбор, полезный буквально каждому.
Оставайтесь с нами, впереди вас ждет еще много интересного!
#итогимесяца
Чтобы вы не пропустили ничего интересного, напомню о чем мы писали в феврале:
Как СТО выбирает руководителей для своих отделов
Как соблюдать баланс между скоростью и качеством
Как правильно принимать обратную связь
Как влиять на результат
Помимо этого мы разобрали кейс, как избавиться от излишнего контроля руководителем. Кейс доступен по подписке для дополнительных материалов на Boosty. При оформлении подписки, вы также получите доступ к кейсу января с разбором руководителя, над которым издеваются подчинные. А уже скоро выйдет новый интересный разбор, полезный буквально каждому.
Оставайтесь с нами, впереди вас ждет еще много интересного!
#итогимесяца
Зачем мне эта головная боль?
Вы знаете, я люблю всякие примеры из жизни, потому что на них часто все становится более очевидно, чем на работе. Так вот, как раз на днях у меня случился такой момент осознания в повседневной жизни. Как-то Максим писал о стереотипных причинах, почему люди идут в руководители. Многие хотят власти, хотят влиять на ситуацию. И вы уже знаете, что формальная должность этого не дает. Но сейчас я вам расскажу, как влиять на людей без всякой там должности, и даже на людей никак с вами не связанных обязательствами.
Одно из моих хобби танцы. Мы с ребятами ставим танец, а потом собираемся в красивом месте и снимаем это все на камеру на память. Последнюю съемку организовали настолько для меня неудобно, что мне вообще пришлось отказаться от этого мероприятия, что меня достаточно сильно расстроило. Я решила, что нужно как-то повлиять на группу, чтобы в следующий раз сделали по-моему и я смогла участвовать. Мы с Максимом всегда обсуждаем дома подобные вещи, и он посоветовал просто взять организацию на себя и я увижу, что никто не будет спорить с уже принятыми решениями.
Должна вам сказать, что не думала, что эффект действительно будет настолько мощным. Стоило мне взять на себя инициативу по организации и с моим решением основных вопросов действительно никто спорить не стал. При этом важно, что я не просто говорила, что я приняла решение, это бы лишило группу ощущения, что они участвуют в выборе. Я приходила с уже готовыми договоренностями, но перед финальным подтверждением.
Например, для меня важен был выбор оператора. Я написала тому, кто мне нравился, и узнала ответы на все основные вопросы. К группе я уже пришла с информацией, что вот этот человек готов нас снимать такого-то числа, во-столько то, в таком-то месте, столько нам это будет стоить. Дальше достаточно было спросить все ли согласны и получить положительный ответ, потому что все вопросы уже были закрыты. Когда за тебя уже все организовали и все что тебе остается сделать, это явиться в нужное место в нужное время и ни о чем не беспокоится, захочешь ли ты брать на себя лишний головняк, просто чтобы что-то поменять? Большинству будет намного проще просто смириться с тем, что есть.
В рабочей среде это происходит точно также. Стоит вам полностью взять на себя инициативу, вы получаете возможность управлять ей и напрямую решать, как она будет реализовываться. Это куча лишнего головняка? Да, это так. С другой стороны, мало кто захочет проходить этот головняк еще раз, чтобы поменять то, что вы уже сделали. Да и выглядеть это будет странно. Именно поэтому технические решения, которые затащили в проект на старте живут там до скончания веков. Кто готов потратить свое время, чтобы все вычистить и сделать по-своему? Единицы.
Основной урок: хочешь, чтобы было сделано по-твоему, проявляй инициативу и бери ответственность на себя. Главное в финале согласовать решение с заинтересованными людьми и руководством. Если не знаете, как организовать реализацию своей инициативы, то подробный план мы уже разобрали тут.
Александра Шаламова
#советы
Вы знаете, я люблю всякие примеры из жизни, потому что на них часто все становится более очевидно, чем на работе. Так вот, как раз на днях у меня случился такой момент осознания в повседневной жизни. Как-то Максим писал о стереотипных причинах, почему люди идут в руководители. Многие хотят власти, хотят влиять на ситуацию. И вы уже знаете, что формальная должность этого не дает. Но сейчас я вам расскажу, как влиять на людей без всякой там должности, и даже на людей никак с вами не связанных обязательствами.
Одно из моих хобби танцы. Мы с ребятами ставим танец, а потом собираемся в красивом месте и снимаем это все на камеру на память. Последнюю съемку организовали настолько для меня неудобно, что мне вообще пришлось отказаться от этого мероприятия, что меня достаточно сильно расстроило. Я решила, что нужно как-то повлиять на группу, чтобы в следующий раз сделали по-моему и я смогла участвовать. Мы с Максимом всегда обсуждаем дома подобные вещи, и он посоветовал просто взять организацию на себя и я увижу, что никто не будет спорить с уже принятыми решениями.
Должна вам сказать, что не думала, что эффект действительно будет настолько мощным. Стоило мне взять на себя инициативу по организации и с моим решением основных вопросов действительно никто спорить не стал. При этом важно, что я не просто говорила, что я приняла решение, это бы лишило группу ощущения, что они участвуют в выборе. Я приходила с уже готовыми договоренностями, но перед финальным подтверждением.
Например, для меня важен был выбор оператора. Я написала тому, кто мне нравился, и узнала ответы на все основные вопросы. К группе я уже пришла с информацией, что вот этот человек готов нас снимать такого-то числа, во-столько то, в таком-то месте, столько нам это будет стоить. Дальше достаточно было спросить все ли согласны и получить положительный ответ, потому что все вопросы уже были закрыты. Когда за тебя уже все организовали и все что тебе остается сделать, это явиться в нужное место в нужное время и ни о чем не беспокоится, захочешь ли ты брать на себя лишний головняк, просто чтобы что-то поменять? Большинству будет намного проще просто смириться с тем, что есть.
В рабочей среде это происходит точно также. Стоит вам полностью взять на себя инициативу, вы получаете возможность управлять ей и напрямую решать, как она будет реализовываться. Это куча лишнего головняка? Да, это так. С другой стороны, мало кто захочет проходить этот головняк еще раз, чтобы поменять то, что вы уже сделали. Да и выглядеть это будет странно. Именно поэтому технические решения, которые затащили в проект на старте живут там до скончания веков. Кто готов потратить свое время, чтобы все вычистить и сделать по-своему? Единицы.
Основной урок: хочешь, чтобы было сделано по-твоему, проявляй инициативу и бери ответственность на себя. Главное в финале согласовать решение с заинтересованными людьми и руководством. Если не знаете, как организовать реализацию своей инициативы, то подробный план мы уже разобрали тут.
Александра Шаламова
#советы
Считаете вопрос о прошлом опыте работы на собеседовании простой формальностью? А ведь некоторые интервьюеры слушают его, как основной, оценивают по нему ваши навыки, умение работать в команде и даже технические знания. Обидно месяцами гонять технические задачки к собеседованию, но завалиться на простом рассказе о себе.
Не знаете, как подать неудачное место работы? У вас есть опыт, которого вы стесняетесь? Пропускаете первое место работы, потому что о нем говорить стыдно или не знаете, как доказать свои положительные качества?
В новом разборе на нашем Boosty для дополнительных материалов я разобрала, как с помощью правильного рассказала о прошлом опыте я располагаю к себе работодателя. На примере собственного опыта я показываю, как можно показать себя в наилучшем свете и скрыть неудачи. Так я легко получала оффер в такие компании, как Яндекс, Mail, Авито, Lazada и многие другие. Этот подход сработает и для вас.
При подписке сейчас вы также получите доступ к дополнительным материалам прошлых месяцев: кейс "Как избавиться от излишнего контроля руководителем" и кейс января с разбором руководителя, над которым издеваются подчинные. Также в комментариях я отвечу на ваши вопросы. Жду вас на разборе уже сегодня!
Александра Шаламова
Не знаете, как подать неудачное место работы? У вас есть опыт, которого вы стесняетесь? Пропускаете первое место работы, потому что о нем говорить стыдно или не знаете, как доказать свои положительные качества?
В новом разборе на нашем Boosty для дополнительных материалов я разобрала, как с помощью правильного рассказала о прошлом опыте я располагаю к себе работодателя. На примере собственного опыта я показываю, как можно показать себя в наилучшем свете и скрыть неудачи. Так я легко получала оффер в такие компании, как Яндекс, Mail, Авито, Lazada и многие другие. Этот подход сработает и для вас.
При подписке сейчас вы также получите доступ к дополнительным материалам прошлых месяцев: кейс "Как избавиться от излишнего контроля руководителем" и кейс января с разбором руководителя, над которым издеваются подчинные. Также в комментариях я отвечу на ваши вопросы. Жду вас на разборе уже сегодня!
Александра Шаламова
Работа с техническим бэклогом
Работа с техническим беклогом на мой взгляд, одно из важнейших умений технического менеджера. При этом с этим обычно возникает огромное количество проблем при росте ребят. Это довольно интересно, с учетом того, что обычно я вижу большой запрос к бизнесу на длительную дорожную карту, чтобы понимать что делаем и куда идем, но со своей стороны такую же техническую дорожную карту выдать готовы единицы. Давайте разбираться что это и зачем.
В технический бэклог должны попадать все технические задачи, которые вы собираетесь сделать в проекте. Например:
- Рефакторинг и/или разделение модулей
- Доработка покрытием тестов
- Выделение новых стендов (если это не делается просто в вашей компании)
- Наполнение стендов тестовыми данными
- Проведение нагрузочного тестирования
- Разбивка проекта на сервисы
- Ресерч, который направлен на поиск лучших решений для проекта
- и т.д.
Все это должно быть собрано в одном месте, приоритезировано и оценено.
Собирать эти вещи надо постоянно, по итогам ваших технических встреч и ретроспектив, там часто всплывают проблемы и все их нужно записывать. Затем проводите отдельные встречи по техническому бэклогу, где выделяйте то, на что команда готова инвестировать время и силы (или на что должны по мнению лидера команды). В целом, тут работа очень мало отличается от работы с любым бэклогом. Ведет бэклог ПМ или тимлид, приоритезирует тимлид или тех. руководитель.
Дальше этот бэклог накладывается на бизнесовый, и задачи в оговоренной у вас пропорции берутся в работу. Главное, что вы можете показать, что и зачем вы собираетесь делать, сразу же показать трудозатраты. А не будете прибегать перед каждой новой задачей со словами, что надо бы инвестировать сколько-то времени, но мы не знаем сколько, но без этого не получится нормально сделать.
Планирование и прозрачность, помогут вам обосновывать необходимость ваших шагов и сделать движение к ним понятным и предсказуемым. Так же вы сами сможете осознанно выбирать из своих проблем те, которые стоит брать в первую очередь. Инвестируйте в работу с техническим бэклогом и ваша работа станет проще.
Максим Шаламов
#советы
Работа с техническим беклогом на мой взгляд, одно из важнейших умений технического менеджера. При этом с этим обычно возникает огромное количество проблем при росте ребят. Это довольно интересно, с учетом того, что обычно я вижу большой запрос к бизнесу на длительную дорожную карту, чтобы понимать что делаем и куда идем, но со своей стороны такую же техническую дорожную карту выдать готовы единицы. Давайте разбираться что это и зачем.
В технический бэклог должны попадать все технические задачи, которые вы собираетесь сделать в проекте. Например:
- Рефакторинг и/или разделение модулей
- Доработка покрытием тестов
- Выделение новых стендов (если это не делается просто в вашей компании)
- Наполнение стендов тестовыми данными
- Проведение нагрузочного тестирования
- Разбивка проекта на сервисы
- Ресерч, который направлен на поиск лучших решений для проекта
- и т.д.
Все это должно быть собрано в одном месте, приоритезировано и оценено.
Собирать эти вещи надо постоянно, по итогам ваших технических встреч и ретроспектив, там часто всплывают проблемы и все их нужно записывать. Затем проводите отдельные встречи по техническому бэклогу, где выделяйте то, на что команда готова инвестировать время и силы (или на что должны по мнению лидера команды). В целом, тут работа очень мало отличается от работы с любым бэклогом. Ведет бэклог ПМ или тимлид, приоритезирует тимлид или тех. руководитель.
Дальше этот бэклог накладывается на бизнесовый, и задачи в оговоренной у вас пропорции берутся в работу. Главное, что вы можете показать, что и зачем вы собираетесь делать, сразу же показать трудозатраты. А не будете прибегать перед каждой новой задачей со словами, что надо бы инвестировать сколько-то времени, но мы не знаем сколько, но без этого не получится нормально сделать.
Планирование и прозрачность, помогут вам обосновывать необходимость ваших шагов и сделать движение к ним понятным и предсказуемым. Так же вы сами сможете осознанно выбирать из своих проблем те, которые стоит брать в первую очередь. Инвестируйте в работу с техническим бэклогом и ваша работа станет проще.
Максим Шаламов
#советы
Где граница, когда разработка может менять задачи бизнеса, а когда нет?
Прелесть самоорганизующихся команд в возможности отдать им задачу и забыть о ней. Мы, технари, можем в рамках своей работы, подстраивать решение задачи под обстоятельства, чтобы довести дело до конца. Однако, где проходит та черта, когда мы можем что-то поменять в задаче на свое усмотрение, не привлекая заказчика, а когда этого делать категорически не стоит?
Смотрите на свою бизнес-команду
Конечно же это границы, которые вы должны выстраивать совместно со своей бизнес-командой. Внимательно следите за реакцией бизнес-коллег на ваши действия, отмечайте, когда они остаются довольны, и особо запоминайте моменты, когда ваши действия вызвали возмущение. Это и есть та грань, за которую переходить не стоит. Со временем бизнес начинает вам больше доверять или наоборот перестает доверять, если вы оплошали, поэтому эти границы могут сдвигаться и такое наблюдение и анализ должны быть постоянными.
Вы обязательно должны знать приоритеты и метрики своего бизнеса, чтобы понимать, что критично для вашего проекта. Например, если вы разрабатываете внутреннюю админку для компании, на ваш откуп могут полностью отдать внешний вид, где вы сможете делать все, как вам угодно, но вот функционал будет критично важен. На внешних промо-сайтах, заточенных под рекламную компанию, может быть важен каждый пиксель и любое внешнее изменение будет критично. Изучайте ваш бизнес, старайтесь в нем хорошо разбираться, чтобы разбираться, что важно, а что нет.
Где точно можно разгуляться?
Со своей стороны вы тоже должны выстраивать собственные границы. Вы отвечаете за качество проекта и все технические решения. Поэтому то, что вы на 100% можете менять в проекте это техническая сторона. Вы должны выбирать, как будет строится проект внутри. Если во время выполнения задачи вы поняли, что другое техническое решение подойдет лучше, а бизнес внешне получит тоже самое, то никакого отдельного подтверждения от вам здесь не нужно. Есть только один нюанс: нельзя менять техническое решение, если это затронет метрики бизнеса. Вы вольны делать с технической стороной проекта все, что вам нужно, пока по функционалу, по метрикам и по времени, затраченного командой на работу, для бизнеса ничего не меняется. Если вы вдруг решили потратить 2 месяца чистого времени на смену фреймворка, да еще и проект после этого стал работать в два раза медленнее, то бизнес вам точно спасибо не скажет. Оценивайте, насколько технические изменения касаются бизнеса, если они заметно сказываются на бизнес-части проекта, привлекайте к решению бизнес. Как правильно подавать свое решение и убеждать бизнес в необходимости изменений, мы подробно говорили в документации к работе с ПО,
Куда точно не стоит лезть?
Чего точно не стоит делать без участия бизнеса, так это менять сроки и состав заранее согласованных релизов и запусков. Бизнес должен однозначно решать, какой функционал должен стать доступен пользователю в каком составе. Иногда может казаться, что лучше сделать пол задачи и выкатить, чем не успеть все целиком, но для бизнеса половина задачи может быть либо юридически недопустимой, либо ломать пиар-компанию, которую месяц готовили и обещали совсем другое. Поэтому во всем, что касается изменения сроков и состава релизов, обязательно нужно консультироваться с бизнес-заказчиком и решать все изменения совместно.
Заведите правила
В идеале, вам с бизнесом нужно совместно составить четкие правила, что входит в их компетенцию, а что в вашу. Тогда вы просто работаете по этим правилам и все будут довольны. Конечно же каждую мелочь в правилах не опишешь, поэтому основные принципы стоит понимать.
В заключении, всегда нужно помнить, что мы с бизнесом одна команда. Всегда отталкиваетесь от этого и старайтесь заботится о своем проекте, думая в первую очередь о его будущем, а потом уже о всем остальном. Уважайте своих коллег и не пытайтесь их переиграть лишь бы сделать по-своему, но всегда отстаивайте реально необходимые изменения.
Александра Шаламова
#agile_который_работает
Прелесть самоорганизующихся команд в возможности отдать им задачу и забыть о ней. Мы, технари, можем в рамках своей работы, подстраивать решение задачи под обстоятельства, чтобы довести дело до конца. Однако, где проходит та черта, когда мы можем что-то поменять в задаче на свое усмотрение, не привлекая заказчика, а когда этого делать категорически не стоит?
Смотрите на свою бизнес-команду
Конечно же это границы, которые вы должны выстраивать совместно со своей бизнес-командой. Внимательно следите за реакцией бизнес-коллег на ваши действия, отмечайте, когда они остаются довольны, и особо запоминайте моменты, когда ваши действия вызвали возмущение. Это и есть та грань, за которую переходить не стоит. Со временем бизнес начинает вам больше доверять или наоборот перестает доверять, если вы оплошали, поэтому эти границы могут сдвигаться и такое наблюдение и анализ должны быть постоянными.
Вы обязательно должны знать приоритеты и метрики своего бизнеса, чтобы понимать, что критично для вашего проекта. Например, если вы разрабатываете внутреннюю админку для компании, на ваш откуп могут полностью отдать внешний вид, где вы сможете делать все, как вам угодно, но вот функционал будет критично важен. На внешних промо-сайтах, заточенных под рекламную компанию, может быть важен каждый пиксель и любое внешнее изменение будет критично. Изучайте ваш бизнес, старайтесь в нем хорошо разбираться, чтобы разбираться, что важно, а что нет.
Где точно можно разгуляться?
Со своей стороны вы тоже должны выстраивать собственные границы. Вы отвечаете за качество проекта и все технические решения. Поэтому то, что вы на 100% можете менять в проекте это техническая сторона. Вы должны выбирать, как будет строится проект внутри. Если во время выполнения задачи вы поняли, что другое техническое решение подойдет лучше, а бизнес внешне получит тоже самое, то никакого отдельного подтверждения от вам здесь не нужно. Есть только один нюанс: нельзя менять техническое решение, если это затронет метрики бизнеса. Вы вольны делать с технической стороной проекта все, что вам нужно, пока по функционалу, по метрикам и по времени, затраченного командой на работу, для бизнеса ничего не меняется. Если вы вдруг решили потратить 2 месяца чистого времени на смену фреймворка, да еще и проект после этого стал работать в два раза медленнее, то бизнес вам точно спасибо не скажет. Оценивайте, насколько технические изменения касаются бизнеса, если они заметно сказываются на бизнес-части проекта, привлекайте к решению бизнес. Как правильно подавать свое решение и убеждать бизнес в необходимости изменений, мы подробно говорили в документации к работе с ПО,
Куда точно не стоит лезть?
Чего точно не стоит делать без участия бизнеса, так это менять сроки и состав заранее согласованных релизов и запусков. Бизнес должен однозначно решать, какой функционал должен стать доступен пользователю в каком составе. Иногда может казаться, что лучше сделать пол задачи и выкатить, чем не успеть все целиком, но для бизнеса половина задачи может быть либо юридически недопустимой, либо ломать пиар-компанию, которую месяц готовили и обещали совсем другое. Поэтому во всем, что касается изменения сроков и состава релизов, обязательно нужно консультироваться с бизнес-заказчиком и решать все изменения совместно.
Заведите правила
В идеале, вам с бизнесом нужно совместно составить четкие правила, что входит в их компетенцию, а что в вашу. Тогда вы просто работаете по этим правилам и все будут довольны. Конечно же каждую мелочь в правилах не опишешь, поэтому основные принципы стоит понимать.
В заключении, всегда нужно помнить, что мы с бизнесом одна команда. Всегда отталкиваетесь от этого и старайтесь заботится о своем проекте, думая в первую очередь о его будущем, а потом уже о всем остальном. Уважайте своих коллег и не пытайтесь их переиграть лишь бы сделать по-своему, но всегда отстаивайте реально необходимые изменения.
Александра Шаламова
#agile_который_работает
Ребят, у нас вышло видео с моими фишками прохождения собеседований. Я там много делюсь своим опытом и реальными историями, рассказываю один постыдный случай, как я мега облажалась на собесе 🤦🏼♀️ и как я это пережила. Ну и конечно рассказываю, что мне всегда помогало собирать предложения из таких компаний, как Яндекс, Авито, Сбертех, Lazada, Mail.ru и прочих. Заходите, буду вам рада 🥰
https://youtu.be/vP4fmlzPwos
https://youtu.be/vP4fmlzPwos
YouTube
Как пройти собеседование в топовую ИТ-компанию. Делюсь своими секретами.
Рассказываю, что мне помогало в течении моей карьеры разарботчиком проходить собеседования в лучшие ИТ-компании страны.
Boosty с доп. материалами и ранним доступом: https://boosty.to/itbesedka/posts/585fdf96-d2a3-40d0-ae13-f8a755a0e6c6?share=post_link
…
Boosty с доп. материалами и ранним доступом: https://boosty.to/itbesedka/posts/585fdf96-d2a3-40d0-ae13-f8a755a0e6c6?share=post_link
…
Ощущение рутины - первый признак начала деградации
Как понять, что ты не деградируешь, а продолжаешь расти? Говорят, невозможно остановиться на месте, ты либо растешь, либо деградируешь. Не тренируемые навыки и знания имеют свойство очень быстро улетучиваться. Вот многое вы помните из школьной программы? Даже если вы делаете каждый день одни и теже задачи, ваш навык выполнения этих задач не остается на одном уровне. Знакомые действия постепенно переходят в автоматические, понимание зачем нужно было это действие постепенно стирается, сначала детали, а со временем и сама причина действия. Остается только автоматическое выполнение.
Если ваша работа начала состоять из череды полу-автоматических, одинаковых действий, то очень быстро придет ощущение рутины. Ваш мозг минимально включается в ежедневные однотипные задачи и начинает скучать. И это очень явный признак того, что близко начало деградации. Вам уже все знакомо, вы уже это все делали сотни раз. Вы больше не развиваетесь на текущих задачах.
Ощущение рутины, это хороший триггер того, что вам пора найти для себя новые вызовы. Дать своему мозгу новую пищу для роста, пока коллеги, которых вы когда-то учи еще не стали умнее вас. Как найти такие вызовы, чтобы не вылететь с первых мест на обочину, мы разбирали тут.
А вы что думаете по этому поводу? Обязательно напишите в комментариях свое мнение. Или выразите его хотя бы реакцией к посту - для нас это очень важно!
#советы
Как понять, что ты не деградируешь, а продолжаешь расти? Говорят, невозможно остановиться на месте, ты либо растешь, либо деградируешь. Не тренируемые навыки и знания имеют свойство очень быстро улетучиваться. Вот многое вы помните из школьной программы? Даже если вы делаете каждый день одни и теже задачи, ваш навык выполнения этих задач не остается на одном уровне. Знакомые действия постепенно переходят в автоматические, понимание зачем нужно было это действие постепенно стирается, сначала детали, а со временем и сама причина действия. Остается только автоматическое выполнение.
Если ваша работа начала состоять из череды полу-автоматических, одинаковых действий, то очень быстро придет ощущение рутины. Ваш мозг минимально включается в ежедневные однотипные задачи и начинает скучать. И это очень явный признак того, что близко начало деградации. Вам уже все знакомо, вы уже это все делали сотни раз. Вы больше не развиваетесь на текущих задачах.
Ощущение рутины, это хороший триггер того, что вам пора найти для себя новые вызовы. Дать своему мозгу новую пищу для роста, пока коллеги, которых вы когда-то учи еще не стали умнее вас. Как найти такие вызовы, чтобы не вылететь с первых мест на обочину, мы разбирали тут.
А вы что думаете по этому поводу? Обязательно напишите в комментариях свое мнение. Или выразите его хотя бы реакцией к посту - для нас это очень важно!
#советы
"Почему меня не уважают?"
Этот вопрос нередко задают, а еще чаще о нем думают. Сюда же можно добавить про восприятие в серьез и про "почему меня не слушают". Поделюсь, как всегда, своим мнением.
Я обычно в ответ задаю простой вопрос: "а за что тебя должны уважать (слушать/…)?". Часто мы приходим к несоблюдению своих обещаний, постоянным конфликтам на ровном месте, боязни отстаивать свое мнение и т.д.
Чтобы тебя уважали другие (слушали, воспринимали и т.д.), нужно уважать себя самому и уважать других. Для того, чтобы уйти от расплывчатых философских измышлений поясню свою мысль.
Как нужно себя вести, чтобы тебя уважали:
- На твои обещания можно положиться. Обещал - сделал, сложности это твои проблемы. В самом худшем случае, вовремя сообщаешь о проблеме, при этом объективность проблемы должна быть очевидна всем.
- Ты готов озвучивать и отстаивать свое мнение при любой аудитории. Не только убеждать коллегу, сидящего рядом, но и руководство.
- Ты должен уметь слышать и адекватно воспринимать чужое мнение. Ты можешь быть не согласен, но вести спор или обсуждение нужно корректно и по существу. Ты должен быть готов, что выберут не твое предложение и уметь уступать, а не обижаться на весь мир и сводить все к срачу.
- Ты должен быть готов брать на себя ответственность за провалы, а не только лавры победы. Сложно уважать человека, который не может принять свои ошибки и ходит обвиняет всех вокруг. Так же, как и того, кто пытается присвоить себе успехи всей команды. Успех общий, неудачи обычно имеют имена (в моих командах неудачи тоже общие, но при разборе конкретных проблем всегда есть имена).
Лично я никогда не мучал себя вопросом, кто уважает меня, а кто нет. Однако, прийти к общей стратегии с коллегами или подчиненными обычно удается, поэтому для себя я вижу этот вопрос так.
Что для вас критично, чтобы уважать коллегу? Пишите в комментариях. И не забудьте оставлять реакции, чтобы я мог оценить полезность этой темы для вас.
Максим Шаламов
#руководителю #разработчику
Этот вопрос нередко задают, а еще чаще о нем думают. Сюда же можно добавить про восприятие в серьез и про "почему меня не слушают". Поделюсь, как всегда, своим мнением.
Я обычно в ответ задаю простой вопрос: "а за что тебя должны уважать (слушать/…)?". Часто мы приходим к несоблюдению своих обещаний, постоянным конфликтам на ровном месте, боязни отстаивать свое мнение и т.д.
Чтобы тебя уважали другие (слушали, воспринимали и т.д.), нужно уважать себя самому и уважать других. Для того, чтобы уйти от расплывчатых философских измышлений поясню свою мысль.
Как нужно себя вести, чтобы тебя уважали:
- На твои обещания можно положиться. Обещал - сделал, сложности это твои проблемы. В самом худшем случае, вовремя сообщаешь о проблеме, при этом объективность проблемы должна быть очевидна всем.
- Ты готов озвучивать и отстаивать свое мнение при любой аудитории. Не только убеждать коллегу, сидящего рядом, но и руководство.
- Ты должен уметь слышать и адекватно воспринимать чужое мнение. Ты можешь быть не согласен, но вести спор или обсуждение нужно корректно и по существу. Ты должен быть готов, что выберут не твое предложение и уметь уступать, а не обижаться на весь мир и сводить все к срачу.
- Ты должен быть готов брать на себя ответственность за провалы, а не только лавры победы. Сложно уважать человека, который не может принять свои ошибки и ходит обвиняет всех вокруг. Так же, как и того, кто пытается присвоить себе успехи всей команды. Успех общий, неудачи обычно имеют имена (в моих командах неудачи тоже общие, но при разборе конкретных проблем всегда есть имена).
Лично я никогда не мучал себя вопросом, кто уважает меня, а кто нет. Однако, прийти к общей стратегии с коллегами или подчиненными обычно удается, поэтому для себя я вижу этот вопрос так.
Что для вас критично, чтобы уважать коллегу? Пишите в комментариях. И не забудьте оставлять реакции, чтобы я мог оценить полезность этой темы для вас.
Максим Шаламов
#руководителю #разработчику
Ко мне периодически заходят люди с вопросами какие технологии выбрать для карьеры разработчика, что учить перед собеседованием. Я всегда стараюсь дать не конкретную технологию, а рассказать принцип, чтобы человек в любой момент мог легко сменить сферу и всегда знал, как выбрать новые технологии для свой карьеры. Записала об этом видео, рассказала, как при смене сферы или просто с нуля понять, какие технологии тебе нужны. Обязательно делитесь с теми, кто сейчас на перепутье.
https://youtu.be/EpMjYQTCGnU
https://youtu.be/EpMjYQTCGnU
YouTube
Что учить для успешной карьеры разработчика
Как не ошибиться с выбором технологий для изучения, если вы находитесь на распутье своей карьеры.
Как выгодно подать свой опыт на собеседовании: https://boosty.to/itbesedka/posts/585fdf96-d2a3-40d0-ae13-f8a755a0e6c6?share=post_link
Boosty с доп. материалами…
Как выгодно подать свой опыт на собеседовании: https://boosty.to/itbesedka/posts/585fdf96-d2a3-40d0-ae13-f8a755a0e6c6?share=post_link
Boosty с доп. материалами…
О чем мы писали в Марте
Если вы что-то пропустили в прошлом месяце, то самое время наверстать:
Зачем разработчику уметь работать по процессам, если есть руководители и скрам-мастера
Что я получу взамен, если возьму на себя ответственность?
Алгоритм работы с техническим бэклогом
Когда разработка может менять задачи, не спрашивая бизнес
Чем опасно ощущение рутины
А на Boosty вы найдете подробный разбор, как заставить собеседующего захотеть тебя нанять сразу же после рассказа о прошлом опыте. С помощью этого подхода я несколько раз вообще не проходила техническую часть собеседования 😉
Оставайтесь с нами, в заготовленных постах уже лежит много интересного! А если хотите пост на свою тему, то задавайте вопросы в нашего бота.
Если вы что-то пропустили в прошлом месяце, то самое время наверстать:
Зачем разработчику уметь работать по процессам, если есть руководители и скрам-мастера
Что я получу взамен, если возьму на себя ответственность?
Алгоритм работы с техническим бэклогом
Когда разработка может менять задачи, не спрашивая бизнес
Чем опасно ощущение рутины
А на Boosty вы найдете подробный разбор, как заставить собеседующего захотеть тебя нанять сразу же после рассказа о прошлом опыте. С помощью этого подхода я несколько раз вообще не проходила техническую часть собеседования 😉
Оставайтесь с нами, в заготовленных постах уже лежит много интересного! А если хотите пост на свою тему, то задавайте вопросы в нашего бота.