Tego ranka miałem interesującą rozmowę z Doc'iem Nortonem. Skłoniło mnie to do rozmyślań...
Wiesz co to jest numer 800. Niektórzy ludzie nazywają je "bezpłatna infolinia". Firma Telekomunikacyjna nazywa je liniami WATS.
Wide Area Telephone Service.
Poniższy tekst jest luźnym tłumaczeniem wpisu bloga Roberta Cecila "Wujka Boba" Martina ze strony :
Proszę o komentarze, jeżeli ta luźność jest zbyt daleko posunięta.
W roku 1976 podjąłem pracę w firmie na przedmieściach Chicago. Nazywała się Teradyne Central. Robiliśmy sprzęt testujący dla firmy telekomunikacyjnej. Nasz produkt nazywał się 4-Tel. Testował każdą linię telefoniczną, w jednym obszarze świadczenia usług, każdej nocy. Jeden obszar świadczenia usług telefonicznych mógł mieć 100'000 linii lub więcej.
System 4-Tel mógł mieć podłączonych do niego jednocześnie 21 terminali. Każdy terminal mógł był użyty przez testera do testowania linii telefonicznej gdziekolwiek w obszarze świadczenia usług. Test mógł wykryć i zdiagnozować dowolne problemy tych linii; i mógł określić czy dany problem jest po stronie centrali, samej linii czy telefonu klienta. To było ważne, ponieważ te trzy tematy były rozwiązywane przez oddzielne zespoły. Wysłanie odpowiedniego zespołu do odpowiedniego problemu pozwalało oszczędzić dużo pieniędzy.
4-Tel miał wiele innych fajnych funkcji. To był pokaźny system z wieloma przypadkami użycia. I był zainstalowany na obszarze całych Stanów Zjednoczonych.
Kiedy jeden z naszych klientów miał problem, mógł zadzwonić pod numer 800. To automatycznie przełączało go do jednej z dwóch naszych linii WATS. Jeżeli to było w czasie normalnych biznesowych godzin pracy, nasza recepcjonistka odebrałaby linię WATS. Gdy już upewniłaby się, że to klient dzwoni z prośbą obsługi serwisowej, prosiłaby o chwilę cierpliwości i mówiłaby przez nasz wewnętrzny system do powiadamiania:
Czy ktoś z oprogramowania mógłby odebrać WATS linię 54.
Kiedy to było już po godzinach, my, w laboratorium, mogliśmy tylko słyszeć dzwonek linii WATS.
Nie ważne, która to była godzina, zawsze odbieraliśmy.
Było nas około tuzin w zespole programistycznym. Szukalibyśmy najbliższego telefonu z migającą lampką oznaczoną "54". Ktokolwiek był najbliżej telefonu odebrałby telefon. Gdybym to był ja, powiedziałbym:
Teradyne Central Oprogramowanie: Mówi Bob Martin.
I wtedy zaczęlibyśmy procesować problem, i poradzilibyśmy klientowi, co robić.
Czasami, oczywiście, to był błąd pilota, który mogliśmy szybko naprawić. Czasami to był znany problem w naszym systemie, dla którego mogliśmy przedstawić obejście. I czasami to był nowy defekt lub problem, który musieliśmy zdiagnozować na miejscu.
Tak czy siak wisieliśmy na telefonie z klientem dopóki problem nie został rozwiązany.
Inżynierowie Odpowiedzialni
Może mógłbyś zapytać dlaczego nie mieliśmy działu obsługi klienta załatwiającego tego typu telefony; i wpisującego defekty w system śledzenia defektów. Odpowiedź do tego jest prosta. Czuliśmy się odpowiedzialni za system. Chcieliśmy wiedzieć czego doświadczają nasi klienci. Nie chcieliśmy mieć warstwy ludzi izolujących nas od problemów, które to my tworzyliśmy w terenie.
Mieliśmy taki termin w Teradyne: Inżynier Odpowiedzialny. To był podtytuł po linią podpisu na każdym Inżynieryjnym Zleceniu Zmiany. My podpisywaliśmy się pod zmianami, które robiliśmy. My byliśmy Inżynierami Odpowiedzialnymi.
Takie znaczenie miał właśnie dla nas ten termin. My czuliśmy się odpowiedzialni. I dlatego nie chcieliśmy czegokolwiek izolującego nas od rzeczywistych sytuacji naszych klientów.
W Teradyne prowadziliśmy nasz własny QA. Robiliśmy nasze własne
DevOpsy. Robiliśmy naszą własną obsługę klienta. I często podróżowaliśmy do lokalizacji klienta żeby pracować z inżynierami Obsługi w Terenie.
W rzeczywistości, to była częsta praktyka dla każdego developera oprogramowania, żeby spędzić dzień lub dwa jeżdżąc z monterem telefonicznym; tylko po to, byśmy mogli zrozumieć, z czym ci goście musieli się mierzyć i jak oni naprawdę używali naszego systemu.
Izolacja
Współczesne zespoły programistyczne są zwykle mocno odizolowane. Żyją w świecie wolnym od rozproszeń pochodzących od klientów i ich "drobnych" problemów. Istnieją całe grupy ludzi, które służą izolowaniu programistów od prawdziwego świata. Dział Obsługi Klienta. Dział Jakości. DevOps. Proszę bardzo, do wyboru do koloru. I dlaczego te grupy w ogóle istnieją? Istnieją, ponieważ we wszystkich z tych dziedzin developerzy oprogramowania zawiedli tak bardzo, że firmy musiały się bronić tworząc całe nowe departamenty i struktury zarządcze.
Myślę, że to jest wstyd. Jak możesz być rzemieślnikiem oprogramowania, jeśli nie porozumiewasz się ze swoim prawdziwym klientem? Jak możesz być rzemieślnikiem oprogramowania, jeśli nie doświadczasz bezpośrednio tych koszmarów, które tworzysz dla devopsów? Jak możesz być rzemieślnikiem oprogramowania, jeśli zostawiasz wszystkie swoje bugi do znalezienia dla działu QA?
Rzemiosło Oprogramowania
Wydaje mi się, że rzemieślnik oprogramowania jest Inżynierem Odpowiedzialnym. Rzemieślnik Oprogramowania nigdy nie będzie odizolowany od prawdziwego świata klienta, od devopsów, od QA, od czegokolwiek jeszcze. Do obowiązków zespołu rzemieślników oprogramowania powinno zaliczać się QA; powinno zaliczać się devops; powinno zaliczać się obsługę klienta. I każdy członek takiego zespołu powinien być zdolny zastąpić każdego innego członka zespołu.
Nie ma nic złego w specjalizacji. Jest wiele złego w izolacji.
Powyższy tekst jest luźnym tłumaczeniem wpisu bloga Roberta Cecila "Wujka Boba" Martina ze strony :
Proszę o komentarze, jeżeli ta luźność jest zbyt daleko posunięta.
