Nasza strona używa cookies. Dowiedz się więcej o celu ich używania i zmianie ustawień w przeglądarce. Korzystając ze strony, wyrażasz zgodę na używanie cookies, zgodnie z aktualnymi ustawieniami przeglądarki. Rozumiem

Twoja aplikacja będzie gotowa w piątek. - Który piątek?!

Tomer Dicturel Co-Founder, CEO / Epic.Ai
Poznaj 10 powodów, przez które projekty Software Development zawodzą.
Twoja aplikacja będzie gotowa w piątek. - Który piątek?!

Jeśli wyszukasz w Internecie trendy dotyczące rozwoju oprogramowania, znajdziesz nieskończoną ilość informacji na temat dynamicznie rozwijających się technologii i tego, w jaki sposób technologia wpłynie na każdy sektor do 2020 roku. Notorycznie słyszymy o wszystkich niesamowitych zmianach, jakie wprowadzi nowa technologia, ale jestem tutaj, aby zakwestionować drugą część poprzedniego zdania.

"W 2020". Dla tych, którzy nie mówią w języku inżynierów oprogramowania, oznacza to 2040.

Jako jedynego faceta w Crane.ai, który nie pisze kodu, najdłużej nękał mnie ten problem. Oczywiście osoby niebędące programistami również stanowią część problemu; ten post miał początkowo zawierać około 5 powodów, dla których projekty tworzenia oprogramowania zawodzą, ale w pełnym stylu klienta zmieniłem specyfikację w połowie projektu, a więc podaję około 10 powodów, dla których projekty tworzenia oprogramowania zawodzą.


1. Źle zdefiniowany (lub, nie daj Boże, niezdefiniowany!) wynik

„Aplikacja mobilna? Zbudowaliśmy most, może być?”

Jednym z największych problemów nękających projekty rozwoju oprogramowania jest słabo określony wynik. Bez właściwej definicji, czym powinien być „produkt końcowy”, mamy gwarancję porażki.

Jest to tak istotne, że może całkiem zmienić kierunek samego projektu (dlatego jest #1 na mojej liście!). Gorąco polecam stworzenie arkusza specyfikacji, aby lepiej określić, jak będzie wyglądał produkt, co zrobi i jak to zrobi. Więcej na ten temat w punkcie o komunikacji i oczekiwaniach!


2. Rozwiązywanie niewłaściwego problemu

„Zbudowaliśmy nowy drewniany most, który wygląda o wiele ładniej niż poprzedni. Samochody? Och, nie, nie może utrzymać samochodów. Prawie wszystko, co jest cięższe od ptaka, go zawali. ”

Innym częstym problemem jest rozwiązanie niewłaściwego problemu. Leży to w tym samym polu, co słabo zdefiniowany wynik, ale ma znacznie szerszy zakres. Chociaż możesz poprawnie zidentyfikować swój produkt końcowy i rozwiązać inne omawiane tutaj problemy, jeśli Twoje rozwiązanie nie rozwiązuje prawidłowo problemu, nie udało Ci się zatem ruszyć z projektem.

Jednym ze sposobów rozwiązania tego problemu jest stopniowe ideowanie. Określ swój główny problem: jakie kroki można podjąć i jakie jest możliwe rozwiązanie. Następnie nieustannie iteruj produkt przez swojego użytkownika końcowego - utrzymuj stały proces przeglądu, aby upewnić się, że projekt właściwie odpowiada potrzebom użytkownika i pozostaje rozwiązaniem głównego problemu.


3. Niewystarczająca komunikacja

„My zbudowaliśmy pół mostu, oni pół tunelu.”

To główny problem dotykający praktycznie każdego projektu, branży i biznesu -komunikacja. Komunikacja jest niezbędna na każdym poziomie projektu rozwoju oprogramowania.

Na poziomie wewnętrznym Twoi programiści muszą skutecznie się komunikować, aby upewnić się, że budują narzędzia i pipeline’y w koordynacji, które są odpowiednio kompatybilne. Powszechnym rozwiązaniem jest sporządzenie wcześniej specyfikacji dla projektu, API i wszelkich innych rozwiązań technicznych, wymaganych w projekcie. Ma to kluczowe znaczenie dla zaoszczędzenia setek godzin czasu, które w przeciwnym razie można by zmarnować na refaktoryzację i restrukturyzację.

Na wyższym poziomie ważne jest również prawidłowe komunikowanie się z innymi zespołami. Zespół marketingowy np. musi wiedzieć, co jest technicznie wykonalne przed sprzedażą koncepcji.

Brak komunikacji na tym poziomie może powodować problemy z rozbiciem projektu. Produkt może zostać poważnie oderwany od tego, co zostało sprzedane, obiecane, zbudowane lub co było faktycznie potrzebne.


4. Brak planu lub osi czasu

„Tak… to będzie gotowe jakoś tak… może za kilka tygodni? Nie wiem w sumie co będziemy robić potem… ”

Bez względu na to, czy przestrzegane są terminy i plany, ważne jest, aby je mieć. Zapewnią projektowi poczucie struktury i pozwolą oszacować, kiedy i jak zadania zostaną zakończone.

Oczywiście dobry plan sięga znacznie dalej. Dobry plan lub timeline może również służyć jako wspólna granica dla dużych zespołów, umożliwiając im szybkie i skuteczne działanie w sprintach. Jeśli funkcja odapda lub potrzebuje więcej czasu, plan/timeline można szybko poprawić, a budżet odpowiednio dostosować.


5. Brak odpowiedzialności

„Kto jest za to odpowiedzialny?… nie ja, pa!” - Harry Truman, prawdopodobnie

Kiedy wszystko się pieprzy, ktoś musi stać z mopem w gotowości. Jeśli dana funkcja ulegnie awarii, powinno być jasne, kto jest za nią odpowiedzialny i jakie kroki należy podjąć, aby temu zapobiec w przyszłości.

Brzmi to dziecinnie, ale powszechnym zjawiskiem w branży tworzenia oprogramowania jest wytykanie palcami.

Backendowi inżynierowie będą obwiniać frontendowych, którzy będą obwiniać sprzedaż, która będzie obwiniać marketing, który będzie obwiniał dział prawny, który będzie obwiniał zarząd, który będzie obwiniał…  Ten proces jest nie tylko czasochłonny i katastrofalny dla morale, ale pozostawia podstawowe pytanie - „co poszło nie tak?” - otwartym i bez odpowiedzi.


6. Zbyt częste przesuwanie bramki

„No dobra, ale teraz most musi również pełnić rolę pasa startowego, mieć 10 kolejnych pasów ruchu, no i może park na środku?”

Ważne jest śledzenie celów projektu i upewnianie się, że są one konsekwentnie wykonywane. Choć możliwe jest rozszerzenie projektu lub zmiana wymagań, częste modyfikacje „celu końcowego” mogą nie tylko zniszczyć morale, ale wręcz uniemożliwić realizację projektu. Często zmiany są nieplanowane i wymagają rozległej refaktoryzacji; z czasem prowadzi to do dużej ilości zmarnowanego czasu, a ostatecznie do nieudanego projektu.

To, co początkowo może wydawać się niewielką zmianą, może stać się długoterminowym projektem.


7. Nieodpowiednia dokumentacja i tracking

„Instrukcje rozładowania tej bomby mówią, by przeciąć czerwony przewód po wyłączeniu zasilania, ale wszystkie przewody są czerwone, a zasilanie zostało odcięte 10 minut temu!” - James Bond, tuż przed końcem swojej kariery

Wspaniale jest stosować zwinną metodologię i szybko się poruszać, ale dokumentacja jest zawsze ważna. Nieudokumentowany kod może prowadzić do wieloletniego długu technicznego i może spowodować ogromne problemy po drodze - „co właściwie robi ta funkcja?”

Równie ważne jest udokumentowanie produktu. Każdy etap procesu, od ideacji przez projektowanie, do wykonania, powinien być dobrze udokumentowany, aby projekt był łatwy do nawigacji dla innych i pozostawał na dobrej drodze. Dobra dokumentacja pozwala na łatwiejszy tracking projektu - w zwinnym systemie wypróbuj tablicę kanban lub podobną, aby śledzić zadania!


8. Źle zdefiniowane wymagania systemowe

„Jak to jest tylko 5 bochenków i 2 ryby ​​dla nas wszystkich?!”

Wymagania techniczne projektu mogą być trudne do oszacowania, ale niezwykle ważne jest, aby to właśnie zrobić. To, co może wydawać się małym dodatkiem, może przerodzić się w problem, polegający na przydzieleniu dodatkowej infrastruktury i przedefiniowaniu całego systemu, aby wprowadzić wsparcie.


9. Słabe przygotowanie

„Ruszamy w rejs połową statku”.

Często projekt jest ekscytujący i łatwo się w niego zaangażować; jednak kluczowe znaczenie dla jego powodzenia ma właściwe przygotowanie. Należy stworzyć specyfikacje, opracować projekty, uzgodnić harmonogram, a zasoby powinny zostać odpowiednio przydzielone.

Popularną metodą zarządzania na poziomie technicznym jest Test Driven Development. Przed napisaniem pojedynczej linii kodu do projektu, zaplanuj architekturę i to, co każdy element musi osiągnąć. Następnie napisz testy, aby stwierdzić, że każdy element rzeczywiście robi to, co było zamierzone. W ten sposób masz gotowe ramy z ustalonymi celami i możesz określić postęp w rozwoju Twojego produktu.


10. Nierealistyczne oczekiwania

„Ok, aplikacja wygląda dobrze - ale dlaczego schemat kolorów nie zmienia się automatycznie, aby pasował do obudowy telefonu użytkownika?”

Ważne jest, aby zarządzać oczekiwaniami. Często klient prosi o funkcję, która jest nieuzasadniona, niepraktyczna lub niewykonalna. Powszechną praktyką jest ograniczenie liczby zmian, które można wprowadzić do specyfikacji, oraz obecność inżyniera podczas dyskusji w celu ustalenia, czy proponowana funkcja jest technicznie wykonalna.


Podsumowanie

Mam nadzieję, że dzięki uniknięciu tych 10 pułapek, Twój kolejny projekt rozwoju oprogramowania będzie zadziwiającym sukcesem. Oby pomogło Ci to uniknąć popełnienia tych samych błędów, które sam popełniałem. Powodzenia!


Oryginał tekstu w języku angielskim przeczytasz tutaj.

Masz coś do powiedzenia?

Podziel się tym z 120 tysiącami naszych czytelników

Dowiedz się więcej