Jak osoba nietechniczna może nauczyć się pisać specyfikację dla małych projektów?

Jak osoba nietechniczna może nauczyć się pisać specyfikacje dla małych projektów?

Mój przyjaciel próbuje zlecić rozwój projektu statystycznego.

W szczególności wykonuje wiele pracy w programie Excel i chce zlecić tworzenie skryptów, aby robić to, co teraz robi ręcznie.

Jednak mój przyjaciel jest wyjątkowo nietechniczny. Jest słaby w pisaniu specyfikacji technicznych.

Kiedy pisze specyfikację, zapisuje się ją tak, jak byś opisał, robiąc coś w programie Excel (przejdź do tej komórki, a następnie skopiuj wartość do tej komórki). Jest również zbyt gadatliwy i kilka razy robi przykłady. Nie jestem pewien, czy właściwie opisuje przypadki narożne.

Pierwszy projekt, który zlecił na zewnątrz, był porażką. Myślę, że przesadził z niektórymi szczegółami, ale zlekceważył narożniki. Ten i / lub koder, którego zatrudnił, nie przejrzał narożnych spraw i nie zadał odpowiednich pytań. Nie jestem pewny. Rozmawiałem z nim i zajęło mi pół godziny, aby znaleźć opis, który powinien zająć pięć minut lub krócej. Na koniec napisałem dla niego skrypty, ale nie zbadałem, dlaczego jego proces z koderem nie powiódł się.

Poprosił mnie o pomoc. Jednak nie chcę się w to angażować, ponieważ wzięcie jego specyfikacji i przełożenie jej na jasne wymagania jest 10 razy więcej pracy niż wykonanie na wyraźnie napisanej specyfikacji.

Jak powinien się uczyć? Czy są zasoby, których mógłby użyć? Czy są sposoby, by uczyć się od małych, niskociśnieniowych projektów ćwiczeniowych z programistami?

Większość jego skryptów jest zorientowana statystycznie i na przetwarzanie danych. np. weź tę kolumnę i przeprowadź nad nią średnią. Usuń te rzędy w tych warunkach. Wyzwanie jest więc inne niż określenie aplikacji internetowej.

Widzę dwa dobre możliwe podejścia do tego problemu. Jednak ważne jest, aby zdać sobie sprawę z dwóch rzeczy. Po pierwsze, inżynieria wymagań to ciężka praca - przekształcenie pomysłu w formalną specyfikację wystarczającą do zbudowania systemu zajmuje dużo czasu, wysiłku i praktyki. Po drugie, jeśli masz dobre wymagania (w dowolnym formacie, od formalnej specyfikacji do mniej formalnych historii użytkowników i przypadków użycia), znacznie łatwiej, taniej i szybciej zbudujesz oprogramowanie (i zbudujesz je wcześniej).

Jeśli twój przyjaciel albo poprosi o zbudowanie wielu narzędzi programowych, albo zamierza je zlecić, powinien nauczyć się pisać wymagania dotyczące oprogramowania, przynajmniej na poziomie celów biznesowych i koncepcji działania. Dwie wiodące książki na temat inżynierii wymagań programowych to Karl Wiegers - Wymagania programowe (wydanie drugie) i Więcej o wymaganiach programowych: drażliwe problemy i porady praktyczne . Spodziewałbym się, że większość osób, które zatrudniłby, potrzebowałaby jakiegoś dokumentu opisującego system, przynajmniej na poziomie celów biznesowych lub koncepcji działania, i te książki się w to wpisują. Zagłębiają się także w to, jak i dlaczego w innych aspektach inżynierii wymagań, które, jak podejrzewałbym, dobry programista przejdą na początku projektu.

Drugą opcją byłoby zatrudnienie kogoś z doświadczeniem w tworzeniu oprogramowania i inżynierii wymagań (a może nawet pewnego rodzaju inżynierii systemów lub architektury systemu), aby zrozumieć przestrzeń problemu i określić, gdzie potrzebne są rozwiązania programowe, a gdzie nie byłoby rozwiązań programowych korzystne, pisz dokumenty, a może nawet nadzoruj lub przeprowadzaj prace rozwojowe. Byłoby to jednak prawdopodobnie droższe i oznaczałoby zatrudnienie na pełny etat programisty na dłuższy czas w celu opracowania nie tylko wymaganego systemu, ale także potrzebnych wymagań i architektury.

Szczerze mówiąc, nie sądzę, że to, czego doświadcza twój przyjaciel, jest tak rzadkie dla kogoś, kto nie rozumie procesu tworzenia oprogramowania. Nie sądzę też, aby wina spoczywała całkowicie na nim. Jeśli pierwszy projekt oprogramowania nie miał dobrych wymagań, programiści, którym zlecono go na zewnątrz, powinni wyjaśnić, udoskonalić i udokumentować wymagania. Szczerze mówiąc, nie jestem pewien, czy jesteś odpowiednią osobą do zaangażowania się, jeśli nie chcesz poświęcić czasu lub wysiłku na pracę z nietechnicznym użytkownikiem / klientem i opracować dobre specyfikacje techniczne (to jest kluczową rolą każdego, kto wykonuje inżynierię wymagań w dowolnej dyscyplinie inżynierskiej).

Myślę, że optymalne rozwiązanie jest tak naprawdę kombinacją moich dwóch opcji. Myślę, że twój przyjaciel (a może i ty) powinien dowiedzieć się o tym, co jest związane z inżynierią wymagań i jakie korzyści, jakie mają solidne wymagania, mogą przynieść projektowi. Jako twórca oprogramowania powinieneś także lepiej zapoznać się z inżynierią wymagań oraz z pozyskiwaniem, dokumentowaniem, analizowaniem i zarządzaniem wymaganiami stosownie do projektów oprogramowania - jest to naprawdę cenna umiejętność dla każdego, kto wykonuje pracę na dowolnym etapie cyklu życia oprogramowania.

Kiedy potrzebuję specyfikacji od nietechnicznego klienta, zazwyczaj proszę ich, aby napisali prostym językiem, co dokładnie chcą osiągnąć. Jak w „aplikacja powinna zrobić od A do B po naciśnięciu C, ale tylko jeśli D”. Dodatkowa premia za „ponieważ D oznacza, że ​​...”.

W rzeczywistości „weź tę kolumnę i przeprowadź nad nią średnią”. jest krokiem we właściwym kierunku. Lepszym wyjaśnieniem byłoby „Tabela zawiera to i tamto” (jeśli struktura jest predefiniowana); „Uzyskaj średnią X”. Zasadniczo jest to najmniej techniczny możliwy sposób bez utraty szczegółów.

Innymi słowy, opisz pomysł, a nie wdrożenie.

Wówczas troskliwy programista powinien być w stanie zrozumieć faktyczny cel tego, co mu zlecił, i sam wybrać właściwe kroki, zadając pytania na coś nieoczywistego.

Jeśli nie ma nikogo, kogo to obchodzi i nie rozumie procesu, projekt i tak się nie powiedzie.

Może spróbować użyć scenariusza .

Poproś go, aby spisał listę rzeczy ( opowiadań ), które aplikacja będzie musiała zrobić, i na tej liście, dopracuje funkcjonalność każdej opowieści.

Może użyć narzędzia takiego jak Asana, aby rozwinąć zakres projektu i funkcjonalność, a nawet wejść w interakcję ze swoim deweloperem.

Przełożenie go na jasne wymagania jest 10 razy więcej pracy niż wykonanie na wyraźnie napisanej specyfikacji.

Amen. To wyjaśnia również, dlaczego:

koder, którego wynajął, nie przejrzał narożników i nie zadał odpowiednich pytań.

Zrozumienie wymagań jest najtrudniejszą (i najdroższą) częścią większości projektów programistycznych. Kiedy osoba nietechniczna pisze wymagania, często dokumentuje tylko obejście, które chce zastąpić („otwórz Excel, kliknij komórkę B3 ...”). Najlepsze, na co mogą liczyć, to dokładna kopia aktualnego poziomu trudności!

Najbardziej produktywnym sposobem, w jaki wiem, jak to obejść, jest zachęcenie tej osoby do napisania przypadków użycia („używaj” rymów z „luźnymi”). Zamiast pisać wymagania, opisz, w jaki sposób system będzie używany. Pozostawia to programistom trochę miejsca na poruszenie, aby zaproponować lepsze rozwiązanie niż to, co robi teraz użytkownik.

Wygląda na to, że problem ten pogarsza słabe umiejętności komunikacyjne ze strony twojego przyjaciela. Musi on / ona wkładać pracę w skuteczne przekazywanie swoich pomysłów lub płacić programistom za wyciągnięcie z nich informacji. Oba procesy są bolesne i czasochłonne, ale robienie tego samemu jest tańsze niż płacenie komuś za to.

W każdym razie jest to powszechna i frustrująca trudność, gdy kreatywni ludzie albo mają niepełny pomysł, albo nie są w stanie opisać go w mniej niż milion słów. Ta osoba powinna spróbować znaleźć niezwykle cierpliwego i wnikliwego programistę, który jest gotów dotrzeć do sedna tego, co naprawdę próbuje zrobić i sprawić, by to się stało.

koder, którego wynajął, nie ... zadał odpowiednich pytań

To przepis na katastrofę. To, a także oczekiwania, o które prosi programista . Koderzy lubią kodować, a nie komunikować się, a oczekiwanie, że złamią swoje nawyki bez zachęty, jest dość nierealne.

Jeśli twój przyjaciel chce wykonać pracę, lepiej ustanowić proces obejmujący ciągłą komunikację z koderem - i to twój przyjaciel musi odgrywać aktywną rolę w tym, a nie koder. „Pokaż mi, co się robi w każdy poniedziałek, i ustal dwie godziny na omawianie tego w każdy wtorek”, takie tam.

• Na wstępie przekaż im kilka lekkich przeglądów iteracyjnych i zwinnych metodologii rozwoju (artykuły w Wikipedii zrobią), aby mogli poczuć, jak to powinno być.
   
• Aby pomóc im zrozumieć wcześniejsze niepowodzenia, dostarcz im kilka lekkich przeglądów Waterfall / Big Design Up Front (te, które zawierają krytykę - znowu, zrobią to artykuły z Wikipedii) - zwykle wykonują całkiem dobrą robotę, wyjaśniając, jak zwykle trudno jest właściwie określić rzeczy z przodu.

Z mojego doświadczenia wynika, że ​​najbardziej niezawodnym sposobem na uzyskanie wymaganej pracy oprogramowania z klientami nietechnicznymi była stała komunikacja i iteracja opisów funkcji, a nie próba określenia tego na śmierć za jednym zamachem.

Większość jego skryptów jest zorientowana statystycznie i na przetwarzanie danych. np. weź tę kolumnę i przeprowadź nad nią średnią. Usuń te rzędy w tych warunkach. Wyzwanie jest więc inne niż określenie aplikacji internetowej.

Jest inaczej - wydaje się o wiele prostsze niż określenie aplikacji internetowej. To logiczny proces. To jest łatwe.

Twój przyjaciel po prostu musi zapisać kroki, które wykonuje, gdy wykonuje ten proces. Może to zrobić, jak chce, ale najważniejsze są dokładność, zwięzłość i jasność. Nie ma powodu, dla którego nie można tego zrobić wyłącznie w tekście, takim jak rękopis; skorzystałby na logicznym podziale komponentów lub zadań i prawdopodobnie działałby dobrze jako schemat blokowy lub diagram.

Teraz twój przyjaciel powinien znaleźć kompetentnego analityka / programistę i zaangażować swoje usługi kawałek po kawałku. Musi przedstawić swoje oczekiwania - codziennie lub co najmniej kilka razy w tygodniu Twój przyjaciel powinien spotkać się z programistą i zobaczyć, jak wygląda postęp. Twój przyjaciel zapłaci programistom za poświęcony czas podczas tych demonstracji, ale warto będzie upewnić się, że projekt jest realizowany zgodnie ze specyfikacją. Wszelkie zmiany specyfikacji - tj. Rzeczy, które pomijał twój przyjaciel - muszą zostać wynegocjowane i prawdopodobnie dodane do podanej ceny.

Zauważ, że powiedziałem „kompetentny” - to nie to samo co „przeciętny”, ponieważ jest wielu „przeciętnych” programistów, którzy nie są kompetentni. Jeśli twój przyjaciel po prostu kupi najtańszy koder lub znajdzie kogoś w Internecie, powinien spodziewać się problemów. Nie sugerować, że ludzie, którzy znajdują pracę online, nie są dobrzy, ale nie zatrudniłbyś kogoś bez rekomendacji.

Twój przyjaciel musi po prostu znaleźć odpowiednią osobę. W każdym projekcie oprogramowania potrzebni są analitycy, programiści, administratorzy systemu, testerzy i kierownicy projektów. Im więcej z tych ról Twój przyjaciel chce „zlecić na zewnątrz”, tym bardziej wykwalifikowany będzie dostawca i tym więcej twój przyjaciel powinien oczekiwać.

Przykro mi, że to ja ci to przekazałem, ale nie jest zadaniem osoby nietechnicznej, aby nauczyć się pisać formalne specyfikacje. Zadaniem programisty jest przeprowadzenie wywiadu z osobą nietechniczną, próba wyjaśnienia, co ta osoba mówi do ciebie o tym, czego szuka, ustalenie, czego tak naprawdę chce klient (w przeciwieństwie do tego, co oni myślą, że chcą, co nie zawsze jest to samo), zbuduj stosunkowo nieformalny dokument wymagań (taki, który jest dobrze skonstruowany, ale który próbuje uniknąć żargonu, którego klient nie zrozumie) i przejrzyj ten dokument z klientem.

Gdy klient jest zadowolony z nieformalnego dokumentu wymagań, można go wykorzystać jako podstawę do opracowania bardziej formalnej specyfikacji wymagań, która zaczyna wchodzić w bardziej techniczne szczegóły na temat tego, co jest potrzebne.

Cały ten proces nazywany jest „przechwytywaniem wymagań” i stanowi pierwszy krok w procesie inżynierii oprogramowania. W rzeczywistości pisanie oprogramowania to tylko niewielka część inżynierii oprogramowania, o czym niestety zapomina wielu programistów. Inną rzeczą, o której wydają się zapominać, jest silna potrzeba komunikowania się z klientem i prowadzenia z nim dialogu podczas całego procesu, aby upewnić się, że wszystko idzie zgodnie z planem.

Jeśli chodzi o komunikowanie się z osobami nietechnicznymi, niezwykle ważne jest, aby unikać rozmawiania z żargonem dotyczącym rozwoju komputerów i oprogramowania. Jeśli używają terminów żargonowych z własnego pola, ważne jest, aby zrozumieć, co oznaczają te terminy, dlatego warto sporządzić glosariusz projektu, aby uzyskać formalne definicje tych terminów. W końcu dla nich pracujesz, więc ważne jest, aby zrozumieć, skąd pochodzą.

zamiast żargonu powinieneś wypróbować zastraszające sposoby komunikowania się z klientem, dokumenty napisane zwykłym językiem angielskim są pomocne, ale wiele osób z branży oprogramowania jest przyzwyczajonych do pisania na komputerach, a nie ludzi, więc może to znaleźć trudny. Ponadto klienci nie lubią czytać dużych stosów papieru, bez względu na to, jak prosty jest ich język, więc możesz skorzystać z pomocy wizualnych. Schematy, szkielety i storyboardy są tu przydatnymi narzędziami.

Krótko mówiąc, sedno sprawy polega na tym, że nauka języka nie jest zadaniem twojego klienta, ale Twoim językiem.