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.
Odpowiedzi:
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:
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),
Osoby specjalizujące się w zarządzaniu projektami,
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:
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.
źródło
Używasz dokładnie niewłaściwej metodologii programowania dla problemów, które napotykasz.
Korzystając z Waterfall, zobowiązujesz się do:
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:
Przywiązane...
... i nie można się przenieść
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ć.
źródło
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:
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.
źródło
Oto kilka rzeczy, które pomogą rozwiązać problemy:
źródło