Czy tworzysz fajne rzeczy?
Jakość 05/08/2006 · Link Jakość w projektach informatycznych kosztuje. Kod wytworzony za pierwszym razem zwykle bardziej przypomina prototyp niż rozwiązanie i wymaga refaktoringu. Dzieje się tak dlatego, że dopiero tworząc produkt zaczynamy dobrze rozumieć zależności między różnymi fragmentami kodu, łatwiej nam dostrzec podobieństwa, uogólnić i stworzyć eleganckie docelowe rozwiązanie. Czy w Twojej firmie (dziale, zespole, projekcie) jest na to czas? Czy tworzysz fajne rzeczy, czy też działasz według filozofii "good enough"? Nie twierdzę, że którekolwiek z dwóch ekstremów jest właściwe, zawsze wybierany jest w końcu jakiś kompromis. Z informatycznego punktu widzenia lepiej oczywiście jest tworzyć rzeczy dobre, choćby dlatego, że tańsze jest ich utrzymanie w przyszłości. Z perspektywy biznesowej zwykle lepsza jest strategia "good enough" - produkt może być szybciej na rynku, może wcześniej rozwiązywać problem klienta, a przy tym może być (przynajmniej inicjalnie) tańszy. Ale szukając optymalnego wyważenia warto zwrócić uwagę na mniej inżynieryjno-biznesowy, a bardziej ludzki aspekt. Ludzie chcą tworzyć coś dobrego. Jeżeli przyciągniesz do zespołu najlepszych, pokażesz im wyjątkowość wyzwania, określisz ambitne i fajne cele, zadbasz o jakość to będziesz miał zmotywowany, efektywny, zaangażowany zespół. I odwrotnie: oszędzanie na jakości, praca nad kiepskim produktem i współpraca ze słabymi ludźmi są początkiem staczania się po równi pochyłej. Utrzymanie motywacji i efektywności w takiej sytuacji jest niezmiernie trudne, przyciągnięcie dobrych osób na dłuższy czas - prawie niemożliwe. Co więcej łatwo o wzmocnienie zwrotne. Odejście dobrej osoby pociągnie za sobą inne: nikt nie chce pracować w słabym zespole, bo to tylko wróży kłopoty i żaden honor na dodatek. Jakość prawdobodobnie spadnie, pogłębiając demotywację zespołu. Nie jest łatwo zawrócić z takiej drogi. Jak się na jakość patrzy w Twoim zespole? Nie mam na myśli pustych deklaracji (czy jest tu ktoś, kto nie słyszał, że celem firmy jest dostarczanie produktów o najwyższej jakości?), ale rzeczywiste działania. Ile jest czasu na refaktoring? Jakie jest podejście managementu do wydłużenia terminów realizacji w zamian za poprawienie jakości? Jakie działania są podejmowane i jakim kosztem, by rzeczywiście produkty były dobrze zrobione? Czy Ty tworzysz fajne rzeczy?Zobacz inne wpisy
- Chaos Report dwanaście lat później
- UI nie jest obszarem inwencji
- Usability is about choosing functionalities
- Full Life Cycle Object-Oriented Testing
- Dlaczego powstaje kiepskie oprogramowanie?
ciekawa sprawa, wymaga pojscia na kompromis. nie zawsze niestety jest czas na dobre rzeczy.
najczesciej refaktoring przeprowadzam w czasie wolnym, po prostu dla wlasnej satysfakcji (czesto w tle jest czas, ktory bede musial poswiecic w przyszlosci na utrzymanie kodu).
pozdrawiam
najczesciej refaktoring przeprowadzam w czasie wolnym, po prostu dla wlasnej satysfakcji (czesto w tle jest czas, ktory bede musial poswiecic w przyszlosci na utrzymanie kodu).
pozdrawiam
07/09/2006,
murwazy
Murwazy,
Z tego co piszesz:
- refaktoring, a w konsekwencji stworzenie bardziej eleganckiego i niezawodnego rozwiązania przynosi Ci frajdę,
- inwestycja w refaktoring w Twojej ocenie zwraca się ze względu na niższy koszt utrzymania systemu w przyszłości,
- mimo to często się z niego rezygnuje, bo krótkoterminowo inne zadania okazują się ważniejsze.
To samo potwierdzają moje doświadczenia.
Nacisk na jakość - tworzenie dobrych, fajnych rzeczy - jest długoterminowo opłacalną strategią. Jest tak zapewne nawet wtedy, gdy odbywa się kosztem np. ilości funkcji w systemie. Jasne, czasem konieczne jest owo "pójście na kompromis": dostarczenie systemu już dziś, dołożenie do niego dodatkowych raportów, czy przesunięcie ludzi do innych, ważniejszych zadań. Moim zdaniem istotne jest to, by pamiętać, że oszczędności na jakości to nie tylko większe problemy z kodem, mniejsza satysfakcja klientów, ale również ryzyko zniechęcenia dobrych pracowników.
Kto chce być częścią zespołu tworzącego byle jakie produkty?
Pozdrawiam,
Marek
Z tego co piszesz:
- refaktoring, a w konsekwencji stworzenie bardziej eleganckiego i niezawodnego rozwiązania przynosi Ci frajdę,
- inwestycja w refaktoring w Twojej ocenie zwraca się ze względu na niższy koszt utrzymania systemu w przyszłości,
- mimo to często się z niego rezygnuje, bo krótkoterminowo inne zadania okazują się ważniejsze.
To samo potwierdzają moje doświadczenia.
Nacisk na jakość - tworzenie dobrych, fajnych rzeczy - jest długoterminowo opłacalną strategią. Jest tak zapewne nawet wtedy, gdy odbywa się kosztem np. ilości funkcji w systemie. Jasne, czasem konieczne jest owo "pójście na kompromis": dostarczenie systemu już dziś, dołożenie do niego dodatkowych raportów, czy przesunięcie ludzi do innych, ważniejszych zadań. Moim zdaniem istotne jest to, by pamiętać, że oszczędności na jakości to nie tylko większe problemy z kodem, mniejsza satysfakcja klientów, ale również ryzyko zniechęcenia dobrych pracowników.
Kto chce być częścią zespołu tworzącego byle jakie produkty?
Pozdrawiam,
Marek
09/09/2006,
Marek Rafałowicz
zgadza sie - refaktoring traktuje po czesci jako zobowiazanie wzgledem pracodawcy (ale nie nadaje wysokiego priorytetu), po czesci jako inwestycje we wlasna wiedze, a czesciowo robie to majac na uwadze wlasne lenistwo (utrzymanie kodu, wykorzystanie go w przyszlosci) :-)
nowe funkcje do systemu dodaje sie o niebo latwiej jesli napisany juz kod (i projekt) jest dobry.
z kolej dobry kod nie ma imo bezposredniogo przelozenia na zadowolenie klientow, przynajmniej nie w wiekszosci przypadkow - nie potrafia go po prostu ocenic (zakladam ze produkt dziala wg zalozen ale moglby byc lepiej zaprojektowany/napisany).
zniechecenie pracownikow - owszem, ale to juz zalezy od ludzi. to kwestia charakteru - znam duzo ludzi, ktorzy pracuja wg zasady "wystarczajaco dobry", nie mam na mysli wylacznie programistow.
nie kazdy jest perfekcjonista :-)
pozdrawiam
nowe funkcje do systemu dodaje sie o niebo latwiej jesli napisany juz kod (i projekt) jest dobry.
z kolej dobry kod nie ma imo bezposredniogo przelozenia na zadowolenie klientow, przynajmniej nie w wiekszosci przypadkow - nie potrafia go po prostu ocenic (zakladam ze produkt dziala wg zalozen ale moglby byc lepiej zaprojektowany/napisany).
zniechecenie pracownikow - owszem, ale to juz zalezy od ludzi. to kwestia charakteru - znam duzo ludzi, ktorzy pracuja wg zasady "wystarczajaco dobry", nie mam na mysli wylacznie programistow.
nie kazdy jest perfekcjonista :-)
pozdrawiam
10/09/2006,
Murwazy
Witaj Murwazy,
Dzięki za odpowiedź.
Pozwolę sobie na jedną uwagę, dotyczącą pracy według zasady "wystarczająco dobrze". Zgadzam się, że wielu ludzi zadowala się takim podejściem do pracy. Co więcej, jak pisałem, często jest to postawa popierana przez kierownictwo zespołu i zgodna z polityką firmy, bo oznacza "optymalizację" wysiłku. Nie zużywa się energii na te prace, które, jak zauważyłeś, nie przekładają się bezpośrednio na korzyści dla końcowego użytkownika.
Nie wyobrażam sobie jednak, by w takim zespole można było wzniecić atmosferę maksymalnego zaangażowania, osiągnięcie tego stanu, gdy zespół staje się czymś więcej niż sumą jego członków: gdy wszyscy walczą o osiągnięcie wspólnego celu, wspierają się nawzajem, dają z siebie wszystko i osiągają zadziwiająco dobre rezultaty. Tę atmosferę, która cechuje zwycięzców. Przykładem niech tu będą najlepsze zespoły sportowe.
Czy można to osiągnąć, jeśli menadżer wymaga bycia "wystarczająco dobrym"? Gdy entuzjazm programisty, który uważa, że jego produkt wymaga dopracowania by był 'state-of-the-art', ściera się z "optymalizacją": przykazem zarzucenia pracy nad nim i przejścia do innych zadań?
Czy można zostać zwycięzcą, jeśli stawia się sobie przeciętne cele?
I czy menadżerowie uwzględniają ten aspekt w swoich decyzjach? Czy biorą pod uwagę długoterminowe skutki takich decyzji dla zespołu, firmy i klientów?
Pozdrawiam,
Marek
Dzięki za odpowiedź.
Pozwolę sobie na jedną uwagę, dotyczącą pracy według zasady "wystarczająco dobrze". Zgadzam się, że wielu ludzi zadowala się takim podejściem do pracy. Co więcej, jak pisałem, często jest to postawa popierana przez kierownictwo zespołu i zgodna z polityką firmy, bo oznacza "optymalizację" wysiłku. Nie zużywa się energii na te prace, które, jak zauważyłeś, nie przekładają się bezpośrednio na korzyści dla końcowego użytkownika.
Nie wyobrażam sobie jednak, by w takim zespole można było wzniecić atmosferę maksymalnego zaangażowania, osiągnięcie tego stanu, gdy zespół staje się czymś więcej niż sumą jego członków: gdy wszyscy walczą o osiągnięcie wspólnego celu, wspierają się nawzajem, dają z siebie wszystko i osiągają zadziwiająco dobre rezultaty. Tę atmosferę, która cechuje zwycięzców. Przykładem niech tu będą najlepsze zespoły sportowe.
Czy można to osiągnąć, jeśli menadżer wymaga bycia "wystarczająco dobrym"? Gdy entuzjazm programisty, który uważa, że jego produkt wymaga dopracowania by był 'state-of-the-art', ściera się z "optymalizacją": przykazem zarzucenia pracy nad nim i przejścia do innych zadań?
Czy można zostać zwycięzcą, jeśli stawia się sobie przeciętne cele?
I czy menadżerowie uwzględniają ten aspekt w swoich decyzjach? Czy biorą pod uwagę długoterminowe skutki takich decyzji dla zespołu, firmy i klientów?
Pozdrawiam,
Marek
10/09/2006,
Marek Rafałowicz
> Czy można zostać zwycięzcą, jeśli stawia się sobie przeciętne cele?
nie mozna.
z drugiej strony mozna stawiac sobie ponadprzecietne cele i nigdy ich nie osiagnac.
mysle, ze sprawa jest dosc zlozona, ciezko o ludzi dajacych z siebie maksimum, sam manadzer nie wystarczy. gra druzyna.
zloty srodek z naciskiem na jakosc moim zdaniem jest najlepszym rozwiazaniem. trzeba pamietac, ze jesli skupimy sie na jakosci kosztem ilosci realizacji ucierpi firma, czyli wszyscy.
pozdrawiam
nie mozna.
z drugiej strony mozna stawiac sobie ponadprzecietne cele i nigdy ich nie osiagnac.
mysle, ze sprawa jest dosc zlozona, ciezko o ludzi dajacych z siebie maksimum, sam manadzer nie wystarczy. gra druzyna.
zloty srodek z naciskiem na jakosc moim zdaniem jest najlepszym rozwiazaniem. trzeba pamietac, ze jesli skupimy sie na jakosci kosztem ilosci realizacji ucierpi firma, czyli wszyscy.
pozdrawiam
11/09/2006,
Murwazy
