Czy Twoje oprogramowanie jest projektowane przez Kłapouchego?

Oryginalny post: Is Eeyore Designing Your Software?

Autor: Jeff Atwood

Ten klasyczny wpis Erica Lipperta w straszliwie boleśnie dokładny sposób opisuje to, ile pracy potrzeba, aby dodać funkcję ChangeLightBulbWindowHandleEx do kodu w Microsofcie:

  • Jeden programista, który poświęci pięć minut na implementację ChangeLightBulbWindowHandleEx.
  • Jeden program manager, który napisze specyfikację.
  • Jeden ekspert od lokalizacji, który przejrzy specyfikację pod kątem ewentualnych problemów z lokalizacją.
  • Jeden ekspert od użyteczności, który przejrzy specyfikację pod kątem problemów z dostępnością i użytecznością.
  • Przynajmniej jeden programista, tester oraz PM, aby przeprowadzić burzę mózgów odnośnie wrażliwości zabezpieczeń.
  • Jeden PM, który doda model zabezpieczeń do specyfikacji.
  • Jeden tester, który napisze plan testów.
  • Jeden kierownik testerów, który uaktualni harmonogram testów.
  • Jeden tester, który napisze przypadki testowe i doda je do nocnej automatyzacji.
  • Trzech bądź czterech testerów, którzy wezmą udział w spontanicznym poszukiwaniu błędów.
  • Jeden pisarz techniczny, który napisze dokumentację.
  • Jeden recenzent techniczny, który potwierdzi dokumentację.
  • Jeden edytor, który potwierdzi dokumentację.
  • Jeden menadżer od dokumentacji, który zintegruje nową dokumentację z istniejącym tekstem, uaktualni spis treści, indeksy, itp.
  • Dwudziestu pięciu tłumaczy, którzy przetłumaczą dokumentację i informacje o błędach na wszystkie wspierane przez Windows języki. Menadżerowie tłumaczów mieszkają w Irlandii (języki europejskie) oraz Japonii (języki azjatyckie), które to kraje są w zupełnie innych strefach czasowych niż Redmond, więc współpraca z nimi może być niekiedy dosyć złożonym problemem logistycznym.
  • Zespół starszych menadżerów do koordynowania pracy wszystkich tych ludzi, wypisania czeków i wyjaśnienia kosztów ich wiceprezesowi.

Myślę, iż czasem programiści zapominają, jak dużo pracy wymaga stworzenie oprogramowania w dużych firmach. Coś, co z zewnątrz może wydawać się nam oczywistą zmianą pięciu linijek kodu, w rzeczywistości wymaga pięciu osobo-tygodni pracy, kiedy wliczysz w to cały narzut związany z procesem. Wytykamy tutaj Microsoftowi, ale to nie znaczy, że tyczy się to tylko tej firmy; jest to prosta funkcja skali i odbiorców dla całego komercyjnego oprogramowania.

Tak więc oczywiste pytanie: kto robi wszystkie te rzeczy dla niekomercyjnego, open-source'owego oprogramowania? Odpowiedź, której udzielił Raymond Chen w komentarzu pod tym samym wpisem, to "nikt":

Kto rozwija plany testów dla oprogramowania open-source? Kto aktualizuje zrzuty ekranów w instrukcji użytkownika i pomocy online? Oraz kto tłumaczy dokumentację na polski i turecki? Kto weryfikuje, czy dana funkcjonalność nie łamie Amerykańskiej Ustawy o Niepełnosprawnych, bądź Niemieckich Praw odnośnie Prywatności? Wtedy, gdy pracowałem nad Linuxem, odpowiedzią było "Nikt. Nie ma czegoś takiego jak plan testów, drukowana instrukcja użytkownika, jedyną dokumentacją, jaka istnieje, to ta po angielsku, oraz nikt nie przejmuje się zgodnością z jakimikolwiek prawami." Może coś się pozmieniało od tamtego czasu.

Oto moje szczere pytanie: czy oprogramowanie open source potrzebuje procesu, aby odnieść sukces? Czy to nie jest tak, że radykalny brak narzutu procesowego w open source nie jest słabością, ale w zasadzie ewolucyjną zaletą? To, czego oprogramowanie open source nie posiada w odniesieniu do procesów, nadrabia wszechobecnością i społecznością. Innymi słowy, jeśli elbończycy kładą duży nacisk na lokalizację, sami mogą podjąć się tego wysiłku. W tym samym czasie, programiści mają więcej czasu na implementację funkcjonalności, które zachwycają największą część klientów, zamiast przedzierać się przez utrudnienia procesowe przy każdej, najmniejszej nawet zmianie kodu.

Czy duże firmy tworzące oprogramowanie są upośledzone przez własne procesy?

Jeśli otwarcie będziesz wynagradzał i promował ludzi za zabijanie pracy poprzez użalanie się nad ryzykiem, kosztem testów, wpływem lokalizacji na każdą z funkcjonalności oraz przerywanie żądania zmiany designu tak, jakby to był Dan Brown zakuty w kajdany przed wściekłym ze złości Papieżem, cóż, każdy złapie widły i krzyknie "Tak się nie da! Nie da się tak dostarczyć produktu!" - efekt Bandwagon murowany.

To zmusza mnie do zastanowienia się nad tym, ile miałem spotkań odnośnie funkcjonalności oraz nad tym, jak mały ich procent został kiedykolwiek wdrożony. To nie jest tak, że każda funkcjonalność to dobry pomysł, ale czasami jasno widać, że dana funkcjonalność powinna zostać zaimplementowana. Niczym Kłapouchy: "O nie. Teraz będziemy musieli to wspierać. Podejrzewam, że żądanie hotfixa może nadejść w każdej chwili.."

Aż za często wydaje się, że oprogramowanie od Microsoft jest zaprojektowane przez Kłapouchego.

Kłapouchy i ptak

W tym przypadku ptaszek reprezentuje funkcjonalności, które zachwycają klientów.

Data publikacji oryginału: 24 marca, 2008

1 komentarze:

Anonimowy pisze...

"Wściekłym ze złości"? :D

Prześlij komentarz

Related Posts with Thumbnails