korzyści b2b

Ustandaryzwoane zasady pracy wewnątrz firmy mogą pomóc we współpracy z na zewnątrz z podobnym profilem działalności, gdzie są podobne rozwiązania realizacji projektów.

Franczyza w IT?

Czy to nie żart? to nie jest sklep, tylko fabryka w fabryce, jak niby to zrobić?

Firma jako fabryka rozwiązań i każdy programista jest samozarządzalną fabryką, która produkuje kod, który następnie trafia do innych ludzi, działów i dalej jest przetwarzany, Proces tworzenia nie jest prosty, wymagana jest znajomość technologii, umiejętność analitycznego myślenia. to tak skomplikowane..

Do czego się sprowadza

Różnica pomiędzy tworzeniem od początku, a wytwarzaniem wykorzystując półprodukty jest taka, że przy półproduktach nie trzeba znać technologii jej wytwarzania.

Porównanie

Porównując to do branży budowlanej, trzeba by każdy murarz miał wiedzę i umiejętności o metodach produkcji cementu.

Dlatego ODR jest dla każdego kto ma wiedzę ogólną a nawet jeśli jej nie ma, to wystarczy mały kurs

Przykład

jeśli ten system będzie wdrożony w firmie to jeśli ktoś inny też ma go wdrożone to wspołraca miedzy firmami będzie prosta bo zasaday współracy okreśła ODR

Książka

One Day Run, rewolucji w szybkosći realizacji projektów

delegowanie koncepcja prototypowanie

łatwość współpracy w międzynarodowym zespole

Filozofia modelu „Dlaczego, jak, co” nie jest nowa. Model zarządzania St. Gallen (SGMM) jako systemowa teoria zarządzania opiera się zasadniczo na identycznej strukturze.

W SGMM kierownictwo i zarządzanie firmą mają trzy poziomy.

Zarządzanie normatywne (-> Dlaczego)
Zarządzanie strategiczne (-> Jak)
Zarządzanie operacyjne (-> Co)

Model zarządzania St. Gallen został po raz pierwszy opublikowany w 1972 roku i od tego czasu jest stale rozwijany. Obecnie SGMM jest czwartej generacji.

Idea Złotego Kręgu firmy Sinek jest próbą wyjaśnienia, dlaczego niektóre osoby i organizacje są szczególnie dobre. Neurobiologia stojąca za ideą złotego koła polega na komunikowaniu się z tymi częściami mózgu, które są emocjami, zachowaniem i podejmowaniem decyzji.

Specjalista, What, Co

Jest to dość łatwe dla każdego lidera lub organizacji wyartykułować "Co oni czw Mogą to być produkty sprzedawane przez firmę lub oferowane przez nią usługi. Dla osoby fizycznej byłby to ich tytuł zawodowy. Sinek twierdzi, że wiadomości „What” dotyczą tylko kory nowej - racjonalnej części naszego mózgu. Jego argumentem jest to, że ta część mózgu to mniej niż mózg limbiczny: część, w której „dlaczego” i „jak” osiągnęły lepsze wyniki. Ludzie i organizacje odnoszące sukcesy wyrażają, dlaczego robią więcej niż tylko skupiają się na tym, co robią. Niektórzy krytycy twierdzą, że model Sinka tak naprawdę odzwierciedla pasję. Namiętni liderzy i namiętne organizacje autentycznie wyrażają entuzjazm i entuzjazm, i to właśnie one ich inspirują. Inni krytycy twierdzą, że model Sinka sugeruje, że ludzie w ogóle nie używają swojego powodu przy podejmowaniu decyzji, co jest dyskusyjne.

Co - co robimy?

W końcu definiujesz konkretne działania i działania w „co”. Ze względu na koncentryczną strukturę modelu „dlaczego, jak, co”, „co” wiąże się z wyższym celem i twoim podejściem.

W kontekście przedsiębiorczości „co” opisuje konkretne produkty i usługi oferowane przez Twoją firmę. Ten poziom operacyjny jest znacznie łatwiejszy do uchwycenia, a przede wszystkim widoczny. Być może dlatego tak wiele firm próbuje się zdefiniować i wyróżnić poprzez „co”. W ten sposób tracą szansę na bardziej niż wyraźne odróżnienie się od konkurencji z dobrym „dlaczego”.

Odniesienie - model zarządzania St. Gallen

Manager, How, jak

Czynniki „Jak” organizacji mogą mieć różne mocne strony lub wartości. Według Sinka przesłanie „jak” jest sposobem na komunikację z mózgiem limbicznym - ważną częścią rządzącą zachowaniem i emocjami. Oprócz „Jak”.

Jak - jak dokładnie?

„W jaki sposób” opisujesz swoje podejście do osiągnięcia celu. Na tym poziomie znajdziesz strategie i modele procesów, które utorują drogę do celu i zdefiniują trasę dla „dlaczego”. Jeśli „dlaczego” jest ukrytym skarbem, to „jak” jest twoją mapą skarbów, że tak powiem.

W kontekście przedsiębiorczości „jak” określa procesy o wartości dodanej, model biznesowy i organizację. Na tym strategicznym poziomie określasz, w jaki sposób Twoja firma dociera do „dlaczego”.

Przedsiębiorca: Why, dlaczego i po co?

• przyczyny

„Dlaczego” to sposób, w jaki wyjaśniasz swój cel oraz powód, dla którego istniejesz i postępujesz tak, jak Ty. Teoria Sinka polega na tym, że przekazywanie pasji leżącej u podstaw „dlaczego” jest sposobem komunikowania się z mózgiem limbicznym słuchacza. Jest to część naszej anatomii, którą czujemy jako zaufanie i lojalność

• a także podejmowanie decyzji. Skuteczne artykułowanie „Dlaczego” to bardzo znaczący sposób komunikowania się z innymi ludźmi. Teoria Sinka polega na tym, że komunikowanie „dlaczego” wpada w część mózgu słuchacza.

Właśnie dlatego Złoty Krąg jest uważany za wpływową teorię przywództwa. Na poziomie organizacyjnym przekazanie „Dlaczego” jest podstawą silnej oferty wartościowej.

Dlaczego i po co tu jesteś?

W kontekście przedsiębiorczości „dlaczego” określa cel, a nawet wyższe znaczenie organizacji. W moim rozumieniu ten cel zawsze odnosi się do klienta. Jeśli okaże się, że pytanie o „dlaczego” nie znajduje dla ciebie przekonywujących odpowiedzi, zastąp „dlaczego” słowem „za co”. „Dlaczego” to centralna gwiazda polarna, która nadaje Twojemu projektowi tożsamość. Na przykład marka bagażowa Delsey bardzo imponująco mówi swojemu klientowi „Dlaczego”.

Why, How, What - Golden Circle

What

Documentaion, Steps, how to build it?

Simon Sineck

golden circle

https://www.youtube.com/watch?v=IPYeCltXpxw

Creating a value proposition with the Golden Circle Model

evelop a more distinctive proposition for their brand amongst similar service providers.

One Day Run

jest wiele sposobów na realizacje projektów, jak znaleźć ten najbardziej optymalny?

przy wykorzystaniu zasad modelu ODR będzie to intuicyjne, firma przyśpieszy realizacjie i zwiększy jakość na każdym etapie.

Dlaczego franczyza?

Gdyż ten model biznesu pozwala na ekspansję na cały świat w sprawdzonym modelu dodatkowo w branży IT jak w mało której, będzie możliwe wspołpdzielenie zasobów , więc nie jest możliwe dziś łatwo określić jak bardzo duży będzie wpływ na branżę.

pommodoro

Zalety One Day run + mniej zmęczonie ludzie + małe projekty + łatwość wprowadzania nowych technologii + rozwoju + mikroserwisy + sprawczosc + wplyw + częste zmiany, łatwość, rutyna,

https://www.youtube.com/watch?v=2CVJuPtlNVU

Wady starego sposobu działania, długie projekty + depresja + zmęczenie https://www.youtube.com/watch?v=Jeg1gkaZERU

The authors of the Software Craftsmanship Manifesto came from the agile movement, which aimed to reform software project management in the 90s. Agile has its own manifesto: http://manifesto.softwarecraftsmanship.org/#/de

Individuals and interactions over processes and tools

Working software over comprehensive documentation

Customer collaboration over contract negotiation

Responding to change over following a plan

Nie tylko działające, ale również dobrze napisane oprogramowanie.
Nie tylko reagowanie na zmiany, ale również ciągłe dodawanie wartości.
Nie tylko osoby i interakcje, ale również społeczność profesjonalistów.
Nie tylko współpraca z klientem, ale również produktywne partnerstwo.

Według Rzemieślników Oprogramowania nie chodzi o to, aby tworzyć kod, ale o to, aby tworzyć dobry produkt. Z tego wynika potrzeba większego zaangażowania programisty w wytwarzanie oprogramowania na wielu poziomach, zwiększenie jego wymagań i oczekiwań, ustalenie poziomu, poniżej którego nie wolno zejść. Dobry rzemieślnik nie robi przecież bubli.

Software Craftsmanship

Praktyka

W dniu pisania artykułu manifest podpisało 23 376 software developerów w całego świata. Liczba ta rośnie niemal liniowo od 2009 roku. Jednak wielu najgorętszych zwolenników idei przypomina, że nie wystarczy sygnować manifestu by stać się prawdziwym Rzemieślnikiem Oprogramowania. Teoria często nie idzie w parze z praktyką. Można taką sytuację przedstawić na wykresie, gdzie na jednej osi pionowej mamy przyjęcie teorii Software Craftsmanship, a na poziomej wprowadzenie ich w praktykę.

Pierwszy przypadek to gdy ktoś odrzuca (najczęściej nieświadomie) to podejście, a także nie produkuje kodu spełniającego kryteria nurtu. Nazwaliśmy tego programistę “jako tako i fajrant”, co chyba pokazuje potencjalne efekty jego pracy. Kolejny programista to “praktyk”. Odrzuca on etos Software Craftsmanship, gdyż uznaje go za zbędny dodatek. W praktyce będzie jednak dbał o swój kod i rozwój z czysto pragmatycznych pobudek - po prostu dzięki temu jest mniej stresu. Osobę, która w pełni zgadza się z teorią ruchu, ale nie radzi sobie z jej zastosowaniem nazwaliśmy “teoretykiem”. Z wymienionych tutaj typów ten jest najbardziej niebezpieczny. Niestety etos i piękne słowa nie zastąpią kodu i czynów. Być może nawet taka osoba zostanie na początku uznana za mistrza - jednak efekt jej prac będzie daleki od doskonałego. Na koniec zostawiliśmy “Prawdziwego Rzemieślnika”, czyli osobę, u której teoria podparta jest praktyką. Ciężko jest powiedzieć ile osób z tych, które podpisało manifest poszło tą drogą.

Post Software Craftsmanship

Idea straciła nieco na blasku w tym sensie, że szczyt jej popularności przypadł na 2010-2011 rok, gdy był to częsty temat na wpływowych blogach programistycznych. Mimo to co roku odbywają się konferencje na ten temat. Np. już 27 października odbędzie się kolejna edycja Software Craftsmanship North America. Z pewnością manifest odcisnął swoje piętno na IT, przyczynił się do stworzenia etosu programisty. Dziś koncept programowania jako rzemiosła wydaje się być zintegrowanym w głównym nurcie. W momencie, w którym coraz więcej osób decyduje się na zostanie programistą z czysto materialnych pobudek warto wrócić do oryginalnego manifestu. Przypomnieć sobie jego założenia, zrozumieć czym może być nasza profesja.

Sandro Mancuso, autor cytowanej już tutaj książki „Software Craftsman. Profesjonalizm, czysty kod i techniczna perfekcja”, napisał, że Rzemieślnik Oprogramowania to ktoś, kto przeszedł długą drogę do mistrzostwa. To developer, który nie tylko zmienił sposób myślenia o programowaniu, ale włożył wiele pracy w rozwój własnych umiejętności i wpłynął na postrzeganie programowania przez innych. Trudno nie pokusić się tutaj o słowo „mentor”, nawet jeśli może się to wydawać przesadą. Warto jednak pamiętać, że prawdziwe rzemiosło w programowaniu, nawet na najwyższym poziomie, nie gwarantuje sukcesu projektu. Natomiast jego brak to główna przyczyna porażki.

Prezentacja

Wszystkie elemtny zmieścić na jednej kartce A4

aby wszystkie ważne sprawy mozna było omówić, szybko:

sposób wytwarzania Software Developmentu architektura mikrousług: SaaS

Taki sposób gwarantuje standaryzację na zewnątrz przez API To co jest wewnątrz nie jest już tak istotne.

Dobrze by było gdyby modele wewnątrz były zapisane językiem Mysql, który pozwala na opisanie struktury danych

Jak opisać procesy zachodzące wenątrz?

Obecny stan

Alternatywy dla One Day Run

Wydawać by się mogło, że są oczywiste alternatywy w postaci:

• systemów, gdzie sprzedaje sie i kupuje oprgroamwoanie

• portale typu freelance, gdzie daje sie zlecenia

• Software house, wynajmujące pracowników na godziny

• Frameworki, rozwiązania technologiczne, pozwalające modułowo budować

Każde z tych rozwiązań, dba tylko o jedną stronę: + Technologię - producentów narzędzi + Kupujących rozwiązanie - klientów zlecających + Realizujących - Developerów + Sprzedających - Software House

W One Day Run:

chodzi o uzyskanie najszybszym, mierzalnym sposobem, oczekiwanego rezultatu.

Spring Boot

https://content.pivotal.io/springone-platform-2017/from-zero-to-hero-with-spring-boot-brian-clozel

Asocjacje

spojrzenie na nawyki, rutyny od strony psychologicznej

wiad

Automatyzacja

Programowanie nie jest procesem automatycznym

wiele jednak zadań można zautomatyzować, obecnie należą do nich: CD, CI, można przy pomocy kilku dodatkowych technik sprawić, że podczas tworzenia oprogramowania najwięcej zadań będzie realizowanych podczas samoego wytwarzania, a nie jak ma to obecnie miejsce, na każdym etapie od projektu do serwisowania.

Co oznacza jakość dla klienta i dla specjalistów?

Jakie ma potrzeby klkient w przypadku realizacji projektu krótkoterminowego i długoterminowego

Jakie są narzędzie monitorowania obecnie

z jakimi trzeba zrobić integracje?

od najprostszych ogólnych do bardziej złożonych

NIkt do zamawiania pizzy nie potrzebuje specjalnego systemu ticketowego

do ubera tez nie

do samolotu tez nie

to są wszystko rzeczy dziejące się w ciągu jednej doby, kilku chwil

nie ma narzutu technologii i zarządzania

jest prost ausłgua która trzeba wykonać

Cena usług it

aby zmniejszyć cenę należało by zwiększyć konkurencję, czyli ilość programistów na rynku. albo zmienić wymagania technologiczneg, pójśc tam, gdzie jest niższy próg wejścia dla programistów, aby nie musieli znać całości, a jednynie wycinek i w nim komfortowo wykonywać zadania

nowe sposoby zarządzania projektem realiacja projektu w jeden dzień.

Kontrola jakości

poprzez uczestnictwo w każdym zadaniu 3 osób, które zlecają, nadzoruja i wykonują zadania, nastęepnie trzeba się na wzajem ocenić i każdy może opisać jak ta sytuacja z jego perspektywy wyglądała i co trzeba zmienić w przyszłości.

klient

Jak projekt jest realizowany od strony klienta

Współpraca z klientem

ważne na początku i na końcu, aby poznać problem, który trzeba rozwiązań i zaproponować rozwiązania a następnie zdefiniować

Programista zajmuje się realizacją i na koniec on sam kontaktuje się z klientem, aby dograć szczegóły

Efektem pracy 3 osób w jeden dzień jest jedna mała aplikacja

Korzyści

Mierzalność

Nie tylko efektów pracy, efektywności ale też efektywności komunikacji z klientem

taki sposób, gdzie są małe zadania, można łatwo uzyskać dużo przejrzystych informacji

inaczej, gdy warunnki sa zmienne, każdy projekt jest bowiem inny, wymaga różnych zasobów dlatego sprowadzając każdy projekt do małych kroków, można kontrolować każdy krok i mierzyć jak sprawdza sie podejście i co można zmienić.

Perfekcyjność a jakość i zadowolenie klienta

Obecność inżynierów wprowadza wysoką kulturę pracy, co oznacza bardzo restrykcyjne podejście do rozwiązywania zgodnego ze schematami nabytymi na drodze edukacji.

Zas to co liczy się dla firmy to efekt, tego działania. Jeśli jest możliwe uzyskanie zadowlających efektów, nie stosując wyśrubowanych norm, to wiele firm, chętnie zgodzi się na obniżenie jakości w imię zwiększenia obrotów, gdyż nie o jakość tutaj się rozschodzi a o zadowolenie klienta, ewnetualne poprawki można zrobić w miarę czasu, gdy klient, będzie o nie zabiegał, ale nawet jeśli będą luki bezpieczeństwa, to nie w całym systemie tylko w jednym jego elemencie, a jeśli nawet w kilku to nadal nie jest to wprost do przewidzenia i zaplanowania, więc element losowości nadal jest po stronie biznesu.

Dla kogo to rozwiązanie

DLa wszystkich firm mających zaplecze it, które jest ich dodatkowym

Kontrola jakości

poprzez standaryzację procesu produkcyjnego można monitorować efektywność pracowników

Minimalizacja strat

Modele

tworzenie małych modeli oprogramowania i danych, możliwych do łatwego definiowania zarządzania, customizowania, implmentacji, refaktoryzacji

Ilość ludzi potrzebnych w projekcie

Zamiast rozwijać techniki zarządzania, lepiej polegać na prototypowaniu skorelowanym z odpowiedzialnością za wyniki tego prototypowania ograniczonego w czasie

Zasoby ludzkie są ograniczone do minium, makysmalna ilość 3, gdyż wówczas komunikacja jest bardzo prosta, nie wymaga dużego zaangażowania, staje się łatwiejsze rozsztryganie niż w p[rzypadku zespołu odpowiedzialnego za wiele rzeczy na raz na wielu etapach w wilu miejscach kodu.

Lepiej przydzielić konkretnych ludzi do konkretnych zdań i dać im odpowiedzialność.

Rynkowe zasady wewnątrz firmy

Skupienie uwagi na rozwiązaniach

Praca ludzka

w tym momencie będzie ostateczcnośćią

będzie też jedną z opcji gdyż będzie możliwe wygenerowanie roziwązania poprzez połączenie kilku modułów

Metodologia

W przypadku standardowych projektów

dobrze jest się spotkać klienci oczekują tego

chcą wiedzieć kto będzie robił bo wiedzą że to ryzyko

W przypadku One Day Run nie ma ryzyka, gdyż każdego dnia jest coś nowego jeśli nie, to można zrezygnować i realizować dalej z innym klientem

łańcuch dostaw

to nie jedna usług, tylko wiele usłgu, dzień po dniu kazda jest rozliczana oddzielnie

Obecny stan

Obecne ograniczenia

w społeczeństwie

• więzi społeczne

w zespołach firmowych

Specyfika wdrożenia w Com40 była inna niż w przypadku pozostałych klientów Novacura. Ponieważ zespół Com40 jest bardzo samodzielny informatycznie i nie chciał pozbywać się swojego autorskiego zestawu sprawdzonych procesów, zdecydował się na odwzorowanie ich w Novacura Flow, adaptując do swoich potrzeb wszystkie brakujące i najbardziej wartościowe z punktu widzenia firmy funkcje. Całość idealnie wpisała się w ekosystem firmy.

Przyjęta strategia okazała się dużo prostsza i mądrzejsza niż rozwijanie starego systemu. Firma wolała skorzystać z outsourcingu IT, kupując Novacura Flow, niż zatrudniać nowych specjalistów IT, o których trudno w tym konkretnym regionie Polski.

– Nasz pierwotny system był dużo bardziej skomplikowany niż Novacura Flow. Na przykład w momencie pojawienia się potrzeby przekazania obowiązków innemu pracownikowi musieliśmy tworzyć specjalną dokumentację – mówi Błażej Macniak, specjalista ds. utrzymania i rozwoju systemu ERP z Com40. – Z Novacura kwestia „wejścia w czyjeś buty” i rozpoczęcia, kontynuacji czy modyfikacji pracy jest banalnie prosta.

udało się również zmienić dotychczasowe przekonanie pracowników, że rejestracji danych w systemie może dokonać jedynie specjalnie do tego wyznaczona osoba – przywiązany do stanowiska komputerowego referent. Teraz każdy pracownik produkcyjny musi wykonać tę pracę sam na swoim stanowisku pracy. To bardzo ułatwia i przyspiesza działania w całej firmie.

Dzięki wiedzy, jaką mamy dziś na temat możliwości Novacura, możemy reagować na pojawiające się wyzwania. Wiemy, jak minimalizować wąskie gardła, jak usprawniać i modyfikować to, co funkcjonuje w firmie. Nie musimy się przyzwyczajać do tego, co jest, możemy reagować, zmieniać, ulepszać, przyspieszać i to przy bardzo ograniczonych zasobach informatycznych

Wdrożenie trwało miesiąc – jak wspominają pracownicy Com40, nie upłynęło nawet 30 dni od umówienia terminu spotkania do pierwszej realizacji. Początkowo Com40 korzystał ze 100 licencji, obecnie wykorzystuje dwa razy tyle.

Połaczenia

Najbardziej optymalna ilość połączeń to 2 lub 3, dlatego aby procesy w projekcie nie były zależne od większej liczby osób warto je podzielić, zakolejkowąć i delegować maksymalnie jednej osobie jedno zadanie:

Jeśli zadanie wymaga wielu ludzi, to trzeba je podzielić tak, by możliwe było wykonanie przez wielu ludzi kolejno, a nie w jednym momencie.

zmniejeszenie ilości połączeń, stworzenie systemu kolejkowania gdzie nie będzie tyle zależności zwalnia zasoby nie tylko w sensie połączeń, ale też czasu i zaangażowania gdyż praca do wykonanaia jest określona, ograniczona, nie ma możliwości na grzebanie się z kodem, z koncepcją, z klientem

są proste pytania i odpowiedzi.

jeśli np. klient nie odpowiada, to nie ma problemu z prowadzeniem projektu na przód, gdyż można te niewyjaśnione kwestie zostawić na potem i zajmować się tym co jest jasne i klarowen

można układać plan pracy na tygodnie, z uwzględnieniem jednostek na każdy dzień w ten sposób łatwe jest przewidzenie opóźnieniń, bo najmnijesza jednostka to jeden dzień

Obecna praktyka w firmach

Superprogramiści

• mamy super pracowników, doskonale radzą sobie nie ma problemów, szef może im wszystko delegować a oni nawet nie mrugają okiem,

Przyczyny

Może być wiele przyczyn, może być to nawet prawda, ale może być też coś o czym szef nie wie:

• kod nie spełnia standardów
• polityka ukrywania problemów i wyrzucania tych, którzy nie nauczą się grać w tą chorą grę

Nawet jeśli wszystko jest w porządku, to nie mamy pewności, kiedy przestanie więc czym szybciej ustandaryzujemy i będziemy mieli wgląd w to, to będzie szansa

Know How

Nawet jeśli firma działa perfekcyjnie, ale nie znasz zasady działania tej perfekcejnyj maszynki skąd bierze sie ten sukcees, tylko zawdięczasz ja (czasen przypadkowo) dobrze dobranemu zespołowi, to warto zastanowić się jak zdobyć receptę na ten sukces raz jeszcze, by zwielokrotnić zyski. Otworzyć nowy oddział, itp.

"Done is better than perfect"

"Dług techniczny"

Temat dobrze znany, ale rozwiązania brak

Przewidywalność

Jak realizować różne projekty i mieć zawsze dobre rozwiązanie?

Kontakty z klientem

Kto kiedy i jak się kontaktuje?

Psychologia

jak wygląda samopoczcucie pracowników jak nie być skazanym na ich humory

jak zamykac projekty szybciej jak nie mieć problemów z motywacją

satysfkacja wykonanych

Zasada małych zywcięstw

5 zwyciestw 5 zadań dziennie lista przypominaczy

mentalne nastawienie

codzienna rutyna

mówisz co zrobisz, dotrzymujesz swojego słowa, deklaracja

1. Język opisowy

• co już jest

2. język deklaracji

• co zrobię

3. Działanie Zachowywanie się aby dotrzeć do tego realizacja natychmiast tego co chemy uzyskać

• nie ma tutaj efektu docelowego od razu, ale jest krok po kroku coraz lepsza wersja tego co chcemy na końcu

Przykład: dziecko

Celem jest nie chodzenie, a przemieszczanie się wówczas każda forma przemiesczania jest sukcesem, miarą szybkość przemieszczania cele można stawiac odnośnie miary, szybkości

1. dziecko nie chodzi
2. dziecko chce chodzić
3. dziecko pełza, raczkuje, chodzi, biega

Przykład: narzędzie do realizacji projektów dziennych.

• ograniczenie perspektywy do jednego dnia
• realizacja małych projektów lub dużych po podzieleniu

1. Obecnie mam ogólne plany, nie mam sprecyzowane wszystkiego
2. chciałbym codziennie realizować jeden gotowy projekt, mały, ale działający
3. Najpierw będą to projekty związane z dokumentacją, potem definicją, prototypem i

Mały

Relacje

Poczucie własnej skuteczności

siła przekonania, iż jest się w stanie zrealizować

połączenie skuteczności z im poziom wyższej skuteczności tym lepiej

Projekty

Każdy projekt jest procesem nie tylko realizacji celu ale także poznawania tego co działa a co nie działa, ta wiedza służy budowaniu lepszego produktu i najłatwiej i najszybciej można ją zdobyć po prostu zaczynając projekt.

Zatrudnianie

• jak wygląda obecnie
• jak może wyglądać wykorzystując ODR?

Dla kogo

Firmy, które chcą zwiększyć swoją efektywność Szukają metod pozwalającą na automatyzację planowanie, delegowania i wykonywania zadań

Rozwiązanie może być szczególnie przydatne dla młodych zespołów, start-up-ów, szukających metod i narzędzi do szybkiego stworzenia rozwiązania dla stworzenia odpowiedniego oprogramowania.

Aplikacja sprawnymi metodami zarządzania pozwala na szybką implementację.

Jaki profil firmy

W obecnej formie, jesteśmy w stanie pomóc w tworzeniu web-owych aplikacji.

Etapy

W pierwszym etapie, potrzebne jest zebranie informacji od zespołu, aby dopasować wdrożenie

Następnie przez kilka tygodni testowania, wyrobienie nawyków

Jak już system będzie sprawnie funkcjonować

Plany

Obecnie jest wiele różnych systemów zarządzania, dlatego w przyszłym roku powstanie kilka integracji dla popularnych rozwiązań z firm: google, microsoft, ..

Gra społecznościowa

Realziacja projektów jako gra W dobie niskich kwalifikacji i niskich ambicji wśród młodych warto dodać elementy gry, aby możliwe było stworzenie naturalnych warunków do rozwoju.

Jednostki

Najmniejsza jednostka czasu to 1 dzień, ponieważ fizycznie można w ciągu klilku godzin zrealizować coś i ocenić to w ciągu 1h byłoby to trudne

Czas jednego dnia

ni jest przypadkowy gdyż pozwala na łatwe zarządzeniie, nawet jeśli pojawią się problemy, to zawsze można to zrobić na drugi dzień gorzej, gdyby zadania były na tydzień, wówczas nieobecność jednego pracownika wprowadziła by 7 dniowe opóxnienie jeast to 7 x więcej, stąd łatweij zorganizować sobie czaqs na jeden dzień iłatwiej nadgonić jeden dzień niż cały tydzień

ale by sdo tego dotrzeć, trzeba też określić zakres zadania oraz plan działania, kolejne zadania, jakie musi wykonać programista nie tylko jaki efekt chce uzyskać, ale jak krok po kroku chce go uzyskać gdzie widzi potencjalne problemy

Lista kontrolna

lista zawiera punkty niezbędne do wykonania czynności

lista jest potrzebna do przygotowania się do wykonania czegoś

w formie pytań lub zdań oznajmujących

Przykłady:

materiały wideo:

• Przedstawienie się. "Cześć, nazywam się Tomasz"
• Spis treści. Omówienie czego dowie się słuchacz/widz "Z tego nagrania dowiesz się: A, B, C, D"
• Omówienie kolejnych punktó
• Podsumowanie
• Wezwanie do akcji. "Jeżeli to nagranie było dla ciebie wartościowe i chcesz dostawać więcej takich materiałów, zapisz się na mój newsletter na stronie programista.de"

https://tallyfy.com/procedure-vs-process/

Process vs Procedure: What’s the Difference? - Tallyfy

A process is a series of related tasks or methods that together turn inputs into outputs.
A procedure is a prescribed way of undertaking a process or part of a process.

At a glance, the two might seem confusing, as they both refer to the same activities being carried out. So, to make it easier, you can look at the difference between a process and a procedure as “what” versus “how.”

A process consists of three elements:

• An input (materials or information)
• A process with its sub-processes
• An output

A procedure, on the other hand, describes:

• Who is responsible for each part of the process
• When each part of the process occurs
• The specifications applicable to each part of the process

Considering the differences between the two terms, it shouldn’t be too surprising that there are different ways to document them. For a process, a simple workflow diagram would do. Procedures, on the other hand, would be explained through a physical or electronic document (To complete the process, do X, Y, and Z). Unlike processes, a procedure doesn’t have to be a workflow – a set of simple guidelines could suffice.

Process and Procedure Example

A fast food outlet makes hamburgers. The process is a simple one, and it all starts with taking the order. After that, the staff springs into action, cooks the patty, prepares the hamburger roll and serves the finished hamburger up to the client.

However, inside this simple process, the fast food outlet’s staff also follow several procedures. Thus, the store owner might specify that the sales assistant should greet the client and smile. He or she may even provide a script for the interaction. That’s a procedure, and it can make a huge difference to a business.

Just think of it: even if the sales assistant is rude and unfriendly, he or she has still completed a part of the hamburger-making process the minute the order is written down. Sure, the customer isn’t going to come back, but the sales assistant has still done the job. The “what” criterion has been fulfilled.

But if the person behind the counter follows a procedure that indicates the expected standard for customer interactions, the entire customer experience changes. Sure, the task remains the same: the assistant writes the order. However, the customer is happy because the quality of the order-placing experience was so much better.

Metodologia

Model działania, składniki, wzorce

Wzorce tego modelu są wykorzystane z ogólnego podejścia, nie z modeli książkowych ale rynkowych, które na co dzień są efektywne:

wolny rynek wewnątrz firmy a nie centralne sterowanie daje swobodę, ale nie zwalnia z odpowiedzialności

w zasadzie odpowiedzialnośc zostaje delegowana, co jest bardzo pożadane, gdyż finalnie odpowiada osoba, które podjęła się dobrowolnie zdania, które uważa, że wykona szybciej, lepiej niż konkurencja - koledzy

Wdrożenie

Najlepiej w środwisku wielu firm gdzie jest potrzeba wykorzystawnia software developmentu w róznych aspektach działanaia gdzie nie ma jednej osoby odpowiedzialnej za software tylko wiele ludzi ma potrzeby i można to delegować zewnętrznej firmie

Gdzie

Najlepiej tam, gdzie można na bieżąco komunikować się w celu poprawy systemu wyjaśniania niejasności i wdrażania ulepszeń

https://www.startplatz.de/

https://www.startplatz.de/tarife/

Firmy szkolące przyszłych prgoramistów

tam można szukać kandydatów do testowania systemu od strony realizacji kodu ewentualnie analityków do zdefiniowania zadania.

Techniczne wskazania

W pierwszej fazie model obejmuje:

• SQL: MySql, PostgreSql, SQLite
• python + API
• nodejs + API
• javascript, html, css
• docker

Srodowisko pracy w projektach IT

Środowisko

Otwarte oparte na delegowaniu odpowiedzialności nie ma tutaj ticketów do zrobienia tutaj każde zadanie jakie się chce wykonać najpierw trzeba samemu poznać więc jeśli są jakieś niejasności, to najpier trzeba je rozwiać, aby to było możliwe to powinni ze sobą współpracować Ci co zlecają oraz wykonują a także 3 strona, która będzie odpowiedzialna za efekt, coś co normalnie nie funkcjonuje, ponieważ często jest tak, że są tylko 2 strony i trudno im bazować na tym modelu, gdyż nie jest przewidziana ingerencja osoby trzeciej jedynie w ograniczonym układzie tutaj 3 osoby musżą być jednocześnie zaangażowane, ale przy okazji wpływają na siebie i rezultatem jest:

• szybsza zdecydowana reakcja
• więcej informacji
• poprzez zadawanie pytań jest więcej odpowiedzi

Dostawca usług:

https://cloud.google.com/products/

Flow

Flow to stan, kiedy zatracasz całkowicie poczucie czasu. Flow to stan całkowitego zatracenia się na wykonywanym zadaniu. Zapominasz o całym świecie i koncentrujesz się mocno na tym, co w danej chwili robisz. Najlepsze jest to, że nie sposób Cię od takiego zadania oderwać.

Jak osiągnąć stan flow w pracy? Przede wszystkim powinieneś pracować nad tym, co Cię zabójczo pasjonuje.

Ciężko jest zatracić się w zadaniu, którego nie będziesz chciał wykonywać. Bo tego nie lubisz, bo się na tym nie znasz, bo wolałbyś zrobić w tym czasie coś zupełnie innego. Kiedy skoncentrujesz się tylko na jednym, konkretnym zadaniu, które dodatkowo będzie Twoją pasją, to wejdziesz w stan flow.

Wyłącz telefon, radio, telewizor. Powiedz domownikom, że będziesz bardzo zajęty i nie chcesz, by ktokolwiek Ci przeszka- dzał.

Budowanie modelu

Czas, podział na interwały, stoper

Zasada pomidorro Ustal, że nad zadaniem będziesz pracował tylko 10 minut. Kiedy już ruszysz, a czas będzie dobiegał końca, możesz przedłużyć o kolejne 10 minut. Skoncentruj się na zadaniu na krótki czas. Sam określ, czy to będzie 15 czy 20 minut. Prawdopodobnie w tym czasie bę- dziesz potrafił skoncentrować się tylko na tym zadaniu. Kiedy zajmiesz się czymś, co ma trwać 3 godziny będzie trudniej utrzymać koncentrację.

Wartościowanie, dlaczego warto?

Jakie korzyści będziesz miał, gdy podejmiesz działanie? Dobre oceny? Więcej czasu na swoje hobby? Dodatkowe pieniądze? Kiedy wyznaczam swoje cele, to zawsze zapisuję także powody, dla których ich zrealizowanie jest dla mnie ważne.

Nagradzaj się.

Kiedy zrobiłeś cokolwiek w zamierzonym kierunku, wyznacz sobie małą nagrodę. Jeśli uczyłeś się systematycznie — idź do kina, na lody, pograj na komputerze.

Wtedy ładujesz akumulatory i wzrasta chęć do robienia kolejnych kroków.

Wiseman proponuje, żeby za każdym razem odpowiedzieć sobie na cztery bardzo ważne pytania: + Jaki jest Twój cel? + Jakie będą korzyści z jego osiągnięcia? + Jakie przeszkody pojawią się na drodze? + Jakie podejmiesz wtedy działanie?

Sprawdzę, czy oferta zawiera wszystkie niezbędne elementy (opinie klientów, lista korzyści, gwarancja, podpis, historia itd.). Przetestuję inny nagłówek. • Sprawdzę, czy sprzedaż ulegnie zmianie, jeśli zwiększę • lub zmniejszę cenę. Sprawdzę, czy dodanie bonusów zwiększy sprzedaż. • Sprawdzę, czy wprowadzenie zwiększenia wartości ko- • szyka pozwoli uzyskać zakładany cel.

Dlaczego więc powinienem pisać artykuły, nagrywać wideo i robić szkolenia: Dlatego że potrafię tłumaczyć skomplikowane zagadnienia w prosty sposób. Dlatego że potrafię dostarczać skutecznych rozwiązań wtedy, gdy wszyscy inni bezradnie rozkładają ręce. Dlatego że chcę zapewnić bezpieczeństwo swojej rodzinie.

Dlatego że lubię otrzymywać informacje zwrotne od czytelników: lubię po każdym napisanym artykule czytać komentarze i maile. Tak, to może trochę narcystyczne, ale lubię czytać, że robię dobrą robotę. Dlatego że podobno mam w sobie coś, co skłania ludzi do działania. Dlatego, żeby udowodnić niedowiarkom, że mimo takich, a nie innych warunków ekonomicznych w Polsce można zarabiać uczciwie godziwe pieniądze. Dlatego że mam pewne umiejętności oratorskie, odpowiedni sprzęt i wspaniałych ludzi, którzy pomagają mi podczas produkcji wideo. Grzechem by było nie wykorzystywać tego całego potencjału. Mam także jeszcze jeden, bardzo osobisty powód. A mianowicie robię to, co robię, także dla Boga. Wierzę, że skoro zosta- łem obdarowany pewnymi umiejętnościami, to powinienem je maksymalnie wykorzystać. Jestem przekonany, że gdy nie robię pożytku z tych wszystkich możliwości, jakie przynosi mi życie, to zadaję Mu cios.

Środowisko

Stworzenie takiego środowiska, żeby niemożliwe było niezrobienie tego, na czym Ci najbardziej zależy. Praca nie zawsze składa się z przyjemności. Czasami trzeba wykonać zadania trudne, nudne i złożone, ale one po prostu muszą być zrobione.

Extreme Productivity

Kiedy na sali siedzi przed Tobą pięćdziesiąt osób — nie ma możliwości, żeby powiedzieć: „Pomyliłem się. Powtórzmy ostatnie 15 minut”. W przypadku jakiegoś błędu językowego poprawiasz się i jedziesz dalej. Zatem zamiast się rozdrabniać na 3–4 dni, co dodatkowo wiąże się z traceniem czasu na ustawianie sprzętu, przebiera- nie się itd., wolę zarezerwować dzień lub dwa i zorganizować szkolenie stacjonarne. Oczywiście płacę za to pewną cenę, ponieważ trzeba opła- cić ludzi, salę, catering, dojazd, jedzenie. Jednak dzięki temu w ciągu jednego czy dwóch dni mam nagraną taką ilość ma- teriału, jakiej nie byłbym w stanie nagrać w tym samym czasie samodzielnie, mówiąc tylko do kamer.

Mind Evolution Academy. Po styczniowym szkoleniu stwierdziłem, że system działa doskonale bo: Szkolenie stacjonarne jest płatne. Wartość dla uczestni- • ków jest ogromna, ponieważ możemy się spotkać twarzą w twarz, mogą mi zadać pytanie, poznać innych cieka- wych ludzi i będąc na sali zrobią wreszcie ćwiczenia, któ- re — gdyby były zamieszczone w książce lub na nagraniu 68 Przestań jęczeć i weź się wreszcie do roboty — zwyczajnie by przeskoczyli. Na sali nie ma ta- kiej opcji — taki kontekst wręcz wymusza robienie ćwiczeń. Wszelkie koszty logistyczne (sala, dojazd, pracownicy, ho- • tel itp.) pokrywane są z wpłat osób, które przychodzą na salę i jeszcze jest na tym zysk. A nawet jeśli wpłaty pokry- łyby jedynie wszystkie koszty, to i tak wyjazd jest opłacal- ny, ponieważ znacznie szybciej został zarejestrowany cały materiał.

model

Jeśli chcesz coś zrobić, a nie wiesz jak? znajdź kogoś, kogo dany przedmiot fascynuje, kto przeszedł wcześniej tę drogę. Niech opowie Ci o swoich sukcesach, ale także porażkach. Co go wtedy wspierało? Jak sobie z tym poradził? Pytaj i ucz się.

Jedno zadanie po drugim

Im więcej zadań chcesz wykonać w jednym czasie, tym mniej efektywny będziesz.

Relaks, odpoczynek

jak działa

składniki

• unikalna nazwa projektu Programista
• wybór języka

Automat - devops

• generuje srodowisko defualtowe o i le nie zostało skonfigurowane docker

Programista

• programuje,
• Commit push

Automat - devops CI

• testuje, podaje wynik

jak realizować projekty

Definicja flow

Założenia są takie:

• 1 projekt

• 1 klient

• 1 analityk

• 1 programista

To definicja relacji pomiędzy dwiema stronami:

• klient-analityk

  • zebranie specyfikacji

• analityk-programista

  • wykonanie planu działania

• klient-programista

  • realizacja i monitorowanie

Współpraca z klientem poprzez narzędzia pokazującą kllientowy wygląd life i pokazujący programistom interakcje, co robi klient jak naciska, itp

Fazy

App design https://books.apple.com/de/book/einf%C3%BChrung-in-die-app-entwicklung-mit-swift/id1215105506?l=de App design ide, tynker https://apps.apple.com/de/app/tynker-learn-to-code-programming-made-easy/id805869467

What is a Product Design Sprint?

It is a 5-phase exercise which uses design thinking to develop a product or feature idea into a prototype that can be tested to help us fill our riskiest knowledge gaps, validate or invalidate our riskiest assumptions and guide future work.

Phase 1: Develop a common understanding of the working context including the problem, the business, the customer, the value proposition, and how success will be determined
Phase 2: Generate insights and potential solutions to our customer’s problems.
Phase 3: Come up with a realistic prototyping storyboard and develop an assumptions table to guide our prototyping and testing phases.
Phase 4: Build a prototype that can be tested with existing or potential customers. 
Phase 5: Test the prototype with existing or potential customers. 

What we deliver during a Product Design Sprint Early validation for your product

During the sprint we decide what to test, how we’re going to test it and then run a handful of interviews to validate our assumptions. You gain invaluable insights into the mind of your customers in a concise timeframe. Team understanding and alignment

The sprint is designed to get all team members aligned on both why and how we’re going to solve problems. We generate ideas together which fuels innovation. Because we working together, you’ll get buy-in from your whole team. A prototype and recorded interviews

You will have recordings of the interviews and the prototype that we created but the most important deliverable is the understanding you get at the end of the sprint. We’ve had several client’s use the prototype to secure funding from investors to continue to move their product forward.

My First Product Design Sprint

Last week, I had the opportunity to be part of my first product design sprint. It was an exciting, exhausting, and intense learning experience that I want to share some tidbits of.

We did the sprint together with Andreas from Promoter: A Stockholm-based startup that helps game developers and publishers track press mentions and to distribute keys and promo codes to journalists.

Andreas and I were joined by Teo and Reda. Both Teo and I are developers in our Stockholm office and Reda, who facilitated the sprint, is our design director.

The goal of the sprint was to increase the number of people trying out the service after visiting the site.

Over the week we went through many of the exercises outlined in our Product Design Sprint guide. Here are some of my favorites:

Five Whys

The Five Whys exercise is used to dig deep into the reasons of a problem to get to the very root of it. It’s done simply by writing down a problem and then asking “Why?” five times, each time writing down a new problem based on the answers.

I found it fascinating that with some added structure, asking the same question five times can provide new insights.

Crazy Eights

Crazy Eights is a short exercise to generate lots of ideas really quickly. It’s done by folding a paper in half four times to produce eight panels and then spending a maximum of five minutes filling them with really rough sketches of eight different user interaction ideas.

We did this exercise a couple of times throughout the sprint and it really helped to jump-start my creative thinking.

Silent and Group Critique

After some rounds of crazy eights we dove deeper into the details of our best deas with the Story Boarding exercise, sketching out flows through the UI.

We followed up on this with both silent and group critique. During the silent critique everyone posted their ideas on the wall. We then individually looked at all of them, putting dot stickers on parts we found interesting or had questions about; this made some of the ideas really stand out.

We went through all the parts with dot stickers as a group, asking everyone what they liked about them.

This way all voices were heard.

Summing Up

As a developer, taking part in a product design sprint was enlightening; it taught me new things about design thinking, introduced me to exercises to help channel my creativity, and showed me new ways of approaching problems.

After the first days, I also had a solid understanding of the product and the problem it was solving. I would have no trouble jumping onto the project, making informed decisions about implementation and prioritization while building out features and squashing bugs.

Having developers take part in product design sprints is also beneficial to the sprints since it diversifies the perspectives and allows for valuable feedback that can avoid wasting time testing out technically unfeasible solutions.

We think product design sprints are an effective and efficient way to learn and to validate ideas and concepts. Therefore, we’d like to do more of them in Stockholm. If you think it sounds interesting, get in touch!

Licytacja

Aktynwa wersja trello

gdzie można opisywac zdarzenia automatyzowac co jak sie pojawi akcja

akcje wziac z api trello

• CRUD

  • Board/Space/Env/Day
  • Column/Projekt
  • Card/Ticket

• People Action

  • move
  • change
  • add me to Ticket

w kazdym ticketie jest chat z robotem, serverem lub osoba

Szablony Realizacji projektu https://trello.com/teams/wedding-planning

http://community.uservoice.com/blog/trello-google-docs-product-management/

How We Use Trello & Google Docs to Make UserVoice Better Every Day | UserVoice Blog | UserVoice Blog

Editor’s Note: Need help building an awesome product roadmap? Don’t forget to check out Get Your Priorities Straight! The Product Manager’s Guide to Smart Product Roadmap Prioritization, our free eBook geared towards product managers facing some tough decisions as they map out the next leg of their product’s journey on their product roadmap.

Get the full version for detailed advice on how to prioritize your product roadmap!

---

Last fall I returned from vacation to find that UserVoice‘s Product Manager, Dejana, had replaced my precious Google Doc “Roadmap” with a Trello board.

It should be noted that my initial reaction to this new process was not positive. My issues weren’t really with Trello but rather how we were using it. Trello is a VERY open ended product. Trello, purposefully, doesn’t prescribe a “right” way to use it so it requires you to get inside and move the furniture around a bit to get it feeling like home.

However after much experimentation, I think we’ve finally arrived at a process we’re very happy with and I thought we should share how it works and what we’ve learned along the way. This will be a longer post than usual and, if you’re not into the process of delivering web products, probably a bit dry. If you prefer to skip directly to our lessons learned, I’ll be sad but not offended.

Our Process

Our development process spans 6 different Trello boards. The focal point of all of these boards is the Current Development board. The goal of all the other boards is to feed cards (representing either an enhancement or a bug, more on these in a minute) into the Current Development board and specifically into its Next Up column. The Next Up column is THE single prioritized list that all of the product team (developers & designers) looks at when they’re ready to take a new card to work on.

Before we dive into the role of all these different boards let’s talk about the blood cells in our product development circulatory system: Trello cards.

[cta id=’2003897′]

Cards

A card represents a single story to be implemented. It could be a new enhancement, a refactoring task or a bug.

Enhancement cards start out as a simple idea, 1-2 sentences long. But before they can move in development they’ll be expanded to include a link to a full-blown Google Doc “spec” and a set of wireframes or (rough) mock ups.

We use the term spec fairly loosely here. These aren’t the specs you remember from your college project course or that crappy enterprise IT consulting company you worked for right out of college. The spec explains the high level customer story, why (from a business perspective) we’re addressing this, what we hope to achieve, and maybe some notes on suggested implementation (though engineers may take or leave this section at their discretion; it’s supposed to be helpful not prescriptive). A good spec will also include first-hand customer stories and a link to the related idea on our UserVoice forums.

If the card is a bug then it simply has steps to reproduce the bug (which hopefully includes a screencast) and a link to the UserVoice Helpdesk ticket that originated it.

How the sausage is made

The Current Development board is the “where the magic happens” board. It has the following columns:

• Next Up
  • Prioritized list of all cards vetted and ready for design & development.
  • It’s worth noting that as a engineer or designer you’re not required to take the top card off the stack but rather the top card you feel most apt to handle.
• In Progress
  • These are the cards that are under active design or development.
  • Once you take a card you “put your face on it” (assign it to yourself). Dev etiquette is that you should never have your face on more than 2 cards at a time: 1 major project and 1 minor.
  • When an engineer takes a card they assign a due date on it to let others know the “expected” delivery date of this card to QA. A quick scan of our board tells me that this rule is more aspirational than executed upon.
• QA
  • When the engineer thinks they’ve completed the story, they’ll deploy it to staging (or sometimes to production but hide the feature behind a “feature flag”) and drag the card to QA. At this point it our QA manager and Head of UX are responsible for taking a look and verifying that everything looks okay for this to go live.
  • As mentioned previously, If the card is an enhancement project that’s quite large we’ll spin up a whole new board dedicated to issues that came up during QA of that project. The project card will stay in QA until all the cards on the project specific QA board are done.
• Launchpad
  • These cards have been reviewed by QA and are ready to be deployed (but not necessarily launched, but more on that in a minute) and there’s probably a GitHub Pull Request associated with it (which will be merged into master by the person that opened the pull request. It’s worth noting that there is no central chokepoint for merging into master: everyone can do it).
  • If the card is a bug or refactoring task it will be deployed to production immediately (but not after 3p PST unless you, as the deployer, are willing to be around for the next 90 minutes to monitor any issues that come up).
  • If the card is an enhancement then it will be deployed to production but will be hidden from end-users by a “feature flag”. Feature flags are named conditional bits that can be turned on, on a per-account basis, to grant access to the new feature. We’ll immediately turn it on for our own UserVoice account and any customers selected by the customer team for early access but otherwise it falls to Marketing to turn on for all accounts when it’s officially launched.
• Live (Week #)
  • These cards have been deployed and are no longer hidden behind feature flags.
  • The only people who move cards to “Live” (essentially our Completed list) are the Product Manager (for enhancements) and the Bug Reporter (for bugs). This helps ensure that the feedback loop is completed before cards move out of sight.
  • Each week has it’s own Live column so we can track what got launched when.

In addition we use 3 labels that can be applied to a card:

• Bug
• Staging – Deployed to staging
• Production – Deployed to production

That was easy right? It’s very much a Kanban style approach to development. Now let’s dive into how cards get onto this board in the first place.

Mommy, where do cards come from?

New cards can come from one of 4 different boards:

• Product Roadmap

  • This has all the major projects for each quarter looking roughly 3 quarters ahead. These big projects are moved to the Planning board once that quarter begins.

• Inbox

  • There are two columns on here: one for ideas from anyone in the company and another for customer ideas (related to UserVoice Helpdesk support tickets or ideas submitted to our UserVoice customer feedback forums).
  • The ideas on this board are reviewed once a week during our Inbox Review meeting (see below for more details).

• Bugs

  • There are 3 columns here:
    • Inbox – unvetted reported bugs.
    • Needs input – We’ve had issues reproducing the issue and the original reporter needs to provide more info.
    • Accepted – Yes, this is almost most certainly a bug.
  • If a bug moves to Accepted and is considered “Critical” by the customer team (you can see how we decide that by reading our critical issue escalation process) then it moves immediately to the Current Development board and the “dev on call” is alerted.
  • If the bug is not critical it stays in Accepted until the Head of Customer Service moves it into the Next Week column which is the bugs that will be fixed next week (duh). The caveat is that he’s only allowed to pick 7 bugs per week. Why only 7 you ask? Because there are always bugs and the customer team always wants them all fixed but one of our major learnings was to set a constant throttle of how much time we’d devote to (non-critical) bug fixing.

• Engineering

  • We keep a list of areas that we think might need refactoring. Each list is a category (eg, Backend, Frontend, Tests, Infrastructure), and each card is a refactoring project or other non-customer-facing project.
  • Engineers take small cards when they feel like it and add them to in progress; larger cards need to be planned in the Next Up list

Who said central planning doesn’t work? (Planning board)

The Planning board is where myself, our PM, and head of UX spend the majority of our time. It has the following columns:

• Next Up
  • This is our roughly prioritized list of the next projects we want to spec out for development
• Spec
  • This means “someone needs to write a spec”. The card at this point is usually just a rough idea.
  • We use Google Docs for specs and heavily rely on contextual comments to asynchronously discuss any contentious points with other members of the team. Any sufficiently complex contentious concept will be fleshed out in an impromptu design meeting (more on this in next section).
• Design
  • Means that the card needs a designer to take a look at it, duh. This doesn’t necessarily mean that a wireframe or mockup will be made as the design stage isn’t just about the look of it, but very much about taking the spec requirements and ironing out design concepts, usability, workflows, and impact on existing functionality – essentially vetting it and hammering out any show-stopping kinks before it goes into the dev cycle. (Also, if the spec needs to go back to the drawing board, it’s sent back to the Spec list.)
• Ready
  • We have spec that’s been reviewed by the idea creator and by the design team. We optionally have a wireframe or other needed artifacts. This is ready to be moved to the Next Up column on Current Development (after it’s reviewed at the Product Planning meeting).

On every other board cards move almost exclusively only from left to right but not on the Planning board. It’s not uncommon for a card to go from Design or Ready back to Spec one or more times before it’s finally moved to Current Development.

Tablica

https://github.com/users/tom-sapletta-com/projects/1?add_cards_query=is%3Aopen

• Tablica zadania do wykonania na dzisiaj
• Zadania na [data]
• Zadania zależne od wyniku zdarzenia [task]

Our admin and management board is fairly straightforward. Each team member has three lists. We can assign cards to ourselves or to each other as well as converse about issues involved in any of those tasks.

To do list – Cards are placed here to assign new tasks

Doing –  The tasks that the person is currently working on.

Done list – Completed tasks, archived at the end of each month.

Our content marketing board has three types of lists:

Content Ideas – This is just where we store all of our content ideas and a place we can look through if we want to start on a new post.

Upcoming posts for the month – These are ideas for posts that we want to move forward with on the month.

Content published for the month –  This includes both on and off site content

Guest ideas for the podcast – A bucket for potential guests where we log some brief notes on why we think they would be a good person to reach out to.

Trello has recently added an editorial calendar feature that is popular tool for content management and planning with top news sites like Mashable, ReadWrite, and the Changlog. They use this calendar internally as well to plan out and create content for their blog. They use colored labels to represent idea topics and have 9 lists to track the status of the article and allowing different team members to contribute when they are needed. You can check out a detailed post on this process here.

Article Ideas
Researching
On hold
Writing
Editing and graphics
Scheduled
Promotion
Ready to publish
Published

We have a workflow to track and communicate with our guest writers. When working with a diverse team of guest writers, it helps to have an overview of what each writer is working on and where they are in the process. Instead of being focused on time frame like our content planning board it is optimized to make communicating with out guest writers easy and centralized.

Ideas up for grabs – Any of our guest writers can pick up these ideas. We try and keep this list populated with a few different themes. Most of the ideas in this list a more generalized ideas and themes, which gives the guest writer a little bit of space to add their own expertise or creativity, which typically makes for better content.
Articles in progress – We assign a card to a specific writer and communicate with them on the card as they progress. Our writers use google docs so it is easy to attach and link their articles right in the card giving us quick access.
Completed articles – Once the articles are approved and uploaded to wordpress we place them in this list.
Resources – This is a static list with links to our processes and procedures relevant to the guest writers. I also keep a checklist here for when the guest post is ready to be uploaded into WordPress I copy this card and assign it to them so they can have the expectations for what a completed post will look like for us, and save a lot of back and fourth.

Task Automation

We use Zapier to create automatic reminders for recurring tasks.

We have a library of processes in Google Drive that give granular instructions on completing the required task. Each card that we create in Zapier is automatically linked to a Google Doc that has precise instructions on how to carry that task out.

We use this to create recurring tasks for our admin team:

Checking email inboxes for spam
Daily bookkeeping
Checking for overtime and processing payroll
Checking PayPal balances and making transfers if necessary
Paying affiliates monthly
Drafting our performance updates to staff

Using zaps to automate card creation keeps us on track for these processes and frees up time and energy to focus on higher level tasks and projects.

Related article: Our exact hands off process for hiring developers offshore

Dan used Trello to collect and categorize his ideas for The 7 Day Startup. He would add ideas that he wanted to include into the book as cards then create lists for themes or chapters in the book.

As the lists continued to grow he used it as an outline for creating his book. Since he already had a lot of the content written as blog posts before, this Trello board helped him map it out and get through the actual writing of the book quickly.

Dans first business book | Trello 2015-01-19 11-03-22

Once all the ideas were categorized, Dan pulled them into a list of chapters to write in a new board. In that board he had lists for each step of the process (i.e. write rough draft, self-review, peer review, send to editor). This made it a more motivating way of working on the book so he could see each chapter progress as he completed the book.

Product Development

Trello and User Voice use Trello to track bugs and new feature development.

Trello

Trello likes to keep things simple and only maintain one internal board, so there is only one place to keep track of things.

Incoming Bugs – The collect bug reports from twitter, email or something that employees identify.

Bugs for this week – The top priority bugs move to this list to be fixed as quickly as possible.

Planning – This list is for new features that need addition planning, research or general figuring out how it will work.

Doing – Bugs or features devs are currently working on.

Waiting for test/review – Features and bugs awaiting code testing and QA.

Ready for merge – These are moved to a staging server and tested to see if it works well live or causes problems elsewhere in the app.

Unshippable – If a new bug is discovered that makes the card unfit for release.

User Voice

User Voice has a series of boards that all feed into a single board labeled current development.

Cards are created on four boards:

Product roadmap – Major projects for each quarter.
Inbox – Tickets from helpdesk or feedback forums.
Engineering – Ideas of currently existing areas that could be improved.
Bugs – Bugs are collected, vetted, and determined in they are critical here.

Public Trello Boards

The team at Trello use a public board to interact with customers, give a high level view of what they are working on, and allow for voting and commenting on new features.

Similar to our content marketing board, they list the new features and updates that go live each month and keep a history of each month.

https://wpcurve.com/trello-for-project-management/

https://trello.com/teams/wedding-planning

franczyza

przyklady

http://www.bubblewaffle.com/pl_franchise.html

struktura

System of Company

• Investment Group
• Construction Companies
• Subcontractors / Craftsmen

Rozszerzenia

Hardware

https://www.amazon.de/Desktop-Celeron-Prozessor-Quad-Core-Mini-Computer/dp/B07QS4B7WH

Software

Obecny model często nie jest ustandaryzowany

każda firma wma własną strukturę, standardy, politykę, kulturę

Programiści nawet jak nie mają dużej swobody, to nie mają dużej wiedzy o zarządzaniu projektami więc są wrzuceni w machinę, w której albo nie odgrywają większej roli, albo nie odnajdują sie w niej.

Standaryzacja poprzez zastosowanie modelu ułatwia wykorzystanie zasobów już teraz na każdym poziomie:

• Hardware
• Software
• Wetware

Co istotne nie potrzeba inwestycji, tylko zmiany podejścia do realizacji projektów i co ważne, nie trzeba od razu tego zmienić, tylko stopniowo, tam gdzie jest to łatwiejsze pozowlić sobie na prototypowanie i na s topniowe uwalnianie potencjału ludzkiego, dla tych, którzy preferują taki sposób, oraz na początku zachęcenie tych, którzy będą ewangelizatorami w firmie do uczestnictwa za drobną opłatą, określić ich obowiązki.

1. szkolenie
2. feedback do ODR

sprzedaz

klienci