Chmura idzie w parze ze zwinnością

W 24. odcinku podcastu „Zwinne organizacje” Paweł Tomkiel i Marcin Knieć stawiają tezę, że nie można być zwinnym nie korzystając z chmury. Co wynikło z tej dyskusji? Zapraszamy do słuchania.

Transkrypcja podcastu

Paweł: Cześć, nazywam się Paweł Tomkiel.

Marcin: Cześć, nazywam się Marcin Knieć.

Paweł: Jesteśmy konsultantami w Deloitte Digital.

W dzisiejszym odcinku będziemy mówić o zwinności, ale w kontekście chmury i żeby dobrze ten temat zrozumieć, zaprosiłem dzisiaj Marcina - dyrektora w dziale Cloud Engineering w Deloitte Consulting. Gdybyśmy mogli zacząć od tego czym jest chmura, jak możemy zdefiniować? I czym właściwie różni się od takiego klasycznego podejścia on-premise?

Marcin: To jest bardzo dobre i bardzo trudne pytanie, bo chmura może być tym, czym tak naprawdę ją zaprojektujemy dla siebie. Jeżeli spojrzymy na samą definicję chmury, że jest to pewnego rodzaju nowy sposób dostarczania usług IT, które są dostępne na żądanie, konfigurowalne, dostępne natychmiast, płacimy za użycie, zużycie, to widzimy paletę ogromnych możliwości, z których możemy skorzystać. To daje nam rzeczywiście chmura. A to, w jaki sposób organizacja ją wdroży, jaki będzie miała na nią pomysł, to sprawia, czym tak naprawdę ta chmura będzie, bo czasami może być przeszkodą, a czasami może być potencjałem, który uwalnia organizację i pomaga realizować projekt.

Paweł: To teraz gdybyś miał porównać to, co teraz powiedziałeś do on-premise, do rozwiązań, które pewnie klasycznie nadal funkcjonują w wielu organizacjach, jaka jest kluczowa różnica?

Marcin: Rzeczywiście on-premise jest to pewnego rodzaju dominant, który jest na rynku i chmura, zwłaszcza w Polsce, bardzo dynamicznie stawia swoje pierwsze kroki, jeśli chodzi o implementację w przedsiębiorstwach. Rzeczywiście bardzo mocno przyspiesza adopcja chmury, pojawiają się nowe inicjatywy, powstają Data Center w Polsce. Zakładamy, że jeszcze ta adopcja chmury przyspieszy, niemniej jednak dominuje świat on-premise, w którym to my jako firma mamy na sobie bardzo dużą odpowiedzialność za utrzymanie całej infrastruktury IT, z punktu widzenia czy sprzętu, ludzi, procesów, także pomysłu, co tak naprawdę chcemy udostępniać jako usługa IT. Czy to będzie oprogramowanie, pewnego rodzaju moce obliczeniowe, czy też funkcje, sztuczna inteligencja – to wszystko spoczywa na naszych barkach. I taka jak dla mnie główna różnica pomiędzy on-premem a chmurą, jest to właśnie balansowanie pomiędzy tą odpowiedzialnością, którą chcemy oddać dostawcy, który w zamian udostępni nam usługi, a w on-premie wszystko jest „na naszej głowie” i jest to pewnego rodzaju ograniczenie, z którym musimy się zmierzyć już na starcie.

Paweł: Po tym, co powiedziałeś, od razu pojawiło mi się w głowie słowo outsourcing serwerów do chmury, ale chyba nie jest tak proste, jak to zabrzmiało.

Marcin: To nie jest takie proste. Jeśli zapytamy osób z rożnych firm, czym jest chmura, to każdy będzie miał swoją odpowiedź. Sama chmura też się zmienia i bardzo mocno ewoluuje w czasie. Rzeczywiście w pierwszych fazach istnienia chmury, czy w naszych umysłach, czy implementacjach, kojarzona była z wirtualnymi serwerami, z backupem, kupowaniem pamięci obliczeniowej, miejsca na dyskach i takie były początki istnienia chmury w organizacjach. Jednak w ostatnich latach chmura zmieniła się na tyle, że myślimy głównie o usługach. Bardzo często zapominamy o serwerach, o tym, jaka powinna być podstawa sprzętowa do dostarczenia pewnego rodzaju usług. Idziemy w stronę, w jaki sposób chcemy wykorzystać usługi chmurowe, aby dawać konkretną wartość do projektów, np. biznesowych, czyli ten sprzęt z punktu widzenia chmury już zostaje troszeczkę gdzieś z tyłu. Skupiamy się na czymś innym, w jaki sposób chcemy generować wartość, realizować projekty i efektywnie dostarczać, w elastyczny sposób.

Paweł: W takim razie to, co powiedziałeś, już buduje obraz tej chmury, faktycznie tej bliższej, choć jeszcze nie tak zaadoptownej w organizacjach, czyli tej, gdzie są usługi na żądanie, gdzie możemy wypożyczyć sobie de facto cały klaster do przetwarzania danych, do machine learningu, do analizy obrazu, do analizy wideo. Czyli faktycznie te usługi, które są najnowsze, ale jednocześnie dają też największą wartość.

Teraz chcę cię zapytać o to z perspektywy zwinności. Zwinność de facto oznacza przyspieszenie dostarczenia jakiejś wartości do klienta, do użytkownika końcowego i to na tym skupia się cały ruch agile, na jak najszybszym dostarczeniu tej wartości. Jak chmura może pomóc w uzwinnianiu organizacji albo inaczej, jak on-premise może zahamować tę zwinność w organizacji?

Marcin: Powiedziałbym, że wolę zacząć od tej pozytywnej strony, czyli powiedzieć, jak chmura może pomóc, bo to jest to, co na pewno można gdzieś później wykorzystać. I tak jak ty opowiadasz o agile to ja cały czas mam chmurę w tle, bo dla mnie te pojęcia są bardzo mocno bliskie sobie, oczywiście, jeżeli odpowiednio to zrozumiemy i wykorzystamy. Dla mnie takim synonimem słowa „chmura” jest „elastyczność” i to elastyczność traktowana na wielu poziomach. Z jednej strony możemy używać tej skalowalności horyzontalnej, wertykalnej, skalować niemal dowolnie swoje zasoby, płacić tylko za to wykorzystane, czyli mocno selektywnie dobierać to, z czego będziemy chcieli skorzystać, z punktu widzenia mocy obliczeniowej. A z drugiej strony, mamy to ogromne bogactwo usług, o których już wcześniej mówiłeś, że nie skupiamy się rzeczywiście tylko na serwerach, na sprzęcie, na tradycyjnych usługach IT, ale idziemy w stronę konkretnych usług biznesowych, czy to związanych z analizą danych czy sztuczną inteligencją, przetwarzaniem obrazu, czy też takimi formami usług, jakie sami zaprojektujemy. Jak chmura jest przede wszystkim ogromną elastycznością, daje wiele możliwości wyboru to jest to jednocześnie błogosławieństwo i klątwa, bo, żeby zrozumieć całe bogactwo, trzeba poświęcić trochę czasu, trzeba mieć wielu specjalistów.

Elastyczność jest takim kluczem - rozliczalność, granularność, skalowalność, prędkość, bo gdzieś w tle zawsze jest ten słynny Time To Market, a w chmurze projektować i dostarczać rozwiązania możemy naprawdę bardzo szybko.

Paweł: Uruchomienie środowiska deweloperskiego zajmuje faktycznie dużo mniej czasu, ale czy to nie jest trochę tak: załóżmy, że jestem właścicielem jakiegoś małego start-upu, mam jeden zespół deweloperski i ten zespół deweloperski chce napisać aplikację do streamingu wideo. Faktycznie mogę od razu użyć zasobów, które mam w chmurze, mogę użyć storedge’u, żeby przechowywać wideo i wszystkich usług analizy tego wideo i mogę bardzo szybko wdrożyć taką aplikację. Tylko czy to nie jest tak, że mogę z tego skorzystać, bo jestem małą organizacją, bo ta zwinność wpisana w to, że jesteśmy nadal mali, jesteśmy start-upem? Jak duże organizacje mogą zwiększać zwinność dzięki chmurze?

Marcin: Duża organizacja może skorzystać z chmury na wiele sposobów, tylko zwykle jest to sposób bardziej kontrolowany. Bo procesy udostępniania zasobów, wydzielania zgód na korzystanie z pewnego rodzaju usług, nawet z racji skali firmy, czy też pewnego rodzaju regulacji, które bywają w przedsiębiorstwach, są po prostu dłuższe. Myśląc o zwinności w kontekście chmury i też dużych organizacji nie myślimy, jak od strony technologicznej usługę chmurową uzyskać szybko, tylko jak sprawić bardziej formalnie, procesowo, proceduralnie, abyśmy mogli z tego bogactwa korzystać. Specyfika chmury polega na tym, że usługi chmurowe są dostępne niemal natychmiast, ze wskazaniem niemal, czyli możemy rzeczywiście bardzo szybko powoływać te usługi. Niemniej jednak to, na co zostanie nam pozwolone w ramach projektu, jakie grono usług będzie dostępne dla grona deweloperskiego, to już zależy od wdrożenia. Sukces tej skali zwinności zależy przede wszystkim od sukcesu wdrożenia agile i wdrożenia też chmurowego, czyli z jednej strony dojrzałości zespołów, które pracują zwinnie, ale z dojrzałości też organizacji, która musi założyć pewnego rodzaju swobodę. Chmurę również można ograniczyć ramami, które będą nie do przeskoczenia, więc w tym kierunku powinniśmy myśleć, aby Cloud Governance, Landing Zone, czyli te podstawy, które z jednej strony sprawiają, że wdrożenia chmurowe są bezpieczne, jednak, żeby służyły temu, aby zespoły mogły eksperymentować, szybko zmieniać architektury, aby testować nowe pomysły i rozwiązania.

Paweł: To jest ciekawe, co powiedziałeś, bo zrozumiałem, że technologicznie chmura jest tak samo dostępna dla małych, jak i dużych organizacji, ale tą pierwszą, główną barierą, którą wymieniłeś jest bariera wszystkich procedur, które są wewnątrz organizacji, które de facto pozwolą komuś z tej chmury skorzystać.

Marcin: Tak, podam tutaj bardzo pragmatyczny przykład. Spotkałem się w swojej karierze z wdrożeniami chmurowymi, gdzie pomysł na to, jak powinna wyglądać implementacja chmury pochodził z centrali, np. zagranicznej i oddziały w Polsce otrzymywały już wstępnie skonfigurowane, ograniczone środowiska chmurowe, wręcz z zaleceniami, w jaki sposób powinny z niego korzystać, w jaki sposób nie powinny z niego korzystać i negocjacje tych warunków były bardzo trudne, czyli traciliśmy pewnego rodzaju elastyczność, którą tak wychwalaliśmy. Przede wszystkim na początku można to porównać do wyprowadzenia psa na spacer, który po prostu ma krótką smycz i kaganiec. Jego możliwości eksperymentowania ze światem są ograniczone, więc pomysł na wdrożenie chmury musi zakładać pewnego rodzaju ramy. To ważne, żeby te ramy były znane, bezpieczne dla organizacji, ale z drugiej strony pozwalały na ruchy w różne strony, które sprawią, że będziemy mogli korzystać z tego, co będzie potrzebne do realizacji projektów.

Paweł: I tak wracamy do tego, co powiedziałeś na początku, że, wdrażając chmurę, musimy gdzieś postawić granicę pomiędzy tym, jak bardzo chcemy ją wystandaryzować i okroić, opakować w nasze procedury, a ile chcemy zostawić sobie elastyczności.

Marcin: Tak, te granice, żeby to wybrzmiało jasno, one są bardzo potrzebne. Ta elastyczność, to pole do eksperymentowania, ta szybka dostępność usług jest jednocześnie i błogosławieństwem i może być też przekleństwem, np. kosztowym. Bo tutaj Pay-As-You-Go może znaczyć tyle, że zapłacimy mało, jak nie będziemy korzystać z danych usług, ale jeżeli będziemy, np. zbyt mocno eksperymentować z wielkością danych w projekcie i przetwarzać ich ogromne ilości, to zapłacimy też odpowiednio dużo. Też z punktu widzenia bezpieczeństwa tego wątku nie można pominąć. Chmura sama w sobie jest bardzo bezpieczna i ona jest zaprojektowana po to, by była bezpieczna, niemniej jednak to my jako użytkownicy, czy też jako administratorzy, mamy zapewniać bezpieczeństwo samych usług chmurowych w projektach i też zbyt duża swoboda, zbyt duże otwarcie na świat nie może nastąpić. Stąd te negocjacje granic, co można użyć, kiedy, w jakich przypadkach budowanie procesu Cloud Governance powinno przebiegać ze wzajemnym zrozumieniem i konieczności pewnych ograniczeń, ale i też konieczności pozostawienia możliwości korzystania z bogactwa, które chmura daje.

Paweł: Nie wiem, czy to będzie trochę zbyt techniczne, ale o to też chciałbym cię zapytać, bo to, co teraz powiedziałeś, wchodzi trochę w to, co wszyscy dostawcy chmurowi mają zdefiniowanego, czyli takie shared responsibility, czyli to dzielenie się odpowiedzialnością z użytkownikiem chmury. Chmura sama w sobie jest bezpieczna, to, co powiedziałeś, ale wszystko, co na niej stawiamy, na niej konfigurujemy, to ta odpowiedzialność leży po naszej stronie. Jak to zrobić dobrze albo czego zacząć?

Marcin: Od czego zacząć? Od pełnego zrozumienia co jest po drugiej stronie. Takim dobrym przykładem dla tych jeszcze, którzy tematu chmurowego nie zgłębiali, w jaki sposób patrzeć na model odpowiedzialności w chmurze, jest taka grafika, która jest szeroko dostępna w sieci, jest konotowana jako pizza-as-a-service - w jaki sposób patrzymy na zdejmowanie tej odpowiedzialności z nas jako użytkowników IT, na przykładzie kulinarnym, który jesteśmy w stanie zrozumieć. Tak jak podkreśliłem, musimy znać naszą odpowiedzialność, dostawcy chmurowi wszystkiego za nas nie zrobią, stąd na etapie przygotowywania się do wdrożeń chmurowych tematy bezpieczeństwa, czy sieci, czy w ogóle tożsamości, która jest takim nowym paradygmatem w chmurze, implementowania też różnego rodzaju podejść do bezpieczeństwa, jak zero trust i wiele innych, to dla niektórych one są nudne, dla niektórych one są zbyt techniczne, ale dobrze przerobione na początku, pozwalają nam eksperymentować dalej z chmurą i robić to bezpiecznie i nie przerażając nikogo też rachunkami za chmurę, które nie ukrywajmy, mogą być czasem też zaskakujące.

Paweł: Marcin, powiedzieliśmy sobie o jednej, takiej głównej barierze. Jakie inne bariery byś jeszcze wymienił, które trzeba pokonać w organizacji, kiedy chce się wdrożyć chmurę, kiedy chce się uzwinnić swój proces dzięki technologii?

Marcin: Z mojej perspektywy, jedną z największych barier we wdrażaniu chmury, ale też ogólnie we wdrażaniu technologii, we wdrażaniu zmian to jesteśmy my sami, czyli ludzie. Wspomnieliśmy też na początku, że chmura jest ogromnym ekosystemem, wszelkiego rodzaju usług, więc pierwszym progiem wejścia w chmurę jest to, że musimy ją dobrze zrozumieć. Musimy poznać nie tylko możliwości, ale też ograniczenia. Musimy zrozumieć również, w jaki sposób powinniśmy współpracować jako zespoły, korzystając z chmury, bo zmienia się model pracy, zmienia się model operacyjny, gdyż można postawić taką tezę: nie możemy pracować identycznie jak do tej pory, aby uwolnić ten potencjał, który jest w chmurze. Chmura nie jest tylko takim dodatkiem do tego IT, który mamy, że dołożymy sobie backup w chmurze i możemy powiedzieć, że czerpiemy jakoś tam znaczącą wartość z chmury. Prawdziwy potencjał wykorzystania usług chmurowych i wartości z chmury to jest też zmiana sposobu pracy, niektórzy twierdzą też, że sposobu myślenia o projektowaniu rozwiązań, o nowych architekturach, które potrafią wyzwolić jeszcze więcej wartości usług chmurowych. Tych barier też bywa więcej, czasami są to bariery formalnoprawne. My, jako Deloitte pomagamy też firmom współpracować z organami nadzorującymi wdrożenia chmurowe, np. w instytucjach finansowych. Wiele też barier procesowych, które przenikają całą organizację, bo jeżeli, np. zaczynamy kupować chmurę na większą skalę i z niej korzystać to nie zmienia nam się tylko technologia, pojawiają się nowe procesy i standardy w dziale zakupów, w dziale kontrolingu, który to rozlicza, w dziale prawnym, który musi zrozumieć również chmurę, aby opiniować umowy, więc ta chmura przy wdrożeniu przenika nam na wskroś wiele działów, jest śmiało można powiedzieć, pewnego rodzaju zmianą i adaptacją całej organizacji, a większość firm nie jest do końca świadomych, jak duża zmiana postępuje przy wdrożeniach chmurowych i nawet jak sformułować ten zespół, który będzie zajmował się tematem chmurowym organizacji.

Paweł: Do tej pory sam nie byłem świadomy, że to pociąga zmiany również w dziale prawnym i kontrolingu. Myślałem, że to jest po prostu zakup, jak każdy inny, tyle że inaczej rozliczany.

Marcin: No nie, jeszcze raz wrócę do tego bogactwa, że chmurę można kupować na wiele sposobów, są to sposoby różne od tych, które dotyczyły nazwijmy to tradycyjnego IT i ta mnogość kontraktów czy sposobu zakupu, zawiłość cenników i złożoność, poziomy rabatowania to oczywiście przy pewnego rodzaju praktyce potrafi nam pomóc, jednak ten próg wejścia, aby dokładnie zrozumieć zawiłości, odpowiedzieć na pytanie czy i kiedy chmura potrafi być np. tańsza dla organizacji, jest bardzo złożona.

Paweł: Zmierzając powoli do brzegu, czy nie jest tak, że chmura jest traktowana dosyć po macoszemu jako właśnie zabawkę młodych firm, zabawkę start-upów, czyli firm, które tworzą jakieś pierwsze MVP, a jak to wygląda z twojej perspektywy, jaki jest poziom adopcji, jak korzystają z tego duże organizacje, które mają funkcjonujące systemy?

Marcin: Muszę z jednej strony przyznać ci rację, bo bardzo często firmy zaczynają swoją przygodę z chmurą od jej testowania w pewnym sensie i implementowania tzw. strategii cloud first, czyli spróbujmy wykorzystać chmurę do tych nowych projektów, które, gdzieś się rodzą, które mamy w głowie. Wykorzystajmy te wszystkie zalety, które są, niemniej jednak chmura jest przede wszystkim stworzona do tego, aby w sposób automatyczny i skalowalny dostarczać złożone rozwiązania. Tutaj możemy płynnie przejść do  jednego z obszarów, które w chmurze wręcz brylują, czyli DevOps i automatyzacja, bo chmura jest wprost stworzona do tego, żeby ją automatyzować, żeby też rozwijać, np. w ramach filozofii Cloud Native rozwiązania, które potrzebują niezależnego skalowania, które mają być odporne na błędy, gdzie możemy bardzo szybko dodawać nowe funkcjonalności niemal niezauważalnie, więc jest szereg platform takich wbudowanych już w chmurę, pewnego rodzaju rozwiązań systemów, usług, które wspierają dostarczanie takich złożonych systemów, które możemy dziś równolegle rozwijać, później integrować i tak w sposób niezauważalny, albo mało zauważalny dostarczać dla użytkowników. Jest to słuszna, Paweł, uwaga, że nie utożsamiamy tylko chmury z PoC, MVP, z eksperymentowaniem. Tutaj rzeczywiście ma swoją przewagę, ale dobrze zaprojektowane rozwiązania, nawet migracja dużych systemów Legacy do architektów chmurowych, potrafią przekuć w projekty, które są doceniane na rynku.

Paweł: Kiedy zadałem ci te pytania, chwilę później powiedziałeś słowo skalowalność, to wydałoby się już tym kluczem do rozwiązania i to chyba sama skalowalność sprawia, że te firmy, które rosną najwięcej, firmy, które wymieniłeś: Netflixa, Spotify i inne firmy, które bazują na swoim wzroście, też bazują na technologii, to chmura wydaje się być totalnie dla nich stworzona.

Marcin: Uważam, że po pierwsze to jest prawda, ale po drugie, że tę prawdę można jeszcze rozwinąć w wiele prawd, bo sama chmura potrafi być elastyczna nawet dla organizacji, które na początku mają duży dług technologiczny, ale chcą coś zmienić. Ważny jest cel, do którego chcemy dojść. Nie każdy ma ambicje bycia Spotify, zdobywania coraz większego rynku w skali globalnej.

Chmura potrafi być elastyczna nawet dla organizacji, które na początku mają duży dług technologiczny, ale chcą coś zmienić.

Są firmy w Polsce, które znam, które działają np. w obszarze bankowości, mogą to być duże, mniejsze czy te średnie banki, które chcą po prostu dużo szybciej dostarczać nowe funkcjonalności do klienta. To jest, np. jeden z celów takich mierzalnych tzw. KPI, które służy wdrożeniom chmurowym, jeżeli teraz robimy, np. release oprogramowania, dostarczamy nowe funkcjonalności, aktualizację oraz na kwartał, raz na 2 miesiące, chcemy mieć zdolność dostarczania nowych funkcjonalności dla klientów, np. w ciągu tygodni lub nawet dni. Taki cel to jest bardzo dobry cel, który powinien zostać sobie postawiony jako jedno z pytań: czy chmura jest dla mnie i w jaki sposób, aby nie myśleć o chmurze, nie samej technologii, ale o tym, co chce zyskać z punktu widzenia tego biznesu, który prowadzę, może dać mi chmura?

Paweł: Innym celem, który teraz przyszedł głowy, kiedy powiedziałeś „dług technologiczny” to, jeżeli pracujesz nad systemem, w którym większość czasu jest poświęcana na maintenance i na poprawienie błędów, to może faktycznie czas pomyśleć nad rozbiciem tego wielkiego monolitu i chociażby zmigrować do chmury, zgodziłbyś się z tym stwierdzeniem?

Marcin: Tak, zgadzam się z tym stwierdzeniem i uczestniczyłem w kilku projektach, gdzie staraliśmy się, jak to powiedziałeś, rozbić te monolity i stopniowo, bo to się nie dzieje za dotknięciem magicznej różdżki, przenosić je do chmury, ale zawsze w tle nie jest samo pozbycie się tego długu technologicznego, czyli te tematy, nazwijmy to, czysto informatyczne. Tego rodzaju inicjatywy przynoszą największą wartość, gdy jednocześnie staramy się zmienić, czy też dostosować te systemy do aktualnych oczekiwań użytkowników. Bardzo często to właśnie użytkownicy, oczekiwania rynku, czy też konkurencja skłaniają nas do tego, żeby ten proces zmiany naszych korowych systemów lub kluczowych dla naszej działalności, do stopniowej, całościowej, częściowej, ale jednak migracji na chmurę, bo nie o samą technologię tam chodzi, oczywiście ten dług technologiczny nikomu nie jest miły, ale największa wartość z takich projektów jest wtedy, gdy jednocześnie wymyślamy nowy sposób obsługi użytkownika, dostosowujemy nowy UI/UX, czyli za jednym zamachem, w jednym projekcie staramy się uzyskać nie tylko korzyść techniczną, ale też biznesową.

Paweł: Marcin, powiedzieliśmy sobie dziś o wielu rzeczach. Jaką jedną kluczową chciałbyś, żeby nasi słuchacze zapamiętali, co byś podkreślił teraz na koniec?

Marcin: Dla mnie taką jedną myślą jest to, że powinniśmy bardzo dobrze przemyśleć cel, jaki sobie stawiamy przy wejściu w chmurę i w szczególności, żeby nie myśleć jedynie o technologii, bo te najważniejsze pytania, które padają przy wdrożeniach chmurowych czy przy strategiach adopcji chmur, które tworzymy, to są pytania o to, jakimi firmami chcemy być, jaki biznes chcemy robić, jak chcemy obsługiwać użytkowników, a chmura jest samym narzędziem, które ma nam w tym pomóc. Oczywiście jest to wiodące, kluczowe narzędzie, które my jako specjaliści bardzo cenimy, lubimy, niemniej jednak cel powinien być bardzo mocno oparty na realiach biznesowych.

Paweł: Bardzo Ci dziękuję, Marcin, za rozmowę, za podzielenie się swoim doświadczeniem.

Drodzy słuchacze, jeżeli chcecie, żebyśmy rozwijali temat chmury to śmiało napiszcie na naszych mediach społecznościowych. Dzisiaj już dziękujemy wam za wysłuchanie naszej rozmowy do końca i do usłyszenia w kolejnym odcinku.