Легаси-боли пост
А что болит-то, когда мы сталкиваемся с легаси?
Болит то, что когда ты вносишь правки - неизвестно где отвалится. К слову, мне неизвестно, существуют ли легаси-проекты с хорошим покрытием автотестами. Интуитивно это не очень очевидно.
Болит, что в проекте обычно есть какие-то специальные "галочки", сделанные неизвестно для кого и для чего. А иногда - сделанные ради удовлетворения какого-то одного человека со странными, непонятными запросами. И хочется эти "галочки" со связанной с ними логикой выпилить, но представитель заказачика исчез с радаров, и никто не может решить что делать с его требованиями. А бывает ещё хуже: особый представитель заказчика никуда не делся, но ушёл на повышение и, хотя формально присутствует, фактически к нему уже не пробиться.
Болит то, что порезаны бюджеты и рефакторинг, всё-таки присутствующий во время разработки, начисто прирезан.
Ну и, конечно, у разработчиков болят устаревшие технологии, с которыми не хочется возиться и в которых есть "тупые проблемы" и "много лишнего кода". Это моя любимая боль, потому что бизнес на такое морщит нос и говорит "так я вам за это и плачу деньги", что порождает ещё больше проблем, но никак не решений.
И, разумеется, проблемой становится отладка. Какие куски приложения с чем связаны, куда ходят - и в современных кластерах на Kubernetes выявить зависимости является нетривиальной задачей, а уж на устаревшем стеке технологий - и подавно.
Однако, мне всё-таки кажется, что зачастую страдающие от "невозможной отладки" просто недостаточно компетентны в инструментах отладки.
Возможно это хорошая ниша для создания обучающих курсов / докладов / статей: "инструменты отладки для адового легаси".
Ну и, конечно, болят философские вопросы в стиле:
- За что мне это?
- Когда всё это кончится?
- Если руководитель скинул на меня этот проект - он меня хочет уволить или наоборот считает, что я крутой?
Если у вас отзывается что-то из написанного выше - мужайтесь и знайте: вы не одиноки. Возможно у вас получится изменить ситуацию или своё отношение к ней. Главное - оставайтесь крутым профессионалом и хорошим человеком.
А что болит-то, когда мы сталкиваемся с легаси?
Болит то, что когда ты вносишь правки - неизвестно где отвалится. К слову, мне неизвестно, существуют ли легаси-проекты с хорошим покрытием автотестами. Интуитивно это не очень очевидно.
Болит, что в проекте обычно есть какие-то специальные "галочки", сделанные неизвестно для кого и для чего. А иногда - сделанные ради удовлетворения какого-то одного человека со странными, непонятными запросами. И хочется эти "галочки" со связанной с ними логикой выпилить, но представитель заказачика исчез с радаров, и никто не может решить что делать с его требованиями. А бывает ещё хуже: особый представитель заказчика никуда не делся, но ушёл на повышение и, хотя формально присутствует, фактически к нему уже не пробиться.
Болит то, что порезаны бюджеты и рефакторинг, всё-таки присутствующий во время разработки, начисто прирезан.
Ну и, конечно, у разработчиков болят устаревшие технологии, с которыми не хочется возиться и в которых есть "тупые проблемы" и "много лишнего кода". Это моя любимая боль, потому что бизнес на такое морщит нос и говорит "так я вам за это и плачу деньги", что порождает ещё больше проблем, но никак не решений.
И, разумеется, проблемой становится отладка. Какие куски приложения с чем связаны, куда ходят - и в современных кластерах на Kubernetes выявить зависимости является нетривиальной задачей, а уж на устаревшем стеке технологий - и подавно.
Однако, мне всё-таки кажется, что зачастую страдающие от "невозможной отладки" просто недостаточно компетентны в инструментах отладки.
Возможно это хорошая ниша для создания обучающих курсов / докладов / статей: "инструменты отладки для адового легаси".
Ну и, конечно, болят философские вопросы в стиле:
- За что мне это?
- Когда всё это кончится?
- Если руководитель скинул на меня этот проект - он меня хочет уволить или наоборот считает, что я крутой?
Если у вас отзывается что-то из написанного выше - мужайтесь и знайте: вы не одиноки. Возможно у вас получится изменить ситуацию или своё отношение к ней. Главное - оставайтесь крутым профессионалом и хорошим человеком.
хранения паролей пост
Свои более чем 500 паролей я храню в KeePass. Он имеет множество реализаций на все платформы (удивительно, но MacPass оказался лучше всего, плюс умеет мерджить два файла) и в общем-то закрывает стандартный набор проблем (шифрование хранилища, напоминания о необходимости сменить пароли, широкие возможности по сортировке и управлению).
Но у меня не один ноутбук. И изменения в список паролей не всегда вносятся при наличии интернета. А значит хранить контейнер с паролями, например, на Google Drive - не вариант: высок риск получить конфликт изменений и в итоге что-то продолбать.
Варианты были разные, в итоге я сформулировал мини-тз (https://news.1rj.ru/str/pet_project_ideas/9) на специальную железку, которая бы решила проблему. Очень хотелось одновременную работу с несколькими устройствами и кросплатформенность. Я перебрал кучу решений, пытался состыковать и так и так по-быстрому, чтобы не тратить месяц на написание низкоуровнего кода - без толку. Готовых кубиков нет.
А потом я наткнулся на https://www.sparkleshare.org/ и подумал: а зачем я так усложняю? Ведь для меня главное - это не продолбать ни одно изменение, а вовсе не "одновременная работа". Git для этого идеален! Штука простая как топор, вроде как даже не сложно пишется самостоятельно.
В общем, рекомендую попробовать. Учтите только, что SparkleShare не умеет использовать ssh-ключи из системы и генерирует свой, который надо вытащить и закинуть в свой гит.
Свои более чем 500 паролей я храню в KeePass. Он имеет множество реализаций на все платформы (удивительно, но MacPass оказался лучше всего, плюс умеет мерджить два файла) и в общем-то закрывает стандартный набор проблем (шифрование хранилища, напоминания о необходимости сменить пароли, широкие возможности по сортировке и управлению).
Но у меня не один ноутбук. И изменения в список паролей не всегда вносятся при наличии интернета. А значит хранить контейнер с паролями, например, на Google Drive - не вариант: высок риск получить конфликт изменений и в итоге что-то продолбать.
Варианты были разные, в итоге я сформулировал мини-тз (https://news.1rj.ru/str/pet_project_ideas/9) на специальную железку, которая бы решила проблему. Очень хотелось одновременную работу с несколькими устройствами и кросплатформенность. Я перебрал кучу решений, пытался состыковать и так и так по-быстрому, чтобы не тратить месяц на написание низкоуровнего кода - без толку. Готовых кубиков нет.
А потом я наткнулся на https://www.sparkleshare.org/ и подумал: а зачем я так усложняю? Ведь для меня главное - это не продолбать ни одно изменение, а вовсе не "одновременная работа". Git для этого идеален! Штука простая как топор, вроде как даже не сложно пишется самостоятельно.
В общем, рекомендую попробовать. Учтите только, что SparkleShare не умеет использовать ssh-ключи из системы и генерирует свой, который надо вытащить и закинуть в свой гит.
Переговоров с руководством про легаси пост
Когда легаси входит в жизнь разработчиков - они, как правило, начинают сопротивляться. По тысяче причин. И в какой-то момент, конечно, приходят к руководству с предложением переписать то или иное.
Ответ, как правило, шаблонный:
Это офигенный ответ по нескольким причинам:
- Он вроде правильный
- Он выглядит простым
- Самостоятельно разработчик просто не способен этого сделать. Как и его руководитель, не знающий техническую матчасть.
- Скорее всего, никто не способен этого сделать: такой расчёт - он скорее про статистику и гадание на кофейной гуще, чем про математику.
И ещё - сюрприз! - беда может быть в чём-то фундаментальном. И приходят не за тем, чтобы бизнес с барского плеча разрешил "пару часов в неделю потратить", а за чем-то серьёзным. Либо за неделей-другой, либо за серьёзной инвестицией хороших out of the box мозгов, которых разработчику не хватает.
Бизнес легко задавливает позицию разработчиков с своей доминирующей позиции. А разработчики голосуют ногами, увольняясь, либо применяют совсем коварное враньё и манипуляции. И то и другое - деструктивные шаблоны.
Чуть менее деструктивны "программисты со сломанным духом", которые остаются в легаси жить навсегда, руководствуясь тем, что их и тут неплохо кормят. Не осуждаю, но сочувствую.
Мне кажется, что есть только один путь победы над легаси - это путь самурая. Делай то, что должно и будь, что будет. Учись на ошибках, верь в себя и коллег на всех уровнях.
Не конструктивно играть в жертву обстоятельств в ключе "я просто получаю от этого проекта деньги" или "моё дело маленькое - закрывать тикеты". Это ваша жизнь, и она всегда содержит и некоторую долю легаси, и некоторое пространство для манёвра. И у вас всегда есть возможность задавать конструктивные и прямые вопросы о проблемах.
Когда легаси входит в жизнь разработчиков - они, как правило, начинают сопротивляться. По тысяче причин. И в какой-то момент, конечно, приходят к руководству с предложением переписать то или иное.
Ответ, как правило, шаблонный:
давай посчитаем окупаемость твоих правок. Мол, сколько денег уйдёт на переписывание, и какой профит мы от этого получим.Это офигенный ответ по нескольким причинам:
- Он вроде правильный
- Он выглядит простым
- Самостоятельно разработчик просто не способен этого сделать. Как и его руководитель, не знающий техническую матчасть.
- Скорее всего, никто не способен этого сделать: такой расчёт - он скорее про статистику и гадание на кофейной гуще, чем про математику.
И ещё - сюрприз! - беда может быть в чём-то фундаментальном. И приходят не за тем, чтобы бизнес с барского плеча разрешил "пару часов в неделю потратить", а за чем-то серьёзным. Либо за неделей-другой, либо за серьёзной инвестицией хороших out of the box мозгов, которых разработчику не хватает.
Бизнес легко задавливает позицию разработчиков с своей доминирующей позиции. А разработчики голосуют ногами, увольняясь, либо применяют совсем коварное враньё и манипуляции. И то и другое - деструктивные шаблоны.
Чуть менее деструктивны "программисты со сломанным духом", которые остаются в легаси жить навсегда, руководствуясь тем, что их и тут неплохо кормят. Не осуждаю, но сочувствую.
Мне кажется, что есть только один путь победы над легаси - это путь самурая. Делай то, что должно и будь, что будет. Учись на ошибках, верь в себя и коллег на всех уровнях.
Не конструктивно играть в жертву обстоятельств в ключе "я просто получаю от этого проекта деньги" или "моё дело маленькое - закрывать тикеты". Это ваша жизнь, и она всегда содержит и некоторую долю легаси, и некоторое пространство для манёвра. И у вас всегда есть возможность задавать конструктивные и прямые вопросы о проблемах.
Принятия решения о задачах пост
В ответ на предыдущий пост @MargaritaAndrianova прислала мне описание подхода к ранжированию задач, который в некоторых ситуациях может помочь разгрести хвосты по техдолгу:
https://docs.google.com/presentation/d/1-DIhhQj4RaeMGfTCF0AhegHt2x6lIvVQr083RQRgHXM/edit
И хотя он не отвечает на вопросы "как договориться с бизнесом, что пора всерьез начать разгребать легаси?" или "за что мне это?" - не могу не поделиться этой заготовкой. Возможно она наведет вас на мысли о своем подходе.
В ответ на предыдущий пост @MargaritaAndrianova прислала мне описание подхода к ранжированию задач, который в некоторых ситуациях может помочь разгрести хвосты по техдолгу:
https://docs.google.com/presentation/d/1-DIhhQj4RaeMGfTCF0AhegHt2x6lIvVQr083RQRgHXM/edit
И хотя он не отвечает на вопросы "как договориться с бизнесом, что пора всерьез начать разгребать легаси?" или "за что мне это?" - не могу не поделиться этой заготовкой. Возможно она наведет вас на мысли о своем подходе.
Google Docs
Ранжирование
Ранжирование задач Алгоритм определения порядка выполнения задач в сложных ситуациях
Расчётов пост
В одном из выпусков прекрасного комикса XKCD (https://xkcd.com/1205/, если быть точным) была чудесная таблица: сколько времени нужно, чтобы окупилась автоматизация.
Но она расчитана исходя из образа жизни автора (рабочие дни в году, рабочие часы, вот это всё).
Я сделал параметризованную версию этой таблицы для вас:
https://docs.google.com/spreadsheets/d/1YM0F7Fsviy5JWPqtfdZwCsyGYFJLT2umBsZ1SBu0ALM/edit?usp=sharing
В одном из выпусков прекрасного комикса XKCD (https://xkcd.com/1205/, если быть точным) была чудесная таблица: сколько времени нужно, чтобы окупилась автоматизация.
Но она расчитана исходя из образа жизни автора (рабочие дни в году, рабочие часы, вот это всё).
Я сделал параметризованную версию этой таблицы для вас:
https://docs.google.com/spreadsheets/d/1YM0F7Fsviy5JWPqtfdZwCsyGYFJLT2umBsZ1SBu0ALM/edit?usp=sharing
xkcd
Is It Worth the Time?
Онбординга пост
В субботу днём буду на DevOpsDays, общаться про технологический онбординг.
Кроме организационного онбординга (посадить на рабочее место, дать технику, познакомить с нужными людьми, придать ускорение в нужном направлении) есть ещё технологическая составляющая. Потому что, как ни крути, у всех есть своё легаси, свои особенные практики, свои соглашения о том как писать код, описывать задачи и участвовать в движухе типа планирования. И HR-ы, которые зачастую занимаются онбордингом, ничего в этом не понимают и по сути ответить на вопросы не могут.
А ещё веселее становится, когда все эти практики-технологии быстро эволюционируют и, например, физически невозможно нанять человека знающего весь необходимый набор технологий и инструментов. Надо людей прокачивать как можно быстрее, но как?
Окей, в теории всё просто: чек-листы, наставничество, парное программирование, ревью, записанные видео и статьи - но что из этого действительно работает на практике и почему? А что - не работает?
Я, например, пробовал организовывать в командах учебные задачи для новичков в рамках "курса молодого бойца". Идея казалась прекрасной: снять нагрузку с тимлида, чтобы инженер в "учебных", "лайтовых" условиях мог освоить базовые вещи и затем идти в одну из команд и доучиваться "в бою".
Но на практике:
а) снятие нагрузки с тимлидов оказалось порочной затеей, так как они полностью отстранились и стали рассчитывать на чудо, не желая даже участвовать в детализации курса;
б) базовые, фундаментальные вещи и приёмы в разных командах оказались разными. И команды отстранялись от попыток их синхронизировать.
в) оказалось, что курса молодого бойца даже в одну неделю не хватает на ощутимый результат: объём информации и знаний слишком большой. А тащить человека дольше без погружения в реальную практику выглядело полным бредом.
🤔 возможно, вы знаете как обойти эти проблемы. У меня, в свою очередь, есть другие истории, которые взлетели и дали отдачу, не смотря на встреченные подводные камни.
Не хочется превращать пост в простыню. Лучше поделимся своей болью интерактивно на митапе в субботу или в канале @KnowledgeConfChannel.
В субботу днём буду на DevOpsDays, общаться про технологический онбординг.
Кроме организационного онбординга (посадить на рабочее место, дать технику, познакомить с нужными людьми, придать ускорение в нужном направлении) есть ещё технологическая составляющая. Потому что, как ни крути, у всех есть своё легаси, свои особенные практики, свои соглашения о том как писать код, описывать задачи и участвовать в движухе типа планирования. И HR-ы, которые зачастую занимаются онбордингом, ничего в этом не понимают и по сути ответить на вопросы не могут.
А ещё веселее становится, когда все эти практики-технологии быстро эволюционируют и, например, физически невозможно нанять человека знающего весь необходимый набор технологий и инструментов. Надо людей прокачивать как можно быстрее, но как?
Окей, в теории всё просто: чек-листы, наставничество, парное программирование, ревью, записанные видео и статьи - но что из этого действительно работает на практике и почему? А что - не работает?
Я, например, пробовал организовывать в командах учебные задачи для новичков в рамках "курса молодого бойца". Идея казалась прекрасной: снять нагрузку с тимлида, чтобы инженер в "учебных", "лайтовых" условиях мог освоить базовые вещи и затем идти в одну из команд и доучиваться "в бою".
Но на практике:
а) снятие нагрузки с тимлидов оказалось порочной затеей, так как они полностью отстранились и стали рассчитывать на чудо, не желая даже участвовать в детализации курса;
б) базовые, фундаментальные вещи и приёмы в разных командах оказались разными. И команды отстранялись от попыток их синхронизировать.
в) оказалось, что курса молодого бойца даже в одну неделю не хватает на ощутимый результат: объём информации и знаний слишком большой. А тащить человека дольше без погружения в реальную практику выглядело полным бредом.
🤔 возможно, вы знаете как обойти эти проблемы. У меня, в свою очередь, есть другие истории, которые взлетели и дали отдачу, не смотря на встреченные подводные камни.
Не хочется превращать пост в простыню. Лучше поделимся своей болью интерактивно на митапе в субботу или в канале @KnowledgeConfChannel.
JetBrains Space
Мне пришёл доступ в Space. Если вы ещё не слышали про него - посмотрите https://www.jetbrains.com/space/ - там весьма неплохо описан концепт. Далее - мои субъективные впечатления.
В главном меню есть пункты: единый поиск (открывающийся по хоткею, не умеет в русскую морфологию и уж тем более семантику), чаты и плюс-минус "стандартный" набор для управления проектами: гит репы, issues, работа над merge request-ами и отдельно вынесенные Checklists проекта.
Мне пришёл доступ в Space. Если вы ещё не слышали про него - посмотрите https://www.jetbrains.com/space/ - там весьма неплохо описан концепт. Далее - мои субъективные впечатления.
В главном меню есть пункты: единый поиск (открывающийся по хоткею, не умеет в русскую морфологию и уж тем более семантику), чаты и плюс-минус "стандартный" набор для управления проектами: гит репы, issues, работа над merge request-ами и отдельно вынесенные Checklists проекта.
Отдельно выделено внимание для блогов. Платформа прямо призывает тебя сразу начать писать статьи.
Это реально интересная идея, чтобы хакнуть людей и сподвигнуть их написать что-нибудь.
Конечно, это не отменяет необходимости в обучении людей писать правильно и использовать этот инструмент, но, честно говоря, это самое вменяемое, что я видел.
Это реально интересная идея, чтобы хакнуть людей и сподвигнуть их написать что-нибудь.
Конечно, это не отменяет необходимости в обучении людей писать правильно и использовать этот инструмент, но, честно говоря, это самое вменяемое, что я видел.
Отдельного внимания заслуживают чаты.
"Зачем делать чаты в 2019-ом году?" - задавался я вопросом, когда читал описание Space.
А вот зачем: на статьи автоматом создаются чаты, на мердж реквесты создаются чаты, и вообще выглядит, как будто коммуникации грамотно разруливаются на те предметы, которые появляются в базе знаний.
Отдельно доставило автоматически созданный чат "Absense" - для оповещения людей об отсутствии. У нас есть нечто подобное, но мы работаем с отсутствиями вручную. Для распределённой команды, например, такой чат весьма необходим, здорово, что такие мелочи сразу идут продуманными из коробки.
"Зачем делать чаты в 2019-ом году?" - задавался я вопросом, когда читал описание Space.
А вот зачем: на статьи автоматом создаются чаты, на мердж реквесты создаются чаты, и вообще выглядит, как будто коммуникации грамотно разруливаются на те предметы, которые появляются в базе знаний.
Отдельно доставило автоматически созданный чат "Absense" - для оповещения людей об отсутствии. У нас есть нечто подобное, но мы работаем с отсутствиями вручную. Для распределённой команды, например, такой чат весьма необходим, здорово, что такие мелочи сразу идут продуманными из коробки.
Конечно, я совсем не коснулся вопросов работы с кодом, сборки и доставки. Потыкаюсь ближе к выходным, но поверхностно выглядит функционально.
Уютный IT адочек
Онбординга пост В субботу днём буду на DevOpsDays, общаться про технологический онбординг. Кроме организационного онбординга (посадить на рабочее место, дать технику, познакомить с нужными людьми, придать ускорение в нужном направлении) есть ещё технологическая…
Технологический онбординг - это погружение в проекты, технологии и специфические соглашения, которые приняты в команде: как писать код, почему используется PostgreSQL вместо MySQL, какие сервисы используются в проекте и как они связаны между собой и другое.
Есть компании, в которых делают полноценный курс новичка: наборы видеозаписей, отвечающих на самые частые вопросы, статьи, обучалки - но как бы то ни было, поддерживать подобный курс очень дорого и тяжело.
Все задают вопрос "как принять решение - стоит какую-то информацию фиксировать в виде доки или нет?" - но внятного ответа мне пока неизвестно. И есть впечатление, что хорошего ответа ни у кого нет.
Есть и ключевая проблема с подобным "курсом новичка" - большой объём материала невозможно запихнуть в голову мгновенно. Всего лишь какие-то 6 часов видео убьют любой мозг, как ни крути.
Таким образом, онбординг следует по смыслу разделять на две части:
- минимальную информацию, которую нужно донести за 2..3 дня максимум.
- общие меры, направленные на улучшение обмена знаниями в команде, которые будут помогать онбордящемуся в первые 2..3 месяца.
Минимальная информация - это строго то, что вызывает реальную боль у новичков. Выявить её очень просто - вести их в течение первой недели-полутора, присутствовать на всех ключевых встречах с человеком, работать в режиме парного программирования и проверять его прогресс.
Общие меры - это, прежде всего, наставничество и создание правильной культуры, подразумевающей качественный фидбэк, свободу в задавании вопросов и другое - но это сами по себе обширные темы, которые надо рассматривать отдельно.
Есть компании, в которых делают полноценный курс новичка: наборы видеозаписей, отвечающих на самые частые вопросы, статьи, обучалки - но как бы то ни было, поддерживать подобный курс очень дорого и тяжело.
Все задают вопрос "как принять решение - стоит какую-то информацию фиксировать в виде доки или нет?" - но внятного ответа мне пока неизвестно. И есть впечатление, что хорошего ответа ни у кого нет.
Есть и ключевая проблема с подобным "курсом новичка" - большой объём материала невозможно запихнуть в голову мгновенно. Всего лишь какие-то 6 часов видео убьют любой мозг, как ни крути.
Таким образом, онбординг следует по смыслу разделять на две части:
- минимальную информацию, которую нужно донести за 2..3 дня максимум.
- общие меры, направленные на улучшение обмена знаниями в команде, которые будут помогать онбордящемуся в первые 2..3 месяца.
Минимальная информация - это строго то, что вызывает реальную боль у новичков. Выявить её очень просто - вести их в течение первой недели-полутора, присутствовать на всех ключевых встречах с человеком, работать в режиме парного программирования и проверять его прогресс.
Общие меры - это, прежде всего, наставничество и создание правильной культуры, подразумевающей качественный фидбэк, свободу в задавании вопросов и другое - но это сами по себе обширные темы, которые надо рассматривать отдельно.
Есть альтернативный подход к уменьшению времени онбординга. Радикальный.
Я его не пробовал, но на митапе делились своими соображениями:
нужно как можно быстрее выявлять "проблемных" и "не способных" людей и увольнять их.
Сюда входит:
- приём "тестового дня"
- более лучшая проработка требований к вакансии вместе с HR-ом
- как можно более раннее принятие решения о прохождении испытательного срока
Формально, так тоже можно уменьшить среднее время онбординга.
Тестовый день
Коллеги поделились впечатлением, что в условиях, когда ты не можешь дать человеку доступ к инфраструктуре, хорошо заходит исследовательское задание в качестве оплачиваемого "тестового дня". То есть потенциальному сотруднику даётся общая, толком не изученная проблема, и предлагается разобраться самостоятельно и написать решение.
Это удобно, так как результаты работы в такой ситуации не жалко выкинуть (если они плохие), и в то же время можно найти человека-сокровище.
Проработка требований
Казалось бы, очевидный совет, но на самом деле ноги многих проблем с онбордингом, похоже, растут из-за отстустствия нормального взаимодействия произвоства и найма.
Проработка требований к вакансиям, обсуждение источников и подходов к найму, поиски способов улучшить жизнь HR-а - это хороший повод начать дружить во имя общей цели.
Конечно, бывают ситуации беспросветные, когда конфликт на уровне руководства. Мне кажется, что в таких ситуациях надо искать другую компанию для строительства карьеры, но это не точно.
Ускорение принятия решения об испытательном
Есть ощущение, что на самом деле тимлиды с опытом способны достаточно точно понять есть толк от человека или нет задолго до окончания испытательного. Если они действительно зададутся такой целью, вылезет и осознается много нюансов касательно требований и онбординг естественным образом начнёт проистекать гораздо шустрее, ибо пятки начнут подгорать.
Однако, вопрос о том, как действительно поставить такую цель остаётся открытым и зависит от специфики компании.
Я его не пробовал, но на митапе делились своими соображениями:
нужно как можно быстрее выявлять "проблемных" и "не способных" людей и увольнять их.
Сюда входит:
- приём "тестового дня"
- более лучшая проработка требований к вакансии вместе с HR-ом
- как можно более раннее принятие решения о прохождении испытательного срока
Формально, так тоже можно уменьшить среднее время онбординга.
Тестовый день
Коллеги поделились впечатлением, что в условиях, когда ты не можешь дать человеку доступ к инфраструктуре, хорошо заходит исследовательское задание в качестве оплачиваемого "тестового дня". То есть потенциальному сотруднику даётся общая, толком не изученная проблема, и предлагается разобраться самостоятельно и написать решение.
Это удобно, так как результаты работы в такой ситуации не жалко выкинуть (если они плохие), и в то же время можно найти человека-сокровище.
Проработка требований
Казалось бы, очевидный совет, но на самом деле ноги многих проблем с онбордингом, похоже, растут из-за отстустствия нормального взаимодействия произвоства и найма.
Проработка требований к вакансиям, обсуждение источников и подходов к найму, поиски способов улучшить жизнь HR-а - это хороший повод начать дружить во имя общей цели.
Конечно, бывают ситуации беспросветные, когда конфликт на уровне руководства. Мне кажется, что в таких ситуациях надо искать другую компанию для строительства карьеры, но это не точно.
Ускорение принятия решения об испытательном
Есть ощущение, что на самом деле тимлиды с опытом способны достаточно точно понять есть толк от человека или нет задолго до окончания испытательного. Если они действительно зададутся такой целью, вылезет и осознается много нюансов касательно требований и онбординг естественным образом начнёт проистекать гораздо шустрее, ибо пятки начнут подгорать.
Однако, вопрос о том, как действительно поставить такую цель остаётся открытым и зависит от специфики компании.
Forwarded from запуск завтра
Первый эпизод по новостному поводу, про nginx! 90% эпизода — про технологии: что такое Nginx, почему и где он используется, что в нем нравится, а что — бесит. 10% — эмоции, получилось жарко и даже немного стыдно.
А ещё это первый эпизод, в котором два гостя, с которыми до записи я не был знаком даже шапочно.
Гости: Данила Штань, технический директор Яндекс.Вертикалей (Авто.ру, Яндекс.Недвижимость и Яндекс.Работа) и Дима Столяров — технический директор крупного русского devops аутсорсера Фланта.
Го слушать, мы создали: Apple, Google, Castbox, Spotify, Яндекс, Overcast, веб-версия.
А ещё это первый эпизод, в котором два гостя, с которыми до записи я не был знаком даже шапочно.
Гости: Данила Штань, технический директор Яндекс.Вертикалей (Авто.ру, Яндекс.Недвижимость и Яндекс.Работа) и Дима Столяров — технический директор крупного русского devops аутсорсера Фланта.
Го слушать, мы создали: Apple, Google, Castbox, Spotify, Яндекс, Overcast, веб-версия.
Родион на пальцах объяснил, что такое управление знаниями и почему это не дока
https://www.youtube.com/watch?v=CZnuwrFIEi4
👍
https://www.youtube.com/watch?v=CZnuwrFIEi4
👍
YouTube
Родион Нагорнов, Лаборатория Касперского. Управление знаниями в ИТ: при чем тут DevOps и привычки?
Что такое знания в компании?
– Нет, это не документация
Участвуете ли вы в процессах управления знаниями в своей работе?
– Каждый день.
Есть ли разница между базой знаний и системой управления знаниями?
– Для меня есть.
Дружат ли управление знаниями…
– Нет, это не документация
Участвуете ли вы в процессах управления знаниями в своей работе?
– Каждый день.
Есть ли разница между базой знаний и системой управления знаниями?
– Для меня есть.
Дружат ли управление знаниями…
Воспользовался выходными, чтобы перечитать закладки со статьями и наткнулся на прекрасное.
https://vc.ru/hr/95754-razvitie-i-proval-regulyarnogo-menedzhmenta-v-it
Статья Максима Цепкова с очень хорошим историческим обзором и аналитикой. Даже проглядывание её по диагонали даёт вам +10 к интеллекту и +5 к выносливости.
https://vc.ru/hr/95754-razvitie-i-proval-regulyarnogo-menedzhmenta-v-it
Статья Максима Цепкова с очень хорошим историческим обзором и аналитикой. Даже проглядывание её по диагонали даёт вам +10 к интеллекту и +5 к выносливости.
Forwarded from DocOps
Смотрите, что у нас получилось: https://imagineui.github.io
Рисовалка мокапов из кода работает в браузере, есть несколько примеров и можно что-то новое задизайнить. Есть и CLI-приложение, пока что не упакованное, но можно собрать и запустить из кода, инструкция там же. Есть базовая документация на английском и русском.
Пробуйте, пишите фидбек, присылайте исходники своих мокапов :)
А ещё, если вам проект понравился, поставьте нам звезду на гитхабе: https://github.com/imagineui/imagineui
Рисовалка мокапов из кода работает в браузере, есть несколько примеров и можно что-то новое задизайнить. Есть и CLI-приложение, пока что не упакованное, но можно собрать и запустить из кода, инструкция там же. Есть базовая документация на английском и русском.
Пробуйте, пишите фидбек, присылайте исходники своих мокапов :)
А ещё, если вам проект понравился, поставьте нам звезду на гитхабе: https://github.com/imagineui/imagineui
Mobile Page: "Landing"
Block: Navigation
One row
"ImagineUI"
Link to Sandbox
Link to GitHub
Link to Docs
Main Block: Demo
Header "ImagineUI"
One row
Image example source code
Image example mockup
Block: Subnoscription
Header Subscribe to our newsletter
Input "full name"
Input e-mail
Button "Subscribe"
"or try out the alpha-version:"
One row
Button Sandbox
Button CLI
Это божественная штука, которая позволяет описывать мокапы ямл-подобным синтаксисом. А значит - описание интерфейсов можно хранить в доке, в гите, и по-человечески с ним работать.
Утилиту можно как запускать локально, так и использовать онлайн-sandbox.
Я мечтал о такой утилите более пяти лет. Спасибо @docops!
Утилиту можно как запускать локально, так и использовать онлайн-sandbox.
Я мечтал о такой утилите более пяти лет. Спасибо @docops!
Выступлений на конференциях пост
Общался со старым знакомым тему конференций и услышал интересный тезис: "Ой, мы пробовали, но как-то не вдохновило. Всё время одни и те же лица, а большая часть выступлений - ни о чём".
Меня тоже когда-то бомбило по похожему поводу, но потом я попал в программный комитет KnowledgeConf и узнал много нового "с другой стороны баррикад".
Чтобы выступления получились хорошими - нужно, чтобы спикер обладал хорошей компетенцией и хотя бы чуть-чуть умел связно выстраивать мысли. Причём второе не так критично, так как:
- крупные конференции помогают коучинговой поддержкой
- на рынке есть тренеры, которые за не такую большую деньгу помогают довести презентацию до ума
- есть море тренеров по публичным выступлениям, это сформировавшийся рынок
- даже если просто рассказать свою историю раз 5-10 разным группам людей и услышать их фидбэк - само собой меняешься к лучшему
Проблема, конечно, с компетентными людьми. Много потраченного времени не означает компетентность. И заёбанность тоже не равна опыту.
Не мало приходящих выступать обладают энергией и желанием блестнуть, но при этом если копнуть "вглубь" — не способны по существу ответить или даже признать свою некомпетентность в этом разрезе. И мне особенно больно такое видеть.
А тех, кто съел пуд соли, понимает границы своей компетентности и приходит с докладом — единицы.
Если вы из таких — не сидите ровно на попе, пожалуйста. Сейчас как раз начинается новый сезон конференций. Вы нужны программным комитетам.
Общался со старым знакомым тему конференций и услышал интересный тезис: "Ой, мы пробовали, но как-то не вдохновило. Всё время одни и те же лица, а большая часть выступлений - ни о чём".
Меня тоже когда-то бомбило по похожему поводу, но потом я попал в программный комитет KnowledgeConf и узнал много нового "с другой стороны баррикад".
Чтобы выступления получились хорошими - нужно, чтобы спикер обладал хорошей компетенцией и хотя бы чуть-чуть умел связно выстраивать мысли. Причём второе не так критично, так как:
- крупные конференции помогают коучинговой поддержкой
- на рынке есть тренеры, которые за не такую большую деньгу помогают довести презентацию до ума
- есть море тренеров по публичным выступлениям, это сформировавшийся рынок
- даже если просто рассказать свою историю раз 5-10 разным группам людей и услышать их фидбэк - само собой меняешься к лучшему
Проблема, конечно, с компетентными людьми. Много потраченного времени не означает компетентность. И заёбанность тоже не равна опыту.
Не мало приходящих выступать обладают энергией и желанием блестнуть, но при этом если копнуть "вглубь" — не способны по существу ответить или даже признать свою некомпетентность в этом разрезе. И мне особенно больно такое видеть.
А тех, кто съел пуд соли, понимает границы своей компетентности и приходит с докладом — единицы.
Если вы из таких — не сидите ровно на попе, пожалуйста. Сейчас как раз начинается новый сезон конференций. Вы нужны программным комитетам.
Не принятых докладов пост
В предудыщем посте я чуток слукавил: типа всё так просто, подайся с докладом и тебя оторвут с руками и ногами. На самом деле есть одна важная фигня: тренды. Слово "тренды" граничит с матерным, поэтому сейчас поясню.
В некоторые года случается бум публикаций и выступлений на определённую тему. Например, в 2018 и 2019 я заметил бум публикаций про Performance Review и про OKR. А значит к 2020-му про эти темы сказано настолько много, что сложно добавить что-то новое, о чём ещё не слышали. И у программных комитетов скорее всего будет скепсис к таким докладам.
Эти тренды так или иначе чувствуют члены каждого ПК и могут дать комментарии. Мало кто пользуется опцией "зайти на сайт конференции, посмореть кто в ПК и потом просто постучаться к человеку на посоветоваться на 20 минут", а она вполне себе существует.
KnowledgeConf в прошлом году публиковала (https://habr.com/ru/company/oleg-bunin/blog/440746/) информацию о трендах на Хабре. В этом году мы проводим уже более глубокий анализ и уже очевидно, что информации об онбординге очень много, а вот о реальном опыте привития культуры обмена знаниями, технологиях и инструментах (кроме попсовых чатботов), вытаскивании команд и проектов из тяжёлых ситуаций (отсутствие каких-либо знаний в "прилетевших" легаси-проектах, жуткая разобщённость подразделений, победабезопасников паранойиков над здравым смыслом и т.п.) или банальном решении истории вида "у нас есть вики, но в неё никто не пишет" — почти нет.
Что делать, если твой доклад опоздал с трендом?
- Можно попробовать податься на другую конференцию. Всегда есть люди, которые опоздали, не услышали, были заняты или находятся в другом информационном поле. В 2020 году по-прежнему есть люди, которые не знают про модели "Родитель-Взрослый-Ребёнок" и люди, для которых является откровением аутотренинг. И про Domain Driven Development многие, кому это нужно, не знают. Это нормально.
- Можно успокоиться и попробовать блестнуть с чем-то другим. Возможно для этого понадобится поменять что-то в своей работе и добиться новых результатов, а текущие достижения зафиксировать и просто использовать как хорошую часть резюме.
- Можно копнуть реально глубоко, изучить существующую матчасть, и попробовать достичь выдающихся результатов. Быть может вы — будущий Лобачевский, который изогнёт ткань привычного пространства.
В предудыщем посте я чуток слукавил: типа всё так просто, подайся с докладом и тебя оторвут с руками и ногами. На самом деле есть одна важная фигня: тренды. Слово "тренды" граничит с матерным, поэтому сейчас поясню.
В некоторые года случается бум публикаций и выступлений на определённую тему. Например, в 2018 и 2019 я заметил бум публикаций про Performance Review и про OKR. А значит к 2020-му про эти темы сказано настолько много, что сложно добавить что-то новое, о чём ещё не слышали. И у программных комитетов скорее всего будет скепсис к таким докладам.
Эти тренды так или иначе чувствуют члены каждого ПК и могут дать комментарии. Мало кто пользуется опцией "зайти на сайт конференции, посмореть кто в ПК и потом просто постучаться к человеку на посоветоваться на 20 минут", а она вполне себе существует.
KnowledgeConf в прошлом году публиковала (https://habr.com/ru/company/oleg-bunin/blog/440746/) информацию о трендах на Хабре. В этом году мы проводим уже более глубокий анализ и уже очевидно, что информации об онбординге очень много, а вот о реальном опыте привития культуры обмена знаниями, технологиях и инструментах (кроме попсовых чатботов), вытаскивании команд и проектов из тяжёлых ситуаций (отсутствие каких-либо знаний в "прилетевших" легаси-проектах, жуткая разобщённость подразделений, победа
Что делать, если твой доклад опоздал с трендом?
- Можно попробовать податься на другую конференцию. Всегда есть люди, которые опоздали, не услышали, были заняты или находятся в другом информационном поле. В 2020 году по-прежнему есть люди, которые не знают про модели "Родитель-Взрослый-Ребёнок" и люди, для которых является откровением аутотренинг. И про Domain Driven Development многие, кому это нужно, не знают. Это нормально.
- Можно успокоиться и попробовать блестнуть с чем-то другим. Возможно для этого понадобится поменять что-то в своей работе и добиться новых результатов, а текущие достижения зафиксировать и просто использовать как хорошую часть резюме.
- Можно копнуть реально глубоко, изучить существующую матчасть, и попробовать достичь выдающихся результатов. Быть может вы — будущий Лобачевский, который изогнёт ткань привычного пространства.