Тимлид Леонид
7.99K subscribers
382 photos
7 videos
1 file
194 links
Канал команды Skyeng Tech. Рассказываем про внутреннюю кухню, тимлидство, кейсы из жизни разработки и QA, а еще делимся статьями и докладами ребят.
Download Telegram
Для комфортной работы команде требуются HR-менеджеры, способные организовать работу и поддерживать моральный дух. Для большой компании это сложная задача. Чат-боты помогают автоматизировать рутинные HR-процессы, улучшают атмосферу и снижают нагрузку на менеджеров. 
Вот некоторые сценарии использования чат-ботов:
• Планирование собеседований
• Онбординг новичков
• Оценка навыков сотрудников
• Создание PDP: персональных планов развития

Подробнее о возможностях чат-ботов в HR-среде: https://bit.ly/2CDZYbt
Ребята, привет!

Одна из моих любимых книг — "Принципы" Рэя Далио. Прочитав её, ты сэкономишь 42 года, которые Рэй потратил на формулирование своих принципов. Обычно, читая книгу, я выписываю 5-10 полезных идей. Для этой же книги я выписал 45!

Принципы, которые начал применять:
• Абсолютная честность и предельная прозрачность. Я уменьшил количество приватных чатов до минимума, делюсь секретными файликами и объясняю логику решений своей команде.
• Непредубежденность. Мне очень не хватало этого слова. Эго — барьер при принятии решений. Непредубежденность стала одним из критериев нашего 360 review.
• Сформулировать принципы принятия решений. Я сформулировал собственные принципы и мы уже сделали это в команде биллинга: записали принципы работы и технические принципы. В ближайшее время скину их в этот канал.

Понравившиеся идеи:
• Нельзя получить абсолютно всё. Но можно получить гораздо больше, чем нужно для счастья.
• Когда нанимаешь водопроводчика — нужен первоклассный водопроводчик, а не любой подходящий водопроводчик.

Совет будущему читателю: хочешь получить 80% результата за наименьшее время — прочитай только "Жизненные принципы". Первая глава с биографией интересна, но не так полезна. А третья — содержит мало новой информации.

Если прочитал или начал читать "Принципы" — обязательно напиши свой отзыв к моему посту в facebook https://goo.gl/s95bAP
Ребята, привет! Вдохновившись книгой Рэя Далио "Принципы", я решил провести эксперимент и сформулировать принципы для команды биллинга.

Начну сразу с принятых принципов: https://hackmd.io/s/r1PmSwIw4

Зачем
• У меня есть видение, какой должна быть команда. Записанное на бумаге обретает особую силу, а чёткие формулировки помогают передавать видение команде.
• Руководствоваться принципами при принятии решений. Помогает избежать споров об одном и том же. Не нужен руководитель для разрешения конфликтов.
• Выявить и разрешить противоречия. Когда голосовали, обнаружили, что на многие вещи смотрим по-разному. Например, самым спорным оказался принцип "Личная жизнь важнее, чем Skyeng".

Как принимали
• Я накидал черновик из 10 принципов, которые считаю самыми важными.
• Предложил команде дополнить список: получилось аж 43 штуки!
• Провели голосование и оценили каждый принцип по 3 критериям: конкретность, согласие с принципом, важность.
• Затем я создал пулл-реквест, где мы уточняли формулировки, обсуждали, спорили, голосовали. В итоге получили 12 принципов работы и 15 технических принципов. Пулл-реквест аппрувнул каждый член комапнды.

Что теперь
Теперь посмотрим, как это работает: или мы будем регулярно использовать принципы или репозиторий с ними затухнет, одно из двух. Пока договорились, что принципы могут меняться: достаточно сделать новый пулл-реквест и получить аппрув от команды. Через полгодика поделюсь новостями: прижилось или нет.
Ребята, всем привет! Организаторы #TeamLeadConf2019 разрешили мне выложить секретное Unlisted видео моего выступления на TeamLeadConf. Мотивация, делегирование и автоматизация: рецепт создания суперкоманды — https://youtu.be/ojRZNSSr4I8

Обязательно:
• смотри на скорости 2x, экономь время
• в комментах на fb пиши свои лайфхаки и техники по теме — https://goo.gl/cAsnxA
• кинь ссылку знакомым разработчикам и тимлидам, если понравилось
Media is too big
VIEW IN TELEGRAM
26 и 27 апреля буду на Стачке: IT-конференции, где ежегодно собирается 5000 разработчиков. Не верится? Мне тоже, поэтому поеду проверить. Если тоже приедешь проверять, приходи на мой доклад Мотивация метриками: как подружить разработку и бизнес. Увидимся в Ульяновске.
Улучшить производительность поможет правильная структура дня. Мы привыкли к 8-часовому рабочему дню, но проблема такого подхода — отсутствие запланированных промежутков отдыха.

Ключ к эффективной работе — чередование работы и отдыха. Исследователи из Draugiem Group выяснили, что люди, практикующие короткие перерывы работают продуктивнее. Оптимальный график — 52 минуты работы, а затем 17 минут перерыва. Перерыв лучше провести отдалившись от работы: почитать или прогуляться. В таком случае ты получишь ещё час энергии для работы.

Список советов:
• Разбей день на часовые интервалы.
• Не обманывай себя. Работай сфокусированно в отведенное время. На Facebook, YouTube и почту — запланированный отдых.
• Ещё лучше вместо соцсетей заняться ходьбой, чтением или общением. Это самые подходящие методы перезарядки.
• Не жди, пока организм попросит сделать перерыв. Если ты устал, то уже пропустил момент. Следуй заранее составленному графику.
This media is not supported in your browser
VIEW IN TELEGRAM
Пробую новый формат: короткие видео вместо коротких постов. Первое видео — Как оценить ресурсы команды. Если у тебя есть фидбек по формату или вопросы по сути — пиши в личку @ax8080.

UPD. Всем спасибо за фидбек о размере файла. Уменьшил, перезалил!
Нашёл интересную статью о проведении 1:1. Автор утверждает, что стоит тратить 30 минут в неделю на каждого члена команды. Еще 15 минут заложить на запись итогов встречи. Для каждого человека создать отдельный канал в Slack: вести заметки и назначать следующие встречи.

• Это не встречи по статусу задач. Статусы — на Kanban или Scrum доске.
• На встрече выясни цели человека и определи, как текущая работа может ему в них помочь.
• Темы для обсуждения должны быть важными и даже жесткими.
• Важно выяснить, понимает ли собеседник пользу 1:1. Что конкретно он считает полезным, а что нет.
• По итогам сессии вы должны прийти к четким результатам, которые станут основой для следующей встречи.

Как понять, что встречи полезны?
• Члены команды говорят об этом.
• У каждого есть чёткое понимание, как и куда двигаться.
• Команда мотивированна и хочет достичь цели.

Чуть позже поделюсь своим опытом проведения 1:1 — принципами, техниками и списком вопросов. Если у тебя есть интересные статьи, о том как проводить 1:1 — скидывай в личку @ax8080. Сделаю подборку и выложу!
Приходилось ли тебе получать трешовые задачи от бизнеса? Что я подразумеваю под "трешем": непонятные, ненужные, плохо оформленные задачи. Под действием "О, идея! Хочу!" продакт-менеджеры иногда немедленно создают тикеты в JIRA. Мы хотели это остановить и увидеть проработанные задачи, удовлетворяющие санитарному минимуму. После раздумий сделали специальный чеклист постановки задач в разработку: https://hackmd.io/s/r1nP8C3uV

Пара замечаний:
• Мы не строим препятствий и бюрократию на пути денежных задач бизнеса. Цель — облегчить взаимодействие с разработчиками и не тратить время на лишнюю работу.
• Мы не контролируем жёстко соблюдение чеклиста. Одно только наличие чеклиста в Confluence улучшило качество задач.
❤1
Привет! Если ты работаешь удалённо или думал начать — тебе может быть интересно, как мы делаем это в Skyeng. Об основных подходах я рассказал в интервью в Oh my code — https://youtu.be/R5aG_OUMVuk. Как обычно, советую смотреть на скорости 2x и только первые 20 минут: дальше я пытаюсь писать код и это ужасно.

Если знаешь крутые книги, статьи, видео и практики по удалённой работе — скидывай в личку @ax8080. Попозже сделаю подборку материалов и ответы на частые вопросы!
Ребята, давно не писал о книгах. Исправляюсь! На днях нашел подборку — "9 книг для Junior-разработчиков". Но автор считает, что каждый разработчик должен прочитать все книги из списка.

1. Clean Code
Роберт К. Мартин

Clean code — книга о том, как сделать код читаемым, чтобы другие могли его понять и изменить в будущем. Превращение лишь нескольких принципов разработки из книги в привычки поможет писать более профессиональный и масштабируемый код.

2. Refactoring
Мартин Фаулер

Создатель Ruby on Rails сказал об этой книге: «прочитать, прежде чем написать еще одну строчку кода». Легендарный Мартин Фаулер учит, как переключаться между кодингом и рефакторингом, и как часто это делать.

3. Soft Skills: The Software Developer's Life Manual
Джон Сонмез

Гармоничное развитие — это рост и обучение: как в профессиональной сфере, так и вне её. Автор Soft Skills рассказывает, насколько важно инвестировать в обучение, здоровье и общее благополучие разработчика.

Полная подборка — по ссылке ниже. Скоро напишу об обязательных книгах для тимлида!
This media is not supported in your browser
VIEW IN TELEGRAM
Привет! Сегодня говорим о том, как оценивать задачи.
Я учёл пожелания: добавил субтитры и сжал видео.
• Предпочитаешь читать, а не смотреть — то же самое текстом
• Первое видео серии — «Как оценить ресурсы команды»

Если знаешь крутые книги, статьи по оценке задач — пожалуйста, скидывай в личку @ax8080
Пожелания по формату и вопросы — туда же
Нашёл подборку 14 законов и принципов в разработке. Да, у меня особенная любовь к принципам.
Вот 3 самых интересных, остальные по ссылке:

Закон Брукса
Добавление разработчиков на поздней стадии только замедлит процесс.
Работа над эффективностью, методологиями и архитектурой принесут больше пользы.

Правило 90-90
Первые 90% кода пишутся за 90% времени. Оставшиеся 10% кода — за другие 90% времени.

Закон Хофштадтера
Любое дело всегда длится дольше, чем ожидается, даже если учесть закон Хофштадтера.
В прошлом году я провел необычный эксперимент: взять отпуск и в отпуске не работать совсем.

Что значит совсем:
• удалить слак с телефона и ноутбука до конца отпуска
• не планировать на отпуск ни одной задачи
• составить список контактов для любой ситуации
• предупредить всех об эксперименте: https://alexeyisonvacation.com

Гипотеза: через 2 недели по приезде буду работать с двойной силой.

И... сработало! Первые дни отпуска ушли на то, чтобы привыкнуть к тому, что ничего не нужно делать. Затем полное спокойствие и свобода. А последние дни отпуска я уже сгорал от желания вернуться и все сделать. По возвращении было очень много энергии: без метрик, по субъективным ощущениям.

Попробуй как-нибудь тоже, вдруг сработает.
Кстати, слак на телефон я так и не установил. Это тоже сделало мою жизнь спокойнее.
Всем привет! Как и обещал, делюсь опытом 1:1.

Зачем я провожу 1:1
• Передаю энергию и видение
• Держу руку на пульсе: текущий статус и проблемы
• Даю обратную связь сотруднику: что хорошо, что плохо
• Получаю обратную связь: как выглядит со стороны то, что я делаю

После найма на первом месте — мотивация и синк ценностей, принципов, целей. Со временем, когда у новичка проходит период адаптации, я смещаю фокус на выявление проблем: стараюсь понять, над чем работать. И, наконец, фокусируюсь на обратной связи — от меня к сотруднику.

Формат и расписание
• Не люблю "регулярные встречи", поэтому без обязательных событий в календаре. Ставлю напоминание — раз в 3 недели. Если нечего обсуждать или я сильно занят, откладываю встречу. В среднем получается раз в 4 недели.
• Заранее скидываю вопросы и о том же прошу собеседника.
• По времени 20—50 минут, заранее не фиксировано.
• Веду логи встреч: проблемы, обещания, статусы. Это помогает держать контекст.
• Между встречами делаю заметки, если сотрудник превзошёл ожидания или нафакапил.

5 вопросов, если не знаешь, с чего начать
• Что тебя за последнее время обрадовало?
• Что тебя расстроило больше всего, какие события?
• Если ли что-то, что мешает тебе работать лучше?
• Чувствуешь ли ты, что развиваешься?
• Самые интересные задачи, которые ты делал — что тебя драйвит больше всего? Какие самые скучные задачи?

Материалы от подписчиков
• Огромная подборка статей о 1:1 (прислал Nikolay Krapivnyy)
• Статья Stop wasting my time with your shitty one-on-one meetings (прислал Mikhail Kuleshov)
• Книга Radical Candor: Be a Kick-Ass Boss Without Losing Your Humanity / Kim Scott (прислал Sergey Grebnov)
• Статья Intro to 1 on 1s (прислала Ulyana)
Времена, когда в компании всё за всех решал биг босс уходят в прошлое. Теперь право голоса может быть сразу у нескольких человек. Что делать, если они не могут принять решение даже после нескольких часов обсуждений?

Прочитал статью о том, как принимают решения в крупных компаниях.

Авторы, стратегические консультанты из Бостона, советуют поступить так:
• Решите заранее, что делать в подобном случае. Например, если через полтора часа команда не найдёт решения, будет голосование.
• Важно заранее определить вес каждого голоса. Сколько голосов нужно: две трети или больше? Есть ли право вето? Чей голос будет решающим?
• Как поступить, если кого-то значимого из состава команды не будет на встрече? Будет ли в этом случае голосование? Кто будет принимать решение?
• Один из вариантов: голосование с вариантами "да", "нет", "не определился". Выбирая последний вариант надо написать условия, при которых решение изменится на "да" или "нет".

У вас в команде есть правила принятия решений?
Правила проведения встреч?
Или можешь посоветовать книги по фасилитации?
Пиши в личку — @ax8080, сделаю подборку советов от подписчиков.
Интересная статья о 10x-разработчиках.

По мнению автора, 10x-разработчик — тот, кто работает в 10 раз продуктивнее других. И эта способность зависит не только от опыта работы и знаний. Итак, 10x-разработчики:
• Задают вопросы: выясняют, что не так в ТЗ, а не тратят время на разработку, если задача поставлена неверно;
• Просят помощи и совета, когда это нужно;
• Понимают, сколько времени тратится на сообщения и отвлекающие приложения. Используют техники для концентрации, такие как pomodoro;
• Знают, как ускорить работу, используют горячие клавиши;
• Любопытны, всё время учатся. Не только кодить, но и расширяют кругозор;
• Прислушиваются к другим и находят окружение, в котором хочется развиваться;
• Делятся знаниями: проводят презентации для команды, ведут блог или консультируют онлайн.
This media is not supported in your browser
VIEW IN TELEGRAM
Привет!
Короткое видео о том, как мы работаем с техдолгом.
В этот раз без дурацкой фоновой музыки!

• Предпочитаешь читать, а не смотреть? Тезисы:
- собери всю команду на рефакторинг-митап
- пусть каждый участник напишет карточку на каждый костыль
- для каждой карточки напишите resolution — как пофиксить
- проведи опрос и приоритизируй проблемы
- оцени сроки по топ-карточкам
- в итоге получишь объем технического долга
- теперь можно делать тикеты в порядке приоритета
• Первое видео — «Как оценить ресурсы команды»
• Второе видео — «Как оценивать задачи»

На последнем CodeFest я подробно рассказал, как мы договариваемся с бизнесом и как планируем рефакторинг. К июню, вроде, будет видео — сразу скину в канал.