Jak ważna jest znajomość funkcjonalności przed kodowaniem?

Pracuję dla firmy produkującej oprogramowanie, w której prace programistyczne zostały nam przekazane. Zespół na lądzie obsługuje obsługę i rozmawia bezpośrednio z klientami. Nigdy nie rozmawiamy bezpośrednio z klientami, po prostu rozmawiamy z ludźmi z zespołu na lądzie, którzy rozmawiają bezpośrednio z klientami.

Gdy nadchodzą wymagania, zespół na lądzie rozmawia z klientami, sporządza dokumenty wymagań i informuje nas. Dokumenty projektowe wykonujemy po przestudiowaniu wymagań (kierujemy się tradycyjnym modelem wodospadu).

Jest jednak jeden problem w całym procesie: nikt w zespole ani na morzu, ani na lądzie nie rozumie całkowicie funkcjonalności aplikacji. Wiemy tylko, że jest to wielka, złożona aplikacja internetowa do obsługi złożonego przetwarzania zamówień, zarządzania katalogami, zarządzania kampaniami i innych działań. Walczymy z dokumentem projektowym, ponieważ wymagania nie byłyby jasne. Następnie przechodzi w serię pytań / odpowiedzi tam iz powrotem między zespołem na lądzie, zespołem na lądzie a klientami. Często mówiono nam, abyśmy rozumieli funkcjonalność z kodu. Ale zwykle nie jest to wykonalne, ponieważ baza kodu jest ogromna, a nawet zrozumienie prostej pozycji menu zajmuje dni, jeśli nie tygodnie. Próbowaliśmy powiedzieć klientom, aby przekazali nam wiedzęo aplikacji, ale bezskutecznie. Nasz kierownik często kazał nam rozpocząć kodowanie, nawet jeśli dokument projektowy nie jest kompletny lub wymagania nie są jasne. Zaczniemy od zakodowania części wymagań, które wydają się jasne, i poczekamy na resztę.

Zwykle opóźnia to wdrożenie o miesiąc. W skrajnych przypadkach mielibyśmy bardzo małe błędy w rozwoju i produkcji, ale klienci powiedzieliby, że nie o to pytają. To zaczynałoby się od obwiniania i szeregu próśb o zmiany, a w końcu opracowywaliśmy coś zupełnie innego.

Moje pytanie brzmi: jak zrobiłbyś prace programistyczne, jeśli nie znasz w pełni funkcjonalności aplikacji?

AKTUALIZACJA

Metodologia rozwoju nie jest tak naprawdę moim wyborem i nie jestem liderem mojego zespołu. Tak to się zaczęło. Próbowałem powiedzieć ludziom o zaletach zwinności, ale bezskutecznie. Poza tym nie sądzę, aby mój zespół miał niezbędne nastawienie do pracy w zwinnym środowisku.

Krótka wersja:

Wiedzieć, co robić ≠ znać swojego klienta.

Wyobraź sobie: jesteś firmą związaną z rozwojem nieruchomości. Poprosisz partnera o zbudowanie dużego kompleksu. Partner mówi, że pomimo wszystkich dokumentów, które mu dałeś, musi również porozmawiać bezpośrednio z osobami, które kupiłyby mieszkania w tym kompleksie. Poważnie?

Długa wersja:

Zawsze miło jest wiedzieć, jak będzie używana konkretna aplikacja, ponieważ nauka jest fajna, ale nie zawsze jest to możliwe w przypadku dużych projektów.

Niektóre domeny są po prostu zbyt złożone. Jeśli jesteś tylko programistą i pracujesz nad wieloma aplikacjami z wielu domen, po prostu nie zawsze rozumiesz, co robi użytkownik końcowy , ponieważ wymagałoby to spędzenia pięciu lat nauki rachunkowości, dziesięciu lat w szkole medycznej, sześć lat studiów prawniczych itp.

Z drugiej strony, oprogramowanie stworzone bez zrozumienia konkretnej domeny będzie w najlepszym wypadku, cóż, nieco bezużyteczne .

Dlatego wymagania funkcjonalne i niefunkcjonalne muszą być pisane przez osoby, które w pełni rozumieją domenę. Zasadniczo gromadzenie wymagań obejmuje jednocześnie:

1. Technicy (na przykład programiści, którzy powiedzieliby, że określona funkcja jest niemożliwa, że ​​ta druga może być znacznie lepsza, jeśli zostanie wykonana w ten sposób, a ta będzie kosztować tysiące dolarów, podczas gdy istnieje znacznie tańsza alternatywa),

2. Osoby specjalizujące się w zarządzaniu projektami,

3. Osoby wyspecjalizowane w dziedzinie klienta , które mają pełne zrozumienie tej domeny i konkretnych potrzeb klienta. Oczywiście może to być sam klient.

Jedno funkcjonalne i niefunkcjonalne wymagania są zapisane i są wystarczająco precyzyjne, nie potrzebujesz niczego innego jako osoby, której praca polega na przełożeniu tych wymagań na kod.

Jeśli chodzi o konkretny przypadek, sam opisujesz przyczynę problemu:

Walczymy z dokumentem projektowym, ponieważ wymagania nie byłyby jasne.

Problemem nie jest brak wiedzy o kliencie , lecz niska jakość wymagań. W prawidłowo zarządzanym projekcie wymagania funkcjonalne i niefunkcjonalne muszą być doskonale jasne i jednoznaczne. Jeśli dokument wymagań nie jest jasny lub mówi ci, że „wygląd wizualny produktu musi być atrakcyjny” lub inne głupoty, to dlatego, że zostało napisane przez ludzi, którzy nie wiedzą, jak to napisać.

Wiedząc o tym, musisz działać inaczej:

• Jeśli wiesz, że zespół, który zbiera wymagania, jest zdesperowany, a twój własny zespół ma wykwalifikowanych ludzi do zbierania wymagań, wyjaśnij sytuację swojemu przełożonemu i powiedz, że inny zespół musi zostać zastąpiony przez osobę kompetentną , na przykład twoją.

• W przeciwnym razie (tj. Jeśli nie są zdesperowani), spróbuj ustalić ich wewnętrzną przyczynę tych niskich wymagań i przekonać ich, że prawidłowe wykonywanie pracy obniży jedynie całkowity koszt projektu . Dobrym pomysłem jest pokazanie statystyk dotyczących tego, jak źle napisane wymagania wpłynęły na projekt poprzez zwiększenie kosztów (o ile?) I ryzyko braku gotowości do terminu.

Prawdopodobnie dokument wymagań jest po prostu niekompletny. Cały czas to widzę: niedoświadczeni menedżerowie projektów są po prostu przekonani, że wystarczy jednostronicowy dokument i nie rozumiem, dlaczego mieliby napisać od trzech do czterystu stron zamiast jednej. Jeśli tak jest w Twojej firmie, pokaż, że poświęcenie więcej czasu na wymagania zmniejszy koszty.

Używasz dokładnie niewłaściwej metodologii programowania dla problemów, które napotykasz.

Korzystając z Waterfall, zobowiązujesz się do:

1. Otrzymywanie właściwych wymagań z góry - to oczywiście nie działa
2. Kodowanie wymagań z dala od klienta - nie jesteś w stanie skutecznie sprawdzić problemów z klientem, biorąc pod uwagę, że zobowiązałeś się do opracowania wymagań
3. Pierwszą szansą, by klient zobaczył ich funkcjonalność, są testy - jest to zdecydowanie za późno, biorąc pod uwagę występujące problemy

Rozważ zastosowanie, jeśli to możliwe, innego sposobu zarządzania projektem. Agile Software Development ma kilka funkcji, które mają na celu rozwiązanie problemów, z którymi się borykasz.

Jakiś czas temu napisano godne porównanie Waterfall vs Agile , weźmy kilka cytatów, które podkreślają twoje problemy:

Missing the Mark:

Po ukończeniu etapu w metodzie Wodospad nie ma powrotu, ponieważ większość oprogramowania zaprojektowanego i wdrożonego w metodzie Wodospad jest trudna do zmiany w zależności od czasu i potrzeb użytkownika. Problem można rozwiązać tylko poprzez cofnięcie się i zaprojektowanie całkowicie nowego systemu, co jest bardzo kosztowną i nieefektywną metodą.

Przywiązane...

Zwinne metody pozwalają na zmiany specyfikacji zgodnie z wymaganiami użytkownika końcowego, co oznacza satysfakcję klienta. Jak już wspomniano, nie jest to możliwe, gdy stosuje się metodę wodospadu, ponieważ wszelkie zmiany, które należy wprowadzić, oznaczają, że projekt należy rozpocząć od nowa.

... i nie można się przenieść

Podsumowując różnicę między nimi, można powiedzieć, że klasyczna metoda wodospadu oznacza przewidywalność, podczas gdy metodologia zwinna oznacza adaptowalność. Metody zwinne dobrze zmniejszają koszty ogólne, takie jak uzasadnienie, uzasadnienie, dokumentacja i spotkania, utrzymując je na jak najniższym poziomie. I dlatego metody Agile przynoszą korzyści małym zespołom o ciągle zmieniających się wymaganiach, a nie więcej niż większym projektom.

To, gdzie jesteś teraz, jest złe; nie spełniasz wymagań klienta, a jeśli jesteś odpowiedzialny za rozwój oprogramowania, produktywność zniknie za oknem, wzrośnie nieufność, a sytuacja może się pogorszyć, a nie poprawić.

Relacje z klientem są kluczowe ; tutaj wygląda na to, że nie jesteś w stanie skutecznie zebrać ich problemów i dostosować się do zmieniających się wymagań w twoim obecnym stylu pracy; dlatego musisz zastanowić się, jak to zmienić.

To nie tak działa. Jednym z tematów mojej obecnej edukacji jest analiza i relacje z klientem. Nacisk kładziony był zawsze na jasne zdefiniowanie projektu. Wyobraź to sobie:

• Zamawiasz firmę budowlaną, aby zbudowała dom, ale nie wiesz, jak ma wyglądać. Po prostu dostosowujesz pierwsze piętro, aby zespół budował dom do pierwszego piętra. Następnie chcesz, aby parter został ułożony inaczej. Ups ...

O ile nie masz pewności, że możesz (częściowo) stworzyć prawidłowe podstawy dla aplikacji, chciałbym tylko powiedzieć klientowi, że nie ma innego sposobu, aby to zrobić, niż z jasno określonymi celami i funkcjonalnościami. Ponieważ jeśli po prostu weźmiesz noża w to, co może być, ryzykujesz wyrzuceniem dużej ilości pieniędzy i czasu.

Oto kilka rzeczy, które pomogą rozwiązać problemy:

1. Popraw komunikację między dwoma zespołami. Poproś drugi zespół, aby skompresował wymaganie do 3 słów, a następnie programista zastosuje te słowa dokładnie. Słowa muszą tylko być poprawne. Nic nie zostanie wdrożone bez tych słów. Każde słowo daje 2000 linii kodu. Wdrożenie rozpoczyna się, gdy znane jest nowe słowo.
2. Jeśli słowo nie jest od razu zrozumiałe dla programistów, mogą zadać jedno pytanie . Pytanie znowu musi być prawidłowe. Potrzebuje natychmiastowej odpowiedzi - odpowiedź nie może poczekać w obie strony z drugiej strony świata, ale należy ją wcześniej poznać. Realizacja rozpoczyna się natychmiast po otrzymaniu odpowiedzi, a odpowiedź zostanie przesłana do listu.
3. Jeśli podczas implementacji występują niejasne lub niejasne wymagania, sposobem ich rozwiązania jest najpierw spojrzenie na (istniejące) 3 słowa. Jeśli nadal nie jest jasne, programista najlepiej zgaduje . Wszelkie opóźnienia w tym procesie są absolutnie zabronione; a prośba o pomoc od drugiego zespołu nie jest właściwym sposobem na rozwiązanie tego problemu - mieli już szansę zmienić wymagania, wybierając prawidłowe 3 słowa.
4. Jeśli po tym wszystkim wymaganie jest nadal niejasne lub niemożliwe do wdrożenia, właściwym sposobem postępowania jest odrzucenie tych 3 słów, które spowodowały problem, i przejście do następnych słów. Wszelkie odrzucone słowa zostaną zebrane i przekazane do drugiego zespołu, który będzie musiał zmodyfikować słowa przed ponownym wprowadzeniem ich do systemu. Odrzucanie słów zawsze przesuwa termin, a wdrożenie będzie musiało zostać ponownie zaplanowane.
5. Zespoły musiałyby zostać ocenione na podstawie liczby odrzuconych słów. Po wdrożeniu wymagania jest ono ustalane na zawsze i nie można go już zmienić . Wszelkie próby zmiany już zaimplementowanych funkcji zostaną odrzucone.
6. Faktyczny problem z tym pytaniem polega na tym, że zakłada, że ​​więcej informacji ułatwia wdrożenie. To nie jest prawda. Im więcej swobody mają programiści, tym łatwiejsza implementacja . Kompresowanie wymagań pozwala na przekazywanie dużych ilości informacji bez ograniczania nadmiernie zadań programistów.