Brzydka prawda o procesie tworzenia oprogramowania

Źródło obrazu: perfectdigital.com

Znasz to zdjęcie, prawda?

Myślę, że to bardzo dobrze pokazuje, że duże rozbieżności i brak wizji mogą pojawić się w projekty rozwoju oprogramowania między wszystkimi uczestnikami i zaangażowanymi osobami. Problemy często pojawiają się już na samym początku, gdy klient przychodzi z (teoretycznie) ostateczną propozycją. produkt wizję i przedstawia ją zespół. Następnie pojawiają się dalsze nieporozumienia, błędne interpretacje i ostatecznie projekt szybko schodzi na złą ścieżkę rozwoju.

Analizując powyższy wykres, przedstawię krok po kroku wszystkie możliwe zagrożenia i zasugeruję, jak z nimi walczyć. Przejdźmy od razu do rzeczy!

1. Jak klient wyjaśnił swój pomysł?

Od samego początku będą występować rozbieżności w wizji produktu. Dlaczego? Powód jest bardzo prosty - każdy interpretuje rzeczywistość na swój sposób, ma wyobrażenie czegoś w głowie i może niedokładnie przedstawić tę wizję drugiej stronie. Jeśli opiszesz słowami produkt, który chciałbyś zbudować, istnieje duże prawdopodobieństwo, że zespół programistów zrozumie Twoją wizję w inny sposób niż zamierzałeś.

Oczywiście można tego uniknąć. Należy jak najszybciej zacząć wizualizować i omawiać poszczególne elementy funkcjonalności produktu na podstawie szkiców. Co ciekawe, pierwsze szkice zazwyczaj nie mają nic wspólnego z finalnym produktem. Na tym etapie najważniejsze jest jednak, aby wizja była spójna.

2. Jak zrozumiał to lider projektu?

Zastanawiasz się, dlaczego pierwsze i drugie zdjęcie są tak różne? Lider projektu zawsze przyjrzy się bliżej wizji produktu. Jednak, ważne jest, aby taka osoba, zasadniczo odpowiedzialna za całość rozwój oprogramowania proces, w pełni rozumie problem i potrzeby związane z produktem. Lider projektu musi mieć jasny "szerszy obraz". Jak widać, oba obrazy nie różnią się pod względem funkcjonalności. Po prostu wyglądają inaczej. Aby lepiej zrozumieć ten punkt, wróćmy do obrazu numer jeden. Na początku projektu nie było żadnych szkiców, co już doprowadziło do nieporozumień. Funkcjonalność produktu jest poprawna, ale projekt jest zupełnie inny.

3. Jak analityk go zaprojektował? i 4. Jak programista to napisał?

Czasami analitycy i programiści nie znają potrzeb użytkowników lub ustalonych celów biznesowych. Widzą tylko mały wycinek całego projektu, na którym się skupiają. Nie są w stanie spojrzeć z szerszej perspektywy, a dzieje się tak szczególnie w przypadku dużych projektów, w których jednocześnie pracuje wielu deweloperów.

Możemy też posłużyć się innym przykładem. Może się zdarzyć, że problem do rozwiązania zostanie nieprawidłowo opisany, na przykład przez właściciela produktu. Wiąże się to z dostarczeniem niekompletnych informacji, na podstawie których deweloper lub projektant tworzą własne interpretacje, a produkt coraz bardziej odbiega od zamierzonej ścieżki rozwoju.

Jak to zmienić? Myślę, że dobrym rozwiązaniem jest upewnienie się, że osoby kluczowe dla projektu mają szczegółową wiedzę na jego temat - tak zwany "bigger picture". W przypadku nieporozumień, łatwiej będzie im doprowadzić do porozumienia. proces tworzenia oprogramowania z powrotem na właściwą ścieżkę. Dlatego pamiętaj - jeśli każdy widzi tylko swój mały fragment rozwijanej funkcjonalności, nieporozumienia w wizji stają się prawdopodobnym zagrożeniem.

5. Jak opisał to konsultant biznesowy?

Tutaj sprawa jest prosta. Produkt musi się sprzedawać. Trzeba się jakoś wyróżnić, aby np. zwykła huśtawka do ogrodu zyskała niezwykłe elementy. Chodzi o to, aby przekonać do siebie potencjalnego nabywcę. Dział marketingu i sprzedaży z pewnością zrobi wszystko, aby pokazać, że produkt jest wyjątkowy.

6. W jaki sposób projekt został udokumentowany?

Brakująca dokumentacja jest bardzo częstym problemem. Czasami tworzenie dokumentacji podczas rozwój produktu wydaje się niepotrzebną stratą czasu. To błąd. Bardzo często powtarzam, że zmiany są wprowadzane szybciej na papierze niż w rzeczywistości. kodi coś w tym jest. Ponadto łatwiej jest odnieść się do dokumentacji, aby śledzić wszelkie zmiany. Uwierz mi, projekt bez dokumentacji jest obarczony bardzo wysokim ryzykiem rozminięcia się z wizją.

7. Jakie operacje zostały zainstalowane?

Etap ten odnosi się do umieszczenia środowiska na serwerze. Podobnie jak w punkcie o programistach i analitykach, bez pełnych danych i z lukami w komunikacji może się okazać, że stworzono tylko część potrzebnego środowiska.

8. W jaki sposób klient został rozliczony?

Jest to wynikiem słabej komunikacji, braku UX i tak dalej. Pojawienie się błędów wydłuża czas rozwoju. A czas to pieniądz, prawda? Moją wskazówką jest prowadzenie projektu zgodnie z Agile, utrzymywać najwyższe standardy komunikacji i utrzymywać jasne wytyczne budżetowe. Nie mam wątpliwości, że w ten sposób unikniesz takich problemów.

9. Jak to było wspierane?

Klienci często skupiają się jedynie na zbudowaniu produktu i na tym kończą. Żyjemy jednak w czasach wielu zmian i innowacji technologicznych, dlatego konieczne jest utrzymywanie stałego wsparcia technicznego. Chodzi o to, by uniknąć sytuacji, w której coś nagle przestaje działać, bo staje się przestarzałe, a produkt traci na wartości. O tym aspekcie również nie należy zapominać.

10. Czego naprawdę potrzebował klient?

Dotarliśmy do ostatniego punktu. Spójrz na rozbieżność między pierwszym i ostatnim wykresem. W końcu oba odnoszą się do perspektywy klienta. Dlaczego tak się dzieje? Wszyscy kłamią, że to takie proste 🙂 Wyniki ankiet zawsze różnią się od rzeczywistych potrzeb respondentów. Odpowiadając na pytanie badacza, użytkownicy chcą pokazać się z jak najlepszej strony. Dlatego, CZĘSTO NIE ODPOWIADAJĄ ZGODNIE Z PRAWDĄale raczej w sposób, w jaki uważają, że powinni odpowiedzieć. Zasadniczo nie chcą być narażeni na negatywną ocenę innych. Oto mała podpowiedź - wspomnij w instrukcjach, że nie ma ani dobrych, ani złych odpowiedzi.

Gdzie jeszcze pojawiają się różnice? Ludzie często nie wiedzą, czego tak naprawdę chcą. Dość często użytkownicy początkowo mówią, że potrzebują 10 funkcji w produkcie, a później faktycznie używają tylko, powiedzmy, 3.

Jak więc rozwiązać ten problem? Oprócz pytania użytkowników, czego chcą i potrzebują, pozwól im przetestować produkt, najlepiej na autentycznych przedmiotach, aby zachować wiarygodność. Im więcej testów podczas tworzenia produktów, tym większa szansa, że wynik będzie dokładny.

Podsumowanie

Jeśli kiedykolwiek zostaniesz członkiem rozwój oprogramowania projektu, zapamiętaj moje przykłady i wyciągnij wnioski, aby nie powielać powyższych błędów. I pamiętaj, te pojęcia są bardzo ważne przy budowaniu produktu (aplikacji) od podstaw:

- dobry UX i testy, aby dowiedzieć się, czego naprawdę potrzebują użytkownicy,

- Komunikacja w ramach projektu, dzięki czemu kluczowe osoby w projekcie mogą dogłębnie zrozumieć problem i potrzeby,

- opracować produkt zgodnie z Zwinność,

- nie zapomnij o wsparciu technicznym.

Czytaj więcej:

– Jak skutecznie zarządzać zdalnymi programistami? Przewodnik dla CTO

– Python vs. Ruby? Której technologii należy użyć do rozwoju produktu?

– Krótki przewodnik po budowaniu i rozwijaniu własnego rynku. Co warto wiedzieć?