Настало время покопаться в шедеврах мировой классики, и выискать там Agile. Мой взгляд сразу упал на любимицу дам Джейн Остин и её «Гордость и предубеждение», потому что это идеальная иллюстрация Agile, как «из книжек», в котором есть и непрерывная обратная связь, итеративность, ретроспектива, реагирование на изменения, и успешное завершение трудного проекта. Всё как мы любим.
Когда в разработке говорят о метриках, многие представляют скучные графики и таблицы, которые существуют ради отчётности. Но метрики — это не числа ради чисел. Это наша приборная панель, без которой управление проектом превращается в полёт вслепую.
Как у пилота, у нас есть разные показатели: одни помогают удерживать курс, например lead time и cycle time, другие вовремя указывают на критические отклонения, а третьи позволяют заранее увидеть «турбулентность» и предсказать риски срыва сроков.
Привет, Хабр!
Частенько тимлидов беспокоит одна ситуация: команда из кросс-функциональных специалистов собирается решить важный вопрос, а процесс превращается в бесконечный спор. Каждый тянет одеяло на себя, вето любого участника способно затормозить прогресс, и в итоге решение либо принимается слишком долго, либо вообще откладывается. В поисках способа ускорить принятие решений и при этом учитывать мнение каждого, естьподход под названием Sociocracy 3.0 (S3). Сегодня я расскажу, что это за методика, как она помогает командам принимать решения на основе согласия без бесконечных обсуждений и вето, и как её можно пилотно опробовать в проекте.
Внедрение искусственного интеллекта перестало быть прерогативой исключительно разработчиков. В этом посте я хочу поделиться своим опытом изучения и практического применения больших языковых моделей, таких как ChatGPT, в области менеджмента, коучинга и продукта.
На протяжении последнего года я активно изучаю возможности искусственного интеллекта. Мой интерес к этой теме начался еще в университете с разработки первых программ на основе нейронных сетей, а позднее я углубился в теорию сложных архитектур и алгоритмов.
Привет, Хабр! Меня зовут Сергей Филатов и я работают в R‑Style Softlab. Сегодня расскажу о разработке с помощью Jmix удобного коннектора для HR‑подразделения, который поможет менеджерам работать с наймом сотрудников.
Мы проанализировали типовой процесс найма сотрудников, который происходит в управлениях по работе с персоналом в разных компаниях и предложили свое решение для автоматизации: простой внутренний инструмент для распознавания и заполнения карточек в «1С. Зарплата и Управление персоналом» и дальнейшей работы с этими сведениями.
Модуль умеет распознавать массив скан‑документов от группы соискателей, подгружать их в 1С, автоматически заполнять карточки соискателей и предоставлять возможность проверки заполненных сведений сотруднику Службы безопасности. Звучит просто, но это помогает экономить множество часов рабочего времени сотрудников HR и сотрудников СБ, которые заняты проверкой кандидатов, убирает рутину и позволяет вести подбор кандидатов быстрее (и эффективнее!).
Еще несколько преимуществ:
Продолжаю разбирать произведения классической литературы по Agile. В первой статье говорил о «Мёртвых душах» и «Преступлении и наказании», где герои использовали принципы Agile и им удавалось достигать результата. А в этой статье разбор неудачного кейса из «Евгения Онегина».
Как использовать метрику потока Throughput и реалистично прогнозировать на основе симуляции Монте-Карло. Разберем динамику Throughput (пропускной способности) за значимые периоды времени, насколько она вариативна, посмотрим на кластеризацию по типам работы).
Разбираем метрику через обслуживание в пабе в пятничный вечер в сравнении с АйТи-командой (с паттернами и примерами). Тема довольно актуальная, так как сейчас в США и Европе расцвет прогнозирования на основе именно метрик потока и появляется много плагинов с Монте-Карло (но не все из них доступны в РФ).
Представьте: вы тихо сидите, пишете документы, проверяете баги или рисуете диаграммы, никого не трогая, как вдруг сверху приходит священный указ: «Ты же всё понимаешь. Расскажи другим.»
И вот вы уже не инженер, а… тренер. Не специалист, а наставник поколения.
Вам вручают группу коллег, которые пришли на обучение так же добровольно, как на медицинский осмотр.
А вы — с презентацией, трясущимися руками и вопросом: «А кто вообще меня сюда поставил?..»
Примите мои соболезнования.
И мою шпаргалку (для себя делал), как инструкцию по выживанию в роли внезапного учителя.
Итак, представим, что вам предстоит войти в аудиторию, где сидит N (5 < N < 20) человек, чьё представление о «бизнес-процессе» ограничивается процессом «заказать кофе с доставкой на работу», а слово «онтология» вызывает боль в мозгах и глазах.
Не паникуйте. Ваша задача — не выйти оттуда поседевшим.
Методология проста: диагностика, интеграция, маска.
Разбираемся по шагам.
Профессиональная деформация заставляет видеть элементы своей работы во всём вокруг. Во время подготовки поездки в отпуск планирую mvp: чек-листы нужных вещей, роадмап поездки, бюджет, сроки. Перед выходом из дома провожу риск-менеджмент: надо ли взять курточку на вечер, если будет холодно? Но моя профдеформация шагнула дальше, и я начал видеть ужасное! Agile в классических литературных произведениях.
"Что будет, если взять Канбан, смешать его с Гантом и весь этот соус вылить на релизную политику? Давайте разбирать на практике!"
Привет Хабр! Я отвечаю за производственный процесс от бэклога до выпуска релиза клиенту в одном из трёх крупных банков, и мой календарь в среднем выглядит вот так. Если твой календарь выглядит похоже, то тебе тоже есть, что менять. Я расскажу о своих девяти правилах, которые помогают справиться с нагрузкой, оптимизировать календарь, перестать уставать и выгорать на работе.
Средняя и крупная организация — это не система, которую можно описать одной схемой. Это поле борьбы и согласования множества истин.
Как работать с этой сложностью? Через методологию "Точек зрения", где фреймворки — не шаблоны, а структуры для диалога.
Представьте, что вы работаете по скраму, но без скрам-мастера. Его задачи распределены между участниками команды. Представили? Отлично! Усложним задачу: представьте, что тимлида тоже нет. «Хаос» — скажете вы? Вовсе нет! Мы так работаем уже несколько лет.
Привет, я — Иван Зверев, фулстэк в Додо. Сегодня я расскажу о том, как круто может самоорганизоваться здоровая команда, если довериться ей, обозначить прозрачные правила работы и дать свободу экспериментировать с процессами. Вперёд!
В этой статье я хочу рассказать об опыте проектного управления в условиях Agile.
Проект, о котором пойдет речь, внедрен в Сбере два года назад. Я выбрал его в качестве примера во-первых потому, что он успешно внедрился, и опыт был признан заказчиками положительным, а во-вторых, на нем можно наглядно проговорить плюсы выделения независимого руководителя проекта.
Для упрощения восприятия сократил немного деталей, но с сохранением сути.
Представленные данные на экране СберБанк Онлайн – вымышленные.
Описание постановки задачи
Подразделением, отвечающим за улучшение клиентского опыта в СберБанк Онлайн (далее - СБОЛ), была поставлена задача: «Отображать секции «Инвестиции» и «Сбережения и пенсии» в раскрытом виде на экране «Накопления» с выводом текущего состояния счета и дохода по каждому из продуктов".
Корпоративное обучение стало неотъемлемой частью работы любой команды или бизнеса. С ним сталкиваются все: от небольших стартапов до крупнейших корпораций. И это неудивительно — в меняющемся мире постоянно появляются новые инструменты, подходы и способы оптимизации. Обучение уже вошло в обязательные HR-стратегии: крупные компании запускают корпоративные университеты, внедряют внутренние платформы, организуют курсы и привлекают внешних подрядчиков.
Однако до сих пор обучение чаще всего рассматривается как надстройка. Оно не встроено в рабочий процесс, а существует параллельно — как что-то дополнительное. Такой подход кажется привычным, но и команда, и руководители всё чаще отмечают его слабые стороны.
В этом эссе — попытка переосмыслить культуру не как мораль и "систему ценностей", а как онтологию: систему сущностей, отношений и паттернов.
Я покажу, как культура теннисистов, шахматистов и open-source разработчиков строится на признании, стыде и неформальных правилах.
И почему попытки «внедрить культуру» превращаются её в имитацию.
Одно недопонимание на встрече может стоить вам недель переделок. В этой статье рассказываем, какие визуальные нотации помогут бизнес-аналитикам и командам понимать друг друга без лишних ошибок. Простые схемы и диаграммы, которые ускорят работу и сделают процессы понятнее для всех: от заказчика до разработчика. Узнайте, как выбирать и применять BPMN, ERD, Sequence Diagram и User Story Mapping в реальных проектах.
Более 30 лет я преподаю — в Вышке, РАНХиГС, Бауманке. За это время сменилось несколько президентов, десяток министров образования, бесчисленное количество реформ, стандартов, платформ и лозунгов. А я, человек с двумя дипломами — инженерным и философским, — всё это время смотрел на систему изнутри и задавал один и тот же вопрос: а что, черт возьми, такое образование на самом деле?
Вроде бы всё написано в законе: образование — это услуга. Рыночная. Сервис для потребителей (студентов), заказчиков (государства, работодателей) и поставщиков (вузов, школ). Просто, понятно, современно.
Но чем дольше я преподаю, тем сильнее ощущаю: это ложь.
Не злая, не корыстная — просто онтологическая ошибка. Потому что если образование — это услуга, то почему вся система медленно, но верно деградирует, а "невидимая рука рынка" образовательных услуг все больше напоминает не руку, а заднее место? Почему даже при растущем финансировании, новом оборудовании и «умных» досках — теряется самое главное?
Не знания. Не навыки. А смысл системы.
В 90-е можно было списать всё на бедность. В нулевые — на отсталость технологий.
Но сейчас? Сейчас у нас есть интернет, онлайн-курсы, ИИ, который пишет за студентов курсовые, дипломы и даже диссертации. А функционеры системы образования смотрят на это, и прячут свои мозги как страус — в песок.
И тут возникает вопрос, который уже нельзя игнорировать: а что, если старая онтология мертва? Что если «услуга», «потребитель», «ЗУНы» и «компетенции» — это архаизмы, которые ИИ просто добивает окончательно?
Привет, Хабр.
Хочу на основе одного проекта поделиться личным опытом: как от полного хаоса в разработке и управления API в виде спецификаций в Confluence мы пришли к удобному и понятному процессу с OpenAPI-спеками и кодогенерацией.
Покажу несколько вариантов, как можно работать с API на практике, с плюсами, минусами и неочевидными граблями каждого из этих подходов: от проектирования и разработки до внесения и согласования изменений.
В статье не будет никакой теории, все примеры и подходы взяты из моей практики, но не ищите тут открытий и откровений. Зачем я её написал? Хочу показать, что выстроить удобный процесс разработки API не сложно, и это принесёт много пользы проекту и команде.
В рамках еженедельных образовательных стримов прошла встреча по фреймворку для продуктовых команд - Scrum. Я скептически относилась к нему в десятые, когда "внедрение" было скорее модным, чем полезным. Но сегодня, имея в организационной структуре компании выделенные продуктовые команды можно точно сказать - Scrum лучший набор инструментов для разработки/создания нового продукта (и речь не только о цифровом продукте, конечно).
Запись встречи можно посмотреть здесь. Отвечу на любые вопросы. Ниже кратко резюме:
Scrum — фреймворк из группы гибких подходов (Agile). Может быть в комбинации с другими гибкими фреймворками. Немного о терминологии:
🕊️ Методология - система принципов, практик, процессов и правил для управления проектами на уровне всей компании. Правила организации процесса готовки с набором кулинарных книг и требованиям к кухне.
🕊️ Фреймворк - гибкая структура с набором рекомендаций, но без строгих правил. Позволяет адаптироваться под контекст. Рецепт конкретного блюда, где, вместо молока, если у вас аллергия, вы не можете добавить воду. Приготовьте другое блюдо.
🕊️ Подход - общая стратегия или философия управления проектами. Будете ли вы пользовать книгой рецептов при готовке или нет? Концептуально. Если да - европейская кухня или русская?
🕊️ Метод - конкретный способ решения задачи в рамках методологии или фреймворка. Обжаривать на открытом огне или с крышкой?
🕊️ Инструмент - инструмент. Не знаю, какое ему дать определение) Ложка, масло.
Итак:
🕊️ Подход: проектный
🕊️ Методология: Agile
🕊️ Фреймворк: Scrum
🕊️ Метод: Спринт, бэклог, ретроспектива и т.д.
🕊️ Инструмент: Agile poker planning, диаграмма сгорания спринта, kanban-board и т.д.
