Zwinna współpraca z Software House

Paweł Tomkiel
Do dzisiejszego odcinka zaprosiłem Ulę Wawrzeniuk. Ula jesteś Head of product delivery w 10clouds. Jesteście Software housem i dzisiaj będziemy rozmawiać o tej współpracy, szczególnie od tej zwinnej strony. Gdybyś mogła na sam początek przedstawić się, powiedzieć trochę więcej o sobie.

Ula Wawrzeniuk
Jasne. Jak na ten moment jestem odpowiedzialna za cały zespół związany z product delivery ale także za cały proces, w jaki sposób podchodzimy do dostarczania produktów naszej organizacji. Głównie mam 3 zespoły, które się tym zajmują. Pierwszy to jest zespół product delivery menedżerów. Co to za role pewnie powiem jeszcze trochę później, bo to jest dosyć nowa i nietypowa rola, jeśli chodzi o podejście zwinne. Drugi zespół to jest agile practice area i to jest zespół, który zajmuje się doskonaleniem wszystkich procesów związanych z podejściem zwinnym. Czyli już nie bezpośrednio dostarczaniem, ale tym żebyśmy w odpowiedni sposób budowali cały proces i odpowiednio go układali w zależności od tego z jakim klientem pracujemy. Natomiast ostatni zespół wspiera pierwsze fazy współpracy z klientem i to w jaki sposób w ogóle chcemy podchodzić do dostarczenia produktu, na którym etapie rozwoju produktu klient przychodzi. Jest to bardziej zespół analityczny, zespół związany z pierwszymi fazami rozwoju produktu. Jest product discovery, odkrywanie produktu, early market validation, czyli badanie czy produkt ma już dopasowanie do rynku, czy powinniśmy przeprowadzić jeszcze jakieś testy z taką perspektywą stricte biznesową, to znaczy, jakie value przez ten produkt chcielibyśmy dostarczyć.

Paweł Tomkiel
Już teraz chciałbym zadać kilka pytań o same procesy, ale zanim do tego przejdziemy, to może tak uspójnijmy rozumienie zwinnej współpracy z software housem- co będziemy przez to rozumieć.

Ula Wawrzeniuk
To może na początku powiem w ogóle o zwinnym dostarczaniu produktu, bo od tego powinniśmy wyjść. Opowiem z naszej perspektywy, jeżeli mówimy o tym, że chcemy dostarczać produkty zwinnie i budujemy zwiną organizację czy zwinne procesy. Po pierwsze, przyjmujemy jakąś kulturę organizacyjną, a następnie dopasowujemy do tego konkretne narzędzia czy konkretne procesy. Mówiąc o kulturze organizacyjnej, czyli sposobie podejścia do realizacji biznesu, zakładamy, że pracujemy w środowisku mocno zmiennym. Pracujemy w środowisku, w którym powinniśmy podchodzić do rozwoju produktu w krótkich iteracjach, ale też jak najszybciej walidować to z użytkownikiem docelowym, w zależności jaką aplikacje budujemy, jaki produkt dostarczamy. To niekoniecznie musi być produkt IT, no ale oczywiście mówimy o zwinnej współpracy z software housem. To będziemy tutaj mówić o rozwoju software'u. Natomiast chcemy jak najszybciej tą wartość dostarczyć. Jeśli chodzi o zwinną współprace z software housem, to troszkę porozmawiamy o tym, jak te procesy się różnią od tego, jeżeli mamy taki zespół wewnętrznie i na jakie elementy trzeba zwrócić uwagę, kiedy chcielibyśmy znaleźć takiego partnera poza naszą organizacją.

Paweł Tomkiel
Teraz, kiedy usłyszałem zwinna współpraca, nakładam na to kalkę doświadczeń, które gdzieś mam ze współpracą z dostawcami. Załóżmy, że jestem dużą firmą. Ja nie mam swojego działu IT i chciałbym, żebyście zrobili produkt. Już wiem jaki to jest produkt, mój CIO już mi powiedział. Jestem jakimś top menedżerem, znajduję was jako dostawcę i przychodzę do Ciebie i mówię- potrzebujemy apkę mobilną do naszego produktu, do naszych kanałów sprzedażowych. No i wiesz, teraz ta zwinność zakłada krótkie iteracje, zakłada tą walidacje. Zakłada wręcz ten skope niezdefiniowany na samym początku albo bardzo płynny. To jak mogłaby zacząć się taka współpraca, jeżeli bym do Ciebie przyszedł.

Ula Wawrzeniuk
Jasne, opowiem o tym, jak my dosyć specyficzne podchodzimy do takiej współpracy w 10clouds. To troszkę różni się od takiej typowej pracy z software housem, ponieważ ten układ, o którym tutaj powiedziałeś, to jest typowe podejście, z którym my się zazwyczaj spotykamy. To znaczy, że klient wewnętrznie analizuje sobie swoją potrzebę, zakłada- ok, chciałem zbudować aplikację mobilną, pójdę do software house i zapytam go, ile to będzie kosztowało. Ja potrzebuję budżet, to jest podstawa. Muszę w jakiś sposób zapewnić finansowanie całego przedsięwzięcia. I zazwyczaj jest tak, że software house mówi- okej no to, czy masz listę funkcjonalności, które my możemy wyestymować. No i w tedy się zaczyna. Jednak pierwszej rzeczy z tej listy wymagań bardzo często nie ma i trzeba ją wypracować razem z klientem. Jeśli ona jest, to wtedy możemy się pokusić o jakąś estymacje. Natomiast tam jest mały haczyk tego typu podejściu. My zakładamy, że klient przeprowadził pełną analizę produktu, ma strategię produktu, ma dobrze przeanalizowanych swoich klientów docelowych. Ma określone pewne założenia, to znaczy, jakie są korzyści, które ma nam ten produkt przynieść i w jakiej perspektywie czasowej. Ma założony pewien proces rozwoju produktu, to znaczy zakładam, że jeżeli dzielimy sobie dostarczenie produktu na kilka faz, ten produkt ma być produktem nowym. W związku z tym na początku zazwyczaj mówimy, że musimy zbudować NVP, czyli produkt o ograniczonej liczbie funkcjonalności. Oddać go na rynek, zobaczyć, jak to działa. Dopiero wtedy możemy rozwijać go dalej, ale już mając pewne korzyści z tego, co wypuściliśmy. Problem polega na tym, że tego bardzo często nie ma, bądź klient sam nie do końca ma świadomość, że pewne z tych elementów są istotne i pewne aspekty takiego odkrywania produktu z punktu widzenia biznesowego powinno się zadziać wcześniej. Czyli to jest w ogóle taka pierwsza moja uwaga. Jeżeli klient chciałby współpracować z software housem i software mówi okej, to daj mi po prostu listę funkcjonalności, my to wy estymujemy, no to już powinna się zapalić czerwona lampka.

Zapraszamy do wysłuchania całego odcinka