-
-
-
-
URL copied!
Автори: Андрій Сидор, 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: чому вивчати та з чого почати?
InsightsSoftwareAutomotiveCommunicationsConsumer and RetailFinancial ServicesHealthcareManufacturing and IndustrialMediaTechnologyТонкощі CV або Як скласти та куди надіслати,...
HRAutomotiveCommunicationsConsumer and RetailFinancial ServicesHealthcareManufacturing and IndustrialMediaTechnologyCI/CD для JS розробників. Частина перша – теорія
DevelopmentSoftwareAutomotiveCommunicationsConsumer and RetailFinancial ServicesHealthcareManufacturing and IndustrialMediaTechnologySoft and Hard Skills: Що важливіше? Розповідь одного...
HRAutomotiveCommunicationsConsumer and RetailFinancial ServicesHealthcareManufacturing and IndustrialMediaTechnologyТОП автори
Категорії блогів
Давайте співпрацювати
Схожі теми
Як зберігати і підвищувати власну продуктивність в ІТ
Артур Мицко, Lead Software Engineer, GlobalLogic У компанії Globallogic я пройшов шлях від С++ trainee до Lead Software Engineer. Як зазвичай буває, коли людина приходить в ІТ-компанію вперше — все навколо нове та цікаве, ти не помічаєш як летить час. Чесно кажучи, в перші роки я не сильно то і відпочивав, переважно на свята. Це, … Continue reading Декомпозуй це: розкладаємо великі та складні задачі на компоненти →
Більше
Як покращити ресурсний стан через оточення
Катерина Васильєва, Senior HRBP, GlobalLogic Ресурсний стан як поняття, яке використовується в психології, медицині, спорті та інших галузях, описує психофізіологічний стан людини, який характеризується рівнем її енергії, витривалості, здатності до праці та концентрації уваги. Відповідно, ресурсний стан впливає на різні аспекти життя людини, і визначається різними чинниками, як то рівень фізичного здоров'я, ступінь стресу або … Continue reading Декомпозуй це: розкладаємо великі та складні задачі на компоненти →
Більше
Як стати .NET розробником. Перші кроки та поради
Олексій Глембицький, Senior Software Engineer, GlobalLogic Мене звати Глембицький Олексій, я .NET розробник в компанії GlobalLogic, а також проводжу вебінари та викладаю курси по мові програмування С#. І в цій статті я би хотів поділитись порадами, які допомагають моїм студентам опанувати мову програмування С# та стати .NET-розробниками. Про мову програмування C# та платформу .NET C# … Continue reading Декомпозуй це: розкладаємо великі та складні задачі на компоненти →
Більше
Як покращити презентації
Денис Братчук, Engineering Director, GlobalLogic Майже кожен з нас час від часу виступає із презентаціями чи доповідями, використовуючи як ілюстрацію слайди, створені в популярних офісних програмах, на кшталт PowerPoint або Google Slides. Менеджери проєктів створюють звіти про хід виконаних робіт, інженери презентують новітні технологічні рішення, керівництво звітує про досягнення фінансових цілей, а менеджери з продажів … Continue reading Декомпозуй це: розкладаємо великі та складні задачі на компоненти →
Більше
Від студента до Trainee-спеціаліста: історія випускника С++ GL BaseCamp
Почати шлях в ІТ під час навчання в університеті — ще той виклик, який вимагає наполегливості і постійної практики. Сергій Піскурський, студент та Trainee Specialist GlobalLogic, приєднався до компанії після проходження С++ GL BaseCamp. Хлопець поділився досвідом навчання перед курсом та підготовки до С++ GL BaseCamp. Чому ти вирішив вивчати С? Коли я почав думати … Continue reading Декомпозуй це: розкладаємо великі та складні задачі на компоненти →
Більше
Share this page:
-
-
-
-
URL copied!