0 просмотренных постов скрыто
Декомпозиция задач: Как сделать проекты управляемыми и успешными — for Business analyst, Scrum master, Project Managers!
Декомпозиция задач — это процесс разбивки сложной задачи или проекта на более мелкие, управляемые и понятные подзадачи. Этот подход позволяет упростить выполнение задачи, сделать её более структурированной и снизить уровень стресса, связанного с её выполнением.
Декомпозицию задач можно осуществлять как на этапе планирования нового спринта, так и в процессе реализации спринта, разбивая требования для дальнейших итераций. Однако второй подход является более предпочтительным. Не стоит привязывать декомпозицию к конкретному спринту, чтобы приходить к его планированию с уже подготовленным бэклогом, разделённым на пользовательские истории .
В такой ситуации, если у нас есть запас декомпозированных требований, это даёт следующие преимущества:
Во-первых, мы не ограничиваем себя в выборе задач для спринта (можем работать только с теми задачами, которые уже декомпозированы).
Во-вторых, во время планирования не нужно тратить время на разбивку, и команда может сосредоточиться на формировании спринта с учётом всех приоритетов, обсудить зависимости и детали реализации требований.
В-третьих, митинг пройдет более продуктивно, и все участники команды будут активно вовлечены. Не забывайте, что митинги должны быть результативными и позитивными, чтобы команда ожидала их с нетерпением, а не воспринимала как скучную рутину.
Два основных подхода к декомпозиции.
Существует два базовых подхода к декомпозиции крупных задач на пользовательские истории — «горизонтальное» и «вертикальное» разбиение:
При применении так называемой «горизонтальной» декомпозиции, задачи делятся на основе типа выполняемых работ (функций) и используемых компонентов. В данном подходе большая задача разбивается на части, где разработчик получает одну долю обязанностей, тестировщик — другую, а технический писатель — третью, и так далее. Важно отметить, что каждая из этих частей не приводит к завершенному результату самостоятельно; для успешного выпуска готового функционала требуется совместная реализация всех взаимосвязанных задач всеми участниками процесса. Пример горизонтальной декомозиции из саб-тасков в Jira:
С другой стороны, «вертикальный» подход к декомпозиции акцентирует внимание на выделении более мелких задач, функций и особенностей, так что каждая пользовательская история может быть реализована и завершена независимо от других. В этом случае в процессе разработки могут участвовать различные роли, а также задействоваться несколько модулей и систем, обеспечивая большую гибкость и скорость в реализации функционала. Пример вертикальной декомозиции из саб-тасков:
Разбиение задач с использованием «вертикального» метода больше соответствует Agile принципам и его применение гораздо более эффективным, основные причины в следующем:
• При использовании «вертикального» подхода к декомпозиции каждая задача становится доступной для реализации, тестирования и демонстрации клиентам или пользователям, что делает её понятной и измеримой, в отличие от более абстрактных «технических» задач, которые возникают при «горизонтальной» разбивке.
• В рамках «вертикальной» декомпозиции каждая конечная пользовательская история обладает явной ценностью для бизнеса, что упрощает процесс сравнения и определения приоритетов таких задач.
• Учитывая, что в решении задач, организованных по «вертикальному» принципу, участвуют специалисты с разными ролями, они легче могут выявить потенциальные проблемы, зависимости и риски, которые могут возникнуть в ходе выполнения работы.
Техники декомпозиции требований
Способ 1: Этапное разбиение бизнес-процессов
Этот подход предлагает разделить крупную задачу, связанную с бизнес-процессом, на более мелкие, независимые компоненты и этапы. Для реализации этого метода важно выделить последовательные шаги, которые можно выполнять автономно. Например, если в бэклоге имеется требование по реализации функции онлайн-покупки, то этапы могут включать:
Вход в личный кабинет
Просмотр товаров в «корзине»
Формирование счета
Отправка счета на почту
Оплата различными способами: банковская карта, перевод и т.д. Каждый из этих этапов можно оформить как отдельную пользовательскую историю. Таким образом, мы разбиваем обширный бизнес-процесс на составные части, что позволяет определить приоритеты и лучше понять процесс в целом, включая возможные зависимости между этапами.
Способ 2: Разделение на позитивные и негативные сценарии
Каждая функциональность включает в себя основной сценарий использования, который ведет к ожидаемому результату, однако возможны и отклонения, приводящие к негативным последствиям. Этот метод предлагает выделить сценарии, которые могут привести к успешному или неудачному результату. Например, для функции покупки в интернет-магазине:
Позитивный сценарий: пользователь авторизуется и успешно совершает покупку.
Негативный сценарий 1: попытка покупки без авторизации.
Негативный сценарий 2: недостаточно средств на счете для завершения транзакции.
Негативный сценарий 3: блокировка учетной записи после нескольких неверных попыток ввода пароля.
Такой подход позволяет заранее определить и спланировать обработку возможных ошибок и исключений.
Способ 3: Разбиение по правилам и условиям
В отличие от предыдущего метода, здесь акцент делается не на этапах, а на логических ветках процесса, основанных на различных правилах. Например, для функции покупки можно выделить правила, такие как:
Минимальная сумма покупки.
Дополнительные варианты оплаты при превышении определенной суммы.
Автоматическая отмена заказа через 2 дня без оплаты.
Каждое из этих условий может быть оформлено как отдельная задача, что помогает выявить важные ограничения и упрощает процесс реализации.
Способ 4: Разделение по типам операций
Многим функциональным требованиям соответствуют стандартные операции, такие как создание, чтение, обновление и удаление (CRUD). Например, для управления карточкой товара в интернет-магазине можно выделить:
Create: добавление нового продукта.
Read: просмотр описания продукта.
Update: редактирование информации о продукте.
Delete: удаление товара из магазина.
Такое разбиение позволяет четко определить необходимые операции и их приоритеты.
Способ 5: Декомпозиция по платформам и ОС
Этот метод заключается в разделении требований в зависимости от платформы или операционной системы. Например, для функции оплаты в интернет-приложении можно выделить задачи для различных устройств:
Персональные компьютеры
Планшеты
Смартфоны
Разные операционные системы: Windows, iOS, Android.
Такой подход помогает определить приоритетные направления разработки.
Способ 6: Разделение по типам данных и параметрам
Некоторые функции могут обрабатывать различные типы данных или параметры. Например, для функции поиска в интернет-магазине можно выделить:
Поиск по наименованию товара.
Поиск по номеру товара.
Поиск с использованием регулярных выражений.
Эта декомпозиция позволяет четко определить допустимые параметры и легко управлять требованиями.
Способ 7: Разделение по ролям и правам доступа
Разные группы пользователей могут иметь разные права доступа и выполнять различные функции. Например, в интернет-магазине это могут быть:
Владелец: создание и удаление товаров.
Администратор: редактирование описаний и работа с клиентами.
Клиент: просмотр и покупка товаров.
Такое разбиение помогает понять, какие функции необходимы для каждой роли и приоритизировать их реализацию.
Способ 8: Декомпозиция по тестовым сценариям
Этот метод разбивает функциональность на основе тест-кейсов, которые необходимо проверить для проверки успешности работы функций. Например, для функции добавления товара в «корзину» могут быть выделены следующие тестовые сценарии:
Товар доступен для покупки.
Товар зарезервирован другим пользователем.
Товара нет в наличии.
Такой подход позволяет объединить различные техники декомпозиции и формирует ясные задачи для разработки и тестирования.
Каждый из этих методов декомпозиции помогает лучше структурировать требования и способствует более эффективной разработке в Agile-среде.
Преимущества Декомпозиции задач:
Улучшает понимание: Разделение крупных задач (или историй пользователей) на более мелкие позволяет команде лучше понять, что именно требуется сделать. Мелкие задачи легче осмысливать и обсуждать.
Лучшая оценка: Команда может более точно оценить время и усилия, необходимые для выполнения мелких задач, что улучшает планирование и управление ресурсами (Гарантирует отличный Митинг Планирования используется числами Фибоначчи или последовательность T-Shirt Sizes ).
Управляемость: Мелкие задачи легче планировать и контролировать. Команда может более точно оценить временные и трудозатратные ресурсы для выполнения каждой задачи.
Увеличение прозрачности: Когда задачи разбиты на более мелкие части, становится легче отслеживать прогресс и выявлять проблемы на ранних этапах. Это позволяет команде быстро реагировать на изменения.
Повышение гибкости: В Scrum часто происходят изменения в требованиях, и декомпозиция задач позволяет команде более гибко реагировать на эти изменения, адаптируя свои планы и приоритеты.
Улучшение качества: Мелкие задачи позволяют команде сосредоточиться на качестве выполнения каждой отдельной части. Это может привести к более высокому качеству конечного продукта.
Стимулирование сотрудничества: Декомпозиция задач может содействовать более активному сотрудничеству внутри команды, так как участники могут работать над различными частями одной задачи одновременно.
Постепенная интеграция: Разделение задач на более мелкие части позволяет команде поэтапно интегрировать и тестировать функциональность, что уменьшает риски и улучшает стабильность.
Я надеюсь, что данная информация вам пригодилась! Если у вас есть вопросы или пожелания, оставляйте комментарии. Буду рад помочь вам с личными советами по IT, бизнес-анализу, Scrum или управлению проектами!
Показать полностью
3
Скрам vs Канбан: Погружение в Agile, плюс памятка для проектных менеджеров!
Приветствую вас, коллеги и соратники в мире управления проектами! При разработки программного обеспечения существует множество подходов, методологий к управлению IT проектами. Среди них топ места занимают Scrum и Kanban. Сегодня освежим наши знания об этих двух методах, и принципах их применении.
Скрам: Кратко о главном
Scrum — это фреймворк для управления проектами, который фокусируется на гибкости и адаптации к изменениям. Это одна из основных методологий по управления проектами из семейства Agile.
Основные элементы Скрам:
Роли:
Product Owner: отвечает за создание и приоритизацию бэклога продукта.
Scrum master: помогает всей команде следовать процессам скрам и устраняет препятствия, которые могут мешать работе.
Developers: группа специалистов, которые выполняют работу по созданию продукта.
Артефакты:
Бэклог продукта: список всех задач и требований, которые должны быть выполнены.
Бэклог спринта: задачи, выбранные для выполнения в текущем спринте.
Инкремент: завершенная работа за спринт, которая добавляет ценность продукту.
События:
Спринт: имеет фиксированный период (обычно 2-4 недели), в течение которого команда работает над задачами.
Планирование спринта: встреча для определения задач, которые будут взяты в работу и выполнены входе спринта командой.
Ежедневный стендап(daily-ки): короткие ежедневные встречи для обсуждения прогресса и препятствий.
Обзор спринта: встреча для демонстрации завершенной работы(демо) заинтересованным сторонам.
Ретроспектива: встреча для анализа прошедшего спринта и выявления возможностей для их улучшения.
Канбан: Кратко о главном
Канбан — это метод управления процессами, который акцентирует внимание на визуализации работы, ограничении незавершенных задач и постоянном улучшении. Это одна из методологий по управления проектами из семейства Agile.
Основные элементы Канбана:
Визуализация вашей работы:
Использование доски Kanban, на которой отображаются задачи в виде карточек, перемещающихся по колонкам доски, имеющие различные стадии/статусы (к примеру, "Todo", "In progress", "In QA", "In review", "Done").
Ограничение незавершенной работы(WIP):
Установка лимитов на количество задач(WIP лимитов), которые могут находиться в каждой колонке одновременно, чтобы предотвратить перегрузку команды и улучшить поток работы.
Постоянное улучшение:
Регулярный мониторинг и оптимизация процессов, использование метрик для оценки производительности, результатов и выявления узких мест, горлышек.
Давайте сравним Scrum и Kanban по различным атрибутам, чтобы знать основные отличия, между этими методами управления (помним, скрам — это фреймворк, а канбан — метод организации и управления задачами). Таблица ниже показывает разницу между Scrum и Kanban.
Разница между Скрамом и Канбаном: Памятка для менеджеров проектов
Давайте сравним Scrum и Kanban по различным атрибутам, чтобы знать основные отличия, между этими методами управления (помним, скрам — это фреймворк, а канбан — метод организации и управления задачами). Таблица ниже показывает разницу между Scrum и Kanban.
1. Work cycle
Scrum: Итерации. Scrum включает спринты, в течение которых команда следует циклу plan-do-check-act (PDCA).
Kanban: Continuous flow. В Канбан, как только одна задача завершается, команда сразу берется за следующую.
2. WIP - Work In Progress
Scrum: WIP лимиты устанавливаются командой Scrum для каждого спринта, и новая работа берется в работу только после завершения всех текущих задач.
Kanban: WIP лимиты в Канбан означает количество задач, которые могут одновременно находиться в одной колонке в течение заданного промежутка времени на конкретном этапе работы.
3. Inspect-Adapt (Empiricism)
Scrum: Каждый спринт — это возможность для инспекции и адаптации.
Kanban: Нет конкретного механизма для инспекции и адаптации. Работа движется в одном направлении.
4. Transparency (Empiricism)
Scrum: Артефакты в Scrum включают product backlog, sprint backlog и increment. Соответственно обеспечить прозрачность требований, реализации и результатов.
Kanban: Никаких специфических артефактов для прозрачности. Канбан-доска обеспечивает некоторую прозрачность. Многие команды используют бэклог продукта (из Scrum) в сочетании с досками канбана.
5. Planning
Scrum: Конкретный митинг для планирования спринта и дня — sprint planning и daily scrum.
Kanban: Нет четких указаний по планированию работы. Команды самостоятельно выбирают свой ритм и подход к планированию.
6. Responsibility/Structure
Scrum: Ответственность в Scrum - владелец продукта фокусируется на бизнесе, разработчики на реализации и Scrum мастер на устранении препятствий и имплементации Скрам. Вся работа выполняется кросс-функциональной командой.
Kanban: В канбане нет такого разбиения как в Скраме: владелец продукта, разработчики и т. д. Предполагается, что над задачами работает группа людей, они двигаются по флоу, пока не переходят в задачу со статусом done. И команда может быть не кросс-функциональной.
7. Stakeholder/Customer
Scrum: Скрам предполагает активное участие заинтересованных сторон и клиента — по крайней мере, один раз за спринт во время мероприятия sprint review(демо).
Kanban: Канбан не дает возможности привлечь заинтересованные стороны или клиентов. Некоторые команды применяют подход “обзора проделанной работы” раз в месяц.
8. Daily meetings
Scrum: Daily в скраме — это короткая ежедневная встреча команды, обычно длится 15 минут, на которой участники обсуждают, что они сделали, что планируют сделать и какие препятствия у них есть. Цель — координация работы и повышение прозрачности.
Kanban: Daily в канбане — стендап не является частью практик Канбана, но все равно можно проводить эту встречу. Стендап можно считать одним из способов реализации принципа improve continuously. Вопросы на них лучше задавать с фокусом на задачи.
9. Поток работы
Scrum: Скрам использует фиксированные временные рамки, называемые спринтами, которые обычно длятся от одной до четырех недель. Это позволяет командам "пушить" заранее запланированные задачи в рамках каждого спринта.
Kanban: Канбан основан на принципе "пул", что означает, что работа вытаскивается из очереди по мере необходимости. Это позволяет командам адаптироваться к изменяющимся требованиям и приоритетам, так как новая задача берется только тогда, когда есть свободный ресурс.
10. Метрики
Scrum: Основные метрики, которые применяются в скраме: Velocity (Скорость), Burndown Chart (График сгорания), Sprint Goal Achievement (Достижение цели спринта), Release Burndown.
Kanban: Основные метрики, которые применяются в канбане: Lead Time (Время производства), Cycle Time (Цикловое время), Throughput (Производительность), Work In Progress (WIP).
11. Оценка и приоритизация
Scrum: В Scrum оценка задач по их приоритету и сложности является обязательной, поскольку без этого невозможно организовать спринт и приступить к его реализации. Все задачи, которые не укладываются в рамки спринта, должны быть декомпозированы на подзадачи и взяты в сприн исходя из капасити.
Kanban: В Kanban-е оценка тасков не является обязательной, но может применяться в определенных случаях, особенно когда отсутствует соглашение о уровне обслуживания SLA.
12. Изменения в ходе работы
Scrum: Скрам изначально не приветствует изменения объема задач, включенных в спринт. Дело в том, что если мы определили цель для конкретного спринта и команда взяла на себя ответственность за ее достижение, то любые изменения в объеме работ могут подорвать все наши планы.
В таких случаях целесообразно завершить текущий спринт раньше срока и начать новый. Однако на практике это приводит к дополнительным затратам времени. Поэтому часто выделяется часть ресурсов команды на внеплановые задачи, что противоречит принципу Agile о "ранней поставке ценного ПО".
Kanban: В методологии Kanban всё гораздо проще — изменения могут быть внесены в любое время. Если бизнес решает, что необходимо срочно приступить к выполнению задачи, это не требует долгих процессов перепланировки (работу можно начать буквально через несколько минут). Однако здесь также существуют свои сложности, например, возможные блокировки задач, которые уже находятся в работе, и снижение производительности разработчика из-за необходимости переключаться на новую задачу. О том, как с этим справляться, я постараюсь рассказать отдельно.
13. Начала работ над тасками
Scrum: Скрам строится на основе спринтов, ограниченных во времени. Работа начинается только после того, как задачи будут расставлены по приоритету и оценены, проработаны ac, после чего они попадают в список спринта (Sprint Backlog). Обычно это происходит с регулярностью, соответствующей итерациям, что подразумевает ожидание включения конкретной задачи в ближайший спринт (хотя это не всегда происходит быстро).
Kanban: В Канбане нет таких ограничений, как в Скраме: задачи берутся сразу в работу по мере возможности или необходимости (например, когда кто-то завершает свою текущую задачу или возникает задача более высокого приоритета). Таким образом, разрыв между созданием задачи и началом работы над ней меньше, чем в Scrum.
14. Проведение демо
Scrum: Demo проводится в конце спринта и является частью Sprint Review. На этом митинге команда демонстрирует завершенные элементы работы (например, функционал, который был разработан за спринт) заинтересованным сторонам, включая владельца продукта. А также в получении ОС по проделанной работе.
Kanban: Формальные демо-сессии не являются обязательными в канбане, их проведение может быть полезным для улучшения коммуникации и сотрудничества в вашей команде.
Поэтому демо-сессии можно проводить, как на регулярной основе (например, раз в определенный период) или после завершения значительных задач.
Напоследок пару слов о СкрамБане
Скрам-бан — это гибридная методология, объединяющая элементы, как Scrum так и Kanban, которая предназначена для управления проектами и улучшения процессов разработки.
Основные характеристики Скрам-бан:
Гибкость: Скрам-бан сохраняет гибкость, позволяя командам вносить изменения в процессе работы, что особенно важно в динамичных условиях.
Визуализация: Использование визуальных инструментов, таких как доски и карточки, помогает командам отслеживать задачи и их прогресс.
Поток работ: Скрам-бан фокусируется на оптимизации потока работ, уменьшая время выполнения задач и повышая эффективность команды.
Непрерывное улучшение: Команды регулярно анализируют свои процессы и ищут способы их улучшения, что способствует росту и развитию.
Скрам-бан подходит для команд, которые хотят сохранить структурированный подход (как в Скрам), но при этом желают иметь гибкость и визуализацию рабочего процесса (как в Канбан) и командам что хотят перейти из скрама в канбан как промежуточный степ.
Напишите в комментариях, что вы чаще используете в своих проектах — Scrum или Kanban? Не забудьте также поставить лайк посту — это вдохновляет меня на написание новых материалов! Спасибо за вашу поддержку!
Показать полностью
3
Если к вечеру мозг уже не тянет: что изменилось в MindBooster после замены DMAE на холин и какой эффект я получил
Последние пару месяцев у меня повторяется один и тот же сценарий. Утром нормально включаешься, днём держишься, а к 15–16 часам мозг начинает «плыть». Сидишь за задачей, а концентрации уже нет, всё начинает тормозить. Кофе даёт час работы, потом откат и ещё хуже. Я решил заново проверить Майндбустер - у него обновили состав, прогнал курс и посмотрел, изменится ли что-то в реальной работе. Спойлер: разница есть.
Привет, на связи Саша, автор проекта RISE. Я разбираю исследования по ноотропам и параллельно тестирую их на себе в рабочих условиях, чтобы отделять рабочие решения от переоценённых.
Итак, в борьбе с тем, что я явно сдаю в половине рабочего дня, были перепробованы базовые вещи: сон, режим, кофе, перерывы. Это даёт эффект, но не закрывает главную печальную проблему - мозг устаёт быстрее, чем заканчивается рабочий день.
Впервые я тестировал MindBooster еще в 2021 году и с тех пор регулярно его использую для тяжелых рабочих периодов и лично рекомендую как готовый комплекс с отличным составом.
Сейчас у него поменяли состав — вместо DMAE добавили холин. Я решил снова прогнать курс (тем более опять наступил период дыма из ушей на работе) и посмотреть, есть ли разница в реальном эффекте.
Что именно поменяли и почему это важно
Итак, раньше в составе был DMAE. Это вещество используют как источник холина, из которого дальше синтезируется ацетилхолин. Вот так это выглядит:
Сейчас в составе сразу холин. То есть как видите, это более прямой путь: холин — это базовый компонент для синтеза ацетилхолина, нейромедиатора, который отвечает за память, внимание и передачу сигналов между нейронами. На практике это означает меньше потерь на промежуточных этапах и более стабильную работу.
Я не ожидал сильной разницы, но она оказалась заметной именно по ощущениям в течение дня.
Как это ощущается в работе
Я не ориентировался на субъективное «ну вроде лучше». Смотрел на конкретные вещи, а именно: скорость задач, концентрацию и состояние к вечеру. Трекал это в своем календаре после всех дел, чтобы потом посмотреть за весь период приема сразу. Вот что изменилось:
Включение стало спокойнее Утром есть энергия и желание работать, но нет перегруза. Состояние более собранное, чем раньше.
Проще держать длинные задачи. Самое заметное изменение. Когда нужно сидеть в одном контексте 2-3 часа, стало меньше желания переключаться на рилсики. Меньше внутреннего сопротивления. Сижу и пилю задачу реально.
Меньше провалов днём. Раньше после обеда был момент, когда приходилось себя буквально заставлять работать. Сейчас этот провал ощутимо сгладился.
К вечеру остаётся ресурс. Не возникает ощущения, что день уже закончился в 16:00. Есть силы закрыть задачи и нормально завершить день, пойти еще в тренажерку или другими активными делами заняться, а не упасть с ютубом на диван.
Память стала быстрее. Проще удерживать детали и быстрее собирать мысли в кучу. Особенно заметно в аналитике, когда надо активно думать и вникать в большой набор данных. Это совпадает с тем, как именно работает холин — он участвует в передаче сигналов между нейронами и поддерживает когнитивные функции .
Как устроен эффект внутри
У комплекса в целом осталась та же логика, просто один из ключевых элементов стал сильнее.
Быстрый эффект: кофеин + теанин дают включение. При этом теанин сглаживает стимуляцию, поэтому нет резких скачков.
Поддержка под нагрузкой: родиола и тирозин помогают держать стресс и не разваливаться, когда задач много.
Накопительный эффект: холин и бакопа работают на память и обучаемость. Это часть, которая раскрывается через 2-4 недели.
В итоге получается не разовый буст, а более стабильное состояние в течение всего курса.
Промо R153VH даст -10% на vivaherb.ru на все. На Майндбустер тоже действует
Кому это даёт максимум
По моему опыту, лучше всего это заходит в трёх сценариях:
— работа с большим объёмом информации
— обучение и прокачка навыков
— периоды высокой нагрузки и дедлайнов
Сразу скажу, если задачи простые и не требуют концентрации, эффект будет менее заметен. Этот инструмент раскрывается именно на сложной умственной работе.
Как я его использовал
Схема стандартная: 2 капсулы утром во время еды, курс месяц-два.
Я отдельно заметил, что важно сразу заходить в рабочие задачи после приёма. В этот момент проще поймать концентрацию и закрепить её. Если отвлечься на ленту или видео, то энергия уходит туда же.
У меня не было никаких побочных эффектов - сон не ломался, раздражительности не появилось. С прошлым вариантом Майндбустера было тоже все хорошо. Но важно учитывать: в составе есть кофеин - так что лучше принимать утром.
Вывод
Замена DMAE на холин оказалась не формальным обновлением, а реальным улучшением формулы. Эффект стал более стабильным: меньше скачков, лучше концентрация, больше ресурса к вечеру.
Для меня это решило главную проблему — не просто включиться в работу, а дожить до конца дня в нормальном состоянии и закрыть задачи, а не переносить их на завтра. Что-то я подустал после зимы, так что это был буквально глоток свежего воздуха.
Не стоит ждать супер резкий буст, скорее это история про способность стабильно и включенно работать весь день. Но вообще именно это даёт основной результат.
Я периодически разбираю свежие исследования и тестирую новые подходы на себе — в основном всё про продуктивность, энергию и как доживать до вечера, когда задач больше, чем часов в сутках.
Показать полностью
3
Зумеры уже стали вас нанимать на работу
Начитался рассказов как зумеры уходят с работы посредине дня и пишут "я не приду", или не выходят на работу, потому что рано вставать и ехать им далеко. Думаю , а нафиг вы их берете тогда, если вы не уверены в человеке? Ну и ладно, у всех свои причуды и финансы.
Сторитейл : Я в пассивном поиске работы, откликаюсь на 5-10 в день, но в айти это игра в долгую.
Я работаю уже почти 10 лет Менеджером клиентских проектов в финансовой сфере, или как сейчас модно говорить - Project manager.
Но к сожалению, как и достаточно много где - сфера начала стремительно загибаться уже как года 2, внешняя конкуренция стала жесточайшей, нового бизнеса стало в 1000 раз меньше, чем в 2022 году, гайки закручены донельзя по финансированию проектов.
Летом 25 года я решил координально сменить сферу. Думал на стройку, но образование не позволило быть там сразу управляющим.
Решено было получить доп. образование и уйти в Айти, в котором я шарю на уровне пользователя. Тем более ни глубоких знаний программирования, и в целом физмата там не требуется. Выбрал, понравилось, отучился.
Начал искать стартовые позиции, на набор боевого опыта. Нашел, отстажировался, но вакансия не подразумевала переход в штат.
Ищу дальше уже 2 недели.
Приходит 23.02, в выходной день, в 7 утра в телегу "нашла вас на сайте Охотник за головами, вот ссылка на нашу вакансию, очень хочу созвона".
Открыл, почитал, денежки указаны неплохие, есть над чем задуматься.
Но название должности "Бизнес ассистент/опер менеджер/проджект менеджер" создает желание спросить, что все таки ищет работодатель.
Функционал - от общения со стейкхолдерами, до "ты тень рук-ля, должен угадывать его желания". Думаю, ну ладно, может интересное предложение.
Назначили время, приготовился, за 5 минут, закрыл все дела, а ссылки нет и нет, сижу жду.
За 1 минуту до времени созвона кидает сайт и : "прошу ознакомиться до встречи".
Кликнул по ссылке - не открывается без впн, дальше не стал заходить. Сомнительно, все таки. Присылает ссылку, захожу.
Девушка, лет 20, неплохой внешности и приятной манерой подачи речи, начинает проверку связи, представляется, и просит включить запись.
Я - "Прошу прощения, давайте без записи".
Д - "Нет, запись обязательна, рук-ль отсматривает и выбирает с кем дальше собеседоваться".
Я - "Ок, но давайте тогда сперва вы расскажете про компанию, вакансию, условия, и тогда вы решите , я вам подхожу или нет, и включим запись - я вам очень подробно расскажу о своем опыте".
Далее начинается заученный рассказ о компании, которая к слову занимается не софт разработкой, как указано в описании, а это крипто обменник. Предвкушая, что оформление на ИП или самозанятость, оплата в крипте или в листочках с дерева, нет ни ДМС, ни техники, я понял что трачу время (опыт уже был в собесах ранее).
Я - "Татьяна, скажите, а вы прежде чем со мной встречаться, читали мое резюме? Я Менеджер проекта, ищу работу Проджект менеджером. У вас в описании прямые обязанности проджект менеджера, но плюс еще системного аналитика, прОдукт менеджера, личного помощника и т.д."
Д - "Давайте я включу запись, вы расскажете про опыт и мы поймем, что вы нам подходите или нет"
Я - "Вроде же обсудили про запись, давайте сначала обсудим мои вопросы..."
Я не успел закончить фразу, и тут иконка загрузки, и : "Организатор завершил конференцию"...
Захожу в ТГ, ни ответа ни привета, просто молчание.
Такое у меня в первый раз.
Показать полностью
Обоз
Генеральный директор нашей IT-компании, Соловейчик, сошел с ума по-своему. Он не стал бегать голым по офису и не купил остров в Тихом океане. Он съездил в Суздаль, выпил там медовухи и вернулся просветленным.
— Хватит, — сказал он, — низкопоклонства перед Западом. Мы русские люди. Какой еще, к лешему, «Скрам»? Какое «Велью»? С понедельника живем по правде.
Так в нашем опенспейсе наступило средневековье.
В понедельник мы собрались на PI-планирование. Теперь это называлось «Великий Сход». Атмосфера была тревожная. Программисты, люди по природе своей циничные и ленивые, жались к стенам.
В центр зала вышел наш Release Train Engineer, Аркадий. Раньше он носил худи с логотипом React, теперь на нем была льняная рубаха, правда, поверх джинсов. Глаза его горели нездоровым огнем.
— Братья! — возопил Аркадий. — Гой еси, мастеровые! Собрались мы ныне, дабы снарядить Обоз Поставки в путь долгий, на квартал грядущий!
Рядом со мной стоял Леха, наш тимлид. Леха — человек мрачный, его жизненная философия сводится к трем аксиомам: сервер упадет, заказчик идиот, а пиво должно быть холодным.
— Староста, — поправил я его шепотом. — Ты теперь не тимлид, а Староста Артели «Бэкенд».
— Я идиот, — буркнул Леха. — А Аркаша — Голова Обоза. Звучит как диагноз.
Началось все с «Оглашения Замысла». Вышли Попечители (бывшие стейкхолдеры) и полчаса рассказывали, как важно нам захватить рынок доставки собачьего корма. Потом слово взял Град-Зодчий (в девичестве — Enterprise Architect). Он развернул схему микросервисов, похожую на карту взятия Казани, и велел строить хоромы каменные, чтоб на века.
Нас разгнали по углам — на «Артельные Посиделки».
— Так, — сказал Леха, глядя в джиру. — У нас тут Затея висит. «Интеграция с платежным шлюзом». Как оценивать будем?
— В стори-поинтах нельзя, — напомнил я. — Соловейчик велел в Вершках. Или в Пядях.
— Хорошо, — Леха почесал затылок. — Тут работы много. API кривое, документации нет. Потянет на семь пядей во лбу.
— Много, — возразил тестировщик Гриша. — Не сдюжим. У нас Тяга слабая, половина артели в отпусках.
— Ладно, пиши пять вершков. И пусть Господь управит.
Самое страшное началось у Доски Пути. Это была огромная пробка на стене, вся опутанная красными нитками. Аркадий бегал вдоль нее, спотыкаясь о провода, и кричал:
— Чьи Путы?! Кто кого держит? Почему Артель «Фронтенд» не может начать верстать кнопку?
— Дык, — отозвался с галерки фронтендер, — мы ждем, пока бэкендеры базу окучат.
— Путы! — трагически воскликнул Голова Обоза. — Тугие, окаянные путы! Староста Леха, пошто задерживаешь братьев своих?
Леха молчал. Ему хотелось курить и, возможно, убить Аркадия.
К вечеру перешли к «Укрощению Лиха». Это был ритуал ROAM, только с национальным колоритом.
— Лихо первое! — зачитывал Аркадий. — «Сервер падает при нагрузке в тысячу юзеров». Кто возьмет на душу?
— Я возьму, — вздохнул Град-Зодчий. — Буду Опекуном сего Лиха.
— Добро! Лихо второе! «Дизайнер уходит в декрет».
— Тут мы бессильны, — сказали из зала.
— Значит, — Аркадий развел руками, — на все воля Божья. Принимаем как есть. Accepted. То есть, тьфу, «Смирение».
В финале было голосование. «Пятерня Веры». Нужно было поднять руку и показать пальцами, верим ли мы в успех нашего безнадежного Обоза.
Я посмотрел на Леху. Леха смотрел в пол. Он знал, что API не заработает, что сроки сгорят, а Соловейчик через месяц передумает и увлечется буддизмом. Леха хотел показать один палец. Возможно, средний.
Но он был Старостой. У него была ипотека и двое детей.
— Голосуем! — взревел Голова Обоза.
В воздух взмыли десятки рук. Все показывали открытую ладонь. Пять перстов. Полная вера. Зуб даем, всё исполним.
— Любо! — прослезился Аркадий. — Сдюжим, православные! Трогай Обоз!
Мы вышли на улицу курить. Шел мокрый снег. Москва стояла в пробках, гудела, жила своей бестолковой жизнью.
— Пять вершков, — задумчиво сказал Леха, глядя на огонек сигареты. — А ведь не сдюжим.
— Не сдюжим, — согласился я. — Зато как звучит! Не факап, а «Лихо». Не баг, а «Испытание». Чувствуешь величие?
— Чувствую, — сказал он. — Пойдем, Радетель. Нам еще код писать. Или, как теперь говорят, бересту марать.
И мы пошли обратно, в нашу избу из стекла и бетона, ковать цифровое счастье для неведомых Попечителей.
Толковый словарь урядства и благочиния в разработке программных изделий
Раздел I. О Людях и Чинах
Agile Team — Артель.
Боевая единица производства. Группа людей, объединенных общей бедой и сроками. Живут в одной избе (или чате), делят радости и баги.
Scrum Master — Староста.
Человек, который не пашет, не сеет, а только спрашивает: «Что ты делал вчера, мил человек, и что будешь делать сегодня?». Следит, чтобы в Артели не пили медовуху до релиза.
Product Owner — Радетель (Хозяин изделия).
Человек с горящими глазами и списком требований, от которых у Мастеровых стынет кровь. Верит, что если очень захотеть, то можно построить терем за три дня.
Release Train Engineer (RTE) — Голова Обоза.
Главный погонщик. Человек с самым громким голосом и самыми расшатанными нервами. Отвечает за то, чтобы все телеги ехали в одну сторону, даже если лошади сдохли.
System Architect — Главный Зодчий.
Старец, рисующий на бересте красивые схемы, которые невозможно воплотить в жизнь. Живет в башне из слоновой кости (или в отдельном кабинете).
Developers — Мастеровые.
Трудовая кость. Люди, которые своими руками превращают безумные фантазии Радетелей в работающий (иногда) код.
Раздел II. О Деяниях и Обрядах
PI Planning — Великий Сход.
Двухдневное гулянье, переходящее в панику. Время, когда все обещают друг другу невозможное, зная, что не сдержат слова.
Team Breakouts — Артельные Посиделки.
Время, когда Мастеровые запираются в углах и пытаются понять, как впихнуть невпихуемое в отведенные сроки.
Confidence Vote — Пятерня Веры (Рукоприкладство).
Обряд всеобщего поручительства. Поднятая рука с пятью пальцами означает: «Зуб даю, сделаем». Один палец (особенно средний) показывать не рекомендуется во избежание гнева Попечителей.
ROAM — Укрощение Лиха.
Ритуал заговаривания проблем. Делится на четыре вида заклинаний:
Избыто (R) — проблему решили (спрятали под ковер).
Взято на душу (O) — нашли крайнего.
На всё воля Божья (A) — смирились с неизбежным крахом.
Соломка подстелена (M) — придумали оправдание заранее.
Раздел III. О Мерах и Вещах
Feature — Затея.
Крупная хотелка Попечителей. Обычно формулируется как «Хочу, чтоб было красиво и само работало».
User Story — Поделка.
Малый кусок работы. То, что реально можно выстругать за пару дней, если не отвлекаться на перекуры.
Story Points — Вершки (или Пяди).
Мера сложности, понятная только самим Мастеровым. Один вершок — работа легкая. Восемь вершков — без пол-литры не разобраться.
Dependency — Путы.
То, что мешает жить. Красные нити на Скрижали Пути, символизирующие, что одна Артель ждет, пока другая перестанет лениться.
Capacity — Тяга.
Сила лошадиная. Способность Артели тащить воз. Обычно переоценивается в два раза в начале пути и недооценивается в конце.
Program Board — Скрижаль Пути.
Доска позора и надежды. На ней видно, кто работает, а кто создает Путы.
Другие подобные рассказы можно прочитать тут https://dovlatov-ai.web.app/
Показать полностью
Разница распределения стоимости в строительстве, машиностроении и программировании — основа для внедрения итераций
Очень часто, когда обсуждают подходы к проектированию и проектному управлению проводят аналогии со строительством или машиностроением. Не стала исключением и моя статья про аджайл https://pikabu.ru/story/mifyi_i_realnost_est_li_osnovanie_protivopostavlyat_agile_i_waterfall_13485192
Конечно всякие аналогии имеют свои границы применимости, но в случае сравнения строительства и разработки ПО об этой границе забывают. Между тем она есть и даже люди далекие и от первого и от второго быстро поймут эту разницу, если просто о ней написать.
Основная разница заключается в сравнении стоимости проектирования и создания итогового продукта. Для сравнения я также решил привести пример из машиностроения с созданием серийного продукта. Имеются фундаментальные различия экономических моделей этих отраслей в аспекте тиражирования решений и распределения стоимости по этапам жизненного цикла.
Для подкрепления мнения некими данными я попросил нейросеть Qwen набросать примерные оценки по стоимости.
Стоимостная характеристика трех отраслей: строительство, машиностроение, разработка ПО.
Строительство: много материальных затрат на этапе производства
В строительстве классическое распределение затрат выглядит так:
Проектирование: 5-10% от общей стоимости
Материалы: 50-60%
Строительно-монтажные работы: 30-40%
Пуско-наладка и сдача: 5-10%
Физическая реальность создает "точку невозврата". После заливки фундамента изменить его параметры практически невозможно без полного демонтажа. Каждый этап жестко зависит от предыдущего, и ошибка на ранней стадии многократно усиливается на последующих. Тиражирование в строительстве означает создание типовых проектов, но даже при этом каждый объект уникален из-за особенностей грунта, климатических условий и инфраструктуры.
Машиностроение: баланс между разработкой и производством
Машиностроение занимает промежуточное положение:
НИОКР и проектирование: 20-30%
Создание прототипов и испытания: 15-25%
Освоение производства (оснастка, станки, линии): 30-40%
Серийное производство: 10-20% на единицу продукции
Здесь ключевой момент — амортизация разработки на количество единиц продукции. Чем больше тираж, тем ниже себестоимость единицы. Но первоначальные затраты на разработку и освоение производства огромны. Изменения после запуска серийного производства чрезвычайно затратны — часто проще разработать новую модель, чем модифицировать существующую линию.
IT-разработка: "бесплатное" тиражирование
В IT-разработке принципиально иное распределение:
Проектирование и анализ: 30-40%
Разработка: 40-50%
Тестирование и внедрение: 20-30%
Поддержка и развитие: 15-25% годовых от стоимости разработки
Самая революционная особенность IT — практически нулевая стоимость тиражирования. Разработка программного продукта может стоить миллион долларов, но выпуск миллиона копий обойдется в несколько рублей за штуку. Это создает уникальную экономическую модель, где можно позволить себе эксперименты и итерации.
Почему в IT можно начинать с весьма "сырого" продукта?
В машиностроении нельзя создать мотоцикл, а потом превратить его в автомобиль. Для этого потребуется полностью перепроектировать платформу, перенастроить производственные линии, переобучить персонал. Стоимость такой "эволюции" будет сравнима со стоимостью разработки нового автомобиля с нуля.
В строительстве аналогичная ситуация. Фундамент гаража не выдержит нагрузки от многоэтажного дома. Стены сарая не станут несущими для башни. Физические законы не обойти.
Но в IT физических ограничений нет. Вы можете начать с простого веб-сайта-одностраничника, добавить базу данных и админку (MVP), интегрировать платежные системы и мобильное приложение (первая версия приложения), а затем создать распределенную облачную платформу с искусственным интеллектом. Каждый этап строится на предыдущем, но при необходимости можно переписывать отдельные компоненты полностью без полного перезапуска проекта.
Это возможно благодаря:
Нулевой стоимости копирования - можно создать сотню экспериментальных версий без финансовых потерь
Модульной архитектуре - компоненты можно заменять независимо друг от друга
Быстрому циклу обратной связи - пользователи тестируют изменения в реальном времени
Стоимостные риски и их управление
Строительство: страхование через детализацию
В строительстве основной риск — физическая невозможность или чрезвычайная стоимость исправления ошибок. Поэтому:
80-90% рисков управляются на этапе проектирования
Используются детальные 3D-модели и BIM-технологии
Предусматриваются запасы прочности в конструкциях
Стоимость изменений после начала строительства кратно превышает стоимость проектирования
Кстати этап проектирования в строительстве сильно перекликается с разработкой ПО. На этом этапе можно всё менять и переделывать, при этом мы всё еще будем нести финансовые затраты гораздо меньше, чем сама стоимость строительства и стоимость отдельных изменений на этапе строительства.
Конечно в строительстве есть примеры возведения серийных домов (хрущевки, панельки) с удешевлением производства, но в данном случае удешевление было не за счет единого проекта, а за счет использования типовых решений, которые можно изготавливать серийно, как и продукцию машиностроения.
Машиностроение: управление через прототипирование
В машиностроении риски распределены между разработкой и производством:
Создаются физические прототипы для проверки концепций
Проводятся ресурсные испытания в экстремальных условиях
Используются CAD/CAM системы для виртуального моделирования
Освоение производства идет поэтапно с постоянной доработкой
Стоимость ошибки, которая выявится после запуска серийного производства может достигать миллионов за простой и переналадку линии, поэтому инвестиции в тестирование и прототипирование оправданы. И бывает очень сложно вносить изменения в готовый продукт серийного производства, потому что изменения могут привести к необходимости полной переделке производственных циклов, а это уже затраты, сопоставимые с разработкой продукта с нуля.
Разработка ПО: управление через итерации
В программировании и разработке ПО риски управляются иначе:
Риск несоответствия требованиям минимизируется через постоянную обратную связь
Технические риски снижаются через рефакторинг и технический долг
Рыночные риски управляются через A/B тестирование и постепенный rollout
Безопасность обеспечивается через непрерывное тестирование и обновления
Стоимость ошибки в IT относительно невысока - можно быстро выпустить горячий фикс или откатиться к предыдущей версии. Это позволяет брать на себя больше рыночных рисков в обмен на возможность быстрого тестирования идей. При этом стоимость подробного проектирования будет не ниже, чем сама разработка, а в некоторых случаях без какого-то прототипа очень сложно определиться с треком дальнейшего развития.
Распределение стоимости по этапам
Практические примеры от нейросети Qwen
Строительство: Burj Khalifa
Стоимость проектирования составила около $100 млн из общего бюджета $1.5 млрд. Изменения в процессе строительства были минимальны — любое отклонение от проекта могло привести к катастрофе. Тиражирование невозможно — это уникальный объект.
Машиностроение: Tesla Model 3
Разработка и освоение производства обошлись в $2+ млрд. Но при производстве 500,000 автомобилей в год себестоимость единицы становится конкурентоспособной. Изменения в процессе производства требуют остановки линий и перенастройки оборудования.
IT разработка: Facebook
Начинался как простой сайт для студентов Гарварда. Стоимость тиражирования для миллиарда пользователей — доли цента на пользователя в месяц. Изменения вносятся ежедневно без остановки сервиса. Первоначальная разработка стоила тысяч долларов, текущая стоимость компании — сотни миллиардов.
Почему аналогии вредны в проектном управлении и как найти баланс
Следовательно сравнение разработки ПО со строительством некорректно именно из-за разного распределения затрат. Поэтому проектное управление в разработке ПО просто обязано опираться прежде всего на итерации и сбор обратной связи, а не на исходное ТЗ и проектные документы.
практические советы для IT проектов:
Архитектурный фундамент - закладывайте понятную архитектуру с возможностью масштабирования, но не надо сразу ударяться в создание микросервисов и прочие архитектурные излишества https://t.me/limsaccreditation/1857
Итеративное наполнение - добавляйте функции постепенно, получая обратную связь на каждом этапе. Первоначальный план при этом будет постоянно меняться, адаптироваться. Концентрируйтесь на важных и востребованных функциях.
Управление техническим долгом - регулярный рефакторинг - это инвестиция в будущую гибкость. При этом надо пересматривать не только код, но и документацию продукта.
Бесплатное тиражирование - используйте преимущество нулевой стоимости копирования для быстрого тестирования гипотез и масштабирования успешных решений.
Вывод
Итерации и необходимость обратной связи в it сфере обусловлены фундаментальными причинами, связанными со стоимостью этапов проектирования и разработки. Без итеративного подхода можно впустую прожигать бюджет на никому не нужное проектирование и дальнейшую разработку продукта, которым никто не будет пользоваться.
Как написали в комментариях к мой предыдущей статье, сам Уинстон Ройс — автор термина Waterfall — в той самой статье 1970 года описывал недостатки каскадной модели, предлагая заменить их итеративной моделью. Таким образом дело не в Agile и настроениях разработчиков, итерации - это самая эффективная модель разработки с экономической точки зрения.
Показать полностью
1