#1 Всем привет!

Начинаю вести свой Телеграмм канал, перешагнув 40-летний рубеж. Вся моя карьера — это более 20 лет в ИТ. На старте я попробовал себя в разных ролях: был не самым лучшим программистом, чуть лучше системным аналитиком, но в итоге стал продвинутым бизнес-аналитиком. Всегда выделялся организаторскими способностями и коммуникативными навыками, что позволило мне через 2 года стать руководителем проектов.
Сейчас меня интересует организация ИТ-процессов и управление проектами с использованием гибких методик, создание эффективных команд, а также все, что связано с персональной эффективностью и удовлетворенностью жизнью.

👨‍💻Зачем мне этот канал?

❇️ Во-первых, это отличный способ переосмыслить накопленный опыт и поделиться своими выводами: как оказалось, для кого-то они уже стали полезными.
❇️ Во-вторых, научиться чему-то новому. Однажды мне довелось целый год читать студентам лекции по теме «Современные информационные технологии». Готовясь к еженедельным лекциям и принимая лабораторные работы, я узнал гораздо больше, чем в то время, когда находился в роли студента.

🏃🏃‍♂️🏊🎨🎬Не только про ИТ.

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

#Знакомство

Вредные советы по декомпозиции задач, навеяно общением с командами.

🤡 Делайте задачи как можно крупнее!
Что бы их было видно издалека и все заинтересованные лица понимали над какой важной и большой проблемой вы работаете! А еще так будет проще оправдать сроки и объяснить, почему заказчик увидит свою фичу только через год!

😈 Не утруждайте себя и команду определением критериев завершения задач!
Пусть каждый решает сам, когда задача выполнена и ее можно закрывать!

💩 Размазывайте функционал по нескольким задачам! Собирать пазлы - это так интересно, особенно, если потом оказывается, что в наборе смешаны детали от разных картинок, а самих деталей не хватает.

👻 Описывайте задачи как можно более общими словами!
Зачем команде знать все детали? Даешь свободу творчеству! К тому же это посодействует развитию творческой мысли заказчика! Когда придет время презентовать результаты, заказчик с превеликим удовольствием расскажет команде, как на самом деле должен работать этот функционал.

🧙Нужно распределить задачи?
Брось кубик и пусть воля случая сведет джуна разработчика и задачу по рефакторингу критически важного отчета для CEO.

🤷‍♂️ Все задачи одинаково важны!
Задача, блокирующая сдачу финансовой отчетности должна томиться в общей очереди, мы делаем задачи строго по порядку. Первый пришел - первый ушел!

🐝 Не связывайте задачи с бизнес-целями!
Пусть команда работает над чем угодно, главное – чтобы все были заняты!

P.S. Список не конечный, есть чем дополнить?

#ЭффективныеКоманды

Пятничное, отпускное…🚅Каждый раз, оказываясь в аэропорту или на вокзале, я ощущаю волнующее предвкушение приключений. Эти места словно ворота в новые миры, полные возможностей и неожиданностей. Вспоминаю начало фильма «Love Actually», где в зоне прилета царит особая магия: объятия, слезы радости, искренние улыбки. Это пространство наполнено историями. Ну а я отправляюсь на встречу очередным приключениям!

Продолжим говорить о декомпозиции задач.

💻 Правила декомпозиции задач команде лучше определить на старте работ. Многие ли делают это осознанно? На моей практике это единицы, которым повезло с лидером/менеджером, они работают в достаточно зрелой или формализованной компании. В иерархии декомпозиции есть уровень, который команда для себя считает условно базовым - это задачи которые реализуются в рамках спринта или движутся по канбан-доске. Как понять, что гранулярность на этом уровне оптимальна?

Для этого можно использовать методику «INVEST»
Каждая буква - традиционно представляет из себя критерий оценки задачи (перевод критериев вольный и адаптирован с учетом опыта использования методики):

❇️ Independent (Независимая): Задача должна быть максимально автономной и в идеале не зависеть от других задач.

❇️ Negotiable (Договариваемая): В прямом переводе использование данного критерия может быть затруднительно. Этот пункт про то, что на вход команде должны поступать «проблемы» для которых команда вырабатывает варианты решений. Таким образом получается, что «история» - решение одной проблемы потенциального пользователя.

❇️ Valuable (Ценная): Задача должна приносить конкретную ценность пользователю или продукту. Это помогает приоритизировать задачи, ориентируясь на наибольшую выгоду. Стоит помнить, что «ценность» - не единственный критерий, используемый в приоритезации задач.

❇️ Estimable (Оцениваемая): Задача должна быть достаточно понятной, чтобы её можно было оценить. Это важно для планирования и распределения ресурсов.

❇️ Small (Небольшая): Задача должна быть достаточно маленькой, её желательно выполнить в рамках одного спринта.

❇️ Testable (Тестируемая): Задача должна быть такой, чтобы можно было проверить её выполнение через тестирование. Это означает, что должны быть чёткие критерии приемки.

Как использовать технику? 🎬 Расскажу в следующей серии.

#ЭффективныеКоманды

Структура декомпозиции, когда и где пользоваться методикой «INVEST»?

Определение структуры декомпозиции задач в проекте/продукте — творческая задача, требующая системного взгляда и анализа типов проводимых работ. Посмотрим, как может выглядеть структура задач (я буду дублировать каждый уровень примерами возможных объектов из Jira):

Уровень 1️⃣: Крупные задачи (Epic в Jira). Начнем с определения крупных задач, которые представляют основные функциональные элементы проекта. Пример требования: «Система должна обеспечивать хранение и управление данными по клиентам компании» преобразуется в Эпик, например: «Хранение и управление данными по клиентам».

Уровень 2️⃣: Функциональные элементы разбиваем на более понятные задачи — фичи (Features в Jira). Для нашего Эпика это может быть: «Ведение карточки клиента в CRM».

Уровень 3️⃣: Уровень: Разбиваем крупные задачи на пользовательские истории (User Stories или Task в Jira). Именно на этом уровне начинаем проверять задачи по методике INVEST. В качестве примера можно привести пользовательскую историю: «Я, как менеджер по продажам, хочу сохранить в системе информацию о новом клиенте». Задачи этого уровня могут быть продемонстрированы заинтересованным сторонам.

Уровень 4️⃣: Определяем необходимые действия для реализации каждой истории (Subtask в Jira). В зависимости от проекта, для реализации одной истории может потребоваться несколько экспертиз и бывают ситуации, когда эти задачи могут решаться параллельно. В этих случаях очень полезно заводить задачи для каждой экспертизы. Например: «Разработать дизайн карточки», «Сверстать карточку», «Разработать тест-кейсы» и т.д.

🟢 Приведенный пример грешит своей абстрактностью и, возможно, перегружен. В реальном проекте нужно учитывать особенности стека технологий и процессы, используемые в команде. Очень часто уровень 2 и 3 объединяют и оставляют только пользовательские истории или фичи. А уровень 4 вообще можно опустить, если команда договорилась декомпозировать задачи таким образом, что в один момент времени над задачей может работать только один человек.

💬 На первых этапах применения «INVEST» рекомендую пройтись по актуальным задачам проекта, используя методику как сито и, таким образом, оценить, насколько эффективно сейчас выстроена система декомпозиции в команде. Со временем применение критериев войдет в привычку и вы будете делать это неосознанно.

#ЭффективныеКоманды