«Я больше не хочу работать по пятницам», — заявил Герр Фрике, сооснователь Solidence. После полугода эксперимента с четырёхдневкой 45 немецких компаний доказали: работать меньше и зарабатывать больше — реально.

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

Я занимаюсь созданием IT-систем и продуктов для людей уже более 10 лет. Такая работа позволила мне изучить различные инструменты для принятия решений, проектирования и системного мышления. При этом практически никогда я не использовала полученные профессиональные навыки в личных целях. До последнего времени. В статье расскажу на примере кошкопользователя, как можно знания разработки продуктов использовать для себя. Насколько интереснее становится их применять и глубже изучать.

Всем привет! Я Константин Мовчан, руководитель аутстаффинг-направления в AGIMA. За годы работы в IT я встречал многих руководителей, которые рано или поздно упираются в один вопрос: «Что лучше: растить лидеров внутри команд или привлекать сильных специалистов с рынка?» На одной чаше весов долгое, но качественное развитие команды, на другой — быстрый и эффективный наём через внешние каналы. 

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

Эта статья точно будет полезна СТО, руководителям IT-департаментов, руководителям IT-рекрутмента, IT-лидам и CPO — всем, кто отвечает за управление и развитие команд в IT.

Многие из нас задаются вопросом, как развиваться, расти, продвигаться по карьере и больше зарабатывать. Ответ зависит от множества факторов, в первую очередь от грейда: Junior вы, Middle или Senior. Есть ли у вас семья, насколько вы готовы к риску и к принятию неприятной правды.

В каком типе компаний развиваться выйдет более эффективно? Джуну лучше в стартапе или в enterprise? А сениору лучше пилить свои проекты или идти в стартап?

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

В этой статье я дам краткую вводную, что такое Archi и ArchiMate. Расскажу о коллективной работе с Archi используя расширение coArchi, после чего предоставлю контейнер позволяющий автоматизировать работу по созданию HTML и PDF документов с ArchiMate моделями. Завершим же, созданием своего GitHub Action, настроим GitHub и GitLab пайплайн с последующей публикацией модели в GitHub/GitLab Pages.

Плюс одно мнение — кому все-таки стоит идти в управление людьми. Или как понять, что у CEO/PO на уме.

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

Какие практики внедрили в нашей команде, сопровождающей 10 систем, чтобы снизить Bus Factor и уменьшить время входа для новичков.

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

Поехали!

Генерация дополненного извлечения (RAG) стала самым популярным способом предоставления LLM дополнительного контекста для создания адаптированных выходных данных. Это отлично подходит для приложений LLM, таких как чат-боты или агенты ИИ, поскольку RAG предоставляет пользователям гораздо более контекстуальный опыт, выходящий за рамки данных, на которых обучались LLM, такие как GPT-4.

Неудивительно, что практикующие LLM столкнулись с проблемами оценки приложений RAG во время разработки. Но благодаря исследованиям, проведенным RAGA, оценка общих характеристик генератора-извлекателя систем RAG в 2024 году является в некоторой степени решенной проблемой. Однако создание приложений RAG до сих пор остается проблемой — вы можете использовать неправильную модель встраивания, плохую стратегию фрагментации или выводить ответы в неправильном формате, что как раз и пытаются решить такие фреймворки, как LlamaIndex.

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

Привет, Хабр!

Меня зовут Александр, я CEO агентства переводов Kolko Group и студии локализации игр Start Localize. Мы специализируемся на локализации, переводе и работе с контентом, сейчас всё больше фокусируемся на проектах для IT и Gamedev.

Сегодня хотелось бы обсудить со всеми удаленную работу, и как её оптимизировать. Я создавал своё агентство переводов и локализации ещё в далеком 2015 году. Открывая агентство, я ориентировался только на привлечение B2B клиентов, поэтому решил обойтись без офиса и сконцентрироваться только на онлайн-работе. На данный момент в нашей команде порядка 10 человек в штате и 250 на аутсорсе (переводчики, редакторы, верстальщики и копирайтеры), и мы до сих пор продолжаем расти.

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

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

По сути, системное проектирование (System Design) — это процесс определения архитектуры, компонентов, модулей, интерфейсов и данных для системы, удовлетворяющих заданным требованиям. Оно включает в себя преобразование требований бизнеса в подробную схему, которая служит руководством на этапе внедрения. Другими словами, на этапе проектирования системы мы выполняем перевод с языка бизнеса на язык ИТ.

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

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

TLDR. Я примерно год создавал курс из 141 урока. Курс получился хороший, все кто проходят рады и пишут положительные отзывы. Я пытался его продавать, в лучшем случае у меня получалось отбивать рекламу в ноль. Короче, я хороший разработчик, я хорошо доношу материал, но я плохой маркетолог. Все эти таргреты, ретаргеты, воронки, шморонки — тоска унылая. Мне гораздо веселее и понятнее заработать на создании и запуске IT-продуктов, чему я и учу в этом учебнике. Так что пишу эту статью, чтобы сообщить вам о существовании моего курса и предложить всем желающим абсолютно бесплатно получить от него пользу 🙂

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

Я недавно решила углубленно разобраться, какие архитектуры бывают в разработке ПО, и написать об этом простую статью. Это моя первая попытка поделиться своими мыслями и объяснить сложные вещи на понятном языке, поэтому буду рада вашей обратной связи

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

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

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

Привет, Хабр!

Зовут меня Егор, и в этой статье я хочу рассказать, как мы с ребятами из компании АИСА запилили свой аналог Jira – с блэкджеком и быстрым API на Go.

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

Одним из часто задаваемых вопросах на собеседовании на позицию Project Manager, а также для сдачи экзамена на сертификат Project Management Professional (PMP)® Exam является вопрос о пяти стадиях формирования команды, таких как Forming, Storming, Norming, Performing, Adjourning, её также называют моделью Такмена в честь её автора Брюса Такмена. Предлагаю разобраться в том, что представляют из себя эти стадии и почему так важно понимать данную концепцию.

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

Существует несколько моделей групповой динамики малых социальных групп. Мы рассмотрим простую и проверенную временем модель Такмана (Bruce Tuckman model). Модель подкупает своей простотой и наглядностью. Чтобы овладеть азами групповой динамики по этой модели, достаточно запомнить последовательность четырёх слов: Forming, Storming, Norming, Performing.

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

А это уже под «катом»…