Сильный тимлид или скиловый техлид - кто важнее для вашего роста?
В прошлом посте Максим привел пример про желание кандидатов найти сильного тимлида, под которым чаще всего подразумевается скиловый техлид. Поговорим про это подробнее.
Висит груша - нельзя скушать
Будучи джуном, я работала в одной из топовый ИТ-компаний. Был у нас и тимлид и скиловый синьор. И вроде бы все для счастья есть и один мой коллега-джун решил этим счастьем воспользоваться. Повадился он ходить к нашему синьору с вопросами. Раз на третий его подхода к синьору раздался на весь офис возмущенный крик тимлида "Ты долго собираешься мешать ему работать? Тебе заняться нечем? Так давай я тебе задач подкину". К синьору больше никто из джунов не подходил.
Никогда не смотрите на простой факт наличия в компании "крутого скилового чувака". Всегда пытайтесь выяснить, как это будет влиять на вас. Спрашивайте, как выглядят процессы в компании? Каким образом происходит рост сотрудников? Как в техническом росте команды участвуют интересующие вас специалисты? А самое главное, будете ли вы частью всего этого?
Несомненно в задачи и тимлида и техлида входит рост технической команды. Разберемся в чем может быть разница для роста подчиненного.
Чем поможет скиловый техлид?
Техлид должен заниматься техническим ростом команды. Он лучше всех разбирается в технологиях проекта и архитектуре, досконально знает, как работает проект. Помогает в проработке конкретных задач, проводит ревью. Выявляет слабые технические стороны участников команды, составляет технические списки на рост. В целом, хороший техлид является этакой базой знаний, он не даст сделать плохо и поможет научиться делать хорошо.
Чем поможет сильный тимлид?
Основная задача тимлида заниматься налаживанием работы команды. Это все, что касается процессов, взаимодействия с бизнесом, взаимодействия с соседними отделами, он кто настраивает общение с вышестоящим руководством и помогает выстраивать в их голове правильное представление о работе вашего отдела. В том числе он занимается ростом команды по софт-скиллам, должностному и финансовому росту. В идеале, это тот человек, который обеспечивает вас условиями для вашего роста и развития.
Благодаря сильному тимлиду вы получаете хорошо описанные задачи и тратите свое время не на выяснение деталей от бизнеса и переделывание того, что было недосказано в задаче, а на продумывание того, как бы лучше эту задачу сделать технически. Вы не тратите время на бессмысленные встречи вместо работы над проектом. Получаете целостный, технически качественный проект, потому что он отстаивает правильные фичи перед бизнесом. Получаете время на починку технических багов, время на работу над техдолгом: рефакторинг, улучшение безопасности, расширяемости проекта. Сильный тимлид создает условия для комфортного общения внутри команды и обмена опытом, что позволяет всем участникам расти вместе и каждому получать выгоду от нахождения в команде. Он создает ту атмосферу и те процессы, которые позволяют участникам команды черпать опыт друг у друга. Благодаря ему руководство видит все ваши заслуги и дает вашей команде ресурсы, деньги на повышения, найм новых сотрудников и качественное железо. Если тимлид действительно хорошо делает свою работу, то вам будет просто стыдно не развиваться в такой команде, потому что у вас будут для этого все условия.
Так кто важнее для роста тимлид или техлид?
Лично мое мнение, что для роста человека в команде намного важнее наличие сильного тимлида, именно в значении тимлида. С хорошим тимлидом, отсутствие техлида можно будет компенсировать, а вот имея скилового техлида без кого-то, кто отладит работу отдела, вы скорее всего получите ту самую не съедобную грушу. Чаще всего в таких командах самый сильный разработчик сидит и разрабатывает, ему некогда помогать кому-то расти, а все остальные чинят баги и бегают в огне, потому что команда не может качественно работать без настроенных процессов.
Александра Шаламова #советы
В прошлом посте Максим привел пример про желание кандидатов найти сильного тимлида, под которым чаще всего подразумевается скиловый техлид. Поговорим про это подробнее.
Висит груша - нельзя скушать
Будучи джуном, я работала в одной из топовый ИТ-компаний. Был у нас и тимлид и скиловый синьор. И вроде бы все для счастья есть и один мой коллега-джун решил этим счастьем воспользоваться. Повадился он ходить к нашему синьору с вопросами. Раз на третий его подхода к синьору раздался на весь офис возмущенный крик тимлида "Ты долго собираешься мешать ему работать? Тебе заняться нечем? Так давай я тебе задач подкину". К синьору больше никто из джунов не подходил.
Никогда не смотрите на простой факт наличия в компании "крутого скилового чувака". Всегда пытайтесь выяснить, как это будет влиять на вас. Спрашивайте, как выглядят процессы в компании? Каким образом происходит рост сотрудников? Как в техническом росте команды участвуют интересующие вас специалисты? А самое главное, будете ли вы частью всего этого?
Несомненно в задачи и тимлида и техлида входит рост технической команды. Разберемся в чем может быть разница для роста подчиненного.
Чем поможет скиловый техлид?
Техлид должен заниматься техническим ростом команды. Он лучше всех разбирается в технологиях проекта и архитектуре, досконально знает, как работает проект. Помогает в проработке конкретных задач, проводит ревью. Выявляет слабые технические стороны участников команды, составляет технические списки на рост. В целом, хороший техлид является этакой базой знаний, он не даст сделать плохо и поможет научиться делать хорошо.
Чем поможет сильный тимлид?
Основная задача тимлида заниматься налаживанием работы команды. Это все, что касается процессов, взаимодействия с бизнесом, взаимодействия с соседними отделами, он кто настраивает общение с вышестоящим руководством и помогает выстраивать в их голове правильное представление о работе вашего отдела. В том числе он занимается ростом команды по софт-скиллам, должностному и финансовому росту. В идеале, это тот человек, который обеспечивает вас условиями для вашего роста и развития.
Благодаря сильному тимлиду вы получаете хорошо описанные задачи и тратите свое время не на выяснение деталей от бизнеса и переделывание того, что было недосказано в задаче, а на продумывание того, как бы лучше эту задачу сделать технически. Вы не тратите время на бессмысленные встречи вместо работы над проектом. Получаете целостный, технически качественный проект, потому что он отстаивает правильные фичи перед бизнесом. Получаете время на починку технических багов, время на работу над техдолгом: рефакторинг, улучшение безопасности, расширяемости проекта. Сильный тимлид создает условия для комфортного общения внутри команды и обмена опытом, что позволяет всем участникам расти вместе и каждому получать выгоду от нахождения в команде. Он создает ту атмосферу и те процессы, которые позволяют участникам команды черпать опыт друг у друга. Благодаря ему руководство видит все ваши заслуги и дает вашей команде ресурсы, деньги на повышения, найм новых сотрудников и качественное железо. Если тимлид действительно хорошо делает свою работу, то вам будет просто стыдно не развиваться в такой команде, потому что у вас будут для этого все условия.
Так кто важнее для роста тимлид или техлид?
Лично мое мнение, что для роста человека в команде намного важнее наличие сильного тимлида, именно в значении тимлида. С хорошим тимлидом, отсутствие техлида можно будет компенсировать, а вот имея скилового техлида без кого-то, кто отладит работу отдела, вы скорее всего получите ту самую не съедобную грушу. Чаще всего в таких командах самый сильный разработчик сидит и разрабатывает, ему некогда помогать кому-то расти, а все остальные чинят баги и бегают в огне, потому что команда не может качественно работать без настроенных процессов.
Александра Шаламова #советы
Как быстро снять стресс в рабочей обстановке
По опросам 2021 года лишь 9% людей не испытывают стресс на работе. Длительный стресс может привести как к выгоранию, так и к различным заболеваниям. А еще неправильная реакция на него может испортить ваши отношения с коллегами и мешать вашей карьере. Поэтому я подобрала для вас быстрые и действенные способы, которые можно применять прямо на рабочем месте.
Правильное восприятие стресса
В целом, стресс это совершенно нормальная реакция организма, помогающая вам справляться со сложными задачами. Он активизирует резервы, дает больше энергии, улучшает мыслительные процессы. Вот некоторые плюсы стресса:
- улучшение памяти;
- повышение иммунитета;
- ускоренное восстановление;
- активация интеллектуальных способностей;
- повышение выносливости нервной системы;
- улучшение работы органов чувств.
Однозначно, стресс может быть полезным. Но как избежать его вреда? Исследования показывают, что уменьшить влияние стресса на организм поможет изменение отношения к нему. Если разум меняет отношение к стрессу, то и тело начинает реагировать иначе. Поэтому первый совет: если вы начинаете чувствовать признаки стресса в своем организме, воспринимайте это как помощь, а не как что-то плохое. Сердце готовится к действиям, поэтому его биение учащается. Быстрое дыхание доставляет больше кислорода к мозгу. Ваш организм вам помогает. Такое отношение значительно снизит негативное влияние стресса и вы быстрее придете в норму.
Упражнения для быстрого снятия стресса
Что делать в моменте, когда эмоции берут верх, а вам нужно продолжать работать? Есть различные упражнения, помогающие снять текущее состояние стресса.
Перенаправление внимания
Один из методов это переправить свое внимание, отвлечь свой мозг от текущего момента. Несколько примеров таких упражнений:
- Просто разговор с кем-то на отвлеченную тему.
- Подумать о чём-то не связанным с работой, вспомните, чего вы хотите достичь в своих хобби.
- Ненадолго сменить обстановку, выйти из места, где почувствовали стресс, 10 минут пройтись по улице, уделяя внимание окружению.
- Полезно попробовать сконцентрироваться на вещах, которые вас окружают. Сосчитать количество ступенек, найти все предметы белого цвета в комнате, придумать для предметов успокаивающую ассоциацию и т.д.
- Посчитать сколько дней осталось до вашего дня рождения или нового года. Арифметические упражнения хорошо занимают мозг.
Можно придумать много способов, главное переключить внимание от текущей проблемы.
Дыхательные упражнения
- Медленное дыхание. Для начала просто начните медленно дышать.
- Дыхание животом. При стрессе мы не замечаем как переключаемся на поверхностное дыхание. Попробуйте осознанно медленно подышать, надувая живот, а не грудь.
- Дыхание 4-7-8. Одна из знаменитых техник, помогающих быстро дать телу сигнал, что опасность миновала и можно успокоится. Сделайте вход в течении 4 секунд (можно просто медленно считать до 4), затем задержите дыхание на 7 секунд и выдыхайте 8 секунд.
Визуализация
Придумайте для себя место спокойствия, в стрессовой ситуации, по возможности, закройте глаза и представьте себя в этом месте.
Расслабление мышц
Разум напрягает тело, а расслабленное тело успокаивает разум. Попробуйте расслаблять по очереди все мышцы тела, почувствуйте все напряжённые места и расслабьте эти мышцы. Также здесь может помочь метод самовнушения, повторяйте для каждой части тела «моя шея расслабляется», «мои руки расслабляются» и т.д.
Это лишь малая часть подобных методов, находите для себя подходящий и используйте в случае стресса. Не забудьте сохранить этот пост, чтобы он всегда был под рукой.
Александра Шаламова #советы
По опросам 2021 года лишь 9% людей не испытывают стресс на работе. Длительный стресс может привести как к выгоранию, так и к различным заболеваниям. А еще неправильная реакция на него может испортить ваши отношения с коллегами и мешать вашей карьере. Поэтому я подобрала для вас быстрые и действенные способы, которые можно применять прямо на рабочем месте.
Правильное восприятие стресса
В целом, стресс это совершенно нормальная реакция организма, помогающая вам справляться со сложными задачами. Он активизирует резервы, дает больше энергии, улучшает мыслительные процессы. Вот некоторые плюсы стресса:
- улучшение памяти;
- повышение иммунитета;
- ускоренное восстановление;
- активация интеллектуальных способностей;
- повышение выносливости нервной системы;
- улучшение работы органов чувств.
Однозначно, стресс может быть полезным. Но как избежать его вреда? Исследования показывают, что уменьшить влияние стресса на организм поможет изменение отношения к нему. Если разум меняет отношение к стрессу, то и тело начинает реагировать иначе. Поэтому первый совет: если вы начинаете чувствовать признаки стресса в своем организме, воспринимайте это как помощь, а не как что-то плохое. Сердце готовится к действиям, поэтому его биение учащается. Быстрое дыхание доставляет больше кислорода к мозгу. Ваш организм вам помогает. Такое отношение значительно снизит негативное влияние стресса и вы быстрее придете в норму.
Упражнения для быстрого снятия стресса
Что делать в моменте, когда эмоции берут верх, а вам нужно продолжать работать? Есть различные упражнения, помогающие снять текущее состояние стресса.
Перенаправление внимания
Один из методов это переправить свое внимание, отвлечь свой мозг от текущего момента. Несколько примеров таких упражнений:
- Просто разговор с кем-то на отвлеченную тему.
- Подумать о чём-то не связанным с работой, вспомните, чего вы хотите достичь в своих хобби.
- Ненадолго сменить обстановку, выйти из места, где почувствовали стресс, 10 минут пройтись по улице, уделяя внимание окружению.
- Полезно попробовать сконцентрироваться на вещах, которые вас окружают. Сосчитать количество ступенек, найти все предметы белого цвета в комнате, придумать для предметов успокаивающую ассоциацию и т.д.
- Посчитать сколько дней осталось до вашего дня рождения или нового года. Арифметические упражнения хорошо занимают мозг.
Можно придумать много способов, главное переключить внимание от текущей проблемы.
Дыхательные упражнения
- Медленное дыхание. Для начала просто начните медленно дышать.
- Дыхание животом. При стрессе мы не замечаем как переключаемся на поверхностное дыхание. Попробуйте осознанно медленно подышать, надувая живот, а не грудь.
- Дыхание 4-7-8. Одна из знаменитых техник, помогающих быстро дать телу сигнал, что опасность миновала и можно успокоится. Сделайте вход в течении 4 секунд (можно просто медленно считать до 4), затем задержите дыхание на 7 секунд и выдыхайте 8 секунд.
Визуализация
Придумайте для себя место спокойствия, в стрессовой ситуации, по возможности, закройте глаза и представьте себя в этом месте.
Расслабление мышц
Разум напрягает тело, а расслабленное тело успокаивает разум. Попробуйте расслаблять по очереди все мышцы тела, почувствуйте все напряжённые места и расслабьте эти мышцы. Также здесь может помочь метод самовнушения, повторяйте для каждой части тела «моя шея расслабляется», «мои руки расслабляются» и т.д.
Это лишь малая часть подобных методов, находите для себя подходящий и используйте в случае стресса. Не забудьте сохранить этот пост, чтобы он всегда был под рукой.
Александра Шаламова #советы
Как бороться с усталостью
Мы уже говорили про выгорание и что это не равносильно усталости. В последнее время очень большой акцент делается на выгорании, не только потому, что люди осознали это как проблему, но и потому, что это модно и молодежно.
Однако проблемы связанные с банальной усталостью и переутомлением никуда не делись и ее влияние на ваше состояние или состояние вашей команды тоже может стать разрушительным. На самом деле с усталостью все кажется проще: вовремя отдыхаешь, быстро переключаешься на отдых и всего-то. В целом, если это получается, то на этом можно и закончить, но, обычно, бывают периоды, когда работа не выпускает и наваливается как лавина. Находясь в процессе, ты реально можешь не замечать, что просто вымотан до предела и работаешь на чистом адреналине от стрессовой составляющей такого подхода. И в таком состоянии не всегда бывает очевидно, что отдых уже критически необходим. На самом деле встречал я такое у большинства своих коллег, впрочем как у и себя.
Признаки усталости
Дак какие же признаки могут нам помочь отследить это состояние:
- Вы бегаете от всего нового. Вообще от всего: новые люди, музыка, фильмы, любые новые впечатления.
- Пропадает желание и мотивация заниматься своими хобби. У вас банально нет сил, но обычно ощущается, как отсутствие желания, что может вводить в заблуждение.
- В работе вы цепляетесь за рутинные задачи не требующие долгого осмысления.
- Концентрация на новых задачах и проблемах дается с огромным трудом
Для отслеживания этого у себя, коллег или подчиненных нужно внимательно следить за этими признаками. Банально слушать человека, или себя, и анализировать информацию будет достаточно. Так же, как руководитель, я принял для себя правило сразу отпускать человека в отпуск, если он сам хочет или ему нужно. Я максимально стараюсь искать возможности, чтобы не делать исключения в этом правиле. Релизы и прочее есть всегда, но мне нужен бодрый, мотивированный и сосредоточенный человек, а не тот кто может с трудом разгребать рутинные задачи.
Если в отпуск уйти не получается
В связи с этим появляется вопрос, а что делать если время пришло, а в отпуск уйти не получается? Есть ли лайфхак? На мой взгляд - нет. Все что можно тут предложить это смягчить ход событий:
- Больше спите, когда чувствуете в этом потребность.
- Получайте новые эмоции и впечатления, это поможет вам вырываться из уныния, которое идет вкупе с накатывающей усталостью.
- Не берите лишних задач, раз уж вы не тянете то, что у вас уже есть.
- Берите отпуск сразу, как будет возможность, не ждите идеальный момент.
Вообще последний пункт довольно важный, идеальных моментов для отпуска не бывает, поэтому передавайте дела (подойдите к этому ответственно) и спокойно отдыхайте. Берегите себя и окружающих людей, отдыхайте вовремя тогда и работа и жизнь будут значительно приятнее.
Максим Шаламов
#советы #тимлиду #разработчику
Мы уже говорили про выгорание и что это не равносильно усталости. В последнее время очень большой акцент делается на выгорании, не только потому, что люди осознали это как проблему, но и потому, что это модно и молодежно.
Однако проблемы связанные с банальной усталостью и переутомлением никуда не делись и ее влияние на ваше состояние или состояние вашей команды тоже может стать разрушительным. На самом деле с усталостью все кажется проще: вовремя отдыхаешь, быстро переключаешься на отдых и всего-то. В целом, если это получается, то на этом можно и закончить, но, обычно, бывают периоды, когда работа не выпускает и наваливается как лавина. Находясь в процессе, ты реально можешь не замечать, что просто вымотан до предела и работаешь на чистом адреналине от стрессовой составляющей такого подхода. И в таком состоянии не всегда бывает очевидно, что отдых уже критически необходим. На самом деле встречал я такое у большинства своих коллег, впрочем как у и себя.
Признаки усталости
Дак какие же признаки могут нам помочь отследить это состояние:
- Вы бегаете от всего нового. Вообще от всего: новые люди, музыка, фильмы, любые новые впечатления.
- Пропадает желание и мотивация заниматься своими хобби. У вас банально нет сил, но обычно ощущается, как отсутствие желания, что может вводить в заблуждение.
- В работе вы цепляетесь за рутинные задачи не требующие долгого осмысления.
- Концентрация на новых задачах и проблемах дается с огромным трудом
Для отслеживания этого у себя, коллег или подчиненных нужно внимательно следить за этими признаками. Банально слушать человека, или себя, и анализировать информацию будет достаточно. Так же, как руководитель, я принял для себя правило сразу отпускать человека в отпуск, если он сам хочет или ему нужно. Я максимально стараюсь искать возможности, чтобы не делать исключения в этом правиле. Релизы и прочее есть всегда, но мне нужен бодрый, мотивированный и сосредоточенный человек, а не тот кто может с трудом разгребать рутинные задачи.
Если в отпуск уйти не получается
В связи с этим появляется вопрос, а что делать если время пришло, а в отпуск уйти не получается? Есть ли лайфхак? На мой взгляд - нет. Все что можно тут предложить это смягчить ход событий:
- Больше спите, когда чувствуете в этом потребность.
- Получайте новые эмоции и впечатления, это поможет вам вырываться из уныния, которое идет вкупе с накатывающей усталостью.
- Не берите лишних задач, раз уж вы не тянете то, что у вас уже есть.
- Берите отпуск сразу, как будет возможность, не ждите идеальный момент.
Вообще последний пункт довольно важный, идеальных моментов для отпуска не бывает, поэтому передавайте дела (подойдите к этому ответственно) и спокойно отдыхайте. Берегите себя и окружающих людей, отдыхайте вовремя тогда и работа и жизнь будут значительно приятнее.
Максим Шаламов
#советы #тимлиду #разработчику
Говорим правду руководству - подводные камни
Меня давно просили написать о том, как говорить неудобную правду в лицо, а еще лучше руководству, и чтобы за это ничего не было. Мол у меня есть опыт. Я долго обдумывал свое мнение на этот счет, в итоге, что я могу сказать. Я бы начал с установки, что вы будете говорить не правду, а свое мнение, и пытаться этим достичь своих целей (мнение может быть как правдой, так и вашей картиной мира).
Что стоит иметь ввиду
Первое, правда - очень специфичное понятие. В одной и той же ситуации вы можете быть и правы и нет. Например, требуя определенных действий или результатов от соседних отделов, вы можете не представлять о их приоритизации или проблемах иного рода. В итоге, вы будете правы, что вам должны предоставить, то, что вы требуете, но, с учетом реальности, и не правы, потому что это невозможно. Поэтому в любой ситуации имейте ввиду, что ситуации может быть сложнее, чем вам видится, но это не повод молчать и не задавать вопросы.
Решите зачем вам это
Второе, наверное самое важное, нужно понимать зачем вы хотите свою "правду" озвучивать. Для меня всегда важно следовать своим установкам, чтобы работа, за которую я отвечаю, делалась правильно (по моим стандартам) и своевременно. Когда я вижу помехи со стороны, я пытаюсь на это повлиять настолько насколько я могу. Тут и попытки напрямую разобраться в проблему и эскалация к руководству и конечно же по возможности настойчивость. Один раз поднять вопрос мало, обычно нужно убеждать людей, искать новые слова, примеры, моменты. Некоторые вещи могут занимать больше года и двух, так что тут нужно много терпения, поэтому важно понимать зачем. Если вы просто хотите задеть кого-то или набросить на вентилятор, это того не стоит. Если вы преследуете свои четкие цели, даже если будет выглядеть как-то не так в глазах окружающих, оно того стоит.
Последствия
Ну и еще один момент, чтобы за это ничего не было не бывает. Постоянно поднимая проблему, пытаясь копаться в тех, которые хотят оставить за границей видимости, вы наработаете определенную репутацию. Такие вещи часто приводят к конфликтам, поэтому, если вы любитель ввернуть резкое словцо, то получите репутацию конфликтного товарища. Скажу по себе, в момент, когда я рос от ведущего до директора разработки, с моим подходом повышения меня обходили с завидным постоянством. Меня это устраивало, потому что когда я его получал, то получал на приемлемых для меня условиях (без компромиссов никуда). Поэтому, если ваша цель быстрый карьерный рост, то такой подход вам явно не помощник в этом.
Что еще бы хотел посоветовать, когда поднимаете постоянно проблемы, будьте готовы к тому, что от вас будут требовать идеи того, как их решить (раз уж вам они мешают), либо часть проблем просто отдадут вам.
Не знаю, что сказать в заключении в этот раз. Подавать ли свое мнение прямо и настойчиво, поднимать ли вопросы по проблемам до победы или закрывать на них глаза, каждый решает сам. Это очень сложная и неприятная (лично по моему мнению) тема и тут надо иметь свои четкие ориентиры и исходя из них выбирать стоит ли ломиться в закрытые ворота или это та проблема, которая не стоит ваших усилий.
Максим Шаламов
#советы
Меня давно просили написать о том, как говорить неудобную правду в лицо, а еще лучше руководству, и чтобы за это ничего не было. Мол у меня есть опыт. Я долго обдумывал свое мнение на этот счет, в итоге, что я могу сказать. Я бы начал с установки, что вы будете говорить не правду, а свое мнение, и пытаться этим достичь своих целей (мнение может быть как правдой, так и вашей картиной мира).
Что стоит иметь ввиду
Первое, правда - очень специфичное понятие. В одной и той же ситуации вы можете быть и правы и нет. Например, требуя определенных действий или результатов от соседних отделов, вы можете не представлять о их приоритизации или проблемах иного рода. В итоге, вы будете правы, что вам должны предоставить, то, что вы требуете, но, с учетом реальности, и не правы, потому что это невозможно. Поэтому в любой ситуации имейте ввиду, что ситуации может быть сложнее, чем вам видится, но это не повод молчать и не задавать вопросы.
Решите зачем вам это
Второе, наверное самое важное, нужно понимать зачем вы хотите свою "правду" озвучивать. Для меня всегда важно следовать своим установкам, чтобы работа, за которую я отвечаю, делалась правильно (по моим стандартам) и своевременно. Когда я вижу помехи со стороны, я пытаюсь на это повлиять настолько насколько я могу. Тут и попытки напрямую разобраться в проблему и эскалация к руководству и конечно же по возможности настойчивость. Один раз поднять вопрос мало, обычно нужно убеждать людей, искать новые слова, примеры, моменты. Некоторые вещи могут занимать больше года и двух, так что тут нужно много терпения, поэтому важно понимать зачем. Если вы просто хотите задеть кого-то или набросить на вентилятор, это того не стоит. Если вы преследуете свои четкие цели, даже если будет выглядеть как-то не так в глазах окружающих, оно того стоит.
Последствия
Ну и еще один момент, чтобы за это ничего не было не бывает. Постоянно поднимая проблему, пытаясь копаться в тех, которые хотят оставить за границей видимости, вы наработаете определенную репутацию. Такие вещи часто приводят к конфликтам, поэтому, если вы любитель ввернуть резкое словцо, то получите репутацию конфликтного товарища. Скажу по себе, в момент, когда я рос от ведущего до директора разработки, с моим подходом повышения меня обходили с завидным постоянством. Меня это устраивало, потому что когда я его получал, то получал на приемлемых для меня условиях (без компромиссов никуда). Поэтому, если ваша цель быстрый карьерный рост, то такой подход вам явно не помощник в этом.
Что еще бы хотел посоветовать, когда поднимаете постоянно проблемы, будьте готовы к тому, что от вас будут требовать идеи того, как их решить (раз уж вам они мешают), либо часть проблем просто отдадут вам.
Не знаю, что сказать в заключении в этот раз. Подавать ли свое мнение прямо и настойчиво, поднимать ли вопросы по проблемам до победы или закрывать на них глаза, каждый решает сам. Это очень сложная и неприятная (лично по моему мнению) тема и тут надо иметь свои четкие ориентиры и исходя из них выбирать стоит ли ломиться в закрытые ворота или это та проблема, которая не стоит ваших усилий.
Максим Шаламов
#советы
Использование грейдов: частые ошибки
К теме грейдов подходят очень по-разному, в каждой компании свои требования и ожидания, я даже заставал эксперимент по плоской структуре в рамках большой компании (сюрприз, но оно не заработало). Я много общаюсь и читаю на тему организации работы команд. Поговорим о том, что я выделил из разговоров по ожиданиям к людям и что я об этом думаю.
Частые ошибки в использовании грейдов
Многие руководители в принципе считают, что им грейды не нужны. В идеальной картине мира куда как проще иметь кучу взаимозаменяемых людей, равной производительности. По такому принципу стараются жить веб-студии, правда даже им приходится обзаводиться грейдами.
Что еще обязательно выделяют - это самостоятельность. Конечно же сам от клиента получил задачу, сам сделал, сам выкатил - красота. Конечно, желательно, чтобы время на ревью и прочие мелочи типа тестирования не тратилось. Вообще когда продукт разрабатывает много людей и он разрастается, то такая самостоятельность будет чудовищно бить по качеству и поддерживаемости проекта. Не говоря о потере контроля за имеющимся функционалом.
Конечно же ответственность и вовлеченность, ну чтобы работал побольше, возмущался поменьше. У клиента есть проблема - все бросил и пошел решать (приоритетов нет), потом доделываешь то, что делал в те же сроки.
По грейдам, джун это тот, кто будет умирать на работе 24/7, он ведь ничего не знает, а задач будут выдавать примерно как всем. Мидл, ну он должен решать задачи, ну по сути любые. Синьоры - это вообще в таком концепции волшебники, которым можно скинуть что угодно и получить за 5 минут решение. А лиды: ну чтобы удержать синьора можно и грейд дать.
Естественно я говорю не о всех компаниях и руководителях, но таких очень немало и они схожи в своих ожиданиях. Многие запросы скрывают нежелание и неумение выстраивать работу. В целом в таком виде это приводит к большой текучке и довольно печальным продуктам.
Как я работаю с грейдами
Что касается моего мнения, то грейды нужны и людям, чтобы отмерять свой прогресс и статус, и руководителям, чтобы адекватно понимать какие к кому можно предъявлять требования. В маленькой команде высококлассных специалистов, формализмы не нужны, в остальных случаях без этого будет сложно.
Ответственность, самостоятельность и вовлеченность, необходимы любому сотруднику и таких людей нужно искать. Но во-первых, если демотивировать людей плохо выстроенными процессами, то любое вовлечение и ответственность начнут отказывать. А второе, что все свои усилия люди должны направлять в рамках зафиксированных (устно или письменно) внутрикомандных правил, тогда это будет хорошо работать и не приводить к проблемам.
Если говорить о самих грейдах, то джуны для меня это люди с неплохой теоретической базой, желающие расти и развиваться, которым интересна область, в которой они работают. Мидлы - люди, которые имеют неплохой практический опыт и могут решать основные типовые задачи на проекте. Синьоры - это люди, которые могут решить любую задачу в рамках проекта, могут помочь другим участникам команды, умеют коммуницировать вне команды. Про тех и тимлидов я писал отдельно.
Но в целом нужны вам грейды или нет, кого вы ищите и как, в итоге будете решать только вы.
Максим Шаламов
#сто #тимлиду #руководителю
К теме грейдов подходят очень по-разному, в каждой компании свои требования и ожидания, я даже заставал эксперимент по плоской структуре в рамках большой компании (сюрприз, но оно не заработало). Я много общаюсь и читаю на тему организации работы команд. Поговорим о том, что я выделил из разговоров по ожиданиям к людям и что я об этом думаю.
Частые ошибки в использовании грейдов
Многие руководители в принципе считают, что им грейды не нужны. В идеальной картине мира куда как проще иметь кучу взаимозаменяемых людей, равной производительности. По такому принципу стараются жить веб-студии, правда даже им приходится обзаводиться грейдами.
Что еще обязательно выделяют - это самостоятельность. Конечно же сам от клиента получил задачу, сам сделал, сам выкатил - красота. Конечно, желательно, чтобы время на ревью и прочие мелочи типа тестирования не тратилось. Вообще когда продукт разрабатывает много людей и он разрастается, то такая самостоятельность будет чудовищно бить по качеству и поддерживаемости проекта. Не говоря о потере контроля за имеющимся функционалом.
Конечно же ответственность и вовлеченность, ну чтобы работал побольше, возмущался поменьше. У клиента есть проблема - все бросил и пошел решать (приоритетов нет), потом доделываешь то, что делал в те же сроки.
По грейдам, джун это тот, кто будет умирать на работе 24/7, он ведь ничего не знает, а задач будут выдавать примерно как всем. Мидл, ну он должен решать задачи, ну по сути любые. Синьоры - это вообще в таком концепции волшебники, которым можно скинуть что угодно и получить за 5 минут решение. А лиды: ну чтобы удержать синьора можно и грейд дать.
Естественно я говорю не о всех компаниях и руководителях, но таких очень немало и они схожи в своих ожиданиях. Многие запросы скрывают нежелание и неумение выстраивать работу. В целом в таком виде это приводит к большой текучке и довольно печальным продуктам.
Как я работаю с грейдами
Что касается моего мнения, то грейды нужны и людям, чтобы отмерять свой прогресс и статус, и руководителям, чтобы адекватно понимать какие к кому можно предъявлять требования. В маленькой команде высококлассных специалистов, формализмы не нужны, в остальных случаях без этого будет сложно.
Ответственность, самостоятельность и вовлеченность, необходимы любому сотруднику и таких людей нужно искать. Но во-первых, если демотивировать людей плохо выстроенными процессами, то любое вовлечение и ответственность начнут отказывать. А второе, что все свои усилия люди должны направлять в рамках зафиксированных (устно или письменно) внутрикомандных правил, тогда это будет хорошо работать и не приводить к проблемам.
Если говорить о самих грейдах, то джуны для меня это люди с неплохой теоретической базой, желающие расти и развиваться, которым интересна область, в которой они работают. Мидлы - люди, которые имеют неплохой практический опыт и могут решать основные типовые задачи на проекте. Синьоры - это люди, которые могут решить любую задачу в рамках проекта, могут помочь другим участникам команды, умеют коммуницировать вне команды. Про тех и тимлидов я писал отдельно.
Но в целом нужны вам грейды или нет, кого вы ищите и как, в итоге будете решать только вы.
Максим Шаламов
#сто #тимлиду #руководителю
Вчера на нашем YouTube-канале вышло новое видео по теме выгорания. Кроме тем этого канала в видео-формате там иногда выходят видео и на другие темы.
https://youtu.be/tpOLjsGfl5Q
https://youtu.be/tpOLjsGfl5Q
YouTube
Главная причина выгорания и два пути ее преодоления
С выгоранием сталкивается огромное количество человек. Но избавится от него не так уж и просто. Зная причины, вы будете иметь больше шансов совладать с проблемой. В этом видео мы поговорим о самой частой причине выгорания и обсудим какие есть два самых действенных…
Признаки плохого работодателя, которые можно выявить на собеседовании. Часть 1.
Есть некоторые проблемы, которые могут помешать комфортной и эффективной работе в компании. Чаще всего они выясняются уже после трудоустройства, но есть некоторые признаки, которые можно выявить прямо на собеседовании. Мы собрали для вас основные из них.
Основной прием, которым нужно пользоваться
Самое главное - не забывайте, что собеседование это обоюдная вещь. Вы продаете свои услуги, а компания продает себя, как лучшего работодателя для вас. Поэтому вы тоже должны внимательно следить за тем, как идет собеседование, как общаются ваши потенциальные коллеги и руководители.
Признак переработок
Первое, на что следует обращать внимание, это какое впечатление создают ваши коллеги. Нередко можно увидеть замученных и невыспавшихся людей, которые будут вести собеседование уткнувшись в ноутбуки. Если таких людей больше одного, то это явно не проблема конкретного человека, а повод задуматься над адекватностью загрузки людей в компании.
Признак возможных конфликтов
Следующее: обращайте внимание на то, умеет ли люди, с которыми вам работать, слушать. Очень часто встречаются собеседники, которые, выслушав ваши ответы, по второму кругу спрашивают какие-то вещи (не разово, что вполне нормально, а постоянно на протяжении всего собеседования). Работа в команде, где не умеют слышать друг друга, приведет к постоянным конфликтам на этапе интеграций, ревью и релизов. Если же это ваш потенциальный руководитель, то тут возникнут трудности с тем, что о ваших проблемах (которые всегда случаются на протяжении работы) скорее всего не услышат и не отреагируют.
Признак неумения ставить задачи
Важный момент, особенно, если вы говорите с руководителем, это умение ставить задачу (объяснить понятно то, что от вас требуется). Ведь ваша работа состоит из решения набора поставленных задач. Если с этим видятся трудности на этапе собеседования, то эти трудности перекочуют в вашу каждодневную работу и будут причиной раздражений и конфликтов.
Признак неумения принимать чужое мнение
Очень важно понять как люди реагируют на ошибки или ситуации, где не согласны с ответом. Если вы идете совсем гладко, я бы даже предложил немного оговориться в каком-то не критичном месте, чтобы увидеть реакцию. Если вы увидите торжество победителя на лице собеседующего, потоки язвительности или иные попытки вас задеть или обидеть, то я бы советовал обходить стороной такие команды и компании. В работе мы порой ошибаемся, а ситуации когда мнение на решение задачи расходятся бывают совсем часто, поэтому умение себя вести в таких ситуациях критически важно.
Больше признаков обсудим в следующем посте. А вопросы, которые обязательно нужно задавать работодателю на собеседовании можно посмотреть в нашем старом посте.
#советы #разработчику
Есть некоторые проблемы, которые могут помешать комфортной и эффективной работе в компании. Чаще всего они выясняются уже после трудоустройства, но есть некоторые признаки, которые можно выявить прямо на собеседовании. Мы собрали для вас основные из них.
Основной прием, которым нужно пользоваться
Самое главное - не забывайте, что собеседование это обоюдная вещь. Вы продаете свои услуги, а компания продает себя, как лучшего работодателя для вас. Поэтому вы тоже должны внимательно следить за тем, как идет собеседование, как общаются ваши потенциальные коллеги и руководители.
Признак переработок
Первое, на что следует обращать внимание, это какое впечатление создают ваши коллеги. Нередко можно увидеть замученных и невыспавшихся людей, которые будут вести собеседование уткнувшись в ноутбуки. Если таких людей больше одного, то это явно не проблема конкретного человека, а повод задуматься над адекватностью загрузки людей в компании.
Признак возможных конфликтов
Следующее: обращайте внимание на то, умеет ли люди, с которыми вам работать, слушать. Очень часто встречаются собеседники, которые, выслушав ваши ответы, по второму кругу спрашивают какие-то вещи (не разово, что вполне нормально, а постоянно на протяжении всего собеседования). Работа в команде, где не умеют слышать друг друга, приведет к постоянным конфликтам на этапе интеграций, ревью и релизов. Если же это ваш потенциальный руководитель, то тут возникнут трудности с тем, что о ваших проблемах (которые всегда случаются на протяжении работы) скорее всего не услышат и не отреагируют.
Признак неумения ставить задачи
Важный момент, особенно, если вы говорите с руководителем, это умение ставить задачу (объяснить понятно то, что от вас требуется). Ведь ваша работа состоит из решения набора поставленных задач. Если с этим видятся трудности на этапе собеседования, то эти трудности перекочуют в вашу каждодневную работу и будут причиной раздражений и конфликтов.
Признак неумения принимать чужое мнение
Очень важно понять как люди реагируют на ошибки или ситуации, где не согласны с ответом. Если вы идете совсем гладко, я бы даже предложил немного оговориться в каком-то не критичном месте, чтобы увидеть реакцию. Если вы увидите торжество победителя на лице собеседующего, потоки язвительности или иные попытки вас задеть или обидеть, то я бы советовал обходить стороной такие команды и компании. В работе мы порой ошибаемся, а ситуации когда мнение на решение задачи расходятся бывают совсем часто, поэтому умение себя вести в таких ситуациях критически важно.
Больше признаков обсудим в следующем посте. А вопросы, которые обязательно нужно задавать работодателю на собеседовании можно посмотреть в нашем старом посте.
#советы #разработчику
Признаки плохого работодателя, которые можно выявить на собеседовании. Часть 2.
Продолжим обсуждать признаки плохих работодателей, которые можно выявить на собеседовании.
Признак неумения слушать или технически слабая команда
Есть еще тревожный звоночек, когда собеседующий хочет услышать только то решение, которое есть в его голове, даже если предложенное не хуже или лучше. Тут снова будет проблема с тем, что ваши коллеги/руководители не умеют слушать и это будет вашей проблемой. Гипотетически такое может быть от низкой квалификации собеседника, который просто вычитал решение и сам не очень понимает, что делать.
Признаки плохо выстроенных процессов
Хорошим показателем слаженной работы, или ее отсутствия, является в целом процесс ведения собеседования. Вам должны представить всех участников, люди должны понимать заранее кто и что будет спрашивать, если кто-то выбывает (например сейчас это актуально из-за возможных проблем с подключением на удаленных собеседованиях), то его тут же страхуют другие участники. Конечно все мы люди и небольшие заминки это нормально, но паузы по несколько минут или жонглирование тем, кто начнет и что спросит не очень хороший показатель.
Полное отсутствие продаж
Если компании и сотрудникам вовсе нечего рассказать о своей компании и задачах, то, возможно, это не та компания, где вам стоит работать. Здесь есть много вариантов отчего возникает эта проблема. Вот основные из них:
- люди настолько устали, что у них нет сил на то, чтобы продавать вам компанию;
- людям не нравится то, чем они занимаются и они просто отбывают повинность, собеседуя вас;
- еще один признак плохо выстроенных проецессов, человек просто не готов к собеседованию и не знает достаточно о конкретном месте, в которое идет набор;
- люди, которые собеседуют, не понимают зачем им это нужно - это признак плохой организации процессов в компании.
Признак нечестной компании
Иногда в процессе собеседований начинают всплывать подробности, которые не оговаривались в самом начале. Например, всплывают новые неоговоренные этапы собеседований. Могут возникнуть новые условия по выдаче техники, способе выплаты зарплаты (например премиальная часть раз в три месяца на значимую часть обещанной суммы в месяц), может выясниться, что обещанная удаленка на самом деле имеет какие-то ограничения и т.д. Это признак того, что компания пытается заманить вас в общение любым способом, скрывая детали будущей работы и обманывая уже на этапе собеседования. Такой компании не стоит доверять и вряд ли вас будет ждать что-то хорошее после трудоустройства.
Признаки плохих процессов и какими вопросами их можно найти
После того как очередь дойдет до вас, обязательно поговорите о процессе работы в компании и команде:
- Как устроен процесс постановки и оценки задач?
- Как распределяются задачи?
- Кто за что в команде и компании отвечает?
- Как устроен процесс приемки и ревью?
- Как устроен процесс работы с релизами, работа с найденными по ходу багами и т.д.?
- Как устроена работа с найденными на проекте багами?
- Что происходит, когда оцененный скоп задач меняется? Как часто это случается?
- Что делать, если наполовину сделанная задача становится не нужна или менее приоритетна и как часто это происходит?
Тут важно услышать стройное повествование, когда чувствуется, что люди рассказываются о чем-то устоявшемся и очевидном. Хорошо, когда сами говорят о проблемах и исключениях (такое бывает всегда, если проект не мертв). Если вы видите нестыковки или не услышали то, что хотели, задавайте уточняющие вопросы. На этом этапе можно узнать очень многое о том, как на самом деле работает компания, если внимательно слушать и не бояться задавать вопросы.
В заключении: что бы вы не услышали, как принимать решение это дело каждого. Но важно на собеседовании собрать для себя максимум информации, чтобы сделать правильный выбор. Слушайте внимательно, не бойтесь задавать вопросы и вы найдете достойный вариант.
#советы #разработчику
Продолжим обсуждать признаки плохих работодателей, которые можно выявить на собеседовании.
Признак неумения слушать или технически слабая команда
Есть еще тревожный звоночек, когда собеседующий хочет услышать только то решение, которое есть в его голове, даже если предложенное не хуже или лучше. Тут снова будет проблема с тем, что ваши коллеги/руководители не умеют слушать и это будет вашей проблемой. Гипотетически такое может быть от низкой квалификации собеседника, который просто вычитал решение и сам не очень понимает, что делать.
Признаки плохо выстроенных процессов
Хорошим показателем слаженной работы, или ее отсутствия, является в целом процесс ведения собеседования. Вам должны представить всех участников, люди должны понимать заранее кто и что будет спрашивать, если кто-то выбывает (например сейчас это актуально из-за возможных проблем с подключением на удаленных собеседованиях), то его тут же страхуют другие участники. Конечно все мы люди и небольшие заминки это нормально, но паузы по несколько минут или жонглирование тем, кто начнет и что спросит не очень хороший показатель.
Полное отсутствие продаж
Если компании и сотрудникам вовсе нечего рассказать о своей компании и задачах, то, возможно, это не та компания, где вам стоит работать. Здесь есть много вариантов отчего возникает эта проблема. Вот основные из них:
- люди настолько устали, что у них нет сил на то, чтобы продавать вам компанию;
- людям не нравится то, чем они занимаются и они просто отбывают повинность, собеседуя вас;
- еще один признак плохо выстроенных проецессов, человек просто не готов к собеседованию и не знает достаточно о конкретном месте, в которое идет набор;
- люди, которые собеседуют, не понимают зачем им это нужно - это признак плохой организации процессов в компании.
Признак нечестной компании
Иногда в процессе собеседований начинают всплывать подробности, которые не оговаривались в самом начале. Например, всплывают новые неоговоренные этапы собеседований. Могут возникнуть новые условия по выдаче техники, способе выплаты зарплаты (например премиальная часть раз в три месяца на значимую часть обещанной суммы в месяц), может выясниться, что обещанная удаленка на самом деле имеет какие-то ограничения и т.д. Это признак того, что компания пытается заманить вас в общение любым способом, скрывая детали будущей работы и обманывая уже на этапе собеседования. Такой компании не стоит доверять и вряд ли вас будет ждать что-то хорошее после трудоустройства.
Признаки плохих процессов и какими вопросами их можно найти
После того как очередь дойдет до вас, обязательно поговорите о процессе работы в компании и команде:
- Как устроен процесс постановки и оценки задач?
- Как распределяются задачи?
- Кто за что в команде и компании отвечает?
- Как устроен процесс приемки и ревью?
- Как устроен процесс работы с релизами, работа с найденными по ходу багами и т.д.?
- Как устроена работа с найденными на проекте багами?
- Что происходит, когда оцененный скоп задач меняется? Как часто это случается?
- Что делать, если наполовину сделанная задача становится не нужна или менее приоритетна и как часто это происходит?
Тут важно услышать стройное повествование, когда чувствуется, что люди рассказываются о чем-то устоявшемся и очевидном. Хорошо, когда сами говорят о проблемах и исключениях (такое бывает всегда, если проект не мертв). Если вы видите нестыковки или не услышали то, что хотели, задавайте уточняющие вопросы. На этом этапе можно узнать очень многое о том, как на самом деле работает компания, если внимательно слушать и не бояться задавать вопросы.
В заключении: что бы вы не услышали, как принимать решение это дело каждого. Но важно на собеседовании собрать для себя максимум информации, чтобы сделать правильный выбор. Слушайте внимательно, не бойтесь задавать вопросы и вы найдете достойный вариант.
#советы #разработчику
Работа мечты
Я очень часто в различных неформальных обсуждениях слышу от людей о том, что их компания мечты Х или проект У, но это все мечты и фантазии. Многие люди годами думают как бы было хорошо, но ничего для этого не делают. Что я хочу сказать и всегда говорю в таких случаях: если есть такая особая компания или проект, то нужно попробовать себя именно на этом месте, тем более что обычно это вполне реально.
Стоит попробовать, даже если в итоге вы откажетесь
Чтобы ничего не перевирать, возьму свои примеры. Когда я перебрался в Москву, мне казалось, что ИТ-компаний кроме Яндекса то и нет. Пройти туда на нужную зарплату с ходу не получилось, а интересные проекты оказалось, что есть и в других местах. Однако, ощущение, что нужно получить оффер именно от Яндекса осталось (причем, как я сейчас понимаю, работать в Яндексе уже желания особенного не было). И уже работая в Сбербанке, я подумал, а собственно почему бы и не закрыть эту тему для себя, тем более, что в тот момент я был техническим руководителем, еще полностью не ушел в управление и пожалуй был в лучших технических кондициях, чем когда-либо еще. Поход в Яндекс закончился для меня неожиданно, я получил оффер, да еще на зарплату на 30% выше текущей. Не смотря на то, что оффер я в итоге отклонил, получив те же деньги в Сбербанке, я не жалею, что закрыл для себя эту тему. Это придало мне уверенности в своих силах и сделало мой выбор осознанным, а не вынужденным из-за того, что я не смог получить оффер в определенную компанию.
Стоит попробовать, даже если не понравится
Такая же история у меня была с командой поиска. В момент, когда я уже поработал тимлидом, я думал, что поиск это что-то другое, более сложное и интересное и не правильно уходить в сторону управления, не попробовав. Я готовился к собеседованиям три месяца и еще примерно полтора занял процесс собеседований. В итоге, я прошел и поработал в команде поиска. В целом, для себя я понял, что в этом нет ничего сверхъестественного, да и задачи быстро становятся обыденными. Я поработал там совсем недолго, полностью переключившись в сторону развития в тимлида и дальше, но я очень рад что попробовал. Я понял, что могу с этим справится, понял, что там точно такие же задачи только со своей спецификой, а развитие в эту сторону мне не сильно интересно.
Что вы получаете в итоге
В целом, может показаться, что я веду к тому, что все эти мечты бред и не окупаются. На самом деле нет, даже не смотря на то, что я не получил ожидаемого, для меня это было очень важно. Это позволило мне закрыть для себя эти темы, не жалеть, что я не попробовал и не думать о том, а что если бы. Как минимум с этой точки зрения, это очень важно. Конечно, поработать в месте, которое вы считаете для себя особенным, в целом помогает почувствовать себя увереннее, а подготовка дает новые знания. Более того, многие люди пройдя по этому пути остаются более чем довольными, что вложили столько усилий и на долгие годы связывают себя с этой компанией или проектом. Основная моя идея в том, что нужно идти к тому, чего вы хотите. Не бойтесь пробовать и вкладывать время и усилия в подготовку, это в любом случае окупится.
Максим Шаламов
#советы #разработчику
Я очень часто в различных неформальных обсуждениях слышу от людей о том, что их компания мечты Х или проект У, но это все мечты и фантазии. Многие люди годами думают как бы было хорошо, но ничего для этого не делают. Что я хочу сказать и всегда говорю в таких случаях: если есть такая особая компания или проект, то нужно попробовать себя именно на этом месте, тем более что обычно это вполне реально.
Стоит попробовать, даже если в итоге вы откажетесь
Чтобы ничего не перевирать, возьму свои примеры. Когда я перебрался в Москву, мне казалось, что ИТ-компаний кроме Яндекса то и нет. Пройти туда на нужную зарплату с ходу не получилось, а интересные проекты оказалось, что есть и в других местах. Однако, ощущение, что нужно получить оффер именно от Яндекса осталось (причем, как я сейчас понимаю, работать в Яндексе уже желания особенного не было). И уже работая в Сбербанке, я подумал, а собственно почему бы и не закрыть эту тему для себя, тем более, что в тот момент я был техническим руководителем, еще полностью не ушел в управление и пожалуй был в лучших технических кондициях, чем когда-либо еще. Поход в Яндекс закончился для меня неожиданно, я получил оффер, да еще на зарплату на 30% выше текущей. Не смотря на то, что оффер я в итоге отклонил, получив те же деньги в Сбербанке, я не жалею, что закрыл для себя эту тему. Это придало мне уверенности в своих силах и сделало мой выбор осознанным, а не вынужденным из-за того, что я не смог получить оффер в определенную компанию.
Стоит попробовать, даже если не понравится
Такая же история у меня была с командой поиска. В момент, когда я уже поработал тимлидом, я думал, что поиск это что-то другое, более сложное и интересное и не правильно уходить в сторону управления, не попробовав. Я готовился к собеседованиям три месяца и еще примерно полтора занял процесс собеседований. В итоге, я прошел и поработал в команде поиска. В целом, для себя я понял, что в этом нет ничего сверхъестественного, да и задачи быстро становятся обыденными. Я поработал там совсем недолго, полностью переключившись в сторону развития в тимлида и дальше, но я очень рад что попробовал. Я понял, что могу с этим справится, понял, что там точно такие же задачи только со своей спецификой, а развитие в эту сторону мне не сильно интересно.
Что вы получаете в итоге
В целом, может показаться, что я веду к тому, что все эти мечты бред и не окупаются. На самом деле нет, даже не смотря на то, что я не получил ожидаемого, для меня это было очень важно. Это позволило мне закрыть для себя эти темы, не жалеть, что я не попробовал и не думать о том, а что если бы. Как минимум с этой точки зрения, это очень важно. Конечно, поработать в месте, которое вы считаете для себя особенным, в целом помогает почувствовать себя увереннее, а подготовка дает новые знания. Более того, многие люди пройдя по этому пути остаются более чем довольными, что вложили столько усилий и на долгие годы связывают себя с этой компанией или проектом. Основная моя идея в том, что нужно идти к тому, чего вы хотите. Не бойтесь пробовать и вкладывать время и усилия в подготовку, это в любом случае окупится.
Максим Шаламов
#советы #разработчику
Как развлечься на работе
Довольно часто я слышу о том, что людям в какой-то момент становится скучно от выполнения их обязанностей, все надоело и нужно менять работу. В целом, не вижу ничего криминального в смене работы, просто для себя важно понимать истинные причины этого. Скука она весьма субъективна и обычно найдет вас везде, если вы не научитесь правильно к этому подходить. Говорить о случаях когда есть иные причины для недовольства я не буду.
Зона комфорта
Скука выплывает обычно в контексте того, что работа по ведению проекта устаканилась и идет своим чередом, соответственно больше не дает дополнительных вызовов и роста. На самом деле это самообман и вы просто вошли в зону комфорта, из которой сами себя вытаскивать не хотите, а смена работа естественным образом решит эту проблему на время, но именно на время. Почему я в уверен, что скука идет от зоны комфорта? Потому что идеальных ситуаций/проектов/команд/технологий/... не бывает. Просто со временем вы принимаете некоторые вещи как данность и перестаете пытаться их улучшить. Дальнейшие упражнения имеют смысл, если вас в целом все устраивает и нет других серьезных причин для увольнения. Так же оставим в стороне случаи, когда вы хотите других позиций в целом.
Как выбраться из зоны комфорта не меняя работу
Итак принимаем за данность, что ничего идеального в нашем мире не бывает. Выделяем для себя время не менее часа в день, на протяжении хотя бы недели. В это время начинаем подробно смотреть на свою работу. Смотрим на все составляющие вашего проекта, на процессы, по которым работает команда (причем ваша позиция в такой ситуации значения не имеет, хотя конечно и сложность с внедрениями зависит от позиции), тех. долг, подходы к автоматизации и тестированию и прочие компоненты, из которых состоит ваша работа и работа вашей команды. Составьте список проблем и отсортируйте их по собственному видению приоритетов. Дальше Возьмите топ-3 проблем и проработайте их, то есть опишите (прямо в документе) суть проблемы, ее влияние на проект и команду, и ваше видение ее решения. Очень вдумчиво подойдите к этому процессу, не спешите и все детально описывайте. Пока вы будете писать и перечитывать, вы сможете хотя бы немного со стороны посмотреть на свои идеи, это поможет вам их сформулировать максимально доступно. После этого представьте свои идеи руководству и команде, обсудите с ними ваше видение, предложите попробовать и возьмите на себя ответственность. Даже если первые идеи отсеют, то вы найдете те проблемы, над которыми сможете поработать и вовлечь других. Начинайте с малых шагов, всегда помните о том, что нужно иметь метрики как было и как стало, обязательно показывайте результаты команде и руководству, помогайте другим вовлекаться в изменения, слушайте обратную связь и корректируйте свои подходы.
Что если идей по улучшениям нет
Бывают ситуации, когда у вас нет идей, как что-то улучшить. Тогда воспользуйтесь знаниями других, читайте книги, смотрите доклады, обсуждайте с коллегами внутри и вне компании (главное без обсуждения чувствительных вещей для компании). В итоге вы наберете набор идей и подходов, которые можно попробовать. Выберите наиболее подходящий и идите по плану описанному выше.
Таким образом, можно все время улучшать окружающие вас рабочие моменты, изучать что-то самому, приносить пользу себе и компании, а главное заскучать таким образом будет довольно сложно.
Максим Шаламов
#советы #разработчику #тимлиду
Довольно часто я слышу о том, что людям в какой-то момент становится скучно от выполнения их обязанностей, все надоело и нужно менять работу. В целом, не вижу ничего криминального в смене работы, просто для себя важно понимать истинные причины этого. Скука она весьма субъективна и обычно найдет вас везде, если вы не научитесь правильно к этому подходить. Говорить о случаях когда есть иные причины для недовольства я не буду.
Зона комфорта
Скука выплывает обычно в контексте того, что работа по ведению проекта устаканилась и идет своим чередом, соответственно больше не дает дополнительных вызовов и роста. На самом деле это самообман и вы просто вошли в зону комфорта, из которой сами себя вытаскивать не хотите, а смена работа естественным образом решит эту проблему на время, но именно на время. Почему я в уверен, что скука идет от зоны комфорта? Потому что идеальных ситуаций/проектов/команд/технологий/... не бывает. Просто со временем вы принимаете некоторые вещи как данность и перестаете пытаться их улучшить. Дальнейшие упражнения имеют смысл, если вас в целом все устраивает и нет других серьезных причин для увольнения. Так же оставим в стороне случаи, когда вы хотите других позиций в целом.
Как выбраться из зоны комфорта не меняя работу
Итак принимаем за данность, что ничего идеального в нашем мире не бывает. Выделяем для себя время не менее часа в день, на протяжении хотя бы недели. В это время начинаем подробно смотреть на свою работу. Смотрим на все составляющие вашего проекта, на процессы, по которым работает команда (причем ваша позиция в такой ситуации значения не имеет, хотя конечно и сложность с внедрениями зависит от позиции), тех. долг, подходы к автоматизации и тестированию и прочие компоненты, из которых состоит ваша работа и работа вашей команды. Составьте список проблем и отсортируйте их по собственному видению приоритетов. Дальше Возьмите топ-3 проблем и проработайте их, то есть опишите (прямо в документе) суть проблемы, ее влияние на проект и команду, и ваше видение ее решения. Очень вдумчиво подойдите к этому процессу, не спешите и все детально описывайте. Пока вы будете писать и перечитывать, вы сможете хотя бы немного со стороны посмотреть на свои идеи, это поможет вам их сформулировать максимально доступно. После этого представьте свои идеи руководству и команде, обсудите с ними ваше видение, предложите попробовать и возьмите на себя ответственность. Даже если первые идеи отсеют, то вы найдете те проблемы, над которыми сможете поработать и вовлечь других. Начинайте с малых шагов, всегда помните о том, что нужно иметь метрики как было и как стало, обязательно показывайте результаты команде и руководству, помогайте другим вовлекаться в изменения, слушайте обратную связь и корректируйте свои подходы.
Что если идей по улучшениям нет
Бывают ситуации, когда у вас нет идей, как что-то улучшить. Тогда воспользуйтесь знаниями других, читайте книги, смотрите доклады, обсуждайте с коллегами внутри и вне компании (главное без обсуждения чувствительных вещей для компании). В итоге вы наберете набор идей и подходов, которые можно попробовать. Выберите наиболее подходящий и идите по плану описанному выше.
Таким образом, можно все время улучшать окружающие вас рабочие моменты, изучать что-то самому, приносить пользу себе и компании, а главное заскучать таким образом будет довольно сложно.
Максим Шаламов
#советы #разработчику #тимлиду
Как настроить инфраструктуру pet-проектов
Довольно часто, многие из нас, по той или иной причине, заводят свои небольшие проекты. Цели у каждого свои, но такие попытки я видел у большинства своих знакомых и сам такие проекты имею. Хотел бы немного поделиться своими соображениями о техническом подходе к таким проектам и как я сам в итоге стал делать.
Какие проблемы могут возникнуть
Раньше, как и многие сейчас, я просто брал выделенный недорогой сервер, поднимал там весь проект и он жил себе не тужил, но у этого всегда было много трудностей (по крайней мере для меня). В проектах появлялся фронт (ssr) и бек API, потом появлялись фоновые процессы запущенные отдельно, не проблемы, но за каждым из них нужен мониторинг и настройка перезапуска при падении. Проблемы могли быть, если кто-то будет выжирать всю память или процессор. Я не говорю уже о том чудном дне, когда люди начнут приходить и ты понимаешь, что серверов должно становиться больше. Следующей проблемой являются базы данных, поднять их не сложно, но ведь нужно настроить тот же мониторинг с рестартом при проблемах и как минимум начать делать бекапы. Конечно же любые раздаваемые файлы, тоже нужно бекапировать и не слечь при их раздаче. Естественно это все решаемо, можно настроить, если потратить достаточно времени. Но, как я уже сказал, проект то по большому счету хоббийный, времени на лишнюю мороку нет, а то, что есть, хочется уделить проекту.
Как сделать эффективнее
Поэтому я сменил подход. Если это проект, где хочется посмотреть на реакцию аудитории для начала, то берем тильду или готовую cms, закупаем немного трафика и смотрим переходить ли на следующий этап.
Перейдя на следующий этап, или сразу начиная с него, я беру готовые инфраструктурные компоненты. Все сервисы я запускаю в kubernetes, который беру как сервис у любого нравящегося вам крупного поставщика облачных услуг. Это сразу решает описанные мною проблемы, с Docker я думаю все умеют работать (ну либо довольно не сложно научиться это делать). Базы данных тоже берем как сервис, с настроенным мониторингом и бэкапами (если есть желание можете добавить ручной бекап в хранилище на этом же поставщике или другом). Добавляем cdn для раздачи статики (опять же предложений вагон, выбираем на свой вкус) и docker regestry для хранения и раздачи образов. Я обычно беру все это в одном месте для простоты эксплуатации. В итоге получаем масштабируемую систему, с неплохим базовым мониторингом, совсем не зависящую от используемых языков программирования.
Да, конечно возникнет вопрос деплоя проектов и изменений в базы, но собственно он возникает всегда. Тут каждый выбирает от своих потребностей и возможностей. Кто-то любит, что-то типа circleci, кто-то напишет вручную. Пока команда маленькая, это не имеет значение. Как только будет расти команда и будет вырисовываться сложный процесс перед выкаткой проекта, то конечно нужно будет брать облачные инструменты (тут тоже есть из чего выбрать).
Минусом данного подхода будет выросшая цена. На текущий момент, чтобы быть уверенным, что все заработает это обойдется в 15-20 тысяч рублей в месяц. Не дешево? но подъемно. В принципе ужаться можно будет и до 8-10 тысяч. Дополнительным плюсом будет, то что вы не ограничены одним проектом, и, настроив выкатку раз, сможете запускать и другие свои проекты схожим образом, без затрат временных усилий.
Максим Шаламов
#советы #разработчику
Довольно часто, многие из нас, по той или иной причине, заводят свои небольшие проекты. Цели у каждого свои, но такие попытки я видел у большинства своих знакомых и сам такие проекты имею. Хотел бы немного поделиться своими соображениями о техническом подходе к таким проектам и как я сам в итоге стал делать.
Какие проблемы могут возникнуть
Раньше, как и многие сейчас, я просто брал выделенный недорогой сервер, поднимал там весь проект и он жил себе не тужил, но у этого всегда было много трудностей (по крайней мере для меня). В проектах появлялся фронт (ssr) и бек API, потом появлялись фоновые процессы запущенные отдельно, не проблемы, но за каждым из них нужен мониторинг и настройка перезапуска при падении. Проблемы могли быть, если кто-то будет выжирать всю память или процессор. Я не говорю уже о том чудном дне, когда люди начнут приходить и ты понимаешь, что серверов должно становиться больше. Следующей проблемой являются базы данных, поднять их не сложно, но ведь нужно настроить тот же мониторинг с рестартом при проблемах и как минимум начать делать бекапы. Конечно же любые раздаваемые файлы, тоже нужно бекапировать и не слечь при их раздаче. Естественно это все решаемо, можно настроить, если потратить достаточно времени. Но, как я уже сказал, проект то по большому счету хоббийный, времени на лишнюю мороку нет, а то, что есть, хочется уделить проекту.
Как сделать эффективнее
Поэтому я сменил подход. Если это проект, где хочется посмотреть на реакцию аудитории для начала, то берем тильду или готовую cms, закупаем немного трафика и смотрим переходить ли на следующий этап.
Перейдя на следующий этап, или сразу начиная с него, я беру готовые инфраструктурные компоненты. Все сервисы я запускаю в kubernetes, который беру как сервис у любого нравящегося вам крупного поставщика облачных услуг. Это сразу решает описанные мною проблемы, с Docker я думаю все умеют работать (ну либо довольно не сложно научиться это делать). Базы данных тоже берем как сервис, с настроенным мониторингом и бэкапами (если есть желание можете добавить ручной бекап в хранилище на этом же поставщике или другом). Добавляем cdn для раздачи статики (опять же предложений вагон, выбираем на свой вкус) и docker regestry для хранения и раздачи образов. Я обычно беру все это в одном месте для простоты эксплуатации. В итоге получаем масштабируемую систему, с неплохим базовым мониторингом, совсем не зависящую от используемых языков программирования.
Да, конечно возникнет вопрос деплоя проектов и изменений в базы, но собственно он возникает всегда. Тут каждый выбирает от своих потребностей и возможностей. Кто-то любит, что-то типа circleci, кто-то напишет вручную. Пока команда маленькая, это не имеет значение. Как только будет расти команда и будет вырисовываться сложный процесс перед выкаткой проекта, то конечно нужно будет брать облачные инструменты (тут тоже есть из чего выбрать).
Минусом данного подхода будет выросшая цена. На текущий момент, чтобы быть уверенным, что все заработает это обойдется в 15-20 тысяч рублей в месяц. Не дешево? но подъемно. В принципе ужаться можно будет и до 8-10 тысяч. Дополнительным плюсом будет, то что вы не ограничены одним проектом, и, настроив выкатку раз, сможете запускать и другие свои проекты схожим образом, без затрат временных усилий.
Максим Шаламов
#советы #разработчику
Выбираем работу по самочувствию в офисе
Мы довольно много пишем о критериях выбора компании, что спросить и как не ошибиться. Недавно я понял, что есть один не маловажный аспект, о котором часто забываю и я и другие люди.
Если вам придется часто работать в офисе, то очень важно понять каким будет ваше рабочее место и обстановка. Многие недооценивают вклад рабочего места и пространства в продуктувность своей работы и в то, в каком состоянии вы будете к концу рабочего дня.
Что в этом плане имеет очень малое значение это офисное здание как таковое, плюшки, берушки и т.д. (хорошо если есть, но можно и под себя организовать).
Что важно на самом деле
Что вам реально нужно? Ваше рабочее место - стол и стул, которые должны быть удобными. Освещение, чтоб не посадить зрение и не мучаться с засветами от окон и ламп. Кондиционирование и приток воздуха. Все это можно проверить, бегло пройдя по офису. Так же постарайтесь понять уровень шума и если он большой, то есть ли места, где можно поработать в тишине.
Лично я стал большое внимание уделять именно притоку воздуха, потому что в ряде офисом с этим проблемы и к вечеру голова чугунная и чувствуешь себя разбитым. Вроде мелочь, но очень сильно все портит, особенно в долгосрочной перспективе.
Это не повод отказаться от оффера, но повод обсудить удаленку или гибрид. Все таки здоровье и производительность должны быть на первом месте, что выгодно и для компании.
Максим Шаламов
#советы #разработчику
Мы довольно много пишем о критериях выбора компании, что спросить и как не ошибиться. Недавно я понял, что есть один не маловажный аспект, о котором часто забываю и я и другие люди.
Если вам придется часто работать в офисе, то очень важно понять каким будет ваше рабочее место и обстановка. Многие недооценивают вклад рабочего места и пространства в продуктувность своей работы и в то, в каком состоянии вы будете к концу рабочего дня.
Что в этом плане имеет очень малое значение это офисное здание как таковое, плюшки, берушки и т.д. (хорошо если есть, но можно и под себя организовать).
Что важно на самом деле
Что вам реально нужно? Ваше рабочее место - стол и стул, которые должны быть удобными. Освещение, чтоб не посадить зрение и не мучаться с засветами от окон и ламп. Кондиционирование и приток воздуха. Все это можно проверить, бегло пройдя по офису. Так же постарайтесь понять уровень шума и если он большой, то есть ли места, где можно поработать в тишине.
Лично я стал большое внимание уделять именно притоку воздуха, потому что в ряде офисом с этим проблемы и к вечеру голова чугунная и чувствуешь себя разбитым. Вроде мелочь, но очень сильно все портит, особенно в долгосрочной перспективе.
Это не повод отказаться от оффера, но повод обсудить удаленку или гибрид. Все таки здоровье и производительность должны быть на первом месте, что выгодно и для компании.
Максим Шаламов
#советы #разработчику
Работа мечты: как не споткнуться о разочарование
Когда Максим написал свой пост о работе мечты, мы договорились, что я напишу о своем опыте, чтобы дать вам больше примеров, почему нужно пытаться работать там, где хочется. Но чем больше я об этом думаю, тем больше понимаю, что буду только повторяться. Но, говоря о том какие плюсы вы можете получить, поработав на месте своей мечты, мы не можем не сказать о минусах таких попыток и том, как не обжечься о разочарование (а тут уж мне есть что рассказать).
Опасность первая: повестись на маркетинг
Большие ИТ-компании вкладываются в свой маркетинг среди кандидатов. Вы видите их сотрудников на конференциях и в статьях на Хабре, они выступают спонсорами событий, открывают свои курсы. От этого создается впечатление, что в компании очень дружественная обстановка, вас все готовы учить, они ведь совершенно бесплатно ходят выступать, чтобы делиться своими знаниями, и они действительно много знают. Но будьте осторожны в таких рассуждениях. Внутри всегда может оказать, что выступающего, на пример, лишат премии, если он не сделает очередной доклад, а откапывал он эти бесценные знания рыская по интернету за неделю до выступления. Если у вас есть хорошее впечатление о компании, то не полагайтесь на него полностью. Найдите людей, которые работают, а еще лучше работали в этой компании, пообщайтесь с ними, поспрашивайте коллег, что они слышали об этой компании. Иногда от одного разговора с бывшим сотрудником компании может кардинально поменяться впечатление.
Опасность вторая: ждать слишком многого
Как хорошобыть молодым и наивным пройти шесть собеседований в компанию своей мечты, уступить пару десятков процентов в зарплате и наконец получить желанное место. А потом понять, что ничего из того, что ты себе представлял здесь нет, а работа скучна и однообразна. Такой поворот может быть очень опасным моментом в вашей карьере. Мы уже говорили о том, к чему могут привести неправильные ожидания. Меня, на пример, в свое время они чуть не довели до смены профессии. Поэтому, постарайтесь не надумывать о компании больше чем знаете. Узнайте как можно больше о том, что в компании на самом деле есть, что будет на вашем проекте. Сядьте и хорошенько подумайте действительно ли там есть то, чего вы ищете. И опять же, не бойтесь задавать правильные вопросы на собеседовании, как бы вам не хотелось скорее его закончить и согласится на оффер. Для этого конечно же подготовьте эти вопросы перед собеседованием в соответствии с вашими текущими запросами к будущей работе. Помните, что поторопившись в выборе сейчас, вы можете потерять уйму времени потом.
За свою более чем 10-летнюю практику я ни один раз стремилась на место своей мечты и ни один раз в нем разочаровывалась, совершая именно эти две ошибки. Несомненно я все равно получала бесценный опыт и росла технически (правда больше на этапе подготовки) и становилась более уверена в своих силах. Но эти ошибки не давали мне выбрать место, где бы я осталась хотя бы не несколько лет работы в удовольствие. Надеюсь мой опыт поможет вам не ошибиться в своем выборе.
Александра Шаламова
#советы
Когда Максим написал свой пост о работе мечты, мы договорились, что я напишу о своем опыте, чтобы дать вам больше примеров, почему нужно пытаться работать там, где хочется. Но чем больше я об этом думаю, тем больше понимаю, что буду только повторяться. Но, говоря о том какие плюсы вы можете получить, поработав на месте своей мечты, мы не можем не сказать о минусах таких попыток и том, как не обжечься о разочарование (а тут уж мне есть что рассказать).
Опасность первая: повестись на маркетинг
Большие ИТ-компании вкладываются в свой маркетинг среди кандидатов. Вы видите их сотрудников на конференциях и в статьях на Хабре, они выступают спонсорами событий, открывают свои курсы. От этого создается впечатление, что в компании очень дружественная обстановка, вас все готовы учить, они ведь совершенно бесплатно ходят выступать, чтобы делиться своими знаниями, и они действительно много знают. Но будьте осторожны в таких рассуждениях. Внутри всегда может оказать, что выступающего, на пример, лишат премии, если он не сделает очередной доклад, а откапывал он эти бесценные знания рыская по интернету за неделю до выступления. Если у вас есть хорошее впечатление о компании, то не полагайтесь на него полностью. Найдите людей, которые работают, а еще лучше работали в этой компании, пообщайтесь с ними, поспрашивайте коллег, что они слышали об этой компании. Иногда от одного разговора с бывшим сотрудником компании может кардинально поменяться впечатление.
Опасность вторая: ждать слишком многого
Как хорошо
За свою более чем 10-летнюю практику я ни один раз стремилась на место своей мечты и ни один раз в нем разочаровывалась, совершая именно эти две ошибки. Несомненно я все равно получала бесценный опыт и росла технически (правда больше на этапе подготовки) и становилась более уверена в своих силах. Но эти ошибки не давали мне выбрать место, где бы я осталась хотя бы не несколько лет работы в удовольствие. Надеюсь мой опыт поможет вам не ошибиться в своем выборе.
Александра Шаламова
#советы
Скоро будет пост о самых губительных ошибках в проведении ретроспективы спринта. А на нашем YouTube-канале вы уже можете посмотреть видео на эту тему.
https://youtu.be/VhfFLiGKiTU
https://youtu.be/VhfFLiGKiTU
Командные встречи - это трата времени?
Многие люди считают любые встречи синонимом потраченного времени и стараются их всячески избегать. Как человек немало поработавший в компаниях, где встречи это инструмент поиска виноватых, поиска возможности спихнуть с себя работу или просто попытка показать свою важность и занятость, я в целом понимаю такое отношение и опасения.
Нужны ли команде встречи
Однако, для командных встреч и взаимодействий такое отношение не имеет право на существование. Начнем с того, что команда это группа людей, работающая вместе для достижения единых целей. Чтобы достигать цели, вы должны уметь эффективно работать вместе, четко согласовывать свои действия, знать кто и чем занимается, а также иметь возможность вовремя помочь товарищу по команде или попросить помощь. Все это невозможно без выстроенных и четких коммуникаций.
Кейс, когда командные встречи действительно не нужны
Если случилось так, что вы команда людей, делающих свои задачи в полной изоляции, не думающих и не знающих о других, то вы не команда, вы просто набор специалистов, делающих свои задачи. Это не хорошо и не плохо, при умении управлять таким подходом. Просто тогда у вас нет команды и нет потребности в командных взаимодействиях.
Почему курилка не может заменить встречи
Подходы типа да мы все обсудим за обедом, в курилке и т.д., мало конструктивны. Не все и не всегда соберутся в одном месте, не всегда разговор будет вестись о работе (у нас чаще всего как раз разговоры не о работе в таких местах), не все услышат и не все запомнят. В итоге будет разброд и шатание.
Почему менеджер не может заменить встречи
Конечно можно дойти до того, что в задаче вы, как менеджер, опишите каждую запятую, которую будет нужно сделать вашим сотрудникам, но лично я всегда избегал построения таких пассивных и низкоквалифицированных команд. Плюс конечно вы будете узким местом в такой схеме и при росте числа задач или горящих сроках все развалится. О том, что и зачем кто должен следить я уже много писал, не буду повторяться.
Что я советую делать
По факту, если вы команда, то вы должны уметь и хотеть эффективно взаимодействовать и коммуницировать внутри. Проблемы с коммуникацией это не повод от них отказываться, а повод их налаживать. Если вас что-то смущает или не устраивает, обсуждайте это с командой и приходите к компромиссам, только так вы станете сильны как команда.
Максим Шаламов
#советы
Многие люди считают любые встречи синонимом потраченного времени и стараются их всячески избегать. Как человек немало поработавший в компаниях, где встречи это инструмент поиска виноватых, поиска возможности спихнуть с себя работу или просто попытка показать свою важность и занятость, я в целом понимаю такое отношение и опасения.
Нужны ли команде встречи
Однако, для командных встреч и взаимодействий такое отношение не имеет право на существование. Начнем с того, что команда это группа людей, работающая вместе для достижения единых целей. Чтобы достигать цели, вы должны уметь эффективно работать вместе, четко согласовывать свои действия, знать кто и чем занимается, а также иметь возможность вовремя помочь товарищу по команде или попросить помощь. Все это невозможно без выстроенных и четких коммуникаций.
Кейс, когда командные встречи действительно не нужны
Если случилось так, что вы команда людей, делающих свои задачи в полной изоляции, не думающих и не знающих о других, то вы не команда, вы просто набор специалистов, делающих свои задачи. Это не хорошо и не плохо, при умении управлять таким подходом. Просто тогда у вас нет команды и нет потребности в командных взаимодействиях.
Почему курилка не может заменить встречи
Подходы типа да мы все обсудим за обедом, в курилке и т.д., мало конструктивны. Не все и не всегда соберутся в одном месте, не всегда разговор будет вестись о работе (у нас чаще всего как раз разговоры не о работе в таких местах), не все услышат и не все запомнят. В итоге будет разброд и шатание.
Почему менеджер не может заменить встречи
Конечно можно дойти до того, что в задаче вы, как менеджер, опишите каждую запятую, которую будет нужно сделать вашим сотрудникам, но лично я всегда избегал построения таких пассивных и низкоквалифицированных команд. Плюс конечно вы будете узким местом в такой схеме и при росте числа задач или горящих сроках все развалится. О том, что и зачем кто должен следить я уже много писал, не буду повторяться.
Что я советую делать
По факту, если вы команда, то вы должны уметь и хотеть эффективно взаимодействовать и коммуницировать внутри. Проблемы с коммуникацией это не повод от них отказываться, а повод их налаживать. Если вас что-то смущает или не устраивает, обсуждайте это с командой и приходите к компромиссам, только так вы станете сильны как команда.
Максим Шаламов
#советы
5 ошибок, делающих ваше ретро бесполезным
Ретроспектива - это одна из самых важных церемоний Agile, она помогает команде улучшать свои процессы и повышать эффективность от спринта к спринту. Но бывает так, что ретро есть, а улучшений нет. Давайте рассмотрим ошибки, которые могут быть этому причиной.
Ретро проводится нерегулярно
В погоне за сроками и бизнес целями команды часто жертвуют своими процессами, чтобы успеть свои основные задачи. И это само по себе уже очень большая ошибка. Именно процессы помогают не тратить время на лишнюю работу и успевать задачи в срок. Что касается ретро, то, во-первых, оно поможет выявить проблемы и исправить их в следующем спринте, что даст прирост производительности команды (мы ведь спешим правда?). Во-вторых, если не провести ретро сразу, то проблемы забудутся и их решение отложится до следующего инцидента (если после него снова не будет пропущено ретро). В-третьих, некоторые проблемы, не будучи отловленными у самых истоков, могут стрельнуть в будущем намного сильнее и иногда их уже очень сложно исправить.
На ретро не назначается ответственный за проблему
Итак, вы собрались на ретро, накидали проблем, сказали, что надо что-то с этим делать и пошли дальше работать. И проблемы пошли работать вместе с вами. Я наблюдала, как месяц за месяцем команды писали на ретро одни и те же проблемы, сокрушались над ними и через две недели процедура повторялась. Чтобы этого не происходило в вашей команде, для каждой проблемы должен быть назначен ответственный за ее решение, ему должны быть поставлены соответствующие задачи и выделено время на решение этой проблемы. Дальше задачи на решение проблем проходят обычный цикл, как и любые задачи на разработку. Лучше всего вести список для каждого ретро, где будет указано какая проблема обсуждалась и кто назначен ответственным. Так всегда можно будет просмотреть историю ретро и оценить их эффективность. Заведите правило: начинать ретро с проверки списка прошлой встречи.
На ретро приглашаются лишние люди
Многим людям тяжело говорить о проблемах. Поэтому, собирая состав ретро, важно помнить, что на встрече должны быть только люди из команды, которые могут свободно (насколько это возможно) общаться и обсуждать свои проблемы. На этих встречах не должно быть представителей бизнеса, какими бы друзьями вы с ними не были, и, в особенности, не должно быть незнакомых команде людей. Даже если вы с ребятами из соседнего отдела работали вместе в этом спринте, не надо звать их на ретро свой команды. Особенно хорошо нужно помнить об этом тимлидам, которые много общаются с представителями других команд и чувствуют себя с ними более свободно, думайте прежде всего о комфорте вашей команды, иначе рискуете получить ретро для галочки.
На ретро начинают искать решение проблемы
Еще один момент, о котором я как-то говорила в статье про правила проведения стендапа, на ретро не должно искаться полное решение проблемы, иначе встреча превратится в балаган. Во-первых, некоторые проблемы невозможно решить за 5 минут, начиная обсуждать решение проблемы, вы можете увязнуть надолго и за все ретро успеть обсудить только один вопрос (и то ни к чему не прийти). Во-вторых, помните, что в многофункциональных командах на ретро могут быть люди, которых не касается конкретная проблема, от обсуждения чужих проблем ваши коллеги только утомятся и потеряют интерес ко встрече. Проблема фиксируется, для нее выделяется ответственный и команда движется дальше.
У ретро нет ведущего
Здесь я скажу коротко - у совершенно любой встречи должен быть ведущий. И ретро здесь не исключение. Кто-то должен следить за правилами проведения ретро, фиксировать проблемы, следить за дисциплиной, помогать выбирать ответственного для проблемы. Конечно в идеале это скрам-мастер, но он есть не во всех командах. Тем не менее ведущий должен быть, иначе встреча будет не эффективной.
Надеюсь вам поможет разбор этих ошибок сделать вашу ретроспективу более эффективной. Если вам интересно больше узнать о церемониях Agile, то ставьте пальцы вверх этому посту и я напишу следующий.
Александра Шаламова
#agile_который_работает
Ретроспектива - это одна из самых важных церемоний Agile, она помогает команде улучшать свои процессы и повышать эффективность от спринта к спринту. Но бывает так, что ретро есть, а улучшений нет. Давайте рассмотрим ошибки, которые могут быть этому причиной.
Ретро проводится нерегулярно
В погоне за сроками и бизнес целями команды часто жертвуют своими процессами, чтобы успеть свои основные задачи. И это само по себе уже очень большая ошибка. Именно процессы помогают не тратить время на лишнюю работу и успевать задачи в срок. Что касается ретро, то, во-первых, оно поможет выявить проблемы и исправить их в следующем спринте, что даст прирост производительности команды (мы ведь спешим правда?). Во-вторых, если не провести ретро сразу, то проблемы забудутся и их решение отложится до следующего инцидента (если после него снова не будет пропущено ретро). В-третьих, некоторые проблемы, не будучи отловленными у самых истоков, могут стрельнуть в будущем намного сильнее и иногда их уже очень сложно исправить.
На ретро не назначается ответственный за проблему
Итак, вы собрались на ретро, накидали проблем, сказали, что надо что-то с этим делать и пошли дальше работать. И проблемы пошли работать вместе с вами. Я наблюдала, как месяц за месяцем команды писали на ретро одни и те же проблемы, сокрушались над ними и через две недели процедура повторялась. Чтобы этого не происходило в вашей команде, для каждой проблемы должен быть назначен ответственный за ее решение, ему должны быть поставлены соответствующие задачи и выделено время на решение этой проблемы. Дальше задачи на решение проблем проходят обычный цикл, как и любые задачи на разработку. Лучше всего вести список для каждого ретро, где будет указано какая проблема обсуждалась и кто назначен ответственным. Так всегда можно будет просмотреть историю ретро и оценить их эффективность. Заведите правило: начинать ретро с проверки списка прошлой встречи.
На ретро приглашаются лишние люди
Многим людям тяжело говорить о проблемах. Поэтому, собирая состав ретро, важно помнить, что на встрече должны быть только люди из команды, которые могут свободно (насколько это возможно) общаться и обсуждать свои проблемы. На этих встречах не должно быть представителей бизнеса, какими бы друзьями вы с ними не были, и, в особенности, не должно быть незнакомых команде людей. Даже если вы с ребятами из соседнего отдела работали вместе в этом спринте, не надо звать их на ретро свой команды. Особенно хорошо нужно помнить об этом тимлидам, которые много общаются с представителями других команд и чувствуют себя с ними более свободно, думайте прежде всего о комфорте вашей команды, иначе рискуете получить ретро для галочки.
На ретро начинают искать решение проблемы
Еще один момент, о котором я как-то говорила в статье про правила проведения стендапа, на ретро не должно искаться полное решение проблемы, иначе встреча превратится в балаган. Во-первых, некоторые проблемы невозможно решить за 5 минут, начиная обсуждать решение проблемы, вы можете увязнуть надолго и за все ретро успеть обсудить только один вопрос (и то ни к чему не прийти). Во-вторых, помните, что в многофункциональных командах на ретро могут быть люди, которых не касается конкретная проблема, от обсуждения чужих проблем ваши коллеги только утомятся и потеряют интерес ко встрече. Проблема фиксируется, для нее выделяется ответственный и команда движется дальше.
У ретро нет ведущего
Здесь я скажу коротко - у совершенно любой встречи должен быть ведущий. И ретро здесь не исключение. Кто-то должен следить за правилами проведения ретро, фиксировать проблемы, следить за дисциплиной, помогать выбирать ответственного для проблемы. Конечно в идеале это скрам-мастер, но он есть не во всех командах. Тем не менее ведущий должен быть, иначе встреча будет не эффективной.
Надеюсь вам поможет разбор этих ошибок сделать вашу ретроспективу более эффективной. Если вам интересно больше узнать о церемониях Agile, то ставьте пальцы вверх этому посту и я напишу следующий.
Александра Шаламова
#agile_который_работает
Правильный выбор инструментов для проекта и как делать нельзя.
Сегодня я бы хотел поговорить о выборе инструментов для решения задач и вытекающих из этого проблем.
Как скука разработчиков убивает проекты
Я поработал уже над множеством проектов и главное над множеством проектов, в старте которых я не участвовал. Оставив за рамками многие первопричины их проблем, посмотрим на те, что в руках у инженеров, а именно - инструментарий. Я уже перестал удивляться видеть самописные фреймворки, большие распределенные системы на простых приложениях, новомодные базы или библиотеки. В итоге, все это либо не решает задачу, либо решает ее плохо. В основном виной этому бывает банальная скука и желание развеяться через изучение нового инструмента, который конечно же повысит и рыночную стоимость специалиста. Ведь не секрет, что работа состоит на 80% из рутины и желание встряхнуться совершенно понятно. Не понятна всегда неготовность к последствиям такого выбора.
Оцениваем свои силы правильно
Второй же причиной таких смелых экспериментов может быть излишняя уверенность в себе. Конечно, разве вы не напишите свой фреймворк? Да что может быть проще. Ну разве что простой анализ репозиториев открытых проектов покажет вам число контрибьюторов и сроки разработки, что возможно немного поможет более здраво оценить свои силы.
Выбираем инструменты правильно
Дак как же выбирать инструменты для решения задач?
- Вы и ваша команда должны в них разбираться, иначе любой инструмент принесет проблемы, а не решения. Например, многие любят сейчас тащить mongodb в проекты (и она правда хороша), но если вы будете использовать ее как реляционную базу, то получите малоприятный результат.
- Инструмент должен хорошо решать именно поставленную задачу, а не задачу развлечения себя и других. Написание своего фреймворка, конечно, будет очень познавательным процессом, пока он не начнет рассыпаться под наплывом правок и доработок, а также необходимостью в поддержке версионированиях и починки багов.
- Инструмент должен быть зрелым и развитым. То есть о его применениях можно найти упоминания, основные ошибки должны быть найдены и вычищены. В свое время, когда мы переходили на асинхронный подход с командой, вышел вреймворк Sanic (https://sanic.dev/en/). Он был нереально быстр, но разваливался на части сценариев. В итоге, мы выждали год, прежде чем начали его использовать.
- Хороший принцип при выборе: хорошо проверенный, надежный и поддерживаемый инструмент, лучше нового, стильного, молодёжного, но не обкатанного.
А как внедрить новое?
Может возникнуть ощущение, что так ты никогда ничего нового не добавишь в свой стек. Это не так. Просто все нужно делать правильно. Я вижу два варианта:
- обкатываем на каком-то внутреннем или вообще учебном проекте. После чего, через небольшие или не сильно критичные куски/проекты добавляем себе в копилку новый инструмент.
- имеем план Б на экстренный переход к проверенному инструменту и готовность всех участников эксперимента к такому исходу (потому что при любых раскладах тут возникают переработки).
В целом, в разработке софта, есть много общих от места к месту проблем, но часть из них мы создаем себе сами, причем совершенно неоправданно. Ведь выбор плохого инструмента это не только плохо решенная задача, но и чудовищная головная боль при поддержке и развитии проекта.
Максим Шаламов
#советы #разработчику
Сегодня я бы хотел поговорить о выборе инструментов для решения задач и вытекающих из этого проблем.
Как скука разработчиков убивает проекты
Я поработал уже над множеством проектов и главное над множеством проектов, в старте которых я не участвовал. Оставив за рамками многие первопричины их проблем, посмотрим на те, что в руках у инженеров, а именно - инструментарий. Я уже перестал удивляться видеть самописные фреймворки, большие распределенные системы на простых приложениях, новомодные базы или библиотеки. В итоге, все это либо не решает задачу, либо решает ее плохо. В основном виной этому бывает банальная скука и желание развеяться через изучение нового инструмента, который конечно же повысит и рыночную стоимость специалиста. Ведь не секрет, что работа состоит на 80% из рутины и желание встряхнуться совершенно понятно. Не понятна всегда неготовность к последствиям такого выбора.
Оцениваем свои силы правильно
Второй же причиной таких смелых экспериментов может быть излишняя уверенность в себе. Конечно, разве вы не напишите свой фреймворк? Да что может быть проще. Ну разве что простой анализ репозиториев открытых проектов покажет вам число контрибьюторов и сроки разработки, что возможно немного поможет более здраво оценить свои силы.
Выбираем инструменты правильно
Дак как же выбирать инструменты для решения задач?
- Вы и ваша команда должны в них разбираться, иначе любой инструмент принесет проблемы, а не решения. Например, многие любят сейчас тащить mongodb в проекты (и она правда хороша), но если вы будете использовать ее как реляционную базу, то получите малоприятный результат.
- Инструмент должен хорошо решать именно поставленную задачу, а не задачу развлечения себя и других. Написание своего фреймворка, конечно, будет очень познавательным процессом, пока он не начнет рассыпаться под наплывом правок и доработок, а также необходимостью в поддержке версионированиях и починки багов.
- Инструмент должен быть зрелым и развитым. То есть о его применениях можно найти упоминания, основные ошибки должны быть найдены и вычищены. В свое время, когда мы переходили на асинхронный подход с командой, вышел вреймворк Sanic (https://sanic.dev/en/). Он был нереально быстр, но разваливался на части сценариев. В итоге, мы выждали год, прежде чем начали его использовать.
- Хороший принцип при выборе: хорошо проверенный, надежный и поддерживаемый инструмент, лучше нового, стильного, молодёжного, но не обкатанного.
А как внедрить новое?
Может возникнуть ощущение, что так ты никогда ничего нового не добавишь в свой стек. Это не так. Просто все нужно делать правильно. Я вижу два варианта:
- обкатываем на каком-то внутреннем или вообще учебном проекте. После чего, через небольшие или не сильно критичные куски/проекты добавляем себе в копилку новый инструмент.
- имеем план Б на экстренный переход к проверенному инструменту и готовность всех участников эксперимента к такому исходу (потому что при любых раскладах тут возникают переработки).
В целом, в разработке софта, есть много общих от места к месту проблем, но часть из них мы создаем себе сами, причем совершенно неоправданно. Ведь выбор плохого инструмента это не только плохо решенная задача, но и чудовищная головная боль при поддержке и развитии проекта.
Максим Шаламов
#советы #разработчику
Работа с целями
Все знают о том, что нужно ставить цели, многие даже пытаются это делать, но почти никто не понимает, как делать это правильно. В рабочих процессах есть большое разнообразие целей: бизнес-цели, долгосрочные цели, краткосрочные цели, цели на квартал, на спринт и так далее и тому подобное. Каждая тема достаточна отдельной статьи. Но для начала давайте поговорим в общем о работе с целям, что они из себя представляют и зачем вообще нужны.
Что такое цель?
Цель - заранее установленный ориентир, которого вы намерены достичь за определенный промежуток времени, представление о результате, к которому вы должны прийти в результате своей работы.
Зачем нужны цели?
Во-первых, без заранее поставленной цели, вы не сможете понять, когда вы пришли к нужному результату и на сколько успешно вы это сделали. Чтобы оценить результаты любой работы, необходимо заранее знать, каким должен был быть идеальный результат. Во-вторых, наличие цели помогает правильно распределять ресурсы. Особенно это критично в нестандартных ситуация. Представьте, что в команде неожиданно заболел разработчик и ресурсов на закрытие спринта стало не хватать. Именно цель поможет вам понять, какими задачами можно пожертвовать, чтобы закрыть спринт удачно. В-третьих, цель помогает не сходить с курса. Все нововведения должны проходить проверку на соответствие цели, так легко определяется их необходимость и критичность. Такой подход очень помогает экономить ресурсы и делать правильный продукт.
Хорошие и плохие цели
Цель должна быть четко выражена и снабжена соответствующими метриками для определения ее выполнения. Частая проблема это именно постановка размытых целей без метрик. Выполнение таких целей невозможно четко определить и оценить успешность этого выполнения. Давайте разберем пример. Представим, что владелец продукта ставить команде на квартал цель “улучшить отзывчивость сайта”. По такой постановке совершенно не понятно что на практике нужно делать и как определить, что цель достигнута. Можно убрать тяжелую картинку с главной и сайт начнет на 10 мс открываться быстрее, это выполнит цель? А что будет считаться выполнением? Это пример плохой постановки цели.
Теперь давайте посмотрим как ее можно сделать хорошей. Для начала нужна более четкая постановка. Например: “сайт должен не менее, чем на 95% проходить проверку PageSpeed Insights для десктопной и мобильной версии.” Уже лучше, понятно к чему мы должно придти. Далее мы уже можем расписать конкретные метрики, такие как: загрузка сайта в среднем должна укладываться в 200 мс, размер загружаемых файлов не должен превышать 100кб и так далее. Так мы получаем уже конкретные метрики, по которым мы четко можем понять, как хорошо мы справились с задачей. Метрики наиболее полезны при неполном достижении цели. На пример, мы не смогли достичь 95% на мобилке, но мы можем оценить насколько мы продвинулись по метрикам: мы смогли достичь 200 мс на загрузке, но размеры файлов достигли лишь на 80%. Так сразу видно где мы находимся на пути достижения цели и на сколько мы к ней близки.
SMART цели
Бывает сложно сформулировать цель и понять насколько она правильно поставлена. Здесь на помощь придет техника постановки целей SMART. Это набор критериев, которым должна соответствовать ваша цель. SMART содержит следующие критерии:
Specific - конкретная
Measurable - измеримая
Attainable - достижимая
Relevant - актуальная
Time-bound - ограниченная во времени
Выводы
Не забывайте ставить цели и делайте это правильно. Это поможет вам приходить к ожидаемым результатам и не свернуть с дороги где-нибудь по пути.
#советы
Все знают о том, что нужно ставить цели, многие даже пытаются это делать, но почти никто не понимает, как делать это правильно. В рабочих процессах есть большое разнообразие целей: бизнес-цели, долгосрочные цели, краткосрочные цели, цели на квартал, на спринт и так далее и тому подобное. Каждая тема достаточна отдельной статьи. Но для начала давайте поговорим в общем о работе с целям, что они из себя представляют и зачем вообще нужны.
Что такое цель?
Цель - заранее установленный ориентир, которого вы намерены достичь за определенный промежуток времени, представление о результате, к которому вы должны прийти в результате своей работы.
Зачем нужны цели?
Во-первых, без заранее поставленной цели, вы не сможете понять, когда вы пришли к нужному результату и на сколько успешно вы это сделали. Чтобы оценить результаты любой работы, необходимо заранее знать, каким должен был быть идеальный результат. Во-вторых, наличие цели помогает правильно распределять ресурсы. Особенно это критично в нестандартных ситуация. Представьте, что в команде неожиданно заболел разработчик и ресурсов на закрытие спринта стало не хватать. Именно цель поможет вам понять, какими задачами можно пожертвовать, чтобы закрыть спринт удачно. В-третьих, цель помогает не сходить с курса. Все нововведения должны проходить проверку на соответствие цели, так легко определяется их необходимость и критичность. Такой подход очень помогает экономить ресурсы и делать правильный продукт.
Хорошие и плохие цели
Цель должна быть четко выражена и снабжена соответствующими метриками для определения ее выполнения. Частая проблема это именно постановка размытых целей без метрик. Выполнение таких целей невозможно четко определить и оценить успешность этого выполнения. Давайте разберем пример. Представим, что владелец продукта ставить команде на квартал цель “улучшить отзывчивость сайта”. По такой постановке совершенно не понятно что на практике нужно делать и как определить, что цель достигнута. Можно убрать тяжелую картинку с главной и сайт начнет на 10 мс открываться быстрее, это выполнит цель? А что будет считаться выполнением? Это пример плохой постановки цели.
Теперь давайте посмотрим как ее можно сделать хорошей. Для начала нужна более четкая постановка. Например: “сайт должен не менее, чем на 95% проходить проверку PageSpeed Insights для десктопной и мобильной версии.” Уже лучше, понятно к чему мы должно придти. Далее мы уже можем расписать конкретные метрики, такие как: загрузка сайта в среднем должна укладываться в 200 мс, размер загружаемых файлов не должен превышать 100кб и так далее. Так мы получаем уже конкретные метрики, по которым мы четко можем понять, как хорошо мы справились с задачей. Метрики наиболее полезны при неполном достижении цели. На пример, мы не смогли достичь 95% на мобилке, но мы можем оценить насколько мы продвинулись по метрикам: мы смогли достичь 200 мс на загрузке, но размеры файлов достигли лишь на 80%. Так сразу видно где мы находимся на пути достижения цели и на сколько мы к ней близки.
SMART цели
Бывает сложно сформулировать цель и понять насколько она правильно поставлена. Здесь на помощь придет техника постановки целей SMART. Это набор критериев, которым должна соответствовать ваша цель. SMART содержит следующие критерии:
Specific - конкретная
Measurable - измеримая
Attainable - достижимая
Relevant - актуальная
Time-bound - ограниченная во времени
Выводы
Не забывайте ставить цели и делайте это правильно. Это поможет вам приходить к ожидаемым результатам и не свернуть с дороги где-нибудь по пути.
#советы