Хочу поделиться тем, как я читаю книги. У меня была проблема: читать круто, книжек много, а времени нет. Вечером после работы нет сил, в выходные хочется отдыхать.

За 2017 год прочитал 3 книги, а в списке "когда-нибудь" накопилось уже несколько десятков. В 2018 прочитал я уже 17 книг и 28 кратких изложений. Возможно, тебе поможет мой способ.

Недавно я начал делать часовые прогулки в обед. И тут осенило: попробую преодолеть неприязнь к аудиокнигам и во время ходьбы слушать книги. Затем совместил с сервисом smartreading и начал чередовать полные версии с краткими изложениями. Слушаю краткую версию перед полной, если такая есть.

Все советы кратко
• прогулки отмечаю в календаре, как встречи — эти слоты невозможно занять
• книги скачиваю на неделю вперед, заранее скидываю на телефон
• веду беклог рекомендаций и списков вроде "топ-10 книг для тимлида"
• после прочтения пишу краткий отзыв 5-10 пунктов: крутые идеи + что применю в работе
• каждой книге ставлю оценку и пометку, читать ли полную версию
• пользуюсь smart audio book player: удобно отматывать назад и ставить скорость 1.3—1.6x
• скучная книга — снимаю наушники и удаляю книгу
• не читаю книги из топа smartreading 💩
• слушаю книги в очереди к врачу и в долгих поездках за рулём
• книги нет в аудио — читаю на ходу с amazon kindle

Кстати, в этот канал буду кидать крутые книги из тех, что прочитал.

Если ты когда-нибудь проводил встречи для обмена опытом, то знаешь: все хотят послушать, а рассказывать не хочет никто. Я регулярно собираю тимлидов на такие встречи и поделюсь некоторыми приёмами, которые мне в этом помогают:

• Пробую разные форматы: что работало пару месяцев назад, может выдохнуться сегодня. Полезно провести cust dev с участниками: ты поймешь, что люди любят, а что — терпеть не могут. Например, я выяснил, что короткие выступления — 🔥, а долгие обсуждения — 💩.
• Не провожу встречи часто, чтобы не страдало качество. Одна встреча в 2 недели — в самый раз.
• Текущий формат: анонс за 5 минут или 20-минутный доклад. На вопросы — 5 минут. За временем жёстко слежу по таймеру.
• "Кто хочет выступить — записывайтесь в файлик" работает только один раз. На второй раз будет пустой файл. Вместо этого пишу каждому в личку: "Артем, на прошлой неделе вы уронили все сервера. Наверное, запилили что-то крутое? Расскажешь в среду?"
• Не отправляю всем одно и то же сообщение: ребята просто игнорируют такие рассылки. Стараюсь не давить — уважение и любовь работают лучше.
• Веду логи ответов вроде "мы заняты переходом на ngrx". Через 2 недели попрошу об этом рассказать.
• После того, как собрал темы устраиваю голосование, чтобы выкинуть скучные темы.
• Стараюсь выступать сам, даже если "нет времени". Невозможно требовать от других того, что не делаешь сам.
• Каждый доклад оцениваем по 3 критериям: "интересный", "полезный", "применю что-то в течение недели". Это фидбек для докладчиков + дарим пиццу за лучшее выступление.

Привет! Удалённые сотрудники тоже хотят общаться вживую. В 2017 году мы провели хакатон для всех разработчиков Skyeng, а в прошлом году перешли на новый формат: командные встречи оффлайн. Расскажу об одной такой встрече — она получилась особенно крутой.

Встречу организовали сами: выбрали даты, город, виллу, развлечения. Не веревочные игры, не свечечки с обнимашечками, не пожелания на листочках. Но встреча не сделается сама, нужен фасилитатор-агитатор: найти крутые варианты, провести голосование.

Развлечения. Мы набрейнштормили 35 вариантов, выбрали топ-10, назначили ответственных и составили расписание. Топ-3 по итогам встречи: настолка "гномы-вредители", велопробег на электробайках, лазертаг.

Минипрезентации: собрались у камина и каждый за 10 минут рассказал о себе. Как пришел в профессию, чем занимался до Skyeng, о хобби и случаях из жизни. Интересно и помогло лучше друг друга узнать.

Продуктивность падает: рядом речка, вокруг — горы, солнце, команда. Процессы не заточены под оффлайн. Но вернувшись домой — фигачили с двойной силой.

Еда. Позаботьтесь о поваре или найдите службы доставки. Кафе — слишком затратно по времени. Выберите одного человека, который соберёт пожелания и вовремя оформит заказ. Пили, как ни странно, мало и редко.

Жилье. Вилла без соседей — огонь. Вместе жили, ели, спали и работали — особая атмосфера и погружение. Важно убедиться, что есть пространство для работы, быстрый интернет и сетевые фильтры.

Работа. Разбились на миникоманды и делали спецпроекты: проверяли безумные гипотезы и пробовали революционные изменения. В сочетании со сменой обстановки отлично сработало.

Ещё пара советов: telegram-канал для оперативной связи, каршеринг, и не брать жён и детей — всё же это не отпуск.

Ты сталкивался с ситуацией, когда разработчик реализует не очевидное решение, а какую-то дичь? И выясняется это слишком поздно: переписывать некогда. Или задача, описанная в пару строк, превращается в геморрой на 2 недели?

Кажется, проблема решается "планированием спринта" или обсуждением задач на стендапе. Но мы больше не планируем всей командой: 8 человек в течение 7 часов утомленно обсуждают задачи. Вспоминаю с ужасом. Или ты, как тимлид, придумываешь решения сам. Но ведь сложно разбираться во деталях круче всех! Особенно если в команде крутые разработчики, а не джуны. Еще труднее никогда не ошибаться.

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

Не больше 4 участников, все должны быть в контексте и заинтересованы в обсуждении. Часто это тимлид + пара человек, которые разбираются в теме. Список определяем заранее опросом: "кто хочет участвовать в обсуждении задачи XXXX? для участия обязательно прочитать: ..."

Не жалей времени: для 8-часовой задачи ревью занимает полчаса, и задача затем не превращается в 24-часовую.

Делюсь нашей инструкцией: https://hackmd.io/s/rJFGNEYP4

Мотивирующая статья (https://bit.ly/2CnF9AU) о ценности компетенций разработчика при полном отсутствии опыта:
• Заявленный в вакансии опыт — проверка компетенций кандидата. Достаточно ли ты компетентен, чтобы писать нужный код и работать в профессиональной среде.
• Средний разработчик без официального опыта работы будет соответствовать вакансии, требующей один год опыта.
• Даже для сеньоров 70% вакансий редко требуют более 4 лет опыта. Но для сеньоров больше требований: опыт работы с конкретными технологиями, опыт руководства или выше качество кода. При этом определяющими будут компетенции, а не стаж.
• Если докажешь на что способен с помощью кода или ответов на собеседовании — опыт работы не будет иметь значения.

Для комфортной работы команде требуются 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
• кинь ссылку знакомым разработчикам и тимлидам, если понравилось

26 и 27 апреля буду на Стачке: IT-конференции, где ежегодно собирается 5000 разработчиков. Не верится? Мне тоже, поэтому поеду проверить. Если тоже приедешь проверять, приходи на мой доклад Мотивация метриками: как подружить разработку и бизнес. Увидимся в Ульяновске.

Улучшить производительность поможет правильная структура дня. Мы привыкли к 8-часовому рабочему дню, но проблема такого подхода — отсутствие запланированных промежутков отдыха.

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

Список советов:
• Разбей день на часовые интервалы.
• Не обманывай себя. Работай сфокусированно в отведенное время. На Facebook, YouTube и почту — запланированный отдых.
• Ещё лучше вместо соцсетей заняться ходьбой, чтением или общением. Это самые подходящие методы перезарядки.
• Не жди, пока организм попросит сделать перерыв. Если ты устал, то уже пропустил момент. Следуй заранее составленному графику.

Пробую новый формат: короткие видео вместо коротких постов. Первое видео — Как оценить ресурсы команды. Если у тебя есть фидбек по формату или вопросы по сути — пиши в личку @ax8080.

UPD. Всем спасибо за фидбек о размере файла. Уменьшил, перезалил!

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

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

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

Чуть позже поделюсь своим опытом проведения 1:1 — принципами, техниками и списком вопросов. Если у тебя есть интересные статьи, о том как проводить 1:1 — скидывай в личку @ax8080. Сделаю подборку и выложу!

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

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

Привет! Если ты работаешь удалённо или думал начать — тебе может быть интересно, как мы делаем это в 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 рассказывает, насколько важно инвестировать в обучение, здоровье и общее благополучие разработчика.

Полная подборка — по ссылке ниже. Скоро напишу об обязательных книгах для тимлида!

Привет! Сегодня говорим о том, как оценивать задачи.
Я учёл пожелания: добавил субтитры и сжал видео.
• Предпочитаешь читать, а не смотреть — то же самое текстом
• Первое видео серии — «Как оценить ресурсы команды»

Если знаешь крутые книги, статьи по оценке задач — пожалуйста, скидывай в личку @ax8080
Пожелания по формату и вопросы — туда же

Нашёл подборку 14 законов и принципов в разработке. Да, у меня особенная любовь к принципам.
Вот 3 самых интересных, остальные по ссылке:

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

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

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