Piotr Morzydusza

Pozdrawiam

To pech, bowiem to właśnie Adobe Reader jest ostatecznym wyznacznikiem zgodności plików ze standardem PDF.

Często jest tak, że nie jesteśmy w stanie wiarygodnie stwierdzić, że daną czynność wykonaliśmy poprawnie. Albo gorzej – jesteśmy pewni, że możemy sprawdzić samych siebie, a tak nie jest do końca.

Dla przykładu opowiem coś, co przydarzyło mi się niedawno.
Mam w moim kliencie poczty sprawdzanie pisowni, oraz plugin zabezpieczający przed wysłaniem maila bez załącznika, kiedy wspominam o nim w treści maila. Mimo to zawsze czytam mail przed wysłaniem jeszcze raz oraz otwieram załączniki.
Jakież było moje zdziwienie, gdy okazało się, że wysłałem kilkukrotnie maila z załącznikiem, który był absolutnie nieczytelny dla odbiorcy. Okazało się, że pliki PDF które wygenerowałem u siebie na Linuksie, są dla mnie (w każdym posiadanym programie) zupełnie czytelne, za to na platformie Windows (czyli z blisko 100% prawdopodobieństwem platformie odbiorcy) podstawowe narzędzie jak Adobe Reader nie jest w stanie ich otworzyć poprawnie.

Sytuacja gdy naprawdę nie byłem w stanie sprawdzić się samemu. A kilka okazji zapewne przez to uciekło.

Czy mógłbyś podać przykład takiego “uniwersalnego multi-checku”? Wielokrotne sprawdzanie tego, co zrobiliśmy może znacznie spowolnić nasze działanie. Może też być oznaką niepewności.

W naszym projekcie, przed opublikowaniem kodu, inny członek zespołu musi go obejrzeć robiąc tzw. code review. Podejście jest fantastyczne, gdyż:
- robimy double check przygotowywując się do wytłumaczenia jak kod powinien działać
- osoba słuchająca robi cross check pytając, weryfikując nasze założenia oraz krytykując
- jeśli osoba oglądająca jest bardziej doświadczona, można się wiele nauczyć niejako “przy okazji”
- jeśli mniej, to mamy szansę nauczyć kogoś paru tricków robiąc takie małe “pay it forward”, ale również szacunku do mniej doswiadczonych, którzy czasem mają jednak fantastyczne pomysły
- jest to w pewnym sensie okazja do pokazania się od pozytywnej strony – poprawienia umiejętności robienia prezentacji, lepszej narracji, pokazania, że myśli się o wszystkich szczegółach

Dużo zalet takiego podejścia powoduje, że staram się je stosować także w życiu codziennym, nie tylko w projektach IT.

pozdrawiam

Przy zamykaniu drzwi po prostu koncentruję się, jak je zamykam.

bb.bartosz,
to również i moja metoda, ponieważ moje paluszki mają adhd i zdarzało się, że mail szedł do odbiorcy bez jego dokończenia.

nota bene – jak ja się cieszę, że dziś mamy dobre środki antykoncepcyjne

AM

Pozdrawiam
Alex

Po tej metodzie na pewno zacznę stosować double check, bo już niestety zdarzyło mi się, że musiałem kilka razy dosyłać załączniki. A co myślicie o tym, że jak wysyłacie dany załącznik to dopisać w mailu, że prosicie o informację czy wszystkie dane dotarły i jeśli nie odpisują to wtedy dzwonić? Niekiedy zdarza mi się dzwonić dużą liczbę razy do pewnych firm i kolejny telefon z pytaniem o dotarcie danych może im się wydać niesmaczny. Ale to moje zdanie i nie wiem czy tak samo myślicie

P.S. Właśnie zobaczyłem ten tekst nad polem komentarza o kopiowaniu do schowka w razie awarii. Robię to od bardzo długiego czasu, żeby nie tracić czasu na kolejne pisanie komentarza w razie wypadku. A czy to nie jest czasami swojego rodzaju double check, żeby się upewnić o zatwierdzenie naszego komentarza?

“Pozwolę sobie się z Tobą nie zgodzić. Jako nadawca zawsze jesteś odpowiedzialny za to, aby Twoje przesłanie dotarło do odbiorcy. Nie tak dawno wysłałem mailem pewne materiały nowemu potencjalnemu klientowi. Oprócz standardowego double check przy wysyłce zrobiłem jeszcze jeden double dzwoniąc dzień później i sprawdzając, czy wszystko dotarło w porządku.”

To jest raczej naturalne i tak powinno się robić, że dzwonimy i upewniamy się czy dotarło to co chcieliśmy wysłać.

Natomiast to o czym ja pisałem, może wybiega poza temat tego postu. Ponieważ poruszyłem sprawy techniczne. I to, że mail dociera z pustym załącznikiem, pomimo, że wysyłamy “pełny” jest możliwe i nie tylko to jeśli chodzi o korespondencje e-mail. Dlatego też powinniśmy sprawdzić poprawne dostarczenie naszych e-maili. Tu do głosu doszło moje ukierunkowanie zawodowe i szukanie problemu w technice .

Alex wyżej pisałem tylko o zawodności e-mail, a nie o tym czy ktoś sprawdzi czy nie.

Nie można też wdrażać zbyt męczących procedur sprawdzających ponieważ firma zaczyna działać ociężale. I czasem takie nadmierne sprawdzanie przynosi wiecej zła niż dobrego. Można ugrzęść w stosie procedur sprawdzających, jeśli się przesadzi. Trzeba do tego podejść z zdrowym rozsądkiem – szczególnie jak jeszcze takich procedur nie mamy i chcemy je dopiero wdrożyć.

serdecznie pozdrawiam
Szymon

Jeśli podwykonawcy nie znają naszych terminów, to, jak pisze Alex, powstają bufory w projekcie. Ale bardzo ważną kwestią jest egzekwowanie terminów wyznaczonych podwykonawcom nie tylko pod presja terminu własnego. Znam przypadki, w których kierownik projektu dbając o dobre praktyki robi taki bufor, ale w przypadku opóźnień interweniuje dopiero gdy sam jest “pod ścianą”. Takie działanie obniża rangę ustalanych przez nas terminów i nasz autorytet. Wykonawcy szybko uczą się, że są ukryte bufory i to bardzo miękkie

Ja jestem zwolennikiem dojrzałego traktowania uczestników projektu. Lepiej zrobić bufor dopasowany do charakteru zadania i zidentyfikowanych zagrożeń i go nie ukrywać. Poważni wykonawcy (a z takimi chcemy współpracować, prawda?) sami będą sobie wyznaczać wcześniejsze robocze deadline’y, żeby mieć zapas czasu na wypadek nieoczekiwanych komplikacji.

A w kwestii pomijanych załączników: w Outlooku napisałem sobie makro, które przed wysłaniem maila bez załącznika szuka w treści słów typu “załącznik”, “przesyłam” itp. i jeśli znajdzie, pyta, czy na pewno wiem, co robię.

Maciej
Witaj na naszym blogu
Double check ważny jest wszędzie i dobrze jest jeśli wejdzie każdemu w krew. Inaczej są rezultaty takie jak napisałeś

bb.bartosz
To jest niezły sposób

Pozdrawiam
Alex