Jak menedżer może oszacować koszt rozwiązania IT

Rozpoczynając projekt, możesz skupić się wyłącznie na stronie technicznej i zaproponować genialne rozwiązanie, najlepsze na rynku. Dopiero później staje się jasne, że całkowity koszt infrastruktury IT sprawia, że ​​wdrożenie jest nieopłacalne dla biznesu. Dobrze, jeśli dowiedziałeś się o tym już na etapie planowania.

I tutaj PM lub BA bardzo by klientowi pomogli, gdyby dokonali wstępnej kalkulacji kosztu posiadania (TCO – total cost of ownership).

Badanie techniczne przyda się menedżerowi nie tylko przy kalkulacji TCO. Zrozumienie architektury projektu pozwoli uniknąć niepotrzebnych kosztów na etapie planowania, pomoże podjąć decyzję o wprowadzeniu nowych funkcjonalności.

W artykule zebrano praktyczne rekomendacje z webinariów naszych prelegentów, które pomagają PM i analitykom biznesowym zrozumieć architekturę projektu na kursie ArchiTech.

Rozwój technologii chmurowej zapewnił firmom praktycznie nieograniczone zasoby do oceny i analizy. Rozwój usług na poziomie cloud computingu od takich światowych graczy jak Amazon, Google, IBM, Oracle pozwala na przeprowadzenie oceny przy mocno obciążonych parametrach i konfiguracjach.

I tu pojawia się problem: gdy zasoby nie są ograniczone, niewiele osób myśli o efektywności ich wykorzystania. Usługi technologii chmurowych docelowo odbiją się na modelu operacyjnym, bo za pół roku opłaty za korzystanie z usługi mogą znacząco wzrosnąć.

Nie przepłacaj za usługi cloud

Platformy chmurowe oferują wiele korzyści przy uruchomieniu nowego produktu. W ciągu 15 minut możesz wdrożyć dowolne środowisko w dowolnym momencie, od razu rozpocząć projekt i zarabiać. To duży plus, ale aby dalej wygrywać, trzeba poprawnie obliczyć koszt posiadania – Total cost of ownership.

• Policz wszystko. Dostawcy usług w cloud udostępniają swoje kalkulatory, ale należy je ponownie sprawdzić. Czasami można zapomnieć o ważnej usłudze, co później wpłynie na produktywność. W innych przypadkach, szczególnie w przypadku mikroserwisów, żądań mocno obciążonych systemów, potrzebne będą dodatkowe komponenty. Oceń przyszłą konfigurację oprogramowania w zasobach cloud – konfiguracja cloud plus oraz konfiguracja software.

Nie bój się szukać specjalistów konkretnego dostawcy cloud i zadawać im dodatkowych pytań. Pomoże to w przyszłości obronić budżety na wsparcie i rozwój tego rozwiązania w ciągu najbliższych 2-3 lat.

• Oblicz TCO. Kolejną ważną kwestią jest to, jak długo należy obliczać koszt posiadania, TCO (total cost of ownership). Dziś nie ma już konieczności obliczania TCO za 5 lat, jak to było do 2010 roku. Spójrz na horyzont nie dłuższy niż 3 lata, a lepiej – 1-2 lata. Teraz wszystko zmienia się bardzo szybko: narzędzia, frameworki, tool, funkcje. Usługi takie jak data quality i data profality w Azure pozwalają na realizację projektów, które kiedyś zajmowały rok, w zaledwie 4 miesiące.

• Weź pod uwagę ROI. Czasami przy obliczaniu kosztu posiadania trzeba będzie wziąć pod uwagę ROI (return of investment). Przykładowo, jeśli firma jest gotowa zainwestować nominalną sumę 100 tys. w nowe rozwiązanie, należy uwzględnić w jaki sposób i w jakim okresie te finanse się zwrócą.

Technologie chmurowe na pewno pomagają zarabiać, ale zawsze trzeba kalkulować, jak efektywnie zarządzać tym narzędziem z finansowego punktu widzenia. W przeciwnym razie koszt posiadania stanie się tak wysoki, że trzeba będzie „wyciąć” część cloud configuration. Dwie możliwości oszczędzania na usługach chmurowych to rezerwacja pojemności (reserved instance) lub przejście na spoty.

Oblicz koszt poszczególnych komponentów

Aby poprawnie oszacować całkowity koszt początkowy rozwiązania IT, spójrz na poszczególne elementy:

• Ile będzie kosztować licencja na komponenty. Pamiętaj, że komercyjne oprogramowanie typu open source i jego wsparcie są płatne, więc spójrz na typy licencji.
• Jaki jest koszt i warunki wdrożenia (time to market). Chodzi o to, po jakim czasie, jeśli zainwestujemy 100 tys., nasza inwestycja się zwróci. ROI trzeba porównywać z czasem time to market, bo jeśli w ciągu roku uda się zrealizować te 100 tys., to być może za rok ten produkt lub usługa straci na znaczeniu.
• Jakie będzie wsparcie. Jeśli na poziomie community, należy szukać personelu technicznego o odpowiednich kwalifikacjach. Jeśli korzystasz z platformy, może to być komercyjne wsparcie typu open source.
• Oddzielnie oblicz koszt rate wewnętrznego wskaźnika zatrudnienia dla specjalistów w tej technologii i w regionie, którego potrzebujesz. Wykonaj obliczenia w perspektywie nie dłuższej niż trzy lata. 
• Opracuj cloud configuration. Możesz zacząć korzystać z kalkulatora dostarczonego przez dostawcę. A następnie dodatkowo komunikuj się z autoryzowanymi partnerami w sprawie niektórych usług. Zwłaszcza jeśli masz pytania dotyczące migracji z niektórych systemów on-premise do cloud.
• Hardware i/lub Software configuration. W przypadku mikrosystemu zamkniętego istotny jest optymalny dobór niezbędnych Hardware i Software oprogramowania, podjęcie decyzji, jakie serwery kupić w centrum data, na jakich platformach, z jakimi application і database serwerami, tak aby koszt posiadania i koszty utrzymania były porównywalne z kwotą, która zostanie zainwestowana w oprogramowanie.
• Oblicz koszt licencjonowania narzędzi programistycznych płatnych bibliotek i frameworków. Mogą być kosztowne, ale jednocześnie skracają czas tworzenia i odpowiednio przyspieszają czas time to market.

Jeśli wszystkie te szczegóły techniczne wydają Ci się zbyt skomplikowane, przyjdź i poznaj kurs TechMind. Za półtora miesiąca nauczysz się komunikować ze specjalistami technicznymi w ich języku i zrozumiesz, jaki framework i zespół wybrać do projektu. A w ArchiTech wyjaśniamy, jak pracować z architekturą projektową i wybierać najlepsze rozwiązanie dla zadania biznesowego.

Co to jest feature

Feature, lub funkcja, jest kluczowym elementem w tworzeniu oprogramowania i zarządzaniu projektami. Jest to odrębny aspekt produktu, który oferuje użytkownikowi pewną wartość.

Jest to cecha funkcjonalna lub zdolność produktu, która czyni go użytecznym lub pożądanym dla użytkownika końcowego. Może to być nowa funkcja, ulepszenie interfejsu, zwiększenie wydajności, a nawet innowacja ułatwiająca korzystanie z produktu.

Feature są niezbędne, aby zapewnić konkurencyjność produktu na rynku. Pomagają spełnić potrzeby i oczekiwania użytkowników, zwiększyć użyteczność produktu i promować jego dystrybucję wśród docelowej grupy odbiorców.

Główne zalety feature są następujące:

• Są opracowywane z uwzględnieniem potrzeb i preferencji użytkowników końcowych, co pozwala zwiększyć ich satysfakcję z produktu.
• Ciągłe dodawanie nowych feature pomaga firmom pozostać w czołówce innowacji technologicznych i konkurencyjności.
• Efektywne i atrakcyjne feature mogą przyciągnąć nowych użytkowników i zwiększyć udział produktu w rynku.
• Dobrze zaplanowane innowacje pozwalają produktowi łatwo dostosować się do zmieniających się wymagań rynkowych i technologicznych.
• Feature mogą znacznie poprawić ogólne postrzeganie i użyteczność produktu.
• Unikalne lub innowacyjne rozwiązania pozwalają produktowi wyróżnić się na tle konkurencji.
• Ciągłe doskonalenie i dodawanie nowych feature może wzmocnić zaufanie i lojalność klientów.
• Skutecznie zaprojektowane funkcje mogą obniżyć koszty wsparcia i konserwacji produktu.
• Dają możliwość otrzymania cennych informacji zwrotnych od użytkowników, które pomagają ulepszyć produkt.
• Rozwój nowych feature może pobudzić kreatywność i innowacyjne podejście w zespole.

Feature jest integralną częścią każdego produktu IT. Zapewniają jej aktualność, odpowiadają potrzebom użytkowników i przyczyniają się do sukcesu produktu na rynku. Ważne jest regularne analizowanie i aktualizowanie feature, aby sprostać zmieniającym się trendom i potrzebom użytkowników.

Co to jest feature w Scrum

Feature w Scrum to konkretna funkcja lub ulepszenie produktu, które należy wdrożyć w ramach sprintu. Elementy te są często formułowane jako historie użytkowników, które opisują pożądaną funkcjonalność z perspektywy użytkownika.

W Scrum feature służą jako podstawa do planowania sprintów i podziału pracy w zespole. Pomagają skupić się na tworzeniu wartości dla użytkownika i wspierają elastyczność w procesie rozwoju.

Zalety feature w Scrum są następujące:

• Koncentracja na wartości dla użytkownika. Pozwala zespołowi skupić się na tworzeniu prawdziwej wartości dla użytkownika.
• Elastyczność i zdolność adaptacji. Feature w Scrum można łatwo dostosować do zmieniających się wymagań lub opinii interesariuszy.
• Zwiększanie przejrzystości. Konkretne rozwiązania zapewniają przejrzystość planowania i śledzenia postępów.
• Poprawa komunikacji w zespole. Jasna definicja feature sprzyja efektywnej interakcji w zespole.
• Przyspieszenie procesu dostawy. Ułatwiają szybszą dostawę produktu.

W Scrum feature jest centralnym elementem planowania i wdrażania pracy. Pomaga zespołowi skoncentrować się na celach użytkownika, zapewniając jednocześnie elastyczność i efektywność tworzenia.

Jak zaimplementować feature w Scrum

Wdrożenie feature w Scrum wymaga zrozumienia zasad Agile i efektywnej interakcji w zespole. Proces wdrażania nowego pomysłu lub funkcji wygląda następująco:

1. Planowanie feature. Wszystko zaczyna się od pomysłu lub wymagania jasno opisanego w formie historii użytkownika. Feature jest oceniana i ustalana w rejestrze produktu w oparciu o jej wartość i złożoność.
2. Tworzenie feature. Zespół wybiera z backlogu nowe pomysły i rozwiązania do wdrożenia w kolejnym sprincie.
3. Projektowanie i wdrażanie. Wykorzystując możliwości zespołu, funkcja jest rozwijana w ramach cykli iteracyjnych obejmujących projektowanie, kodowanie i testowanie.
4. Codzienne spotkania scrumowe. Zespół omawia postępy i rozwiązuje pojawiające się problemy.
5. Zakończenie prac nad feature. Nowa funkcja jest prezentowana zainteresowanym stronom w celu uzyskania opinii. Przeprowadzana jest retrospektywa, zespół analizuje proces pracy nad feature i szuka sposobów na jej ulepszenie.

Wdrożenie feature w Scrum wymaga jasnego zrozumienia wymagań, ścisłej współpracy w zespole i ciągłego dostosowywania się do zmian. Kierownik projektu pełni rolę łącznika pomiędzy pomysłem a decyzją.

Aby pomyślnie wdrożyć feature, wymagana jest wiedza techniczna. W tym celu menedżerowi pomoże Techmind – kurs dla nietechnicznych specjalistów z zakresu IT, który w pełni odkryje przed menedżerem wszystkie aspekty rozwoju. Zobacz program kursu na stronie i złóż wniosek, aby dowiedzieć się więcej o tym, jak Techmind pomaga rozwiązywać problemy menedżerów.

Feature – wdrożyć, czy lepiej nie

Czasami menedżerowie stają przed pokusą wdrożenia zestawu feature lub dostarczenia nowych, po prostu dlatego, że jest to koniecznością, a wiele feature oznacza większą value. Nie zawsze konieczne jest stosowanie tego podejścia, zwłaszcza jeśli nie ma całościowego zrozumienia ewolucji produktu. Jest jednak jeszcze jedna skrajność: wizja produktu „wykuta w kamieniu” – powinniśmy robić tylko to i nic więcej.

Pozostałe dwie skrajności wdrażania nowej funkcjonalności są związane z potrzebami klienta. W jednym przypadku menedżerowie zbyt długo analizują rynek i przegapiają moment, w drugim menedżer ma pewność, że zna potrzeby lepiej niż sam klient.

Jakakolwiek kategoryczność w kwestiach wdrażania feature może tylko zaszkodzić. Dlatego bądź elastyczny, rozważ kwestie z różnych punktów widzenia. Czasami warto po prostu spojrzeć z boku: na przykład, w jaki sposób dana osoba dokonuje zakupów.

Wstępna ocena pomaga uniknąć błędu w wyborze tego, co i kiedy wdrożyć. Analitykę przed feature można podzielić na określone kategorie:

• Rozmiar feature, czas wdrożenia: dzień, tydzień, miesiąc lub feature jest tak duża, że ​​trudno oszacować jej wielkość i wymagane zasoby.
• Komplementarność – czy jakiekolwiek procesy ulegną poprawie, scenariusz pierwotny czy wtórny. Może to zmienić istniejący skrypt lub otworzyć nowy.
• Nowość – czy konkurencja ma coś podobnego, czy też pomysł jest zupełnie nowy i powstał w trakcie burzy mózgów.
• Mierzalność wyniku – jak zmienią się określone wskaźniki. Jeśli chodzi o mierzalność, może być kilka opcji: nie można tego obliczyć, znacznie poprawi to metryki, można poprawić lub można obliczyć wynik, ale nie jest jasne, jaki wpływ ma to na główne wskaźniki.
• Skąd wziął się pomysł na feature: z best practice, od kolegów, ze strony klientów, „szpiegowanie konkurencji”, zrodziło się od samego menadżera, narodziło się w zespole.
• Opracowanie – w jakim stopniu feature jest zrealizowana, dopracowana i na ile jesteśmy gotowi ją rozwinąć. Istnieją różne poziomy opracowania: od „nie jest jasne, jak to zrobić i komu to potrzebne” do „w Jira są zakres obowiązków, plan i zadania”.

Rozumiejąc ogólnie proces tworzenia, menedżer może wyjaśnić ograniczenia lub przekonać klienta do przeznaczenia budżetu na ważne funkcjonalności. Decyzje odnośnie architektury podjęte na samym początku prac z pewnością znajdą odzwierciedlenie w produkcie końcowym. Jeśli więc PM naprawdę chce mieć wpływ na jakość, zrozumienie kwestii technicznych jest niezbędne.