” Prośba o funkcję!!!”
często jest to okrzyk bojowy, którego używamy, aby bagatelizować pilność problemu klienta. W końcu nie ma czasu na dodawanie nowych funkcji, gdy patrzymy na niekończący się dziennik błędów, który stoi przed nami.
dla amerykańskich inżynierów oprogramowania różnica między błędem a żądaniem funkcji jest krystalicznie jasna. Błąd jest rozbieżnością między tym, jak faktycznie działa kod, a tym, jak nasz kod miał działać. Żądanie funkcji wymaga nowego kodu, aby zaspokoić sprawę, która nie może być obsługiwana przez bieżący kod.
ten rodzaj procesu myślowego zawsze prowadzi nas do bardziej ogólnego pytania o to, jak powinno być używane oprogramowanie takie jak DoneDone. Czy Twoja organizacja powinna używać jednego typu oprogramowania do rejestrowania błędów, innego typu oprogramowania do zarządzania nadchodzącymi zadaniami i jeszcze innego typu oprogramowania do śledzenia żądań funkcji?
spędzamy dużo energii psychicznej próbując przesiać problemy rejestrowane przez Klienta lub klienta, próbując ustalić, czy wrzucimy problem do wiadra” bug”, czy” feature request”. W przypadku prac konsultacyjnych, kiedy pracujemy nad wstępnie zdefiniowaną umową o zachowaniu oprogramowania, ma to sens. Wnioski fabularne mogą wymagać dodatkowej opłaty.
ale jeśli chodzi tylko o czystą praktykę budowania dobrego oprogramowania, szczególnie jeśli pracujemy nad własnymi produktami, jak bardzo powinniśmy dbać o kategoryzację problemu w ten sposób?
pozwalamy technikom (i technikom) przeszkadzać w rozwiązywaniu problemów.
Robert Martin (a.k.a. Uncle Bob) mówi dużo o oprogramowaniu. Uważa on, że sieć jest jedynie mechanizmem dostarczania i niczym więcej. Nie jest to doświadczenie użytkownika końcowego i nie jest to cel oprogramowania. To tylko mały, głupi szczegół. Kiedy jednak programujemy my, programiści, na architekturę naszych aplikacji ma zbyt duży wpływ fakt, że jest to aplikacja internetowa.
w ten sam sposób, co jeśli weźmiemy pod uwagę termin, którego używamy do „rzeczy, które muszą zostać zrobione”, aby być głupim szczegółem?
z punktu widzenia osoby rejestrującej to „coś”, czy naprawdę ma dla niej znaczenie, że żąda nowej funkcji, a nie odkrywa błędu? Ona po prostu chce, aby jej problem został rozwiązany przez innego człowieka, a najlepiej, aby wiedzieć, kiedy jej problem może zostać rozwiązany.
możesz być w stanie zobaczyć szczegóły techniczne bardziej wyraźnie, jeśli opuścimy świat oprogramowania. Kiedy hydraulik przychodzi naprawić nieszczelny prysznic, wyobrażam sobie, że nie dbasz o szczegóły. Jeśli głowica prysznicowa została nieprawidłowo zainstalowana (błąd) lub jeśli uszczelka jest uszkodzona (błąd) lub jeśli brakuje taśmy teflonowej w taniej rurze (funkcja), wszystko, co zależy od tego, jak długo zajmie Naprawa i ile będziesz obciążony.
błąd lub żądanie? To i to. I to bez znaczenia.
w zeszłym tygodniu jesteśmy Mamut wydany kin, narzędzie HR oprogramowanie dla małych firm. Kin daje prosty sposób na śledzenie wniosków o Czas Wolny każdego pracownika. Jedna rzecz, której Kin nie robi teraz, to odróżnianie weekendów i świąt od dni roboczych. Tak więc, jeśli chcesz zdjąć cały tydzień w Święto Dziękczynienia, musisz ręcznie wprowadzić liczbę godzin, o które prosisz.
zespół otrzymał już kilka próśb o automatyczne śledzenie krewnych. W rzeczywistości jest w kolejce wydania. Ale kiedy jest zalogowany, w dowolnym miejscu, w którym jest zalogowany, czy zespół Kin powinien uznać to za błąd, żądanie funkcji, zadanie lub zadanie?
dzwoniąc do mojego wujka Boba, moja odpowiedź jest prosta: nie ma znaczenia, jak sklasyfikować prośbę. To tylko głupi szczegół.
to nie znaczy, że w ogóle nie powinniśmy go klasyfikować. Zespół Kin może oznaczyć problem jako „żądanie funkcji” i najpierw popracować nad naprawieniem bardziej krytycznych problemów (takich jak użytkownik z problemem autoryzacji). To jest dobre i eleganckie, i słuszne podejście.
jednak błędem byłoby automatyczne zakładanie, że wszystkie żądania funkcji są mniej pilne niż wszystkie błędy. To czyni raczej drobny szczegół tego, jak klasyfikujemy problem centralnym punktem, gdy go rozwiązujemy. Nie powinno tak być. Ostatecznie wszystkie te prośby są po prostu rzeczami, które wymagają rozwiązania.
niech techniczna będzie głupim szczegółem
w tym celu Etykieta, którą dajemy wszystkim tym żądaniom, jest w dużej mierze nieważna. Ważniejsze jest to, że ktoś się nimi zajmuje i istnieje ogólna idea, kiedy te prośby zostaną rozpatrzone. Ważniejsze jest to, że 33% więcej użytkowników skorzysta na tym, że punkt A jest adresowany w porównaniu z punktem B. niezależnie od tego, jaki rodzaj rzeczy jest punkt A lub punkt B, punkt A jest bardziej wartościowy do adresowania. To wszystko. Nic więcej.
więc następnym razem, gdy spędzasz zbyt dużo czasu na kategoryzowaniu zadań, błędów, żądań funkcji i zadań, pamiętaj, aby zapomnieć o szczegółach technicznych. To tylko głupie szczegóły.
Zarejestruj konto DoneDone w 30 sekund. Chcesz przeczytać więcej o Ka Wai Cheung? Nowa książka Ka Wai na temat współczesnego programisty, Kod programisty, jest dostępna w ebooku i druku. Możesz śledzić go na Twitterze @ developerscode .