Как эффектно ворваться в mob-программирование? Узнай из выступления нашего бэкенд-лида!
В прошлом году Витя Михайлов, Backend lead Garage Eight, выступил на конференции TechLead 2024 с докладом про mob programming. Он рассказал про пользу этого подхода к разработке, а также трудности его внедрения. А еще поделился приемами, которые помогут вовлечь в этот процесс команду, справиться с «болячками» и сделать mob-программирование частью ежедневной работы.
Если не смог побывать на мероприятии, то самое время смотреть запись ;-) > YouTube > VK
Кстати, у Вити есть свой ламповый канал, где он разгоняет про бэкенд, менеджмент и процессы разработки. Заглядывай почитать!
Чем занимается директор департамента разработки в финтехе
Привет, Хабр! 🙌
Начинаем цикл постов о менеджменте в IT. 👑 Илья, директор департамента разработки ЮMoney, расскажет о том, каково это — перейти с позиции мидла в управленческую должность в финтехе, начать руководить огромными командами, нанимать лидов, мотивировать и растить людей.
Первый пост — про карьерный путь Ильи и обязанности директора разработки. Должен ли он только руководить? Или писать код по вечерам и разрабатывать технические решения — тоже нормально?
Илья:
За 10 лет работы в ЮMoney у меня было четыре карьерных периода:
Пришёл в компанию мидл-разработчиком в отдел фронтенда в 2014 году.
За N лет вырос до сеньор-специалиста.
Спустя N лет стал руководителем отдела разработки интерфейсов.
Ещё через N лет — директором департамента разработки. Теперь работаю под руководством IT-директора.
Моя главная обязанность сегодня — управлять руководителями направлений разработки. Но писать код я при этом не перестал: это, можно сказать, моё хобби, которому я посвящаю свободное от работы время. 🙂
Поначалу на управленческой должности мне было сложно разглядеть свой вклад в общие результаты. Ребята в команде что-то делают, я подсказываю и контролирую, а в итоге ощущение такое, что вроде и помогал, а вроде просто рядом стоял… Со временем это чувство ушло, и сейчас у меня есть чёткое понимание того, что я делаю: обнаружил проблему >>раскопал её >> поставил решение на рельсы >> процессы улучшились. Чтобы побороть синдром самозванца, пришлось даже поработать со специалистами: мне очень помогли наши HR BP.
Чем ещё я занимаюсь в компании, не считая управления большим департаментом? Пишу технические решения, описываю, что и как мы внедряем, но на тактическом, верхнем уровне. Например, если мы хотим начать использовать какую-то новую технологию, я анализирую её, изучаю, что нужно для внедрения, и передаю коллегам в работу. Сейчас в моём фокусе LLM (большие языковые модели): мне интересно в них разбираться и применять их в работе.
***
Ждите следующий пост про найм лидов в разработку. А пока задавайте вопросы в комментариях. 😉
Китайский ИИ-проект DeepSeek возглавил топ по скачиванию в США.
OpenAI с проектом ChatGPT была основана 10 лет назад, имеет 4500 сотрудников и привлекла $6,6 млрд капитала. Китайская DeepSeek была основана менее 2 лет назад, имеет 200 сотрудников и была разработана менее чем за $10 млн. Но они начали конкурировать.
DeepSeek выпустила версию DeepSeek‑V3, LLM с открытым кодом, который соответствует производительности ведущих американских моделей, но требует гораздо меньше затрат на обучение. Модель имеет 685 млрд параметров, а в основе её архитектуры лежит подход Mixture of Experts (MoE) с 256 «экспертами», из которых восемь активируются для каждого токена.
В тестах производительности DeepSeek‑V3 превосходит Llama 3.1 и другие модели с открытым кодом. DeepSeek‑V3 соответствует или даже превосходит Chat GPT-4o, уступая лишь Claude 3.5 Sonnet от Anthropic.
В DeepSeek сообщили о расходах в размере $5,6 млн на обучение своей нейросети по сравнению с предполагаемыми $500 млн, потраченными на обучение Llama-3.1.
Бенчмарки подтверждают, что Deepseek недалека от решений OpenAI, но всего за 3% от стоимости разработки. Стоимость собственного API DeepSeek составляет всего $0,55/$2,19 за вход/выход — значительно дешевле.
Китайские разработчики из DeepSeek пошли проторенным путём и сделали свой ИИ-проект, внимательно изучив ошибки других. В результате стоимость продукта Deepseek оказалась на 97% ниже, чем раздутые американские проекты с большими затратами на обучение.
Бенчмарки подтверждают, что Deepseek недалека от решений OpenAI, но всего за 3% от стоимости разработки.
Стоимость собственного API DeepSeek составляет всего $0,55/$2,19 за вход/выход — значительно дешевле.
Эксперты считают, что китайская DeepSeek может представлять угрозу для фондовых рынков США, компания создала модель искусственного интеллекта по чрезвычайно низкой цене и без доступа к передовым чипам, что ставит под вопрос необходимость сотен миллиардов капиталовложений в эту отрасль.
В декабре DeepSeek представила новую языковую модель DeepSeek‑V3, которая продемонстрировала впечатляющие результаты в работе с кодом. Модель имеет 685 млрд параметров, а в основе её архитектуры лежит подход Mixture of Experts (MoE) с 256 «экспертами», из которых восемь активируются для каждого токена.
По данным Deepseek, V3 демонстрирует производительность, сопоставимую с ведущими проприетарными моделями, такими как GPT-4o и Claude-3.5-Sonnet, во многих тестах, при этом предлагая лучшее соотношение цены и производительности на рынке.
Также DeepSeek выпустила открытую версию модели рассуждений DeepSeek‑R1, которая, по её утверждению, работает наравне с o1 от OpenAI в определённых тестах. Это уже подтвердили независимые бенчмарки.
Команда из девяти сотрудников Nokia в 2007 году выступила с внутренней презентацией, на которой объявила, что представленный первый iPhone от Apple может изменить стандарты индустрии и станет лидером рынка.
Согласно выводам инженеров компании, сенсорный интерфейс вместе с безупречной интеграцией интернет-приложений обеспечит непревзойденную простоту использования. По их мнению, Nokia нужно было оперативно разработать собственный сенсорный интерфейс, чтобы не проиграть Apple.
Менеджмент Nokia не прислушался к мнению разработчиков и инженеров, а iPhone вскоре стал новым стандартом в индустрии мобильных устройств. Мобильный бизнес компании Nokia в 2011 году приобрела Microsoft.
Культура и практика написания MoM (minutes of meeting)
Короткий пост о том, что это такое, зачем (и для чего) и, конечно, как.
Тема избита, но хочется поделиться опытом. Вероятно, это болит лишь у меня, но за последние 5 лет я не встречал компанию, в которой MoM был общей практикой. При этом есть очевидная потребность фиксировать историю решений и сформированных устных договоренностей. Так для меня этот пост крик души и возможность напомнить о пользе этой практики.
Что такое MoM (Minutes of meeting)? 🤨
Короткие, тезисные записи ключевых мыслей по результату встречи.
Зачем MoM?
Юридическая значимость, если использовать email для фиксации позиций и решений (возможно, в мессенджерах тоже, но в email я уверен)
Синхронизация представления о результатах встречи
Напоминалка (чтобы вернуться к результатам обсуждения, если потребуется). Вроде записки самому себе в будущем, которая поможет вспомнить обсуждение и ключевые для участников договоренности
Как MoM?
Идеально - сразу после встречи (чтобы не забылось)
Путь написания письма (email). Вспоминаем пункт про юридическую значимость
Коротко - 5±2 тезиса по следующим пунктам. Количество не случайно. Короткий текст воспринимается легче, проще выделить главное и требует меньше времени на создание
Кто был на встрече (участники)
Что обсуждали (ключевая тема, ответвления) 1±2
Что решили (ведь зачем-то собирались?)1±2
Задачи, которые появились на встрече. Кто исполнитель и, конечно, дедлайны по ним. Тут ограничений нет.
Следующая встреча - требуется ли, дата и время
Стоит упомянуть, что вести MoM задача непростая. Часто бывает, что ведущий заметки для написания MoM может "выпадать" из встречи, особенно если идет жаркая дискуссия. Вероятно, можно решить эту проблему делегируя задачи транскрибирования и саммаразинга техническим решениям ИИ.
Будильник на iPhone с новыми версиями iOS продолжает тормозить. Пользователи жалуются, что мелодия играет с задержкой в несколько часов или не играет вообще. Apple знает о проблеме, но уже год не может её исправить. Временное решение: «Настройки» — «Face ID и код-пароль» — отключите «Распознавание внимания».
Система управления проектами для удаленных команд Virex теперь доступна!
Коммуникация, задачи, аналитика, гибкость — всё это про Virex.
Система управления проектами Virex начинается с простоты. Все проекты в одном месте. Все ключевые данные, задачи и прогресс проекта одном экране.
Матрица задач в Virex гибкая. Вы можете настроить процесс работы под себя: бэклог, задачи в процессе и завершённые задачи — всё это легко управляется и визуализируется.
Лента активности Virex: больше не нужно искать, кто, что и когда сделал. Все изменения в проекте собраны в одном месте.
Встроенные чаты для каждого проекта. Общайтесь со своей командой прямо в Virex.
Это новый предпраздничный выпуск нашего подкаста «Свободный слот». Обсуждаем Новый год глазами инженера: фича фризы и декабрьский стресс, дежурства в праздники и возвращение к рабочей рутине после перезагрузки.
Полный джингл беллс!
Подписывайтесь на канал AvitoTech в Telegram, там мы рассказываем больше о профессиональном опыте наших инженеров, проектах и работе в Авито, а также анонсируем митапы и статьи.
Трогай, это на Новый год: восемь принципов разработки в Авито
Всем предновогодний привет! Приготовили для вас подарок — вместе с инженерами собрали наиболее актуальные принципы, которыми мы руководствуемся в Авито. Взяли их из Плейбука — это у нас такой свод правил, методов, шагов и сценариев, по которым команда разрабатывает свои продукты и сервисы.
Так вот, принципы эти легко адаптировать под ваши рабочие задачи, а некоторые и вовсе можно использовать в ситуациях, не связанных с разработкой. Забирайте то, что понравилось, улучшайте разработку и инженерную культуру вместе с нами.
С наступающим Новым годом! Делайте крутые продукты и фичи — надеемся, что наш Плейбук вам в этом поможет. И не забывайте балансировать между трудом и отдыхом!
Подписывайтесь на канал AvitoTech в Telegram, там мы рассказываем больше о профессиональном опыте наших инженеров, проектах и работе в Авито, а также анонсируем митапы и статьи.
Совсем недавно мне довелось поучаствовать в роли докладчика в конференции TeamLead Conf 2024. Выступал, как технический директор компании "Спринт-Ф", а темой выбрал "Законы Мерфи в повседневной работе руководителя".
Жаль, конечно, что строгий регламент выступления не позволяет рассказать всё, что хочется поведать аудитории. Но, надеюсь, то, что успел рассказать, было кому-то интересно и полезно.
Новый год, или приключения айтишников в лесу. Специальный выпуск Sravni Podcast
В преддверии Нового года специалисты Сравни, тимлид Денис Сизый и Deputy CTO Василий Бяхов, перенеслись из привычного офисного пространства в сказочный лес.
Став на время помощниками Деда Мороза, за чаепитием подвели итоги уходящего года, сравнили подготовку к празднику с ИТ-процессами и поделились планами на 2025.
В этом выпуске:
Сравниваем Новый год с ИТ. Как спроектировать архитектуру праздника?
Нижний Новгород • Екатеринбург • Новосибирск • Владивосток • Ижевск • Казань • Тюмень • Уфа • Иркутск • Челябинск • Самара • Хабаровск • Красноярск • Омск
Полезные советы от разработчика OpenSearch Даниила Дубровкина из AWS.
Вы смотрели The IT Crowd? Это уморительный британский телевизионный ситком примерно 2006 года, в котором группа ИТ‑гениев работала в отделе технической поддержки Reynholm Industries в Лондоне. Один из характерных смешных моментов заключается в том, что каждый раз, когда звонил телефон, Рой брал трубку и, не дожидаясь ответа, спрашивал: «Вы его выключили и снова включили?», а затем вешал трубку. Я часто чувствую себя Роем, когда общаюсь с пользователями, сообщающими об ошибках в проектах с открытым исходным кодом, которые я поддерживаю.
Вот мой структурированный подход к любым ошибкам (багам, проблемам), о которых сообщают в моих проектах с открытым исходным кодом:
Не исправляйте ошибку. Поскольку это проект с открытым исходным кодом, и мы не продаём программное обеспечение, у сопровождающих может быть некоторая социальная ответственность, но они не обязаны что‑либо делать.
Не пытайтесь воспроизвести ошибку. Не уверены, что это ошибка? Не можете воспроизвести проблему? Вежливо запросите дополнительную информацию или разъяснения.
Не пытайтесь написать тест, который докажет, что это ошибка. Попросите человека, сообщившего о проблеме, попытаться написать автоматизированный и провальный тест. Это поможет сузить круг проблем и гарантировать, что ошибка останется исправленной в будущем.
Не исправляйте ошибку. Теперь, когда человек, сообщивший об ошибке, написал для неё автоматизированный тест, он так близок к её исправлению. Попросите его сделать это. Это дает человеку, сообщившему об ошибке, чувство причастности и вклада в проект.
Не делайте ничего другого. Не можете получить никакого участия в устранении ошибки от человека, сообщившего о ней? Оставьте ошибку открытой. Кто‑то другой её подхватит.
tl;dr Не исправляйте ошибку! У здорового проекта с открытым исходным кодом будет много вовлечённых участников, особенно когда дело касается ошибок. Это один из самых простых плодов, которые вы можете собрать как сопровождающий. Тем не менее, иногда я просто хочу исправить ошибку сам, потому что это так интересно.
9 законов программирования для новичков и опытных, без которых невозможно добиться успеха в проекте.
Закон Брукса — если вы посадите трёх кодеров за одну задачу, они не сделают её в три раза быстрее. Чем больше ваша команда, тем сложнее становится координация и планирование.
Закон Гудхарта — чем жестче ваши KPI и метрики для измерения эффективности, тем сильнее они отвлекают от выполнения самих задач. В самых запущенных случаях люди забивают на задачи и переключаются только на KPI.
Закон Хайрама — чем больше у API пользователей, тем сильнее они полагаются на незадокументированные особенности, превращая их в «обязательные» функции. Из‑за этого любые изменения становятся сложными, ведь легко сломать что‑то для тех, кто уже привык к старым фишкам.
Закон Конвея — структура программ часто повторяет организационную структуру команды, которая её создала. Если слепо следовать границам в команде, софт получится неоптимизированным.
Закон Линуса — база опенсора. Чем больше людей проверяют код, тем больше шансов найти ошибку.
Закон Хофтшадтера — дедлайн всегда нужно ставить с запасом. Мы склонны занижать количество времени, необходимое для выполнения задачи.
Закон Кернигана — код всегда должен быть простым и понятным. Сложный код всегда становится неподъёмным в отладке и сопровождении — это только вопрос времени.
Закон Питера — софт‑ и хард‑скиллы, это разные навыки. Так, топовый кодер не обязательно обладает такими же способностями к управлению людьми, руководству командами или выполнению стратегических требований лидерства.
Закон Парето — усилия должны быть избирательными. Чтобы 20% усилий приносили 80% результатов, сначала нужно понять, куда прикладывать эти усилия. Качество всегда перевешивает количество, а результат важнее времени затраченного на задачу.
Краткий курс по принятию управленческих решений — Александра Прокшина / Ural Digital Weekend 2024
Решения мы обычно принимаем на основе интуиции, опыта и анализа. И если по первым двум способам все скорее понятно, то каким может быть анализ? И что мешает нам объективно оценивать ситуацию и действовать правильно?
В докладе на веселом примере принца из первого Шрека, разберем, как заметить ту или иную ловушку мышления, и инструменты, которые можно использовать, чтобы из них выбираться и не быть в итоге скушанным драконом. Рассмотрим кейсы принятия решений из моего опыта:
— Брать выгодный, но спорный проект в работу или нет.
— Как выбрать между двумя одинаково хорошими разработчиками.
— Как понять, что с сотрудником пора расстаться.
— Cтоит ли применять новую технологию или нет. Спойлер: в обычном виде в столбик плюсы и минусы выписывать не будем, но попробуем для них кое-что математическое. Доклад будет полезен как разработчикам, так и тимлидам и менеджерам, особенно тем, у кого выбор или принятие решений вызывают боль.
Масштабирование под давлением — возможность или вызов?
На этот вопрос в подробностях отвечает бэкенд-инженер и руководитель команды разработки монетизационных продуктов Авито Дмитрий Телепнев. Из его рассказа вы узнаете:
как обеспечить рост монетизации по модели cost-per-action;
как масштабировать CPA от MVP до 1млн RPM;
как подойти к планированию и обеспечить прагматичный подход к исправлению вкупе с продуктовыми инициативами.
Переходите по ссылке, чтобы ничего не упустить.
Подписывайтесь на канал AvitoTech в Telegram, там мы рассказываем больше о профессиональном опыте наших инженеров, проектах и работе в Авито, а также анонсируем митапы и статьи.
Измеряй и управляй! Как и за какими метриками должен следить каждый уважающий себя продакшн — Сергей Полуэктов / Ural Digital Weekend 2024
Какие есть особенности у бизнеса в продакшн? Что нужно знать пассивному инвестору? По каким критериями можно оценить стабильность объемов производства, рентабельности, дебиторской задолженности, роста и продаж? И как можно повлиять на все эти метрики? Ответы на эти вопросы вы найдете в выступлении Сергея.
Вместо менторов и карьерных консультантов: проверяем резюме по 60 пунктам бесплатно, без смс и регистрации
Привет, Хабр! Публикую свой чек-лист, который поможет быстро «причесать» резюмешку перед поиском новой работы в 2025 году.
Часть пунктов — капитанские советы, но тем не менее, похожие чек‑листы консультанты продают за 5–10 тысяч рублей. Собрал собственную версию и делюсь тут. Сохраняйте в закладки и накиньте плюсиков, кому было полезно.
ОБЩИЕ РЕКОМЕНДАЦИИ ○ Резюме сделано под конкретное направление поиска ○ Резюме не содержит орфографических и грамматических ошибок ○ В названии файла резюме есть ваша фамилия, имя и название должности ○ Формат файла: PDF ○ Не используется шаблон с «красивым» дизайном ○ Объем резюме до трех страниц ○ Язык, на котором написано резюме соответствует языку рынка ○ Текст резюме набран одним кеглем (за исключением заголовков) ○ В резюме нет цветных выделений ○ Используется не более 1–2 шрифтов
КОНТАКТНАЯ ИНФОРМАЦИЯ ○ В резюме указаны ваши настоящие данные ○ Есть фотография ○ Фотография в хорошем качестве, без пикселей ○ На фотографии только вы ○ Фото сделано в анфас ○ На фотографии у вас спокойное и доброжелательное выражение лица ○ Указан телефон ○ Указана почта ○ Название почтового ящика звучит официально ○ Указан мессенджер ○ Есть ссылка на портфолио / Linkedin / Github ○ Портфолио / Linkedin / Github без информации, которая может показать вас в плохом свете ○ Формат работы не противоречит условиям вакансии ○ С помощью контактов с вами можно связаться в том же канале, где рекрутер получил резюме ○ Ссылки на контакты кликабельные и работают ○ Написано саммари
ДОЛЖНОСТЬ И ЗАРПЛАТА ○ Желаемая должность указана в единственном числе ○ Название должности совпадает с названием позиции в вакансии ○ Указана желаемая зарплата ○ Зарплата укладывается в разумную вилку по рынку
ОПЫТ РАБОТЫ ○ Позиция на последнем месте работы совпадает с названием должности в вакансии ○ Опыт отражен в хронологическом порядке ○ Периоды работы отражены с точностью до месяца ○ Фокус в описании опыта сделан на последние 5–7 лет ○ Описаны ваши достижения ○ В достижениях описаны только результаты ○ В формулировках достижений нет общих фраз ○ Список обязанностей позиционирует вас только с позитивной стороны ○ Описание достижений сформулировано по одинаковой логике ○ Достижения отделены от операционных задач смысловыми блоками ○ Достижения и задачи расположены в виде маркированного списка ○ Достижения описаны по формулам XYZ или STAR ○ В достижениях есть цифры ○ В достижениях есть факты ○ В описании достижений используется совершенный глагол: сделал, улучшил, вырастил, ускорил и т. д. ○ Достижения расположены в порядке убывания ценности для бизнеса ○ Хотя бы 1/3 из ваших достижений пересекаются с требованиями вакансии ○ Задачи описаны понятным языком, без сложных терминов ○ Нерелевантный опыт занимает не более трети всего опыта, либо переформулирован под вакансию ○ Опыт с давностью более 10 лет удален из резюме ○ Опыт менее года скрыт, либо «докручен» до 1 года ○ Если в одной компании у было несколько должностей — ваш карьерный рост легко считывается ○ Для каждой компании где вы работали написано короткое интро ○ Для каждой компании указан ее сайт ○ В описании опыта нет белых пятен (пробелы в карьере от 1 года) ○ Блок достижения и обязанностей не содержит «канцелярского» языка
ОБРАЗОВАНИЕ ○ Оконченное — указано ○ Если проходили курсы — не более 2–3 позиций
НАВЫКИ ○ Список навыков соответствует требованиям вакансии минимум на 2/3 ○ Убраны очевидные навыки вроде владения ПК/Word/Excel ○ Навыки расположены в порядке убывания важности для позиции
