Конференция техлидов из E-com

Ребята из СберМаркета проводят тематическую конференцию про E-com. Техлиды из разных команд Озона, Lamoda, X5 и самого СберМаркета будут рассказывать про интересные технические кейсы, с которыми они работают. В программе: быстрый запуск новых проектов, работа с несколькими датацентрами, организация платформенных команд и проектирование систем.

📆Дата: 24 августа, 16:00 по Москве
👉Регистрация

Реклама. ООО «Инстамарт Сервис», 115035, Москва, ОГРН 1187746494980. 18+

Self-hosted альтернативы инструментам Atlassian

Я пропустил новости про уход из России Atlassian стека. Если вас это коснулось, в статье рассказывают про альтернативы, которые можно поднять у себя на сервере.

Что использовать вместо Jira:
👉Plane
👉Redmine
👉Tuleap

Что использовать вместо Confluence:
👉Outline
👉Bookstack
👉Docuwiki

Что использовать вместо Trello:
👉Mattermost Boards
👉Logseq
👉Kanboard

Если вы можете порекомендовать другие аналоги – делитесь в комментариях!

Как построить доверие в общении

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

Построить доверие с такой низкой базы очень сложно, но все еще возможно. Я проходил через такую ситуацию несколько раз, и советы из статьи резонируют:

👉Говорите с человеком осторожнее, всегда помня о том, что каждое слово, которое может быть превратно истолковано, пойдет во вред.
👉Если у вас есть ощущение, что вы могли сказать что-то лишнее, то лучше проговорите эти опасения явно. Пусть даже с момента общения прошло какое-то время.
👉Если вам кажется, что на вас наехали, попробуйте рассказать человеку вашу картину мира, и почему сказанное им вы воспринимаете как агрессию или нарушение границ. Главное – подчеркнуть, что это не реальность, а то, как вы ее воспринимаете.
👉Эмпирическое правило – для здоровых доброжелательных отношений на каждый негативный эпизод должно приходиться пять позитивных. Старайтесь их создавать, просто говоря что-то хорошее по возможности.

Вебинар про работу с техдолгом

Когда я работал в Авито, процесс работы с техническим долгом был выстроен там очень круто. Несколько практик, которые этому помогали:
👉Ответственность за своевременное решение техдолга, как и за общее качество продукта, лежала на тимлиде. Соответственно, о его перфомансе во многом судили именно по этому.
👉Продакт и тимлид находились в разных “ветвях власти”. Ни один из них не мог диктовать другому правила игры. Это вело к постоянному конструктивному конфликту и наличию баланса между продуктовым и техническим бэклогом.
👉Наличие единых по всем командам практик health check помогало СТО и руководителям разработки следить, что техдолг находится под контролем у каждой из команд.
👉Большие куски технического долга, для решения которых требовалось усилие многих команд в течение продолжительного времени, выносились как цели на уровень компании, и получали buy-in от бизнеса. Так было, например, с распилом монолита, или с переездом в несколько дата центров.

Так вот, ребята в Авито хорошо шарят в практиках постепенной борьбы с техническим долгом. Александр Прянин, Technical Unit Lead одной из команд, скоро проводит воркшоп про то, как формировать и приоритизировать техдолг, контролировать его прирост и убыль и минимизировать его накопление.

📆Дата: 30 августа, 19:00 по Москве
👉Регистрация

Как создавать дисфункции, пытаясь их устранить

Ох, какая же вредная статья! Начинается все клево – автор рассказывает про то, что на все проблемы обязательно надо смотреть системно, не бросаться тушить пожары сломя голову, а искать взаимосвязи в системах. А решение – составлять специальные Dysfunction Maps.

И вот тут начинается все самое интересное! Автор определяет проблему – команда не успевает сделать за спринт все, что было запланировано. И следующим же шагом он определяет дисфункцию – у команды отсутствуют цели спринта. Дальше дисфункцию ожидаемо предполагается лечить постановкой этих целей.

Что меня бесит – вместо того, чтобы проанализировать, почему текущая ситуация вообще считается проблемой, что именно влияет на ее возникновение, и из-за каких корневых причин команда не перформит, автор предлагает сразу внедрять какие-то практики. Причем из-за приседаний с составлением бессмысленной схемы обычный карго-культ приобретает видимость продуманного анализа.

Короче говоря, посмотрите статью, и не делайте так, как предлагает автор. Гораздо более полезно в таком случае попробовать построить дерево текущей реальности из теории ограничений. Оно как раз не дает переходить к простым решениям до того, как вы точно не определите все корневые проблемы.

Признаки хорошей стратегии

Статей про то, какой должна быть стратегия – море. Какие-то из них совсем дурацкие, какие-то – в целом неплохие и несут в себе хорошие мысли. Вот конкретна эта хороша тем, что может подсказать вам несколько дополнительных критериев, которые можно использовать для оценки и дальнейшей доработки вашей стратегии.

А вообще, лучше всего прочитайте "Good strategy, bad strategy" Румельта. Не расскажет, как именно надо составлять стратегию, но хорошо натренирует нейроночку на то, чтобы распознавать плохую.

Как организовать one day offer event

Ко всем компаниям, организующим такие мероприятия, у меня один вопрос – почему, вместо того, чтобы системно улучшить процесс найма и сделать его быстрее или качественнее, вы вкладываете силы в разовый ивент. Вернее, ответ очевиден – это возможность получить быстрый результат и закрыть горящие вот прямо сейчас вакансии. Но вот почему, посмотрев на результативность, выводы не применяются в изменении обычного процесса найма – загадка.

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

4 совета для тимлидов в работе с проектами и задачами

Задумывались ли вы о том, что грамотная постановка задач, четкий дедлайн и коммуникация с командой - это уже 50% вашего успеха в работе с проектом? Ведь согласитесь, если задача поставлена с четким ТЗ, дедлайном и ответственным - то вопросов у ваших коллег будет возникать меньше, а результат не заставит себя долго ждать.

Решили напомнить про 4 важных совета, как быстро и без боли упростить работу с задачами в команде:

1. Ясное определение целей и ожиданий: Начните с четкого определения целей проекта и задач. Делите их на более мелкие управляемые этапы и определите приоритеты. Это поможет всей команде понять куда двигаться и сфокусироваться на самом важном.
2. Декомпозиция задач: Разбивайте большие задачи на более мелкие подзадачи, делайте чек-листы. Это поможет создать более наглядное представление о процессе работы, а также улучшит планирование и отслеживание прогресса.
3. Открытая коммуникация: Не забывайте про честную коммуникации в команде. Регулярные статус-апдейты, встречи и обратная связь помогут предотвратить непонимание и улучшить взаимодействие коллег.
4. Гибкий подход к методологиям: Используйте современные подходы, такие как Scrum, чтобы адаптироваться к изменениям и быстро реагировать на новые требования.

А теперь о хорошем инструменте для этих целей. Организовать эффективную работу с задачами и проектами можно в бесплатном Битрикс24. Тут вы сможете отлеживать сроки и планировать загрузку, общаться с командой по видео и обмениваться файлами на корпоративном диске. Удобно, что работать можно в любом режиме — от канбана до диаграммы Ганта. А вести проекты гибко поможет Скрам.

Подробности оставлю по ссылке.
Бесплатно для команд любого размера, регистрируйтесь!

Реклама. Рекламодатель.

Как ментальное состояние руководителя влияет на команду

Любой руководитель – обычный человек, который вне работы подвергается точно такому же стрессу, как и любой другой человек в его команде. Даже хуже, ведь из-за большого количества одновременных контекстов и вопросов, в которых надо принимать решения, мыслетопливо заканчивается еще быстрее, а уровень стресса только растет.

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

У каждого – своя ситуация, и свои способы борьбы со стрессом и расфокусировкой. В статье предлагается несколько довольно дельных, например, структурирование дня, выгрузка всего из головы, разбор входящих только в определенное время. Посмотрите, может быть, что-то откликнется.

CROC TeamLead Weekend

Ребята из КРОКа проводят митап для тимлидов, совмещенный с обучением хождению под парусом и каякингом.

Сначала про контент:

👉Кирилл Краснов, эксперт по бизнес-коммуникациям, расскажет про пять идей улучшения рутинной работы команды.
👉Евгений Антонов, Иван Лукьянов, Валентин Губарев и Кирилл Краснов разберут вопросы и кейсы посетителей на круглом столе.

А теперь про формат. Помимо докладов все участники могут научиться ходить под парусом или освоить каяки. Специальных навыков иметь не нужно, все покажут на месте!

🗓10 сентября, 15:00–21:30, офлайн в Москве
📍парусный спот КРОК х Сила ветра, Москва, Строгино

Мероприятие – бесплатное, но нужно зарегистрироваться и дождаться подтверждения. Количество мест на споте ограничено.
Реклама. ЗАО "КРОК Инкорпорейтед"

Как продавать техдолг

Сам по себе термин "техдолг" – определение-коробочка, внутри которого может быть что угодно, начиная от довольно бесполезных миграций с одного пакетного менеджера на другой, заканчивая работами, без которых сервис не будет масштабироваться под ожидаемой нагрузкой. Как только речь заходит о том, чтобы убедить бизнес инвестировать в отдачу техдолга, полезно переходить на более конкретный язык. Примеры – на прикрепленной картинке.

Помимо этого, в статье есть еще несколько советов по продаже техдолга:

👉Обосновывая инвестиции во внутренний тулинг, сразу продумайте ответы на вопросы про ожидаемый возврат инвестиций и то, как вы будете оценивать адопшн. Можно посмотреть на фреймворк продаж MEDDIC.
👉Инвестиции в отказоустойчивость проще всего обосновать через SLO.
👉Инвестиции в переписывание кода обосновывайте через оценку того, когда вы сможете доставить результаты рефакторинга до прода, улучшение читаемости и поддерживаемости кодовой базы, экономию времени или решение проблем ближайшего будущего.

Ошибки в переговорах о зарплате

В статье разбираются две частые ошибки, их последствия и способы их избежать:

1️⃣Раскрывать рекрутеру заранее подробную информацию о ваших ожиданиях и текущем состоянии дел: компенсации на работе и других собеседованиях.
2️⃣Вступать в переговоры за оффер, не будучи к ним полностью готовым. Например, не имея на руках сразу несколько офферов от разных компаний, и не понимая своей итоговой цены на рынке.

Проблемы лишних абстракций во фреймворках

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

Ключевая цитата: "Frustration happens when the developer is unable to use their existing skills or feels disproportionally punished for doing it their way instead of your way".

Product Map – карта всего, что надо знать продактам

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

Из хороших альтернатив могу еще посоветовать вот эту карту от автора Product Architecture Framework.

Что отличает хорошие решения от плохих

Статья в основном про принятие продуктовых решений, но выводы вполне применимы и в других областях.

👉Вся суть принятия решений в том, чтобы выбрать путь с наибольшей вероятностью успеха, основываясь на доступной в данный момент информации.
👉Качество решений нельзя оценивать, смотря на их результат. Не всегда цель может быть сформулирована заранее, и сравнить ожидания с реальностью не выходит. А оценивать результат в вакууме довольно бессмысленно.
👉В таких условиях имеет смысл оптимизировать то, что находится под контролем – процесс принятия решения и предварительный анализ.

Помимо этих тезисов большая часть статьи как раз про советы по повышению качества процесса и анализа.

Как продакту не оверсейлить, а команде не андерделиверить?
 
Разберитесь в том, как выглядит дизайн большой системы, чтобы лучше понимать, что и в какие сроки реально сможет реализовать ваша команда.
 
Получить полное представление о том, из каких базовых блоков состоит любая большая современная система можно на курсе System Design.

Здесь вы поработаете над архитектурой реальных проектов сервиса такси, приложения для знакомств и многих других, познакомитесь с типичной структурой дизайн-собеседований в Big Tech и получите практический и детальный план ответа на собеседовании.

Успевайте присоединиться к обучению: https://karpov.courses/systemdesign

Кстати, по промокоду LEAD15GR для вас действует скидка 5% до 20 сентября.

Реклама. ООО "Карпов Курсы". Erid: LjN8KNvey

SRE принципы для CI/CD пайплайна

Хороший подход к определению ожиданий к стабильности CI/CD пайплайна с использованием хорошо известных SRE практик:

⭐️Service Level Objectives (SLOs): какой уровень стабильности гарантирован.
📊Service Level Indicators (SLIs): как именно трекается уровень стабильности.
🧳Error Budgets: как долго пайплайн может не отвечать требованиям SLO.

Пример:

⭐️SLO: Каждый коммит должен быть протестирован в течение 5 минут после пуша.
📊SLI: Общее время прогона билда.
🧳Error budget: 40 билдов, время прогона которых заняло больше 5 минут, на протяжении 4 недель.

Мне особенно зашла идея с определением бюджетов на ошибку. Таким образом, команде, отвечающей за инфраструктуру, не придется бросать все свои задачи и реагировать на любое отклонение от желаемых значений. Но если проблемы накапливаюся, есть четко определенный момент принятия решения о том, что делать дальше.

Пол и потолок в перфомансе

У баскетбольных аналитиков есть модель описания перфоманса игроков, основанная на их граничных показателях:

👉High floor, high ceiling: Самые лучшие игроки, которые показывают отличный результат и в хорошие дни, и в плохие.
👉High floor, low ceiling: надежные игроки с предсказуемо средним перфомансом.
👉Low floor, high ceiling: ненадежные игроки с проблесками гениальности. Могут сыграть как отвратительно плохо, так и слишком хорошо.

С точки зрения команды разработки, так же, как и спортивной команды, полезнее всего первые две категории. При этом, в процессе найма мы часто пытаемся оценить ceiling, а не floor. При таком подходе легко нанять человека из третьей категории, который большую часть времени будет тянуть команду вниз.