Про аутстафф.
Ниже размышления исключительно на основе своего личного опыта работы с аутстафф-сотрудниками.
Во-первых. При привлечении аутстафф-сотрудника кандидат должен проходить те же этапы собеседования, что и кандидат при найме в штат, т.е. это как минимум технический этап и этап проверки soft skills. Полагаться на веру в то, что вам сразу дадут технически сильных кандидатов, которые умеют работать в команде, не стоит. Всегда надо проверять.
Во-вторых. Это способ оплаты time-to-material, т.е. когда аутстафф-сотрудник полностью вовлечён в работу вашей команды, не отвлекается на сторонние проекты и, в идеале, не трекает нигде время, т.к. и так понятно, что он занят каждый день задачами вашей команды.
В-третьих. Аутстафф-сотрудник после онбординга должен обладать правами, практически равными штатному сотруднику, чтобы он чувствовал себя частью команды, понимал общие цели, задачи и метрики команды. Он должен чувствовать, что его наняли не просто тупо делать то, что ему скажут, а как специалиста, который имеет свою точку зрения, экспертизу и может влиять на принятие решений в рамках зоны своей ответственности и экспертности.
В-четвёртых. Ваш тимлид должен работать с аутстафф-сотрудником практически так же, как если бы это был его штатный сотрудник. С одной стороны, спорный тезис, так как для тимлида это, возможно, будет работа "в стол" — ведь аутстафф-сотрудник может по разным, не зависящим от тимлида причинам, покинуть проект. Но это необходимо, т.к. иначе сложно будет добиться качества работы аутстафф-сотрудника такого же, как от штатного сотрудника.
В-пятых. Привлечение аутстафф-сотрудников стоит сопровождать параллельным поиском штатных сотрудников, т.к. на постоянной основе иметь в штате большое количество аутстаффа может быть слишком рискованным подходом для ваших команд разработки.
В целом аутстафф — нормальная тема, если уметь его правильно применять и не преувеличивать с количеством.
Ниже размышления исключительно на основе своего личного опыта работы с аутстафф-сотрудниками.
Во-первых. При привлечении аутстафф-сотрудника кандидат должен проходить те же этапы собеседования, что и кандидат при найме в штат, т.е. это как минимум технический этап и этап проверки soft skills. Полагаться на веру в то, что вам сразу дадут технически сильных кандидатов, которые умеют работать в команде, не стоит. Всегда надо проверять.
Во-вторых. Это способ оплаты time-to-material, т.е. когда аутстафф-сотрудник полностью вовлечён в работу вашей команды, не отвлекается на сторонние проекты и, в идеале, не трекает нигде время, т.к. и так понятно, что он занят каждый день задачами вашей команды.
В-третьих. Аутстафф-сотрудник после онбординга должен обладать правами, практически равными штатному сотруднику, чтобы он чувствовал себя частью команды, понимал общие цели, задачи и метрики команды. Он должен чувствовать, что его наняли не просто тупо делать то, что ему скажут, а как специалиста, который имеет свою точку зрения, экспертизу и может влиять на принятие решений в рамках зоны своей ответственности и экспертности.
В-четвёртых. Ваш тимлид должен работать с аутстафф-сотрудником практически так же, как если бы это был его штатный сотрудник. С одной стороны, спорный тезис, так как для тимлида это, возможно, будет работа "в стол" — ведь аутстафф-сотрудник может по разным, не зависящим от тимлида причинам, покинуть проект. Но это необходимо, т.к. иначе сложно будет добиться качества работы аутстафф-сотрудника такого же, как от штатного сотрудника.
В-пятых. Привлечение аутстафф-сотрудников стоит сопровождать параллельным поиском штатных сотрудников, т.к. на постоянной основе иметь в штате большое количество аутстаффа может быть слишком рискованным подходом для ваших команд разработки.
В целом аутстафф — нормальная тема, если уметь его правильно применять и не преувеличивать с количеством.
👍13🔥5❤3💩2
Про управленческую ёмкость у руководителя руководителей.
Выше в этом посте я размышлял про максимальный размер команды. Сейчас хочется подумать о количестве прямых репортов у руководителя департамента/отдела/управления, те не о руководителе команды.
Скажем, у нас есть тимлид тимлидов. Сколько у него может быть в прямом подчинении тимлидов, те команд? За сколько команд он может нести ответственность как руководитель домена?
Если отталкиваться от «Кошелек Миллера», то это 7 ± 2. На мой взгляд, это не совсем верно именно для данного вопроса, верно что-то типа 4 ± 1. Две команды — вроде бы слишком мало, чтобы формировать домен, а шесть — уже как будто бы слишком много, чтобы держать в фокусе все цели всех команд и строить долгосрочное целеполагание и систему метрик для тимлидов этих команд. Понятно, что это зависит от множества факторов и условий, но, на мой взгляд, должно быть примерно так.
Если спросить у gpt, то
Что думаете?
Выше в этом посте я размышлял про максимальный размер команды. Сейчас хочется подумать о количестве прямых репортов у руководителя департамента/отдела/управления, те не о руководителе команды.
Скажем, у нас есть тимлид тимлидов. Сколько у него может быть в прямом подчинении тимлидов, те команд? За сколько команд он может нести ответственность как руководитель домена?
Если отталкиваться от «Кошелек Миллера», то это 7 ± 2. На мой взгляд, это не совсем верно именно для данного вопроса, верно что-то типа 4 ± 1. Две команды — вроде бы слишком мало, чтобы формировать домен, а шесть — уже как будто бы слишком много, чтобы держать в фокусе все цели всех команд и строить долгосрочное целеполагание и систему метрик для тимлидов этих команд. Понятно, что это зависит от множества факторов и условий, но, на мой взгляд, должно быть примерно так.
Если спросить у gpt, то
3–5 команд. Подходит для отделов, требующих высокой координации и персонального внимания (например, научные исследования, продуктовые команды в IT).
5–8 команд. Стандарт для крупных отделов, где требуется умеренный уровень координации.
Более 8 команд. Это редко, так как высокая нагрузка на руководителя снижает управление. В таких случаях создаются дополнительные уровни управления (например, подотделы с руководителями групп).
Что думаете?
❤7👍3💩2
Должен ли СТО хантить сам?
Когда я работал в Магнит, рядом с нами, скажем так, на одной улице, расформировывалась одна из самых крупных (или самая крупная) IT-компаний РФ в сфере доставки продуктов и еды из ресторанов. Благодаря проактивным действиям и нетворкингу нам удалось привлечь в свои команды топовых инженеров. Этим занимался не рекрутмент, этим занимался наш СТО и все СТО-1.
Сейчас ЗЯ находится на этапе активного роста, мы расширяем команду, приглашая новых инженеров. Я лично вовлечён в этот процесс и причина не в нехватке сотрудников в отделе рекрутинга. Я глубоко убеждён, что СТО обязан играть значимую роль в привлечении, оценке и собеседовании специалистов для ключевых направлений, которые имеют решающее значение для компании на определённых этапах ее развития.
Думаю, вы слышали, что, начиная с декабря 2024 года, в IT-инфополе начали появляться новости о череде сокращений у крупных IT-гигантов. Это продолжается и на текущий момент, новостей становится больше и касается это большего числа компаний. Понимаю, что аудитория этого канала является достаточно узким кругом моих знакомств, но всё же, если вы сейчас находитесь в поиске, напишите мне (@arxell). Или откликайтесь на наш лендинг. Сейчас в первую очередь нужны сильные C# backend-разработчики для развития своей программы лояльности/биллинга и запуска разных рекламных штук =)
Когда я работал в Магнит, рядом с нами, скажем так, на одной улице, расформировывалась одна из самых крупных (или самая крупная) IT-компаний РФ в сфере доставки продуктов и еды из ресторанов. Благодаря проактивным действиям и нетворкингу нам удалось привлечь в свои команды топовых инженеров. Этим занимался не рекрутмент, этим занимался наш СТО и все СТО-1.
Сейчас ЗЯ находится на этапе активного роста, мы расширяем команду, приглашая новых инженеров. Я лично вовлечён в этот процесс и причина не в нехватке сотрудников в отделе рекрутинга. Я глубоко убеждён, что СТО обязан играть значимую роль в привлечении, оценке и собеседовании специалистов для ключевых направлений, которые имеют решающее значение для компании на определённых этапах ее развития.
Думаю, вы слышали, что, начиная с декабря 2024 года, в IT-инфополе начали появляться новости о череде сокращений у крупных IT-гигантов. Это продолжается и на текущий момент, новостей становится больше и касается это большего числа компаний. Понимаю, что аудитория этого канала является достаточно узким кругом моих знакомств, но всё же, если вы сейчас находитесь в поиске, напишите мне (@arxell). Или откликайтесь на наш лендинг. Сейчас в первую очередь нужны сильные C# backend-разработчики для развития своей программы лояльности/биллинга и запуска разных рекламных штук =)
👍11❤8❤🔥2
Банального вопроса пост.
Должен ли TeamLead писать код?
Вопрос, которым задается каждый TeamLead команды, когда становится её руководителем. Именно в такой формулировке правильного ответа на него нет. Нет, потому что вопрос задан неверно: в нём не раскрыто, о какой именно команде идет речь. Правильная формулировка, например, может быть такой:
Или такой:
В целом всё просто. Чем больше в команде инженеров разных специальностей, тем меньше TeamLead должен уделять времени написанию кода. Его фокус смещается на people-менеджмент, процессы, архитектуру, документацию, метрики и планирование. На самом деле, на все то, что описано на Teamlead Roadmap.
Сейчас это встречается реже, но раньше в вакансиях на TeamLead'а часто писали про "играющего тренера" при команде из ±10 человек. Это жуткий антипаттерн. Если вы хотите полноценного "играющего тренера", который будет хотя бы 50% времени писать код, то это точно про функциональные команды (команды одного стека разработки) с составом ±5 человек.
Моя точка зрения такая: Не важно, пишет ли ваш TeamLead код, важно, чтобы он "программировал" своих сотрудников и свою команду на успех!
Набор статей на эту тему для составления собственного мнения:
- Должен ли тимлид писать код?
- Почему тимлид может писать код?
- От джуна до тимлида. Должен ли тимлид писать хороший код, чем хорош planning poker и другие интересности
- Уже не программист, но еще не менеджер
- Руководитель, который навсегда в вашем сердечке, — какой он? И что делает его таким крутым? ❤️
Должен ли TeamLead писать код?
Вопрос, которым задается каждый TeamLead команды, когда становится её руководителем. Именно в такой формулировке правильного ответа на него нет. Нет, потому что вопрос задан неверно: в нём не раскрыто, о какой именно команде идет речь. Правильная формулировка, например, может быть такой:
Должен ли TeamLead писать код в команде, состоящей из трёх backend-разработчиков?
Или такой:
Должен ли TeamLead писать код в команде, состоящей из десяти инженеров разных стеков разработки/тестирования/аналитики?
В целом всё просто. Чем больше в команде инженеров разных специальностей, тем меньше TeamLead должен уделять времени написанию кода. Его фокус смещается на people-менеджмент, процессы, архитектуру, документацию, метрики и планирование. На самом деле, на все то, что описано на Teamlead Roadmap.
Сейчас это встречается реже, но раньше в вакансиях на TeamLead'а часто писали про "играющего тренера" при команде из ±10 человек. Это жуткий антипаттерн. Если вы хотите полноценного "играющего тренера", который будет хотя бы 50% времени писать код, то это точно про функциональные команды (команды одного стека разработки) с составом ±5 человек.
Моя точка зрения такая: Не важно, пишет ли ваш TeamLead код, важно, чтобы он "программировал" своих сотрудников и свою команду на успех!
Набор статей на эту тему для составления собственного мнения:
- Должен ли тимлид писать код?
- Почему тимлид может писать код?
- От джуна до тимлида. Должен ли тимлид писать хороший код, чем хорош planning poker и другие интересности
- Уже не программист, но еще не менеджер
- Руководитель, который навсегда в вашем сердечке, — какой он? И что делает его таким крутым? ❤️
👍15😁4❤2
Крутое исследование от JetBrains - State of Developer Ecosystem Report 2024
Вот что я для себя отметил:
- JS, как всегда, на первом месте. Python тоже не отстает, видимо, благодаря ML/DS и прочим математическим задачам.
- Радует, что PostgreSQL потихоньку отжимает аудиторию у MySQL, а MongoDB/SQLite/Redis внезапно для меня стабильно находятся на +- третьем месте.
- GoLang немного сдал позиции, но, видимо, за пределами РФ. В РФ все же Go остается крайне популярным.
- Rust потихоньку растет и все еще надеется заменить C/C++.
- Yandex Cloud занял 1% аудитории облачных сервисов, что приятно.
- 28% респондентов ответили, что компания измеряет их development experience и продуктивность. При этом за эти метрики в 68% случаев отвечает TeamLead, а в 17% случаев — платформенные команды. Однако! =)
- Самое сложное в работе: 38% — понять, чего хочет клиент, 34% — коммуникации по рабочим вопросам c коллегами, 32% — понимание чужого кода.
- И самое интересное и волнующее для меня — это размер команды: 71% опрошенных работают в командах до 12 человек.
Вот что я для себя отметил:
- JS, как всегда, на первом месте. Python тоже не отстает, видимо, благодаря ML/DS и прочим математическим задачам.
- Радует, что PostgreSQL потихоньку отжимает аудиторию у MySQL, а MongoDB/SQLite/Redis внезапно для меня стабильно находятся на +- третьем месте.
- GoLang немного сдал позиции, но, видимо, за пределами РФ. В РФ все же Go остается крайне популярным.
- Rust потихоньку растет и все еще надеется заменить C/C++.
- Yandex Cloud занял 1% аудитории облачных сервисов, что приятно.
- 28% респондентов ответили, что компания измеряет их development experience и продуктивность. При этом за эти метрики в 68% случаев отвечает TeamLead, а в 17% случаев — платформенные команды. Однако! =)
- Самое сложное в работе: 38% — понять, чего хочет клиент, 34% — коммуникации по рабочим вопросам c коллегами, 32% — понимание чужого кода.
- И самое интересное и волнующее для меня — это размер команды: 71% опрошенных работают в командах до 12 человек.
👍5❤2🔥1
Метрики эффективности спринта.
Летом 2024 года, когда все были в отпусках, у меня выдалось две относительно свободные недели. Передо мной стояла задача подумать над тем, как можно оценить работу команд, которые делают Ecom в ЗЯ. Не с целью найти слабых, а скорее понять, что где как поломано, работает плохо или не работает вообще. Не помню как, но сначала я наткнулся на этот плагин для grafana, а затем на эту статью от Skyeng на Habr. И понеслось...
Я загорелся идеей на основе непосредственных данных из базы Jira построить ряд дешбордов для оценки как классических метрик типа TimeToMarket / LeadTime / CycleTime, так и метрик эффективности спринта.
Что такое вообще метрики эффективности спринта? Опять же, есть множество способов измерить спринт. На эту тему мне очень нравится вот этот доклад на PodlodkaTeamLeadCrew#12 от Avito. Но если не погружаться в академические тонкости, и строить что-то свое на коленке, то это % того, что команда сделала относительно того, что она обещала сделать.
Что значит «сделала»? Что значит «обещала сделать»? Сейчас постепенно команды переходят на планирование спринта в сторях, где каждая сторя — это некая цель спринта. Все, что не сторя, менее важно. Процент выполненных сторей и является той эффективностью спринта, которую мы ищем. Я прекрасно понимаю, что любую метрику можно «похачить», например, декомпозировав эпик на стори так, что они будут закрываться, но при этом фича не будет двигаться к завершению. Считаем, что осознанно «хачить» никто не будет, если будет, то нам с такими не по пути.
На скрине спринт одной из команд, где я ВРИО тимлида, команда запланировала 12 сторей (целей), закрыла за сам спринт 9, то есть 75%. Уже чуть позже, в самом начале следующего спринта, еще 2 стори, то есть 91%. Но итоговый результат мы считаем 75%.
Если говорить о каких-то выводах, то основное, и, наверное, в чем-то стыдное и банальное, — это фокусировка команды на целях спринта, оформленных так, чтобы это было визуально максимально понятно и прозрачно видно на Scrum-доске, например, в виде swimlane'ов.
Летом 2024 года, когда все были в отпусках, у меня выдалось две относительно свободные недели. Передо мной стояла задача подумать над тем, как можно оценить работу команд, которые делают Ecom в ЗЯ. Не с целью найти слабых, а скорее понять, что где как поломано, работает плохо или не работает вообще. Не помню как, но сначала я наткнулся на этот плагин для grafana, а затем на эту статью от Skyeng на Habr. И понеслось...
Я загорелся идеей на основе непосредственных данных из базы Jira построить ряд дешбордов для оценки как классических метрик типа TimeToMarket / LeadTime / CycleTime, так и метрик эффективности спринта.
Что такое вообще метрики эффективности спринта? Опять же, есть множество способов измерить спринт. На эту тему мне очень нравится вот этот доклад на PodlodkaTeamLeadCrew#12 от Avito. Но если не погружаться в академические тонкости, и строить что-то свое на коленке, то это % того, что команда сделала относительно того, что она обещала сделать.
Что значит «сделала»? Что значит «обещала сделать»? Сейчас постепенно команды переходят на планирование спринта в сторях, где каждая сторя — это некая цель спринта. Все, что не сторя, менее важно. Процент выполненных сторей и является той эффективностью спринта, которую мы ищем. Я прекрасно понимаю, что любую метрику можно «похачить», например, декомпозировав эпик на стори так, что они будут закрываться, но при этом фича не будет двигаться к завершению. Считаем, что осознанно «хачить» никто не будет, если будет, то нам с такими не по пути.
На скрине спринт одной из команд, где я ВРИО тимлида, команда запланировала 12 сторей (целей), закрыла за сам спринт 9, то есть 75%. Уже чуть позже, в самом начале следующего спринта, еще 2 стори, то есть 91%. Но итоговый результат мы считаем 75%.
Если говорить о каких-то выводах, то основное, и, наверное, в чем-то стыдное и банальное, — это фокусировка команды на целях спринта, оформленных так, чтобы это было визуально максимально понятно и прозрачно видно на Scrum-доске, например, в виде swimlane'ов.
👍8❤2👌2
Нашел в своих старых заметках опросник, через который я прогонял кандидатов в свою команду во время работы в ostrovok.ru. Спустя 8 лет некоторые вопросы всё ещё кажутся актуальными.
Что ты будешь делать, если задача, поставленная перед тобой, плохо описана?
1. спрошу у лида
2. верну задачу обратно в пул со статусом need info
3. отвечу на свои вопросы сам и сделаю так, как считаю правильным
Ожидаемый ответ: 1 или 1/3
Что ты будешь делать, если у тебя кончатся задачи в спринте?
1. ничего
2. займусь самообучением/самообразованием
3. возьму сам задачи из бэклога
4. спрошу у лида
5. посмотрю, что у нас с техническим долгом, и постараюсь закрыть его
Ожидаемый ответ: 3 или 4 или 5
Если тебе что-то непонятно, то ты спросишь у лида или попробуешь разобраться сам?
1. буду стараться разобраться сам, пока не сдамся
2. попробую быстро разобраться сам, если не получится, спрошу у лида
3. сразу спрошу у лида, тк это будет быстро и эффективно
Ожидаемый ответ: 1 или 2
Для разработки фичи нужна помощь разработчика из другой команды. Сегодня он работает удаленно, а фичу хочется начать делать уже сегодня. Что делать?
1. постараюсь четко сформулировать свой вопрос и задать его в корпоративном мессенджере. Буду надеяться, что получу полный ответ
2. предложу пообщаться с коллегой голосом в Skype
3. дождусь завтра, когда он будет в офисе, а пока займусь другими задачами
4. спрошу у лида
Ожидаемый ответ: 1 или 2
Собрали релиз, в который вошло множество фич, багфиксов и рефакторинга. Поняли, что в релизе есть новый баг, который затрагивает менее 1% пользователей. Что делать?
1. будем фиксить, снова все тестировать, в итоге отложим релиз на 1–2 дня, а возможно и больше
2. катим, но сразу фиксим и готовим новый релиз
Ожидаемый ответ: 2
Как лучше поступить при написании новой фичи в текущем большом проекте?
1. начну сразу делать фичу, после ее разработки/внедрения буду рефакторить проект
2. проведу небольшой рефакторинг, потом сразу буду делать фичу
3. буду рефакторить, пока не пойму, что код новой фичи хорошо ложится в текущий проект
Ожидаемый ответ: 2 или 3
Микросервис, с которым взаимодействует твой проект, изменил что-то в текущей интеграции по API, тем самым сломав ее. Изменения небольшие, и ты можешь сам пофиксить проблему на своей стороне. Что делать?
1. напишу ребятам, что они все сломали, и пусть чинят
2. напишу ребятам, что они все сломали, но починю у себя, тк это быстрее
Ожидаемый ответ: 2
Буквально вчера вышла новая версия языка, на котором написан твой проект. В ней есть множество киллер-фич, которые тебе очень нужны, но просто так обновиться нельзя, так как есть легаси-библиотеки, которые ее не поддерживают. Что делать?
1. всё, пора! Хватит это терпеть! Буду просить у лида время на обновление до новой версии
2. 5 лет терпели и еще 5 потерпим, а потом уже и работу сменю
Ожидаемый ответ: 1
Что ты будешь делать, если задача, поставленная перед тобой, плохо описана?
1. спрошу у лида
2. верну задачу обратно в пул со статусом need info
3. отвечу на свои вопросы сам и сделаю так, как считаю правильным
Что ты будешь делать, если у тебя кончатся задачи в спринте?
1. ничего
2. займусь самообучением/самообразованием
3. возьму сам задачи из бэклога
4. спрошу у лида
5. посмотрю, что у нас с техническим долгом, и постараюсь закрыть его
Если тебе что-то непонятно, то ты спросишь у лида или попробуешь разобраться сам?
1. буду стараться разобраться сам, пока не сдамся
2. попробую быстро разобраться сам, если не получится, спрошу у лида
3. сразу спрошу у лида, тк это будет быстро и эффективно
Для разработки фичи нужна помощь разработчика из другой команды. Сегодня он работает удаленно, а фичу хочется начать делать уже сегодня. Что делать?
1. постараюсь четко сформулировать свой вопрос и задать его в корпоративном мессенджере. Буду надеяться, что получу полный ответ
2. предложу пообщаться с коллегой голосом в Skype
3. дождусь завтра, когда он будет в офисе, а пока займусь другими задачами
4. спрошу у лида
Собрали релиз, в который вошло множество фич, багфиксов и рефакторинга. Поняли, что в релизе есть новый баг, который затрагивает менее 1% пользователей. Что делать?
1. будем фиксить, снова все тестировать, в итоге отложим релиз на 1–2 дня, а возможно и больше
2. катим, но сразу фиксим и готовим новый релиз
Как лучше поступить при написании новой фичи в текущем большом проекте?
1. начну сразу делать фичу, после ее разработки/внедрения буду рефакторить проект
2. проведу небольшой рефакторинг, потом сразу буду делать фичу
3. буду рефакторить, пока не пойму, что код новой фичи хорошо ложится в текущий проект
Микросервис, с которым взаимодействует твой проект, изменил что-то в текущей интеграции по API, тем самым сломав ее. Изменения небольшие, и ты можешь сам пофиксить проблему на своей стороне. Что делать?
1. напишу ребятам, что они все сломали, и пусть чинят
2. напишу ребятам, что они все сломали, но починю у себя, тк это быстрее
Буквально вчера вышла новая версия языка, на котором написан твой проект. В ней есть множество киллер-фич, которые тебе очень нужны, но просто так обновиться нельзя, так как есть легаси-библиотеки, которые ее не поддерживают. Что делать?
1. всё, пора! Хватит это терпеть! Буду просить у лида время на обновление до новой версии
2. 5 лет терпели и еще 5 потерпим, а потом уже и работу сменю
👍9❤1🔥1👌1
Пока кто-то сокращает, мы нанимаем, открываем новые направления и рынки для бизнеса.
Новости на этой неделе.
- На рынке говорят о том, что крупные компании сокращают штат IT-шников. А ритейлер «Золотое Яблоко», наоборот, рассказал о планах нарастить пул таких специалистов.
- С массовыми сокращениями не всё так плохо — обнаружил, что в Золотом Яблоке открыто 30 вакансий, на которые планируют нанять 150 (!) человек.
- "Золотое Яблоко" планирует расширить штат IT-специалистов на 25%. Кажется, ритейлер готовится к серьёзному усилению в диджитале.
- «Золотое Яблоко» расширяет ИТ-штат на 25%
- «Золотое Яблоко» на четверть увеличит штат IT-специалистов
Чтобы вам было проще, вот мои вакансии в Ecom или пишите мне (@arxell) c ссылкой или c файлом на ваш CV, я перешлю кому надо.
- ios / android
- Middle .NET developer / Senior .Net developer
- Middle Fullstack QA / Senior Fullstack QA
- Системный аналитик
- Frontend developer Vue
Также ищем TeamLead'ов команд разработки, которые отвечают за delivery-процесс в своей команде по доставке ценностей для клиентов, метрики, планирование т.д. и т.п. что описано тут.
Новости на этой неделе.
- На рынке говорят о том, что крупные компании сокращают штат IT-шников. А ритейлер «Золотое Яблоко», наоборот, рассказал о планах нарастить пул таких специалистов.
- С массовыми сокращениями не всё так плохо — обнаружил, что в Золотом Яблоке открыто 30 вакансий, на которые планируют нанять 150 (!) человек.
- "Золотое Яблоко" планирует расширить штат IT-специалистов на 25%. Кажется, ритейлер готовится к серьёзному усилению в диджитале.
- «Золотое Яблоко» расширяет ИТ-штат на 25%
- «Золотое Яблоко» на четверть увеличит штат IT-специалистов
Чтобы вам было проще, вот мои вакансии в Ecom или пишите мне (@arxell) c ссылкой или c файлом на ваш CV, я перешлю кому надо.
- ios / android
- Middle .NET developer / Senior .Net developer
- Middle Fullstack QA / Senior Fullstack QA
- Системный аналитик
- Frontend developer Vue
Также ищем TeamLead'ов команд разработки, которые отвечают за delivery-процесс в своей команде по доставке ценностей для клиентов, метрики, планирование т.д. и т.п. что описано тут.
🔥7❤5💅4✍2🤡2😍2🎉1
Про гигиенический минимум.
Мне раньше было смешно, когда я видел в резюме у кандидатов среди навыков пункты Jira/Confluence. Что же такого особенного надо уметь, чтобы заявлять это как навыки в своём резюме, — думал я.
Прошло время, и мне стало грустно, тк сейчас мне начинает казаться, что работу с таск-трекером как навык надо внести в гигиенический минимум при найме в IT-компании.
Не понимаю, как можно не уметь делать простейшие вещи в Jira, типа создания Story и привязки к ней задач или хотя бы просто сделать существующую задачу подзадачей (сабтаской) у Story. Это же база!
Сейчас, на фоне сокращений в РФ, я точно убеждён, что время кодеров прошло — они никому не нужны, как те самые валенки в углу. Нужны инженеры, которые умеют ставить себе задачи, описывать их, программировать их, писать к ним тесты, оставлять в каком-то виде после себя документацию, проверять, что happy-кейсы проходят, и релизить в prod.
Принцип «Швейцарского ножа» актуален как никогда.
Мне раньше было смешно, когда я видел в резюме у кандидатов среди навыков пункты Jira/Confluence. Что же такого особенного надо уметь, чтобы заявлять это как навыки в своём резюме, — думал я.
Прошло время, и мне стало грустно, тк сейчас мне начинает казаться, что работу с таск-трекером как навык надо внести в гигиенический минимум при найме в IT-компании.
Не понимаю, как можно не уметь делать простейшие вещи в Jira, типа создания Story и привязки к ней задач или хотя бы просто сделать существующую задачу подзадачей (сабтаской) у Story. Это же база!
Сейчас, на фоне сокращений в РФ, я точно убеждён, что время кодеров прошло — они никому не нужны, как те самые валенки в углу. Нужны инженеры, которые умеют ставить себе задачи, описывать их, программировать их, писать к ним тесты, оставлять в каком-то виде после себя документацию, проверять, что happy-кейсы проходят, и релизить в prod.
Принцип «Швейцарского ножа» актуален как никогда.
GitHub
arxell/playbook/engineering_culture.md at main · arxell/arxell
Contribute to arxell/arxell development by creating an account on GitHub.
🤡12💯12👍8🔥3❤2
Небольшой красоты пост.
Впереди гендерные праздники: 14/23 февраля и 8 марта.
Порадовать свою вторую половину, маму, папу, брата или сестру можно, подарив электронную подарочную карту ЗЯ с уникальным дизайном, созданным непосредственно вами с помощью нейросети.
Пример запроса
Сам запрос, кстати, можно тоже сгенерировать через AI (chatgpt). Я запросил так:
и получил то, что выше. Вот такой вот круговорот AI запросов в природе.
P.S.: ограничение 3 дизайна за 2 часа, будьте аккуратны в своих запросах =)
Впереди гендерные праздники: 14/23 февраля и 8 марта.
Порадовать свою вторую половину, маму, папу, брата или сестру можно, подарив электронную подарочную карту ЗЯ с уникальным дизайном, созданным непосредственно вами с помощью нейросети.
Пример запроса
молодая пара держится за руки в красивом парке, вокруг цветущие деревья с сердечными листьями. На переднем плане корзинка с цветами и открытками в форме сердец. Небо окрашено в розово-фиолетовые оттенки захода солнца, сверху летят маленькие купидоны с луками
Сам запрос, кстати, можно тоже сгенерировать через AI (chatgpt). Я запросил так:
Напиши запрос для генерации картинки для 14 февраля
и получил то, что выше. Вот такой вот круговорот AI запросов в природе.
P.S.: ограничение 3 дизайна за 2 часа, будьте аккуратны в своих запросах =)
🔥7❤5👍5
Гибко или строго?
Вроде бы простой вопрос. В такой формулировке гибкость звучит как очевидный правильный ответ, тк гибкость подразумевает скорость. Так ли это? Всегда ли гибкость дает скорость, а строгость замедляет?
Если задуматься об этом вопросе на примере конфигурации backend-сервисов, где есть скажем два варианта:
A) динамическое конфигурирование сервисов в runtime
B) конфигурирование через YAML-конфиги с последующим деплоем
то кажется, что динамическая конфигурация в runtime будет быстрее.
Да, если речь идет о разовом изменении, то вариант A будет быстрее, но дьявол, как всегда, кроется в деталях. Я строго убежден, что варианты типа A в том или ином виде накапливают большой технический долг по сравнению с вариантами типа B, что в итоге на длительной дистанции приводит к драматическому замедлению скорости разработки.
Попробую, попытаюсь объяснить. В IT уже давно решён вопрос хранения кода. Кстати, вот отличная статья на эту тему. Сейчас разработчик всегда может посмотреть историю жизни каждой строчки кода в своем проекте, так как git всё помнит. Всегда можно откатиться к предыдущей версии, понять, что было тогда, что было где-то посередине, и как всё выглядит сейчас. Понятно кто/что/как/когда изменил, есть связь с задачей в таск-трекером, а CI/CD обеспечивает проверку каждого этапа изменения и связи изменения с номером сборки и релиза. Это в совокупе дает максимальную прозрачность и явность в изменениях. Конфигурация — это такой же "код", как и код, написанный на условном Python/Golang/C#/Java/..., если к конфигурации относиться как к коду, то на долгой дистанции это уменьшает количество тупых багов, инцидентов и неконтролируемых изменений, которые съедают кучу времени у команды разработки.
Другое дело, что если CI/CD медленный или нет возможности самостоятельно раскатывать свои backend-релизы, то разработчики по пути наименьшего сопротивления будут искать лазейки, чтобы менять конфиги динамически, без изменения их в YAML-файлах. Это уже вопросы к зрелости инфраструктуры, DevOps-процессов и качеству CI/CD. Иными словами, если у меня, как у разработчика, от мержа ветки с изменениями в master до раскатки на prod-стенд проходит 3–5 минут, то о динамической конфигурации мне и думать нет смысла.
P.S.: фичефлаги и АБтесты это не конфигурация!
Вроде бы простой вопрос. В такой формулировке гибкость звучит как очевидный правильный ответ, тк гибкость подразумевает скорость. Так ли это? Всегда ли гибкость дает скорость, а строгость замедляет?
Если задуматься об этом вопросе на примере конфигурации backend-сервисов, где есть скажем два варианта:
A) динамическое конфигурирование сервисов в runtime
B) конфигурирование через YAML-конфиги с последующим деплоем
то кажется, что динамическая конфигурация в runtime будет быстрее.
Да, если речь идет о разовом изменении, то вариант A будет быстрее, но дьявол, как всегда, кроется в деталях. Я строго убежден, что варианты типа A в том или ином виде накапливают большой технический долг по сравнению с вариантами типа B, что в итоге на длительной дистанции приводит к драматическому замедлению скорости разработки.
Попробую, попытаюсь объяснить. В IT уже давно решён вопрос хранения кода. Кстати, вот отличная статья на эту тему. Сейчас разработчик всегда может посмотреть историю жизни каждой строчки кода в своем проекте, так как git всё помнит. Всегда можно откатиться к предыдущей версии, понять, что было тогда, что было где-то посередине, и как всё выглядит сейчас. Понятно кто/что/как/когда изменил, есть связь с задачей в таск-трекером, а CI/CD обеспечивает проверку каждого этапа изменения и связи изменения с номером сборки и релиза. Это в совокупе дает максимальную прозрачность и явность в изменениях. Конфигурация — это такой же "код", как и код, написанный на условном Python/Golang/C#/Java/..., если к конфигурации относиться как к коду, то на долгой дистанции это уменьшает количество тупых багов, инцидентов и неконтролируемых изменений, которые съедают кучу времени у команды разработки.
Другое дело, что если CI/CD медленный или нет возможности самостоятельно раскатывать свои backend-релизы, то разработчики по пути наименьшего сопротивления будут искать лазейки, чтобы менять конфиги динамически, без изменения их в YAML-файлах. Это уже вопросы к зрелости инфраструктуры, DevOps-процессов и качеству CI/CD. Иными словами, если у меня, как у разработчика, от мержа ветки с изменениями в master до раскатки на prod-стенд проходит 3–5 минут, то о динамической конфигурации мне и думать нет смысла.
P.S.: фичефлаги и АБтесты это не конфигурация!
Хабр
История систем управления версиями
В этой статье сравним с технической точки зрения самые известные системы управления версиями (в будущем планируем расширить список): Первое поколение SCCS (Source Code Control System) RCS (Revision...
👍3
6 месяцев с iPhone
Так получилось, что я всегда пользовался Android: HTC Hero -> HTC Legend -> Nexus 5/5X -> Samsung S19/S20/S22. Наверное, было что-то еще, но я уже не вспомню, а история с iPhone у меня как-то не завелась еще с ВУЗа. Я давно хотел iPhone, но отсутствие USB-C мне не давало покоя, и я ждал. Дождался, этим летом (2024) мне подарили iPhone 15 Pro Max, и это стало разочарованием.
Если отбросить весь текущий контекст санкций и отсутствие удобного способа установки банковских приложений, VPN и Apple Pay, мне все равно непонятны две вещи: нет нормальной кнопки «Назад» и долгие анимации там, где они не нужны. Еще я так и не смог разобраться с заменой клавиатуры Apple на Gboard, она вроде как работает, но периодически все равно открывается стандартная клавиатура Apple, которая меня жутко бесит (субъективно, конечно, но все же).
В итоге я вернулся на новый Samsung S25 и бесконечно этому рад. Видимо, это как вопрос кошек и собак, яблок и груш, красного и белого, темного и светлого, те каждому свое.
Так получилось, что я всегда пользовался Android: HTC Hero -> HTC Legend -> Nexus 5/5X -> Samsung S19/S20/S22. Наверное, было что-то еще, но я уже не вспомню, а история с iPhone у меня как-то не завелась еще с ВУЗа. Я давно хотел iPhone, но отсутствие USB-C мне не давало покоя, и я ждал. Дождался, этим летом (2024) мне подарили iPhone 15 Pro Max, и это стало разочарованием.
Если отбросить весь текущий контекст санкций и отсутствие удобного способа установки банковских приложений, VPN и Apple Pay, мне все равно непонятны две вещи: нет нормальной кнопки «Назад» и долгие анимации там, где они не нужны. Еще я так и не смог разобраться с заменой клавиатуры Apple на Gboard, она вроде как работает, но периодически все равно открывается стандартная клавиатура Apple, которая меня жутко бесит (субъективно, конечно, но все же).
В итоге я вернулся на новый Samsung S25 и бесконечно этому рад. Видимо, это как вопрос кошек и собак, яблок и груш, красного и белого, темного и светлого, те каждому свое.
💯10🤝9👍6
Про выбор адреса.
Решил, что пора понемногу освещать технологические проблемы, которые мы решаем в ЗЯ. Сегодня расскажу про вопрос выбора адреса. Вроде бы простой вопрос, но на самом деле нет, когда вы международная компания, представленная в разных регионах мира.
Легко ли выбрать адрес? Спроси меня об этом год назад, я бы с уверенностью ответил «да», но сейчас я скажу «нет».
Мы работаем с разными провайдерами адресов: Yandex, Google, Dadata, Mappable. Обусловлено это тем, что в разных регионах и странах разные провайдеры имеют разное качество геоданных, и нельзя условно везде использовать Google. Все усложняется, когда для клиента в стране мы используем Google, тк считаем, что он дает лучшее качество адреса, а курьеры используют Yandex просто потому, что привыкли.
Особенности между геопровайдерами
- разные форматы ID;
- разные ID ведут к одному адресу (например, в саджесте и геокоде);
- разная детализация адреса;
- разное тегирование элементов адреса (в Yandex много промежуточных компонентов между регионом и населенным пунктом обозначается как district. У Google больше возможностей показать детали адреса с различающимися тегами).
В зависимости от региона – разное качество данных
- МЕ: у некоторых адресов в раскладке отсутствует населенный пункт, т.е. здания принадлежат уровню выше (например, региону), также из-за специфики региона;
- KZ (Google): многие дома не определяются, некорректная нумерация домов (на других картах адрес ведет в другое место), старые данные в наименованиях (с 2006 года уже есть новые сведения);
- АЕ (Google): новые районы города (Дубай) не определяются по подсказкам, обратному геокодированию;
- SA (Google): по некоторым областям со спутника видны пустыри в чертах населенного пункта, но на схеме оказывается район с домами. Медленная скорость актуализации геоданных;
- SA (Mappable): по тем же областям с пустырями есть соответствие спутника и схемы, т.е. зданий реально нет, там пусто;
- РФ (Dadata): точность ФИАС до улицы при наличии дома и координат до дома (при этом адрес реально существует) – по ФИАСу адреса восстановиться может только до улицы; можно придумывать названия домов, строений, корпусов – Dadata выводит такое как реальную подсказку, однако точность координат и ФИАСа падает уже, например, до улицы; в Dadata один тип улицы, в Яндексе другой (например, станция против улицы). У Dadata источником являются местные органы самоуправления, предоставляющие адресную информацию.
Лично для меня было новостью, что в AE, в частности в Дубае, у домов может не быть названий улиц, и это совершенно нормально. Все в основном ориентируются по номерам домов.
Решил, что пора понемногу освещать технологические проблемы, которые мы решаем в ЗЯ. Сегодня расскажу про вопрос выбора адреса. Вроде бы простой вопрос, но на самом деле нет, когда вы международная компания, представленная в разных регионах мира.
Легко ли выбрать адрес? Спроси меня об этом год назад, я бы с уверенностью ответил «да», но сейчас я скажу «нет».
Мы работаем с разными провайдерами адресов: Yandex, Google, Dadata, Mappable. Обусловлено это тем, что в разных регионах и странах разные провайдеры имеют разное качество геоданных, и нельзя условно везде использовать Google. Все усложняется, когда для клиента в стране мы используем Google, тк считаем, что он дает лучшее качество адреса, а курьеры используют Yandex просто потому, что привыкли.
Особенности между геопровайдерами
- разные форматы ID;
- разные ID ведут к одному адресу (например, в саджесте и геокоде);
- разная детализация адреса;
- разное тегирование элементов адреса (в Yandex много промежуточных компонентов между регионом и населенным пунктом обозначается как district. У Google больше возможностей показать детали адреса с различающимися тегами).
В зависимости от региона – разное качество данных
- МЕ: у некоторых адресов в раскладке отсутствует населенный пункт, т.е. здания принадлежат уровню выше (например, региону), также из-за специфики региона;
- KZ (Google): многие дома не определяются, некорректная нумерация домов (на других картах адрес ведет в другое место), старые данные в наименованиях (с 2006 года уже есть новые сведения);
- АЕ (Google): новые районы города (Дубай) не определяются по подсказкам, обратному геокодированию;
- SA (Google): по некоторым областям со спутника видны пустыри в чертах населенного пункта, но на схеме оказывается район с домами. Медленная скорость актуализации геоданных;
- SA (Mappable): по тем же областям с пустырями есть соответствие спутника и схемы, т.е. зданий реально нет, там пусто;
- РФ (Dadata): точность ФИАС до улицы при наличии дома и координат до дома (при этом адрес реально существует) – по ФИАСу адреса восстановиться может только до улицы; можно придумывать названия домов, строений, корпусов – Dadata выводит такое как реальную подсказку, однако точность координат и ФИАСа падает уже, например, до улицы; в Dadata один тип улицы, в Яндексе другой (например, станция против улицы). У Dadata источником являются местные органы самоуправления, предоставляющие адресную информацию.
Лично для меня было новостью, что в AE, в частности в Дубае, у домов может не быть названий улиц, и это совершенно нормально. Все в основном ориентируются по номерам домов.
👍9😁3🔥2🤔1
Про профили технических менеджеров.
Наконец-то добрался до описания, что такое TeamLead и что такое тимлид тимлидов (ClusterLead) в рамках своего субъективного понимания этой проблемы. База, конечно же, взята из Avito playbook, тк считаю, что ничего лучше в этом плане на просторах рунета нет.
В свой playbook добавил личное представление о том, что такое TeamLead платформенной команды и ClusterLead платформенного кластера, в частности их связь с гильдиями.
#playbook
Наконец-то добрался до описания, что такое TeamLead и что такое тимлид тимлидов (ClusterLead) в рамках своего субъективного понимания этой проблемы. База, конечно же, взята из Avito playbook, тк считаю, что ничего лучше в этом плане на просторах рунета нет.
В свой playbook добавил личное представление о том, что такое TeamLead платформенной команды и ClusterLead платформенного кластера, в частности их связь с гильдиями.
#playbook
👍6🔥1
Про разницу отношения к работе.
Я сейчас нахожусь в отпуске в Австралии, приехал посетить русскую свадьбу друга.
На свадьбе было достаточно много представителей разных ИТ-профессий из разных концов планеты. Много говорили про разницу в подходах к работе, в том числе про work-life balance. В итоге я в который раз убеждаюсь, что русские или русскоговорящие работают совсем иначе. Мы работаем больше, у нас в основном ненормированный рабочий график, выход на работу в выходные не является нормой, но и не является каким-то табу.
Для примера, мой друг рассказал историю. Коллеге по работе надо было выйти в субботу, и менеджер этого сотрудника предложил ему личную помощь по дому, в том числе с детьми, чтобы тот смог поработать на выходных. Отношение к личному времени и к личному пространству совсем иное; не могу судить, плохо это или хорошо, но это так.
Другой знакомый рассказал, что его русскоговорящего коллегу поставили техменеджером на проекте, где команда была международной. В итоге этого менеджера сняли с проекта, так как он всех пушил, просил оценок, сроков и спрашивал за результат, на что команда была не готова и падала в обморок при слове deadline.
Понятно, что всё это вырвано из контекста и не отражает реальной картины, но это то, что лично я вижу и слышу от знакомых, которые уехали из РФ и работают за её пределами.
Я сейчас нахожусь в отпуске в Австралии, приехал посетить русскую свадьбу друга.
На свадьбе было достаточно много представителей разных ИТ-профессий из разных концов планеты. Много говорили про разницу в подходах к работе, в том числе про work-life balance. В итоге я в который раз убеждаюсь, что русские или русскоговорящие работают совсем иначе. Мы работаем больше, у нас в основном ненормированный рабочий график, выход на работу в выходные не является нормой, но и не является каким-то табу.
Для примера, мой друг рассказал историю. Коллеге по работе надо было выйти в субботу, и менеджер этого сотрудника предложил ему личную помощь по дому, в том числе с детьми, чтобы тот смог поработать на выходных. Отношение к личному времени и к личному пространству совсем иное; не могу судить, плохо это или хорошо, но это так.
Другой знакомый рассказал, что его русскоговорящего коллегу поставили техменеджером на проекте, где команда была международной. В итоге этого менеджера сняли с проекта, так как он всех пушил, просил оценок, сроков и спрашивал за результат, на что команда была не готова и падала в обморок при слове deadline.
Понятно, что всё это вырвано из контекста и не отражает реальной картины, но это то, что лично я вижу и слышу от знакомых, которые уехали из РФ и работают за её пределами.
👍17🔥5😁3
Про чувство собственности в IT.
Иногда я сталкиваюсь с риторикой: "это мой сервис/экран/продукт/компонент/... и я никого туда не пущу". Меня жутко бомбит, когда я слышу что-то подобное, тк не могу принять такую точку зрения.
На мой взгляд, есть несколько причин, почему так говорят.
Первая возможная причина — боязнь, что сломают. Люди дорожат своей проделанной работой и боятся, что кто-то со стороны может случайно ее испортить. Я понимаю такой аргумент, но все мы состоим из плоти и крови, все мы можем заболеть, и всех нас может сбить автобус. Закрывать все на себе — плохо, тк это значит, что после вас с высокой вероятностью все развалится. Вспоминаем историю Генри Форда про отпуск для своих топ-менеджеров.
Вторая возможная причина — боязнь вскрыть свою некомпетентность. Если кто-то яростно старается недопустить к своей работе кого-то, то стоит задуматься о качестве того, что не видно для внешнего наблюдателя. Если проделанная работа соответствует всем требованиям, то у сотрудника не будет повода бояться показать, что скрыто "под капотом". Может быть и так, что некомпетентности на самом деле нет, и на деле у сотрудника синдром самозванца.
Третья возможная причина — желание быть незаменимым. Пожалуй, это самый страшный кейс, тк если сотрудник осознанно хочет быть незаменимым, то с высокой вероятностью за этим прячутся не самые порядочные мотивы.
Иногда я сталкиваюсь с риторикой: "это мой сервис/экран/продукт/компонент/... и я никого туда не пущу". Меня жутко бомбит, когда я слышу что-то подобное, тк не могу принять такую точку зрения.
На мой взгляд, есть несколько причин, почему так говорят.
Первая возможная причина — боязнь, что сломают. Люди дорожат своей проделанной работой и боятся, что кто-то со стороны может случайно ее испортить. Я понимаю такой аргумент, но все мы состоим из плоти и крови, все мы можем заболеть, и всех нас может сбить автобус. Закрывать все на себе — плохо, тк это значит, что после вас с высокой вероятностью все развалится. Вспоминаем историю Генри Форда про отпуск для своих топ-менеджеров.
Вторая возможная причина — боязнь вскрыть свою некомпетентность. Если кто-то яростно старается недопустить к своей работе кого-то, то стоит задуматься о качестве того, что не видно для внешнего наблюдателя. Если проделанная работа соответствует всем требованиям, то у сотрудника не будет повода бояться показать, что скрыто "под капотом". Может быть и так, что некомпетентности на самом деле нет, и на деле у сотрудника синдром самозванца.
Третья возможная причина — желание быть незаменимым. Пожалуй, это самый страшный кейс, тк если сотрудник осознанно хочет быть незаменимым, то с высокой вероятностью за этим прячутся не самые порядочные мотивы.
👍9❤6🔥1
"А кто его будет обучать?" (с) ...
Я всегда жил и работал в парадигме, что лучшее обучение — это те боли и страдания, тот пот и кровь, через которые ты прошёл, решая задачи на рабочем месте. Курсы, менторы, наставники — это всё, конечно, хорошо, но ничто не закаляет так, как опыт, через который пришлось пройти в рамках решения реальных задач.
Существует модель обучения 70/20/10, её ещё иногда называют моделью обучения Дженнингса.
70% — решение рабочих задач. Работа с реальными кейсами и задачами, работа над собственными ошибками и формирование выводов.
20% — общение с коллегами. Получение обратной связи, обмен опытом с коллегами, работа с наставником или коучем.
10% — формальное обучение. Прохождение корпоративного обучения, курсов, вебинаров, тренингов и лекций.
С моделью обучения 70/20/10 совершенно необязательно, чтобы у линейного инженера был руководитель, который превосходит его в hard-навыках. В условиях современного интернета, когда количество бесплатных курсов/подкастов/конференций/семинаров превышает количество свободного времени, нуждаться в прямом наставнике, который должен обучать сотрудника, означает признание этого сотрудника в нежелании заниматься самообразованием. Например, если ваш инженер уровня middle+ просит помочь ему стать senior, просто дайте ему радикально более сложную задачу и позвольте ему справляться с ней самостоятельно.
Полезные ссылки:
- Модель «70:20:10» — доказанная практика, серьёзная теория или просто популярный миф?
- Как управлять талантами в большой корпорации
- Что такое модель обучения Дженнингса (70:20:10)
- 702010institute.com
P.S.: для джуна ситуация может быть чуть иной, тк джуну на старте всё-таки нужен наставник.
Я всегда жил и работал в парадигме, что лучшее обучение — это те боли и страдания, тот пот и кровь, через которые ты прошёл, решая задачи на рабочем месте. Курсы, менторы, наставники — это всё, конечно, хорошо, но ничто не закаляет так, как опыт, через который пришлось пройти в рамках решения реальных задач.
Существует модель обучения 70/20/10, её ещё иногда называют моделью обучения Дженнингса.
70% — решение рабочих задач. Работа с реальными кейсами и задачами, работа над собственными ошибками и формирование выводов.
20% — общение с коллегами. Получение обратной связи, обмен опытом с коллегами, работа с наставником или коучем.
10% — формальное обучение. Прохождение корпоративного обучения, курсов, вебинаров, тренингов и лекций.
С моделью обучения 70/20/10 совершенно необязательно, чтобы у линейного инженера был руководитель, который превосходит его в hard-навыках. В условиях современного интернета, когда количество бесплатных курсов/подкастов/конференций/семинаров превышает количество свободного времени, нуждаться в прямом наставнике, который должен обучать сотрудника, означает признание этого сотрудника в нежелании заниматься самообразованием. Например, если ваш инженер уровня middle+ просит помочь ему стать senior, просто дайте ему радикально более сложную задачу и позвольте ему справляться с ней самостоятельно.
Полезные ссылки:
- Модель «70:20:10» — доказанная практика, серьёзная теория или просто популярный миф?
- Как управлять талантами в большой корпорации
- Что такое модель обучения Дженнингса (70:20:10)
- 702010institute.com
P.S.: для джуна ситуация может быть чуть иной, тк джуну на старте всё-таки нужен наставник.
Wikipedia
70/20/10 model (learning and development)
learning and development model
👍12🔥7👏4
Про заметки.
Где вы храните заметки?
Я уже не помню, что было с самого-самого начала, но я до сих пор пользуюсь Evernote. Там у меня хранятся разные старые заметки, которые тащить в новые хранилища нет смысла, но периодически я туда возвращаюсь, чтобы что-то освежить в памяти.
Потом я познакомился с Notion, и это, конечно, был своего рода прорыв. Записная книжка контактов, вопросы для собеседований, личный и семейный бюджет, документы больничных анализов — всё-всё можно было круто организовать в Notion. Знаю, что многие компании его используют как аналог Jira/Confluence, тк его функциональность действительно может их заменить. Но, к сожалению, лично меня Notion заблокировал, когда началась история с санкциями и Cancel Culture.
А что сейчас? Сейчас я многие заметки веду в ТГ в Saved Messages (оно же избранное). Не знаю, почему так получилось, как-то само собой все заметки перетекли туда, особенно это стало актуально, когда ТГ сделал теги у сообщений и поиск по ним в Saved Messages.
Многие рекомендовали попробовать Obsidian, типа он как Notion, но лучше. Да? Стоит?
Где вы храните заметки?
Я уже не помню, что было с самого-самого начала, но я до сих пор пользуюсь Evernote. Там у меня хранятся разные старые заметки, которые тащить в новые хранилища нет смысла, но периодически я туда возвращаюсь, чтобы что-то освежить в памяти.
Потом я познакомился с Notion, и это, конечно, был своего рода прорыв. Записная книжка контактов, вопросы для собеседований, личный и семейный бюджет, документы больничных анализов — всё-всё можно было круто организовать в Notion. Знаю, что многие компании его используют как аналог Jira/Confluence, тк его функциональность действительно может их заменить. Но, к сожалению, лично меня Notion заблокировал, когда началась история с санкциями и Cancel Culture.
Если интересно погрузиться в этот дивный мир, то вот сравнения сервисов между собой.
- Универсальность против конкретики. Какой сервис заметок и баз знаний подойдет именно вам?
- ТОП-15 лучших приложений для заметок
- Лучшие приложения для заметок на 2024 год
А что сейчас? Сейчас я многие заметки веду в ТГ в Saved Messages (оно же избранное). Не знаю, почему так получилось, как-то само собой все заметки перетекли туда, особенно это стало актуально, когда ТГ сделал теги у сообщений и поиск по ним в Saved Messages.
Многие рекомендовали попробовать Obsidian, типа он как Notion, но лучше. Да? Стоит?
❤2👍2🔥1