Poprzedni filmik parę osób zaciekawił, pozwolę sobie zatem wkleić następny. Jason Fried zastanawia się czemu tak trudno pracować w pracy, czemu wielu osobom łatwiej zrobić coś konkretnego w domu, samolocie, restauracji, gdziekolwiek tylko nie w tym głównym najważniejszym miejscu. W biurze są dwie rzeczy, których nie ma nigdzie indziej - kierownicy i spotkania.

Sposób, który wygląda na idealne rozwiązanie problemu programującego durnia. Zaplanować, opisać, udokumentować, przeszkolić. Analizę robimy tak, projekt techniczny siak, kod piszemy owak, testy według formalnego planu w iluś tam etapach, release według checklisty. Wszędzie oczywiście szczegółowe zalecenia - od spisu dokumentów i raportów po 9432 szczegółowe zalecenia co do formy kodu.

Będzie wiadomo co i jak trzeba robić, to każdy będzie mógł te operacje wykonywać.

Prywatny, zamykany pokój dla każdego to abstrakcja. To rozwiązanie dla Google i innych bogaczy albo dla dziwacznie postępowych firm.

Ale gdyby tak wziąć jeden pokój w biurze, nawet w takim nienajlepszym, byle miał szczelne drzwi i w przyzwoicie izolujące ściany. I gdyby powiesić na drzwiach taką kartkę:

Najpierw jest lista rzeczy do zrobienia. Z czasem robi się bardzo długa, więc wyróżniona z niej zostaje lista rzeczy pilnych. Na ich bazie powstaje wykaz spraw najpilniejszych. Później absolutnie priorytetowych.

A na koniec i tak liczy się, kto akurat zawiśnie na telefonie albo stanie nad głową.

O motywacji rozpisywałem się już parokrotnie (min. pisząc o pracy na sztukę, o tym co jest fajnego w informatyce czy o tym po co się chodzi do pracy). Temat jakoś mocno mnie męczy, może dlatego, że sam swoją motywację muszę odbudować...

W każdym razie, dzisiaj nie będę się rozpisywał, za to wkleję filmik.

Jesteśmy (my, programiści) zafascynowani procesem, w którym systemy informatyczne się rodzą. Organizacja pracy, metody, narzędzia, wzorce, języki, plany. Byle dotrzeć do magicznego 1.0 (choćby i beta). Byle dostarczyć. Byle uruchomić.

Coraz lepiej uświadamiamy też sobie, że to nie koniec, że po rozruchu aplikacje żyją dalej. Uczymy się, jak je tworzyć, by ewolucja była możliwa, by 1.0 było fundamentem a nie ostatnim krokiem. Rozważamy różne modele rozwojowe.

Głupie pytanie. Gdzieś trzeba zarabiać!

To naturalna odpowiedź, ale brzmi w niej fałszywa nuta.

W mojej pierwszej pracy przez co najmniej rok właściwie nie interesowałem się, ile zarabiam. Dużo bardziej zajmujące było co i z kim robię. Później kiepskie zarobki zaczęły trochę ciążyć ale byłem na tyle przywiązany do zespołu i na tyle zaabsorbowany realizowanymi projektami, że odszedłem dopiero, gdy firma w szale reorganizacji rozbiła jedno i drugie.

Poniższy materiał podobno wyciekł z firmy Netflix (gdzie był/jest używany jako informator dla pracowników). Dawno nie widziałem prezentacji, która poruszałaby w zwarty i czytelny sposób tak wiele ważnych tematów, dlatego - niezależnie od pewnej rezerwy, jaką zawsze odczuwam widząc hasła o zatrudnianiu tylko najlepszych - bardzo zachęcam do przejrzenia.

Spotkania biznesowe. Rytuał, obyczaj, metoda, narzędzie.

Był czas, gdy byłem podekscytowany i przejęty. Szansa, by posłuchać (z czasem i podyskutować) o ważnych dla zespołu czy firmy kwestiach.

Był czas, gdy desperacko unikałem.

Dziś znowu widzę, że są potrzebne. O trudnych czy przełomowych sprawach trzeba powiedzieć, nie wystarczy napisać - tak już chyba jesteśmy skonstruowani.

Ale bardzo często wychodzę z poczuciem głębokiego niedosytu.

Celem projektu jest ....., tak aby ..... uwzględniając, że .....

Uczyli mnie tego na jakimś pradawnym kursie, jeszcze w latach 90-ych. Miało być krótko (wraz z rozwinięciem najwyżej pół strony) i konkretnie. Główny cel, kilka celów pomocniczych, najważniejsze uwarunkowania.

Celem projektu jest budowa webowego interfejsu dla sklepu, tak aby klienci mogli efektywnie wyszukiwać i zamawiać towary przez internet, uwzględniając konieczność integracji z istniejącym systemem magazynowym.