Pierwsza wersja jest beznadziejna, ale i tak ją wydaj

Oryginalny post: Version 1 Sucks, But Ship It Anyway

Autor: Jeff Atwood

Jestem niezadowolony z każdego, najmniejszego kawałka kodu, jaki kiedykolwiek opublikowałem. Częściowo dlatego, że -- podobnie jak wielu programistów -- jestem perfekcjonistą. No i właśnie, nieuchronnie pojawiają się... problemy:

  • Harmonogram był zbyt agresywny i krótki. Potrzebujemy więcej czasu!
  • Napotkaliśmy niewidoczne wcześniej problemy techniczne i zmuszają nas one do zawierania niekomfortowych kompromisów.
  • Mieliśmy zły projekt i trzeba było go zmienić w samym środku procesu tworzenia oprogramowania.
  • Nasz zespół doświadczył wewnętrznych konfliktów, których nie przewidzieliśmy.
  • Konsumenci nie byli tymi, o których myśleliśmy.
  • Komunikacja między projektantami, programistami oraz pozostałymi członkami zespołu nie była tak efektywna, jak myśleliśmy, że będzie.
  • Niedoszacowaliśmy czasu, jaki potrzebny jest na nauczenie się nowej technologii.

Ta lista ciągnie się i ciągnie. Powodów, dla których projekty programistyczne się nie udają jest mnóstwo.

Na sam koniec cyklu produkcji zostajesz z oprogramowaniem, które jest bladym cieniem świecącego, wspaniałego monumentu inżynierii oprogramowania, jaki wyobrażałeś sobie, kiedy zaczynałeś.

Pojawia się skłonność do uznania porażki -- żeby dać więcej czasu w harmonogramie, aby wszystko poprawić zanim produkt zostanie wypuszczony na rynek. Jest jednak tak, że prawdziwy deweloper publikuje.

Jestem tutaj, aby powiedzieć Ci o pewnym błędzie.

Tak, zrobiłeś w tym projekcie od groma rzeczy źle. Zrobiłeś źle od groma innych rzeczy, o których jeszcze nawet nie wiesz. Nie ma możliwości, aby dowiedzieć się, czym te rzeczy są, dopóki nie wypuścisz aktualnej wersji i nie pokażesz jej użytkownikom oraz konsumentom. Myślę, że Donald Rumsfeld ujął to znakomicie:

Jak wiemy,
Są wiadome wiadome.
Są rzeczy, o których wiemy, że wiemy.
Wiemy również,
Że są znane niewiadome.
To znaczy,
Wiemy, że są pewne rzeczy,
Których nie wiemy.
Ale są również nieznane niewiadome,
Te, o których nie wiemy,
Że nie wiemy.

Kiedy staniesz oko w oko z nieuniknionymi niespodziankami na zakończenie projektu -- pojawią się przymusowe kompromisy, zupełnie niesatysfakcjonujące poprawki na szybko i częściowe rozwiązania -- możesz wziąć się w garść i zacząć wylizywać swoje rany. Możesz spędzić kilka dodatkowych miesięcy naprawiając obecną wersję przed jej opublikowaniem. Możesz nawet poczuć się dobrze, że zdecydowałeś się wykonać tę pracę inżynieryjną, zanim pokazany został światu kolejny niekompletny kod pełen błędów.

Niestety, to nawet większy błąd niż opublikowanie ułomnej wersji.

Zamiast spędzać trzy miesiące poprawiając obecną wersję w sterylnych, wyizolowanych warunkach laboratoryjnych, mógłbyś spędzić te same trzy miesiące słuchając opinii od rzeczywistych, do bólu uczciwych, denerwującychoddanych użytkowników Twojego oprogramowania. Nie oprogramowania, które sobie wymarzyłeś, nie od użytkowników których sobie wymarzyłeś, ale takich, jacy istnieją w realnym świecie. Możesz więc zmienić podejście i wykorzystać ten bezpośredni feedback nie tylko, aby naprawić wszystkie kiepskie fragmenty pierwszej wersji, ale również, aby wydawać budżet projektowy bardziej efektywnie, opierając się na twardych danych otrzymywanych od Twoich użytkowników.

Uwaga, nie mówię, że masz wypuszczać chłam. Uwierz mi, wszyscy jesteśmy tutaj perfekcjonistami. Ale prawdziwy świat może być brutalny i nieprzejednany dla nas, perfekcjonistów. Rozsądniej jest pozwolić oprogramowaniu „odejść”, a kiedy zorientujesz się, że rozbiło się o skaliste wybrzeże realnego świata, rozczarowanie jest nieuchronne... ale wyleczalne! To co jest ważne, to raczej nie pierwotny stan oprogramowania -- w zasadzie niektórzy mówią nawet, że jeśli nie jesteś zawstydzony pierwszą wersją, to nie opublikowałeś jej wystarczająco wcześnie -- ale to, co robisz po jego opublikowaniu.

Szybkość i kontaktowość Twojego zespołu z użytkownikiem wpłynie na jakość oprogramowania bardziej niż jakiekolwiek pojedyncze wydanie. To jest to, w czym potrzebujesz być dobry. Nie platoniczna idea dostarczania mitycznego, perfekcyjnego oprogramowania, ale bycie kontaktowym względem Twoich użytkowników oraz konsumentów i okazywanie im tego poprzez proces ulepszania i udoskonalania oprogramowania zgodnie z ich opinią. Więc do tego stopnia, do którego optymalizujesz chcąc otrzymać bliskie perfekcji wersje oprogramowania, optymalizujesz źle.

Nie ma wątpliwości, że jakimkolwiek budżetem czasu byś nie dysponował, otrzymasz lepsze oprogramowanie wydając je tak wcześnie, jak to tylko możliwe, a następnie wykorzystując pozostały czas na iteracje w oparciu o opinie użytkowników.

Więc zaufaj mi: nawet jeśli pierwsza wersja jest kiepska, wydaj ją mimo to.

Data publikacji oryginału: 3 grudnia, 2009

3 komentarze:

Anonimowy pisze...

Z tym uciekaniem od wydania pierwszej wersji, kojaży mi się pewien zespół programistów zajmujący się grą Duke Nukem Forever.

Anonimowy pisze...

Świetny artykuł i "niestety" zgodny z wymaganiami klientów, którzy widzą, że "to działa" a nie "jak to jest zrobione". Wydaje mi się że żeby zaspokoić i klientów i swoje pobudki trzeba nauczyć się odnajdywać kompromis pomiędzy tymi dwoma zagadnieniami.

Tomasz Kowalczyk pisze...

No proste, dlatego najlepsze projekty to te, które zrobiłeś dla siebie.

Prześlij komentarz

Related Posts with Thumbnails