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

🦋 Почему «перезагрузка» — это не опция, а продуктовая необходимость

Я боюсь «ломать» то, что работает. Боюсь потерять стабильность и контроль.

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

Факт:

Когда гусеница превращается в бабочку, в коконе происходит жестокий биохимический процесс.

Всё тело гусеницы буквально растворяется в суп-пюре. Я себе это вижу не иначе, как финал "Терминатор 2: Судный день" под ту же музыку.

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

Но шутки в сторону. Происходит не улучшение гусеницы. Это не «апгрейд» и не «ребрендинг».

Это- смерть одной формы и рождение совершенно другой. Старая система уничтожается, чтобы дать жизнь новой.

Менеджерская боль:

А мы в это время:

-Цепляемся за «успешные процессы», которые уже не масштабируются.

-Дорабатываем «проверенные решения», которые давно устарели.

- Улучшаем «старый UI», вместо того чтобы создать принципиально новый продукт.

Мы пытаемся «улучшить гусеницу», боясь признать - чтобы летать, нужно сначала перестать ползать.

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

- Вывод:

Настоящий прорыв требует не улучшения, а метаморфозы.

Иногда нужно:

- Разрушить текущую структуру.

- Отказаться от «работающих», но уже ограничивающих процессов.

- Пересобрать продукт с нуля, а не наращивать техдолг.

Да, это страшно. Да, будет больно. Иногда долго. Даже очень.

И делать это должны не пришлые эксперты. А сама команда.

Но единственное, что страшнее- остаться гусеницей в мире, где все уже летают.

p.s. Было бы безобразием не упомянуть, что гусеницы живут от нескольких недель до нескольких лет. Бабочка-максимум 20 дней.
Но. Цель жизни гусеницы - превратиться в бабочку. Цель бабочки - дать жизнь новым гусеницам.

- Вопрос:

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

https://t.me/howtcp

#крылья_ноги_и_хвосты

🦋 Почему «перезагрузка» — это не опция, а продуктовая необходимость

Я боюсь «ломать» то, что работает. Боюсь потерять стабильность и контроль.

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

Факт:

Когда гусеница превращается в бабочку, в коконе происходит жестокий биохимический процесс.

Всё тело гусеницы буквально растворяется в суп-пюре. Я себе это вижу не иначе, как финал "Терминатор 2: Судный день" под ту же музыку.

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

Но шутки в сторону. Происходит не улучшение гусеницы. Это не «апгрейд» и не «ребрендинг».

Это- смерть одной формы и рождение совершенно другой. Старая система уничтожается, чтобы дать жизнь новой.

Менеджерская боль:

А мы в это время:

-Цепляемся за «успешные процессы», которые уже не масштабируются.

-Дорабатываем «проверенные решения», которые давно устарели.

- Улучшаем «старый UI», вместо того чтобы создать принципиально новый продукт.

Мы пытаемся «улучшить гусеницу», боясь признать - чтобы летать, нужно сначала перестать ползать.

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

- Вывод:

Настоящий прорыв требует не улучшения, а метаморфозы.

Иногда нужно:

- Разрушить текущую структуру.

- Отказаться от «работающих», но уже ограничивающих процессов.

- Пересобрать продукт с нуля, а не наращивать техдолг.

Да, это страшно. Да, будет больно. Иногда долго. Даже очень.

И делать это должны не пришлые эксперты. А сама команда.

Но единственное, что страшнее- остаться гусеницей в мире, где все уже летают.

p.s. Было бы безобразием не упомянуть, что гусеницы живут от нескольких недель до нескольких лет. Бабочка-максимум 20 дней.
Но. Цель жизни гусеницы - превратиться в бабочку. Цель бабочки - дать жизнь новым гусеницам.

- Вопрос:

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

https://t.me/howtcp

#крылья_ноги_и_хвосты

Ссылки и всплывающие подсказки в PlantUML

Всем привет!
Продолжаем тему PlantUML. Сегодня за 5 минут и без воды поговорим о Сылках и всплывающих подсказках в PLantUML

1️⃣ Для добавления ссылки и текста ссылки, используйте конструкцию: [[<URL-ссылки> <Текст ссылки>]]
Пример: [[http://plantuml.com Ссылка (без всплывающей подсказки) на plantUML]]

2️⃣Для добавления: всплывающей подсказки к тексту (с ссылкой), используйте конструкцию: [[<URL-ссылки>{<всплывающая подсказка>} <Текст ссылки>]]
Пример: [[http://plantuml.com Ссылка (без всплывающей подсказки) на plantUML]]

3️⃣Для добавления: всплывающей подсказки к тексту (без ссылки), используйте конструкцию: [[{<всплывающая подсказка>} <текст к которому относится всплывающая подсказка>]]
Пример: [[{всплывающая подсказка} Всплывающая подсказка (без ссылки)]]

🔥 Внимание!!! Чтобы всплывающие подсказки работали у заказчика, выгружайте диаграммы в формат SVG

Пример кода ниже (а ссылка тут), а файл с примером в формате SVG тут:

@startuml
Title **Ссылки и всплывающие подсказки в PlantUML**

' Для добавления: ссылки и текста ссылки, используйте конструкцию: `[[<URL-ссылки> <Текст ссылки>]]`
    Alice -> Bob: [[http://plantuml.com Ссылка (без всплывающей подсказки) на plantUML]]

'Для добавления: всплывающей подсказки к тексту (с ссылкой), используйте конструкцию: `[[<URL-ссылки>{<всплывающая подсказка>} <Текст ссылки>]]`
  Alice -> Bob: [[http://plantuml.com{всплывающая подсказка (с ссылкой)} Ссылка (со всплывающей подсказкой) на plantUML]]

' Для добавления: всплывающей подсказки к тексту (без ссылки), используйте конструкцию: `[[{<всплывающая подсказка>} <текст к которому относится всплывающая подсказка>]]``
  Alice -> Bob:  [[{всплывающая подсказка} Всплывающая подсказка (без ссылки)]]

@enduml

Code Wiki — AI документация репозиториев от Google

Google релизнули новый интересный проект. Code Wiki — википедия с документацией open source репозиториев. А в будущем обещают CLI версию для автоматической документации приватных репозиториев! Неужели документация кода будет теперь всегда актуальной?

Как работает?

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

Code Wiki:

• Помогает найти open source репозитории по нужной тематике. То есть информация о репозитории, видимо, векторизуется и сверху работает семантический поиск.

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

• Автоматически обновляет документацию и все схемы после каждого PR. А значит документация наконец-то всегда актуальна.

Я немного посравнивал документацию от Code Wiki и документацию в самих опенсорс репозиториях. На мой взгляд, в хорошо поддерживаемых open source репозиториях авторская документация, конечно, все равно лучше.

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

Пробуем тут.

Подписывайся на телеграм канал Заместители. Там еще больше интересного про ИИ агентов.

Сколько стоит получить 1 оффер?

Хотите вы этого или нет — но мы уже сделали 330 000 автоматизированных откликов за 5 месяцев. И за это время успели подсобрать кое какие данные.

Рассказываю:

Да, часть из откликов может быть нерелевантной, часть уходит «в молоко», но сейчас уже 40–50% попадают в яблочко.

А есть ли вообще выхлоп? Давайте посчитаем.

За всё время в нашем ассистенте Софи было 434 платных пользователя.
На этих 434 человек мы насчитали 1 956 приглашений на интервью. (Это именно те, что приходят через хх.ру (приглашения в тг или на почту мы не видим - поэтому их может быть и больше)).

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

Средний пользователь заплатил нам 6 500 рублей.
Значит, одно интервью обходится примерно в 2 888 рублей.
Считается, что нужно пройти 3–5 интервью с разными компаниями, чтобы получить 1 оффер.

Итого — около 11 000 рублей стоит один оффер через Софи. Это значит что у кого-то он может выйти в 4500 рублей, а у кого-то в 30000, 40000 или вообще его не быть.

📕📖📚 "Управление победоносной командой" — звучит как отличное название, поэтому я решил ознакомиться со свежей книгой по управлению командами от бывшего бейсбольного тренера, а ныне тренера по лидерству и командной динамике: Трента М. Кларка.

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

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

Стиль изложения максимально напоминает книгу "45 татуировок менеджера" Максима Батырева, которую многие называют жёсткой, что подчёркивает, что человек пришёл из спорта, где высокие ставки и высокая награда за результат, и какие-либо оправдания не принимаются.

__

В основе "Управление победоносной командой" лежат три взаимосвязанных столпа: командная работа, мотивация, стратегия.

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

Эти истории подчёркивают главный принцип: настоящие команды процветают благодаря SPARC — Духовности, Продуктивности, Ответственности, Обязанности и Обучаемости, — концепции, разработанной Кларком для формирования устойчивости.

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

___

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

SpaceWeb открыл расширенную API-документацию для веб-мастеров и DevOps-инженеров

SpaceWeb расширил публичную API-документацию. В открытом доступе появились методы для управления ключевыми облачными сервисами: балансировщиками нагрузки, бэкапами, мониторингом, базами данных, почтой и DNS-записями.

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

Что изменилось

В документации появились полноценные методы для работы с основными сервисами платформы:

• балансировщик нагрузки;

• облачные бэкапы;

• управление IP-адресами;

• мониторинг ресурсов;

• почтовые сервисы;

• DBaaS;

• DNS-управление.

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

Зачем это нужно

Расширенная API-документация помогает специалистам глубже контролировать инфраструктуру и встраивать управление ресурсами в собственные процессы. 

Теперь пользователи могут:

• отслеживать метрики потребления и интегрировать их во внутренние системы мониторинга;

• ускорять развертывание окружений;

• автоматизировать управление политиками бэкапов и масштабирование сервисов.

SpaceWeb продолжает развивать платформенное API и движется к модели Infrastructure as Code. В ближайших релизах появится поддержка Terraform и Ansible, чтобы пользователи могли включать управление облачными ресурсами в CI/CD-пайплайны, автоматизировать инфраструктуру и сокращать время вывода IT-продуктов на рынок. Ознакомиться с API-документацией можно на сайте SpaceWeb

Анимация интерфейса в приложении Discord нагружает ПК. Речь идёт о трёх точках, которые появляются, когда кто-то на сервере пишет сообщение. В режиме покоя Discord нагружает процессор на 1%, а при появлении этой анимации — на 10-15%. От этого бага страдает так много пользовательских систем, что даже появился плагин (проверка урла на VirusTotal), отключающий анимацию.

Легендарный разработчик культовых игр Джон Кармак посоветовал разработчикам на Python никогда не переназначать и не обновлять переменную вне итеративных вычислений в циклах. По его словам, наличие всех промежуточных вычислений полезно в отладчике и позволяет избежать проблем, когда при перемещении блока кода он автоматически использует версию переменной, отличную от изначальной. А вот в C/C++ хорошей практикой является инициализация практически всех переменных как const. Кармаку хотелось бы, чтобы это было сделано по умолчанию, а mutable было ключевым словом.

Ранее на Хабре был пост: "17 открытых репозитариев, чтобы выучить Python с нуля".

ИИ в продакшн: где заканчивается хайп и начинается реальная польза

Полгода назад Дарио Амодей из Anthropic заявил: к сентябрю 2025 года 90% кода будут писать нейросети — не помощники, а полноценная замена разработчиков.
Наступил ноябрь. Пророчество не сбылось — но IT-индустрия изменилась радикально. Теперь в компаниях раскол — кто-то жалуется, что нейросети только перегружают всех, а кто-то обучает ИИ на замену рутине.

На конференции AI Boost эксперты от Сбера, Магнита, Атол и Surf обсудили, что изменилось за последние полгода и как ИИ-агенты на самом деле работают в продакшене разработки. Получилась честная и горячая дискуссия, как команды бигтеха и ИТ-компаний переходят на ИИ и что стало с ролью разработчика. Смотрите запись самого обсуждаемого круглого стола конференции, из которой узнаете:

• Почему люди всё ещё пишут 90% кода и как команды учатся использовать AI-агентов в реальной работе.

• Чем хороший джун отличается от ML-модели и что ждёт джунов в мире, где их задачи уже умеет решать AI.

• Можно ли доверить нейросетям проектирование сложных систем и где проходит граница ответственности человека.

• Стоит ли перестраивать SDLC ради ИИ или достаточно встроить новые инструменты в существующие процессы.

• Почему спагетти-код может стать нормой.

• Может ли вообще ИИ заменить разработчиков — или все это так и останется хайпом.

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

Евгений Сатуров, CTO Mobile в Surf

Спикеры:

• Дмитрий Панычев — Head of Seller Development в Magnit OMNI

• Глеб Михеев — лидер трайба «Цифровой ассистент» в Сбере, автор телеграм-канала «Уставший техдир»

• Владимир Кочегаров — Head of QA в компании Атол

• Евгений Сатуров — CTO Mobile в Surf

Смотрите полную запись круглого стола на YouTube.

Экс-инженер Nvidia Чип Хьюен (Chip Huyen, исследовательница ИИ, которая раньше работала над платформой NeMo в Nvidia и преподавала машинное обучение в Стэнфорде) считает, что неважно, что именно вы создаёте, главное — пройти путь от идеи до готового решения, которым сможет воспользоваться кто-то другой.

По словам Хьюен, строить что-то с нуля могут и должны не только инженеры. Например, даже начинающие пользователи без технического образования благодаря ИИ-ассистентам для кодинга могут создавать рабочие проекты. «После этого они становятся гораздо увереннее в себе и лучше понимают, как работает ИИ», — пояснила Хьюен.

Тем, кто не знает, с чего начать, Хюен предлагает простое упражнение: в течение недели записывать всё, что раздражает — от рутинных задач до медленных процессов. А потом выбрать одну проблему и попробовать её решить. При этом важно не ограничиваться только практикой. «Учиться только через проекты — всё равно что осваивать новый язык, просто разговаривая», — отмечает Хьюен. Чтобы разобраться в инструментах, стоит изучить теорию — выбрать учебный курс, книги или структурированную программу.

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

Снежные вершины и карьерные высоты: как все совмещать?

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

• как выглядят команды внутри Авито и как различается их функционал?

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

• как проводить собеседования и качать софт-скиллы?

• и конечно, как расслабляться, покоряя снежные вершины?

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

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

Айтишников пытаются вернуть в офисы и “заставить” работать?

Недавно прочитал в одном издании, что на IT-рынке США намечается новый тренд: сразу несколько экспертов отрасли заявили о необходимости увеличивать рабочее время разработчиков и возвращать их в офисы.  Эксперты намекают на 12-часовой рабочий день и шестидневку. Пишут, что уже сейчас в Кремниевой долине ИИ-стартапы снова начинают организовывать труд по принципу “работа-проживание - сон” в офисе.  Цель всего этого - удерживать лидирующие позиции в технологической гонке с Китаем.

Как мне кажется, вокруг темы ИИ в разработке сейчас слишком много хайпа. Гонка между США и Китаем действительно есть: выиграет тот, кто создаст AGI - общий искусственный интеллект, сравнимый с человеческим. При этом, не все понимают, что сам по себе AGI, возможно - несбыточная мечта.

Этот “пузырь” хайпа раздувается все сильнее, пока никто не вмешивается в деятельность этого сектора. Приставку “AI” и возможности искусственного интеллекта “запихивают” едва ли не в каждый сервис. Без этого продукты хуже продаются. Сотрудников заставляют использовать ИИ, вводят метрики и делают подсчеты, однако по факту на данный момент AI помогает в очень ограниченном числе задач.

Почему разработчиков “загоняют” в офисы? Считается, что в офисе все работают продуктивнее и не отвлекаются. Но корни проблемы стоит искать не здесь. В России, например, голод на талантливых инженеров только усиливается. Волна найма “айтишников с нуля” после трехмесячных курсов закончилась, но проблема никуда не делась: с помощью современных инструментов, в том числе и ИИ, компании могут быстро создавать MVP продукта , а вот с их поддержкой и развитием начинаются проблемы.

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

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

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

Ресурс Clone Wars содержит более ста клонов самых полезных сервисов. Например, с помощью этой библиотеки можно разобраться в устройстве самых хайповых программ и попрактиковаться в коде. Есть буквально всё, в том числе и клоны сервисов, ушедших из России: Notion, Spotify, YouTube, TikTok, Discord, Dribble, Dropboх и прочее. Детальный разбор устройства каждого сервиса, кода, архитектуры и функционала, а также советы по его воссозданию. Можно стащить использовать многие решения в своих пет‑проектах.

Давно слышали про Nokia? А они то никуда не пропали…  

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

Для тех, кто не застал историю взлета и падения финской гиперкорпорации поясню. В 2000х модель 3310 произвела абсолютный фурор. Совершенно неубиваемый кирпич с встроенной игрой «змейка» стал мечтой многих вне зависимости от пола и возраста. Потом была эра смартфонов, где Nokia тоже неплохо себя чувствовала. Но затем пришел Apple и 2008 год стал началом конца для многих компаний (в том числе для blackberry, но речь не о них).

Нет бизнеса — нет компании. Зачем за ней следить? А бизнес-то есть, причём с выручкой 20+ млрд $! Никак не ожидаешь увидеть такую цифру, говоря о компании, которая вроде как вообще закрыться должна была. В чём причина, как они оттолкнулись от дна и чем вообще занимаются?  

На самом деле, причина в человеке по имени Раджив Сури. Он долгое время работал в Nokia и к моменту известного коллапса был директором подразделения Nokia Solutions & Networks (раньше называлось вместо Solutions — Siemens), которое занималось телеком-оборудованием и сетями.  

После того, как подразделение мобильников погибло, у Nokia вообще осталось только NSN и Nokia Technologies. К тому времени Сури уже показал всем, что такое чёткое видение и бескомпромиссный менеджмент. Пока все хайповали на рынке мобильников, он прекрасно понимал, что почва под ногами нестабильно и что надо развивать что-то, что будет нужно всем, вне зависимости от меняющихся вкусов клиента.

Так что своей зоной фокуса он сделал именно развитие сетей и телеком оборудования, что до коллапса вообще не было ключевым направлением Nokia. В самые жаркие времена (с 2009 по 2012) он устроил реструктуризацию в убыточном NSN, сократил несколько тысяч человек (ага, операционная эффективность) и сфокусировал всю работу на B2B и развитии технологий связи (2G, 3G, 4G). Все его усилия привели к тому, что NSN показывала рост и прибыльность, что вообще позволило Nokia не уйти в небытие.  

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

Под его руководством была приобретена Alcatel-Lucent, чтобы не конкурировать, а создать самого крутого производителя сетевого оборудования, чтобы дать отпор Ericsson и Huawei.  

Кроме того, видя, как прогрессирует технология связи, он сделал ставку на развитие 5G, чем и занимался с помощью своей R&D структуры, денег на которую он не жалел.  

По итогу, умирающая Nokia сейчас в топ-3 поставщиков телекоммуникационного оборудования по всему миру, с долей примерно 25% и оборотом 20+ млрд.  

Чем мне так понравилась эта история? Для меня самыми ценным тут являются 2 вещи.  

1. Чёткое видение будущего и умение отбросить всё, что неважно, что как раз и показал Сури.  

2. Как фокус на, возможно, не самом хайповом, но очень перспективном активе, может спасти почти что умирающий бизнес.

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

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

ВкусВилл объявляет о ребрендинге Автомакона и переименовывает его в «ТехВилл» — технологии, которые двигают ритейл вперед

ВкусВилл проводит ребрендинг своей технологической «дочки» — компании Автомакон. Новое название — «ТехВилл» (полное наименование — «Технологии ВкусВилл») — отражает смысл и миссию компании: создание современных ИТ-решений, которые уходят в основу развития ритейла будущего. В ближайшее время к ТехВиллу присоединятся ООО «ДатаЛаб» и ООО «Фулстек». 

В июле 2025 года ВкусВилл объявил о завершении сделки по приобретению части структур ГК “Автомакон” (ООО «Автомакон», ООО «ДатаЛаб», ООО «Фулстек»), которые занимались развитием информационных технологий сети ВкусВилл в течение последнего десятилетия. Этот шаг стал началом нового этапа в развитии ИТ ВкусВилла, больших перспектив для расширения возможностей и реализации новых амбициозных проектов для обеих компаний и сотрудников. 

Логичным продолжением стало концептуальное брендинговое объединение трёх компаний. Название “ТехВилл” родилось из желания сохранить сильную связь с материнским брендом ВкусВилл, при этом отразить технологическую составляющую компании. Это не просто игра слов — это отражение ДНК компании: технологии, встроенные в повседневную жизнь покупателей и сотрудников ВкусВилла.

ТехВилл будет заниматься теми же задачами, что и прежде, но под новым, ярким и понятным названием: разработкой программного обеспечения как для покупателей (мобильное приложение, сайт, сервисы доставки, персонализация), так и для внутреннего пользования (системы управления складами, логистикой, аналитикой, CRM, автоматизация магазинов). Фокус работы — создание технологий, которые делают ВкусВилл лидирующим технологическим ритейлером в России.

Помимо ребрендинга и создания бренд-бука компании со своими атрибутами, команда запустила новый сайт techvill.ru, который стал полноценной платформой, на которой можно узнать о технологиях компаний, услугах, открытых вакансиях и принципах работы. Сайт станет витриной для IT-специалистов, партнёров и всех, кто интересуется цифровой трансформацией ВкусВилла.

“Мы запустили трансформацию бренда, чтобы он отвечал текущим вызовам рынка и нашим амбициям. ТехВилл — это полноценный технологический центр компетенций внутри экосистемы ВкусВилла. Мы видим его как новатора, который будет формировать цифровое лицо компании в ближайшие годы. Мы объединяем развитие и масштабирование существующих решений. Но как и в любом тех-бизнесе — двери для инноваций всегда открыты. Главное — стабильность, качество и соответствие потребностям пользователей”, — Дмитрий Апаршев,  Управляющий по ИТ ВкусВилл.

​​Про AI-ускорение рутины разработчиков, которого... НЕТ! ч.3. В предыдущих частях мы смотрели годные исследования от том, как AI влияет на результаты работы, со стороны самого разработчика (раз, два). 

А теперь быстро посмотрим на результаты труда разработчиков! Ведь бешеный прирост эффективности (которого нет) должен быть виден невооруженным взглядом.

1️⃣ Если легко завайбкодить простые приложения, то они должны наводнить сторы. Statista говорит нам, что никакого прироста нет ни в App Store, ни в Google Play. Нет всплеска ни количества новых доменных имен, ни количества игр в Стиме.

То есть даже у индихакеров нет никаких «закодил приложение за три дня, люди пользуются». Но наверняка есть «три дня вайбкодил, но давать пользоваться таким нельзя».

2️⃣ Более того, нет даже значимого прироста числа github репозиториев! А ведь с революционной технологией разработчики должны запускать сайд‑проекты намного быстрее.

Данные из innovation graph, по которому можно проанализировать даже пики ru‑релоканотов в эмигрантских лимбах 🙂 (пост).

3️⃣ То есть подавляющее большинство говорящих о 10х эффекте от вайбкодинга и кодинга с AI никогда не пробовали ни вайбкодить, ни писать код. В работе это может выглядеть так: менеджер предлагает внедрять AI кодинг инструменты (все же внедряют!) А на деле это ведет к снижению эффективности труда разрабов в компании.

4️⃣ CEO Notion недавно рассказал The Wall Street Journal, что до AI маржинальность продукта была 90%, а после добавления AI фич упала до 80%. Проще говоря, они как лидеры рынка были обязаны добавить фичи, но в итоге теряют на этом деньги (бурного прироста пользователей из-за AI нет).

5️⃣ В реальном айтишном мире написание кода никогда не было узким местом создания софтверных продуктов. И мы сегодня видим на рынке, что AI инструменты скорее дают ощущение эффективности, а не саму эффективность.

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

6️⃣ В посте про AI агентов я предложил на любую реплику AI энтузиаста просить записать скринкаст того, что у него круто работает (кстати в комментах НИКТО из энтузиастов не смог этого сделать).

А на реплики индихакеров про эффективность кодинга с AI можно просить показать, что они накодили.

Платформенная команда: секретный инструмент для масштабирования бизнеса

В ЮMoney мы используем стандартный фронтенд-стек — React, TS, Nest.JS — и микросервисную архитектуру с более чем 70-ю сервисами. По мере роста компании, количества команд и сотрудников в отделе нам понадобились единые стандарты в разработке и общий вектор развития. Эти потребности теперь закрывает платформенная команда.

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

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

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

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

В репозитории Awesome First Pull Request Opportunities больше сотни проектов, в которые новички могут делать пул-реквесты и получать обратную связь и даже советы по изучению программирования. Все проекты разделены по языкам и темам: C#, C++, Java, JS, фронтенд, бэкенд, информбезопасность, мобильная разработка под iOS и Android. Каждый найдет проект и стек. Проекты и репозитории ведут реальные разработчики и постоянно их поддерживают. Каждая команда всегда читает пул-реквесты, часто дает советы по разработке и обучению, обратную связь новичкам и даже шанс попасть на стажировку.

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

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

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

Проблема не в планировании, а в том, как мы планируем. Традиционный подход с фиксацией сроков на старте проекта в условиях высокой неопределенности обречен на провал. Однажды я подумал в чем полезность планирования? Что будет если планирование не проводить? Как это повлияет на разработку? Очевидно, что заказчик чувствует некую уверенность, когда получает сроки реализации задачи. Но это очень условно и польза, на самом деле, не большая. Сроки, как мы уже знаем, все равно сдвинутся и, скорее всего, превратятся в инструмент давления на команду разработки и на самого РП.

Почему же так получается? Те, кто изучают Kanban метод знают, что относиться к процессу разработки нужно как к процессу накопления знаний по данной проблеме (задаче). В процессе реализации и сама команда и заказчик узнают много нового по этой задаче. Каждый в своей зоне ответственности. Получая новые знания вносятся правки как в постановку, так и в техническую реализацию. Получается, если проводить планирование в самом начале, то точность будет основана на почти нулевом знании о задаче. Виной тому очень высокая неопределенность. В самом конце разработки, когда задача уже почти готова к выкатке на прод, все участники уже довольно точно могут сказать, когда задача закроется. Неопределенность низкая и почти отсутствует.

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

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

Дайджест открытых мероприятий МФТИ на октябрь

❗️На все мероприятия требуется предварительная регистрация через телеграм-бота: https://t.me/mipt_events_bot.

Инструмент стратегической канвы для поиска своего ценностного предложения
🗓 8 октября 🕛 18:00 (Мск)

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

Построение распределенных систем: подходы, методы, команда
🗓 9 октября 🕛 19:00 (Мск)

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

Собираем команду стартапа: кого берем сразу, а кого привлекаем чуть позже
🗓 15 октября 🕛 20:00 (Мск)

Составим эффективный план по привлечению специалистов в команду начинающего стартапа, когда еще нет продукта.

Разработчик IT-продукта в 2025 году: роль и современные подходы
🗓 16 октября 🕛 18:00 (Мск)

Узнаем от практикующего специалиста со стажем 10+ лет про современные методологии разработĸи и как разработчику взаимодействовать с бизнесом.

Типы архитектур: основные приложения
🗓 24 октября 🕛 19:00 (Мск)

Разберем основные типы архитектур на примерах и обсудим будущее разработки приложений.

📍У некоторых мероприятий дата и время могут быть скорректированы. Мы сообщим заранее, если такое произойдет

♾️Регистрация через телеграм-бота: https://t.me/mipt_events_bot

Я размышлял над созданием инструмента для вайбкодинга и вот что я понял:

Вайбкодинг — это менеджмент.

Со всеми его плюсами и минусами.

У менеджмента фокус на управление.

У разработки фокус на конструирование.

Для менеджмента нужны прокачанные скилы общения (говорить, слушать, писать, читать на человеческом)

Для разработки нужны прокачанные скилы разработки (говорить, слушать, писать, читать на программном)

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

Как стать сеньором и что делать дальше?

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

• как выглядит головоломка из сеньорских навыков, опыта и подходов?

• почему качественная проверка важнее скорости?

• и всегда ли баланс — это благо?

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

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

Работать в одной команде много лет или менять их несколько раз в год

Обсудили с девчонками-тестировщицами Контура. 💅 Капа Потапова шесть лет в одной команде, Катя Заусова — из бюро тестировщиков, меняет проекты и контекст задач каждые несколько месяцев.

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

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

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

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

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

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

Работа в одной команде даёт больше чувства значимости в успехе продукта

Меняет команды: Конечно, потому что ты регулярно вносишь свою лепту. Но тут ещё важно, чтобы команда рассказывала о своих результатах и успехах, вакуума быть не должно, когда человек думает «У меня есть одна зона ответственности, а на другие даже не смотрю». Чтобы чувствовать свою значимость, тебе нужно хотя бы видеть продуктовые метрики фич.

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

Работа в одной команде может привести к выгоранию из-за однообразия

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

Я спасаюсь тем, что у меня много непроектных активностей, например, мероприятия и обучение.

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

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

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

Приходите послушать и посмотреть выпуск подкаста с Капой и Катей ➡️ YouTube, Rutube, VK, Яндекс Музыка.

Представлен репозиторий Free Certifications с бесплатными сертификациями по IT-технологиям от Google, Oracle Microsoft и других компаний. Все сертификаты строго разделены по категориям: фронтенд, бэкенд, SQL, Data Science, информбезопасность, аналитика и ещё множество тем.

Разработка в 2025 году — это уже не только про умение писать код. Важно уметь работать в связке с ИИ, быстро адаптироваться к новым инструментам и смотреть на задачи шире, чем строки кода. Автоматизация ускоряет процессы, языковые модели становятся полноценным помощником, а кибербезопасность требует внимания как никогда раньше.

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

Что формирует будущее разработчиков

1. ИИ и языковые модели. Инструменты вроде Cursor/Windsurf и LLM помогают быстрее и качественнее выполнять то, что вы уже умеете, или разобраться в новой теме. LLM берут на себя «черновую» работу: исправляют опечатки, улучшают оформление кода, помогают с декомпозицией задач и первичным код‑ревью. Это снижает нагрузку и освобождает время под архитектурные решения.

2. Кибербезопасность. С ростом объема данных и активным использованием ИИ‑решений увеличивается и число атак. В 2025 году безопасность уже не «дополнительная опция», а критически важный аспект разработки. В приоритете: оперативное устранение уязвимостей, поддержка зависимых библиотек в актуальном состоянии, а также проектирование безопасных систем.

Главные скиллы

— Промпт‑инжиниринг и итеративный подход. Чем лучше вы понимаете и формулируете задачу для LLM, тем лучше результат. Разбивайте сложные задачи на небольшие, пошагово уточняйте вводные, добавляйте контекст, референсы и критерии качества.
 — Умение адаптироваться к изменениям. Мир меняется быстро: нужна гибкость и готовность учиться новым инструментам и подходам.
 — Осознанное применение ИИ. ИИ ускоряет рутину, но не заменяет понимания. Код или решения без осознания внутренних механизмов сложнее поддерживать; сырые и неадаптированные ответы часто дороже, чем написать с нуля.
 — Критическое и системное мышление. Хороший разработчик видит систему целиком, задает вопросы, сравнивает варианты и думает на несколько шагов вперед: архитектура, влияние изменений, риски и стоимость владения.

Как развиваться разработчику

1. Книги, курсы и пет‑проекты. Рабочая связка: цель → план → небольшой прототип → разбор ошибок. LLM помогают собрать персональный план обучения: перечисляете, что знаете и что хотите изучить, — получаете черновой roadmap и список практик.

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

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

Как новенький сервис превращается в легаси помойку

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

1 шаг. Восторг и энтузиазм

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

2 шаг. Не хватает тяги

Наша ракета отлично стартанула. Вкушаем первые плоды переписанного сервиса. Радуемся. Но начинаются первые проблемы. Бесплатный пробный период хорошей жизни закончился - нагрузка начинает возвращаться обратно. В начале нам дали люфт. Но халява быстро кончилась — бизнесу снова понадобились фичи "на вчера". Вынуждены меньше фокусироваться на прекрасном будущем и всё больше концентрироваться на грустном настоящем. Начинаем активно поддерживать текущую версию сервиса и параллельно разрабатывать новую.

3 шаг. Кто же убийца?

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

4 шаг. Кто мы и откуда пришли

Энтузиазма поубавилось. Сервис уже переживает первые послабления в качестве в угоду скорости. Надо скорее дописывать MVP. Качество, структура и масштабируемость перестали быть приоритетом. Руководство уже и не помнит, зачем всё это затеяли. Сама идея становится всё более призрачной.

5 шаг. Мы не сеем, мы жнём

MVP готово. Переезжаем на наше новое детище. На старый сервис можно поставить печать [DEPRECATED] и убрать на задворки. Начинаем пользоваться и выполнять новые задачи уже там.

6 шаг. Мне кажется, мы здесь уже были

Через пару недель разработки появляется стойкое ощущение дежавю. Сервис вроде новый, построен аккуратнее. Но почему-то замечаются те же ошибки. Местами - те же подходы. Уже есть зоны кода, в которые никто не решается лезть. "Чёрные дыры" проекта. Да и багов меньше не стало. Мы же не сделали вторую версию такой же кривой, как первая? Мы же могли потратить время и ресурсы впустую? Ведь так?

7 шаг. Убийцей был дворецкий!

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

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

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

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

Четвертое - ретроспективу стоило провести до старта. Определиться какие ошибки были совершены в старом сервисе и учесть их в новом.

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

Заметки в никуда

...и вот у меня спрашивают «А какие у тебя мотивация работать и стимул для развития?», а я говорю «Деньги». Ты бы видел как на меня посмотрели! Как будто ждали какой-то другой ответ. Что мне надо было ответить? Не понимаю. Работать за идею?

Недавно общался со своим другом с прошлой работы и разговор зашел за повышения и performance review. И этот момент ТОТАЛЬНОГО непонимания руководителями желания сотрудника зарабатывать больше мне как-то скребется, я слышал о похожих ситуациях уже немало.

Хотелось бы здесь написать остро "НИКТО!", но буду мягче. Если мы будем честны: мало кто в найме готов работать только за идею. Я уверен, если предложить этому ревьюверу: «Ой, а давай мы твою зарплату попилим на весь отдел? Тебе же хватит идеи?», – он быстро сольется.

Идея – это роскошь. Можешь себе позволить работать за идею, если холодильник забит, ипотека закрыта, есть запас жирка и нет переживаний за деньги. Желательно, запас средств на несколько поколений безбедной жизни. Всё остальное – манипуляция. И пропагандировать нечто подобное с позиции руководителя – это, ну не знаю, бред?

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

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

Отличная компенсация + интересные задачи + адекватный менеджмент = получаем мотивированную команду. Идея и миссия компании – это важно и круто, но это вишенка на торте, а не замена базовым потребностям.

Ценность разработчика. Мысли о том самом…

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

Баланс между качеством и скоростью

Качество и скорость - это две противоположные крайности одного спектра.

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

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

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

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

• иметь возможность базового масштабирования, без фанатизма, но с заделом на возможные изменения завтра

• учитывать временные рамки, воспринимая время как ограниченный ресурс

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

Продуктовое мышление

Хороший разработчик не ограничивается своим куском кода и клочком текста в ТЗ. Перед тем как приступить к задаче, важно выстроить полную картину. Зачем эта задача бизнесу? Кому это нужно? Какую боль пользователя решает? Чего это нам будет стоить? Иногда ответы на эти вопросы проясняют картину лучше, чем ТЗ от менеджера.

Спор "как правильно"

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

Предсказуемость

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

Работа с неопределенностью

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

Долгосрочность решений

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

Заметки в никуда. Подписаться

Пан или MVP пропал! Дебаты на ProductCamp

Уже в эту субботу, 20 сентября, МойОфис организует жаркий баттл продуктологов в формате парламентских дебатов на ProductCamp. Никакой воды и эмоций — только факты и сильные аргументы.

Тема встречи: «Fail Fast наносит больше вреда качеству продукта и духу команды, чем приносит пользы?»

Мы обсудим, может ли быстрая «обкатка» сырой версии подорвать продукт и команду, и бывают ли ситуации, когда Fail Fast действительно оправдан.

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

Дебаты стартуют в субботу, 20 сентября, в 17:00 в большом шатре. Будет жёсткая профессиональная дискуссия без купюр и сантиментов!

Вопрос: оцени сколько времени займет выполнение задачи?

Оценка - это, по определению, предположение.

Так что какое число ни назови столько и будешь работать до следующего такого вопроса 😁

Как не сливать бюджет на разработчиков без задач?

Представим ситуацию. Большой аутсорс, 5 распределённых команд, у каждой обычно в работе по 1–3 проекта. Наступает момент, когда текущий проект сдан, а новый проект ещё не утверждён: документы в стадии подписания, а ТЗ ещё не сформировано. Команда разработчиков ждёт отмашки, возникает свободное время между проектами. Что делать? Бюджет утекает на разработчиков, которые ничем не заняты. Какой выход из ситуации, когда кончились задачи?

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

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

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

Что мы в итоге имеем и в чём выгода?

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

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

Заметки в никуда

Про вайб и прочих ИИ агентов в ретроспективе "лихих 90-х"

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

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

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

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

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

10 лет в AvitoTech — а минусы будут?

В этот раз в гости пришёл Александр Лукьянченко, технический руководитель кластера Architecture. Саша работает в Авито почти 10 лет: компания менялась на его глазах, а сам он прошел путь от разработчика до менеджера высшего звена. В интервью вместе с Сашей и ведущим Виктором Раевым, руководителем разработки юнита Services Base, поговорим вот о чём:

• как выглядит путь от разработчика до менеджера высшего звена длиной в 10 лет;

• какие изменения произошли в Авито с 2016 года;

• как зарождалась PaaS — платформа, которая теперь облегчает жизнь инженерам;

• что такое AvitoPlato и какие планы по развитию продукта на будущее.

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

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

Как связаны игра «Что? Где? Когда?» и работа в IT?

А вы знали, что методы легендарной интеллектуальной игры могут стать ключом к эффективной работе вашей команды? Рассказываем в нашей новой статье!

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

Если хочется идти дальше стандартных подходов и строить по-настоящему слаженную команду — статья «Что? Где? Когда?» и эмоциональный интеллект в бизнес-команде для вас!

Инженер по безопасности компании Fortinet представил экспериментальный инструмент KittyLoader. Это небольшой загрузчик, написанный на C и Ассемблере, который автор сам называет крайне ненадёжным и не предназначенным для практического применения.

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

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

Гигачад на сцене, быдлокодер в опенспейсе

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

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

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

Мне кажется, давно пора признаться самим себе, что разработка делится на два типа: "сказки об идеальных решениях" и "настоящая работа", где первые треплют языком, а вторые решают проблемы бизнеса - хоть это в 95% случаев и превращается в жопоболь через какое-то время.

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

Заметки в никуда

Поиск скомпрометированных зависимостей через Dependency Track

На днях стало известно о компрометации почти 2-х десятков npm-пакетов (подробнее в этой статье). Зловредный код может похищать криптовалюту. Это не первый раз, когда в зависимости попадает зловред (например, в 2022 году зловред удалял данные).

Один из вариантов поиска наличия скомпрометированных пакетов среди сотен проектов - использование Dependency Track. При этом поиск возможен и в транзитивных зависимостях тоже. На картинке ниже показан процесс. Заходим в раздел "Components", вводим название в формате "pkg:npm/$name$". Далее остаётся отсортировать по версии и найти среди них скомпрометированную (сейчас это легко - нужно смотреть самую старшую версию). Можно поиск производить сразу по конкретной версии. Пример:

pkg:npm/simple-swizzle@0.2.3

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

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

Дейлики: благо или зло?

В новом выпуске подкаста «Свободный слот» Саша Прокшина и Паша Федотов разбирают принципы грамотного планирования. Обсуждаем:

• какими должны быть идеальные итоги встречи?

• как выглядят секреты эффективной фасилитации и perfect follow-up?

• и конечно, как выстроить день так, чтобы успеть всё?

А в финальной рубрике «Встреча — или текстом» попробуем найти ответ на вечный вопрос: сколько людей нужно, чтобы согласовать цвет кнопки, утвердить формат даты и решить другие, не менее судьбоносные задачи?

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

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