Система управления проектами для удаленных команд 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 ○ Навыки расположены в порядке убывания важности для позиции
Как начать думать про платформы и к чему такие мысли могут привести?
На эти вопросы отвечает Шамиль Хайртдинов, технический руководитель кластера Заказы с доставкой в Авито. В своем докладе Шамиль рассказывает, как создать горизонтальную платформу в вертикальной команде, а также разбирает, как именно выглядит путь становления транзакционной платформы от узконаправленного решения до горизонтального.
Если хотите разобраться в платформенной теме — советуем посмотреть выступление Шамиля.
Подписывайтесь на канал AvitoTech в Telegram, там мы рассказываем больше о профессиональном опыте наших инженеров, проектах и работе в Авито, а также анонсируем митапы и статьи.
Как повысить свою ценность в ИТ: в поиске новых компетенций. Новый выпуск Sravni Podcast
Поговорили с Левоном Гончаровым, экспертом в области Agile и построении команд. Обсудили, как разносторонность и насмотренность помогают в ИТ (и в целом в карьере), об успешном планировании, делегировании и самых ценных сегодня софт-скиллах.
Также в этом выпуске:
Как меняются требования к разработчикам
Везде ли эффективен SCRUM
Что важно знать о психологии при работе с командами
Путь от айтишника до владельца баскетбольного клуба и кинопродюсера
Пока в столице гремел РЭД, я на выходных посещал другую локальную конференцию — KD Conf. Помимо приятного чувства, что на конференцию не надо никуда лететь/ехать, подхватил два интересных инсайта про внедрение LLM-моделей в процессы:
📃 Можно валидировать ГДД:
Проверить документ на противоречивость информации.
Проверить документ на достаточность информации.
Отформатировать документ под конкретный отдел. Т.е. переоформить так, чтобы с доком было удобно работать программистам, художникам и т.д.
🏷️ Можно валидировать описания для задач:
Проверить, что описание соответствует шаблону.
Проверить, что информация релевантная, а не ради удовлетворения шаблона.
Проверить, что предоставленной информации достаточно для выполнения задачи.
Делать это можно вручную, по необходимости, или автоматизированно через API.
Нужно только подобрать подходящий для команды набор промтов и следить, чтобы нейронка не нагаллюционировала лишнего 🤩
В этой схеме есть две явные проблемы — это конфиденциальность🛡️ и стоимость запросов 💵 Решается это развёртыванием внутренней корпоративной LLM. На конференции я чаще всего слышал про Llama от Meta. И мы в команде тоже как раз смотрим в сторону этого решения.
Мероприятие было «не геймдевное» — весь этот опыт исходил от энтерпрайза, банкинга и прочего бигтеха. Поэтому интересно, пробовали ли кто уже в геймдеве вводить в процессы подобные инструменты❓
Управление направлением разработки в IT-компании на 2500 чел — Юлия Бажанова / Ural Digital Weekend 2024
Почему важно делать не только проектную разработку и аутстафф, а также вкладываться в продуктовую разработку? Как посчитать от этого экономический эффект? Правила ведения IT-бизнеса, которые с годами не стареют.
Как меняется менеджмент в компании с ростом от 20 до 200 человек — Николай Фетюхин / Ural Digital Weekend 2024
Менеджмент — система управления людьми в компании, где строится какая-то культура, на нее нанизываются всякие регламенты, отчеты. Круто, когда планы совпадают с фактами.
1. История становления менеджмента в моих компанияx.
2. Чем большие компании отличаются от маленьких?
3. Почему в IT-компаниях все плохо с менеджментом?
