Управление разработкой *

Что такое чистая архитектура: основные особенности

Чистая архитектура — это подход к проектированию систем, который предполагает независимость от фреймворка и вообще от внешних компонентов. Выделяем слой use-кейсов, слой сущностей, UI и презентер — и теперь эти слои и есть наши фреймворки. Поэтому реальный фреймворк в чистой архитектуре можно использовать как инструмент, а не перестраивать весь проект под его ограничения.

Какие еще свойства чистой архитектуры важны:

1. Тестируемость. Это значит, что бизнес-правила могут быть протестированы без UI, без баз данных, без веб-сервера и без любого другого внешнего компонента. Например, у нас может быть фронтенд на React и мобилка на Flutter — и мы при этом всё равно можем менять контракты, не меняя бизнес-правила.

2. Чистая архитектура независима от информационных хранилищ. Можно поменять PostgreSQL на MongoDB или на любую другую СУБД. При этом работа бизнес-правил не изменится. 

3. Чистая архитектура — это независимость от внешнего сервиса. По факту слой use-кейсов изолирован от внешнего мира, ничего о нем не знает. А знает только о том, как работать в рамках бизнес-системы.

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

❓Разработчик и стартап: работать | основать | избегать?

В новом выпуске Sravni Tech Podcast обсуждаем, куда податься разработчику: пойти работать в стартап, рискнуть и запустить свой или держаться подальше от “стартапной суеты”? Наш гость — Илья Хрусталёв, основатель Foodfox (тот самый, что стал «Яндекс.Едой»).

 В выпуске:
📌Работа в ИТ-стартапе: ожидание vs реальность
📌Жизненный цикл стартапа (и когда это уже не стартап?)
📌Запускаем свой бизнес в ИТ. Что важно учесть?
📌Различия стартапов в России и США. Где проще получить инвестиции?

Подписаться на ТГ-канал Sravni Tech

Посмотреть подкаст можно здесь:

✅VK
✅YouTube
✅RUTUBE

А послушать — здесь:
✅ Яндекс Музыка
✅ Плеер в ТГ

Чем полезна ротация разработчиков внутри компании

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

Разберем, как это работает:

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

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

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

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

• Идентификация проблем. Если разработчик работал медленно в одной команде, но быстро в другой — возможно, в первой проблемы. Они могут быть связаны с коммуникацией или с постановкой задач, но проверить точно стоит.

Главное при ротации — приставить к разработчику более опытного ментора. Так человеку будет легче адаптироваться в новой среде и получить необходимые знания для повышения продуктивности.

Больше советов по этой теме читайте в нашей статье. Она поможет выстроить работу команды разработки таким образом, чтобы дедлайны не срывались.

Президент РФ Владимир Путин в рамках «перечня поручений по итогам пленарного заседания и посещения выставки Форума будущих технологий, включая встречи с учёными», поручил Правительству РФ рассмотреть вопрос о создании национального суперкомпьютерного центра.

«С учётом ранее данных поручений рассмотреть вопрос о создании национального суперкомпьютерного центра, предусмотрев возможность предоставления российским исследователям доступа к его вычислительным мощностям и обратив внимание на необходимость подготовки кадров для данного центра».

Эффект Пигмалиона (Розенталя)

Раньше (до того как машины стали стоить как квартира) замечал несколько раз - вот выберешь себе новую машину и вдруг в городе их оказывается уже очень много. Вот едет и вот еще. И потом начинаешь замечать, что их реально много стало вокруг.

На самом деле, их конечно же не стало больше, просто мы их стали замечать.

Такое наше поведение является проявлением эффекта Пигмалиона (Розенталя) и является одним из когнитивных искажений (ошибок мышления - обожаю эту тему, вот и сюда ввернул).

Эффект Пигмалиона - ожидания человека определяют его действия.

Психологи Роберт Розенталь и Ленора Якобсон провели эксперимент: в начале учебного года они выделили учеников из разных классов начальной школы, которые по результатам теста оказались более талантливыми и обладали более высоким IQ, чем их одноклассники. На самом деле никаких выдающихся способностей у них обнаружено не было и ученики были выбраны случайно, однако учителям сообщили обратное. Повторное тестирование в конце года показало, что результаты «одарённых» учеников в среднем улучшились, а показатель IQ увеличился.

Дело в том, что наш мозг с трудом отличает восприятие и ожидание. Социолог Роберт Мёртон описал самосбывающиеся пророчества, к которым относится эффект Пигмалиона, как самогипноз. Имея изначально убеждение о себе или других, мы влияем на действительность и делаем так, что оно становится правдой. Этот психологический феномен позволяет целенаправленно или случайно влиять на реальность.

А что автомобиль?

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

Отсюда есть 2 интересных следствия:

1. Просто формулируя цели — вы уже настраиваете себя.

Сформулировав цель вы получите результат больше, чем если не сформулируете и будете просто «копать-бежать».

Это лучше чем ничего, но точно недостаточно чтобы сделать прорыв.

OKR служит хорошей формулой для формулирования целей.

2. От ожиданий руководителя зависит результат сотрудников.

Руководитель, который думает что его окружают «дэбилы», получит результат сильно хуже, чем тот кто будет верить в своих сотрудников  и доверять им.  Мои ребята точно способны на большее!

А знаете чей слоган «для способных на большее»? Пишите в комментариях

Неудивительно, что эти ребята сейчас активно внедряют OKR. Это уже становится частью их культуры.

⛵️Без кого не выплывем: 4 ключевые роли в OKR-проекте

Одна из базовых причин, почему так много неудачных внедрений OKR - OKR не рассматривается в компании как проект трансформации. 

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

Представьте, что для выполнения сложной миссии нам нужна команда, почти, как на пиратском корабле🏴‍☠️.

Наш опыт показывает, что есть 4 ключевые роли, без который наш корабль никуда не поплывет. 

Итак. 

Для успешного внедрения OKR как проекта нам понадобятся следующие роли.

🔶 Лидер проекта внедрения OKR — главный в проекте, это по сути капитан корабля. Обычно эту роль на себя берет кто-то из ТОП-менеджеров.  Он напрямую заинтересован в успехе проекта и обладает управленческими компетенциями. Как и любой бывалый капитан, он понимает важность человеческой составляющей в проекте изменений.

Ключевые его задачи:

✅ вовлекать ТОП-менеджеров и других участников проекта;

✅ управлять изменениями;

✅ обеспечивать ресурсами участников проекта.

🔶 OKR-коуч — главный эксперт по OKR. Это тот самый мудрец, обладающий секретными знаниями о сокровищах, без которых команда не реализует проект.  Работает на уровне организации и ТОП-менеджеров, а не команды. Обладает обширной практикой и набором инструментов, которые подбирает под конкретную ситуацию, в том числе управления изменениями. Чаще это приглашенный эксперт.

🔶 OKR-мастер работает на уровне команды, а не компании. Он задает ритм, помогает грести в верном направлении через декомпозицию целей и выстраивание регулярного процесса изменений. С его участием команда системно добивается бОльших результатов. И точно доплывет быстрее, чем без него.

🔶 OKR-Strategist отвечает за сборку общего дерева целей по компании. Является экспертом в декомпозиции целей и работе с метриками. Его ценность в том, чтобы помочь компании  правильно распределить ресурсы между различными целями и выстроить регулярный процесс мониторинга.

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

У нас уже есть курс для OKR-мастеров. И мы планируем запустить обучение и по другим ролям, чтобы у компаний была возможность собрать полноценную команду и запускать изменения.

Поэтому сейчас я провожу бесплатные интенсивы в закрытом телеграм-чате. Подробности обучения и ссылка на чат в моем телеграм-канале.

Как накачать управленческую мышцу? 🤔

Вспомните, как вы стали руководителем первый раз?

Вы показывали хорошие результаты на своей текущей позиции, были активны и хотели роста. Вы были хорошим экспертом и профессионалом.

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

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

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

В период кризисов вы также подключали свою экспертизу и опыт. Решения надо принимать быстро и максимально эффективно. Не до тренировок, дела делать надо.

В итоге в большинстве кризисных ситуациях (а последние лет 5 только такие и есть) вы добивались результата использую сильные экспертные мышцы. У управленческой мышцы даже не было шанса стать настолько же развитой, как экспертная.

Как это изменить?

В организме у нас тоже есть сильные мышцы - агонисты/антагонисты (двигатели),  стабилизаторы (фиксируют сустав и корпус) и синергисты (усиливают движение).

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

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

Как это сделать?

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

Так вы автоматически подключите управленческую мышцу, потому что по другому просто не получится достичь результата.

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

Поэтому в Японии управленцы периодически меняли свои позиции - руководил маркетингом, стал управлять складом или производством.

Это тоже про концентрированно прокачать управленческие компетенции.

 Я не предлагаю менять ТОПов местами, есть вариант лучше.

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

А я пока предлагаю вам перейти в мой телеграм-канал и больше узнать об OKR и лидерстве.

💎Сократ и OKR

Более 2000 лет назад Сократ придумал концепцию - быть -> делать ->иметь

Суть ее в том, чтобы что-то «иметь», нам необходимо в начале «быть» этим человеком или компанией, потом «делать» (совершать поступки из этого нового состояния) и в результате поступков мы будем иметь то, что хотели.

Прочитайте еще раз. Вызывает ли у вас это сопротивление?

Почему?

Мы же часто хотим в начале что-то иметь, а уже после думаем про все остальное.

Но как можно «быть» в самом начале — спросите вы?

«Я же сначала хочу иметь млн долларов, а уже после этого я могу стать богатым. Наоборот не получится».

Но на самом деле всё не совсем так. Люди, которые выиграли лотерею или в казино, не остаются богатыми надолго.

Как думаете, почему?

Чтобы чего-то достичь, важно внутренне стать/быть таким. Именно этот новый подход изменит ваш способ мышления. Оно изменит действия, и уже это с более высокой вероятностью обеспечит «иметь».

Давайте посмотрим на такую ситуацию:

Есть ли для вас разница между - быть «отцом» и иметь детей?

Для одних разницы не будет.  Это нормально 🙂

Но другие скажут что разница огромна — можно иметь детей и не быть отцом, а можно быть отцом, не имея детей.

Быть отцом — это цель, сформированная формате бытия (состояния).

Иметь детей —  цель в виде действия (изменения).

А при чем тут OKR?

Когда мы только формировали с Татьяна Винтерголлер первый курс по OKR 3 года назад, то отметили , что есть цели-состояния, а есть цели-изменения. И долго обсуждали, стоит ли так усложнять на курсе. В результате первого прогона отказались.

И только в этом году я понял, в чем их отличия.

Формируя цель в формате состояния (каким я/компания хочу быть?), вы создаете целый набор вариантов, какие для этого необходимы изменения (цели-изменения) и, таким образом, создаете для себя целое пространство вариантов.

Если же вы фокусируетесь на целях-изменениях, то часть вариантов можно упустить.

Что важно — выбирайте тот вариант, который для вас комфортен на данном этапе. Если вы формируете цели от изменений, вы уже получаете преимущество перед 95% других, в следующем году сможете сделать следующих шаг 🙂

А как вы формируете цели и какой подход ближе? Поделитесь в комментариях.

P.S. Это пост-пояснение к публикации “В поисках идеальной формулы OKR”.

В поисках идеальной формулы OKR 🔎

В интернете можно найти чек-листы для проверки качества OKR — вдохновляющие, конкретные, измеримые.

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

Но вопрос остается: как выглядит идеальная формула OKR?

В определении Цели важно:

1. глагол;

2. объект изменений; 

3. качество, которое приобретает объект в процессе изменений.

И что-то это мне все время напоминало, аж до зуда. 🤔

А ведь есть формула составления работ в JTBD - «глагол + существительное + контекст». Можно ли ее применить и тут?

Стал изучать, и оказалось еще интереснее:

Теорию JTBD активно разрабатывали 2 человека - Энтони Ульвик и Алан Клемент.

Ульвик говорил, что работа это « job-activities» - «do goals» - работы - действия (пример: построить дом).

А в это же время Клемент доказывал:  работа — это что-то ценностное - «be goals» - работа как состояние или бытие (пример: быть хорошим отцом).

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

Таким образом, для формулирования Objective можно использовать формулу «глагол + существительное + контекст качество» (прилагательное или изменение).

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

Например, вы сформулировали цель - «Стать умным, красивым и сильным», то для каждого качества нужная своя метрика :)

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

Попробуйте формулировать OKR в таком варианте и поделитесь результатам, плз :)

P.S. Уточнения и пояснения в следующих постах​.

Как создавать лидеров в компании, оптом

Чтобы достигать ДРУГИХ результатов нужно действовать по-другому, а в начале думать по-другому.

 Новый результат ⬅️ новый способ действия ⬅️ новый способ мышления.

А для этого очень много нужно вкладываться в развитие команды и конкретных людей.

И вот тут есть проблема - 90% предпринимателей не хотят заниматься развитием команды.

Люди это сложно, долго и еще ненадежно. Только научишь, а они и уйти могут.

Вот бы как-то решить эту задачу, но чужими руками.

И мы научились это делать!

Когда мы запускаем OKR в компании, то обязательно вводим своих OKR-мастеров.

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

❗ В результате команда начинает кратно быстрее бежать (есть кейсы когда за 3 месяца получили результат больше, чем за предыдущие 9 месяцев). Также она забирает ответственность за достижение цели и изменения, которые для этого необходимо реализовать.

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

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

В рамках этой роли он работает с командой - 1-2 часа в неделю, что позволяет ему эффективно выполнять и свои основные функции.

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

Вот и получается что мы получаем в 2 раза больше лидеров:

1. Те кто умеют достигать целей с командой.

2. Те кто умеют выстраивать процесс команды так, чтобы она достигала целей.

«Дай человеку рыбу, и он будет сыт один день. Научи человека ловить рыбу, и ты накормишь его на всю жизнь».

А вы САМИ хотите заниматься развитием команды?

Когда разработчику пора к юристу: типы лицензий ПО, коварный open source и авторское право на код

В новом выпуске Sravni Podcast поговорили с Юлией Суворовой, Head of Legal and Compliance в Сравни. В том числе о проверке лицензий в случае с open source решениями, оформлении интеллектуальной собственности и других сценариях взаимодействия юристов с ИТ-командами.

Также в выпуске:

📌Всем ли ИТ-компаниям (и командам) нужны юристы; риски их отсутствия
📌Юридические кейсы в ИТ: покупка ПО, проверка open source библиотек, оформление права на код
📌Как нормативные акты влияют на процессы разработки
📌Юрист в ИТ: в чём специфика этой профессии?

Посмотреть подкаст можно здесь:

✅VK
✅YouTube
✅RUTUBE

А послушать — здесь:

✅ Яндекс Музыка

Оставляйте реакции, делитесь ссылкой!📣

• Канал Sravni Tech в TG

Такой диалог:

Менеджер:
насколько трудоёмко вернуть галерею на страницу товара? Сейчас мы принимаем только 1 картинку, а нужно несколько.

Разработчик:
Просто взять и вернуть нельзя. Галерея была лет 5 назад, я даже не помню как она выглядела. Если надо - будем делать, не надо - не будем. Трудоемкость тут не причём, как мне кажется.

Менеджер:
Ну бизнес измеряет все часами и днями....

Как думаете, в контексте этого диалога, имеет значение, как бизнес считает сроки? Или сроки здесь вообще не важны?

Моя позиция такая: если оценки сроков влияют на нужно/не нужно, то скорее всего не нужно.

Нужно/не нужно должно определятся целями. Нужно/не нужно сейчас - важностью. Нет целей - как понять важно это или нет?

Оценки сроков важны, спору нет, но они должны влиять на приоритет:

• Если важная и её делать долго, то нужно начинать сейчас. Приоритет самый высокий.

• Если важная, но делать быстро и дедлайн далеко, доделываем текущие и начинаем важную. Приоритет высокий, но ниже текущих.

Когда я говорю 2 дня, и менеджер говорит - делаем, а когда 2 недели - не делаем и забываем на полгода, тогда с оценкой нужности и важности задачи явно что-то не так.

Эта ситуация может быть показателем отсутствия целей и стратегии развития продукта.

А бывает еще так, что менеджер или руководитель начинает давить, что бы уменьшить сроки... сами подумайте - оно вам надо?

P.S.: тут тоже пишу https://t.me/it_weekdays о буднях.

Напиши мне программу богатства

С выходных каждый день программирую новый сервис для студентов.
Программист я никакой, но очень нравится.
Сидишь, смотришь, как нейронка пишет код за тебя. А ты ей: «Просто хочу быть богатым, напиши мне программу». Магия какая-то.
Так думают все, кто первый раз пробует с нейронкой написать код. А потом, спустя первые 20 минут, чёт, ошибка какая-то, и потом 4 часа пробуешь её поправить с помощью нейронки.

Вторая стадия — это когда ты пишешь ей уже матом, чтобы выплеснуть всю ненависть к роботу, и он извиняется: «Мол, прости брат, не бей, ошибся» — и вроде легче на душе. И ошибается снова и снова.
Моя стадия — 4 нейронки, которые правят ошибки друг друга, долго, муторно, но двигаешься, чуть быстрее, чем сам.

Следующая стадия — это уже сам пишешь код. Надеюсь, не дойду сюда.
Всегда, когда видите, что кто-то по-быстрому разбогател с помощью ИИ, помните, что ИИ сделала 20-30% работы.

Перешли этот пост тому, кто думает, что быстро напишет программу с помощью ИИ.

Зачем компании нужна миссия?

Ответ на этот вопрос знает Виктор Раев — технический руководитель юнита в Авито и гость нового выпуска подкаста «Мы обречены». Витя рассказывает про ключевые ценности Авито, а главное: про то, какое отражение они находят в повседневной жизни разработчиков. 

Подробнее о манифесте Авито можно почитать здесь, а чтобы лучше познакомиться с внутренними принципами компании — приглашаем послушать Витю с 23 минуты.

Смотреть на YouTube

Подписывайтесь на канал AvitoTech в Telegram, там мы рассказываем больше о профессиональном опыте наших инженеров, проектах и работе в Авито, а также анонсируем митапы и статьи.

Каким вышел Avito TeamLead Drinkup #3?

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

Чтобы почувствовать атмосферу того вечера, кликайте на видео.

Смотреть VK
Смотреть YouTube

Подписывайтесь на канал AvitoTech в Telegram, там мы рассказываем больше о профессиональном опыте наших инженеров, проектах и работе в Авито, а также анонсируем митапы и статьи.

Совсем недавно была новость, что Amazon увольняет 14 тысяч менеджеров. И эта новость подавалась в апокалиптических тонах — будто конец уже близко, всё загибается, и пора бежать спасаться. Однако не стоит верить провокационным заголовкам; важно уметь правильно интерпретировать ситуацию.

Что мы знаем про Amazon:

• В Amazon работает около 1,5 миллионов сотрудников.

• Компания известна своими регулярными увольнениями неэффективных работников.

Теперь давайте посчитаем. Если каждый менеджер управляет от 5 до 10 человек, в среднем возьмём 7. Сколько же менеджеров потребуется для штата в 1,5 миллиона?

Для этого представьте себе дерево, где на нижнем уровне будет 1,5 миллиона «листьев», а все остальные уровни — менеджеры. Возводим число 7 в разные степени и смотрим результаты:

7⁰ = 1
7¹ = 7
7² = 49
7³ = 343
7⁴ = 2401
7⁵ = 16807
7⁶ = 117649
7⁷ = 823543
7⁸ = 5764801

Уже на восьмом уровне количество «листьев» превышает общее число сотрудников Amazon. Поэтому вернёмся на седьмой уровень — там примерно 800 тысяч «листьев».

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

Теперь сложим количество менеджеров с нулевого уровня до шестого и подсчитаем итог:1+7+49+343+2401+16 807+117649 =137 257;

Таким образом, чтобы управлять всей компанией, понадобится около 137 тысяч менеджеров.

Итак, увольнение 14 тысяч менеджеров — это примерно 10% от общего числа управленцев, тех самых неэффективных сотрудников, которых Amazon ежегодно сокращает.

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

Как пройти путь от разработчика до директора нескольких кластеров?

Об этом расскажет гость нового выпуска шоу «AviTalk» — Игорь Гранщиков, руководитель разработки вертикали Авито Недвижимость. Игорь воспроизводит в подробностях весь свой карьерный трек от обучения и первой работы до руководящих позиций.

Смотреть VK
Смотреть на YouTube

Подписывайтесь на канал AvitoTech в Telegram, там мы рассказываем больше о профессиональном опыте наших инженеров, проектах и работе в Авито, а также анонсируем митапы и статьи.

На ресурсе OverAPI собраны все шпаргалки для разработчиков по популярным языкам программирования и технологиям. Информация там постоянно обновляется. Можно нажать на любую команду и узнать о ней всё. Ресурс бесплатный и без регистрации.

7 очень вредных советов для тимлида

Если вы хотите, чтобы вся команда вас возненавидела, чтобы половина сотрудников выгорела, а вторая уволилась в самое ближайшее время, следуйте этим простым и действенным рекомендациям — успех гарантирован:

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

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

3. Делайте всё сами, так легче и быстрее. Ну а кто, если не вы? На объяснение задания вы потратите больше сил и времени, а так всё сделаете самостоятельно — и дело в шляпе.

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

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

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

7. Пресекайте неформальное общение в команде — это мешает работе. Поболтать о всяком можно и в свободное время. А в рабочих чатах и тем более в офисе не кружок по интересам.

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

Освойте инструменты креативных методологий для применения в проектах и рабочих задачах 💡

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

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

Кому будет полезен курс:

• руководителям больших и маленьких команд, которые хотят освоить новые инструменты, чтобы улучшить рабочие процессы;

• тем, кто хочет находить уникальные решения для развития проектов и получить практический опыт в их реализации;

• всем, кому интересны креативные методики.

Желаем успехов!

Что такое Avito Fallback и чем он так хорош?

Рассказывает Николай Губин, бэкенд-инженер в Авито. Avito Fallback — это механизм, позволяющий пользователям в какой-то степени продолжать пользоваться сервисом, даже если упал production. Коля говорит про эволюцию проекта и его технические особенности, а также про проблемы, которые возникают при работе, и то, как их лечить. 

Подробнее про Avito Fallback — в видео с 10:58.

Смотреть YouTube

Подписывайтесь на канал AvitoTech в Telegram, там мы рассказываем больше о профессиональном опыте наших инженеров, проектах и работе в Авито, а также анонсируем митапы и статьи.

По мотивам очередного холивара  
Со сравнением удалёнки, гибрида и офисной работы.  

Ария выгоревшего удалёнщика  

Я выключаю мониторы.
Я пишу тебе письмо  
Про то, что больше не могу  
Смотреть на дерьмо.  
Про то, что больше нет сил,  
Про то, что я почти запил,  
Но не забыл тебя.  

Про то, что Телеграмм звонил,  
Хотел, чтобы я встал,  
Оделся и пошёл,  
А точнее — побежал.  
Но только я его послал,  
Сказал, что болен и устал,  
И эту ночь не спал.  

Припев:  
Я жду ответа,  
Больше надежд нету,  
Скоро кончится лето,  
Это...  

А с погодой повезло,  
Снег идёт четвёртый день.  
Хотя на Яндексе рисуют,  
Что жаркой будет даже тень.  
Но, впрочем, в том углу, где я,  
Пока и сухо, и тепло.  
Но я боюсь пока.  

А дни идут чередом,  
День едим, а три пьём,  
И, в общем, весело живём,  
Хотя и снег за окном.  

Вот Сеть опять упала,  
Я сижу в тишине,  
Чему и рад вполне.  

Припев:  
Я жду ответа,  
Больше надежд нету,  
Скоро кончится лето,  
Это...

Полная версия будет тут:

https://dzen.ru/a/Z8CmP2eHfSYGpw9V

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

Аутстаф-специалист НЕ ХУЖЕ штатного, потому что:

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

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

А вот почему аутстаф-специалист ЛУЧШЕ штатного сотрудника:

• Широкий диапазон навыков и решений за счет участия в разносторонних проектах.

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

• Фокус на результат. Аутстаф-специалисты сосредоточены на выполнении конкретных задач. Они более продуктивны, в отличие от штатных сотрудников, которые могут отвлекаться на корпоративные процессы.

• В стороне от конфликтов. Аутстаф-специалисты не вмешиваются во внутренние споры, корпоративные интриги и политику компании, поэтому реже отвлекаются от работы.

Читайте также:

- Честное мнение разработчика про аутстаф
- Видео для тех, кто предпочитает YouTube
- Аутстаф глазами руководителя направления

Если вашему проекту нужны опытные аутстаф-специалисты, то можем обсудить сотрудничество.

В недавней книге про построение успешной карьеры в IT в качестве менеджера, отдельным пунктом идет пункт про ИИ, в котором автор призывает тимлида разрабатывать политику использования ИИ в своей команда и согласовать её с политикой использования ИИ в компании. В вольном пересказе это звучит примерно так:

"Как ведущий разработчик, одна из ваших ключевых обязанностей — оценивать и интегрировать новые технологии, включая инструменты искусственного интеллекта (ИИ), в процессы разработки. Рассматривая возможность принятия или отказа от внедрения инструментов ИИ, важно сохранять сбалансированный подход, который ставит во главу угла потребности команды, конкретные преимущества технологий и потенциальные риски.

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

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

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

Собственно есть парочка вопросов:

1. Используете ли вы лично какие-то ИИ-инструменты для работы?

2. Требует ли компания от вас, чтобы вы согласовывали использование ИИ?

3. Считаете ли важным регламентировать использование ИИ-инструментов?

4. Есть ли у вас в компании формальные правила использования ИИ в виде регламента?

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

Стартапы

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

Редкий спрос на специалистов. Аутстаф в стартап заказчика — это ограниченная история из-за ресурсов и количества работы. Обычно они берут одного-двух человек, и нет смысла предлагать еще.

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

Крупные компании

Проблема с доступами. У корпораций работает целая служба безопасности, через которую нужно получать доступы к системам. И делается это мучительно долго.

Что вы замечали особенного в работе на аутстафе в корпорации? Пишите в комментариях.

Читайте также:

- Честное мнение разработчика про аутстаф
- Видео для тех, кто предпочитает YouTube
- Аутстаф глазами руководителя направления

Если вашему проекту нужны опытные аутстаф-специалисты, то можем обсудить сотрудничество.

Чему культовые аниме могут научить менеджеров аутстафф-проектов

Управление проектами, особенно в аутстаффинге, это не то, чему учат в школе или универе. Об этом не пишут учебники, не снимают документалки на Discovery, не делают инструкции на трех языках. В общем, тонкости этого ремесла всем приходится осваивать на практике.

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

• «Наруто» учит преодолевать сложности, связанные с адаптацией специалиста в новой команде и с его онбордингом. Вспомните, как наставник Какаши объяснял Наруто правила команды 7.

• «Моя геройская академия» учит разрешать конфликты и строить доверительные отношения. Например, Аизава и Всемогущий проводят регулярные 1-to-1 с учениками.

• «Токийский гуль» учит следить за качеством работы. Так гулевые отряды несколько раз замечают, что их действия на заданиях не согласованы и что это всем мешает. После этого командиры внедряют четкие процессы.

• «Атака титанов» учит создать все условия для того, чтобы заказчик давал полную и своевременную обратную связь исполнителю. Так, например, поступают командиры, когда бывают недовольны отрядами.

• «Тетрадь смерти» учит минимизировать риски утечки данных и строго соблюдать юридические нормы. Помните, как Кира внушал союзникам, как важно следовать его инструкциям? 

• «Магическая битва» учит тщательно подбирать специалистов под запрос клиента. Например, учитель Годзё подбирает под каждую миссию тех учеников, чьи компетенции позволят решить задачу эффективнее всего.

• «Моб Психо 100» учит эффективно презентовать свои знания и навыки, чтобы получать достойную оплату. Тот же Рейген объясняет потенциальным клиентам, что услуги хорошего экстрасенса точно не будут дешевыми.

• «Токийские мстители» учит выстраивать диалог со сложными ЛПРами. Такимичи вынужден то и дело договариваться с другими персонажами, чтобы изменить события будущего. И в этом ему помогает гибкость.

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

Мы провели большое интервью сотрудников и узнали парочку интересных моментов, раскрывающих правду жизни аутстаф-специалистов. Уже рассказали, с какими проблемами они сталкиваются. А теперь поделимся, почему разработчикам нравится работать в аутстаф-компаниях?

«Проще жить, когда чувствуешь поддержку компании за спиной»
Аутстаф-специалисты подметили, что им спокойнее, когда компания берет на себя все заботы по поиску проектов, договоры с HR-ами, руководителями и прочее.

«Подбираем проект, на котором интересно работать»
Account Head уточнила, что руководители заинтересованы вывести сотрудника на проект, над которым ему нравится работать, где он будет мотивирован сделать много и хорошо.

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

Это неполный список, предлагаем дополнить его в комментариях. Какие плюсы вы видите в работе на аутстаф?

Читайте также:

- Честное мнение разработчика про аутстаф
- Видео для тех, кто предпочитает YouTube
- Аутстаф глазами руководителя направления 

Если вашему проекту нужны опытные аутстаф-специалисты, то можем обсудить сотрудничество.

Мы провели большое интервью сотрудников и узнали парочку интересных моментов, раскрывающих правду жизни аутстаф-специалистов. Для начала расскажем про сложности, с которыми сталкиваются наверняка все, кто пришел на аутстаф-проект:

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

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

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

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

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

Пишите в комментариях, с какими еще проблемами сталкивались вы как аутстаф-специалисты?

Читайте также:
Аутстаф глазами руководителя направления
Честное мнение разработчика про аутстаф
Видео для тех, кто предпочитает YouTube

Если вашему проекту нужны опытные аутстаф-специалисты, то можем обсудить сотрудничество.

Архитектурный надзор и анализ трейсов

В новом выпуске НЕмитапа — проекта, где наши инженеры рассказывают про инструменты и подходы — Ваня Нещадин, техлид команды Bridge, делится опытом, как в Авито обрабатывают 5 миллионов трейсов в сутки.

Из видео вы узнаете:

• зачем вообще обрабатывать такой объем трейсов;

• с чего начинали, какой была архитектура сервиса;

• graceful degradation (GD): что это, как найти и устранить GD;

• уровни критичности сценариев и сервисов.

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

Смотреть VK
Смотреть YouTube

Подписывайтесь на канал AvitoTech в Telegram, там мы рассказываем больше о профессиональном опыте наших инженеров, проектах и работе в Авито, а также анонсируем митапы и статьи.

Ответ на этот вопрос очевиден — выгода.

Экономия затрат на HR
Наем сотрудника в штат — многоэтапный процесс: найти кандидатов, провести несколько собеседований, онбординг, не говоря о куче бюрократической работы. В случае с аутстаф-компаниями, заказчику предлагаются проверенные специалисты с готовыми резюме, которых можно собеседовать и быстро подключить: в среднем за 3–7 дней уже реально вывести человека на проект.

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

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

Экономия времени
Аутстаф-разработчики – ребята с опытом, поэтому обучение, организация рабочего места и внедрение в процессы проходит в разы быстрее.

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

Если вашему проекту нужны опытные аутстаф-специалисты, то можем обсудить сотрудничество.

Читайте также:
- Честный материал о том, как Doubletapp взаимодействует с заказчиками и готовит специалистов к аутстаф-проектам
- Мнение разработчика про аутстаф
- Видео для тех, кто предпочитает YouTube

Для начала разъясним, что такое бизнес-юнит:

Это выделенное подразделение в компании с собственной структурой и стратегией. Если совсем просто – маленькая компания в большой. 

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

• Аутстаф помогает пережить все колебания рынка, так как специалисты работали и продолжают это делать в корпорациях, отличающихся стабильностью. 

• 70% собеседований с клиентом заканчиваются успешно, это значит, что аутстаф-специалисты Doubletapp имеют постоянную коммерческую загрузку

• Работа на аутстафе удачно вписывается в концепцию роста сотрудника от стажера до мидл/мидл+ в корпорации.

• Сотрудники Doubletapp довольны опытом работы на аутстаффе и готовы идти на новые проекты. 

Если вашему проекту нужны опытные аутстаф-специалисты, то можем обсудить сотрудничество.

Читайте также:
Честный рассказ о том, как мы готовим специалистов, выводим на проекты и взаимодействуем с заказчиками
Мнение разработчика про аутстаф
Видео для тех, кто предпочитает YouTube

Эта встреча могла быть сообщением в чате: 6 проверочных вопросов

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

Перед тем как назначить встречу, задай себе эти вопросы — они помогут не только чётко определить её цель, но и сделать обсуждение продуктивным:

• Зачем нам нужна эта встреча? Зачем мы проводим эту встречу именно сейчас?

• Что должно измениться после этой встречи? Конкретизируем эти ожидания, уточняем последствия. Какой ожидаемый эффект для команды, проекта или бизнеса? Если ничего не измениться, возможно встреча не нужна;)

• Какой конкретный результат мы хотим получить по итогу встречи? Что будет наилучшим результатом встречи? (Принятое решение, согласованный план, список идей для дальнейшего обсуждения, подписанный документ и т.д.).

• Что случится, если встречу не проводить? Если ответ — «ничего страшного», значит, её можно заменить асинхронным обсуждением.

• Кто должен участвовать, а кого можно не звать? (Частая проблема — на встречах слишком много людей или наоборот не хватает нужных.).

• Какие решения/информация нужны до встречи? (Если участники придут неподготовленными, встреча может затянуться и быть бесполезной. Этот вопрос помогает заранее собрать данные).

Разработчик под ником madprops предложил способ для быстрого поиска команд в терминале

«Я очень часто обращаюсь к истории действий в shell, чтобы снова и снова запускать одни и те же команды. Пока нет эффективного способа сделать это. Я думаю, что это проблема, которую нужно решать с помощью специализированного инструмента. Я могу попробовать сделать инъекцию оболочки с помощью rofi позже. Но сейчас я придумал трюк, который помогает в работе. Добавьте значки к командам, чтобы вы могли мгновенно распознавать их по стрелкам вверх:

• : ✅;./utils/check.sh

• : ⚡;./scripts/tag.py

• : 📚;./scripts/makedocs.sh

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

ME:
You an expert Java programmer. Your job is to create PlantUML diagramm for the provided code.

LLM:
Creating a PlantUML diagram for the provided code involves understanding the relationships between the classes, their methods, and their interactions. Below is a PlantUML diagram that represents the key classes and their relationships based on the provided code.

AI сильно изменит подход к разработке и DevOps:
Знание и умение запоминать огромное количество технических деталей отходит на второй план, по сравнению с умением формулировать мысли и задавать вопросы.

LLM это как новый компилятор, только вместо кода, мы отправляем ему вопросы на естественном языке и куски кода на проверку.

Если раньше языки программирования оптимизировали для человека, то сейчас AI-Assisted разработка, приведет к тому что структура кода нужно будет оптимизировать для AI.

Машине все равно это camelCase или snake_case и разбита ли ваша программка на сотни файлов в десятках директорий. Машине «удобнее» если все токены будут в одном файле.

yek

git clone https://github.com/apache/iceberg.git
cd iceberg
ls arrow/src/main/java/org/apache/iceberg/arrow
ArrowAllocation.java		DictEncodedArrowConverter.java
ArrowSchemaUtil.java		vectorized
yek --json

2025-02-15T11:56:02.751663Z DEBUG Not a Git repository or unable to open: "."
/var/folders/kr/bxl1m6050xnbq5glx1nbfrx40000gn/T/yek-output/yek-output-ba15253a25ac66a21beb1f5433405467913ac2354fa1fa0c47eed2cc6220cc6a.json
(base) anton@Antons-Mac-mini arrow % ls -lhat /var/folders/kr/bxl1m6050xnbq5glx1nbfrx40000gn/T/yek-output/yek-output-ba15253a25ac66a21beb1f5433405467913ac2354fa1fa0c47eed2cc6220cc6a.json
-rw-r--r--@ 1 anton  staff   192K 15 фев 14:56 /var/folders/kr/bxl1m6050xnbq5glx1nbfrx40000gn/T/yek-output/yek-output-ba15253a25ac66a21beb1f5433405467913ac2354fa1fa0c47eed2cc6220cc6a.json

🌱Объясняем основы риск-менеджмента на репке

В известной русской сказке один дед посадил репку. Она выросла огромной, дед решил вытащить её, но не смог — в одиночку такой проект просто так не затащить. Тогда он собрал команду: позвал бабку, внучку, Жучку, кошку и мышку. Только благодаря командной работе дед справился с задачей.

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

🔮 Риск роста: будь готов к неожиданностям
Когда дед инициировал проект (сажал репку), он вряд ли предполагал, что она вырастет такой огромной. В реальной практике проект вида «репка-переросток» встречается не так уж и редко. Мог ли дед что-то с этим сделать? Конечно мог! 

Что можно сделать:

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

• На этапе планирования ответить на вопрос «а что нам будет нужно, если…?» и строить планы с учетом возможных рисковых событий. 

• Основываясь на риск-плане, сформировать резерв ресурсов — времени, денег и прочего. Например: «Сколько времени понадобится дополнительно, если репка будет зреть долго?», «Кто в итоге участвует в сборе урожая?» и так далее.

👥 Риск недооценки команды: отсутствие подготовки
Деду пришлось собирать команду по ходу дела. Если бы он сразу оценил возможные сложности, подготовил ресурсный план и заранее распределил роли, то, возможно, всё прошло бы быстрее.

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

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

Главное, что дед мог понести неприятные для него затраты на срочное привлечение команды. И вот тут уже всё могло быть не так просто: Жучку, может, и достаточно погладить по голове со словами «ну кто тут хорошая девочка?», а вот кошка вряд ли стала бы работать без гарантий элитного корма.

Что можно сделать:

• Сформируйте ресурсный план и соберите команду заранее, продумав роли каждого.

• Убедитесь, что все участники понимают задачу и готовы приступить к работе.

🧩 Риск несогласованности: тянуть в разные стороны
В сказке все участники тянули за одну сторону репки, что обеспечило успех. А вот в IT-проектах часто возникает «перетягивание каната» — каждый тянет в свою сторону.

Причин может быть масса, но на выходе вы можете получить полную несогласованность действий: дед с бабкой тянут в разные стороны, мышь со своими друзьями-кротами могут попытаться сделать подкоп, а внучка со словами «ваши технологии устарели!» может подложить динамит, чтобы репка вылетела с эффектным взрывом. 

Что можно сделать:

• Заранее определить подход и технологии.

• Убедиться, что цели и задачи понятны всей команде.

• Настроить регулярный мониторинг и следить, чтобы все двигались в одном направлении. 

⚠️ Риск упущенных возможностей: вовремя привлечь помощь
Мышку позвали в последнюю очередь, хотя ее вклад оказался решающим. А ведь иногда именно «незаметные», но важные участники команды (например, аналитик или DevOps) могут посоветовать лучшее решение.

Что можно сделать:

• Слушать мнения всех членов команды, даже если они временные участники.

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

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

P. S. Первый пост из этой серии — про инфобез и семеро козлят.

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

Agile нужно искать не Jira, а в рабочем окружении, которое не должно мешать постоянному самоусовершенствованию и экспериментам.

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

Время разработчика еще никогда не было настолько дороже, чем железо. Просто добавьте CPU и RAM.
Amazon, Oracle, Google на полную катушку, используют свою же инфраструктуру для разработки. Это не «догфудинг» – скорее они пьют свое же собственное шампанское.

Быстрая итерация становится средой, в которой рождается (а не насаждается сверху) Agile.

Как внедрить ML Autotasking в отделе продаж и что из этого выйдет

Рома Захаров, руководитель аналитики юнита ML Autotasking в коммерческом департаменте Авито, делится опытом, как использовать аплифт от касания менеджера для ранжирования его задач. Почему это влияет на рост эффективности работы и какие проблемы могут возникнуть при создании MVP? Из доклада вы узнаете про:

• аплифт как наиболее правильную метрику эффективности менеджера;

• автоматизацию выбора клиентов, с которыми будет взаимодействовать менеджер;

• механику сбора датасета для обучения модели — почему это было непросто;

• сравнение ранжирования клиентов моделью против бейзлайнового алгоритма;

• сложности, возникшие при внедрении модели.

А здесь ссылка для тех, кто привык смотреть на YouTube.

Подписывайтесь на канал AvitoTech в Telegram, там мы рассказываем больше о профессиональном опыте наших инженеров, проектах и работе в Авито, а также анонсируем митапы и статьи.

Senior-разработчик: интроверт с большим опытом VS экстраверт, но опыта меньше

Кого выбрать в свою команду?

>> Рассказывает Илья, директор департамента разработки в ЮMoney.

Тут всё, конечно же, зависит от контекста. Если у меня в команде ребята-мидлы, которых нужно растить и обучать, выберу человека, который умеет разговаривать — с хорошо прокачанными софтами. Сегодня в компаниях у разработчиков нет проблем с технической экспертизой (хард-скиллами) — очень уж много доступных материалов и курсов, где можно научиться тому, что нужно. А вот с мягкими навыками у большинства разработчиков сложнее, и натренировать их так же быстро, как харды, не получится.

3 греха в софтах айтишников 😈

• Отсутствие критического мышления. Это когда человек к каким-то своим убеждениям не может отнестись критически и переубедить его невозможно. Из-за этого возникают споры в командах.

• Когнитивные искажения. Под одними и теми же словами и фразами люди могут подразумевать разные вещи. И это тоже приводит к конфликтам.

• Неспособность вовремя остановиться и не работать, когда рабочий день закончился. В ЮMoney есть процесс проверки здоровья команды — Health Check, и среди вопросов есть пункт про нагрузку команды с градацией ответов от «Всё в порядке» до «Мы горим и проектов слишком много!». Если столкнулись со вторым случаем, я встречаюсь с директором департамента проектов, вместе разбираем отчёты по командам и решаем, что можно сделать, чтобы стало легче. Иногда точечно обращаемся к тому сотруднику, которому тяжело, предлагаем помощь. Может, у него вообще проблемы не на работе, а дома: это разбираем вместе с HR BP. Бывают и случаи, когда PM (проектный менеджер) взял слишком много задач и нагрузка возросла так, что стало дискомфортно. Обсуждаем с ним проблему и снижаем нагрузку на команду.

***

Хочешь тоже работать в ЮMoney? Откликайся на наши вакансии! 😉

Сэм Альтман сообщил, что GPT-5 будет бесплатной, а следующей нейросетью OpenAI станет GPT-4.5.

Альтман признал, что сам устал от десятков моделей с разными названиями и неясными функциями — с GPT-4.5 в компании начнут возвращение к понятному неймингу. С GPT-5 номерные модели будут объединять сразу все функции и сами определять, когда им дать короткий, но быстрый ответ, а когда уйти в длительное размышление.

Также GPT-5 запланирована быть бесплатной с неограниченным доступом к чат‑боту и всем функциям, но с базовым уровнем мощности. У нейросети будет несколько ступеней: основная для обычных пользователей, продвинутая для Plus‑подписчиков и мегамощная за $200. Ждать GPT-4.5 осталось несколько недель.

Должен же тимлид смотреть Merge Request (Pull Request)? 

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

• контролировать качество кода программистов команды;

• следить за соблюдением принятых стандартов;

• управлять рисками кодовой базы команды;

• обучать участников команды через ревью их кода;

• держать руку на пульсе того, чем занимаются участники команды. 

Однако что делать, если у вас кросс-функциональная команда, состоящая из двух бэкендеров, пары фронтендов, QA и аналитика? Нужно ли вам просматривать все их MR? Сможете ли вы адекватно оценить код на PHP, код на React + TypeScript и автотесты на Python? Очевидно, что нет. 

Для разрешения данной ситуации вы можете:

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

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

Попросить самого опытного разработчика функциональной команды (например, техлида всех фронтендов) просматривать ревью вашего фронта, чтобы всё было хорошо. Но это быстро превращается в узкое место, когда ваши MR ждут ревью неделями, замедляя все релизы.

 Как поступить?

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

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

Автоматическое распределение код-ревью среди всех участников функции (все фронтенды, все бэкенды), вне зависимости от проекта, с фиксацией лица, поставившего одобрение. Автоматически напомните человеку, что он превысил установленные компанией сроки на проведение ревью.

То есть программисты из других команд могут не разбираться в вашем домене, но они способны проверить, что код не делает ничего лишнего и корректно функционирует в рамках проекта (при нагрузке, сущностях, подходах). А факт рандомности ревьювера и фиксации апрува, не позволит им проводить ревью формально.

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

В итоге, если тимлид вместе с техническими лидерами выстроит жёсткую систему доставки инкремента на продакшн, ему самому не обязательно просматривать каждый MR своей команды. Исключение составляют лишь те случаи, когда «душа просит».

P.s. Рекомендую: Эволюционная архитектура - автоматизированное управление программным обеспечением - Нил Форд`