Декомпозуй це: розкладаємо великі та складні задачі на компоненти

Categories: Work-lifeAutomotiveCommunicationsConsumer and RetailFinancial ServicesHealthcareManufacturing and IndustrialMediaTechnology

Автори:  Андрій Сидор, Senior Consultant, Quality Assurance, GlobalLogic Ukraine

Андріан Яблонський, Senior Consultant, Engineering, GlobalLogic Ukraine

Будь-яка велика задача складається з маленьких. Її можна розкласти на компоненти - це називається декомпозиція.

Як декомпозувати складні задачі? Як максимально точно оцінювати великі (і не дуже) проєкти? Які техніки є ефективні, а яких краще не використовувати? Про це та більше - розкажемо у цій колонці.

Декомпозиція

Велика система чи продукт - це завжди комплекс, де користувач бачить лише верхівку. Левова частка роботи розробників, тестувальників, аналітиків, залишається поза увагою кінцевих юзерів. Тому, при декомпозиції проєктів, завжди беріть до уваги високорівневі цілі, які потрібні саме кінцевому користувачу та замовнику:

  • Щоб продукт був красивий
  • Щоб швидко працював
  • Щоб не мав помилок

Правила декомпозиції: практичні поради

Ми виділили кілька важливих порад, які допоможуть декомпозувати задачі правильно:

  • Кожен раз, коли ви декомпозуєте свою задачу, ми рекомендуємо керуватися ROI, тобто тою цінністю, яку ви принесете замовнику. Пам'ятайте, що задача міряється в грошах, у часі та результаті.

  • Демонструйте результат роботи над задачею кожного дня. Це допоможе вам легко та чітко зрозуміти, що ви зробили за певний інтервал часу. Ви можете підготувати звіт та продемонструвати який новий чи додатковий функціонал був успішно реалізований за цей час. Таким чином, ваш проєкт стає проєктом driven by value, де ви дійсно створюєте цінність щодня. Це потрібно робити з самого початку: від компонентів, по вертикальній декомпозиції до кожного user story.

  • Радимо робити user story на один день, а не на 81519 story points, які будуть на весь спринт.

  • Задачі, в ідеалі, мають бути тривалістю не більше двох годин. Рекомендуємо спробувати налаштувати таймер на кожні дві години та записувати що вам вдалося за цей час зробити. Це допоможе чіткіше розуміти на що ви витрачаєте час, та навчитися точніше оцінювати термін виконання того чи іншого завдання.

  • Робіть перерви на 10-15 хвилин після двогодинного штурму задачі, аби дати можливість собі відпочити та проструктурувати інформацію в голові. Це допоможе завершити задачу швидше та ефективніше.

  • Беріться за складні задачі зранку, коли мозок свіжий. Але знову ж таки, не більше двох годин. Якщо у вас задача потребує понад дві години для вирішення, розкладіть її на кілька днів, але йдіть маленькими кроками.

  • Пам'ятайте про "Принцип Парето": 20% зусиль - це 80% результату. Не намагайтесь створити ідеальну систему, яка розв'яже усі проблеми світу. Зробіть те, що треба зробити сьогодні, те, що від вас вимагається перш за все.

  • Вічно оцінювати та розставляти пріоритети не можна. Створіть roadmap на 2-3 кола, не більше.

  • Будь-які проєкти закінчуються. Оце ваш час для презентації власних ідей та рекомендацій.

  • Розклали велике завдання на підзадачі? Добре. Але не залишайте їх "на потім", бо вони мають властивість зростати, як снігова куля. Радимо відразу виконати, отримати зворотний зв’язок, та рухатися далі.

Постановка цілей та шляхи їх реалізації

Це була теорія, а тепер - до практики. Техніка, яку ми рекомендуємо використовувати, може бути застосована у будь-яких випадках життя. Тож, розглянемо шлях до реалізації цілей на прикладі простого бажання - купити авто марки Mercedes.

Звісно, автомобілі цього бренду є різні, тому спершу вам потрібно чітко зрозуміти, про яке саме авто ви мрієте. Те, про що ми казали вище - розділіть ціль на дрібніші кроки та проходьте їх по черзі.

Аби потренуватися у цій техніці, ви можете виписати всі свої мрії, далі проаналізувати їх використовуючи SMART техніку, та перетворити їх у цілі.

Хвилинка психології. Після аналізу ви, можливо, побачите, що ваші мрії, навіть давні, не перетворились у цілі. Чому так? Коли ми починаємо щось планувати, то розуміємо, що шлях буде досить довгий та складний. Тому нам простіше відмовитись від мрії, а натомість сфокусуватись на тому, що ми дійсно хочемо. Саме тому важливо всім цілям дати пріоритети та дедлайни. Це допоможе  ефективно планувати дії та розподіляти ресурси.

А тепер наведемо приклад, як досягти поставлену ціль.

Уявімо, що вам потрібно зробити тестування певного iOS застосунку. Для цього вам потрібно зібрати білд додатку, інсталювати його, провести активні дії та отримати логи результату.

Під час цього процесу варто не забувати, що ваше рішення повинне легко розширюватися та масштабуватися. Рішення, яке легко розвертається - дуже привабливе, і відповідно відкриває нові можливості для замовника.

Ось як це тестування ми розклали по пунктах на картинках нижче:

Техніки оцінювання

Є різні підходи та техніки оцінки, проте, основним фокусом є не забувати те, що ви робили. Типовою помилкою менеджерів, лідів та розробників є те, що вони достатньо оптимістичні у своїх прогнозах, та погоджуються на ті терміни, які не є реалістичними.

Наступне, що приводить до недооцінювання, це залучення до команди людей тоді, коли ви вже не встигаєте довести проєкт до кінця. Є закон Брукса, в якому чітко сказано, що якщо проєкт не вкладається у терміни, то залучення нових людей затримає виконання проєкту на ще довший термін. Нових людей потрібно навчити, а часу на менторінг зазвичай потрібно дуже багато.

Тому на різних стадіях задач потрібно використовувати різні підходи.

Top-Down

Досить проста техніка. Декомпозиція зверху-вниз. Ідея цієї техніки полягає у тому, щоби встановити бюджет проєкту і подальший розподіл його між різними етапами або завданнями. Тобто, ця техніка дозволяє чітко зрозуміти скільки грошей замовник готовий витратити на свій проєкт чи на якусь конкретну активність. Далі, знаючи які типові активності у нас можуть бути для певного типу задач, ми ділимо цей бюджет - на тестування, розробку, дослідження.

Недолік естімейту такого типу - це його неточність, а бюджет виділяється на основі грубих припущень. Тому тут є дуже важливим робити просту оцінку, показувати deliverables, ставити додаткові запитання, і якщо є додаткові зміни від замовника, які не були узгоджені спочатку, оформлювати їх як change request.

Analogous

У порівнянні з попередньою технікою, ця є більш точною. Її можна використовувати коли ми вже робимо певні схожі проєкти й, коли з’являється новий замовник чи заходить новий проєкт, ми маємо можливість знайти аналогічні проєкти.
Слайд 45.00

Three Point

У цій техніці використовується розбиття задач на менші підзадачі. Далі менеджер з командою оцінюють ці задачі та визначають можливі ризики. На основі цього, отримують три оцінки - песимістичні, реалістичні, та оптимістичні. Є різні формули, як вирахувати середнє значення, яке варто застосовувати при оцінці потрібного вам бюджету.

Найпростіша формула - це додати всі три оцінки та поділити на три - (П+Р+О)/3. Точнішою формулою ж вважається оцінка, коли ми реалістичну оцінку множимо на 4, додаємо песимістичну та оптимістичну оцінки та ділимо на шість - (П+Р*4+О)/6.

Bottom up

Одна з технік, яка дає найкращий результат з точки зору оцінки, але є досить складною у застосуванні та є досить часозатратною. Якщо ви абсолютно чітко розумієте, які задачі вам варто виконати, ви їх неодноразово виконували і маєте статистику зібрану впродовж кількох років, то відповідно ви знизу до верху описуєте всі задачі та складаєте бюджет.

На цьому ми завершимо нашу розповідь про декомпозицію та методики оцінки. Сподіваємось, наші поради стануть вам у пригоді!

Top Insights

Python: чому вивчати та з чого почати?

Python: чому вивчати та з чого почати?

InsightsSoftwareAutomotiveCommunicationsConsumer and RetailFinancial ServicesHealthcareManufacturing and IndustrialMediaTechnology
Тонкощі CV або Як скласти та куди надіслати, щоб отримати пропозицію мрії про співпрацю

Тонкощі CV або Як скласти та куди надіслати,...

HRAutomotiveCommunicationsConsumer and RetailFinancial ServicesHealthcareManufacturing and IndustrialMediaTechnology
CI/CD для JS розробників. Частина перша – теорія

CI/CD для JS розробників. Частина перша – теорія

DevelopmentSoftwareAutomotiveCommunicationsConsumer and RetailFinancial ServicesHealthcareManufacturing and IndustrialMediaTechnology
Soft and Hard Skills: Що важливіше? Розповідь одного рекрутера

Soft and Hard Skills: Що важливіше? Розповідь одного...

HRAutomotiveCommunicationsConsumer and RetailFinancial ServicesHealthcareManufacturing and IndustrialMediaTechnology

ТОП автори

Oleh Moroz

Oleh Moroz

Test Engineer, Quality Assurance, GlobalLogic

Volodymyr Nos

Volodymyr Nos

Lead Software Engineer, Engineering, GlobalLogic

Mariia Krapyvka

Mariia Krapyvka

Specialist, GlobalLogic

Maryna Sergiyenko

Maryna Sergiyenko

Associate Manager, Engineering, GlobalLogic

Yaroslav Pushko

Yaroslav Pushko

Lead Software Engineer, Engineering, GlobalLogic

Категорії блогів

  • URL copied!