Что входит в обязанности ведущего разработчика
Вот эта большая статья Джона Олспау называется «Быть ведущим инженером». В первый раз я прочитала её примерно четыре года назад, когда только перешла на нынешнюю работу, и она действительно повлияла на представления об этом направлении моей карьеры.
Перечитав её сейчас, действительно интересной там кажется одна вещь, что эмпатия и помощь команде — важная часть работы сеньора. Что, конечно, является правдой!
Но сейчас я вижу, что большинство или все ведущие инженеры, которых я знаю, берут на себя значительную помощь другим сотрудникам вдобавок к своей личной работе по программированию. Сейчас мне кажется, что я и мои коллеги сталкиваются не столько с проблемой «Что?? Нужно РАЗГОВАРИВАТЬ С ЛЮДЬМИ?? НЕВЕРОЯТНО», сколько с другой проблемой: «Как сбалансировать всю эту руководящую работу со своим индивидуальным вкладом / программированием? Сколько и какой работы я должен делать?». Поэтому вместо того, чтобы говорить о признаках сеньора из статьи Олспау (с которыми я полностью согласна), хочу поговорить о работе, которую мы делаем.
О чём эта статья
«Чем занимается ведущий инженер» — огромная тема, а здесь лишь небольшая статья, так что следует иметь в виду:
Что входит в обязанности
Это вещи, которые я рассматриваю больше как работу ведущего инженера и меньше как работу менеджера (хотя менеджеры определённо делают кое-что из перечисленного, особенно создание новых проектов и связывание проектов с бизнес-приоритетами).
Почти вся эта работа по сути техническая: помочь кому-то справиться со сложным проектом — это явно человеческое взаимодействие, но проблемы, над которыми мы будем работать вместе, как правило, будут техническими! («Может, если упростить дизайн, то мы сможем быстрее справиться!»).
В списке отсутствует пункт «делать оценки/прогнозы». Здесь я ещё не очень хороша, но я думаю, что когда-нибудь стоит потратить на это больше времени.
Список кажется большим. Кажется, что если заниматься всеми этими вещами, то они поглотят все ваши интеллектуальные ресурсы. Думаю, что в целом имеет смысл выделить какую-то часть и решить: «Прямо сейчас я собираюсь сосредоточиться на X, Y и Z, я думаю, что мой мозг взорвётся, если я попытаюсь сделать B и C».
Что не входит в обязанности
Тут немного сложнее. Я не говорю, что такими вещами категорически нельзя заниматься. Большинство ведущих инженеров, которых я знаю, тратят огромное количество времени, думая об этих проблемах, и немного работают в этом направлении.
Но мне кажется, что полезно провести некоторую границу, потому что у некоторых людей высокое чувство ответственности за команду и компанию — и они готовы взяться за всё подряд, в результате чего будут перегружены работой и не смогут вносить технический вклад, который на самом деле является их основным делом. Поэтому установление некоторых границ помогает определить, по каким вопросам есть смысл попросить о помощи, когда ситуация становится неспокойной. Ваши реальные границы зависят от вас / вашей команды. 
Большинство из перечисленного ниже — работа менеджера. Оговорка: менеджеры делают намного больше, чем перечисленное здесь (например, «создают новые проекты»), а в некоторых компаниях некоторое из перечисленного может фактически быть работой ведущего инженера (например, спринт-менеджмент).
Полезно явно задавать границы
Недавно я столкнулась с интересной ситуацией, когда обсуждала с менеджером свои обязанности — и мы поняли, что очень по-разному на них смотрим! Мы прояснили ситуацию, и теперь всё в порядке, но это заставило меня понять, что очень важно договориться об ожиданиях.
Когда я начинала как инженер, работа была довольно простой — я писала код, пыталась придумать проекты, которые имели смысл, и всё было прекрасно. У моего менеджера всегда было чёткое представление о моей работе, ничего слишком сложного. Теперь ситуация изменилась! Поэтому теперь я считаю, что обязана определить работу, которую:
Не соглашайтесь на работу, которую не можете / не хотите делать
Думаю, очень важно отказаться от работы, которую я не могу сделать или которая в долгосрочной перспективе не доставит радости! Кажется заманчивым взять на себя много работы, даже если она вам не очень нравится («О, это хорошо для команды!», «Ну кто-то же должен это сделать!»). Конечно, иногда я беру на себя задачи только потому, что они должны быть выполнены, но думаю, что для здоровья команды на самом деле очень важно, чтобы сотрудники делали то, что им в целом нравится и чем они могут заниматься в долгосрочной перспективе.
Поэтому я возьму небольшие задачи, которые просто нужно сделать, но важно не говорить при этом: «О, конечно, я потрачу большую часть своего времени на то, что у меня плохо получается и что мне не нравится, нет проблем» :). И если «кто-то» должен это сделать, возможно, это просто означает, что нам нужно нанять/обучить кого-то нового, чтобы заполнить пробел.
Что должен знать и делать ведущий разработчик?
Уважаемые хабралюди, наверное многие из вас работают в офисе. Кто-то из вас работает под руководством человека, чью должность можно называть «ведущий разработчик», а кто-то таковым и является.
Пожалуйста, расскажите о вашем понятии, кто для вас человек в должности «ведущий разработчик», какие обязанности он выполняет, что он должен знать, какими качествами он должен обладать?
Может ли он знать в среднем меньше, чем члены его команды разработчиков?
Является ли это скорее административной должностью, где главное способность к управления, а не техническая подкованность?
У меня возникли такие вопросы, потому что всю свою профессиональную жизнь я был скромным самостоятельным фрилансером, теперь меня интересует образ жизни офисов.
Спасибо вам за ваши ответы.
Могу поделиться своим американским опытом, я тимлид, у нас в компании 5 команд. Каждый тимлид, в том числе и я должны:
Работать с менеджерами по проектам (которые формулируют задачи в целом)
Распределять работу внутри команды
Следить за своевременным исполнением работы
Проверять качество кода младших разработчиков
Нести ответственность за свою команду (спрашивать будут именно с тимлида)
Составлять тонны всяких отчетов
Тимлид отчитывается перед менеджером по разработке.
Кстати, у нас в компании тимлиды программируют не меньше остальных, а спрос с тимлида больше.
Тимлид не обязан знать больше чем члены его команды, однако он как правило спец в своей области.
Тимлид во многом администратор. Однако, он и программист. Тимлид принимает решения по поводу
тех или иных подходов к решению поставленных задач. Я бы сказал что тимлид это самая первая
ступень на менеджерском пути.
— Во-первых, он должен уметь аккуратно и вежливо говорить, обязательно, взвешивая каждое слово. Тоже самое в отношении его письменности. Это качество необходимо, как для общения с подчинёнными, так и с начальством и клиентами. Как не смешно, незнание русского языка плохо складывается на бизнесе.
— Во-вторых, он должен уметь организовать работу людей. Это качество личности изначально заложенное у порядка 10% людей, у остальных оно вырабатываться с опытом.
— В-третьих, он должен понимать систему, в которой он работает. Это касается и среды программирования, и области приложения. Например, ведущий программист АБС должен знать не только язык программирования для АБС, но и бухучёт кредитных организаций.
Эти три качества отличают хорошего ведущего программиста от плохого.
То есть я правильно понял? Этот человек должен быть:
— В чем-то дипломатом, чтобы уметь корректно обращаться с членами его команды и уметь улаживать трения.
— В чем-то менеджером, чтобы построить эффективную работу группы.
— И быть непосредственно техническим специалистом в области своей работы.
Спасибо, это хорошая систематизации.
Ведущий, если это не формальность, должен быть существенно лучше как девелопер — лучше и качественнее писать код, разбираться и править код своей команды — на него, как правило сваливают ответственность за управлением кодом в VCS в рамках работы своей команды, фичи или продукта. То есть знания и опыт работы с VCS необходимы.
Также ведущий часто выступает как эксперт в сфере своей компетенции. Пишет/создает дизайн, опеределяет свою часть архитектуры и так далее — смотреть в сторону архитекторов, евангелистов и фоллоувед
Дополнительно ведущий как правило
— определяет/подтверждает сроки и обьемы работ своей команды, участвует в планировании, управлении техническими рисками
— контролирует обьем и качество работы
— занимается рутиной в части управления обьемом работ, качеством, планами — эскалирует, подтверждает, рутит баги, пишет отчеты и так далее — смотреть в сторону работы ПМа, который делегирует часть ответственности на ведущего в рамках порученной его команде части проекта. То есть ведущий — это немного ПМ, совсем немного, но это другое направление нежели кодинг как таковой. По хорошему этому должны учить — курсы как минимум.
Сваливать на ведущего работу линейного менеджера для команды неправильно, но часто ему такое сваливается.
В развитых компаниях ведущий — это единственная позиция в которой совмещаются менеджерские и технические роли. Одни вырастают в дальнейшем в ПМ-ов, другие — в технических экспертов.
Джун, мидл и сеньор: разбираемся, кто есть кто
«Любой дурак может написать код, понятный компьютеру. Хороший программист пишет код, понятный человеку»
Деление специалистов на junior, middle и senior хорошо знакомо разработчикам — так обычно определяют уровень компетенций. Но каких требований ожидать от работодателя, если ему нужен «джун», «мидл» или «сеньор»? Попробуем разобраться.
Возраст и опыт — далеко не главное
Человек, который мало знаком с IT, может подумать, что senior — это разработчик, который много лет отдал своей профессии, middle — программист среднего возраста, а junior — вчерашний школьник, который начинает осваивать программирование.
Нельзя сказать, что это полное заблуждение. Нередко джуны действительно молоды, мидлам около 35 лет, а у сеньоров уже седеют волосы. Но не так уж редко встречаются солидные джентльмены, работающие на позиции middle и даже junior под руководством молодого senior-разработчика. Все зависит от компетенций человека, его личностных качеств и, конечно, возраста старта в профессии.
Так в чём различие?
Есть несколько способов понять, кто есть кто, но самый простой и эффективный — посмотреть исходники. Если код сложной программы без труда могут разобрать другие разработчики, у него понятная архитектура и стройная логика — скорее всего, его писал сеньор. И напротив, если код простого продукта получился причудливым, со сложными абстракциями и странными однострочниками — над ним наверняка работал джун.
Сеньоры заботятся о простоте кода — чтобы его легко освоили коллеги, а поддержка не доставила хлопот. Джунам для этого не хватает опыта — они действуют по принципу «Если работает, то всё отлично». До читаемости и чистоты кода руки не доходят.
Если для сравнения взглянуть на код, написанный сеньором, может даже возникнуть недоумение: «Да как так, сложная ведь программа, а так изящно и просто написана!» Этот навык приходит с опытом и далеко не ко всем.
Разница только в коде?
Нет, на этом различия не заканчиваются. Рассмотрим внимательнее специалистов каждого уровня, а затем сопоставим наблюдения.
Junior
В большинстве случаев джуны реализуют простые задачи: например, части проекта, которые затем объединяются. Они делают кирпичики, из которых можно возвести пригодный для жизни дом. При этом джуны зачастую не представляют себе масштабы здания, в постройку которого они вкладываются.
Хорошим джуном считается тот, который может самостоятельно работать над своими «кубиками» — техническими задачами. При этом важно, чтобы его разработки нормально функционировали, когда их встраивают в приложение или сервис.
Скорее всего, на следующий уровень выйдет джун, который:
Middle
Джун, который набрался опыта, улучшил компетенции и научился чисто выполнять свои задачи, может претендовать на позицию мидла. Буквальный перевод слова middle — «середина», но на самом деле в разработке мидл ближе к сеньору, чем к джуну.
Мидлы осознают масштабы проекта, но тоже разрабатывают только его части, хотя и более крупные. Мидл способен самостоятельно выполнять сложные задачи в рамках проекта, причём не только технические, но и административные. На этом уровне разработчик должен понимать требования бизнеса и уметь реализовывать их на практике.
Важные качества мидлов:
Senior
Эта ступень не каждому доступна — многие разработчики остаются на уровне мидла всю карьеру. Чтобы подняться выше, нужны «тонкие» компетенции, которые позволят решать задачи, которые не под силу больше никому. Нужно знать и уметь больше, чем большинство коллег. Например, не просто писать хороший код, а учитывать в нём инструментарий и специфику компании. Сеньоры могут самостоятельно разработать масштабное приложение или сервис с нуля — потому что понимают архитектуру и знают, что и как должно быть создано.
Сеньору требуется не только навык командной работы, как мидлу, но и управленческий опыт. Значит, нужны и коммуникативные навыки. Сеньор может убедительно донести свою точку зрения до команды и руководства, а после реализовать предложенную идею. Он всегда знает, как задать вопрос (и коллеге, и поисковому сервису), чтобы получить нужный ответ. И ещё синьор — это часто ментор: помогает джунам осознать масштабы проекта, правильно работать и развиваться.
Сеньор должен глубоко понимать устройство библиотек, фреймворков, инструментов разработки. Иначе конечный продукт будет вести себя непредсказуемо.
Такой специалист в команде — это фактор стабильности. Он понимает технические риски и знает, как их снизить. Задача сеньора — сделать так, чтобы в коде совсем не было «костылей», которыми грешат джуниоры и мидлы. Без вмешательства опытного руководителя иногда получаются такие продукты, которые ассоциируются разве что с фантастическим гибридом бегемота с носорогом, у которого есть ещё гены утконоса и лотоса. Работает этот монстр Франкенштейна — и ладно.
В сухом остатке
Мы видим, что разница между тремя категориями специалистов — не в возрасте или стаже. Главные различия состоят в отношении к самому процессу разработки, в его понимании и осознании. Об этом и цитата в эпиграфе статьи: она очень точно характеризует новичков и профессионалов.
В GeekBrains мы готовим и джунов, и специалистов уровня middle. Для первых у нас есть короткие курсы — «профессии», а для вторых — более продолжительные программы на факультетах GeekUniversity. Выбирайте сами, по какому маршруту сократить путь до позиции сеньора
«Любой дурак может написать код, понятный компьютеру. Хороший программист пишет код, понятный человеку»
Деление специалистов на junior, middle и senior хорошо знакомо разработчикам — так обычно определяют уровень компетенций. Но каких требований ожидать от работодателя, если ему нужен «джун», «мидл» или «сеньор»? Попробуем разобраться.
Возраст и опыт — далеко не главное
Человек, который мало знаком с IT, может подумать, что senior — это разработчик, который много лет отдал своей профессии, middle — программист среднего возраста, а junior — вчерашний школьник, который начинает осваивать программирование.
Нельзя сказать, что это полное заблуждение. Нередко джуны действительно молоды, мидлам около 35 лет, а у сеньоров уже седеют волосы. Но не так уж редко встречаются солидные джентльмены, работающие на позиции middle и даже junior под руководством молодого senior-разработчика. Все зависит от компетенций человека, его личностных качеств и, конечно, возраста старта в профессии.
Так в чём различие?
Есть несколько способов понять, кто есть кто, но самый простой и эффективный — посмотреть исходники. Если код сложной программы без труда могут разобрать другие разработчики, у него понятная архитектура и стройная логика — скорее всего, его писал сеньор. И напротив, если код простого продукта получился причудливым, со сложными абстракциями и странными однострочниками — над ним наверняка работал джун.
Сеньоры заботятся о простоте кода — чтобы его легко освоили коллеги, а поддержка не доставила хлопот. Джунам для этого не хватает опыта — они действуют по принципу «Если работает, то всё отлично». До читаемости и чистоты кода руки не доходят.
Если для сравнения взглянуть на код, написанный сеньором, может даже возникнуть недоумение: «Да как так, сложная ведь программа, а так изящно и просто написана!» Этот навык приходит с опытом и далеко не ко всем.
Разница только в коде?
Нет, на этом различия не заканчиваются. Рассмотрим внимательнее специалистов каждого уровня, а затем сопоставим наблюдения.
Junior
В большинстве случаев джуны реализуют простые задачи: например, части проекта, которые затем объединяются. Они делают кирпичики, из которых можно возвести пригодный для жизни дом. При этом джуны зачастую не представляют себе масштабы здания, в постройку которого они вкладываются.
Хорошим джуном считается тот, который может самостоятельно работать над своими «кубиками» — техническими задачами. При этом важно, чтобы его разработки нормально функционировали, когда их встраивают в приложение или сервис.
Скорее всего, на следующий уровень выйдет джун, который:
Middle
Джун, который набрался опыта, улучшил компетенции и научился чисто выполнять свои задачи, может претендовать на позицию мидла. Буквальный перевод слова middle — «середина», но на самом деле в разработке мидл ближе к сеньору, чем к джуну.
Мидлы осознают масштабы проекта, но тоже разрабатывают только его части, хотя и более крупные. Мидл способен самостоятельно выполнять сложные задачи в рамках проекта, причём не только технические, но и административные. На этом уровне разработчик должен понимать требования бизнеса и уметь реализовывать их на практике.
Важные качества мидлов:
Senior
Эта ступень не каждому доступна — многие разработчики остаются на уровне мидла всю карьеру. Чтобы подняться выше, нужны «тонкие» компетенции, которые позволят решать задачи, которые не под силу больше никому. Нужно знать и уметь больше, чем большинство коллег. Например, не просто писать хороший код, а учитывать в нём инструментарий и специфику компании. Сеньоры могут самостоятельно разработать масштабное приложение или сервис с нуля — потому что понимают архитектуру и знают, что и как должно быть создано.
Сеньору требуется не только навык командной работы, как мидлу, но и управленческий опыт. Значит, нужны и коммуникативные навыки. Сеньор может убедительно донести свою точку зрения до команды и руководства, а после реализовать предложенную идею. Он всегда знает, как задать вопрос (и коллеге, и поисковому сервису), чтобы получить нужный ответ. И ещё синьор — это часто ментор: помогает джунам осознать масштабы проекта, правильно работать и развиваться.
Сеньор должен глубоко понимать устройство библиотек, фреймворков, инструментов разработки. Иначе конечный продукт будет вести себя непредсказуемо.
Такой специалист в команде — это фактор стабильности. Он понимает технические риски и знает, как их снизить. Задача сеньора — сделать так, чтобы в коде совсем не было «костылей», которыми грешат джуниоры и мидлы. Без вмешательства опытного руководителя иногда получаются такие продукты, которые ассоциируются разве что с фантастическим гибридом бегемота с носорогом, у которого есть ещё гены утконоса и лотоса. Работает этот монстр Франкенштейна — и ладно.
В сухом остатке
Мы видим, что разница между тремя категориями специалистов — не в возрасте или стаже. Главные различия состоят в отношении к самому процессу разработки, в его понимании и осознании. Об этом и цитата в эпиграфе статьи: она очень точно характеризует новичков и профессионалов.
В GeekBrains мы готовим и джунов, и специалистов уровня middle. Для первых у нас есть короткие курсы — «профессии», а для вторых — более продолжительные программы на факультетах GeekUniversity. Выбирайте сами, по какому маршруту сократить путь до позиции сеньора
Заходят как-то в бар «джун», «мидл» и «сеньор»: чем отличаются уровни программистов
В IT-среде принято маркировать уровень специалиста словами «джуниор», «мидл» и «сеньор». Но как понять, на какой вы ступени, и чем вообще эти уровни отличаются? Разбираемся, что на практике ждут работодатели и можно ли прийти устраиваться на должность джуна, а стать мидлом?
Зачем нужна классификация
Деление айтишников, да и не только, на джунов, мидлов и сеньоров — международная традиция. Поскольку в той или иной степени знать английский язык все равно нужно, у нас в IT-среде не стремятся заменять уже привычные для индустрии маркеры на какие-то свои.
В основе классификации — опыт и навыки. Иногда между делом подразумеваются и софт-скиллы. База — единая для всех, хотя в разных компаниях могут быть отхождения из-за специфики отрасли и устройства команды.
Junior с английского переводится как младший. Этим прилагательным также обозначают студентов младших курсов и начинающих специалистов.
• Год-полтора в профессии или делал только учебные проекты.
• Использует один-два метода для решения задач, остальные не пробовал или не разбирается в них.
• Не ориентируется или слабо понимает, как решать нестандартные задачи.
За джунами требуется контроль и проверка кода. Они не знакомы с деталями и нюансами, с которыми сталкивались опытные коллеги. Но этот этап проходят все специалисты в начале работы в IT-сфере.
Игорь Фонин (тимлид команды frontend-разработки, МегаФон):
Джуны выполняют разные функции в зависимости от направления, в котором работают. Например, в кодовом направлении обязанности будут отличаться от команды к команде. А во фронтэнде плюс-минус одинаковые: маленькие задачи для получения опыта, фикс багов, маленькие компоненты на странице. Если джун с этими задачами справляется, получает более сложные. Ему нужен постоянный надзор старшего — мидла или сеньора, тимлида.
Анна Гуминская (тимлид команды backend-разработки, МегаФон):
Обязанности джуниоров чаще всего ограничены определенным набором задач. Поэтому они не видят картину целиком и работают в основном как исполнители. Чтобы понимать, какое решение лучше принять в той или иной ситуации, нужно набраться опыта. Это главная задача любого джуна, если он хочет дорасти до мидла.
На что обращают внимание рекрутеры при подборе
1. Минимальные курсы или образование по специальности. Логично, что для работы программистом на Python нужно знать этот язык.
2. Знание английского. Требуемый уровень зависит от специфики вакансии. Например, в МегаФоне язык потребуется не только чтобы писать код, но и для коммуникации.
3. Софт-скиллы. Навык аналитической работы желателен почти на всех IT-специальностях. Но ключевым для джуниора станет способность к обучению.
Как только джуниор набрался опыта и научился принимать правильные решения в работе над проектом, он переходит на уровень «мидл».
С английского — середина. Специалист уровня мидл — следующая ступень эволюции джуна.
• Ориентируется в методах решения задач и подбирает оптимальные.
• Умеет писать код аккуратно.
• Осознает свою роль в общей системе проекта, и как его задачи влияют на работоспособность продукта.
• С уверенностью берется за нестандартные задачи.
Мидл — это опытный сотрудник, который развивается в своем направлении и умеет делать больше, лучше и быстрее джуна. Задачи у мидла более трудные, но и зарплата выше. Когда специалист этого уровня наращивает достаточно компетенций и опыта, он становится сеньором и выбирает один из трех путей развития: продолжить кодить и стать в этом первоклассным специалистом, сконцентрироваться на технической стороне проектов или взяться за управление командой.
Игорь Фонин (тимлид команды frontend-разработки, МегаФон):
Мидлы — это ребята, способные выполнять любой спектр задач от технических до тех, что улучшают проект. Мидлы создают новые страницы, а при принятии решения советуются с сеньором или тимлидом. Но не всегда мидлам доступны архитектурные задачи — за ними нужен контроль.
На что обращают внимание рекрутеры при подборе
1. Портфолио и реальные проекты.
2. Знания (измеряются количеством языков, протоколов и систем, которые освоены на практике);
3. Менеджерские качества — например, в МегаФоне смотрят на понимание культуры Agile.
Мидл — это человек, который способен включиться в работу в незнакомой отрасли или новом отделе быстро и почти без ошибок, поскольку он гораздо увереннее в своих знаниях и навыках, чем джун. Мидл намеренно включается в работу смежных сфер или набирается опыта в других отделах. Стремление углубить знания, разобраться в прежде непонятном и прокачать себя со временем превратит его в сеньора.
С английского — старший. Это либо гуру в своем направлении, либо тимлид и руководитель отдела.
• Глубоко знает направление, в котором работает, и в достаточной мере прокачан в смежных сферах.
• Набил массу шишек и все их превратил в полезный опыт.
• Умеет выдержать баланс: знает, где на компромисс идти нельзя, а где можно опустить простоту и красоту и сделать костыль.
• Обладает хорошими коммуникативными навыками и тем, что принято называть «эмоциональным интеллектом».
• Умеет делегировать и распределять задачи в команде, базируясь на сильных сторонах коллег.
У сеньора особый склад ума. Он знает, что отвечает за код и продукт и берет на себя ответственность за принятые решения. Отмазки не использует и не скидывает ответственность на клиентов, коллег или судьбу.
Игорь Фонин (тимлид команды frontend-разработки, МегаФон):
Сеньор — человек с развитыми софт-скиллами. Он помогает младшим коллегам, оценивает сложность задач и выступает лидером своей команды в техническом плане. К лиду в основном обращается по поводу того, как лучше сделать, или за мнением со стороны.
На что обращают внимание рекрутеры при подборе
1. Софт-скиллы и образ мышления.
2. Уровень экспертизы.
Пути эволюции мидла
Упрощая, мы хотим выстроить прямую цепочку эволюции: джун, мидл, сеньор. Но на деле не обязательно идти по проторенной дорожке к логичной финальной точке в виде позиции тимлида. У мидла есть несколько путей, по которым он может следовать, но все они непременно приведут его к уровню сеньора.
1. Разработчик-эксперт. Если специалист не хочет бросать код, он волен остановиться и не идти дальше по карьерной лестнице. В этом случае он станет сеньором, который пишет код, развивает свои навыки и углубляет знания. Рост в этом пути развития — это увеличение стоимости компетенций.
2. Техлид (в дальнейшем архитектор). Этот путь выбирают те, кто хочет сконцентрироваться на технической части: придумывать комплексные решения и системы, смотреть на всю картину целиком и решать интересные задачи. Архитектор уже не занимается кодом, а проектирует и продумывает решения.
3. Тимлид (в дальнейшем руководитель разработки). Та самая управленческая должность. Это кардинальная смена деятельности. Вместо кода тимлид занимается мотивацией своей команды, оценкой эффективности и следит за тем, чтобы все процессы работали. Часто бывает, что техлид и тимлид — это один и тот же человек. Он видит общую картину, принимает решения и при этом руководит командой.
Классифицикация по трем уровням скиллов разработчиков — чисто прикладной инструмент. Он упрощает процесс отбора и помогает обозначить компетенции и требуемый опыт. Но каждый случай индивидуален. В МегаФоне нацелены на быстрое развитие сотрудников и помогают развивать их навыки.
Сергей Кузин (менеджер по подбору персонала, МегаФон):
Рост от джуна до мидла и до синьора сейчас может быть очень стремительным. Многое зависит от инициативы самого разработчика. В МегаФоне для таких переходов есть практически неограниченные возможности по изучению современных технологий и языков и плотная работа с наставниками.
IT в МегаФоне очень разнородно, мы много чем интересным занимаемся. В большей степени команды фокусируются вокруг наших продуктов: есть ребята, которые занимаются мобильным приложением, сайтом. Есть те, кто разрабатывает и поддерживает продукты для корпоративных клиентов (от умных производств, видеоаналитики до крупных проектов безопасных городов и так далее). Есть и те, кто сфокусирован на счастье внутренних сотрудников и делают жизнь каждого из нас — в офисе или на удаленке, — проще и удобнее. Продуктовый подход в разработке позволяет нам быть быстрее и делать действительно важные вещи.
В МегаФоне предлагают конкурентные по рынку вилки зарплат для соискателей с разным уровнем экспертизы. А переход между позициями джуна и мидла или мидла и сеньора в компании происходит за счет обучения и поддержки менторов. В МегаФоне не обязательно идти по дороге «стажер — тимлид», можно двигаться между проектами и находить для себя более интересные задачи.
Атмосфера в МегаФоне, возможность учиться внутри компании и обмен опытом между отделами помогают быстро вырасти с джуна до мидла, а с мидла до сеньора, если у сотрудника есть такое желание. Митапы, мастер-классы и конференции в профессиональной сфере дадут значительный буст навыкам.
МегаФон ищет в свою IT-команду QA-тестировщика, Java, iOS и React разработчиков. И прямо сейчас у вас есть возможность получить приглашение на собеседование без лишних тестовых работ. Если вы в поиске вакансии, выбирайте свою специализацию и пройдите наш Пиратский квест.
Доброе дело спустя год
В прошлом году мы установили два стенда со скакалками в центре Челябинска. Любой желающий может взять скакалку и попрыгать.
Прошло достаточно много времени, и я хочу поделиться наблюдениями.
Стенды функционируют, скакалки пропадают, но не фатально. Потери на Алом Поле составляют в среднем 13 скакалок в месяц, на стадионе Локомотив примерно в 8 раз меньше.
Так выглядит стенд, когда мы месяц не были в парке.
Самый неприятный случай был, когда мы приехали на площадку через несколько дней после того, как навели там порядок. И обнаружили на нём одну скакалку.
По моим наблюдениям пакостят в основном школьники. Оказывается, многие из них даже не догадываются, для чего скакалки нужны. Я неоднократно наблюдал, как они перекидывают их через турник и качаются, некоторые размахивают ими и стучат ими по опорам турников. Иногда бегают с ними по газонам и бросают где попало (мы находили в округе).
Обычно я подхожу и рассказываю, для чего нужны скакалки. Бывает, что у ребят появляется интерес, тогда я могу показать несколько трюков и чему-то научить.
Какие бы потери не происходили, мы регулярно пополняем наличие на обоих стендах.
В хорошую погоду прыгают довольно много, одновременно бывает 10-15 человек. Причем это люди всех возрастов.
Сначала скакалки были разноцветными без какой либо закономерности. А потом мы додумались соотнести цвета в зависимости от длины.
Теперь пользоваться ими стало удобнее, а также контролировать наличие. Если кто-то присылает фотку с состоянием стенда, сразу легко оценить, каких скакалок не хватает, чтобы пополнить наличие.
Зимой рядом со стендом нагребли большую кучу снега, поэтому когда она начала таять, пришлось на три недели убрать скакалки, чтобы они не валялись в грязи (когда я проектировал стенды, то не додумался крючки разместить выше, чтобы скакалки не касались земли).
Когда подсохло, то скакалки мы повесили на место, а на землю постелили резиновые коврики, чтобы рукоятки не пачкались, и людям не ходить по земле.
Хочу сказать про сами скакалки. Мы вешаем на стенды не обычные резиновые, а бисерные. Они не путаются во время прыжков (это особенно важно для новичков) и не перемерзают на морозе, поэтому прыгать можно круглый год.
Я сам довольно неплохо прыгаю со скакалкой, но когда начинал, мне не хватало нужного инвентаря, поэтому дело шло довольно медленно. Семь лет назад я бы с удовольствием ходил в подобное место. Думаю, что там есть шанс встретить единомышленников, учитывая то, что скакалка становится всё популярнее в последнее время.
Итог. Я доволен проектом.
За всё время (это 15 месяцев) потери довольно большие: 200 скакалок на Алом Поле и 40 на стадионе Локомотив. Думаю, что за это время скакалками воспользовались несколько тысяч человек. Некоторые из них периодически пишут мне в соц сетях приятные слова.
Для установки следующего стенда будем учитывать, что в спортивных локациях меньше случайных людей, поэтому скакалки пропадают реже, чем в парке.
Мы недавно переехали в другой город, но продолжаем навещать наши стенды и пополнять наличие скакалок.
У этого проекта несколько целей:
1. Создать условия для занятий спортом (физкультурой).
2. Проверить, насколько жизнеспособной может быть подобная инициатива.
3. Показать своим детям положительный пример и научить их ценить чужой труд.
Неудобно вышло
Ответ apsil в «Елена, Алё?!»
Не знаю продолжение ли этого, но в телеге ссылаются именно на это.
Подъехала вторая часть с той самой ебанутой мамашкой из вотсапа.
Спас 10 человек
Животные в городе
Приз за лучшие ноги получает.
Котстел
Гордость
Кстати коровок или свинушек не жалко?
Нормально так. Девочка Грета с мамой.
Такие поздравления
Как делают бумагу
«Народ у нас оскотинился». Под Петербургом мама-депутат ищет, кто слил видео с её ребёнком за рулем
Депутат из Гатчинского района Ленобласти похвасталась в социальных сетях навыками вождения своего маленького сына. После звонка журналистов ролик оказался удалён, а среди подписчиков начался поиск стукача.
На видео, опубликованное в Instagram депутата совета депутатов Гатчинского района Светланы Малашковой, обратило внимание издание 47news 27 ноября. В ролике на коленях у женщины сидит маленький мальчик, вероятно сын, и управляет автомобилем. Ребёнок заявляет, что сел за руль в 7 лет.
— Сейчас, можно сказать, ты первый раз едешь сам. Левее, канава, — поправляет Малашкова, добавляя, — но педали нажимаю я. Мы тут решили по дорожке проехаться до магазина. Сам едет (переводит камеру на накатанную заснеженную дорогу, видно, что на спидометре 18–20 км/час).
— Ой, мам, там машина! Стой, мам, держи! — воскликнул мальчик.
Мать смеётся в ответ на камеру: «Испугался, руль бросил. Я тебе там помогу, не бойся».
Малашкова в разговоре с журналистами отказалась комментировать видео. После звонка ролик из аккаунта пропал, но появилась запись. «Пока я в бане мои подписчики скидывают мои сториз журналистам. Хочу сказать одно, народ у нас оскатинился и доносами занялся. И мне жаль его» (орфография и пунктуация сохранены. — Прим. ред.).
Светлана Малашкова окончила Институт специальной педагогики и психологии и Государственный институт экономики, финансов, права и технологий. Стала депутатом на выборах в 2019 году от ЛДПР. Входит в постоянную комиссию по вопросам правопорядка и законности. В апреле 2021 года зарегистрировалась как индивидуальный предприниматель. Вид деятельности — реклама. Ранее работала в гатчинской полиции, но уволилась после рождения ребёнка. Известна как экоактивист, борющийся со свалками.
Как моя Мама отказалась от меня
К машине шли гордым строем.
Впереди охранник с тележкой, наполненной продуктами.
Следом я с литровой коробкой сока, кульком конфет и синим воздушным шариком, и следом мама с чеком, десяти процентной скидкой и бурчанием «Откажусь, к чертовой матери, от тебя. Ходишь, блин, позоришь». Но довольная.