Cześć, dzień dobry. Witam was w podcaście IT i Biznes. Nazywam się Grzegorz Tabor i na co dzień prowadzę trzy firmy, w tym firmę programistyczną, agencję doradczo-rekrutacyjną i SaaS do monitoringu cen konkurencji dla e-commerce. Podcast IT i Biznes kieruję do właścicieli firm oraz menedżerów, którzy na co dzień współpracują w swoich firmach często i dużo z szeroko pojętym IT i chcieliby realizować owe projekty IT bardziej świadomie i skuteczniej. Odcinek 44. Nie tylko kod.

Jak zarządzać technologicznymi aspektami firmy, kiedy nie jesteś osobą techniczną. Czy musisz znać się na kodowaniu, żeby skutecznie zarządzać technologią w swojej firmie? Niekoniecznie. W tym odcinku podpowiadam, jak podejmować świadome decyzje technologiczne, rozumieć ryzyka i unikać typowych pułapek.

W tym odcinku naszego podcastu porozmawiamy o tym, jak zarządzać technologicznymi aspektami firmy, kiedy nie jesteś programistą. Czy też osobą techniczną. Technologia jest dzisiaj kluczowym elementem rozwoju każdej firmy i to nie tylko kod, ale też strategia, która napędza nasz biznes do przodu.

A więc, jak sprawić, by technologia działała na naszą korzyść? Jak zarządzać zespołem IT, nie mając głębokiej wiedzy programistycznej czy też technicznej? W tym odcinku postaram się odpowiedzieć na te pytania, dzieląc się praktycznymi wskazówkami i strategiami, które pomogą Ci lepiej zrozumieć i zarządzać technologicznymi wyzwaniami w firmie. Gotowy lub gotowa? Serdecznie zapraszam. Cześć, dzień dobry.

Witam serdecznie w 44 odcinku mojego podcastu IT Business, w którym to rozprawimy się z tematem zarządzania technologicznymi aspektami firmy, jako osoba nietechniczna. No i właśnie ten podział na osobę techniczną, nietechniczną, to mi się zawsze podoba, a też jednocześnie trochę zawsze się tak uśmiecham, patrzę z przymrzeniem oka na to, bo to jest ciekawe zjawisko, kiedy obserwuje się i osoby techniczne, i osoby nietechniczne, będąc trochę w jednej i w drugiej grupie i widząc z jednej strony, jak osoby techniczne oczekują konkretu zaangażowania i takiego zrozumienia tego, że no ta technologia naprawdę powinna być wiodąca, a z drugiej strony osoby nietechniczne są bardziej nastawione na swoje cele, ale jednocześnie czują taki opór często w komunikacji z osobami technicznymi, po prostu czując, że nadają na innych falach i niekoniecznie chcąc zrozumieć w ogóle tę drugą stronę. Także tutaj jedna i druga strona często do siebie celuje jak z armaty, co jest zupełnie niepotrzebne.

No i trzeba właśnie wybudować sobie taki pomost między jedną a drugą stroną i spróbować się dogadać tak, żeby jednak ten wspólny język znaleźć, bo to jest moim zdaniem podstawa odpowiadając na tytułowe pytanie, jak zarządzać technologicznymi aspektami firmy. Przede wszystkim no właśnie mając wspólny język między osobami technicznymi i nietechnicznymi. No i teraz trochę jest tak, że wielu managerów traktuje IT, czy zespoły IT niejako jako takie zaplecze, czy co gorsza zasoby.

I generalnie jest tak, że to podejście to jest jedna z pierwszych rzeczy, którą trzeba zmienić, jeżeli naprawdę chcemy skutecznie zarządzać obszarami technologicznymi w naszej organizacji. Bo w rzeczywistości technologia jest jednym z kluczowych elementów strategii biznesowej, no bo tak naprawdę nie oszukujmy się, w dzisiejszych czasach bez odpowiedniej strategii IT, bez odpowiedniego podejścia w kontekście IT, bez zrozumienia tego, że cele biznesowe są super istotne i że ta technologia musi na nie odpowiadać. Firma często nie będzie rozwijać się tak szybko, jakby mogła.

No i cóż no po prostu przemyślane wdrażanie i zaplanowane wdrażanie technologii zwyczajnie w świecie wspiera w biznes. To jest mega truizm, ale warto to podkreślić. Z kolei bez odpowiednich narzędzi, bez odpowiednich rozwiązań i bez odpowiedniego podejścia też trudno po prostu firmę rozwijać w sposób efektywny.

I teraz myślę, że warto to podkreślić, żeby to też dobrze wybrzmiało, że technologia nie powinna być traktowana w dzisiejszych czasach jedynie jako wsparcie, tylko powinna być naprawdę integralną częścią strategii biznesowej. Tak jak budujemy strategię marketingową, strategię sprzedażową, strategię HR-ową, to tak samo powinniśmy mieć zbudowaną strategię IT, aby w ramach tej strategii mieć spisane i zaplanowane rzeczy, które powinny się zadziać lub procesy też mieć zmapowane, które powinny się dziać, jeżeli chodzi właśnie o to IT i o tą komunikację między właśnie osobami technicznymi i nietechnicznymi. I w ogóle jeżeli jesteś ze mną od jakiegoś czasu, to na pewno znasz to podejście, w ramach którego staram się mocno podkreślać to, że generalnie zaplanowana strategia IT naprawdę dobrze wspiera cele biznesowe.

Natomiast jeżeli dopiero zaczynasz naszą przygodę i naszą podróż z podcastem IT Biznes, to mam nadzieję, że właśnie od tego momentu zaczniesz patrzeć na tą technologię właśnie w sposób zupełnie inny, czyli jako taki sposób, który ma sprzyjać i wspierać twój biznes, a nie być tylko przykrą rzeczą do wdrożenia, bo konkurencja ma, albo bo wszyscy mają. I teraz generalnie co do zasady, można by odpowiedzieć krótko na to pytanie tytułowe, jak zarządzać technologicznie aspektami firmy, kiedy nie jesteś osobą techniczną? No zatrudniaj osobę techniczną i tak naprawdę niech ta osoba techniczna zarządza, tak? Można by to tak spłycić i podsumować. Natomiast, co jest super istotne, z tym zatrudnieniem osoby technicznej, która ci to będzie wszystko układać w firmie, to jest bardzo różnie, bo tak naprawdę na to, żeby projekt IT realizować, to często się mówi, że potrzeba całego zespołu, no i poniekąd to jest prawda, ponieważ tak naprawdę te projekty IT mają tak dużo różnych odpowiedzialności, że często zespół IT musi liczyć co najmniej kilka osób, żeby wszystkie te odpowiedzialności w ogóle pokryć w pewnym sensie, to znaczy zapewnić to, że wszystkie te odpowiedzialności związane z projektem będą zapewnione.

I teraz, żeby dobrze się komunikować z drugą osobą, warto ją poznać, więc żeby się dobrze komunikować jako osoba nietechniczna z zespołem IT, z zespołem wewnętrznym czy zewnętrznym, bez znaczenia, ale chodzi o to, że jako osoba nietechniczna z osobami technicznymi, to dobrze jest poznać rolę osób w zespole IT, jakie po prostu mają i za co dana osoba w danej roli odpowiada. No i tak idąc przez takie najważniejsze role, jakie sobie tutaj na dzisiaj zapisałem, kolejność jest tak naprawdę przypadkowa, bo chodzi o to, żeby te role po prostu były zawarte wszystkie, te które akurat tutaj wymieniłem, co ważne, czy które sobie zapisałem, a które zaraz Wam wymienię, natomiast co do zasady nie chodzi o to po pierwsze, która jest ważniejsza, która mniej ważna, bo tutaj każda z tych roli jest podobnie ważna, można powiedzieć i to też za chwilkę nam wyjdzie dlaczego. Po drugie, ważne jest przede wszystkim to, żeby zapamiętać, że w istocie jedna osoba może pełnić kilka ról i to też jest istotne i bardzo często jest tak, że właśnie kiedy w firmach są mniejsze zespoły IT, to właśnie one pełnią jakby pojedyncza osoba w tym zespole pełni na przykład role, nie wiem, dwie, trzy, za które odpowiada, czy bardziej obszary za które odpowiada.

No i teraz jakie to są te role? Już wymieniam i wyjaśniam. Jedna z ról jaką mam zapisaną to rola CTO, czyli Chief Technology Officer, czyli dyrektor technologiczny, osoba, która jest odpowiedzialna za strategiczny rozwój technologiczny Twojej firmy. I ten CTO, czyli ten dyrektor technologiczny, powinien ustalić kierunek, w jakim ma podążać Twoja firma w obszarze technologicznym, biorąc pod uwagę jej cele biznesowe przede wszystkim.

I to powinna być osoba, która będzie podejmowała finalne decyzje o wyborze technologii, decyzje o architekturze systemów, decyzje o długofalowej wizji rozwoju technologicznego. Więc jeżeli chodzi o kwestie aspektów wizji, strategii IT w Twojej firmie i takie ogólne podejście z serii, jak nasza firma powinna technologicznie być przygotowana, unormowana, jak powinna działać od strony technologii, to CTO jest osobą, która to powinna poukładać. Teraz idąc dalej, kolejną z ról, którą mam wypisaną to jest Tech Lead.

Tech Lead to jest z reguły w zespole osoba, która odpowiada za nadzorowanie i realizację projektów technologicznych właśnie od strony technicznej. I teraz Tech Lead często zarządza zespołem programistów, czyli sprawdza w jaki sposób kod jest zaprogramowany, czy rozwiązania są efektywne, czy będą skalowalne, czy są realizowane zgodnie z planem, z przyjętą ustaloną wcześniej CTO architekturą i też strategią. Więc wszelkie pytania dotyczące implementacji, szczegółów technicznych czy też problemów z konkretnymi na przykład rozwiązaniami, no to właśnie Tech Lead na takie rzeczy powinien tutaj odpowiadać.

Teraz kolejna taka rola, którą zapisałem to Product Manager, czyli osoba, która jest odpowiedzialna za rozwój produktu. Często jakby staramy się budować aplikacje w taki sposób, że nazywamy je różnymi produktami w zależności od tego za jaki obszar biznesowy na przykład one odpowiadają. W przypadku na przykład sklepu internetowego może być tak, że firmy jakby bardziej e-commerce'u może być tak, że sklep internetowy to jest jeden produkt, na przykład jakiś PIM, czyli system do zarządzania produktami to będzie inny produkt.

Jakiś osobny mikroserwis do wyszukiwania to będzie jeszcze inny produkt i tak dalej i tak dalej. Czyli takie obszary produkty, czyli takie obszary biznesowe zaopiekowane poprzez poszczególną aplikację możemy sobie to nazwać produktem. Taki Product Manager dba o to, żeby zarządzić całym cyklem życia produktu tak zwanym od pomysłu, czyli od tego, że chcemy nową wyszukiwarkę zróbmy to przez implementację aż po wdrożenie i dalszy rozwój tego konkretnego produktu.

I ten Product Manager jest niejako takim mostem między zespołem technicznym a rynkiem. Tak jak CTO jest mostem trochę między biznesem a całym zespołem technicznym tak tutaj znowu Product Manager pośredniczy trochę między zespołem technicznym a stricte rynkiem. Więc jeżeli interesują Cię kwestie dotyczące produktu, wymagania użytkowników, różnych funkcjonalności w tym danym produkcie no to ten Product Manager jest osobą, która za takie rzeczy właśnie w zespole powinna odpowiadać.

Idąc dalej, Project Manager. Project Manager to osoba, która łączy te wszystkie światy w całość a na koniec zapina je jeszcze w tak zwany budżet, w harmonogram, w terminy i wyznacza priorytety. Czyli to jest osoba, która koordynuje całokształt prac nad projektem czy też projektami, które w wyniku opracowanej strategii CTO mogą wyniknąć.

I to jest osoba, która dba o to, żeby te projekty były właśnie zrealizowane, żeby je dowieść w cudzysłowie, żeby ewentualne blokery z zespołem na bieżąco wyjaśniać. Nie jest to łatwa rola, trzeba być tego świadomym, bo często Project Manager jest pierwszą osobą kontaktową dla klientów i też pierwszą osobą kontaktową dla zespołu i trochę jest po środku i potrzeb, oczekiwań interesariuszy i dostępności, możliwości zespołu i oczekiwań, nie wiem, zarządu czy na przykład CTO w zespole, który z takim Project Managerem współpracuje. Także naprawdę niełatwa rola.

I tutaj chapeau bas dla wszystkich Project Managerów, którzy faktycznie są w stanie na przykład łączyć swoją rolę też na przykład z jeszcze jakąś inną rolą no i faktycznie dopinać te tematy i z zespołem, i z klientami, i w ogóle z interesariuszami. Naprawdę szacun. Teraz idąc dalej, jeżeli chodzi jeszcze o inne role.

Oczywiście programiści, czyli to jest taka rola, która jest najczęściej spotykana i widzicie, dopiero teraz o niej mówię tak naprawdę, bo zdarza się, że widzimy, że w firmach ludzie mają podejście, że właśnie są aspekty techniczne do zarządzania. Zatrudnię programistę, który będzie mi doradzał. Czy to jest dobra droga czy nie, to jeszcze sobie wrócimy do tego tematu.

Natomiast programiści to są oczywiście osoby, które tworzą kod, tworzą rozwiązania, programują je, wdrażają technologiczne aspekty projektu. Są odpowiedzialni za to, żeby zaimplementować wymagania według specyfikacji, które sobie wcześniej ustalają z product managerem, zgodnie ze wskazówkami od TechLeada i zgodnie ze strategią i takim, powiedzmy, bazowym workflow wypracowanym z CTO, czyli z tym dyrektorem technologicznym. No i tutaj oczywiście komunikacja, szczególnie w kontekście konkretnych już spraw, bo to tak naprawdę od tego, jak programista coś zaprogramuje, będzie mocno zależało, jak coś będzie działało już finalnie, albo na przykład wyglądało, jeżeli to jest programista frontendowy.

Więc to tutaj pod tym kątem komunikacja z tą osobą jest zasadna. Idąc dalej mamy UX i UI designerów, czyli osoby, które dbają o to, żeby użytkownicy byli zadowoleni z aplikacji, z których korzystają, czy na przykład, żeby klienci chętniej kupowali w sklepie, czuli się w nim jeszcze lepiej po prostu. UI designerzy, czyli właśnie UX to jest ta warstwa taka doświadczeniowa, UI to warstwa już prezentacji pokazująca konkretne interfejsy, jak one będą wyglądały.

Kolejna grupa często niedoceniana to są testerzy. Jeżeli chodzi o testerów i tutaj tą rolę testerską, no to właśnie każdy projekt IT powinien w swoim zespole, którego realizuje, mieć testerów, czy też testera, po to, żeby właśnie wszystkie rzeczy, które się gdzieś tam pojawiają na linii, że programista na przykład u siebie lokalnie czegoś nie znalazł, zostały wyłapane na środowisku testowym, a przynajmniej ich zdecydowana większość, i żeby projekt nie musiał być później przez klienta testowany, tylko żeby był odbierany. Jaka jest różnica dla klienta między testowaniem, a odbieraniem projektu, to opowiadałem w odcinku poprzednim, czterdziestym trzecim, także jeśli interesuje Cię ta dygresja i ten temat, to serdecznie tam też do odcinka czterdziestego trzeciego zapraszam.

No i kończąc kwestie ról, mamy jeszcze dwie, które z mojej perspektywy są ważne, bo wcześniej pokryliśmy sobie kwestie strategii, kwestie organizacyjne, kwestie produktu, kwestie technologiczną i jej napisania, kwestie makiet i UX-u, kwestie tego, żeby ktoś to finalnie przetestował, i pozostają nam jeszcze dwie role, które są takie trochę połączone z tym, na jakich serwerach będzie stała aplikacja, czy dane rozwiązania. Mianowicie jest to rola saas admina, czyli osoby, która zarządza wszelkimi systemami, infrastrukturą, rozpisuje, czy po prostu organizuje rzeczy na serwerach. I DevOps, i tutaj jest ciekawostka, bo teraz czym się różni saas admin od DevOps-a? No DevOps jest osobą lub na przykład zespołem, ale tutaj przyjmijmy, że to jest osoba, która po prostu odpowiada za sprawne działanie systemów IT i procesów wdrażania oprogramowania w firmie.

I osobą taką, czy zadaniem takiego DevOps-a, jest łączenie pracy programistów z zespołem operacyjnym, czyli osobami, które dbają o infrastrukturę. Czyli takie trochę łączenie sysadminów z programistami. Często jest tak, że w firmach na przykład DevOps jest jednocześnie też saas adminem, więc to też takie tutaj można przyjąć założenia.

Żeby lepiej zrozumieć rolę DevOps-a w przypadku zespołów IT, wyobraź sobie restaurację i wyobraź sobie, że programiści to kucharze, którzy tworzą nowe przepisy, czy innymi słowy piszą kod. Zespół operacyjny to kelnerzy, menedżerowie restauracji, którzy dbają o to, żeby dania były podawane na czas i wszystko działało sprawnie. I to jest odpowiednik serwerów, sieci i systemów IT.

A DevOps to jest taka osoba, która sprawia, że kucharze i obsługa współpracują ze sobą bez problemów. Kuchnia działa płynnie, klienci dostają zamówienia na czas, cieplutkie, gotowe. To jest właśnie rola DevOps.

Czyli DevOps zajmuje się automatyzacją, monitorowaniem i zapewnianiem, żeby nowo stworzone funkcje aplikacji szybko i bezproblemowo trafiały do użytkowników. I dzięki takiej osobie te systemy IT powinny działać stabilnie i zmiany powinny być wprowadzane bez przestojów i bez błędów. No i jak sam widzisz lub sama widzisz, jest tych odpowiedzialności całkiem sporo i tych ról też.

No i teraz bardzo trudno jest to zorganizować one-man army. To znaczy, trudno jest, łatwo. Łatwo jest to zrobić, jeżeli tych osób w zespole jest kilka.

Trudno jest to zrobić, jeżeli na przykład jest tylko jedna czy dwie osoby. Teraz, jako że projekty IT generalnie raczej są złożone, no bo składają się z jakiegoś kodu czy jakiegoś rozwiązania bazowego. Składają się z jakiejś analizy przedwdrożeniowej, składają się ze zbieraniem ustaleń wielu stron interesariuszy.

Takie projekty IT składają się z infrastruktury serwerowej, z różnych powiązań ludzko-organizacyjno-firmowych. Tak naprawdę składają się jeszcze też z różnych kwestii prawnych typu licencje, jakieś umowy wszelkiego rodzaju, czy też składają się na przykład z projektu graficznego, a do tego muszą jeszcze spełnić określone założenia biznesowe i tym samym też realizować określone cele biznesowe. No to tutaj serio zespół mający pokryte wszystkie te role, to jest bardzo duży potencjał i dużo większa szansa, że to się uda, jeżeli ten zespół jest też kluczowo dobrze zarządzany.

I teraz zdarza się, że dla uproszczenia buduje się zespoły, gdzie jedna osoba ma kilka ról, tak jak wspomniałem wcześniej. I o ile na początku to jest bardzo dobre rozwiązanie, o tyle warto wiedzieć, gdzie jest sufit tego, że dana osoba będzie w stanie faktycznie dwie lub na przykład trzy role spełnić i mieć to ujęte w takim planie długoterminowym, czy też właśnie wojsk strategii, do kiedy takie rozwiązanie, czy zespół z tak rozdzielonymi kompetencjami, rolami, będzie po prostu działał sprawnie. Standardowo te procesy IT, różne wdrożenia i tego typu rzeczy przekazuje się zwyczajnie do zespołu IT.

Jeszcze wracając do naszego tytułowego pytania. Jako osoba nietechniczna, jeżeli chcesz, a na przykład nie mając CTO w swoim zespole, jeżeli chcesz zarządzać tym obszarem technologicznym, to powinieneś bądź powinnaś mimo wszystko opierać się mocno na bazie wiedzy swojego zespołu. Lub jeżeli masz CTO, to możesz po prostu tego CTO dopytać.

I teraz, kto powinien podejmować strategiczne decyzje biznesowe? Czy zespół, czy konkretny programista, czy CTO? No i teraz z tego właśnie trochę pojawia się odpowiedź na częste pytanie, czy programiści to najlepsze osoby, które powinny podejmować strategiczne decyzje technologiczne. No i teraz z mojej perspektywy często jest tak, że programiści oczywiście mają bardzo dużo różnych doświadczeń. Często jest tak, że to są programiści, którzy zrealizowali dużo różnych projektów, ale teraz bardzo rzadko spotyka się programistów, którzy bardzo mocno zwracają uwagę na biznes i którzy poświęcą technologię dla biznesu niejako.

A teraz z perspektywy patrzenia strategicznego trzeba bardzo mądrze podejść do tego, żeby ocenić jak to IT w naszej firmie powinno wyglądać. Które obszary, które działy potrzebują IT super stabilnego, gdzie warto doinwestować to IT, warto zadbać o jeszcze lepszy monitoring, jeszcze szybsze czasy reakcji i jeszcze lepsze systemy po prostu, które działy w firmie na przykład mogą działać z trochę gorszej klasy systemami z mniejszym czasem SLA, czyli po prostu dłuższym czasem reakcji na awarię, bo nawet jeżeli tam coś nie zadziała, to po prostu jesteśmy w stanie z tym żyć. Czyli chodzi mi o to, że jeżeli chcemy szukać kompromisów i podejmować tego typu strategiczne decyzje biznesowe, bo jak na przykład budżet na IT rozdzielić per działy, per potrzeby, no to uważam, że tego typu decyzje należałoby podjąć po pierwsze biorąc pod uwagę oczywiście opinię wszystkich osób w zespole, chyba że ten zespół jest super dużo, no to wtedy tych najważniejszych w cudzysłowie osób w zespole albo przynajmniej najbardziej doświadczonych, ale koniec końców to jedna osoba w firmie powinna odpowiadać za tą finalną decyzję strategiczną od strony technologii, która dla biznesu będzie kluczowa i za to powinien odpowiadać CTO.

Tutaj innej drogi moim zdaniem nie ma. Jeżeli w ogóle szukasz wsparcia w takich trudnych i skomplikowanych problemach IT albo chciałbyś bądź chciałabyś zasięgnąć takiej niezobowiązującej porady osoby z zewnątrz, to śmiało skontaktuj się ze mną, chętnie zerknę na twój konkretny przypadek i podpowiem, co by można było w tej konkretnej sytuacji zrobić. No ale dobra, to tutaj taka mini autoreklama, natomiast jeżeli nadal jako osoba nietechniczna, nie mając w zespole CTO, chcesz poskromić swój zespół IT albo zespół zewnętrzny i chcesz dopytać o konkrety, to właśnie w drugiej części tego odcinka chętnie podpowiem Ci taką listę pytań, jakie z pewnością warto zadać.

I przede wszystkim, jeżeli już wiemy, do kogo kierować pytania, bo z grubsza wiemy, kto w zespole za co pewnie odpowiada, to zastanówmy się, jak prawidłowo pytania zadawać. Według mnie kluczowe jest to, żeby przede wszystkim nastawić się na mindset, ja to nazywam takiego małego dziecka, bardzo ciekawego, czy ciekawskiego w tym sensie. Potrzebne jest takie zadawanie pytań i taka ciekawość w tym obszarze i też otrzymywanie wersji zwrotnej jak dla pięciolatka i też komunikowanie tego.

I możecie się ze mnie tutaj śmiać, ale serio otwartość na zadawanie pytań i próba zrozumienia, taka szczera chęć zrozumienia bardzo mocno wspiera proces komunikacji na linii IT i biznesu. I oczywiście nie chodzi o bycie infantylnym, to zupełnie nie to mam na myśli, tylko chodzi o wzajemne zrozumienie i szacunek do swojego podejścia i do tej inności między osobami technicznymi i nietechnicznymi, jakkolwiek to nie brzmi. I przy tym jednak chodzi o to, żeby zachować tą szczegółowość i to zrozumienie, żeby ono się pojawiło.

I teraz a propos tej szczegółowości i zrozumienia, pytania ogólne, typu czy to działa, czy np. pytania o to, jaki jest status danej sprawy, czy pytania z serii w ogóle, na które da się odpowiedzieć tak lub nie, raczej bym ich unikał, bo one z reguły, jeżeli chodzi o kontakt z osobami technicznymi, sprawiają, że osoby techniczne będą szybko je próbowały zbyć, bo nie będą czuły sensu, żeby na nie odpowiadać. To może się tak wydarzyć.

Natomiast jeżeli zaczniemy zadawać pytania, które będą wymagały trochę więcej odpowiedzi, takiej w sensie bardziej już szczegółowej, jeżeli będziemy dążyć do tego, żeby uzyskać taki pełniejszy obraz, jeżeli będziemy dopytywać i koniec końców jako osoba nietechniczna zrozumiemy tę drugą perspektywę i nastawimy się na rozwiązywanie różnych sytuacji, no to wówczas powinniśmy być w stanie po tych pytaniach przede wszystkim móc chociaż przynajmniej na jakichś przykładach, porównaniach zrozumieć co jak działa i dzięki temu też czuć się pewniej z danym zespołem, czy to wewnętrznym, czy zewnętrznym, że po prostu tematy są zaopiekowane i idą dobrze. I teraz listę pytań, które warto zadać podzieliłem na 7 kategorii. To są pytania, to są obszary, różnie można do tego podejść.

Natomiast co do zasady jest 7 kategorii i oto one. Pierwsza kategoria to pytania o ryzykach technologicznych. Czyli na przykład, jakie są potencjalne ryzyka związane z tą konkretną technologią? Jak te ryzyka możemy zminimalizować? Podpowiem, że warto sobie jako osoba nietechniczna zapisywać na kartce te ryzyka, no i po prostu zapisywać też obok jak będziemy z tymi ryzykami pracować.

Czy ta technologia jest skalowalna w kontekście przyszłego rozwoju firmy? Czyli też jakby przyjmijmy sobie wizję na przykład jakąś tam dalszą typu za 2-3 lata. Gdzie chcielibyśmy być jako firma? Jako też, jako ta osoba nietechniczna na przykład z marketingu. Ile leadów planujemy generować? Jaki ruch na stronie? Czy jaki ruch w sklepie? Teraz czy ta technologia wytrzyma ten ruch, czy nie wytrzyma? Przy jakich zasobach serwerowych? No tutaj warto też sobie pod tym kątem zacząć szukać powiązań w tego typu pytaniu.

I odnośnie samej technologii infrastruktury też po prostu dopytywać. Dopytywać i dopytywać. I bez oporów dopytywać.

Druga kategoria to pytania o zgodność z wymogami biznesowymi. Czyli przyjmuję założenie, że jeżeli jesteśmy przedstawicielami biznesu nietechnicznymi to mimo wszystko jakieś wymogi biznesowe jesteśmy w stanie sobie zdefiniować samodzielnie i spisać. Ewentualnie zrobić to na przykład z pomocą product ownera czy na przykład analityka biznesowo technicznego czy po prostu analityka biznesowego.

To też jest kwestia do ustalenia i to też różnie w firmach wygląda. I teraz warto tę daną rzecz, którą chcemy zaudytować w ten sposób, podpytać pod kątem na przykład jakie korzyści biznesowe ta technologia będzie przynosiła firmie w krótkim i długim okresie. Czyli co się zdanie zaraz po wdrożeniu i co się będzie działo na przykład za dwa lata.

Jakie to będą korzyści biznesowe? Czy ta technologia jest zgodna z naszą wizją rozwoju i celami strategicznymi na najbliższe lata? Ktoś może odpowiedzieć tak, jest albo nie, nie jest ale też w jakich obszarach jest zgodna. Tutaj można sobie jeszcze dopytać. Też przedstawiając cele strategiczne można się zastanowić i do tego do sobie po prostu podłączyć te właśnie konkretne takie technologiczne.

Czyli na przykład jeżeli naszym celem jest to żeby system był ładniejszy, bo chcemy inaczej naszym celem takim biznesowym jest to, że chcemy na przykład zwiększyć sprzedaż z jakiegoś powodu. I teraz wiemy o ile ją chcemy zwiększyć. I wiemy, że na przykład jednym z powodów dla którego ktoś nie kupuje jest na przykład stary wygląd systemu to logicznym jest, że powinniśmy zaplanować wdrożenie nowego wyglądu tego systemu.

Natomiast to czy powinniśmy od razu robić pełny nowy wygląd tego systemu czy tylko jakiś delikatny lifting no to znowu jest kwestia bardzo tutaj do ustalenia i do właśnie zastanowienia się czy ta technologia jest zgodna z naszą wizją rozwoju. Czyli na przykład to podejście w kontekście technologicznym będzie zgodne z naszą wizją. No i jak to będzie po prostu tutaj działało w tym konkretnym obszarze teraz i jak to będzie wyglądało w przyszłości.

Ok. Kolejna kategoria pytań to pytania o wdrożenie i implementację. Czyli kto będzie potrzebny do wdrożenia tej technologii.

Osoby z jakimi rolami czy mamy te osoby w naszym zespole czy będziemy potrzebowali osób z zewnątrz. Jakie są szacowane terminy jakie są szacowane czasy realizacji. Jakie wyzwania mogą się pojawić w trakcie implementacji.

Jakie przeszkody mogą się pojawić. Jakie mamy plan powiedzmy tutaj na ich rozwiązanie. Co może przestać działać.

Jakie są ryzyka w obszarze tutaj które trzeba też przetestować. Czyli co może się wydarzyć w kontekście niedziałania. Jak biznes będzie pracował jeżeli okaże się że wdrożenie zostało wykonane niepoprawnie.

Też warto sobie odpowiedzieć na takie pytanie. Kolejna kategoria to pytania o kosztach i o utrzymaniu. Czyli jakie będą koszty utrzymania tej technologii.

Podpowiem że warto tutaj sobie też wylistować zakres czynności jakie będą wykonywane i na tej podstawie też ocenić koszty utrzymania. Na przykład czy istnieją jakieś ukryte koszty przed którymi tutaj powinniśmy być świadomi i powinniśmy się też zabezpieczyć. Tu mam na myśli po prostu koszty które do tej pory nie były przedstawiane np.

na poziomie ofertowania. To też jest rzecz którą należałoby sprawdzić. Warto zapytać jaką mamy np.

gwarancję po wdrożeniu. Jeżeli to jest zewnętrzna firma której takowej gwarancji udziela. Kolejna kategoria to pytania o kompatybilności i o integracjach.

Czyli czy ta technologia którą sobie wdrożymy będzie dobrze połączyć się z naszymi systemami. Innymi słowy ktoś nam powie że tak będzie dobrze więc dopytujmy w jaki sposób będzie integrować dane. Jak te dane będą przesyłane.

Możemy sobie zmapować po prostu to jak te dane będą przesyłane i potwierdzić czy one faktycznie tak tutaj wykonawca czy zespół to widzi. Czy istnieją potencjalne problemy z integracją tej technologii z naszymi obecnymi rozwiązaniami. Innymi słowy czy nasze obecne rozwiązania mają jakieś interfejsy według których można się z nimi komunikować.

Ale też czy ta nowa technologia jaką wdrażamy ma interfejsy dzięki którym jesteśmy w stanie te dane wymieniać. Jakie tutaj mogą się jeszcze pojawić ryzyka bo to jest istotne. Zadanie pytania otwartego jakie mogą się pojawić problemy jakie mogą się pojawić ryzyka i spisywanie tego jako osoba nie techniczna naprawdę polecam bo to bardzo mocno otwiera głowę i pokazuje że często wychodzą rzeczy które wyszłyby dopiero później na etapie wdrożenia.

No a można jednym pytaniem zaoszczędzić na przykład 30 tysięcy złotych pracy zespołu. Naprawdę polecam. Kolejna kategoria przedostatnia jeżeli chodzi o pytania to pytanie o bezpieczeństwo oczywiście.

Czyli jakie mechanizmy zabezpieczeń będą wybudowane, wdrożone. Jakie są ryzyka związane od strony bezpieczeństwa z tą technologią. Na ile ten system jest bezpieczny który wdrażamy.

Czy jest na przykład wdrożona dwuetapowa weryfikacja. Czy jest na przykład system zgodny z RODO. Czy w ogóle jeżeli chodzi o przepisy prawa to wszystko jest zadbane.

To też warto na przykład zasięgnąć porady czy to jakiejś kancelarii prawnej która przygotuje pewne kryteria odbioru od strony bezpieczeństwa na co trzeba szczególną uwagę zwrócić. No i o to warto też po prostu dopytać. Ostatnia kategoria pytań to kategoria pytań o przyszła aktualizacji i o rozwój.

Czyli na przykład jakie będą plany dotyczące tej wdrażonej technologii w przyszłości. Jakich nowych funkcjonalności możemy oczekiwać. Kto zadba o to żeby te nowe funkcje faktycznie sprawdzać czy są i czy powinniśmy je wdrażać do firmy jeżeli korzystamy z jakiegoś gotowego oprogramowania.

Kto będzie zarządzał procesem zmiany. Czyli kto będzie dbał o to żeby ludzie byli doinformowani co się dzieje w ramach danego projektu i w jaki sposób powinniśmy do tego podchodzić. Czy jest w ogóle do tej pory jakaś planowana aktualizacja dla danej technologii.

Jaka to jest wersja. Czy najnowsza. Kiedy ta wersja powstała.

No bo jak na przykład to jest najnowsza wersja ale system był ostatnio aktualizowany 6 lat temu to może być taki średni pomysł jeżeli chodzi o jego wykorzystanie. Niejako. No i cóż.

Dzięki tego typu pytaniom uzyskujemy naprawdę dokładniejsze informacje na temat technologii na temat danego projektu jego wpływu na firmę. No i też wyzwań jakie mogą się pojawić na przykład podczas jego wdrożenia. I jeżeli jesteś teraz w tym momencie słuchanie odcinka i myślisz że to nie dotyczy ciebie bo przecież nie masz własnego zespołu IT a korzystasz z zewnętrznych programistów na przykład z software house'u czy współpracujesz z zewnętrznymi programistami po prostu z zewnętrznego software house'u to nic bardziej mylnego bo te zasady te pytania obowiązują zarówno wtedy kiedy współpracujesz z zespołem in house jak i wtedy gdy polegasz na zewnętrznej pomocy.

Zespół to zespół i bez względu na to kto zajmuje się technologią w twojej firmie te kluczowe pytania dotyczące ryzyk kosztów czy implementacji powinny być zadawane serio w każdym modelu współpracy i to tak naprawdę jeżeli masz zespół w którym faktycznie jest dostępny CTO z którym możesz porozmawiać i który zadbał już o takie rzeczy albo powinien zadbać no to oczywiście warto tego CTO to jeszcze sobie podpytać wyjaśnić mieć pewność że ma to pod kontrolą natomiast jeżeli w zespole CTO nie ma i to ty bierzesz na swoje barki jako osoba nietechniczna właśnie zarządzanie trochę tym zespołem upewnienie się że zespół ogarnia w cudzysłowie mówiąc mówiąc wprost no warto wtedy z tych pytań z pewnością skorzystać jeżeli chciałbyś bądź chciałabyś uzyskać te pytania w formie pisemnej albo na przykład jeszcze jakąś konkretną sytuację przeanalizować serio napisz chętnie podpowiem pomogę zupełnie zobowiązująco. I okej przechodząc do podsumowania dzisiejszego odcinka bo się troszkę rozgadałem. Omówiliśmy według mnie kluczowe aspekty które pomogą Ci jako osobie nietechnicznej skutecznie zarządzać obszarem technologicznym czy w IT generalnie w Twojej firmie.

Jak widzisz nie musisz być ekspertem od kodowania. Natomiast Twoją rolą jako menadżera jest przede wszystkim rozumienie konsekwencji podejmowanych decyzji identyfikowanie ryzyk poprzez zadawanie właśnie odpowiednich pytań. Jeśli zajdzie taka potrzeba to konsultowanie się aby podejmować świadome wybory.

Z mojej perspektywy ta lista pytań którą omówiliśmy w dzisiejszym odcinku to takie serio mocno pomocne narzędzie. Mocno pomocne narzędzie tak. I dzięki tej liście pytań możesz serio zadając te pytania i drążąc tematy możesz dużo lepiej zrozumieć z czym mierzy się Twój zespół.

Czego też powinieneś bądź powinnaś wymagać od swojego zespołu czy też od partnera technologicznego zewnętrznego. Także serio zachęcam Cię do zastosowania tych pytań czy w obecnym projekcie który prowadzisz czy w przyszłym. Bo to niekoniecznie trzeba te pytania zadawać w fazie przedwdrożeniowej.

Można je też zadawać w trakcie wdrożenia. Jeżeli czujesz taką potrzebę zwyczajnie żeby podrążyć te tematy to myślę że te pytania z tych siedmiu kategorii które wymieniłem serio warto zadać. I teraz jeżeli na te pytania dostaniesz konkretne odpowiedzi to świetnie i to jest znak że Twój zespół w cudzysłowie ogarnia, wie co robi.

Twój partner na przykład jeżeli to jest firma zewnętrzna dobrze rozumie projekt dobrze rozumie założenia i panuje nad sytuacją. Jeżeli w odpowiedzi usłyszysz to zależy bez konkretnego wyjaśnienia będziesz czuć że coś nie gra to serio to będzie do Ciebie sygnał ostrzegawczy że to serio też wymaga doprecyzowania czy też po prostu przemyślenia. I w tego typu sytuacji myślę że warto na chwilkę zatrzymać projekt na kilka dni, zebrać ten cały zespół, podzielić się swoimi przemyśleniami, obawami i upewnić się że zespół odpowiedział na nie w taki sposób który Cię satysfakcjonuje i który powoduje że faktycznie te obawy zostaną rozwiane po prostu.

Bo zarządzanie technologią to nie jest tylko wybór narzędzi czy modelu współpracy ale przede wszystkim umiejętność stawiania właściwych pytań wyciągania wniosków i realizacji dzięki temu dobrze celów biznesowych. Jeśli masz ochotę na więcej takich rozmów to daj znać jak chętnie przygotuję kolejne odcinki które pomogą Ci się lepiej i jeszcze lepiej odnaleźć w świecie technologii i biznesu. W podziękowaniu ogromnym za wytrwanie do końca dzisiejszego odcinka bo jest to jeden z dłuższych odcinków jakie tutaj wypuszczam w ramach IT Biznes Zaspojleruję bardzo chętnie że kolejny odcinek będzie przede wszystkim o tym jak pracować z zespołami IT w kontekście jakie wskaźniki jakie KPI można ustawić, jakie można łatwo mierzyć w jaki sposób właśnie porozumieć się z IT językiem IT czyli właśnie poprzez konkretne liczby, wskaźniki ale też przedstawię szereg kolejnych porad jak współpracować z zespołami in-house a jak też współpracować z zespołami zewnętrznymi.

Jeżeli interesują Cię tego typu treści to pamiętaj proszę o zostawieniu subskrypcji, łapki w górę w miejscu gdzie aktualnie słuchasz mojego podcastu a tymczasem bardzo Ci dziękuję drogi słuchaczu droga słuchaczko za dzisiaj no i do usłyszenia za tydzień we wtorek. Cześć!