Temat: Więcej nie znaczy wolniej
Tomasz G.:
Ja w Twoim artykule nie znajduję żadnej nowości.
Pocieszam się, że to wcale nie musi świadczyć źle o jakości artykułów :)
Możliwe, że target jest inny, dobrze sprzedałeś produkt (artykuł), ale zły obrałeś target.
Szczerze mówiąc, to zaczynam się gubić z tym "złym targetem". Kto wg Ciebie w zamierzeniu miał być odbiorcą?
Temat stworzyłem na 3-4 grupach dla developerów i, opierając się na rozmowach, które przeprowadzałem, wiem, że niejeden programista/lider zespołu spotkał się z takim problemem.
Nikogo nie wskazujesz, ale najwyrazniej pracujesz w obszarze mało profesjonalnym, skoro wnioskujesz, że branża leży tak jakościowo.
Zwróć uwagę, że u mnie w zespole (oraz w pozostałych zespołach w firmie) większosć praktyk/technik się stosuje. Poza tym, rozmawiam z wieloma ludźmi z różnych "obszarów", i z małych firm i z korporacji i wiem, że nadal są ludzie, którzy napotykają ten problem.
Ja nie piszę absolutnie nic o skali zjawiska, a jedynie o tym, że ono występuje. A skoro tak jest i mi udało się kilkukrotnie rozwiązać tego typu problemy, uważam, że nic nie tracę, jeżeli podzielę się obserwacjami i doświadczeniem. Ewentualne dyskusje mogą jedynie pomóc, ponieważ mogą pozwolić mi poprawić błędy w przymyśleniach oraz rozwinąć temat.
Nie znam osobiście nikogo kto kwestionowałby wagę analizy. [...]
Co nie znaczy, że wszyscy analizują problem w wystarczającym stopniu. Jeżeli pracujesz nad projektami, które zawsze były skrupulatnie (wystarczająco) przeanalizowane, to mogę Ci jedynie pozazdrościć.
Jak to mówi "babcia Hela" to "oczywista oczywistość".
Osobiście twierdzę, że "oczywistość" jest zbyt subiektywna, aby odnosić się do niej w IT, ale to już temat na inną dyskusję:)
Kiedy pracowałem (outsourcing) jako konsultant (lead dev) w projekcie mialem problemy z przekonywaniem PM-a (przedstawiciel klienta) do akceptowania budżetu na refaktoryzację. Później nigdy tego nie miałem w swoim budżecie, a etap zawsze był zabudżetowany. Po prostu sprzedawałem ją ukrytą w dev process
[...]
Komunikacja IT <-> biznes jest w tym przypadku prosta. Straszysz kosztami, zachęcasz zyskami, rzeczy których druga strona nie jest w stanie zrozumieć ukrywasz w procesie. Biznes nie musi wiedzieć, że development składa sie z kodowania, code review i refaktoryzacji.
Pod jednym z wpisów dostałem całkiem niezły komentarz odnośnie świadomości klientów.
Dlaczego chcąc wystawić dom nie negujesz tego, że praca architekta jest potrzebna? Bo zdajesz sobie sprawę, że się to bardziej opłaca, wyjdzie taniej i jakościowo lepiej. Nie zatrudniasz ekipy bez planów. A późniejsze urządzenie? To też już inny proces (inny zespół ludzi), który jednak nadal dotyczy tego samego projektu.
Dlaczego mam ukrywać testowanie, dokumentację, refaktoryzację przed zleceniodawcą? A co, gdy on się dowie o tym, że robiłem testy? Ja osobiście bym się "odrobinę" zirytował, gdyby ktoś za moje pieniądze robił dodatkowe rzeczy, nawet jeżeli robił je w dobrej wierze, bo "on wie lepiej, co dla mnie dobre".
Z drugiej jednak strony, wyobraź sobie, że dokształcanie klienta również przynosi korzyści i to nie tylko Tobie. I przez dokształcanie nie mam na myśli dokładnego tłumaczenia mu jak i co się dzieje i jakiego języka/frameworka/biblioteki/narzędzia używam, a jedynie o opis koncepcji i przedstawienie zalet i wad, ponieważ one też istnieją, a ich ukrycie mogłoby negatywnie na nas w przyszłości się odbić.
Jakie korzyści? Klient, który wie, że np. testowanie jest potrzebne i już miał okazję tego doświadczyć, następnym razem również te testy będzie chciał mieć. W dodatku posiadanie ich kompletu umożliwia mu swobodniejszą zmianę dostawcy oprogramowania, gdyby współpraca z nami mu nie odpowiadała.
Jeżeli widzi, że "wyszło mu to na zdrowie", to istnieje szansa, że powie o tym w swoim środowisku i uda mu się komuś wytłumaczyć, że to się opłaca i przynosi zyski.
Jeżeli robisz zmiany w swoim zespole i manager/pracodawca widzi, że przynosi to efekty, to pozwoli na takie zmiany (albo nawet sam będzie chciał je zainicjować) w pozostałych zespołach/przyszłych projektach. To wpłynie na jakość produktów końcowych i zadowolenie deweloperów.
Nie chodzi tu o manipulację, ale o unikanie konfliktów.
Moim zdaniem, to jest ukrywanie informacji.
Jeżeli kupuję auto, to zdaję sobie sprawę, że były przeprowadzane crash testy oraz, że dostanę obszerną instrukcję. Wiem, że to jest wliczone w koszt pojazdu, ale mimo wszystko cieszę się, że ktoś poświęcił czas i wykonał tą część pracy.
пропозиції роботи
