MACH är ett format på arkitektur bestående av en uppsättning principer för nya, modernare och vad många anser bättre tekniker.
Förkortningen MACH står för Microservices, API-first, Cloud-native samt Headless.
MACH är ett format på arkitektur bestående av en uppsättning principer för nya, modernare och vad många anser bättre tekniker.
Förkortningen MACH står för Microservices, API-first, Cloud-native samt Headless.
Ofta bör du vara proaktiv och ibland bör du vara reaktiv. Proaktivitet medför att du förekommer händelser och du undviker att hantera händelser reaktivt i efterhand.
Försök alltid att föregå din uppdragsgivare, både vid positiva händelser och vid mindre bra situationer.
Ett generellt tips (som gäller det mesta) är att göra det smått och ofta, än omfattande och sällan.
Det är därför det är bra att göra utvärderingar ofta och inte låta det gå allt för lång tid mellan dem.
Det är också bra att inte ha för långa horisonter – för långt till nästa deadline. Ha hellre ett mindre omfattande scope, som ni i teamet utför på kortare kalendertid. För att istället iterera och/eller vidareutveckla det ni har gjort tidigare och hittills.
Kommunikation är en kritisk framgångsfaktor. Särskilt i uppdrag där en produktutveckling sker.
Kommunicera hellre för mycket (smått och ofta) än för lite (stort och sällan). Både med dina närmsta kollegor (ni i teamet) samt med er uppdragsgivare.
Prioritera, fokusera och leverera är tre stycken grundläggande saker som du behöver bemästra.
Prioritera vad ni i teamet ska göra härnäst. Ni kan inte göra allt på en gång, så prioritera genom att välja ut vad som är mest värdeskapande att ha klart till nästa gång.
Fokusera på de saker ni i teamet har valt ut att göra – er prioritering.
Genom att ni har fokuserat på det ni har prioriterat har ni störst chans att leverera det er uppdragsgivare önskar.
Er leverans blir kvalitativare och sannolikt motsvarar (eller till och med överträffar) er kunds förväntningar.
Det här uttalandet sa en kollega till mig för en tid sedan:
Programmering är inte en teknisk utmaning. Det är en mellanmänsklig utmaning.
Hen är en av branschens mest kompetenta programmerare och jag såg hen lösa många utmaningar med kod. Men varför är då programmering så svårt?
Jo, för att det är människor inblandade. Det är vår kommunikation och interaktion med varandra som är det utmanande. Oavsett om det handlar om programmering eller vad det än må handla om så är utmaningen oss människor emellan.
Här på webbplatsen www.productexecutivation.se finns en öppen och tillgänglig handbok på svenska. Det är sällsynt med litteratur inom ämnet på just svenska.
Verket kan ses som en handbok i Product Management för dig som arbetar som Product Manager, Product Owner eller i liknande funktion.
Jag vill tipsa om ett blogginlägg rörande skillnaden på att vara en projektledare och en produktledare. Projektledning kontra produktledning. Project Management versus Product Management. Ett citat från blogginlägget:
”Detta inlägg är en fortsättning på min serie inlägg om projekt och projektledarrollen. I dagens inlägg diskuterar jag vad som skiljer projekttänk från produkttänk och vad projektledaren egentligen bör ha för ansvar inom produktutvecklingen.”
Läs hela blogginlägget på https://jockeholm.wordpress.com/2008/11/23/projektledare-kontra-produktledare
Tekniken är idag långt framme och den kommer vara än längre fram imorgon. Det är inte tekniken som sätter gränser till vad som idag är möjligt att åstadkomma. Det som sätter gränsen är vår egen fantasi.