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