Nowy projekt to wielkie emocje - zar贸wno te pozytywne, jak i te stresuj膮ce. Z jednej strony cieszymy si臋, 偶e dostali艣my szans臋, 偶e b臋dziemy mogli nabra膰 komercyjnego do艣wiadczenia, ale z drugiej strony pojawiaj膮 si臋 obawy - czy na pewno damy rad臋? Czy klient b臋dzie zadowolony? Czy uda si臋 wsp贸艂praca z zespo艂em?
Pocz膮tki, pierwsze dni, w projektach s膮 r贸偶ne. Z du偶膮 doz膮 prawdopodobie艅stwa mog臋 napisa膰, i偶 ka偶dy projekt oraz ka偶da firma to zupe艂nie inne podej艣cie do takich temat贸w. Ci臋偶ko zatem w kilku s艂owach opisa膰 jak to mo偶e wygl膮da膰. Napisz臋 zatem o swoim w艂asnym do艣wiadczeniu, a reszt臋 pozostawi臋 ju偶 Waszej wyobra藕ni i zdolno艣ci logicznego my艣lenia.
Swoj膮 karier臋 zaczyna艂em jako QC - zwyk艂y klikacz, kt贸ry zna艂 ju偶 projekt (wcze艣niej pracowa艂em przy pomocy technicznej tej aplikacji, zatem zna艂em j膮 od podszewki). Po kilku rozmowach z moim mentorem, otrzyma艂em dost臋p do Phabricatora (to taka troszk臋 inna Jira, ale projekt nie jest ju偶 rozwijany), gdzie mia艂em dost臋pne zadania - moja praca polega艂a na sprawdzaniu czy uda艂o si臋 naprawi膰 bugi. Po kilku dniach zacz膮艂em wykonywa膰 testy eksploracyjne aplikacji oraz sprawdza膰 nowe funkcjonalno艣ci - czy zosta艂y poprawnie wdro偶one, czy nie zawieraj膮 b艂臋d贸w, czy s膮 u偶yteczne, po prostu - czy da si臋 z nich korzysta膰. Je偶eli napotka艂em jaki艣 b艂膮d, zg艂asza艂em to do mentora, ten to ze mn膮 odtwarza艂 i je偶eli uzna艂 to za stosowne, zg艂asza艂em to do Phabricatora. Na tym moja rola si臋 ko艅czy艂a - ot, zwyk艂y tester.
Z czasem jednak trafi艂em do nowej firmy i do projekt贸w dla klient贸w. Po wdro偶eniu si臋 do firmy, mia艂em kilka "testowych projekt贸w". O pierwszym prawdziwym dowiedzia艂em si臋... nagle. Przychodzi pewna osoba i m贸wi do mnie "chod藕, za 5 minut mamy rozmow臋 z klientem, to b臋dzie Tw贸j projekt". Klient ze Stan贸w Zjednoczonych, wi臋c nie do艣膰 偶e pierwszy prawdziwy projekt (jako QA, nie QC), to jeszcze pierwsza rozmowa z klientem i do tego pierwsza powa偶na rozmowa po angielsku. Nigdy tego nie zapomn臋 馃槈 Mo偶e kiedy艣 opowiem troch臋 wi臋cej o tej rozmowie, ale teraz wr贸膰my do tematu. Ustalili艣my flow, logik臋 aplikacji i naszym pierwszym zadaniem by艂o okre艣lenie organizacji pracy (spotkania - kiedy i jakie). Podczas tego spotkania od razu zasugerowa艂em pierwsze wa偶ne kwestie - jaki flow zada艅 w Jirze, jak rejectujemy zadania, do kogo je przypisujemy oraz ustalenia dotycz膮ce Definition of Ready oraz Definition of Done. Zada艂em r贸wnie偶 kilka dodatkowych pyta艅 - co z notatkami ze spotka艅 (kto, jak, w jakiej formie), jak dzielimy si臋 prezentowaniem aplikacji przed klientem po ka偶dym sprincie, jak dzielimy si臋 wyci膮ganiem wymaga艅 od klienta (uf, PM wzi膮艂 to najtrudniejsze zadanie 馃槄). OK. Sprawy organizacyjne ustalone, to teraz kwestia ustalenia co dok艂adnie robimy - planowanie dzia艂a艅, priorytetyzacja widok贸w/sekcji w aplikacji, brak design'贸w - co z tym robimy oraz par臋 innych temat贸w. Gdy zacz臋li艣my dzia艂a膰, mog艂em skupi膰 si臋 na testowaniu pierwszych funkcjonalno艣ci (tak, QA r贸wnie偶 testuje 馃槈), sugerowaniu improvement贸w, a w mi臋dzyczasie tworzeniu test case'贸w - wtedy jeszcze w Excelu/Wordzie. Projekt z jednej strony nie by艂 skomplikowany - flow by艂o wzgl臋dnie logiczne, by艂o troch臋 miejsca na par臋 usprawnie艅, niewielka ilo艣膰 papierkologii (jeden plan test贸w, raport z test贸w [a dok艂adniej z regresji]). Z drugiej strony projekt by艂 bardzo wymagaj膮cy - okaza艂o si臋, 偶e klient ma to wszystko gdzie艣 i mieli艣my z nim bardzo s艂aby kontakt. Wyci膮ganie jakichkolwiek informacji by艂o ma艂ym rocket science.
Kolejny projekt - moje pocz膮tki wygl膮da艂y tak, 偶e przez 2-3 dni wdra偶a艂em si臋 do projektu (on ju偶 istnia艂, w por贸wnaniu do poprzedniego). Moim zadaniem by艂o zg艂aszanie jak najwi臋kszej ilo艣ci bug贸w, improvement贸w - zar贸wno tych dotycz膮cych samych funkcjonalno艣ci, jak i takich zwi膮zanych z podstawami bezpiecze艅stwa. Ot, takie dziwne za艂o偶enia, ale wzi膮艂em je na klat臋. Bardzo fajny projekt. Kolejny projekt - pocz膮tki wygl膮da艂y do艣膰 stresuj膮co - bardzo niestabilne 艣rodowisko deweloperskie, brak 艣rodowiska testowego, brak jakichkolwiek plan贸w i za艂o偶e艅, zero dokumentacji, nadchodz膮cy release na produkcj臋, brak jakichkolwiek test贸w zanim tu trafi艂em, du偶a ilo艣膰 programist贸w (a zatem du偶a ilo艣膰 zada艅), ba艂agan w Jirze, a do tego wszystkiego na horyzoncie widoczne ju偶 by艂y audyty SEO oraz wydajno艣ci (wykonywane przez zewn臋trzne firmy), czyli dodatkowa tona zada艅. Zadanie? Oficjalnie - doprowadzi膰 do releasu stabiln膮 wersj臋 aplikacji. Nieoficjalnie - zrobi膰 tutaj porz膮dek, w przeciwnym razie nie by艂o 偶adnych szans na jak膮kolwiek stabilno艣膰. Bardzo du偶e ci艣nienie, pora偶ka podczas releasu (release si臋 uda艂, ale po kilku sekundach wszystko pad艂o, klient by艂 obok), kilkugodzinne spotkania do p贸藕nych godzin. Ale w ko艅cu wyszli艣my na prost膮 i wszystko si臋 uda艂o.
Jak zatem mo偶na zauwa偶y膰 - ka偶dy projekt jest inny, ka偶dy start jest inny. Mo偶esz trafi膰 na prosty i nieskomplikowany projekt, gdzie Twoja rola ograniczy si臋 do testowania, zg艂aszania improvement贸w i drobnej papierkologii. Mo偶esz te偶 trafi膰 na 艣rodek tr贸jk膮ta bermudzkiego z misj膮 bezpiecznego wyprowadzenia za艂ogi. Mo偶esz te偶 trafi膰 do projektu, gdzie b臋dzie codzienny kontakt z klientem lub zagranicznym zespo艂em, ale r贸wnie dobrze mo偶esz trafi膰 tak, 偶e kontakt z klientem ograniczy si臋 do jednego spotkania co dwa tygodnie.
O r贸偶nych problemach w bran偶y Quality Assurance opowiada艂em w cyklu "Problemy w pracy(...)" na YouTube. Zapraszam Ci臋 serdecznie.
|