Abstrakcja warstwy twórczej
From The Joel on Software Translation Project
Do miasta przybywa młody mężczyzna. Zasadniczo wygląda dość dobrze i ma mało pieniędzy w portfelu. Całkiem nieźle dogaduje się z kobietami.
Nie mówi zbyt wiele o swej przeszłości, lecz wyraźnie widać że spędził dużo czasu w bezdusznej, ogromnej firmie.
Jest z natury otwarty i przyjazny, wewnątrz zaś pewny siebie, ale nie arogancki. Nie ma więc problemu z podłapaniem kilku małych zadań z biuletynu pracy w lokalnej Kawiarence Programistycznej. Szybko jednak traci zainteresowanie w projektowaniu baz danych dla firm ubezpieczeniowych, próżnych stron www dla kur domowych oraz finansowych programów kalkulacyjnych.
Po roku przekalkulował sobie iż oszczędził dość pieniędzy na średnio dostajne życie przez kolejny rok. Więc, po konsultacji ze swym wiernym czworonogiem, zestawia swą maszynę w prześlicznie oświetlonym pokoju w mieszkanku wynajętym nad sklepem spożywczym i instaluje na niej głęboko przemyślany wybór oprogramowania.
Obdzwania swoich przyjaciół aby uprzedzić ich, iż jeśli wyda im się odseparowany przez następne kilka miesięcy, to tylko z powodu bardzo aktywnej pracy. Następnie siada i zaczyna pisać kod.
A czego by nie pisał, kod jego idealnym jest, artystyczny, elegancki, bezbłędny. Interfejs użytkownika tak idealnie podąża śladem myśli człowieczej że ludzie którym go prezentuje w Kafejce zapominają że w ogóle jest jakiś interfejs. Jego kod jest błyskotliwy.
Zachęcony przez swych kolegów, zakłada mają firmę i przygotowuje się do realizacji zamówień.
Wrodzona skromność ułatwia oczekiwanie, lecz po miesiącu sytuacja na koncie bankowym nie przedstawia się zachęcająco. Do tej chwili pojawiły się tylko trzy zamówienia: jedno od jego matki, jedno od anonimowego darczyńcy z Kawiarenki Programistycznej, i jedno które sam złożył, aby przetestować system dostawczy.
W następnym miesiącu przychodów brak.
Taki stan rzeczy zaskakuje go kompletnie i pozostawia w melancholii. W Wielkiej Firmie nowe produkty powstawały regularnie, i nawet jeśli były nieeleganckie i nieprzyjazne, wciąż sprzedawały się w sensownych ilościach. Jeden z produktów nad którym pracował okazał się wielkim hitem.
Kolejne kilka miesięcy, i jego prognoza finansowa zaczyna wyglądać źle. Jego pies patrzy na niego smutnie, może niekoniecznie rozumiejąc co jest źle, ale będąc świadomym ekspresji smutku na jego twarzy, a on sam wydaje się nie mieć sił aby wstać rano, wyjść z przyjaciółmi, iść na zakupy celem zapełnienia niebezpiecznie pustoszejącej lodówki, czy po prostu wykąpać się.
Pewnego wtorku sprzedawca z pobliskiego sklepu odmawia mu sprzedaży „na rachunek”, a jego bankier już dawno przestał odpowiadać na jego telefony.
Wielka korporacja nie jest mściwa. Potrafią poznać talent i chętnie zatrudniają go spowrotem, zwiększając płacę. W niedługi czas wygląda lepiej, ma nowe ubrania i starą pewność siebie. Ale coś, gdzieś... znikło, zginęło - błysk w oku; nadzieja, że mógłby stać się panem własnego losu, umarła.
Dlaczego poniósł klęskę? Jest całkiem pewny że rozumie „Marketing”, twierdzi. Jak wielu młodych techników, łatwo przychodzi mu rzec iż „Microsoft ma gorsze produkty lecz lepszy marketing”.
Wypowiedziane przez twórcę oprogramowania słowo „marketing” zazwyczaj oznacza wszystkie „sprawy biznesowe”: wszystko, czego tak do końca się nie rozumie o procesie tworzenia i sprzedaży produktu.
Lecz to, tak naprawdę, nie jest sensem słowa „marketing”. Tak właściwie Microsoft ma dość mierny marketing. Czy myślicie że te wielkie, puste postery reklamowe w rzeczywistości zachęcają kogokolwiek do zakupu pakietu Microsoft Office?
Oprogramowanie to dialog pomiędzy twórcą a użytkownikiem. Ale aby dialog ten zaistniał, potrzeba wiele, wiele pracy poza samym napisaniem programu. Marketing jest istotną sprawą, owszem, ale także sprzedaż, public relations, a także biuro, sieć firmowa, infrastruktura, poza tym klimatyzacja w biurze, także pomoc techniczna, księgowość i wór innych zadań i spraw.
Co tak naprawdę robią twórcy oprogramowania? Projektują i piszą kod, rozplanowują ekrany, debugują, integrują oraz wrzucają kod źródłowy do systemu zarządzania i kontroli źródeł.
Poziom na którym pracuje programista (np. Emacs) jest zbyt daleką abstrakcją aby mieć coś wspólnego z biznesem. Twórcy oprogramowania pracujący w warstwie abstrakcji potrzebują warstwy implementacyjnej – organizacji, która bierze ich kod programu i zamienia go w produkt. Dolly Parton, pracująca w warstwie „śpiewania ślicznej piosenki”, także potrzebuje ogromnej warstwy implementacyjnej – aby przygotować nagrania, zarezerwować hale koncertowe, przygotować bilety i sprzęt dźwiękowy, a wreszcie wypromować nagranie i zebrać profity.
Dowolna firma software’owa która ma przynosić profity składać się będzie z małej warstwy twórców (tworzących oprogramowanie), rozłożonej na wierzchu wielkiego abstraktu organizacyjnego.
Abstrakcja ta istnieje po to, aby stworzyć iluzję iż codzienne zadania programisty (projektowanie i pisanie kodu, sprawdzanie w kodzie, debugowanie itp.) to jedyne czego potrzeba aby stworzyć produkt i posłać go na rynek. Co z kolei prowadzi mnie do idei tego eseju:
Większość „świeżych" menedżerów zapomina o tym punkcie. Myślą tradycyjnymi schematami Command-and-Conquer (Rozkazuj-i-Podbijaj) których nauczyli się z filmów Holywoodzkich.
Według schematu Command-and-Conquer, menedżerzy-slesz-przywódcy określają kierunek rozwoju biznesu, po czym wydają stosowne rozkazy do swych poruczników aby poruszyć firmę w określonym kierunku. Porucznicy z kolei dzielą te zadania na mniejsze części i rozdają je swym podwładnym celem ich rozporządzenia. Taka struktura istnieje aż do samego „dołu” organizacji, gdzie ktoś na szarym końcu tak naprawdę wykonuje jakąś pracę. W tym modelu programista jest trybikiem w maszynie: pisarczykiem który wykonuje część rozkazów zarządzania.
Istnieją firmy które tak pracują. Bardzo łatwo jest je rozpoznać, głównie po tym, że ich reprezentant wykonuje bezmyślne i denerwujące czynności, i wie o tym, i może nawet go to martwi, ale nic z tym nie może zrobić. To wielkie linie lotnicze które na zawsze tracą wielokilometrowego klienta odmawiając mu zamiany bezzwrotnego biletu, gdy ten musi wracać do domu z powodu nagłego wypadku rodzinnego. To dostawcy usług internetowych, których sieci częściej leżą niż nie, i którzy, gdy anulują twoje konto, nadal wysyłają ci kolejne rachunki, i kolejne, i tak dalej, ale gdy dzwonisz aby o tym narzekać, musisz połączyć się z płatną linią i czekać jakąś godzinę, a i tak odmawiają refundacji dopóki nie stworzysz bloga, na którym będziesz pisać jak bardzo są do dupy. To twórcy samochodów z Detroit którzy dawno już zapomnieli jak się projektuje samochody, i przechodzą od jednej strategii marketingowej do drugiej, tak jakby jedynym powodem dla którego nikt nie kupuje ich okropnych samochodów był zbyt niski rabat.
Dość.
Darujmy sobie. Hierarchia rozkazów zarządzania została wypróbowana, i zdała się działać jakiś czas w latach dwudziestych przeciw małym konkurentom, ale nie wystarczy dla modelu biznesu wieku dwudziestego pierwszego. Firmy komputerowe muszą użyć innego modelu.
W firmie software’owej pierwszym priorytetem zarządzania musi być stworzenie owej abstrakcji dla programistów.
Jeśli programista w którymś momencie martwi się zepsutym krzesłem lub wisi na telefonie z firmą Dell usiłując zamówić nowy sprzęt, w abstrakcji powstała dziura.
Pomyśl o swej warstwie abstrakcji jak o wielkim, przepięknym jachcie z niewyobrażalnie mocnymi napędami. Jest przecudnie utrzymywany. Dania i drinki są serwowane ze szwajcarską precyzją. Pokoje są sprzątane i przygotowywane przez służki dwa razy dziennie. Mapy nawigacyjne są zawsze precyzyjne i aktualne. Systemy GPS i radaru zawsze działają, a gdyby się zepsuły – pod pokładem są zapasowe. Na mostku stoją programiści którzy tak naprawdę myślą tylko o prędkości, kierunku i tym, czy chcą na lunch tuńczyka czy łososia. W międzyczasie zespół profesjonalistów w sztywnych, lśniących bielą uniformach krąży na paluszkach pod pokładem pilnując, aby wszystko sprawnie pracowało – napełniając zbiorniki paliwowe, zdrapując skorupiaki, krochmaląc serwetki na lunch. Zespół ten wie co ma robić, lecz odbiera swe wytyczne od starego pryka który zawsze jakże delikatnym skinieniem wskazuje zadania, koordynując symfonię tak aby programiści mogli abstrahować od wszystkiego związanego z jachtem – poza prędkością, kierunkiem oraz tym, czego chcą na lunch.
Zarządzanie w firmie software’owej jest przede wszystkim odpowiedzialne za tworzenie abstrakcji dla programistów. My budujemy jacht, my serwisujemy jacht, my jesteśmy jachtem, ale nie my nim sterujemy. Wszystko co robimy sprowadza się do utrzymywania ciągłej abstrakcji dla programistów tak, aby ci mogli pisać świetny kod, który trafi w ręce użytkowników końcowych.
Programiści potrzebują Systemu zarządania i kontroli źródeł. System ten oznacza iż potrzebujesz sieć, serwer który musi być kupiony, zainstalowany, mieć kopię zapasową i system zasilania awaryjnego, oraz to że taki serwer generuje dużo ciepła, co oznacza że musi być w pomieszczeniu ze specjalną klimatyzacją, i że klimatyzator musi mieć dostęp na zewnątrz budynku, co z kolei oznacza instalowanie osiemdziesięciofuntowego wentylatora na ścianie na zewnątrz budynku, co denerwuje właścicieli posesji na tyle aby przyprowadzili własnego technika który znajdzie miejsce na jego montaż (decyzja: na zewnętrznej ścianie, tu na górze na osiemnastym piętrze, w najmniej dostępnym miejscu), i że właściciele wmieszają w to swych prawników, gdyż będziemy musieli sprzedać swego pierworodnego aby móc to wszystko zrobić, a później pojawia się zespół instalacyjny ze sprzętem tak prymitywnym, że pasowałby do zestawu Barbie, co znów denerwuje brygadzistę, który nie pozwala im wspinać się na osiemnaste piętro w uprzęży Mattel wykonanej z półcalowego, różowego plastiku, i przysięgam na Boga że mógłby to być pas dyskotekowy Barbie, i ktoś musi znów zadzwonić po agenta budowlanego aby okazało się że po dwunastu miesiącach konstrukcji klimatyzatora potrzebny będzie dopisek do kontraktu, o którym wiadomo było przed świętami Bożego Narodzenia a dopiero teraz ktoś wpadł na to że będzie potrzebny, i jeśli twój programista spędzi chociaż jedną minutę na zastanawianiu się nad tym wszystkim, jest to jedna minuta za dużo.
Dla twoich programistów musi to być wyabstrahowane tak, aby sprowadzało się do wpisania svn commit w linii poleceń.
Właśnie po to mamy struktury zarządzania.
Dla tych wszystkich rzeczy których żadna firma nie może ominąć – ale jeśli twoi programiści martwią się nimi, cóż – zarządzanie zawiodło, tak samo jak 100-stopowy jacht zawiódł jeśli jego wielomilionowy właściciel musi zejść na dół do siłowni i, hm... zbudować silnik.
Z jednej strony masz typowe firmy tworzone przez byłych sprzedawców oprogramowania, gdzie wszystko sprowadza się do Sprzedaży, i wszyscy istniejemy aby podbijać Sprzedaż. Takie firmy łatwo zidentyfikować po tym, że budują wersję 1.0 swojego produktu (jakimś cudem), po czym kompletnie tracą zainteresowanie oprogramowaniem. Ich zespół twórczy jest zagłodzony lub nie istnieje gdyż nikomu nigdy nie przyszło do głowy aby pracować nad wersją 2.0.... Wszystko, czym zarządzanie się martwi – to Sprzedaż.
Z drugiej strony szali masz typowe firmy software’owe tworzone przez byłych programistów. Takie firmy trudniej znaleźć gdyż w większości przypadków są małe i ciche, polerują swój kod gdzieś w zaciszu, którego nikt nigdy nie znajduje, i zanikają równie cicho w nieistnieniu zaraz po stworzeniu Great Ruby Rewrite, ich zmieniającego wizję świata, samorefaktoryzującego się dzieła, jakoś dziwnie niedocenianiego przez Klientów.
Oba typy firm mogą z łatwością być wymiecione ze sceny przez firmy napędzane przez programistów i organizowane tak, aby programiści siedzieli „za kółkiem”, lecz posiadające „pod maską” świetne abstrakcje które odwalają całą robotę związaną z zamianą kodu na produkt.
Programista pracuje najproduktywniej w cichym, prywatnym biurze ze świetnym komputerem, nielimitowanymi napojami, stałą temperaturą otoczenia w okolicach między 68 i 72 stopni (F), bez odbłysków na ekranie, na krześle które jest tak wygodne że się go nie czuje, z administratorem który przynosi mu pocztę i zamawia manuale i książki, administratorem systemowym który dba o to aby internet był równie dostępny jak tlen, testerem który widzi błędy których on sam nie widzi, projektantem graficznym który sprawia że jego ekrany są prześliczne, zespołem marketingowym który sprawia że masy pragną jego produktów, zespołem sprzedawców którzy upewniają się że masy dostaną jego produkty, kilkoma świętymi w pomocy technicznej którzy pomagają klientom w konfiguracji i eliminacji błędów i pomagają programistom zrozumieć jakie błędy generują te wszystkie telefony, no i z następnym worem funkcji zarządzających i administrujących, które łącznie sumują się w okolicach 80% listy płac. To nie przypadek że Rzymska armia miała stosunek czterech pomocników na jednego żołnierza. To nie oznaka dekadencji. Dzisiejsze armie pracują zapewne w proporcjach 7:1. (Coś czego nauczyłem się dziś od Pradeep Singh: jeśli tylko 20% twego zespołu to programiści, i możesz zaoszczędzić 50% pieniędzy z wypłat przez zatrudnienie programistów z Indii, cóż, ile prawdziwej mocy rywalizacyjnej uzyskasz z tych 10% oszczędności?)
Podstawowym zadaniem zarządzania jest stworzenie iluzji iż firma software’owa może być napędzana pisaniem kodu, gdyż to właśnie robią programiści. I chociaż fajnie byłoby mieć programistów którzy świetnie sobie radzą w sprzedaży, projektowaniu grafiki, administracją systemami i gotowaniu, jest to nierealistyczne. Tak jak próbując nauczyć świnię tańca, marnotrawisz czas i denerwujesz świnię.
Microsoft radzi sobie świetnie z tworzeniem takich abstrakcji, tak świetnie że naśladowcy mają naprawdę ogromne problemy rozwijając własny biznes. Wielokrotnie nie mogą wprost uwierzyć jak dużo pracy włożono w organizację „pod pokładem”, i nie mają absolutnie żadnych idei jak taki proces odtworzyć u siebie.
Nikt nie oczekuje aby Dolly Parton umiała wpiąć mikrofon. Istnieje niewiarygodna infrastruktura menadżerów, muzyków, techników studyjnych, firm nagraniowych, fryzjerów i publicystów, którzy istnieją dla stworzenia abstrakcji, że jedyne czego potrzeba aby miliony fanów ją usłyszały – to jej śpiew. Wszystkie te funkcje pomocnicze i zarządzające, które „tworzą” Dolly Parton, robią najwspanialsze rzeczy aby stworzyć najbardziej idealną abstrakcję: perfekcyjną iluzję że Dolly śpiewa dla nas. To jest jej piosenka. Kiedy słuchasz Dolly na swoim iPodzie, istnieje ogromna infrastruktura której zadaniem jest umożliwić tobie właśnie to, ale najlepsze co może ta instrastruktura zrobić to zniknąć kompletnie z oczu. Stworzyć jednolitą abstrakcję że Dolly Parton śpiewa – prywatnie – dla nas.
