Каким вышел Avito TeamLead Drinkup #3?
Одним февральским вечером в московском офисе Авито мы узнали, что под хорошее вино и вкусную еду разговоры про управление командой, процессы найма и привычную рутину тимлидов сразу преображаются.
Чтобы почувствовать атмосферу того вечера, кликайте на видео.
Подписывайтесь на канал AvitoTech в Telegram, там мы рассказываем больше о профессиональном опыте наших инженеров, проектах и работе в Авито, а также анонсируем митапы и статьи.
Совсем недавно была новость, что Amazon увольняет 14 тысяч менеджеров. И эта новость подавалась в апокалиптических тонах — будто конец уже близко, всё загибается, и пора бежать спасаться. Однако не стоит верить провокационным заголовкам; важно уметь правильно интерпретировать ситуацию.
Что мы знаем про Amazon:
В Amazon работает около 1,5 миллионов сотрудников.
Компания известна своими регулярными увольнениями неэффективных работников.
Теперь давайте посчитаем. Если каждый менеджер управляет от 5 до 10 человек, в среднем возьмём 7. Сколько же менеджеров потребуется для штата в 1,5 миллиона?
Для этого представьте себе дерево, где на нижнем уровне будет 1,5 миллиона «листьев», а все остальные уровни — менеджеры. Возводим число 7 в разные степени и смотрим результаты:
7⁰ = 1
7¹ = 7
7² = 49
7³ = 343
7⁴ = 2401
7⁵ = 16807
7⁶ = 117649
7⁷ = 823543
7⁸ = 5764801
Уже на восьмом уровне количество «листьев» превышает общее число сотрудников Amazon. Поэтому вернёмся на седьмой уровень — там примерно 800 тысяч «листьев».
Предположим, что у некоторых менеджеров подчинённых больше семи, такое бывает в функциональных подразделениях.
Теперь сложим количество менеджеров с нулевого уровня до шестого и подсчитаем итог:1+7+49+343+2401+16 807+117649 =137 257;
Таким образом, чтобы управлять всей компанией, понадобится около 137 тысяч менеджеров.
Итак, увольнение 14 тысяч менеджеров — это примерно 10% от общего числа управленцев, тех самых неэффективных сотрудников, которых Amazon ежегодно сокращает.
Таким образом, новость перестаёт казаться сенсационной и становится обычной практикой. Так что всегда сохраняйте ясность ума и не поддавайтесь панике.
Как пройти путь от разработчика до директора нескольких кластеров?
Об этом расскажет гость нового выпуска шоу «AviTalk» — Игорь Гранщиков, руководитель разработки вертикали Авито Недвижимость. Игорь воспроизводит в подробностях весь свой карьерный трек от обучения и первой работы до руководящих позиций.
Смотреть VK
Смотреть на YouTube
Подписывайтесь на канал AvitoTech в Telegram, там мы рассказываем больше о профессиональном опыте наших инженеров, проектах и работе в Авито, а также анонсируем митапы и статьи.
На ресурсе OverAPI собраны все шпаргалки для разработчиков по популярным языкам программирования и технологиям. Информация там постоянно обновляется. Можно нажать на любую команду и узнать о ней всё. Ресурс бесплатный и без регистрации.
7 очень вредных советов для тимлида
Если вы хотите, чтобы вся команда вас возненавидела, чтобы половина сотрудников выгорела, а вторая уволилась в самое ближайшее время, следуйте этим простым и действенным рекомендациям — успех гарантирован:
Следите за каждым шагом сотрудников, иначе будут филонить. Требуйте ежедневных отчетов, лучше текстом и чтобы со всеми деталями. Высший пилотаж — синки по статусу задач утром и вечером, чтобы не расслаблялись.
Передавайте задачи без четкого техзадания — учите коллег автономности. У вас и так все дедлайны горят, еще не хватало тратить время на расписывание задач. В конце концов разработчики не маленькие, сами разберутся.
Делайте всё сами, так легче и быстрее. Ну а кто, если не вы? На объяснение задания вы потратите больше сил и времени, а так всё сделаете самостоятельно — и дело в шляпе.
Забейте на техдолг, фичи важнее. Если код работает, лишний раз не трогайте его. Ставьте в приоритет работу над новыми функциями, это интереснее и перспективнее.
Не тратьте время на обратную связь для команды. В крайнем случае укажите на ошибки, но не помогайте исправить — пусть сами возятся. А если сотрудник чего-то добился — ни в коем случае не хвалите, а то зазнается.
Отдавайте все задачи самому опытному в команде, так быстрее. Всемогущий разработчик заменяет целый штат неопытных.
Пресекайте неформальное общение в команде — это мешает работе. Поболтать о всяком можно и в свободное время. А в рабочих чатах и тем более в офисе не кружок по интересам.
А если серьезно, то в отдельной статье подробно разбираем, почему каждое из этих убеждении портит жизнь не только всей команде, но и самому тимлиду. Приходите читать и делитесь опытом в комментариях.
Освойте инструменты креативных методологий для применения в проектах и рабочих задачах 💡
В новом бесплатном онлайн-курсе Креативное мышление в рабочих задачах рассказываем, как мыслить нестандартно, генерировать идеи и приземлять их в реальные IT-проекты.
Обучение проходит в формате интерактивной истории: в роли руководителя вы будете решать задачи команды. Пройдете путь преодоления трудностей в жизни команды от момента их выявления до решения. Приобретете навыки поиска корневой проблемы, фокусировки и использования креативных инструментов в рабочих задачах.
Кому будет полезен курс:
руководителям больших и маленьких команд, которые хотят освоить новые инструменты, чтобы улучшить рабочие процессы;
тем, кто хочет находить уникальные решения для развития проектов и получить практический опыт в их реализации;
всем, кому интересны креативные методики.
Желаем успехов!
Что такое Avito Fallback и чем он так хорош?
Рассказывает Николай Губин, бэкенд-инженер в Авито. Avito Fallback — это механизм, позволяющий пользователям в какой-то степени продолжать пользоваться сервисом, даже если упал production. Коля говорит про эволюцию проекта и его технические особенности, а также про проблемы, которые возникают при работе, и то, как их лечить.
Подробнее про Avito Fallback — в видео с 10:58.
Подписывайтесь на канал AvitoTech в Telegram, там мы рассказываем больше о профессиональном опыте наших инженеров, проектах и работе в Авито, а также анонсируем митапы и статьи.
По мотивам очередного холивара
Со сравнением удалёнки, гибрида и офисной работы.
Ария выгоревшего удалёнщика
Я выключаю мониторы.
Я пишу тебе письмо
Про то, что больше не могу
Смотреть на дерьмо.
Про то, что больше нет сил,
Про то, что я почти запил,
Но не забыл тебя.
Про то, что Телеграмм звонил,
Хотел, чтобы я встал,
Оделся и пошёл,
А точнее — побежал.
Но только я его послал,
Сказал, что болен и устал,
И эту ночь не спал.
Припев:
Я жду ответа,
Больше надежд нету,
Скоро кончится лето,
Это...
А с погодой повезло,
Снег идёт четвёртый день.
Хотя на Яндексе рисуют,
Что жаркой будет даже тень.
Но, впрочем, в том углу, где я,
Пока и сухо, и тепло.
Но я боюсь пока.
А дни идут чередом,
День едим, а три пьём,
И, в общем, весело живём,
Хотя и снег за окном.
Вот Сеть опять упала,
Я сижу в тишине,
Чему и рад вполне.
Припев:
Я жду ответа,
Больше надежд нету,
Скоро кончится лето,
Это...
Полная версия будет тут:
Сегодня рынок аутстаффа находится на подъеме. Но несмотря на большой спрос, некоторые продолжают утверждать, что привлекать аутстаф-специалистов нецелесообразно, аргументируя тем, что они работают хуже штатной команды. Ребята из Doubletapp, аутстаф-партнера многих российских корпораций, объяснили, почему это заблуждение.
Аутстаф-специалист НЕ ХУЖЕ штатного, потому что:
Его компетенции не отличаются от компетенций постоянного сотрудника, он прошел такие же этапы отбора, и его навыки подходят под задачи проекта.
Он заинтересован и мотивирован сделать проект на отлично, ведь от результатов его работы зависит, как долго продлится сотрудничество.
А вот почему аутстаф-специалист ЛУЧШЕ штатного сотрудника:
Широкий диапазон навыков и решений за счет участия в разносторонних проектах.
Ребята из нашей команды имеют глубокую специализацию в определенных технологиях. Они получили профильное образование, совершенствовали скиллы на внутренних проектах, а только после перешли в аутстаф.
Фокус на результат. Аутстаф-специалисты сосредоточены на выполнении конкретных задач. Они более продуктивны, в отличие от штатных сотрудников, которые могут отвлекаться на корпоративные процессы.
В стороне от конфликтов. Аутстаф-специалисты не вмешиваются во внутренние споры, корпоративные интриги и политику компании, поэтому реже отвлекаются от работы.
Читайте также:
- Честное мнение разработчика про аутстаф
- Видео для тех, кто предпочитает YouTube
- Аутстаф глазами руководителя направления
Если вашему проекту нужны опытные аутстаф-специалисты, то можем обсудить сотрудничество.
В недавней книге про построение успешной карьеры в IT в качестве менеджера, отдельным пунктом идет пункт про ИИ, в котором автор призывает тимлида разрабатывать политику использования ИИ в своей команда и согласовать её с политикой использования ИИ в компании. В вольном пересказе это звучит примерно так:
"Как ведущий разработчик, одна из ваших ключевых обязанностей — оценивать и интегрировать новые технологии, включая инструменты искусственного интеллекта (ИИ), в процессы разработки. Рассматривая возможность принятия или отказа от внедрения инструментов ИИ, важно сохранять сбалансированный подход, который ставит во главу угла потребности команды, конкретные преимущества технологий и потенциальные риски.
Перед предложением использования любого инструмента ИИ начните с оценки того, насколько он соответствует текущим и будущим проектам вашей команды. Оцените, сможет ли инструмент ИИ повысить производительность и оптимизировать рабочие процессы путем автоматизации рутинных задач, освобождая разработчиков для решения более сложных проблем. Важно также оценить качество выходного продукта, создаваемого инструментом ИИ, частоту возникновения ошибок и степень интеграции с существующими инструментами и рабочими процессами. Инструменты ИИ должны легко встраиваться без значительных изменений текущих процессов.
Внедрение инструментов ИИ связано с рисками, которые требуют тщательного управления. Команды могут стать чрезмерно зависимыми от ИИ, что потенциально снижает способность решать проблемы и ограничивает инновации. Важную роль играют безопасность и конфиденциальность, особенно в отношении обработки данных инструментами ИИ и соблюдения соответствующих норм защиты данных. Помимо начальных затрат, учитывайте долгосрочные расходы на обучение, интеграцию и обслуживание"
И дальше проводится обзор того, какие инструменты есть, для чего их можно использовать, какие есть бест-практисы в области ИИ и так далее.
Собственно есть парочка вопросов:
Используете ли вы лично какие-то ИИ-инструменты для работы?
Требует ли компания от вас, чтобы вы согласовывали использование ИИ?
Считаете ли важным регламентировать использование ИИ-инструментов?
Есть ли у вас в компании формальные правила использования ИИ в виде регламента?
Мы провели большое интервью сотрудников и узнали парочку интересных моментов, раскрывающие правду жизни аутстаф-специалистов. Уже рассказали, с какими проблемами они сталкиваются, какие плюсы видят в работе в аутстаф-компании. А теперь раскрываем, с чем сталкивается специалист в проектах разных масштабов.
Стартапы
Хаос в процессах. У стартапов часто не построена или только готовится система спринтов и задач. Таски приоритизируются по тому, насколько они приносят прибыль, и потом уже по тому, насколько они технически нужны. Трудно получить аппрув на рефакторинг чего-либо.
Редкий спрос на специалистов. Аутстаф в стартап заказчика — это ограниченная история из-за ресурсов и количества работы. Обычно они берут одного-двух человек, и нет смысла предлагать еще.
Зависимость от инвестиций. Работа с аутстаф-специалистами может резко прекратиться из-за нехватки финансирования, несмотря на договоры и дедлайны.
Крупные компании
Проблема с доступами. У корпораций работает целая служба безопасности, через которую нужно получать доступы к системам. И делается это мучительно долго.
Что вы замечали особенного в работе на аутстафе в корпорации? Пишите в комментариях.
Читайте также:
- Честное мнение разработчика про аутстаф
- Видео для тех, кто предпочитает YouTube
- Аутстаф глазами руководителя направления
Если вашему проекту нужны опытные аутстаф-специалисты, то можем обсудить сотрудничество.
Чему культовые аниме могут научить менеджеров аутстафф-проектов
Управление проектами, особенно в аутстаффинге, это не то, чему учат в школе или универе. Об этом не пишут учебники, не снимают документалки на Discovery, не делают инструкции на трех языках. В общем, тонкости этого ремесла всем приходится осваивать на практике.
Однако менеджеры нашего аутстафф-направления давно заметили, что они по долгу службы часто решают те же задачи, что и персонажи культовых аниме. А значит, у этих персонажей точно есть чему поучиться.
«Наруто» учит преодолевать сложности, связанные с адаптацией специалиста в новой команде и с его онбордингом. Вспомните, как наставник Какаши объяснял Наруто правила команды 7.
«Моя геройская академия» учит разрешать конфликты и строить доверительные отношения. Например, Аизава и Всемогущий проводят регулярные 1-to-1 с учениками.
«Токийский гуль» учит следить за качеством работы. Так гулевые отряды несколько раз замечают, что их действия на заданиях не согласованы и что это всем мешает. После этого командиры внедряют четкие процессы.
«Атака титанов» учит создать все условия для того, чтобы заказчик давал полную и своевременную обратную связь исполнителю. Так, например, поступают командиры, когда бывают недовольны отрядами.
«Тетрадь смерти» учит минимизировать риски утечки данных и строго соблюдать юридические нормы. Помните, как Кира внушал союзникам, как важно следовать его инструкциям?
«Магическая битва» учит тщательно подбирать специалистов под запрос клиента. Например, учитель Годзё подбирает под каждую миссию тех учеников, чьи компетенции позволят решить задачу эффективнее всего.
«Моб Психо 100» учит эффективно презентовать свои знания и навыки, чтобы получать достойную оплату. Тот же Рейген объясняет потенциальным клиентам, что услуги хорошего экстрасенса точно не будут дешевыми.
«Токийские мстители» учит выстраивать диалог со сложными ЛПРами. Такимичи вынужден то и дело договариваться с другими персонажами, чтобы изменить события будущего. И в этом ему помогает гибкость.
У нас в блоге целая статья о каждом из этих аниме с подробными выводами и советами по ведению проектов в аутстаффе. Так что приходите читать и делитесь своими примерами в комментариях.
Мы провели большое интервью сотрудников и узнали парочку интересных моментов, раскрывающих правду жизни аутстаф-специалистов. Уже рассказали, с какими проблемами они сталкиваются. А теперь поделимся, почему разработчикам нравится работать в аутстаф-компаниях?
«Проще жить, когда чувствуешь поддержку компании за спиной»
Аутстаф-специалисты подметили, что им спокойнее, когда компания берет на себя все заботы по поиску проектов, договоры с HR-ами, руководителями и прочее.
«Подбираем проект, на котором интересно работать»
Account Head уточнила, что руководители заинтересованы вывести сотрудника на проект, над которым ему нравится работать, где он будет мотивирован сделать много и хорошо.
Несколько корпоративов в год
Аутстаф-специалист ходит на корпоративы сразу двух и более компаний: своей и аутстаф-проекта. Были случаи, когда наших ребят заказчик пригласил на мероприятие, оплатил проживание, а перелет оплатили мы.
Это неполный список, предлагаем дополнить его в комментариях. Какие плюсы вы видите в работе на аутстаф?
Читайте также:
- Честное мнение разработчика про аутстаф
- Видео для тех, кто предпочитает YouTube
- Аутстаф глазами руководителя направления
Если вашему проекту нужны опытные аутстаф-специалисты, то можем обсудить сотрудничество.
Мы провели большое интервью сотрудников и узнали парочку интересных моментов, раскрывающих правду жизни аутстаф-специалистов. Для начала расскажем про сложности, с которыми сталкиваются наверняка все, кто пришел на аутстаф-проект:
Доступы
В корпорациях служба безопасности может выдавать доступы по несколько недель, поэтому разработчики не могут полноценно работать и пушить на прод.
Оборудование
У клиентов часто бывает требование, чтобы вся работа выполнялась на их технике. Либо, если можно работать на своей машинке, необходимо ждать доставку специфичных токенов в виде флешки. Это дело не всегда быстрое, может затянуться на несколько недель, и работа стопорится, так и не начавшись.
Переброски
Не частая ситуация, но вполне возможная, когда клиент может с утра сказать, что работа завершена, так как финансирование приостановлено, а вечером того же дня изменить свое решение. Понятно, что заказчик как бы управляет ресурсами для реализации проекта с минимальными издержками, но для аутстаф-специалиста такие заявления — стресс.
Хантинг
Для кого-то это проблема, для кого-то возможность, но хантинг аутстаф-специалистов бывает в трех случаях из пяти.
Есть мнение, что к аутстаф-сотрудникам относятся иначе, чем к штатным, из-за этого им тяжело влиться в команду. Но по итогам нашего опроса это не подтвердилось: ребята ответили, что если уже имеется опыт работы на аутстаф-проектах, то нет никаких проблем во взаимодействии.
Пишите в комментариях, с какими еще проблемами сталкивались вы как аутстаф-специалисты?
Читайте также:
Аутстаф глазами руководителя направления
Честное мнение разработчика про аутстаф
Видео для тех, кто предпочитает YouTube
Если вашему проекту нужны опытные аутстаф-специалисты, то можем обсудить сотрудничество.
Архитектурный надзор и анализ трейсов
В новом выпуске НЕмитапа — проекта, где наши инженеры рассказывают про инструменты и подходы — Ваня Нещадин, техлид команды Bridge, делится опытом, как в Авито обрабатывают 5 миллионов трейсов в сутки.
Из видео вы узнаете:
зачем вообще обрабатывать такой объем трейсов;
с чего начинали, какой была архитектура сервиса;
graceful degradation (GD): что это, как найти и устранить GD;
уровни критичности сценариев и сервисов.
Также Ваня рассказывает, какие возникли трудности при работе с графовой базой данных Neo4j и как с ними справились.
Подписывайтесь на канал AvitoTech в Telegram, там мы рассказываем больше о профессиональном опыте наших инженеров, проектах и работе в Авито, а также анонсируем митапы и статьи.
Ответ на этот вопрос очевиден — выгода.
Экономия затрат на HR
Наем сотрудника в штат — многоэтапный процесс: найти кандидатов, провести несколько собеседований, онбординг, не говоря о куче бюрократической работы. В случае с аутстаф-компаниями, заказчику предлагаются проверенные специалисты с готовыми резюме, которых можно собеседовать и быстро подключить: в среднем за 3–7 дней уже реально вывести человека на проект.
Экономия затрат на зарплаты
Налоговые и другие обязательные отчисления берет на себя компания, которая предлагает аутстаф-специалистов.
Также если нанять человека на конкретный проект с коротким сроком реализации, то уволить сотрудника из штата будет дороже, чем снять аутстаф-специалиста.
Экономия времени
Аутстаф-разработчики – ребята с опытом, поэтому обучение, организация рабочего места и внедрение в процессы проходит в разы быстрее.
Специфическая экспертность
На аутстаф можно быстро привлечь специалистов, обладающих экспертностью, которой внутри компании нет, и которых клиенту будет сложно нанять самостоятельно.
Если вашему проекту нужны опытные аутстаф-специалисты, то можем обсудить сотрудничество.
Читайте также:
- Честный материал о том, как Doubletapp взаимодействует с заказчиками и готовит специалистов к аутстаф-проектам
- Мнение разработчика про аутстаф
- Видео для тех, кто предпочитает YouTube
Для начала разъясним, что такое бизнес-юнит:
Это выделенное подразделение в компании с собственной структурой и стратегией. Если совсем просто – маленькая компания в большой.
Doubletapp занимается аутстаффом с 2020 года и делает это хорошо. В прошлом году укрепилось желание сделать упор на развитие этого направления и сделать отдельный бизнес-юнит. Подсчитали преимущества и риски – поняли, что плюсов такого решения больше:
Аутстаф помогает пережить все колебания рынка, так как специалисты работали и продолжают это делать в корпорациях, отличающихся стабильностью.
70% собеседований с клиентом заканчиваются успешно, это значит, что аутстаф-специалисты Doubletapp имеют постоянную коммерческую загрузку
Работа на аутстафе удачно вписывается в концепцию роста сотрудника от стажера до мидл/мидл+ в корпорации.
Сотрудники Doubletapp довольны опытом работы на аутстаффе и готовы идти на новые проекты.
Если вашему проекту нужны опытные аутстаф-специалисты, то можем обсудить сотрудничество.
Читайте также:
Честный рассказ о том, как мы готовим специалистов, выводим на проекты и взаимодействуем с заказчиками
Мнение разработчика про аутстаф
Видео для тех, кто предпочитает YouTube
Эта встреча могла быть сообщением в чате: 6 проверочных вопросов
Мы все не любим затянутые, бессмысленные митинги на несколько часов. Часто они превращаются в хаотичный обмен мнениями, а решения так и не принимаются. Причина не в самой встрече, а в том, что она изначально плохо спланирована: непонятно, зачем мы собрались, кто должен участвовать и к какому результату нужно прийти.
Перед тем как назначить встречу, задай себе эти вопросы — они помогут не только чётко определить её цель, но и сделать обсуждение продуктивным:
Зачем нам нужна эта встреча? Зачем мы проводим эту встречу именно сейчас?
Что должно измениться после этой встречи? Конкретизируем эти ожидания, уточняем последствия. Какой ожидаемый эффект для команды, проекта или бизнеса? Если ничего не измениться, возможно встреча не нужна;)
Какой конкретный результат мы хотим получить по итогу встречи? Что будет наилучшим результатом встречи? (Принятое решение, согласованный план, список идей для дальнейшего обсуждения, подписанный документ и т.д.).
Что случится, если встречу не проводить? Если ответ — «ничего страшного», значит, её можно заменить асинхронным обсуждением.
Кто должен участвовать, а кого можно не звать? (Частая проблема — на встречах слишком много людей или наоборот не хватает нужных.).
Какие решения/информация нужны до встречи? (Если участники придут неподготовленными, встреча может затянуться и быть бесполезной. Этот вопрос помогает заранее собрать данные).
Разработчик под ником madprops предложил способ для быстрого поиска команд в терминале
«Я очень часто обращаюсь к истории действий в shell, чтобы снова и снова запускать одни и те же команды. Пока нет эффективного способа сделать это. Я думаю, что это проблема, которую нужно решать с помощью специализированного инструмента. Я могу попробовать сделать инъекцию оболочки с помощью rofi позже. Но сейчас я придумал трюк, который помогает в работе. Добавьте значки к командам, чтобы вы могли мгновенно распознавать их по стрелкам вверх:
: ✅;./utils/check.sh
: ⚡;./scripts/tag.py
: 📚;./scripts/makedocs.sh
Обратите внимание на двоеточия и точки с запятой. Значки не являются частью команды, они ничего не делают. Но теперь ваше зрение очень быстро распознает нужный элемент. Вместо иконок можно использовать текст, который можно легко отфильтровать позже», — пояснил madprops.
ME:
You an expert Java programmer. Your job is to create PlantUML diagramm for the provided code.
LLM:
Creating a PlantUML diagram for the provided code involves understanding the relationships between the classes, their methods, and their interactions. Below is a PlantUML diagram that represents the key classes and their relationships based on the provided code.
AI сильно изменит подход к разработке и DevOps:
Знание и умение запоминать огромное количество технических деталей отходит на второй план, по сравнению с умением формулировать мысли и задавать вопросы.
LLM это как новый компилятор, только вместо кода, мы отправляем ему вопросы на естественном языке и куски кода на проверку.
Если раньше языки программирования оптимизировали для человека, то сейчас AI-Assisted разработка, приведет к тому что структура кода нужно будет оптимизировать для AI.
Машине все равно это camelCase или snake_case и разбита ли ваша программка на сотни файлов в десятках директорий. Машине «удобнее» если все токены будут в одном файле.
git clone https://github.com/apache/iceberg.git
cd iceberg
ls arrow/src/main/java/org/apache/iceberg/arrow
ArrowAllocation.java DictEncodedArrowConverter.java
ArrowSchemaUtil.java vectorized
yek --json
2025-02-15T11:56:02.751663Z DEBUG Not a Git repository or unable to open: "."
/var/folders/kr/bxl1m6050xnbq5glx1nbfrx40000gn/T/yek-output/yek-output-ba15253a25ac66a21beb1f5433405467913ac2354fa1fa0c47eed2cc6220cc6a.json
(base) anton@Antons-Mac-mini arrow % ls -lhat /var/folders/kr/bxl1m6050xnbq5glx1nbfrx40000gn/T/yek-output/yek-output-ba15253a25ac66a21beb1f5433405467913ac2354fa1fa0c47eed2cc6220cc6a.json
-rw-r--r--@ 1 anton staff 192K 15 фев 14:56 /var/folders/kr/bxl1m6050xnbq5glx1nbfrx40000gn/T/yek-output/yek-output-ba15253a25ac66a21beb1f5433405467913ac2354fa1fa0c47eed2cc6220cc6a.json
🌱Объясняем основы риск-менеджмента на репке
В известной русской сказке один дед посадил репку. Она выросла огромной, дед решил вытащить её, но не смог — в одиночку такой проект просто так не затащить. Тогда он собрал команду: позвал бабку, внучку, Жучку, кошку и мышку. Только благодаря командной работе дед справился с задачей.
А теперь разберем этот кейс детальнее с позиции проектного управления и посмотрим, какие риски мог бы предусмотреть дед.
🔮 Риск роста: будь готов к неожиданностям
Когда дед инициировал проект (сажал репку), он вряд ли предполагал, что она вырастет такой огромной. В реальной практике проект вида «репка-переросток» встречается не так уж и редко. Мог ли дед что-то с этим сделать? Конечно мог!
Что можно сделать:
Подумать и отработать основные риски: оценить плодородность почвы, сезонность посева и сбора, странную любовь бабки к стимуляторам роста для растений и, наконец, что за сорт репы решили сажать.
На этапе планирования ответить на вопрос «а что нам будет нужно, если…?» и строить планы с учетом возможных рисковых событий.
Основываясь на риск-плане, сформировать резерв ресурсов — времени, денег и прочего. Например: «Сколько времени понадобится дополнительно, если репка будет зреть долго?», «Кто в итоге участвует в сборе урожая?» и так далее.
👥 Риск недооценки команды: отсутствие подготовки
Деду пришлось собирать команду по ходу дела. Если бы он сразу оценил возможные сложности, подготовил ресурсный план и заранее распределил роли, то, возможно, всё прошло бы быстрее.
Хорошо, что у нашего деда была добротная инхаус-команда дома. Но вот как бы выкрутился из этой ситуации его одинокий престарелый сосед? Брал бы аутстаф/аутсорс у нашего героя? Или так бы и бросил свой проект, не собрав урожай?
К тому же, нашему деду безумно повезло — его команда была высоко замотивирована и работала бесплатно. Но, такое бывает только в сказке и в мечтах некоторых заказчиков. Возможно, наш оригинальный сюжет закончился как раз на моменте постоплаты, но это уже совсем другая история…
Главное, что дед мог понести неприятные для него затраты на срочное привлечение команды. И вот тут уже всё могло быть не так просто: Жучку, может, и достаточно погладить по голове со словами «ну кто тут хорошая девочка?», а вот кошка вряд ли стала бы работать без гарантий элитного корма.
Что можно сделать:
Сформируйте ресурсный план и соберите команду заранее, продумав роли каждого.
Убедитесь, что все участники понимают задачу и готовы приступить к работе.
🧩 Риск несогласованности: тянуть в разные стороны
В сказке все участники тянули за одну сторону репки, что обеспечило успех. А вот в IT-проектах часто возникает «перетягивание каната» — каждый тянет в свою сторону.
Причин может быть масса, но на выходе вы можете получить полную несогласованность действий: дед с бабкой тянут в разные стороны, мышь со своими друзьями-кротами могут попытаться сделать подкоп, а внучка со словами «ваши технологии устарели!» может подложить динамит, чтобы репка вылетела с эффектным взрывом.
Что можно сделать:
Заранее определить подход и технологии.
Убедиться, что цели и задачи понятны всей команде.
Настроить регулярный мониторинг и следить, чтобы все двигались в одном направлении.
⚠️ Риск упущенных возможностей: вовремя привлечь помощь
Мышку позвали в последнюю очередь, хотя ее вклад оказался решающим. А ведь иногда именно «незаметные», но важные участники команды (например, аналитик или DevOps) могут посоветовать лучшее решение.
Что можно сделать:
Слушать мнения всех членов команды, даже если они временные участники.
✅ Вывод: риски управляемы, если их учитывать
Сказка про репку — это классический пример того, как важно заранее предусмотреть потенциальные проблемы и вовремя реагировать на трудности. Если бы дед умел в риск-менеджмент, то его царь-репку можно было бы вытащить намного быстрее и без лишних усилий.
И, конечно, не стоит забывать про важность командной работы: даже маленькая мышка может спасти огромный проект.
P. S. Первый пост из этой серии — про инфобез и семеро козлят.
Если проводить аналогию с футболом, то можно сказать, что большинство крупных российских компаний играют с утяжелителями для ног. Если от них избавится – то тогда они побегут.
Agile нужно искать не Jira, а в рабочем окружении, которое не должно мешать постоянному самоусовершенствованию и экспериментам.
Нет таких проектов, которые должны собираться и тестироваться дольше часа, если только речь не идет о логическом синтезе или симуляции.
Время разработчика еще никогда не было настолько дороже, чем железо. Просто добавьте CPU и RAM.
Amazon, Oracle, Google на полную катушку, используют свою же инфраструктуру для разработки. Это не «догфудинг» – скорее они пьют свое же собственное шампанское.
Быстрая итерация становится средой, в которой рождается (а не насаждается сверху) Agile.
Как внедрить ML Autotasking в отделе продаж и что из этого выйдет
Рома Захаров, руководитель аналитики юнита ML Autotasking в коммерческом департаменте Авито, делится опытом, как использовать аплифт от касания менеджера для ранжирования его задач. Почему это влияет на рост эффективности работы и какие проблемы могут возникнуть при создании MVP? Из доклада вы узнаете про:
аплифт как наиболее правильную метрику эффективности менеджера;
автоматизацию выбора клиентов, с которыми будет взаимодействовать менеджер;
механику сбора датасета для обучения модели — почему это было непросто;
сравнение ранжирования клиентов моделью против бейзлайнового алгоритма;
сложности, возникшие при внедрении модели.
А здесь ссылка для тех, кто привык смотреть на YouTube.
Подписывайтесь на канал AvitoTech в Telegram, там мы рассказываем больше о профессиональном опыте наших инженеров, проектах и работе в Авито, а также анонсируем митапы и статьи.
Senior-разработчик: интроверт с большим опытом VS экстраверт, но опыта меньше
Кого выбрать в свою команду?
>> Рассказывает Илья, директор департамента разработки в ЮMoney.
Тут всё, конечно же, зависит от контекста. Если у меня в команде ребята-мидлы, которых нужно растить и обучать, выберу человека, который умеет разговаривать — с хорошо прокачанными софтами. Сегодня в компаниях у разработчиков нет проблем с технической экспертизой (хард-скиллами) — очень уж много доступных материалов и курсов, где можно научиться тому, что нужно. А вот с мягкими навыками у большинства разработчиков сложнее, и натренировать их так же быстро, как харды, не получится.
3 греха в софтах айтишников 😈
Отсутствие критического мышления. Это когда человек к каким-то своим убеждениям не может отнестись критически и переубедить его невозможно. Из-за этого возникают споры в командах.
Когнитивные искажения. Под одними и теми же словами и фразами люди могут подразумевать разные вещи. И это тоже приводит к конфликтам.
Неспособность вовремя остановиться и не работать, когда рабочий день закончился. В ЮMoney есть процесс проверки здоровья команды — Health Check, и среди вопросов есть пункт про нагрузку команды с градацией ответов от «Всё в порядке» до «Мы горим и проектов слишком много!». Если столкнулись со вторым случаем, я встречаюсь с директором департамента проектов, вместе разбираем отчёты по командам и решаем, что можно сделать, чтобы стало легче. Иногда точечно обращаемся к тому сотруднику, которому тяжело, предлагаем помощь. Может, у него вообще проблемы не на работе, а дома: это разбираем вместе с HR BP. Бывают и случаи, когда PM (проектный менеджер) взял слишком много задач и нагрузка возросла так, что стало дискомфортно. Обсуждаем с ним проблему и снижаем нагрузку на команду.
***
Хочешь тоже работать в ЮMoney? Откликайся на наши вакансии! 😉
Сэм Альтман сообщил, что GPT-5 будет бесплатной, а следующей нейросетью OpenAI станет GPT-4.5.
Альтман признал, что сам устал от десятков моделей с разными названиями и неясными функциями — с GPT-4.5 в компании начнут возвращение к понятному неймингу. С GPT-5 номерные модели будут объединять сразу все функции и сами определять, когда им дать короткий, но быстрый ответ, а когда уйти в длительное размышление.
Также GPT-5 запланирована быть бесплатной с неограниченным доступом к чат‑боту и всем функциям, но с базовым уровнем мощности. У нейросети будет несколько ступеней: основная для обычных пользователей, продвинутая для Plus‑подписчиков и мегамощная за $200. Ждать GPT-4.5 осталось несколько недель.
Должен же тимлид смотреть Merge Request (Pull Request)?
Если задать такой вопрос, то большинство людей ответят утвердительно, поскольку это кажется максимально очевидной обязанностью любого тимлида, чтобы:
контролировать качество кода программистов команды;
следить за соблюдением принятых стандартов;
управлять рисками кодовой базы команды;
обучать участников команды через ревью их кода;
держать руку на пульсе того, чем занимаются участники команды.
Однако что делать, если у вас кросс-функциональная команда, состоящая из двух бэкендеров, пары фронтендов, QA и аналитика? Нужно ли вам просматривать все их MR? Сможете ли вы адекватно оценить код на PHP, код на React + TypeScript и автотесты на Python? Очевидно, что нет.
Для разрешения данной ситуации вы можете:
Забить на код-ревью систем, которые не считаете критическими для успеха проекта. Возможно, никто не расстроится, если автотестер будет писать код так, как посчитает нужным.
Попросить разработчиков проводить код-ревью друг у друга. Однако всё довольно быстро превратится в формальные проверки, когда одобрения ставятся просто ради галочки.
Попросить самого опытного разработчика функциональной команды (например, техлида всех фронтендов) просматривать ревью вашего фронта, чтобы всё было хорошо. Но это быстро превращается в узкое место, когда ваши MR ждут ревью неделями, замедляя все релизы.
Как поступить?
Предварительное согласование решений. Мало кому нравится читать чужой код, но многие любят обсуждать правильные подходы. Если члену команды предстоит сложная задача, попросите его описать своё решение и предложите остальным её обсудить. Это станет одновременно и публичной документацией, и предварительным ревью выбранного подхода.
Максимально возможное покрытие фитнес-функциями (автоматические форматтеры, автотестеры, анализаторы кода). Согласуйте с техлидами внедрение в проект автоматических анализаторов и добавьте их в пайплайны репозитория. Ни один MR не пойдёт на ревью до тех пор, пока не будет соответствовать установленным стандартам. Так вы сэкономите массу времени.
Автоматическое распределение код-ревью среди всех участников функции (все фронтенды, все бэкенды), вне зависимости от проекта, с фиксацией лица, поставившего одобрение. Автоматически напомните человеку, что он превысил установленные компанией сроки на проведение ревью.
То есть программисты из других команд могут не разбираться в вашем домене, но они способны проверить, что код не делает ничего лишнего и корректно функционирует в рамках проекта (при нагрузке, сущностях, подходах). А факт рандомности ревьювера и фиксации апрува, не позволит им проводить ревью формально.
Приемочные тесты и регрессионное тестирование при релизах. QA-специалисты проверяют задачи на готовность и удостоверяются, что решение соответствует требованиям, а при выпуске на продакшн проводится автоматизированное тестирование, чтобы убедиться, что система нормально справляется с последним добавлением функционала.
В итоге, если тимлид вместе с техническими лидерами выстроит жёсткую систему доставки инкремента на продакшн, ему самому не обязательно просматривать каждый MR своей команды. Исключение составляют лишь те случаи, когда «душа просит».
P.s. Рекомендую: Эволюционная архитектура - автоматизированное управление программным обеспечением - Нил Форд`
Не пишите ничего на Groovy.
Есть такой шутливый пост про разработку, называется no-code framework. «Лучший способ писать безопасные и надежные приложения. Ничего не пишите, и никуда не деплойте».
Нечто подобное, я мог бы написать про Groovy. Не пишите ничего на Groovy. Особенно пайплайны для Jenkins. Когда-то давно, когда в Jenkins еще не было декларативных пайплайнов, сторонние разработчики сделали плагин – Job DSL, благодаря, которому стало возможным писать джобы на Groovy. Хотя вернее будет назвать этот усечнный вариант языка – Jenkins Groovy.
Для человека у которого в руках молоток, любая проблема выглядит как гвоздь, а для разработчика, девопса или тестировщика, любая задача выглядит как пайплайн на Groovy. Все начинается с хорошей идеи вынести несколько функций в общую библиотеку, а заканчивается монструозной автоматизации, напоминающей машину Руба Голдберга.
Заканчивается это осознанием, того, что так больше жить нельзя, и нужно мигрировать на какой-то другой ci фреймворк. Jenkins здесь не причем – это отличный инструмент, который позволяет гибко настраивать CI под любые задачи, и масштабируется, в умелых руках до тысяч пайплайнов и дестков тысяч билдов.
Самое главное – не пишите ничего на Groovy. Нет, это отличный, хоть и потерявший в последнее время изрядно популярность язык, но описывать на нем сложную логику в CI это все равное, что выстрелить себе в ногу. Можно заставить это работать, но в конечном итоге это замедлит ритм разработки и усложнит всем жизнь.
Разработчики на Groovy встречаются крайне редко, а DevOps инженеры и тестировщики не смогут написать хороший, понятный, тестируемый код. Даже если они научатся, потом эти навыки негде будет применить, потому что за пределами Gradle, Jenkins и Jira, он, сейчас нигде не используется.
Если вам нужно шарить код в CI, то можно писать утилиты или автоматизацию на Python, Go, Bash и упаковывать это все в контейнеры.
Если вы хотите использовать Groovy для того, чтобы написать на нем свой кастомный workflow engine для Jenkins, то остановитесь и подумайте хорошо. Скорей всего это ошибка – все тоже самое можно реализовать с помощь скрипта на Bash или Python, который вызывается внутри декларативного pipe.
Если российские компании, которые написали миллионы строчек кода на Jenkins Groovy и на этом они сейчас теряют сотни тысяч человеко часов.
Решение этой проблемы не переезд на GitLab пайплайны – просто не пишите на Groovy. Если у вас меньше 200 разработчиков и не используется монорепозиторий, вам не нужен Bazel, просто не пишите Groovy.
Все что я написал про Groovy и Jenkins, можно применить к TeamCity и Kotlin DSL.
Все топовые фичи нового релиза Go
Случился релиз новой версии языка Go: 1.24. Разбираем основные нововведения и используем улучшенные инструменты по максимуму.
В новом выпуске avito.code Павел Агалецкий, техлид и бэкенд-разработчик Авито, рассказывает о самых топовых фичах, а также делится их особенностями, благодаря которым писать код станет еще проще.
Смотреть выпуск на YouTube
Смотреть выпуск в VK
Подписывайтесь на канал AvitoTech в Telegram, там мы рассказываем больше о профессиональном опыте наших инженеров, проектах и работе в Авито, а также анонсируем митапы и статьи.
Разработчик из польской инди-студии Immersion Games, который занимался проектом VR-игры про фитнес, похудел в процессе работы на игрой. Он сбросил 30 кг за семь месяцев, пока делал Fitness Fables.
База для изучения одного из популярнейших языков программирования Python. С новыми знаниями вы сможете вкатиться в ИИ, веб-разработку, создание приложений и даже в геймдев.
Курсы и задачи:
Курс «Learn Python 3» от Codecademy.
Курс «Python for Everybody» от freeCodeCamp.
Задачи Python от freeCodeCamp.
Учебник Python от w3schools.
Уроки от Real Python.
Учебник Python от GeeksforGeeks.
Курс Python от Codechef.
Задачи Python от Exercism.
База по Python для вката в ML.
Введение в Python от Стэнфордского университета.
Интерактивные платформы:
Видеоуроки:
Курс CS50 от Гарвардского университета.
Работа с ИИ на Python от Гарвардского университета.
Книги:
Программирование на Python от НТУИТ.
Бонус: в Steam вышла игра Joy of Programming — Software Engineering Simulator от разработчика на Python.
Осваиваем 23 самых популярных языка программирования с нуля. Учебная база содержит практические курсы для начинающих разработчиков, которые хотят изучить новые ЯП, включая всю необходимую теоретическую часть с разделами по ООП и асинхронным программированием. На каждый урок есть практические задачи — читаем теорию и тут же оттачиваем навыки. Авторы проекта показали самые востребованные связки языков программирования и фреймворков.
Как эффектно ворваться в 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 может "выпадать" из встречи, особенно если идет жаркая дискуссия. Вероятно, можно решить эту проблему делегируя задачи транскрибирования и саммаразинга техническим решениям ИИ.
Что еще можно почитать на эту тему:
Учимся проводить совещания (2008 г)
MoM: Как? Зачем? Почему? (2024 г)
Будильник на iPhone с новыми версиями iOS продолжает тормозить. Пользователи жалуются, что мелодия играет с задержкой в несколько часов или не играет вообще. Apple знает о проблеме, но уже год не может её исправить. Временное решение: «Настройки» — «Face ID и код-пароль» — отключите «Распознавание внимания».
Система управления проектами для удаленных команд Virex теперь доступна!
Коммуникация, задачи, аналитика, гибкость — всё это про Virex.
Система управления проектами Virex начинается с простоты. Все проекты в одном месте. Все ключевые данные, задачи и прогресс проекта одном экране.
Матрица задач в Virex гибкая. Вы можете настроить процесс работы под себя: бэклог, задачи в процессе и завершённые задачи — всё это легко управляется и визуализируется.
Лента активности Virex: больше не нужно искать, кто, что и когда сделал. Все изменения в проекте собраны в одном месте.
Встроенные чаты для каждого проекта. Общайтесь со своей командой прямо в Virex.
Заходите в Virex прямо сейчас!
97% языков программирования в мире используют семантическое версионирование.
