Capacity – co to znaczy i jak je rozumieć?

Capacity to po prostu Twoja realna „pojemność” – ile pracy, klientów czy zadań jesteś w stanie obsłużyć w konkretnej jednostce czasu, bez zatykania systemu i spadku jakości. Ta miara pozwala policzyć, czy biznes w ogóle ma szansę zarabiać i czy Twój plan pracy nie jest czystą fikcją. Jeśli chcesz świadomie planować, prognozować przychody i nie przepalać zasobów, warto dobrze zrozumieć, czym jest capacity i jak je liczyć w różnych kontekstach. Właśnie temu poświęcony jest ten tekst – przeczytaj i przełóż to od razu na swoją firmę lub zespół.

Co to znaczy capacity?

Capacity to pojemność systemu, zespołu lub lokalu – maksymalna ilość pracy, zadań albo klientów, jaką możesz obsłużyć w określonym czasie przy założeniu, że wszystko działa w normalnych warunkach. W restauracji będzie to liczba posiłków na godzinę, w zespole Scrumowym liczba wymagań na Sprint, a w chmurze obliczeniowej ilość operacji, które mieszczą się w przydzielonych zasobach. Zawsze chodzi o granicę, powyżej której pojawiają się kolejki, opóźnienia albo przeciążenie.

Ta granica nie jest abstrakcyjna – wynika z konkretnych ograniczeń: liczby ludzi, stolików, mocy obliczeniowej czy kanałów komunikacyjnych. Capacity nie opisuje tego, co „chciałbyś” zrobić, tylko to, co realnie jesteś w stanie dowieźć przy danym składzie, sprzęcie i procesach. Dlatego dobrze policzona pojemność działa jak zimny prysznic: pokazuje, czy Twój pomysł ma sens przy obecnych zasobach.

Capacity to liczba maksymalnych zadań, klientów lub operacji w jednostce czasu, które jesteś w stanie obsłużyć bez tworzenia zatorów.

Jak rozumieć capacity w restauracji?

W gastronomii capacity bardzo łatwo przełożyć na liczby. „Policz ile osób możesz nakarmić na godzinę” – to najbardziej obrazowa definicja. Jeśli lokal jest w stanie wydać 100 posiłków na godzinę, to właśnie ta liczba jest jego graniczną pojemnością operacyjną. Na tej podstawie możesz zbudować cały model finansowy: od punktu rentowności po maksymalne przychody.

Jak policzyć, kiedy lokal wychodzi na zero?

Najpierw trzeba znać koszty stałe i zmienne. Koszty stałe to czynsz, pensje, energia – wydajesz je niezależnie od liczby klientów. Koszty zmienne to głównie koszt jedzenia i materiałów na jedno danie. Kiedy wiesz już, ile kosztuje Cię godzina otwarcia lokalu, możesz policzyć minimalną liczbę posiłków potrzebnych, aby pokryć wszystkie wydatki. Tę wielkość dzielisz przez capacity i dostajesz wymagany poziom „wypełnienia” restauracji.

Jeżeli Twój lokal ma capacity na poziomie 100 posiłków na godzinę, a próg rentowności wypada przy 50 daniach na godzinę, znaczy to, że musisz być zapełniony co najmniej w 50%, aby nie dokładać do biznesu. Gdy z wyliczeń wychodzi, że potrzebujesz 70–80% stałego obłożenia, model jest bardzo ryzykowny – koszt jest za wysoki albo pojemność lokalu zbyt mała jak na daną lokalizację.

Jak obliczyć maksymalne i realne przychody lokalu?

Drugi krok to przełożenie capacity na pieniądze. Jeśli umiesz policzyć posiłki na godzinę, łatwo policzysz maksymalną sprzedaż. Wzór jest prosty: capacity na godzinę mnożysz przez średnią wartość transakcji (np. 40 zł) i liczbę godzin pracy dziennie. W przykładzie 100 transakcji na godzinę przy 40 zł daje 4000 zł maksymalnego obrotu na godzinę. Gdy lokal pracuje 10 godzin, matematyczny sufit to 40 000 zł dziennie.

Wiesz jednak, że pełne wypełnienie lokalu utrzymuje się rzadko. Dlatego stosuje się uśrednienie – np. przyjęcie 50% typowego wykorzystania capacity. Wtedy liczysz: capacity x godziny pracy x średnia transakcja x 50%. Dla naszego przykładu: 100 x 10 x 40 zł x 50% = 20 000 zł. To szacunkowy dzienny przychód, który lepiej odzwierciedla rzeczywistość niż sam „sufit” teoretyczny.

Jak policzyć capacity z podziałem na stoliki, kuchnię i kelnerów?

Cała restauracja będzie tak silna, jak jej najsłabsze ogniwo. Capacity trzeba więc policzyć osobno dla trzech obszarów, a za pojemność całego lokalu przyjąć wartość najmniejszą:

• capacity stolików,
• capacity kuchni,
• capacity obsługi kelnerskiej.
• capacity procesów pomocniczych (np. zmywak, pakowanie na wynos).

Stoliki liczysz, mnożąc ich liczbę przez średnią liczbę gości na stolik w ciągu godziny. Jeśli masz 10 stolików, średnio siedzą po 2 osoby i spędzają przy stole około godziny, pojemność sali to 20 osób na godzinę. Kuchnię liczysz, biorąc liczbę kucharzy, mnożąc przez 60 minut i dzieląc przez średni czas przygotowania dania, uwzględniając dodatkowe zadania (np. zmywanie). Kelnerów liczysz podobnie – łączna liczba minut pracy w godzinie podzielona przez średni czas pełnej obsługi jednego klienta.

Capacity całej restauracji to minimum z capacity stolików, kuchni i obsługi – ten element będzie generował kolejki i opóźnienia.

Jak capacity działa w świecie IT i danych?

W zarządzaniu systemami IT pojęcie pojemności jest równie przydatne, tylko operujemy innymi jednostkami. W usługach chmurowych zamiast liczby klientów na godzinę liczy się na przykład ilość zapytań, operacji czy jednostek mocy obliczeniowej. W takim świecie capacity mierzy się nie w osobach, ale w jednostkach obliczeniowych CU przypisanych do danej platformy.

Jak Microsoft Fabric mierzy pojemność?

Platforma Microsoft Fabric korzysta z jednostek Compute Units, które opisują moc obliczeniową dostępnej pojemności. Tę pojemność można monitorować przy pomocy narzędzia Microsoft Fabric Capacity Metrics. Aplikacja zbiera dane o tym, jak w czasie wykorzystywane są zasoby – które operacje zużywają najwięcej mocy, gdzie pojawia się dławienie, a gdzie system musi skalować się w górę, żeby utrzymać wydajność.

Administrator widzi m.in. z jakim obciążeniem działają obliczenia Spark, jak rośnie użycie magazynu danych w ciągu ostatnich 30 dni oraz kiedy automatyczne skalowanie podnosi lub zmniejsza pojemność. Dzięki temu wie, czy trzeba zwiększyć capacity, czy raczej zmienić sposób pracy zespołów i optymalizować konkretne obciążenia. To ten sam mechanizm, co w restauracji – ograniczone zasoby i konieczność zdecydowania, czy inwestować w ich powiększenie.

Capacity a systemy komunikacji radiowej

W łączności radiowej pojemność oznacza maksymalną liczbę użytkowników i kanałów, które mogą działać równocześnie w ramach jednej infrastruktury. System trunkingowy Capacity Plus dla radiotelefonów MOTOTRBO jest tu dobrym przykładem – jedna stacja bazowa jest w stanie obsłużyć do 1200 urządzeń, do 12 cyfrowych kanałów głosowych i 24 kanały do transmisji danych. Tak skonstruowane capacity eliminuje konieczność dokładania kolejnych częstotliwości i pozwala utrzymać płynny przepływ komunikatów głosowych oraz danych.

Jak capacity łączy się z velocity w Scrumie?

W zespołach zwinnych capacity ściśle łączy się z pojęciem Velocity. Velocity mówi, ile wymagań zespół zwykle dowozi w jednostce czasu (najczęściej w Sprincie), a capacity opisuje, jaka jest przewidywana „pojemność” zespołu na najbliższą iterację. Obie miary pracują w tym samym języku: Story Points, liczba wymagań lub inna przyjęta jednostka wysiłku.

Czym jest velocity?

Story Points to najpopularniejsza jednostka, w której zespoły Scrumowe liczą velocity. Jeżeli przez ostatnie 5 Sprintów zespół zrealizował łącznie 170 punktów w ukończonych wymaganiach, średnia prędkość wyniesie 34 Story Pointy na Sprint. Często liczy się ją jako średnią kroczącą z 3–5 ostatnich iteracji, bo sposób pracy i skład zespołu zmieniają się w czasie.

Jeśli zespół nie używa punktów, velocity da się wyrazić w liczbie zrealizowanych elementów Backlogu Produktu na Sprint – np. średnio 6 wymagań. Gdy szacuje się w godzinach, velocity nie ma dużo sensu, ponieważ dwutygodniowy Sprint 10-osobowego zespołu daje zawsze tę samą nominalną liczbę godzin, a różnice wynikają z organizacji pracy, nie z samej skali czasowej.

Jak rozumieć capacity w zespole Scrumowym?

W kontekście Scrum capacity to prognoza, ile zespół jest w stanie realnie zrealizować w nadchodzącym Sprincie. Używa się tej samej jednostki, co przy velocity: jeśli liczysz punkty, capacity wyrażasz w punktach, jeśli liczysz wymagania – w liczbie wymagań. W standardowym Sprincie, bez świąt i masowych urlopów, capacity często zbliża się do średniego velocity, bo warunki są podobne do historycznych.

Różnica pojawia się tam, gdzie wchodzą w grę nieobecności, dodatkowe obowiązki czy wdrożenia produkcyjne. Wtedy zespół szacuje swoją dostępność godzinową lub procentową – uwzględniając urlopy, szkolenia, stałe dyżury – i na tej podstawie koryguje capacity, podczas gdy velocity nadal pozostaje średnią z przeszłości.

Jak używać capacity do korekty velocity?

Kiedy Sprint wypada w okresie świątecznym albo połowa zespołu idzie na urlop, używanie samego velocity prowadzi do fałszywej prognozy. Tu wchodzi w grę capacity – pokazuje, że w nadchodzącej iteracji „nominalna prędkość” z przeszłości powinna zostać obniżona, bo zasoby są mniejsze. Można to policzyć matematycznie (np. odejmując godziny nieobecności) albo oszacować zespołowo „na czuja” na Planowaniu Sprintu.

Velocity opisuje historyczną prędkość zespołu, a capacity koryguje tę prędkość na najbliższy Sprint, biorąc pod uwagę faktyczną dostępność ludzi.

Jak używać capacity i velocity w planowaniu?

Capacity i velocity nie są po to, żeby nimi raportować „produktywność”, tylko po to, żeby zespół i biznes mógł realistycznie planować. Product Owner, znając średnią prędkość zespołu i wielkości elementów Backlogu Produktu, może ułożyć prognozę – w którym Sprincie mniej więcej wypadnie realizacja kolejnych bloków pracy. Jeśli pierwszych 50 elementów Backlogu waży 200 Story Pointów, a zespoły dowożą średnio około 40 punktów na Sprint, łatwo oszacować, że ostatni z nich wyląduje mniej więcej za 5 iteracji, o ile nie zmieni się zawartość Backlogu.

Tu do gry wchodzi też Prawo Parkinsona, które mówi, że praca rozszerza się tak, aby wypełnić czas dostępny na jej ukończenie. Jeśli zaplanujesz wyraźnie mniej niż Twoje średnie velocity, zespół z dużym prawdopodobieństwem „rozciągnie” te zadania tak, że i tak nie zostanie czasu na „dobieranie” nowych wymagań. Z kolei planowanie znacznie powyżej historycznego maksimum kończy się niedowiezieniem Sprintu i chroniczną frustracją.

Dlatego przy planowaniu przyjmuje się prostą zasadę: nie planuj więcej niż wynosi Twoje średnie velocity lub jego rozsądny górny przedział z ostatnich Sprintów. A gdy szykują się urlopy, święta lub duże wdrożenie, koryguj plan w dół na podstawie capacity, zamiast udawać, że „tym razem się sprężymy”. Realna pojemność – czy to w restauracji, chmurze, czy zespole Scrumowym – stawia granice, których nie da się przeskoczyć samymi deklaracjami.