Как правильно принимать решение
Довольно часто в нашей жизни нужно принимать решения. Сегодня мы конечно будем говорить о принятии решений в работе. Есть решения, которые вам нужно принять лично, есть решения, которые нужно принять совместно с другими. Решать нужно и руководителям, и людям, которые отвечают только за себя.
Возможности в принятии решений в зависимости от должности
Будучи исполнителем, в зависимости от компании, вы имеете рамки, в которых выполняете задачи, в них часто бывает достаточный простор для выбора способов решений и выбора инструментов.
Как часть команды, вы можете договариваться о способах решения командных проблем и взаимодействий, выбор инструментария и т.д.
Как руководитель, вы имеете много возможностей для принятия решений, главное находить баланс (об этом отдельно).
Ключевые моменты для правильного принятия решения
Что я считаю критично для принятия решений:
- каждое решение должно быть принято своевременно, то есть нужно ставить конечные сроки принятия решения. Даже если вы будете ставить их сами себе. Слишком поздно принятые решения могут сильно повлиять на сроки и качество проекта. Плюс, многие забывают про неприятный момент в виде того, что, если вы не приняли решение, за вас его примет руководство. Например, если я готов отдать принятие решения на откуп команды или исполнителя, по достижению оговоренного конечного срока принятия решения, если я готовое решение от команды не получаю, то решение выбираю я сам. Также делают многие руководители. Поэтому своевременность и оперативность в этом вопросе имеет большое значение.
- после принятия решения нужно собирать установки метрики/критерии успешности. Это нужно, чтобы понять насколько хорошо мы приняли решение, не обходится ли это нам слишком дорого и не создало ли это больше проблем, чем решило. Эти критерии нужно выбрать в момент выбора и ориентироваться на них в процессе решения.
- после принятия решения, пока не выбрано иное, нужно целенаправленно и четко следовать этому решению. Не нужно метаться и пытаться попробовать что-то еще. Идите к цели, не распыляйтесь.
- в случае, если решение перестает удовлетворять установленным критериям, то нужно взвесить снова все за и против и, либо изменяйте решение, либо скорректируйте метрики и ожидания.
Готовность принимать решения и отвечать за них - одно из важнейших умений руководителя и любого хорошего специалиста. Помимо ответственности, это позволит получить вам больше возможностей. Поэтому не бойтесь принимать решения, а то их примет кто-то другой.
Максим Шаламов
#разработчику #тимлиду
Довольно часто в нашей жизни нужно принимать решения. Сегодня мы конечно будем говорить о принятии решений в работе. Есть решения, которые вам нужно принять лично, есть решения, которые нужно принять совместно с другими. Решать нужно и руководителям, и людям, которые отвечают только за себя.
Возможности в принятии решений в зависимости от должности
Будучи исполнителем, в зависимости от компании, вы имеете рамки, в которых выполняете задачи, в них часто бывает достаточный простор для выбора способов решений и выбора инструментов.
Как часть команды, вы можете договариваться о способах решения командных проблем и взаимодействий, выбор инструментария и т.д.
Как руководитель, вы имеете много возможностей для принятия решений, главное находить баланс (об этом отдельно).
Ключевые моменты для правильного принятия решения
Что я считаю критично для принятия решений:
- каждое решение должно быть принято своевременно, то есть нужно ставить конечные сроки принятия решения. Даже если вы будете ставить их сами себе. Слишком поздно принятые решения могут сильно повлиять на сроки и качество проекта. Плюс, многие забывают про неприятный момент в виде того, что, если вы не приняли решение, за вас его примет руководство. Например, если я готов отдать принятие решения на откуп команды или исполнителя, по достижению оговоренного конечного срока принятия решения, если я готовое решение от команды не получаю, то решение выбираю я сам. Также делают многие руководители. Поэтому своевременность и оперативность в этом вопросе имеет большое значение.
- после принятия решения нужно собирать установки метрики/критерии успешности. Это нужно, чтобы понять насколько хорошо мы приняли решение, не обходится ли это нам слишком дорого и не создало ли это больше проблем, чем решило. Эти критерии нужно выбрать в момент выбора и ориентироваться на них в процессе решения.
- после принятия решения, пока не выбрано иное, нужно целенаправленно и четко следовать этому решению. Не нужно метаться и пытаться попробовать что-то еще. Идите к цели, не распыляйтесь.
- в случае, если решение перестает удовлетворять установленным критериям, то нужно взвесить снова все за и против и, либо изменяйте решение, либо скорректируйте метрики и ожидания.
Готовность принимать решения и отвечать за них - одно из важнейших умений руководителя и любого хорошего специалиста. Помимо ответственности, это позволит получить вам больше возможностей. Поэтому не бойтесь принимать решения, а то их примет кто-то другой.
Максим Шаламов
#разработчику #тимлиду
Как не погрязнуть в ручных правках
Я давно работаю в IT, поработал в разных компаниях и отделах, оброс знакомствами и контактами. Интересно, что я почти в каждом месте встречаю одну и туже проблему.
Давайте немного напряжем воображение. Вы делаете задачу по приему оплаты за услуги на вашем сайте. В какой-то момент оказывается, что части пользователей выдается немного меньше услуг после оплаты. Но не страшно, бизнес, который управляет приоритетами, приходит и говорит: "ребята, нет времени это чинить, давайте в базе проставим руками, как должно быть и не будем тратить время на правки. Сейчас не до этого, а пользователей таких немного". Знакомая история?
К чему это приводит
Похожие истории имеют обыкновение копиться и множиться. Это приводит к ситуациям, когда появляются сломанные пользовательские сценарии и пути, что приводит к постоянным просьбам в стиле “поменяйте руками в базе доступ”, “посмотрите кто сделал последнее изменение в этом объявлении”, “посмотрите, какая у этого пользователя почта” и таких задач становится все больше и большею. В итоге они начинают занимать значимую часть времени команды. Хотя, казалось бы, времени итак не было. Команда при этом оказывается в ловушке собственной мотивации, ведь все знают, что они хотят двигаться вперед и видеть, как их продуктом пользуются. Поэтому многие разработчики идут на встречу и попадают в ситуацию, когда продукт трещит по швам, а половину дня приходится разбираться с пользовательскими обращениями, чтобы руками поправить их проблему. При этом, такие задачи всегда срочные и требуют резкой смены контекста. Многие заводят в итоге дежурных, которых нужно все больше и больше, что мало меняет общую картину. Если пустить ситуацию на самотек, это в итоге сильно навредить проекту и подорвет мотивацию команды, замученную бесконечными рутинными задачами.
Что же делать?
Я предлагаю следующее решение этой проблемы. Помните, что услуги IT-специалистов дороги и занимать их чем-то отвлеченным крайне дорогая и сомнительная затея. Посчитайте процент пользователей, которых затрагивают проблемы и сколько времени займет ручная обработка всех их проблем. А потом посчитайте время на создание простого интерфейса, где бизнес руками сможет разрешить все сложности. Обычно этот аргумент становится решающим. Конечно нужно подкрепить уверенностью в правильности шага и терпением. Правильно было бы просчитать системное решение проблемы т.е. время на закрытие бага или недоработки функционала. На примере покажите, что разово закрыть проблему будет выгоднее и решите ее раз и навсегда, освободив время команды с рутинных ручных разборов этой проблемы.
После пары таких заходов, соберитесь с бизнесом и договоритесь, что вместо ручной работы вы всегда выбираете один из двух вариантов: интерфейс для ручной правки бизнесом или системное решение проблемы.
Максима Шаламов
#тимлиду #разработчику
Я давно работаю в IT, поработал в разных компаниях и отделах, оброс знакомствами и контактами. Интересно, что я почти в каждом месте встречаю одну и туже проблему.
Давайте немного напряжем воображение. Вы делаете задачу по приему оплаты за услуги на вашем сайте. В какой-то момент оказывается, что части пользователей выдается немного меньше услуг после оплаты. Но не страшно, бизнес, который управляет приоритетами, приходит и говорит: "ребята, нет времени это чинить, давайте в базе проставим руками, как должно быть и не будем тратить время на правки. Сейчас не до этого, а пользователей таких немного". Знакомая история?
К чему это приводит
Похожие истории имеют обыкновение копиться и множиться. Это приводит к ситуациям, когда появляются сломанные пользовательские сценарии и пути, что приводит к постоянным просьбам в стиле “поменяйте руками в базе доступ”, “посмотрите кто сделал последнее изменение в этом объявлении”, “посмотрите, какая у этого пользователя почта” и таких задач становится все больше и большею. В итоге они начинают занимать значимую часть времени команды. Хотя, казалось бы, времени итак не было. Команда при этом оказывается в ловушке собственной мотивации, ведь все знают, что они хотят двигаться вперед и видеть, как их продуктом пользуются. Поэтому многие разработчики идут на встречу и попадают в ситуацию, когда продукт трещит по швам, а половину дня приходится разбираться с пользовательскими обращениями, чтобы руками поправить их проблему. При этом, такие задачи всегда срочные и требуют резкой смены контекста. Многие заводят в итоге дежурных, которых нужно все больше и больше, что мало меняет общую картину. Если пустить ситуацию на самотек, это в итоге сильно навредить проекту и подорвет мотивацию команды, замученную бесконечными рутинными задачами.
Что же делать?
Я предлагаю следующее решение этой проблемы. Помните, что услуги IT-специалистов дороги и занимать их чем-то отвлеченным крайне дорогая и сомнительная затея. Посчитайте процент пользователей, которых затрагивают проблемы и сколько времени займет ручная обработка всех их проблем. А потом посчитайте время на создание простого интерфейса, где бизнес руками сможет разрешить все сложности. Обычно этот аргумент становится решающим. Конечно нужно подкрепить уверенностью в правильности шага и терпением. Правильно было бы просчитать системное решение проблемы т.е. время на закрытие бага или недоработки функционала. На примере покажите, что разово закрыть проблему будет выгоднее и решите ее раз и навсегда, освободив время команды с рутинных ручных разборов этой проблемы.
После пары таких заходов, соберитесь с бизнесом и договоритесь, что вместо ручной работы вы всегда выбираете один из двух вариантов: интерфейс для ручной правки бизнесом или системное решение проблемы.
Максима Шаламов
#тимлиду #разработчику
Нужны ли руководителю технические знания?
В своих статьях и курсах мы много говорим о софт-скиллах руководителей. Давайте сегодня посмотрим на вторую составляющую работы - хард скиллы, а вернее о балансе между ними. Несомненно любая руководящая позиция требует знаний и умений далеко выходящих за технические навыки и знания. Но можно ли обойтись совсем без технических знаний? Ответ на этот вопрос сильно зависит от позиции и обязанностей.
Основная концепция
Понятно, что знания у CIO/CTO, под которым 150 человек и руководителем команды, под которым 5 человек, если не должны, то могут сильно отличаться. Чем больше под руководителем людей, отделов, проектов, тем более высокоуровнево он должен уметь смотреть на проблемы. Нужно уметь выбирать технологии, которые в целом устроят компанию (даже в ущерб конкретному отделу), выбирать методологии работы, выстраивать отделы. На таких позициях обычно количество технологий, с которыми работают подчиненные так велико, что знать их все в деталях человеку просто не под силу, да этого и не требуется.
Однако, чем ближе руководитель к решению конкретных прикладных задач, тем выше должна быть его погруженность в эту специфику. Зачем это нужно? Тут есть несколько моментов.
Понимание специфики
Первое, руководитель будет говорить со своими людьми на одном языке, а это очень важно. Он постоянно работает с людьми, принимает решения и чем лучше его понимают, чем выше уверенность людей, что он понимает то, о чем говорит, что ему можно доверять, тем лучше люди будут слушать своего руководителя и охотнее поддерживать его решения. Конечно я не говорю, что вы, будучи руководителем, должны все и лучше всех знать и уметь, конечно нет. Но нужно понимать специфику того, с чем работаешь. Руководитель должен понимать что делают его люди и зачем, чтобы уметь понять их проблемы, чтобы помочь решать их проблемы.
Оценка качества
Второе, руководитель должен уметь контролировать ход работ и принимать работу своих подчиненных. Для верхнеуровневой приемки из разряда "тыкнул кнопку - лампочка загорелась" есть другие люди. Управленец должен уметь понимать развивается ли продукт правильно, должен уметь оценить качество сделанной работы и понять все ли работают как надо и должны, оправданы ли сроки. Даже если в команде есть техлид, вышестоящий руководитель не можете полностью отдать эти знания в его голову и контроль в его руки. Спросят о результатах в итоге все равно с более высокого руководства и оно должно уметь понять, что хорошо, а что плохо. Естественно привлекать людей для ревью и анализа результата тоже необходимо, сторонний взгляд всегда полезен. Главное нужно, по необходимости, смочь понять как идут дела и хорошо ли выполняется работа.
Оценка качества работы подчиненных
Третье, и временами самое неприятное, руководитель должен уметь контролировать не просто ход работ, а понять насколько хорошо или плохо работает конкретный человек. Поскольку от него будет зависеть повысить его зарплату или нет, увольнять человека или нет, то конечно он должны уметь оценивать человека. А поскольку он оценивает технического специалиста, то оценка его технических знаний необходима для комплексного принятия решений о подчиненном.
Заключение
В заключении, подведем итог. Технические руководители должны обладать техническими знаниями и навыками. От позиции к позиции набор знаний и умений варьируется, от максимального погружения в конкретную область, когда вы тимлид/техлид, до высокоуровневого понимания технологий и методологий управления, достаточного для принятия решений о выборе технологий, но не обязательно достаточного, чтобы самому смочь внедрить технологию в любой проект на более высоких позициях.
Максим Шаламов
#тимлиду #разработчику
В своих статьях и курсах мы много говорим о софт-скиллах руководителей. Давайте сегодня посмотрим на вторую составляющую работы - хард скиллы, а вернее о балансе между ними. Несомненно любая руководящая позиция требует знаний и умений далеко выходящих за технические навыки и знания. Но можно ли обойтись совсем без технических знаний? Ответ на этот вопрос сильно зависит от позиции и обязанностей.
Основная концепция
Понятно, что знания у CIO/CTO, под которым 150 человек и руководителем команды, под которым 5 человек, если не должны, то могут сильно отличаться. Чем больше под руководителем людей, отделов, проектов, тем более высокоуровнево он должен уметь смотреть на проблемы. Нужно уметь выбирать технологии, которые в целом устроят компанию (даже в ущерб конкретному отделу), выбирать методологии работы, выстраивать отделы. На таких позициях обычно количество технологий, с которыми работают подчиненные так велико, что знать их все в деталях человеку просто не под силу, да этого и не требуется.
Однако, чем ближе руководитель к решению конкретных прикладных задач, тем выше должна быть его погруженность в эту специфику. Зачем это нужно? Тут есть несколько моментов.
Понимание специфики
Первое, руководитель будет говорить со своими людьми на одном языке, а это очень важно. Он постоянно работает с людьми, принимает решения и чем лучше его понимают, чем выше уверенность людей, что он понимает то, о чем говорит, что ему можно доверять, тем лучше люди будут слушать своего руководителя и охотнее поддерживать его решения. Конечно я не говорю, что вы, будучи руководителем, должны все и лучше всех знать и уметь, конечно нет. Но нужно понимать специфику того, с чем работаешь. Руководитель должен понимать что делают его люди и зачем, чтобы уметь понять их проблемы, чтобы помочь решать их проблемы.
Оценка качества
Второе, руководитель должен уметь контролировать ход работ и принимать работу своих подчиненных. Для верхнеуровневой приемки из разряда "тыкнул кнопку - лампочка загорелась" есть другие люди. Управленец должен уметь понимать развивается ли продукт правильно, должен уметь оценить качество сделанной работы и понять все ли работают как надо и должны, оправданы ли сроки. Даже если в команде есть техлид, вышестоящий руководитель не можете полностью отдать эти знания в его голову и контроль в его руки. Спросят о результатах в итоге все равно с более высокого руководства и оно должно уметь понять, что хорошо, а что плохо. Естественно привлекать людей для ревью и анализа результата тоже необходимо, сторонний взгляд всегда полезен. Главное нужно, по необходимости, смочь понять как идут дела и хорошо ли выполняется работа.
Оценка качества работы подчиненных
Третье, и временами самое неприятное, руководитель должен уметь контролировать не просто ход работ, а понять насколько хорошо или плохо работает конкретный человек. Поскольку от него будет зависеть повысить его зарплату или нет, увольнять человека или нет, то конечно он должны уметь оценивать человека. А поскольку он оценивает технического специалиста, то оценка его технических знаний необходима для комплексного принятия решений о подчиненном.
Заключение
В заключении, подведем итог. Технические руководители должны обладать техническими знаниями и навыками. От позиции к позиции набор знаний и умений варьируется, от максимального погружения в конкретную область, когда вы тимлид/техлид, до высокоуровневого понимания технологий и методологий управления, достаточного для принятия решений о выборе технологий, но не обязательно достаточного, чтобы самому смочь внедрить технологию в любой проект на более высоких позициях.
Максим Шаламов
#тимлиду #разработчику
Сегодня мы подготовили для вас инфографику о принципах набора людей для маленькой компании. Более развернутую информацию можно найти в статье.
#тимлиду #разработчику
#тимлиду #разработчику
Офис или удаленка? Личный опыт.
Сейчас очень много идет споров и обсуждений на тему “офис против удаленки”. Крупные компании пытаются вернуть сотрудников в офис, в то время, как большинству сотрудников хорошо работается удаленно. Расскажу свою историю и к какому выводу я в итоге пришел.
Как я перешел на полную удаленку
Сам я познакомился с полной удаленкой на старте пандемийных проблем. У нас была довольно зрелая команда, и мы, одни из первых, опробовали возможности полной удаленки. Затем, уже перейдя в ТАСС, я собрал полностью удаленную команду. В целом, на удаленке и с удаленной командой я проработал 3 года (за исключением посещения очных совещаний с руководством компании). Я обустроил удобное рабочее место и зарезервировал интернет. Переход на удаленные коммуникации для моей команды прошел довольно безболезненно. Плюсом мы получили возможность усиливаться ребятами со всей страны, а не только с локации нахождения офиса. Вообще, это был довольно хороший опыт, результаты были достигнуты, какого-то дискомфорта от работы дома не наблюдалось. Однако, когда я искал новую работу, удаленку я не стал ставить обязательным условием и вообще скорее склонялся к возвращению в офис.
Дак как так случилось, если эксперимент получился удачным? Начну лично с моих проблем, а потом перейду к общим для команды.
Проблема командного духа
На удаленке у большинства из нас пропало ощущение, что мы команда. И вернуть это так и не получилось. Новые ребята быстро интегрировались в работу, но не было того ощущения сплоченности для решения поставленной задачи. Если раньше мы довольно хорошо чувствовали, кто начинает выдыхаться и ему нужно отдохнуть или дать смену деятельности, то на удаленке с этим случались проблемы. Естественно мы улучшили уровень удаленной коммуникации, но это не могло заменить эффект от частого неформального общения в офисе. Наверное, это показывает, что есть куда расти в этом плане, но по моим наблюдениям и опросам, эта проблема накрыла многих.
Проблема срочных, критичных задач
Следующей сложностью было то, что какие-то срочные и критичные вещи проще решать собравшись вместе в одном месте. Первое время нештатных ситуаций было много и поток созвонов и зумов затягивал. Бесконечные совместные зумы частично решили проблему, но когда экран пошарить надо было двоим или троим все затягивалось. С учетом, что я в основном беру проекты, которые нужно вытаскивать из сложных ситуаций, эта проблема бьет всегда.
Проблемы участников команды
Если говорить в общем, то на удаленке некоторые люди теряют связь с командой, чувствуют себя в изоляции. Часть людей просто не умеет в домашних условиях спланировать свой день и их производительность стремится к нулю.
Что выбираю я
Имея возможность сравнивать, мне ближе офисная история с возможностью гибрида, но я вижу много плюсов от удаленки и для компании и для людей, поэтому у меня к сотрудникам есть простой подход. Адаптация в основном проходит в команде, затем, если человек способен сохранять эффективность на удаленке, то это его право. Конечно, есть ряд работ, которые, по ряду причин, не возможны на удаленке, а у некоторых компаний есть особые требования к удаленке, но это все можно легко узнается на собеседовании.
А какой у вас был опыт удаленной работы? Какие были проблемы, а что понравилось больше, чем в офисе?
Максима Шаламов
#разработчику #тимлиду
Сейчас очень много идет споров и обсуждений на тему “офис против удаленки”. Крупные компании пытаются вернуть сотрудников в офис, в то время, как большинству сотрудников хорошо работается удаленно. Расскажу свою историю и к какому выводу я в итоге пришел.
Как я перешел на полную удаленку
Сам я познакомился с полной удаленкой на старте пандемийных проблем. У нас была довольно зрелая команда, и мы, одни из первых, опробовали возможности полной удаленки. Затем, уже перейдя в ТАСС, я собрал полностью удаленную команду. В целом, на удаленке и с удаленной командой я проработал 3 года (за исключением посещения очных совещаний с руководством компании). Я обустроил удобное рабочее место и зарезервировал интернет. Переход на удаленные коммуникации для моей команды прошел довольно безболезненно. Плюсом мы получили возможность усиливаться ребятами со всей страны, а не только с локации нахождения офиса. Вообще, это был довольно хороший опыт, результаты были достигнуты, какого-то дискомфорта от работы дома не наблюдалось. Однако, когда я искал новую работу, удаленку я не стал ставить обязательным условием и вообще скорее склонялся к возвращению в офис.
Дак как так случилось, если эксперимент получился удачным? Начну лично с моих проблем, а потом перейду к общим для команды.
Проблема командного духа
На удаленке у большинства из нас пропало ощущение, что мы команда. И вернуть это так и не получилось. Новые ребята быстро интегрировались в работу, но не было того ощущения сплоченности для решения поставленной задачи. Если раньше мы довольно хорошо чувствовали, кто начинает выдыхаться и ему нужно отдохнуть или дать смену деятельности, то на удаленке с этим случались проблемы. Естественно мы улучшили уровень удаленной коммуникации, но это не могло заменить эффект от частого неформального общения в офисе. Наверное, это показывает, что есть куда расти в этом плане, но по моим наблюдениям и опросам, эта проблема накрыла многих.
Проблема срочных, критичных задач
Следующей сложностью было то, что какие-то срочные и критичные вещи проще решать собравшись вместе в одном месте. Первое время нештатных ситуаций было много и поток созвонов и зумов затягивал. Бесконечные совместные зумы частично решили проблему, но когда экран пошарить надо было двоим или троим все затягивалось. С учетом, что я в основном беру проекты, которые нужно вытаскивать из сложных ситуаций, эта проблема бьет всегда.
Проблемы участников команды
Если говорить в общем, то на удаленке некоторые люди теряют связь с командой, чувствуют себя в изоляции. Часть людей просто не умеет в домашних условиях спланировать свой день и их производительность стремится к нулю.
Что выбираю я
Имея возможность сравнивать, мне ближе офисная история с возможностью гибрида, но я вижу много плюсов от удаленки и для компании и для людей, поэтому у меня к сотрудникам есть простой подход. Адаптация в основном проходит в команде, затем, если человек способен сохранять эффективность на удаленке, то это его право. Конечно, есть ряд работ, которые, по ряду причин, не возможны на удаленке, а у некоторых компаний есть особые требования к удаленке, но это все можно легко узнается на собеседовании.
А какой у вас был опыт удаленной работы? Какие были проблемы, а что понравилось больше, чем в офисе?
Максима Шаламов
#разработчику #тимлиду
Плюсы и минусы продолжительной работы на одном месте
Плюсы:
- вы получаете возможность расти в глубину. Конечно это здорово попробовать много всего и разного, но не менее увлекательно копать в глубь. Например, только осев в компании надолго, я смог на практике разобраться в тонкостях работы с проектами под разными типами нагрузки, хорошо разобрался в том, как работает postgres и elasicsearch и т.д. Этот опыт для меня оказался ценнее, чем поверхностные изучения кучи разных технологий.
- можете получить опыт в становлении и работе реально сильной и сплоченной команды. Конечно все мы работаем в коллективе. Но, когда часто меняешь работу, не сильно вкладываешься в команду, не всегда даже успеваешь пройти тот этап, когда набор людей реально станет командой. Работа в реально сильной и сплоченной команде - это опыт, который я бы не променял на несколько переходов с повышением. Наша команда формировалась примерно 2 года, после чего костяк не менялся в течении трех лет.
- ощущение сопричастности к результату совершенно другое. Если вы долго работаете над проектом и он становится успешным, то чувство вашей причастности и вклада в результат значительно выше, чем если бы вы поучаствовали в этом год.
- со временем вам становится все проще работать в компании. Вы всех знаете, вас все знают, вы знаете, как и что работает. Соответственно вы тратите минимум времени на условности и рутину (по крайней мере не больше, чем необходимо). Вы становитесь центром знаний и компетенций, к вам ходят за советом и помощью.
Из сложностей можно выделить необходимость в выстраивании долгосрочных отношений в компании, вход в зону комфорта, из которой сложно выйти, также вы можете застрять в неактуальном стеке (если работаете с устаревшими технологиями, которые не собираются менять).
Как и всегда, каждый сам выбирает свой путь. Нет однозначно выигрышной или проигрышной позиции, нужно уметь выжимать максимум из каждой и не упускать свои возможности.
Максим Шаламов
#советы #разработчику #тимлиду
Плюсы:
- вы получаете возможность расти в глубину. Конечно это здорово попробовать много всего и разного, но не менее увлекательно копать в глубь. Например, только осев в компании надолго, я смог на практике разобраться в тонкостях работы с проектами под разными типами нагрузки, хорошо разобрался в том, как работает postgres и elasicsearch и т.д. Этот опыт для меня оказался ценнее, чем поверхностные изучения кучи разных технологий.
- можете получить опыт в становлении и работе реально сильной и сплоченной команды. Конечно все мы работаем в коллективе. Но, когда часто меняешь работу, не сильно вкладываешься в команду, не всегда даже успеваешь пройти тот этап, когда набор людей реально станет командой. Работа в реально сильной и сплоченной команде - это опыт, который я бы не променял на несколько переходов с повышением. Наша команда формировалась примерно 2 года, после чего костяк не менялся в течении трех лет.
- ощущение сопричастности к результату совершенно другое. Если вы долго работаете над проектом и он становится успешным, то чувство вашей причастности и вклада в результат значительно выше, чем если бы вы поучаствовали в этом год.
- со временем вам становится все проще работать в компании. Вы всех знаете, вас все знают, вы знаете, как и что работает. Соответственно вы тратите минимум времени на условности и рутину (по крайней мере не больше, чем необходимо). Вы становитесь центром знаний и компетенций, к вам ходят за советом и помощью.
Из сложностей можно выделить необходимость в выстраивании долгосрочных отношений в компании, вход в зону комфорта, из которой сложно выйти, также вы можете застрять в неактуальном стеке (если работаете с устаревшими технологиями, которые не собираются менять).
Как и всегда, каждый сам выбирает свой путь. Нет однозначно выигрышной или проигрышной позиции, нужно уметь выжимать максимум из каждой и не упускать свои возможности.
Максим Шаламов
#советы #разработчику #тимлиду
О чем еще нужно помнить
Нужно помнить, что наша задача, как руководителей, организовать успех в рамках своих полномочий. Это и найм нужных людей, и своевременные релизы и т.д. и т.п. В идеале, вы должны делать работу под ключ на своем уровне (важно что свою и на своем уровне). Если сделать можно, то найти способ преодолеть все преграды, если нет, то вовремя сообщить об этом и предложить варианты решения проблемы.
Обязательно нужно быть готовым к различным спорам, конфликтам, обидам, завистям, эскалациям и прочим видам не самых приятных взаимодействий. Всегда решить все мирно и дружно вряд ли возможно и нужно. В баланс к этому, нужно учиться и искать компромиссы и договариваться, иначе вы утонете в склоках и конфликтах. Здесь нужно искать золотую середину.
В завершении я могу сказать, что работа руководителя не для всех. Многим это просто не нужно, просто есть стереотип, что счастье оно в этом. Занимайтесь тем, что вам действительно нравится, тем более, что в ИТ хорошие деньги получают и не руководители, а в крупных компаниях есть вертикали специалистов, для тех, кто не хочет руководить, но хочет роста.
Максим Шаламов
#тимлиду #разработчику
Нужно помнить, что наша задача, как руководителей, организовать успех в рамках своих полномочий. Это и найм нужных людей, и своевременные релизы и т.д. и т.п. В идеале, вы должны делать работу под ключ на своем уровне (важно что свою и на своем уровне). Если сделать можно, то найти способ преодолеть все преграды, если нет, то вовремя сообщить об этом и предложить варианты решения проблемы.
Обязательно нужно быть готовым к различным спорам, конфликтам, обидам, завистям, эскалациям и прочим видам не самых приятных взаимодействий. Всегда решить все мирно и дружно вряд ли возможно и нужно. В баланс к этому, нужно учиться и искать компромиссы и договариваться, иначе вы утонете в склоках и конфликтах. Здесь нужно искать золотую середину.
В завершении я могу сказать, что работа руководителя не для всех. Многим это просто не нужно, просто есть стереотип, что счастье оно в этом. Занимайтесь тем, что вам действительно нравится, тем более, что в ИТ хорошие деньги получают и не руководители, а в крупных компаниях есть вертикали специалистов, для тех, кто не хочет руководить, но хочет роста.
Максим Шаламов
#тимлиду #разработчику
Командность
Все мы работаем в команде и нужно учиться взаимодействовать с людьми, работать в рамках принятых процессов. Выражать свое несогласие и критику нужно уметь, ровно как и участвовать в изменениях процессов. Я люблю работать с людьми с характером и внутренним стержнем, но если они отталкиваются от вводных, что все хуже их и они делают своим присутствием всем одолжение, то обычно ждать от них эффективной работы не приходится. Умение работать в команде и с людьми приходит с опытом. Обычно тут нужно проявлять терпение (если человек не переходит границ) и помогать человеку. Большинство моих ребят хотели и старались развиваться в этом направлении, но это занимало годы. Были и те, кому это было не надо, мы просто переставали работать вместе.
Субординация
Под этим пунктом я не имел ввиду парадигму “я начальник, ты дурак”. Тут заложен смысл о том, что все внутренние договоренности должны соблюдаться, пока они не были изменены. И ты не ставишь свое мнение выше мнения команды, а работаешь в рамках этой команды. Убедил всех - молодец. Также за начальником остается последнее слово в случаи спорных ситуаций (за моими я естественно тоже оставляю право финального слова). Если говорить о себе, то я не люблю залезать в те решения, которые на мой взгляд должны приниматься не мной. Но, если я вижу критичную проблему или есть неразрешимый спор, то беру это на себя.
Каждый сам ставит приоритеты и идет по ним, я поделился своим видением. Надеюсь вам было полезно.
Максим Шаламов
#тимлиду #разработчику
Все мы работаем в команде и нужно учиться взаимодействовать с людьми, работать в рамках принятых процессов. Выражать свое несогласие и критику нужно уметь, ровно как и участвовать в изменениях процессов. Я люблю работать с людьми с характером и внутренним стержнем, но если они отталкиваются от вводных, что все хуже их и они делают своим присутствием всем одолжение, то обычно ждать от них эффективной работы не приходится. Умение работать в команде и с людьми приходит с опытом. Обычно тут нужно проявлять терпение (если человек не переходит границ) и помогать человеку. Большинство моих ребят хотели и старались развиваться в этом направлении, но это занимало годы. Были и те, кому это было не надо, мы просто переставали работать вместе.
Субординация
Под этим пунктом я не имел ввиду парадигму “я начальник, ты дурак”. Тут заложен смысл о том, что все внутренние договоренности должны соблюдаться, пока они не были изменены. И ты не ставишь свое мнение выше мнения команды, а работаешь в рамках этой команды. Убедил всех - молодец. Также за начальником остается последнее слово в случаи спорных ситуаций (за моими я естественно тоже оставляю право финального слова). Если говорить о себе, то я не люблю залезать в те решения, которые на мой взгляд должны приниматься не мной. Но, если я вижу критичную проблему или есть неразрешимый спор, то беру это на себя.
Каждый сам ставит приоритеты и идет по ним, я поделился своим видением. Надеюсь вам было полезно.
Максим Шаламов
#тимлиду #разработчику
Выгорание у джунов до старта работы - миф или реальность?
У каждого разработчика настает однажды такой момент, когда его все задолбало и хочется на дачу жарить шашлыки или пару недель позалипать в компьютерные игры. Ну вот кто нынче не выгорал? Но оказывается, чтобы выгореть не обязательно даже начинать работать. Пошла такая тенденция, что джуны, иногда даже без опыта работы, уже приходят на собеседование с историями о выгорании. Уже не раз слышала и от обучающихся еще разработке ребят: "что делать, помогите, три месяца учусь программированию, больше не могу...". Честно вам скажу, ребята, первая моя реакция на такое была в стиле "да что ты, сосунок, знаешь о выгорании?!". Но все не так просто. Разберемся с основными причинами, тем более, что они общие для всех.
Во-первых, есть такое понятие, как академическое выгорание - выгорание от учебы (я вот почитала про него и поставила себе диагноз задним числом, может и у вас оно было). Большинство взрослых людей, хоть раз просыпались от кошмаров про экзамены. Какой бы нам не казалась сейчас сложной жизнь, для большинства учеба это огромный стресс. А стресс - это главный друг выгорания. Я тут вам сейчас про методы борьбы со стрессом рассказывать не буду, как-то у нас уже был такой пост.
Второе, это умение организации времени. Согласитесь, что даже опытные ребята не всегда это умеют, а что говорить про тех, кто только начал. Большинство гордиться своим умением сидеть за компом не вставая по 5-8-12 часов. Признаюсь, я сама через такую проблему прошла, к счастью Максим мне помог осознать свою проблему и теперь я сажусь за задачи с будильником, иначе не умею вовремя оторваться и сделать перерыв. Даже если вам кажется, что вы можете 5 часов не вставать и не отдыхать, поверьте, ваш организм не может. Не мучайте его и тоже заведите себе будильник. Заметите как стали меньше уставать и больше и качественнее работать. По циклу работы тут нужно подбирать под себя, но по классике в "методе помидора" цикл длится пол часа: 25 минут работа и 5 перерыв. Но делать цикл больше 90 минут я бы не советовала. И учтите, что чем длиннее шаг цикла, тем дольше нужен перерыв.
Третий момент, который влияет на нас на всех, но для джунов может быть особо шокирующим, это несоответствие работы представлениям о ней. Эта тема изучается не только в ИТ, это уже известный феномен - молодые специалисты, недавно вышедшие на работу впадают в шок от всего, что на них неожиданно сваливается, и не могут справится с такими нагрузками. Один из моментов, когда высок риск смены профессии. К сожалению, образовательные учреждения не дают многих практических навыков и совершенно не знакомят молодых ребят с реальностью будущей работы. Что с этим можно сделать? Было бы здорово начинать работу постепенно, еще во время учебы. Я, на пример, начинала с фриланса (один из самых простых способов для студентов), и работа в небольшой студии после этого мне показалась отдыхом.
Вывод: да, джуны могут выгореть, есть реальные причины, которые к этому приводят. Не всегда это так, но об этом мы поговорим как-нибудь в следующий раз. А если вы подозреваете у себя выгорание, то определить его вам поможет тест Маслач, который вы найдете в этом посте. Там же написано, что делать дальше.
Александра Шаламова
#разработчику #тимлиду
У каждого разработчика настает однажды такой момент, когда его все задолбало и хочется на дачу жарить шашлыки или пару недель позалипать в компьютерные игры. Ну вот кто нынче не выгорал? Но оказывается, чтобы выгореть не обязательно даже начинать работать. Пошла такая тенденция, что джуны, иногда даже без опыта работы, уже приходят на собеседование с историями о выгорании. Уже не раз слышала и от обучающихся еще разработке ребят: "что делать, помогите, три месяца учусь программированию, больше не могу...". Честно вам скажу, ребята, первая моя реакция на такое была в стиле "да что ты, сосунок, знаешь о выгорании?!". Но все не так просто. Разберемся с основными причинами, тем более, что они общие для всех.
Во-первых, есть такое понятие, как академическое выгорание - выгорание от учебы (я вот почитала про него и поставила себе диагноз задним числом, может и у вас оно было). Большинство взрослых людей, хоть раз просыпались от кошмаров про экзамены. Какой бы нам не казалась сейчас сложной жизнь, для большинства учеба это огромный стресс. А стресс - это главный друг выгорания. Я тут вам сейчас про методы борьбы со стрессом рассказывать не буду, как-то у нас уже был такой пост.
Второе, это умение организации времени. Согласитесь, что даже опытные ребята не всегда это умеют, а что говорить про тех, кто только начал. Большинство гордиться своим умением сидеть за компом не вставая по 5-8-12 часов. Признаюсь, я сама через такую проблему прошла, к счастью Максим мне помог осознать свою проблему и теперь я сажусь за задачи с будильником, иначе не умею вовремя оторваться и сделать перерыв. Даже если вам кажется, что вы можете 5 часов не вставать и не отдыхать, поверьте, ваш организм не может. Не мучайте его и тоже заведите себе будильник. Заметите как стали меньше уставать и больше и качественнее работать. По циклу работы тут нужно подбирать под себя, но по классике в "методе помидора" цикл длится пол часа: 25 минут работа и 5 перерыв. Но делать цикл больше 90 минут я бы не советовала. И учтите, что чем длиннее шаг цикла, тем дольше нужен перерыв.
Третий момент, который влияет на нас на всех, но для джунов может быть особо шокирующим, это несоответствие работы представлениям о ней. Эта тема изучается не только в ИТ, это уже известный феномен - молодые специалисты, недавно вышедшие на работу впадают в шок от всего, что на них неожиданно сваливается, и не могут справится с такими нагрузками. Один из моментов, когда высок риск смены профессии. К сожалению, образовательные учреждения не дают многих практических навыков и совершенно не знакомят молодых ребят с реальностью будущей работы. Что с этим можно сделать? Было бы здорово начинать работу постепенно, еще во время учебы. Я, на пример, начинала с фриланса (один из самых простых способов для студентов), и работа в небольшой студии после этого мне показалась отдыхом.
Вывод: да, джуны могут выгореть, есть реальные причины, которые к этому приводят. Не всегда это так, но об этом мы поговорим как-нибудь в следующий раз. А если вы подозреваете у себя выгорание, то определить его вам поможет тест Маслач, который вы найдете в этом посте. Там же написано, что делать дальше.
Александра Шаламова
#разработчику #тимлиду
Многоэтапные собеседования - зачем?
Многоэтапные собеседования бесят большинство собеседующихся и многие правда не понимают зачем это все. Самым интересным оказалось то, что ребята проводящие первый этап часто сильно недовольны, что их мнения недостаточно. Я, как всегда, поделюсь своим мнением и видением этой ситуации.
Почему компании делают несколько собеседований
Для вас, как для собеседующегося, нужно понимать, что, если бы компании впихивали всех в одно собеседование, то просто бы сломали себе процесс найма, а вы бы постоянно сталкивались с переносами собеседований. Свободное время у нанимающих руководителей найти не так просто (у меня бывают недели где с 6 утра до 23 время под собеседования я найти не смогу), а с учетом большого числа отсевов на первом этапе, собирать всех в один тур будет не эффективно для компаний с большим числом открытых вакансий. Я сейчас воспринимаю такую систему без эмоций. Проще в маленьких компаниях, но там и потребность меньше, поэтому решение в один тур не редкость.
Почему руководители проверяют людей после технического собеседования
Что касается расстройства собеседующих, что их мнения недостаточно. Тут все довольно просто, брать кота в мешке никто не хочет. Пусть кандидат удовлетворяет техническим запросам компании, но намного важнее впишется ли он в вашу команду, мотивирован ли он, умеет ли работать в команде и т.д.
Очень часто я прихожу на последний этап и вижу ребят, которые вообще не хотят ничего делать. Мыслят в стиле: платите деньги, а я может выделю время пару задач закрыть. Конечно же дайте мне еще удаленки, конференции, дни к отпуску и т.д. А вот изучить что-то новое, взять ответственность за что-то, стараться и т.д., неее, это сложно. Они уже все узнали, все изучили, им все скучно и не интересно. Кто нанимает много, понимает о каких ребятах я говорю.
Как я делегирую принятия решений о найме подчиненным
Лично я очень просто подхожу к вопросу делегирования принятия решений, я хожу какое-то время с выбранными ребятам на собеседования. В начале собеседования веду я, объясняю, что и зачем я спрашиваю, как принимаю решения, что важно на какую позицию и как правильно задавать вопросы и интерпретировать ответы. Потом я хожу в режиме слушателя, проверяю все ли ребята делают правильно. Затем я перестаю ходить на собеседования, но мы проводим разборы в случае найма неудачных кандидатов, если видна проблема или непонимание, повторяем цикл. Если говорить о своем старте лидом, то в Рамблере мне просто приводили людей, такой был процесс. В Сбере уже таких проблем не было, я сам отбирал себе людей и, с учетом самых высоких требований к кандидатам, за мной другие обычно не перепроверяли.
Выводы
Получилось, что-то больше похожее на обзор, чем на то, из чего можно сделать выводы, но если попробовать, то многоэтапные собеседования (на мой взгляд должно быть не больше трех) это необходимость для компаний. А чтобы на основе только вашего мнения принимали решения о наймах, повышайте свою репутацию и доверие к себе.
Максим Шаламов
#тимлиду #разработчику
Многоэтапные собеседования бесят большинство собеседующихся и многие правда не понимают зачем это все. Самым интересным оказалось то, что ребята проводящие первый этап часто сильно недовольны, что их мнения недостаточно. Я, как всегда, поделюсь своим мнением и видением этой ситуации.
Почему компании делают несколько собеседований
Для вас, как для собеседующегося, нужно понимать, что, если бы компании впихивали всех в одно собеседование, то просто бы сломали себе процесс найма, а вы бы постоянно сталкивались с переносами собеседований. Свободное время у нанимающих руководителей найти не так просто (у меня бывают недели где с 6 утра до 23 время под собеседования я найти не смогу), а с учетом большого числа отсевов на первом этапе, собирать всех в один тур будет не эффективно для компаний с большим числом открытых вакансий. Я сейчас воспринимаю такую систему без эмоций. Проще в маленьких компаниях, но там и потребность меньше, поэтому решение в один тур не редкость.
Почему руководители проверяют людей после технического собеседования
Что касается расстройства собеседующих, что их мнения недостаточно. Тут все довольно просто, брать кота в мешке никто не хочет. Пусть кандидат удовлетворяет техническим запросам компании, но намного важнее впишется ли он в вашу команду, мотивирован ли он, умеет ли работать в команде и т.д.
Очень часто я прихожу на последний этап и вижу ребят, которые вообще не хотят ничего делать. Мыслят в стиле: платите деньги, а я может выделю время пару задач закрыть. Конечно же дайте мне еще удаленки, конференции, дни к отпуску и т.д. А вот изучить что-то новое, взять ответственность за что-то, стараться и т.д., неее, это сложно. Они уже все узнали, все изучили, им все скучно и не интересно. Кто нанимает много, понимает о каких ребятах я говорю.
Как я делегирую принятия решений о найме подчиненным
Лично я очень просто подхожу к вопросу делегирования принятия решений, я хожу какое-то время с выбранными ребятам на собеседования. В начале собеседования веду я, объясняю, что и зачем я спрашиваю, как принимаю решения, что важно на какую позицию и как правильно задавать вопросы и интерпретировать ответы. Потом я хожу в режиме слушателя, проверяю все ли ребята делают правильно. Затем я перестаю ходить на собеседования, но мы проводим разборы в случае найма неудачных кандидатов, если видна проблема или непонимание, повторяем цикл. Если говорить о своем старте лидом, то в Рамблере мне просто приводили людей, такой был процесс. В Сбере уже таких проблем не было, я сам отбирал себе людей и, с учетом самых высоких требований к кандидатам, за мной другие обычно не перепроверяли.
Выводы
Получилось, что-то больше похожее на обзор, чем на то, из чего можно сделать выводы, но если попробовать, то многоэтапные собеседования (на мой взгляд должно быть не больше трех) это необходимость для компаний. А чтобы на основе только вашего мнения принимали решения о наймах, повышайте свою репутацию и доверие к себе.
Максим Шаламов
#тимлиду #разработчику
Должен ли руководитель уметь сам проверить работу каждого?
В очередной раз получил вопрос: “Если ты ничего не делаешь руками, то тебе сложно становится проверять чужую работу, а со временем вообще разучишься это делать. Что делать? А если ты не можешь проверять, то зачем ты тогда нужен? Просто ходить задачи раздавать?”. Нюансы бывают разные, но это волнует многих начинающих лидов, которых я знаю и которых растил. Давайте сегодня без общих рассуждений чисто к моему мнению.
Это вопрос сам по себе не имеет смысла, потому что в нем раскрыто сразу же полное непонимание, чем ты собираешься заниматься, как руководитель, и для чего. В такой постановке вопроса у меня есть предположение, что у руководителя должно быть экспертное знание во всех направлениях и языках, а также DevOps и сопровождении. Сомневаюсь, что эта история про реального человека, поэтому умение все проверить лучше всех - это иллюзия контроля, которая еще и замедляет работу команды. Не надо тешить свое эго тем, что ты везде и всюду умнее, ты формируешь команду и растишь ее, твоя цель, чтобы люди по целевым направлениям знали и умели больше тебя.
Про раздачу задач и вот это все. Ваша задача основная - сделать так, чтобы ваш проект работал хорошо, все выполнялось в срок и предсказуемо. Все остальное крутится вокруг достижения этого и подстраивается под реалии, в которых вы оказались. Если достаточно раздать задачи и все будет готово вовремя и в срок, то и отлично. Но обычно вам нужно все распланировать, проконтролировать итоговый результат (не руками, мы уже выяснили, что всего знать нельзя, но через тестирование и опытную эксплуатацию), организовать работу с багами и т.д. В какой-то момент вам может стать скучно, когда вы все наладите и делегируете, но обычно жизнь подбрасывает кучу изменений и нештатных ситуаций.
В целом, если вы рассматриваете работу лида как что-то лишнее и неинтересное, это история не для вас. А так работы вам хватит с горкой, еще будете искать кому ее делегировать.
Еще статьи по теме задач руководителя, которые уже есть на канале:
Нужны ли руководителю технические знания
Чем занят руководитель
Чем отличается руководитель от разработчика
Задачи тимлида и техлида
Мой путь от разработчика к СТО
Максим Шаламов
#тимлиду #руководителю
В очередной раз получил вопрос: “Если ты ничего не делаешь руками, то тебе сложно становится проверять чужую работу, а со временем вообще разучишься это делать. Что делать? А если ты не можешь проверять, то зачем ты тогда нужен? Просто ходить задачи раздавать?”. Нюансы бывают разные, но это волнует многих начинающих лидов, которых я знаю и которых растил. Давайте сегодня без общих рассуждений чисто к моему мнению.
Это вопрос сам по себе не имеет смысла, потому что в нем раскрыто сразу же полное непонимание, чем ты собираешься заниматься, как руководитель, и для чего. В такой постановке вопроса у меня есть предположение, что у руководителя должно быть экспертное знание во всех направлениях и языках, а также DevOps и сопровождении. Сомневаюсь, что эта история про реального человека, поэтому умение все проверить лучше всех - это иллюзия контроля, которая еще и замедляет работу команды. Не надо тешить свое эго тем, что ты везде и всюду умнее, ты формируешь команду и растишь ее, твоя цель, чтобы люди по целевым направлениям знали и умели больше тебя.
Про раздачу задач и вот это все. Ваша задача основная - сделать так, чтобы ваш проект работал хорошо, все выполнялось в срок и предсказуемо. Все остальное крутится вокруг достижения этого и подстраивается под реалии, в которых вы оказались. Если достаточно раздать задачи и все будет готово вовремя и в срок, то и отлично. Но обычно вам нужно все распланировать, проконтролировать итоговый результат (не руками, мы уже выяснили, что всего знать нельзя, но через тестирование и опытную эксплуатацию), организовать работу с багами и т.д. В какой-то момент вам может стать скучно, когда вы все наладите и делегируете, но обычно жизнь подбрасывает кучу изменений и нештатных ситуаций.
В целом, если вы рассматриваете работу лида как что-то лишнее и неинтересное, это история не для вас. А так работы вам хватит с горкой, еще будете искать кому ее делегировать.
Еще статьи по теме задач руководителя, которые уже есть на канале:
Нужны ли руководителю технические знания
Чем занят руководитель
Чем отличается руководитель от разработчика
Задачи тимлида и техлида
Мой путь от разработчика к СТО
Максим Шаламов
#тимлиду #руководителю
Что делать, если тебя не уважают
Один разработчик поведал мне одну прекрасную историю. Устроился он в новую компанию, где задачи ему приходили от владельца продукта. Получив первую свою задачу, он внимательно на нее посмотрел и понял, что данных для ее решения не хватает. Естественно, единственный человек, который мог решить его проблему был тот самый владелец продукта. Но при первой же попытке задать вопрос, мой знакомый получил жесткий ответ: "Значит так! Тебя взяли сюда работать, а не вопросы задавать. Вот иди и делай". Угадайте, кто остался виноват, что задача сделана не правильно?
Бизнес-команда любит недооценивать разработку. Они придумывают крутые фичи, знают рынок, как свои пять пальцев (обычно нет), ежедневно решают будущее продукта, а все что остается разработчику - просто сделать, что ему сказали. Ну на сколько это сложно? Конечно, история выше из ряда вон, но на бытовом уровне с неуважением со стороны бизнес-команды сталкивался практически каждый разработчик.
Есть много подходов, которые помогут вам изменить ситуацию, но мы сейчас поговорим, о самом основополагающем. Самое важное, что вам нужно, чтобы бизнес начал относится к вам более уважительно, это стать для него решением его проблем, решением, без которого он конечно же не справится. Всего-то надо стать незаменимым, тоже мне задача.
Во-первых, давайте разберем подход, который очень часто встречается среди коллег, и который тоже, как это ни странно работает - рассказывать всем, как много и усиленно ты работал, даже если ты на самом деле почти ничего не делал. Нет ли у вас такого коллеги, который постоянно ходит и рассказывает, как ему тяжело, как он работал все выходные, какую неимоверно сложную задачу ему пришлось затащить, а какие у него мешки под глазами (вот-вот смотри!)? Как ни странно, таким ребятам верят и часто относятся к ним с уважением. Все потому, то они убеждают всех, что они реально тащат неимоверный груз и очевидно всех спасают. Какую бы мелочь они не сделали - все узнают о тех усилиях, которые они приложили! Главное для них, это не попасть под опытного управленца, который знаком с таким типом людей и умеет с ним работать. Тогда им либо правда придется работать, как они рассказывают, либо довольно быстро отправиться искать другое место работы.
На самом деле, показывать бизнесу то, какую пользу вы ему приносите, очень важно для формирования уважения. Но можно это делать и иначе. Для этого надо учиться хорошо презентовать свою работу. Не только делать задачи, но и красиво преподносить их решение. Обязательно хорошо готовиться к общим встречам, особенно демонстрации результатов спринтов и релизов. Показывать, что было сделано, какие проблемы были решены, какие метрики изменились в лучшую сторону и как это положительно повлияет на ваш продукт. В общем, корректно, но во всей красе показывать, как хорошо вы работаете.
Еще один важный момент, в том числе формирующий уважение, это правильное преподнесение проблем и технических задач. Заход в бизнес с идеей потратить пару месяцев на внедрение тестов в проект "потому что надо", точно положительно не скажется на уважении к вам. Бизнес тут дело делает, а вы с какой-то очередной дикой идеей пришли, лишь бы время потратить в свое удовольствие. Важно заходить со стороны понимания важности продукта, заботы о нем и его качестве для пользователя. Если владелец продукта раз за разом будет видеть, как вы приносите идеи, улучшающиеего ваш продукт, это будет вызывать в нем уважение. Вы же свой человек, вы хотите того же, что и он, но делаете это методами, которыми он не владеет. А чтобы он видел, что это реально приносит пользу, опять же нужно учиться правильно преподносить результаты своей работы.
Если хотите получать больше уважения от бизнеса, учитесь применять эти подходы. Больше про методы формирования уважения, представления своей работы и идей перед бизнесом, вы найдете в нашей документации к работе с PO и PM.
Александра Шаламова
#разработчику #тимлиду
Один разработчик поведал мне одну прекрасную историю. Устроился он в новую компанию, где задачи ему приходили от владельца продукта. Получив первую свою задачу, он внимательно на нее посмотрел и понял, что данных для ее решения не хватает. Естественно, единственный человек, который мог решить его проблему был тот самый владелец продукта. Но при первой же попытке задать вопрос, мой знакомый получил жесткий ответ: "Значит так! Тебя взяли сюда работать, а не вопросы задавать. Вот иди и делай". Угадайте, кто остался виноват, что задача сделана не правильно?
Бизнес-команда любит недооценивать разработку. Они придумывают крутые фичи, знают рынок, как свои пять пальцев (обычно нет), ежедневно решают будущее продукта, а все что остается разработчику - просто сделать, что ему сказали. Ну на сколько это сложно? Конечно, история выше из ряда вон, но на бытовом уровне с неуважением со стороны бизнес-команды сталкивался практически каждый разработчик.
Есть много подходов, которые помогут вам изменить ситуацию, но мы сейчас поговорим, о самом основополагающем. Самое важное, что вам нужно, чтобы бизнес начал относится к вам более уважительно, это стать для него решением его проблем, решением, без которого он конечно же не справится. Всего-то надо стать незаменимым, тоже мне задача.
Во-первых, давайте разберем подход, который очень часто встречается среди коллег, и который тоже, как это ни странно работает - рассказывать всем, как много и усиленно ты работал, даже если ты на самом деле почти ничего не делал. Нет ли у вас такого коллеги, который постоянно ходит и рассказывает, как ему тяжело, как он работал все выходные, какую неимоверно сложную задачу ему пришлось затащить, а какие у него мешки под глазами (вот-вот смотри!)? Как ни странно, таким ребятам верят и часто относятся к ним с уважением. Все потому, то они убеждают всех, что они реально тащат неимоверный груз и очевидно всех спасают. Какую бы мелочь они не сделали - все узнают о тех усилиях, которые они приложили! Главное для них, это не попасть под опытного управленца, который знаком с таким типом людей и умеет с ним работать. Тогда им либо правда придется работать, как они рассказывают, либо довольно быстро отправиться искать другое место работы.
На самом деле, показывать бизнесу то, какую пользу вы ему приносите, очень важно для формирования уважения. Но можно это делать и иначе. Для этого надо учиться хорошо презентовать свою работу. Не только делать задачи, но и красиво преподносить их решение. Обязательно хорошо готовиться к общим встречам, особенно демонстрации результатов спринтов и релизов. Показывать, что было сделано, какие проблемы были решены, какие метрики изменились в лучшую сторону и как это положительно повлияет на ваш продукт. В общем, корректно, но во всей красе показывать, как хорошо вы работаете.
Еще один важный момент, в том числе формирующий уважение, это правильное преподнесение проблем и технических задач. Заход в бизнес с идеей потратить пару месяцев на внедрение тестов в проект "потому что надо", точно положительно не скажется на уважении к вам. Бизнес тут дело делает, а вы с какой-то очередной дикой идеей пришли, лишь бы время потратить в свое удовольствие. Важно заходить со стороны понимания важности продукта, заботы о нем и его качестве для пользователя. Если владелец продукта раз за разом будет видеть, как вы приносите идеи, улучшающие
Если хотите получать больше уважения от бизнеса, учитесь применять эти подходы. Больше про методы формирования уважения, представления своей работы и идей перед бизнесом, вы найдете в нашей документации к работе с PO и PM.
Александра Шаламова
#разработчику #тимлиду
Как руководителю заставить подчинённых и коллег себя уважать
Очень частая тема и проблема для начинающих да и вообще всех руководителей это уважение. Нужно чтобы люди уважали, что делать и как быть.
Что такое уважение
Я хочу зайти чисто с практической точки зрения, мне сложно сказать уважают люди меня или кого-то, вопрос в том, делают они то, что вам нужно или нет, контролируете ли вы их действия или нет. Потому что именно это важно на работе, вы можете уважать или даже любить кого-то, но не слушаться его. Будучи руководителем лучше меньше задумываться о том, кто, что и почему думает о вас, всем вы угодить точно не сможете. Поэтому, скорее всего, под уважением вы имеете ввиду восприятие вас, как человека, к которому будут прислушиваться, за кем будут идти, который будет контролировать процесс. Не берусь выставлять себя экспертом, но определенные вещи точно могу подсказать.
Внешность
Внешний вид. Да я знаю, что многих начнет трясти с этого, самовыражение и все такое. Дак вот, есть места, где ваш внешний вид может быть уместен или нет. И важно какое впечатление вы ожидаете произвести. Может вы и имеете право надеть клоунский костюм на работу (дресс кода почти ни у кого нет), но воспринимать серьезно вас будут немногие (если вы уникум харизмы, то вам точно все мои советы не интересны, вы хоть голый вывезете, но много ли таких людей?). Поэтому всегда думайте над тем, где и с кем вы будете взаимодействовать и как ожидается там быть одетым. Если вы хотите одеться как-то по-другому, то не ради самовыражения, а преследуя какие-то цели, например, показать, что отличаетесь или что вы из другой группы (если вы знаете что и зачем делаете, то бога ради). Есть некоторые ребята, которые ходят в очень мятых и заношенных вещах, думайте, что хотите, но они вызывают больше отторжения и вопросов у людей, которых не знают или которые их знают мало. Если вопрос того, как вас воспринимают, вам интересен, то используйте уместную и опрятную одежду.
Подача
Подача себя. На встречах и в общении вы должны быть уверены в себе и последовательны. Высказывайте свое мнение, убеждайте в своей правоте, не бойтесь спорить (но не переходите на грубость и споры ради спора). Если вы не можете высказать и отстоять свое мнение (а для подчиненных и их в большинстве случаев тоже), то доверие и уважение внушать вы не сможете.
Последовательность
Последовательность / своя позиция. Уважение вызывают люди, у которых есть своя понятная позиция, которую они последовательно отстаивают. Если вы все время прыгаете с идеи на идею, с подхода на подход, то будете восприниматься очень поверхностным и мало знающим. Взгляд на работу и то, как правильно ее делать, должны быть именно ваши и из вашего опыта.
Опыт
Опыт и готовность помочь. Очень укрепляют ваши позиции знания, опыт и, главное, готовность ими поделиться с другими. И ничто так не подрывает авторитет, как постоянно всплывающие подтверждения вашей некомпетентности по вашей прямой должности. Людей действительно знающих и готовых помогать мало и люди к таким тянуться.
Вообще не бойтесь запрашивать о себе и своей работе обратную связь, слушайте внимательно людей. Да, многие в лицо всего не выскажут, но скажут достаточно для того, кто хочет услышать. Неплохой способ внимательно посмотреть на себя в зеркало, посмотреть, как вы говорите и представить, что вы со стороны смотрите на такого человека, общее впечатление вы сможете составить. Я прошелся по самым верхам и тому, с чем можно быстро поработать. Книг по лидерству и развитию коммуникабельных навыков довольно много, выбирайте под себя. Если вам чего-то не хватает, но хочется, то вы сможете усилить свои слабые стороны.
Максим Шаламов
#тимлиду #руководителю
Очень частая тема и проблема для начинающих да и вообще всех руководителей это уважение. Нужно чтобы люди уважали, что делать и как быть.
Что такое уважение
Я хочу зайти чисто с практической точки зрения, мне сложно сказать уважают люди меня или кого-то, вопрос в том, делают они то, что вам нужно или нет, контролируете ли вы их действия или нет. Потому что именно это важно на работе, вы можете уважать или даже любить кого-то, но не слушаться его. Будучи руководителем лучше меньше задумываться о том, кто, что и почему думает о вас, всем вы угодить точно не сможете. Поэтому, скорее всего, под уважением вы имеете ввиду восприятие вас, как человека, к которому будут прислушиваться, за кем будут идти, который будет контролировать процесс. Не берусь выставлять себя экспертом, но определенные вещи точно могу подсказать.
Внешность
Внешний вид. Да я знаю, что многих начнет трясти с этого, самовыражение и все такое. Дак вот, есть места, где ваш внешний вид может быть уместен или нет. И важно какое впечатление вы ожидаете произвести. Может вы и имеете право надеть клоунский костюм на работу (дресс кода почти ни у кого нет), но воспринимать серьезно вас будут немногие (если вы уникум харизмы, то вам точно все мои советы не интересны, вы хоть голый вывезете, но много ли таких людей?). Поэтому всегда думайте над тем, где и с кем вы будете взаимодействовать и как ожидается там быть одетым. Если вы хотите одеться как-то по-другому, то не ради самовыражения, а преследуя какие-то цели, например, показать, что отличаетесь или что вы из другой группы (если вы знаете что и зачем делаете, то бога ради). Есть некоторые ребята, которые ходят в очень мятых и заношенных вещах, думайте, что хотите, но они вызывают больше отторжения и вопросов у людей, которых не знают или которые их знают мало. Если вопрос того, как вас воспринимают, вам интересен, то используйте уместную и опрятную одежду.
Подача
Подача себя. На встречах и в общении вы должны быть уверены в себе и последовательны. Высказывайте свое мнение, убеждайте в своей правоте, не бойтесь спорить (но не переходите на грубость и споры ради спора). Если вы не можете высказать и отстоять свое мнение (а для подчиненных и их в большинстве случаев тоже), то доверие и уважение внушать вы не сможете.
Последовательность
Последовательность / своя позиция. Уважение вызывают люди, у которых есть своя понятная позиция, которую они последовательно отстаивают. Если вы все время прыгаете с идеи на идею, с подхода на подход, то будете восприниматься очень поверхностным и мало знающим. Взгляд на работу и то, как правильно ее делать, должны быть именно ваши и из вашего опыта.
Опыт
Опыт и готовность помочь. Очень укрепляют ваши позиции знания, опыт и, главное, готовность ими поделиться с другими. И ничто так не подрывает авторитет, как постоянно всплывающие подтверждения вашей некомпетентности по вашей прямой должности. Людей действительно знающих и готовых помогать мало и люди к таким тянуться.
Вообще не бойтесь запрашивать о себе и своей работе обратную связь, слушайте внимательно людей. Да, многие в лицо всего не выскажут, но скажут достаточно для того, кто хочет услышать. Неплохой способ внимательно посмотреть на себя в зеркало, посмотреть, как вы говорите и представить, что вы со стороны смотрите на такого человека, общее впечатление вы сможете составить. Я прошелся по самым верхам и тому, с чем можно быстро поработать. Книг по лидерству и развитию коммуникабельных навыков довольно много, выбирайте под себя. Если вам чего-то не хватает, но хочется, то вы сможете усилить свои слабые стороны.
Максим Шаламов
#тимлиду #руководителю