Как структурировать диалоги с LLM: шаблоны, интенты, статусы и архитектура ai-dialog-system, превращающая хаос в управляемую систему. Подход подходит для аналитики, CI и командной разработки.
Привет, Хабр! Это команда стажировок Авито и мы подготовили простой тест для стажеров, которые не знают, как выбрать направление в IT.
На стажировке в Авито начинающие инженеры могут за полгода дорасти до уровня junior в QA или Frontend-, Backend-, Android- и iOS-разработке. С первых дней на программе ты сможешь работать над реальными задачами рука об руку с более опытными коллегами. А что именно нужно будет делать и как подобрать наиболее подходящее направление развития — узнаешь из этой статьи.
Мы просто смотрим на экран. Один варнинг. Один, но он красный. Он "орёт". Не получается сразу понять, в чём дело. Условный рефлекс срабатывает, и уже открывается Git. Сейчас пофиксим, а потом подумаем. Даже если предупреждение касается чего-то безобидного, один красный прямоугольник на фоне зелёных строчек может парализовать внимание.
Как вы думаете, нужно ли архитектуру на вашем текущем проекте подвергнуть масштабному пересмотру и исправлению? Ставлю на то, что большинство читателей ответят положительно. И эта часть именно про это. В ней мы рассмотрим:
1. Когда сложившаяся архитектура подлежит масштабным изменениям.
2. Что не менее важно, когда лучше оставить, как есть.
3. Ключевые признаки проблем в архитектуре.
4. Основные способы исправления таких проблем.
Но для начала мы вспомним, что было в предыдущих сериях. В первой части мы прошлись по теории и выяснили:
1. Что техническая реализация заметно влияет на успехи бизнеса, хоть и не очень критично;
2. Что из всех аспектов технической реализации наибольший вклад в успех вносит именно архитектура;
3. Что самое важное свойство архитектуры — максимальная независимость команд друг от друга;
4. Что это свойство вытекает напрямую из двух фундаментальных характеристик программного обеспечения: coupling и cohesion, где coupling — характеристика связи двух точек системы/кодовой базы; а cohesion — характеристика того, насколько плотно упакованы такие связи в компоненты.
Во второй части мы уже перешли к практике построения архитектуры с нуля. Мы узнали:
1. Что попытки угадать с архитектурой до старта проекта обычно проваливаются.
2. Что маленькие команды работают буквально в разы эффективнее, чем большие.
3. Что лучший способ разделить софт между командами - делать это постепенно. Начать с одной команды и уже затем дробить систему по обнаруженным в процессе разработки границам.
Теперь перейдем к вопросу, что же делать, если «все уже украдено до нас».
Обзор без маркетинга, с фокусом на то, что реально нужно менеджеру: практика, широта тем, прикладные знания, релевантность, отсутствие воды и инфоцыганщины.
Как-то раз уже делался обзор по всем существующим на рынке курсам по управлению проектами, пришло время почихвостить рынок с новой, актуальной темой.
Когда-то всё было проще. В достопамятные двухтысячные годы джунов и в самом деле нанимали. Не спрашивали о «релевантном опыте», не требовали ссылки на боевые проекты и не строили сложных лабиринтов из HR-интервью, технических сессий, тестовых заданий и многоступенчатых собеседований. Но прошло 15–20 лет — и всё изменилось до неузнаваемости. Новички (стажёры и джуны) теперь бесправны и даже подозрительны.
За семь лет проведения воркшопов по Story Points я наблюдаю одну и ту же картину: команды изучают технику, применяют её несколько спринтов, а затем постепенно возвращаются к старым паттернам. И если на маленьких масштабах работы с одной командой или тремя кажется что Story Points прекрасный подход, на текущем масштабе — около 50 команд в IT — 60% используют Story Points, 40% не используют - я вижу совершенно иную картину. И вот что интересно: те 60%, которые используют, делают это крайне по-разному.
Причем конверсия в правильное использование Story Points 3 месяца после тренингов составляет дай бог 20%. Проблема не в самом инструменте, а в том, как мы его используем и для каких целей.
Привет, меня зовут Анатолий Чикирев, и сегодня я расскажу вам о Lean-практиках сокращения потерь в IT-сфере. Для начала давайте договоримся о терминологии. Lean и бережливое производство — это синонимы. Я буду использовать оба термина, но речь пойдёт об одном и том же. Но сначала пара слов обо мне и моём опыте.
Я работаю продактом в SM Lab с 2022 года, в целом в IT пришел в 2018 году — тогда я занимался заказной разработкой. Впервые я узнал о бережливом производстве в Высшей школе экономики, где изучил базовую теорию и основные понятия. Уже тогда мне показалось это интересным, но, разумеется, практики ещё не было никакой. Потом я пришел на свою первую работу на завод, где участвовал в пилотном проекте по внедрению Lean с привлечением консультантов. Там я руководил проектным офисом, поэтому сам проект видел больше с административной точки зрения и только несколько раз выходил «в поле» с руководителем проекта, а глубже в суть методологии погрузился уже позже.
Следующим этапом стала работа в международной FMCG-компании, где бережливое производство уже было внедрено, и я пришёл, как говорится, «на готовенькое»: моей задачей было поддерживать систему, развивать её и внедрять новые инструменты и практики, которые предлагала международная команда. Именно тогда я по-настоящему прочувствовал пользу и мощь Lean, увидев, как эти принципы работают на практике в производстве и какой эффект они могут приносить бизнесу.
Когда я перешёл в IT (сразу после той самой FMCG-компании), у меня возник большой вопрос: «А работает ли Lean здесь?». Я понимал, что теоретически — должно. Но как именно это применять? Как перенести инструменты, которые я применял на производстве, на IT-процессы? Поначалу это было неочевидно. Со временем, когда я освоился и в IT, и в роли продакта, и в самой SM Lab, всё встало на свои места. Я разобрался, как Lean может работать здесь, начал внедрять его на практике — и применяю до сих пор.
Когда команда разработки делится на два лагеря из-за ИИ, а релиз вряд ли подождёт, возникает ступор и вопрос — что делать? В статье — как я решал эту проблему, шерстил исследования, форумы и вытащил у коллег 10 рабочих промптов для ускорения работы.
Чем дольше я работаю в разных системах управления проектами — тем лучше понимаю, насколько разные у команды и руководителей приоритеты.
— Сотрудникам важно легко разобраться в интерфейсе, держать под рукой свои задачи и красивый фон для доски с задачами выбрать 😌
— Руководителям важно знать, кто чем занят, контролировать работу команды и видеть полную картину по проектам 😎
Этот обзор я решила посвятить руководителям, так как сама пару лет назад начала управлять отделом. И теперь мои требования к системе управления проектами сильно возросли. В нем будут обзор возможностей для руководителей в разных сервисах, примеры использования и комментарии из личного опыта. Сотрудником тоже будет полезно о них узнать.
Переименование Scrum Master в Agile Delivery Manager — не просто смена названия на бейдже. Это отражение глубинных изменений в понимании роли, сфокусированной не на фреймворке, а на реальной ценности, которую команда приносит бизнесу. В эпоху потокового мышления и зрелых инженерных практик, где CI/CD — уже норма, лидерство в поставке перестаёт быть вспомогательной функцией. Эта статья — о том, как меняется суть роли, почему Scrum становится слишком узким, и почему переход к модели ADM может стать следующим логичным шагом для тех, кто давно перерос рамки agile 101.
Пока менеджеры мечтают о мире, где можно просто шепнуть ChatGPT «сделай мне Uber, но подешевле» — и вуаля, готовый продакшен, разработчики делятся на два лагеря: одни паникуют, другие спокойно встраивают Copilot в рабочий процесс и смеются над его гениальными архитектурными решениями.
Но давайте будем честны: если бы ИИ действительно мог заменить разработчиков, мы бы уже жили в утопии, где техдолг исправляется одним кликом, баги фиксятся до того, как попадают на прод, а документация пишется без привычных «TODO: исправить позже».
Я Илья Некрасов, Android Team Lead KODE. В этой статье предлагаю разобраться, почему бизнес так любит идею «разработки без разработчиков» и почему она не работает.
Клиенты бывают требовательными, взыскательными, с невыполнимыми или неподходящими идеями. А если клиент ещё и с другим менталитетом, то коммуникация усложняется вдвойне. Расскажу про свой опыт и на примере жизненных кейсов покажу, как начать говорить с зарубежным клиентом на одном языке. Ведь почти весь мой опыт работы — с клиентами из США и Европы. Причём клиенты разные — от соло-стартаперов до менеджеров и дизайнеров из Google.
Эти истории помогут продактам, проджектам и даже инженерам — всем, кто взаимодействует с заказчиком напрямую.
Привет, Хабр! Меня зовут Рома Ковалевский, я program-менеджер из Берлина с 10+ годами опыта. Работаю с топами из бигтеха США — мои коллеги работали в компаниях вроде Google, Amazon, Apple и других гигантах. Веду собственный телеграм-канал про управление проектами «Менеджер от боженьки». Там — больше полезных постов и инсайтов о карьере проектного менеджера.
С AGI не баловался только ленивый.
О TD не писал только очень ленивый.
На момент конца ноября 2022 года интернет содержал более 60 "статей" как нам тяжело жить и банкротиться. Из них меньше десятка на русскоязычных ресурсах. Тогда я хотел сделать анализ всех этих статей "ручками", в итоге пытаюсь закрыть гешефт гештальт нелениво, напрягая мозжечок alice.yandex и sber.giga.chat
Привет, Хабр! Меня зовут Наталия, и я руковожу отделом тестирования в группе компаний Экзон. Начала карьеру в IT 7 лет назад с позиции стажера автоматизатора, работала фулл-стек тестировщиком, тех-лидом и имею опыт построения команд тестирования с нуля.
Когда я пришла на проект, у нас было 9 тестировщиков, из которых только двое умели писать автотесты. Остальные работали вручную, а покрытие автотестами составляло 30% на двух модулях из шести. Регресс длился вечность, баги вылезали в продакшене, а команда мечтала о волшебной кнопке “Протестировать всё”. Но вместо поиска магии мы выбрали стратегию, которая сократила время регресса и жизнь багов. И да, мы не нанимали дорогих аутсорс-гуру и не продавали душу рекрутерам.
Нанимать джунов — это настоящая pain in ass. Откликов приходит больше ста в неделю, а кандидаты отличаются по уровню: одни только вчера окончили курсы, другие — почти мидлы. Пока разберем все отклики, проверим тестовые, проведем собеседования — проходит полтора месяца. А потом найденный сотрудник не проходит испытательный, и все повторяется снова.
Чтобы облегчить поиск, мы в Mindbox настроили конвейер стажировок. Теперь на отбор тратим меньше времени, а получаем разработчиков, знакомых с процессами, проверенных «в бою» и лояльных к компании. В статье — подробная инструкция для нанимающих менеджеров: как построить процесс, проводить собеседования и онбордить стажеров.
Далее >>>
Об авторе
Меня зовут Глеб Ковалев, я ведущий frontend-разработчик в Mindbox. Пару лет назад я начал проводить стажировки для frontend-разработчиков. А сейчас начинающих фронтов мы нанимаем преимущественно через стажировки. О том, как это происходит, расскажу в этой статье.
Приветствую! Меня зовут Борис, я руководитель отдела фронтенд-раработки в ЮМoney и продакт-менеджер платформенной команды. О сложностях управления подобными командами и проблемах, которые иногда возникают, уже рассказывал в своей предыдущей статье. Сегодня хочу поделиться историей о том, как в условиях ограниченных ресурсов нам удалось выстроить консистентность пользовательского интерфейса в сервисе, который состоит более чем из 70 микросервисов и охватывает разные направления бизнеса.
Так почему же Contract First оказался не так хорош на практике?
Это связано с тем, что в теории Contract First не учитывает необходимость постоянных доработок контракта и коммуникации между командами. Основная проблема кроется не в инструментах, а в процессах разработки API: если они выстроены плохо, коммуникация нарушается. Именно процессы — а не недостаток компетенций или инструментов — являются источником проблем.
Привет, Хабр! Меня зовут Алексей Панаэтов, я технический лидер Центра геосервисов в МТС Web Services. Каждый руководитель рано или поздно задается вопросом о количественной оценке эффективности команды. Метрики помогают принимать решения объективно, но их очень сложно строить, когда в работе активно используются множества разных инструментов: трекеры задач, системы контроля версии, корпоративный мессенджер и другие. К ним нужно сначала получить доступ, затем выгрузить и обработать нужные данные. Ad-hoc-методы вроде csv-файлов и таблиц Excel подходят для разового анализа, но их тяжело поддерживать.
Я тоже столкнулся с этой проблемой и для ее решения создал и выложил в открытый доступ код CaptainBridge — инструмент, который помогает собирать и строить метрики эффективности команды.
