Czy warto być egocentrykiem?

Odbyłam ostatnio z córką ciekawą rozmowę o egocentryzmie. Właściwie to wygłosiłam monolog, ponieważ ona, jak przystało na zbuntowaną nastolatkę, nie bardzo mnie słuchała, a ja, jak prawdziwy upierdliwy rodzic, nie bardzo się tym przejęłam. Być może jest to dowodem, że obie znamy z autopsji omawiane zagadnienie.

Egocentryzm (łac. ego – ja + centrum – środek) to tok rozumowania polegający na centralnym umiejscowieniu własnej osoby w otoczeniu. Przekonanie o tym, że jest się najważniejszą osobą i świat kręci się wokół nas. Egocentryzm jest naturalną postawą rozwojową na określonym etapie rozwoju dziecka, dokładnie w okresie przedszkolnym. Później w życiu dorosłym, teoretycznie jest objawem niedojrzałości, a co za tym idzie niedostosowania do życia w społeczeństwie.

Obserwacja dostarcza jednak niezliczonych dowodów na to, że bardzo wielu z nas nie wyrasta z egocentryzmu. Ba! Wygląda nawet na to, że jest on niezbędny do życia w społeczeństwie, a szczególnie do osiągnięcia sukcesu w biznesie i korporacji. Wystarczy poczytać biografię Steva Jobsa, żeby nie mieć najmniejszych wątpliwości, że był osobą skrajnie egocentryczną (a może nawet socjopatą). Większość z nas mimo to, zazdrości mu osiągnięć, tylko czy chcielibyśmy być  taką osobą? Bez skrupułów, bez sentymentów, bez wartości rodzinnych, po cudzych karierach do celu – wydaje się straszne…. A jednak ja lubię swojego IPhonea i jestem za niego Stevowi wdzięczna.

Temat jest na czasie nie tylko z powodu Jobsa, ale również dyskusji o absolwentach, którzy mają niezwykle wysokie mniemanie o sobie i żądają wysokich wynagrodzeń już na początku kariery. Czy mnie to razi? Tak. Czy chciałabym, żeby moja córka przejawiała taką postawę wobec pracodawcy? Tak.  A wobec mnie? Nie.

 Z całą pewnością najlepiej jest mieć wysoką ale adekwatną samoocenę. Znać swoje mocne strony i umieć je wycenić. Czasem jednak lepiej je zawyżyć, być może otoczenie się nie pozna, a w przypływie doświadczenia szybko uzupełnimy brakujące kompetencje. Kluczem do sukcesu staje się tu wyważenie,  żeby przypadkiem nie przedobrzyć. Wiele młodych osób to potrafi, ci starsi mają problem, bo zostali wychowani zgodnie z duchem ujmowania sobie.

Rodzice mnie uczyli, że mądrzejszy ustępuje głupszemu, że trzeba opiekować się młodszymi i słabszymi, że starszym zawsze należy się szacunek, że wszystkim trzeba się dzielić, a wręcz wskazane jest oddać, że nie wolno pyskować i trzeba czekać na swoją kolej. Tak silnie udało im się wdrukować mi te zasady, że inne zachowanie budzi moje rozczarowanie. Niestety wszystko to niezwykle utrudnia odniesienie sukcesu i zrobienie kariery. Dzisiaj nie można cicho czekać na swoją kolej. Trzeba naginać rzeczywistość i iść do przodu nie patrząc na ofiary. Może takie osoby są mniej sympatyczne ale mają większe szanse osiągnąć sukces.

Jednak arogancja nie zawsze się sprawdza i ma również pułapki. Cierpi na tym nie tylko etyka biznesu ale również relacje z klientem. Co z tego, że wierzymy w swoje możliwości, jeśli nikt nie będzie chciał nam za nie zapłacić. Tylko osoby posiadające odrobinę geniuszu jak Jobs mogą sobie pozwolić na niesłuchanie innych, ponieważ potrafią kreować potrzeby, dają ludziom rzeczy o których jeszcze nie wiedzieli, że ich potrzebują. Reszta niestety (a może na szczęście) musi nauczyć się słuchać, rozumieć i mieć szacunek do klienta. Nie zaszkodzi również odrobina pokory wobec otrzymywanych informacji zwrotnych, bo to rozwija.

Cieszę się, że w tych niesprzyjających czasach szczęśliwie jestem otoczona ludźmi, którzy potrafią spojrzeć poza własne ego. Może nie stworzymy wielkiej korporacji ale poczucie sensu i dobre relacje z ludźmi z pewnością nam to wynagrodzą.

Podziel się swoim organizerem :)

Ostatnia zmiana organizacji pracy skłoniła mnie do podzielenia się kilkoma doświadczeniami z tym związanymi.

Pewnie jak każdy zaczynałem od prostej listy ToDo i kalendarza. Rozwiązanie takie sprawdza się tak długo jak jesteśmy w stanie w głowie zapanować nad tym co zapisujemy. Zazwyczaj osiągnięcie tego etapu nie zajmuje wiele czasu.

W naszej branży często z rozwiązaniem przychodzi firma. Wszelkie bugtrackery i inne systemy prowadzenia projektu pozwalają zbierać zadania do realizacji w jednym miejscu i jakoś nad nimi panować nawet jeśli bierzemy udział w sporej ilości projektów.

Co jednak jeśli chcemy zapanować też nad swoimi prywatnymi sprawami? Trochę głupio wrzucać zadanie o wytrzepaniu dywanów w firmowym organizerze ;)

Tak właśnie zaczęła się moja przygoda z GTD. Od początku wspierałem się aplikacjami na laptopie i telefonie. OmniFocus był idealnym rozwiązaniem. Pracowicie i konsekwentnie zbierałem wszelkie zadania w inboxie. Robiłem co mogłem aby regularnie je przeglądać i porządkować. Z realizowaniem też jakoś sobie radziłem czyli system działał.

Z czasem jednak moja droga z GTD zaczęła się nieco rozchodzić. Model w jakim pracuję nie do końca pokrywał się z jego założeniami. Brakowało mi możliwości nadawania priorytetów dla zadań. Można było to realizować oczywiście za pomocą kontekstów ale to nie do końca miało sens ponieważ konteksty powinny być związane z możliwością wykonania konkretnej aktywności. Drugim problemem z jakim się zderzyłem to właśnie `miejscowość` kontekstów.

Być może coś pominąłem w trakcie lektury Davida Allena jednak podejmowanie działań w momencie gdy jestem w jakimś miejscu lub przy urządzeniu, kompletnie się nie sprawdzało. Cóż z tego że w kontekście `przy komputerze` miałem 5 zadań na weekend skoro pogoda dopisała i komputer włączałem dopiero w poniedziałek… jakieś 2 dni po terminie realizacji. Definiowanie dat końcowych też do końca nie rozwiązywało problemu. Pojawiały się sytuacje gdy w widoku zadań ze zdefiniowanym terminem było ich kilka i każde z innego kontekstu. W efekcie i tak musiałem ‘biegać’ z miejsca na miejsce. Czyli praca włożona w utrzymanie organizera była stratą czasu.

Postanowiłem trochę przemyśleć model własnego działania i poszukać innej drogi. Narzędzia powinny wspierać naturalne preferencje a nie wymuszać trudne zmiany.

Tak zainstalowałem sobie Things. Przepisałem cały organizer pozostawiając podział na projekty tam gdzie było to możliwe. Część zadań przedefiniowałem z użyciem obszarów odpowiedzialności, co jest świetnym rozwiązaniem w sytuacji gdy chcesz zachować jakąś część kontekstów z GTD ale nie wszystko traktujesz jako projekt. Przykładowo odkurzyć samochód to pojedyncze zadanie z obszarze auto. Nie widzę powodu do robienia z tego projektu i rozpisywania na niezliczoną ilość zadań :)

Obecny model pracy oparłem o priorytety. Mam zdefiniowane 4 poziomy (3 wyższe i 1 obniżający rangę zadania względem `normalnego`). Zadania posiadają również często swoje terminy zakończenia ponieważ są rzeczy, z którymi nie można się spóźnić. Tak czesto jak to potrzebne i możiwe przeglądam sobie zgromadzone wpisy. Czasem wszystkie, czasem tylko wybrane obszary lub projekty. Każdy taki przegląd owocuje dodaniem kilku wyższych priorytetów do zadań, czasem ich obniżeniem.

Zadania, które muszę wykonać pojawiają się dzięki tym działaniom w widoku ‘Today’. Widzę tam te zadania, których daty końca są bliskie oraz te które oznaczylem do realizacji ze wzgledu na priorytet. Rozwiązał się też problem nagłych wrzutek. Czy mi się to podoba czy nie, czasem coś takiego wpada i trzeba jakoś zareagować. Zatem umieszczam to od razu w widoku ‘Today’ i sprawa załatwiona.

Po 4 miesiącach nowego porządku jak na razie nie znalazłem dziury w systemie. Pozwala mi on elastycznie zarządzać tym co mam do zrobienia a z drugiej strony jestem w stanie utrzymać porządek w pracach. Widzę toczące się projekty, mam pogrupowane zadania względem obszarów zainteresowań itp. Jest lżej, choć praca nadal się sama nie wykonuje ;)

Gdyby ktoś chciał się podzielić swoimi doświadczeniami z organizacji pracy, to bardzo chętnie poczytam. Wciąż szukam ulepszeń i nowych możliwości na ułatwienie sobie organizacji pracy.

Współpraca biznesowa jak u dobrego mechanika

Ostatnio, po rozmowie z klientem na temat projektu, nasunęło mi się pewne skojarzenie z życia. Mam wrażenie, że często firmy mają problem z prowadzeniem projektów podobny jak ja czasem mam ze swoim autem.

Jak w każdym aucie od czasu do czasu coś mi się zepsuje. A jako, że przed zakupem auta nie spędzałam wolnego czasu na pogłębianiu wiedzy z dziedziny motoryzacji, wszystko co stuka, puka musi być sprawdzone u specjalisty :) 

I tutaj pojawiają się pewne komplikacje, bo okazało się, że nie mogę po prostu wyszukać w Google „mechanik samochodowy” i pojechać do jednego ze znalezionych zakładów w celu naprawy wszystkiego co może nie działać. Są pewne specjalizacje…Do Pana Marka jeżdżę bo zajmuje się tłumikami, do Pana Jurka bo jest blacharzem/lakiernikiem, Pan Wojtek zajmuje się wymianą części itp, itd.

Ale ja, jako „laik” w dziedzinie motoryzacji, chciałabym móc przekazać swoje auto w jedno miejsce gdzie zaopiekują się nim kompleksowo.

Podobnie dzieje w projektach informatycznych. Najpierw potrzebujemy osoby, której opowiemy o naszym projekcie a ona nam powie czy jest to, z punktu widzenia technologii, możliwe…Następnie musimy znaleźć kogoś kto nam to wytworzy. Potem dobrze by było przetestować i wdrożyć. Niezbędne będzie również utrzymanie na serwerze, no i oczywiście marketing jeśli zamierzamy promować nasz produkt w internecie.

Widzę tutaj co najmniej 3 firmy, które trzeba znaleźć, sprawdzić ich doświadczenie i opowiedzieć o swoim projekcie, a potem weryfikować działania.

A czy nie byłoby idealnie móc rozmawiać tylko z jedną firmą, która wszystkim się dla nas zajmie? Doradzi, przeanalizuje, znajdzie takich wykonawców, którzy spełnią nasze wymagania i poprowadzi projekt od początku aż do samego końca?

Myślę, że podobnie jak ja chciałabym mieć „uniwersalnego” mechanika, który wspierałby mnie we wszystkim co jest związane z moim autem, to wiele firm byłoby zainteresowanych kompleksową współpracą z jedną firmą, która pomoże i doradzi w temacie rozwoju biznesu czy nowych technologii.

O rozwiązaniach dedykowanych i autorskich

Poszukując narzędzi informatycznych dla biznesu często stajemy przed dylematem wdrożenia gotowego rozwiązania lub stworzenia oprogramowania dedykowanego. Warto rozważyć kilka za i przeciw obu modeli aby móc podjąć lepszą decyzję i zaplanować rozwój naszej platformy.

Rozwiązania gotowe:

  • krótki czas uruchomienia
  • baza wiedzy dostępna na stronach producentów
  • możliwe wsparcie ze strony innych użytkowników oprogramowania
  • szybka rozbudowa o kolejne gotowe elementy
  • niski koszt początkowy
  • zakres funkcjonalności narzucony przez producenta
  • rozwój zależny od producenta lub społeczności
  • potrzeba dostosowania niektórych procesów biznesowych do możliwości narzędzia
  • koszt późniejszego wsparcia technicznego

Oprogramowanie dedykowane:

  • funkcjonalności idealnie dopasowane do przedsiębiorstwa
  • rozwój oprogramowania dyktowany aktualnymi potrzebami biznesu
  • możliwość dowolnego modelowania procesów firmy w aplikacji
  • niższy koszt utrzymania (często ograniczony do infrastruktury)
  • długi czas uruchomienia
  • znajomość systemu jedynie w obrębie wykonawcy i klienta
  • rozbudowa wymaga kolejnych prac developerskich
  • wysoki koszt uruchomienia narzędzia

Żadnego z powyższych modeli nie można polecić jako lepszego. Wybór powinien być podyktowany rzeczywistymi potrzebami biznesowymi jakie chcemy realizować przy pomocy naszego oprogramowania.

Jako ciekawostkę chciałbym przedstawić jeszcze jeden parametr często odróżniający oprogramowanie dedykowane od gotowego i równie często pomijany. Poniższe wykresy pokazują czas załadowania w oknie przeglądarki dwóch stron internetowych. Pierwsza z nich została stworzona od podstaw przez zespół, którego celem było zapewnienie możliwie szybkiego dostępu do prezentowanych informacji.

Drugi wykres przedstawia ten sam parametr czasowy dla serwisu opartego na popularnej platformie CMS. Założeniem projektu było w możliwie niskim budżecie dostarczenie bogatych funkcjonalności.

Dlatego w Rocket Studio analizujemy przede wszystkim potrzebny biznesowe aby rekomendowane przez nas rozwiązanie nie wymagało przebudowy zaraz po jego wdrożeniu i nie pociągało nieprzewidzianych kosztów.

Wysyłamy bezpłatne materiały dla kadry zarządzającej o tym jak skutecznie wykorzystać IT w biznesie

Wyślemy Ci najnowsze artykuły, case studies, porady
+ unikalne materiały tylko dla czytelników newslettera

Gwarantujemy 100% prywatności. Nie będziemy się dzielić Twoimi danymi.

Co wspólnego ma budowlanka z informatyką?

Jak pokazuje życie, budowa domu nie różni się wiele od procesu tworzenia oprogramowania.

W pierwszej kolejności zasiadamy nad koncepcją. Spisujemy nasze pomysły na pomieszczenia, układ pięter i wszystko to co widzieliśmy u innych i też to chcemy. Następnie wkraczają architekci i konstruktorzy, sprowadzający nieco nasze wizje na ziemie i dbający o to aby nasz przyszły dom spełniał wymagania i normy budowlane. Następnie przystępujemy do budowy.

Prace budowlane rozpoczynają się od fundamentów. Jest to jeden z trudniejszych etapów. Błędy popełnione przy wylewaniu ław prowadzą wprost do krzywej wieży zamiast domu marzeń. Stawianie ścian, elewacja i wykończenie to wbrew pozorom już wisienka na torcie, choć bardzo kosztowna wisienka.

Dlaczego jednak rozpisuję się o budowaniu domu na blogu informatycznym? Ponieważ w projektach informatycznych sytuacja jest bardzo podobna.

Klient przychodzi z wyobrażenami swojej aplikacji, analitycy i architekci oprogramowania mają za zadanie przekuć wizję na rzeczywiste rozwiązania informatyczne. Menedżer projektu niczym kierownik budowy dba aby praca toczyła się zgodnie z planem.

Niestety jednak w świecie IT klienci zbyt często przykładają dokładnie odwrotną wagę do kolejnych etapów działań. Najważniejszy jest wygląd, następnie funkcjonalności a na końcu użyteczność. Sporadycznie klient zastanawia się w oparciu o jakie rozwiązania powstanie jego aplikacja i czy w przyszłości będą się one nadawały do dalszego rozwoju.

Etapem wręcz mitycznym jest analiza. Choć wszyscy deklarują, że planowanie jest najważniejsze to rzeczywistość pokazuje iż klienci często etap analizy i opracowania makiet obcinają do minimum. Traktują go jako zło konieczne i chcą natychmiast przejść do `klikania` w swoją nową stronę. To niestety jest gotowy przepis na porażkę.

Może warto czasem jednak zatrzymać się i zastanowić w jaki sposób chcemy podejść do naszego projektu. Co jest w nim prawdziwą wartością a co jedynie efektem podjętych działań. To w tym obszarze wspieramy naszych klientów w Rocket Studio, dbamy aby ich oprogramowanie było funkcjonalne i stanowiło podstawę do dalszego rozwoju.

UX o poranku :)

Otrzymałem dziś SMS o następującej treści:

od: PocztaSA

Przesyłka nr xXxXxXxXxXxXxXxXxXxX zostanie doreczona w ciagu 24 godz. W przypadku nieudanej proby doreczenia przesylka bedzie do odbioru w UP

Miło widzieć, że nasz narodowy dostawca poczty rozwija się i używa nowych mediów do informowania klientów o swoich usługach. Szkoda tylko, że nie bardzo wiadomo co z tą wiadomością począć. Niewiele wiem o przesyłce, którą mam otrzymać a informacja, że w przypadku niedoręczenia przesyłkę będę musiał odebrać sam jest w przypadku Poczty oczywista.

Może dobrym pomysłem byłoby zamiast magicznego numeru podać nazwę nadawcy?

Znaczenie analizy w projektach IT

Po co firma ma wydawać pieniądze na analityka? Przecież do tej pory jakoś realizowaliśmy projekty i wszystko bez niego jakoś działało. Szkoda pieniędzy na analizę.

Radzę zwrócić tu uwagę na słowo kluczowe „jakoś”. Jakoś realizujemy, jakoś działa, jakaś jakość jest. Jak to „jakoś” wygląda? No właśnie… W USA prawie 70% projektów kończy się porażką, a co piąty jest kompletną katastrofą [1]. W polskich firmach nie jest lepiej – tylko 21 % projektów uznaje się za sukces [2]. Ponadto, połowa projektów przekracza swój budżet (średnio o 1/3), a 61% przekrocza termin (średnio o 2/3).

Problemy

Z czego wynikają te problemy? Popatrzymy na 10 najważniejszych czynników wpływających na porażkę projektu [1].

  1. Brak informacji wejściowych od klienta  
  2. Niekompletne wymagania i specyfikacje projektu
  3. Zmiana wymagań i specyfikacji projektu
  4. Brak wsparcia ze strony kierownictwa
  5. Brak kompetencji w danej dziedzinie
  6. Brak zasobów ludzkich
  7. Nierealne oczekiwania klienta
  8. Niejasne cele
  9. Nierealne ramy czasowe projektu
  10. Nowe technologie

Czy to nie znamienne, że aż 5/10 czynników dotyczą ściśle roli analityka w projekcie. Brak lub źle przeprowadzony proces zrozumienia biznesu klienta oraz inżynierii wymagań jest najpoważniejszym czynnikiem porażek projektów. Aż chciałoby się rzec: „Analiza, głupcze!”.

Przecież jest project manager

Ale po co mi analityk? Jest przecież project manager, on się tym może zająć… W małych, prostych projektach – pewnie tak. Wykorzystując metodyki agile, to nawet sam PM nie będzie potrzebny. Co jednak przy bardziej złożonych systemach? 3/4 projektów ma co najmniej 100 wymagań [3]. Trzeba znać narzędzia dobrze wyjaśniające wymagania klienta. Brak tych narzędzi powoduje wspomniane wyżej problemy. Według raportu [3] najlepiej wątpliwości wyjaśniają:

  • 71,4 % – modele procesów,
  • 50,1 % – prototypy,
  • 47,5 % – modele interfejsu użytkownika,
  • 46,5 % – diagramy przypadków użycia,
  • 31,1 % – diagram aktywności,
  • 30,1 % – schematy/odręczne rysunki,
  • 6,6% % – inne

Czy project manager potrafi je dobrze przygotować? Nie tego uczył się przez całą swoją karierę…

Inni już wybrali

Na świecie widać już zmianę myślenia. Analitycy przestali być złem koniecznym, a wartościową rolą w projekcie. Według raportu przeprowadzonego przez Forrester Research [4] wśród ludzi decydujących o tym jak wyglądają projekty w największych formach IT, najbardziej znaczące role w projektach mają:

  1. Business Analysis – 70%
  2. Architecture and IT strategy/planning – 66%
  3. Project management – 65%
  4. Security – 62%
  5. Service management – 60%
  6. Client relationship management – 56%
  7. Business continuity nad IT financial management – 55%
  8. Portfolio management – 50%

Analiza decyduje o sukcesie projektu

Chcesz by Twoje projekty kończyły się sukcesem? Nie masz wyjścia. Musisz podejść na poważnie do analizy. I nie chodzi tu o to, by mianować analitykiem jednego z członków zespołu. Nie każdy może być analitykiem! Analiza wymaga świetnej znajomości technik analitycznych i zdolności interpersonalnych.

Niezależnie od przyjętej metodyki, dobry analityk pozwala skrócić czas i koszty tworzenia oprogramowania, zwiększyć jakość i szanse powodzenia projektu. Zanim więc, by poprawić moce przerobowe, zatrudnisz kolejnego już programistę, zastanów się czy nie sensowniej byłoby wydać te pieniądze na pierwszego analityka?

Źródła:

  1. http://www.sdtimes.com/link/30247 – Standish Group Report, 2006
  2. http://www.pmresearch.pl/sites/results –  Raport z polskiego badania projektów IT 2010
  3. http://info.jamasoftware.com/acton/attachment/1511/f-000f/ – Jama Software, 2010
  4. http://www.cioinsight.com/c/a/Careers/IT-Careers-Most-Important-IT-Roles-770285/ – IT Careers, Forrester Research, 2010