Ponieważ kontynuujemy dyskusję na temat programowania obiektowego w WordPressie, ważne jest, abyśmy nie wyprzedzali samych siebie, jeśli chodzi o tworzenie produktu dla kogoś innego.
Tak często łatwo jest:
- usłyszeć, co mówi klient,
- zbudować coś na podstawie tego, co usłyszeliśmy,
- przekaż go wspomnianemu klientowi.
Ale jest w tym o wiele więcej. Trochę tańczyłem wokół tego w poprzednich postach z tej serii; jednak chciałbym zacząć drążyć do tego, co to znaczy słyszeć:
- Co mówi klient,
- Opracuj zestaw wymagań,
- A następnie stwórz wokół tego pętle sprzężenia zwrotnego.
Ostatecznie chcemy mieć pewność, że ludzie, dla których pracujemy i rozwiązania, które tworzymy, naprawdę są rozwiązaniami, a nie przeszkodami lub przeszkodami, przez które muszą przeskoczyć.
Co więcej, myślę, że nie wystarczy, aby klient po prostu cieszył się doświadczeniem swojego produktu końcowego, ale również z pracy z jednym (lub tymi) budującymi rozwiązanie.
Powiedziawszy to, przyjrzyjmy się, co to znaczy słuchać tego, co mówią i stamtąd wyjść.
Zrozumienie oczekiwań klientów
Za każdym razem, gdy czytasz książki lub inne materiały dotyczące tego rodzaju rzeczy, często sprawia to, że jedna z dwóch stron staje się „złym facetem". Nie zawsze, ale czasami sprawia, że:
- klient wydaje się ignorantem, o czym mówi,
- lub sprawia, że programista wydaje się być palantem, ponieważ zachowuje się jak ktoś, kto wie więcej na dany temat.
A co z trzecią opcją, w której klient ma jasny obraz tego, czego chce, a programiści są gotowi słuchać i współpracować z klientem, aby coś zbudować?
Jasne, po drodze nastąpią wyjaśnienia i będą musiały zostać zdefiniowane terminy, a pewna „rekalibracja” kalendarza rozwoju może nawet być tego częścią.
Ale najważniejsze jest to: żadna partia nie powinna działać przeciwko drugiej. Zamiast tego chodzi o wspólną pracę nad rozwiązaniem. Jasne, wymaga komunikacji (w czym programiści nie zawsze są świetni, z mojego doświadczenia, ale nie ma powodu, dla którego nie może być lepiej).
Co mówi klient? (Co mówi programista?)
Ilekroć się spotykacie, prawdopodobnie myślicie o tym samym, ponieważ każdy z was mówi innym językiem i każdy z was myśli, że to drugie powiedzenie jest żargonem.
I to nie jest złe.
Klienci mają sposób na mówienie o tym, czego chcą, a programiści mają sposób na mówienie o tym, jak będą dostarczać.
Warunki, których używamy
Ale może być wspólny cel.
Postaraj się o opis problemu, który próbujesz rozwiązać. Postaraj się to zrobić w kategoriach laików, aby projekt był zgodny z celem i funkcjonalnością rozwiązania.
Nie sądzę, czy to zadziała dla wszystkich, ale jest to pierwsza rzecz, którą polecam zrobić, gdy siedzisz z klientem.
Jak zobaczysz w dalszej części tych postów, warto opracować kilka zdań, których możesz użyć na początku swojej pracy, do których możesz się odwołać za każdym razem, gdy podejmujesz decyzję.
Innymi słowy, Ty (i oni) możecie zapytać:
Czy to, nad czym pracuję, przyczynia się do wspólnego celu?
I tutaj możesz określić podstawowy zestaw wymagań.
„To musi…”
Jeśli chodzi o kupowanie czegoś, budowanie czegoś, proszenie o coś, pragnienie czegoś lub cokolwiek innego, dość łatwo jest zacząć od zdania „Chcę, aby…”
Ale jest duża różnica między „chcę to zrobić [zrobić coś]” a „potrzebuję tego [aby coś zrobić]”, a kiedy pracujesz w oprogramowaniu, ogólnie można śmiało powiedzieć, że rzeczy, które są potrzebne, są kluczowe. do aplikacji. A rzeczy, które są pożądane, to to, co przychodzi po zbudowaniu fundamentów aplikacji.
To znaczy, jest to rozmowa o „trzeba mieć” i „chcę mieć”. I ważne jest, aby prowadzić rozmowy, aby można było dojść do ostatecznego stwierdzenia wspólnego celu aplikacji.
Gdy to nastąpi, możesz rozpocząć planowanie oprogramowania wokół problemu klienta. I tu w grę wchodzi zbieranie wymagań.
Opracowywanie wymagań
To, co Ty i klient dobrze rozumiecie, co należy zbudować, to czas na zestawienie wymagań.
Ta część może być fajniejsza niż się wydaje. Wiem, wiem: brzmi jak praca domowa lub jakieś zadanie, prawda? Ale nie jest. Zamiast tego bierze to, czego chcą, co rozumiesz, tłumaczy na wspólny język, a następnie pisze dokument wyjaśniający, co zrobi oprogramowanie.
Jednak w zależności od twojego doświadczenia może to być nudne. A przez nudę mam na myśli jedną z najgorszych części twojej pracy. Poza tym wymagania zawsze się zmieniają, prawda?
Nie zawsze.
Jeśli poświęcisz trochę czasu, aby zrozumieć, czego chcą od samego początku, wymagania nie muszą być 50-stronicowym dokumentem opisującym, jak każdy pojedynczy moduł ma działać.
Wiele książek dokumentuje to jako mówiące, że tak właśnie musi być. Ale w ciągu prawie dekady robienia tego, nigdy nie miałem czegoś tak długiego, a klienci generalnie byli niesamowicie wdzięczni, gdy zobaczyli krótką listę, którą można poprawić za pośrednictwem poczty e-mail lub Dokumentów Google, podpisać, a następnie nazwać przenoszeniem projektu Naprzód.
Porozmawiam o tym więcej w przyszłości, ale niezależnie od tego, jakie masz złe doświadczenia, boisz się lub niepokoisz, nie musisz siedzieć. Będziemy o tym rozmawiać w tej serii.