Belokamentsevs shorts

Nylig, ganske ved et uhell, etter forslag fra en god person, ble en idé født - å legge ved et kort sammendrag til hver artikkel. Ikke et abstrakt, ikke et lokkemiddel, men et sammendrag. Slik at du ikke kan lese artikkelen i det hele tatt.

Jeg prøvde det og likte det veldig godt. Men det spiller ingen rolle - det viktigste er at leserne likte det. De som for lenge siden hadde sluttet å lese begynte å komme tilbake og stemplet meg som grafoman. Og en annen god person rådet meg til å skrive et sammendrag for hver gammel artikkel. Jeg takket ja, og nå, tilfeldig, skriver jeg disse novellene. Kalt dem shorts.

Jeg gjør deg oppmerksom på flere slike shorts, basert på flere publikasjoner. Kanskje finner du noe nyttig for deg selv.

Katten døde, halen gikk av

Møter går veldig ofte uten resultater. De kom sammen, pratet og gikk hver til sitt.
Resultatene eller produktene fra møtet er beslutninger. Det er derfor de vanligvis ikke eksisterer. Og hvis det er det, er det ikke alltid av god kvalitet.
Hvis møtet er tidsbegrenset og det må tas en beslutning, så er det (vedtaket) av dårlig kvalitet.
Dersom møtet ikke er tidsbegrenset og varer til vedtak er fattet, så fattes ethvert vedtak så lenge møtet avsluttes.
Hvis en avgjørelse blir tenkt på et møte, så blir den akseptert – rett og slett fordi hjernen setter pris på det den kom frem til.
Forståelse for den dårlige kvaliteten på løsningen vil komme senere, men det vil være for sent.
For å ta en effektiv beslutning er det bedre å ikke delta i diskusjonen, men å observere stille.
For det første vil ikke hjernen være opptatt med å komme med svar.
For det andre er det ikke noe press for å ta en beslutning.
Etter at møtet er over, kan du rolig tenke på det og ta en avgjørelse. Det vil være av høyere kvalitet.
Nøkkelen er å være stille og lytte under møtet. For at andre ikke skal bekymre seg, si at dette er en bevisst posisjon.

habr.com/en/post/341654

Latente parasitter

I bunn og grunn er det to tilnærminger til å sette mål og overvåke gjennomføringen: parasittisk og symbiotisk.
Den symbiotiske tilnærmingen er å sikre at problemet løses.
Den parasittiske tilnærmingen er å sørge for at problemet IKKE er løst.
Den symbiotiske tilnærmingen er grei og grei, men vanskelig å implementere. Derfor er det sjelden.
Oppgaven er satt på en slik måte at alt er klart – mål, ressurser og begrensninger.
Kontroll utføres slik at problemet er nøyaktig løst.
Den symbiotiske tilnærmingen er å overlate en del av ansvaret (i tillegg) for å løse problemet på regissøren.
Den parasittiske tilnærmingen er utsmykket og smart, men enkel å implementere. Derfor forekommer det ofte.
Oppgaven er stilt på en slik måte at ingenting er klart. Jo mindre tydelig jo bedre.
Det er tilrådelig å ikke utøve kontroll i det hele tatt.
Det er ikke noe ansvar på oppgavelederen; hele "apen" blir transplantert på utøverens nakke.
Hensikten med den parasittiske tilnærmingen: manipulasjon, følelsesmessig nød, selvbekreftelse. Derfor finnes det ofte i arbeidet til mentorer med nybegynnere.
Bedre, selvfølgelig, er en symbiotisk tilnærming.

habr.com/en/post/343696

Dimensjoner vs illusjoner

Hvis du evaluerer prosessen og resultatene av aktivitetene dine uten målinger, vil du alltid gjøre feil.
Vurdering uten tall avhenger av humøret ditt. Dårlig humør - det vil se ut til at du ikke fungerer bra. Godt humør er det motsatte.
På denne måten kan du sitte og jobbe dårlig i en uke, og på fredag ​​kan du produsere utmerkede resultater, og det vil se ut til at hele uken gikk bra.
I bunn og grunn er det to typer beregninger: kvantitativ og alternativ (bedre kjent for programmerere som boolsk).
"Oppgave fullført i tide" er en boolsk. Dette er det samme som "Delen er god" (et alternativt kvalitetstegn når de ikke kan måles i tall).
"Vi jobber bra", "Vi oppfyller planen", "Jeg er flott" - også boolsk.
Det er vanskelig å konstruere en kontrollprosess ved å bruke boolske anslag. Det anbefales å gå over til kvantitative beregninger så raskt som mulig.
Boolsk genererer byråkrati og formalisme. For eksempel kan det å fullføre oppgaver i tide oppnås ved å øke tidsfrister, finne på oppgaver for deg selv og implementere IBD.
For å administrere basert på boolske indikatorer må du bruke mye tid – på møter, analyser osv. For det er for lite informasjon.
Det anbefales å måle både prosess og resultat. Da blir bildet mest komplett.
For programmerere anbefales "Planning Poker"-metoden fra Scrum.

habr.com/en/post/343910

Dette er Sparta

La oss si at du er en programmerer og at du får en seriøs oppgave. Og du tror at det ikke er nødvendig å løse problemet - det er dumt, skadelig.
Typisk oppførsel i en slik situasjon: vis oppgaven i et offentlig felt. Send det til godkjenning hos sjefen, start et internt prosjekt, registrer det i systemet osv.
Det er her alt bryter sammen. Personen som kom med oppgaven ønsker ikke å bli ansett som en tosk. Og når de først har kommet inn på det offentlige feltet, vil de forsvare seg.
Det er viktig for en person å ikke miste ansikt, i politisk forstand. Hovedsaken i politikk er å aldri innrømme feilene dine. Du trenger ikke å gjøre noe, men det viktigste er å ikke ha noen innrømmede feil.
En person vil gjøre sitt beste for å bevise at programmereren er en skurk, en idiot, en motstander av endring. Og programmereren må fortsatt løse problemet.
I noen tilfeller vil en person ordne alt slik at programmereren ikke løser problemet i det hele tatt. Da vil personen være "hvit", og programmereren vil være absolutt "svart" (han motsto og mislyktes til slutt).
Det finnes flere løsninger.
Den første er å bli en forretningsprogrammerer, forstå relaterte områder og bestemme selv hva og hvordan du skal automatisere der.
Den andre er artikkelen Chief of Change. For eksempel utviklingsdirektør.
For det tredje, ikke møt opp og bare gjør det du får beskjed om.
Fjerde - The Way of Sparta, rask avvisning av beslutninger. Bedre kjent som fail fast, fail cheap.
Hovedsaken er ikke å involvere publisitet. Fortell personen - la oss ikke kaste bort mye tid, la oss lage en prototype og se om løsningen er levedyktig eller ikke.
Prototypen vil ta litt tid. Hvis de lykkes, vil begge få sitt - en normal avgjørelse og politiske poeng.
Hvis det mislykkes, vil ingen komme til skade. Vel, folk vil behandle programmereren bedre.

habr.com/en/post/344650

Surrogater

Business liker ikke 1C og dets produkter, webutviklere, QMS, regnskap, økonomer, utviklingsprosjekter, Scrum, TOS, controlling, KPI og motivasjonssystemer.
Bedrifter elsker økt lønnsomhet på grunn av automatisering, økt omsetning fra online markedsføring, forbedret produktkvalitet, et enkelt og forståelig bilde av virksomheten i tall, prognoser for selskapets tilstand, en reell økning i effektivitet, raskere prosjektgjennomføring med 2-4 ganger, en multippel økning i fortjeneste og en nedgang i varelager , et nøyaktig styringssystem, et klart og forståelig system for å vurdere tingenes tilstand i virksomheten, et arbeidsvurderingssystem som lar deg sparke halvparten av lederne.
Bedrifter elsker å nå forretningsmål. Næringslivet liker ikke surrogater.
En surrogat er når du har bedt om å oppnå et forretningsmål, men har mottatt et automatiseringsprosjekt, en nettside, en bunke papir, en stab av uforståelige ansatte eller uleselige foot wraps-rapporter.
En surrogat er når målet langs veien erstattes av et middel til å oppnå. Og alle glemte målet.
Produksjonen av surrogater er basert på tre pilarer: formalisme, gradualisme og gjensidig ansvar.
Formalisme er overføring av mål til papir med dekomponering. Men i hovedsak - å overføre fokus for oppmerksomhet fra det store målet til små detaljer. Ingen husker målet lenger - alle diskuterer detaljene.
Gradualisme er en lav overgangshastighet fra mål til midler. I begynnelsen diskuteres målet fortsatt noen ganger. Men gradvis, steg for steg, nevnes det mindre og mindre. Helt til kunden selv glemmer det, drukner i detaljene.
Gjensidig ansvar er at alle entreprenører opptrer tilnærmet likt. Det er ikke et eneste automatiseringsverktøy som faktisk øker fortjenesten. Derfor har ikke kunden egentlig noe valg.
Hva å gjøre?
Unngå surrogater og det første skrittet mot deres opprettelse: formalisme. I hvert fall på interne prosjekter. Sett deg et mål og snakk med utøveren om det hele tiden. Om skala, ressurser, planer osv. - Samme. Men det viktigste handler om målet.
Ellers vil oppmerksomhetsfokuset helt sikkert skifte, og du vil få et annet surrogat.

habr.com/en/post/344844

Jab Klitschko

Det er en slik bokser - Vladimir Klitschko. Han har en særegenhet - den konstante bruken av jabben. Vel, altså. mer konsekvent enn andre boksere.
Jabben holder motstanderen konstant i spenning og sliter ut ham.
Nøkkeltrekk ved Klitschko-jabben: enkel utførelse (relativ, selvfølgelig) og konsistens.
Mange forfattere sier at konstant utførte, nyttige, men enkle handlinger kan gi mange fordeler.
Jeg bestemte meg for å prøve det også. Jeg laget et enkelt regnskapssystem - hvilke jabs jeg gjorde i dag.
Det skjedde på fabrikken. Jeg gjorde jabs til lunsj (jeg har ikke lunsj), dvs. 1 time om dagen. Gjorde det andre ikke gjør (de sier det fører til suksess).
Jeg satte opp tester av et selvlærende system, kom med ideer til utvikling, implementerte andres ideer til utvikling, satte opp autooppgaver, refaktorerte og optimaliserte koden.
Hver dag - enhver oppgave fra denne listen. Fullført en oppgave - kjekk. Flere er mulige.
Observasjoner ble utført i 3 måneder. I løpet av denne tiden gjorde jeg 30 kontroller, kom med 200 ideer, implementerte 80 andres ideer, bygde automatiserte prosesser for to avdelinger og gjorde tre kule optimaliseringer.
Kul. Vel, dette er "i mellom." Jeg anbefaler til alle.

habr.com/en/post/344934

Fleksibelt surrogat

Ordet "Scrum" refererer til minst to enheter: filosofi og rammeverk.
Filosofien, eller tilnærmingen til arbeid, er beskrevet i boken av Jeff Sutherland.
Rammeverk, dvs. algoritmen for handlinger er beskrevet i et dokument kalt Scrum Guide.
Filosofi ble et rammeverk fordi forfatterne av filosofien ønsket å tjene penger på det (med deres egne ord).
Rammeverket er sterkt forenklet i forhold til filosofien. Hovedsaken er at målet er forenklet, eller rettere sagt kastet ut.
Målet med filosofi: akselerere oppnåelse av resultater. Dessuten til tider. Boken inneholder eksempler på akselerasjon med 8 ganger.
Hensikten med rammeverket: slik at du har Scrum. Det står der: hvis du følger instruksjonene, har du Scrum; hvis du bryter instruksjonene, har du ikke Scrum.
Rammeverket innebærer ikke akselerasjon i å oppnå resultater i det hele tatt.
Personer som underviser eller implementerer Scrum jobber med rammeverket. De forteller og implementerer en algoritme som ikke fører til andre resultater enn "vi har nå Scrum."
Poenget er klart. Filosofi er veldig vanskelig å selge. Rammeverket er enklere.
Et rammeverk er et produkt. Han gikk som forventet gjennom "pakkingen". Det er enkelt, forståelig, det er støtte og mange spesialister. Minner deg ikke om noe?
Alt er bra, bortsett fra resultatet - det er ingen.
Hvis kunden ikke er kjent med Scrum-filosofien, vil han være ganske fornøyd med implementeringen av rammeverket.
Hvis kunden er kjent med Scrum-filosofien, vil han bli skuffet over implementeringen av rammeverket - det vil ikke være noen akselerasjon i å oppnå resultater.
Det vil være kult, fasjonabelt, moderne, men ingen forretningsmål vil bli oppnådd (bortsett fra å bruke budsjettet på "noe nytt").
Hva burde jeg gjøre? Studer Scrum-filosofien. Den er basert på den japanske filosofien om kvalitetsstyring, hvor essensen er: måling og endeløs forbedring.
Dessverre må du tenke mye, eksperimentere, observere og dessverre jobbe. Hvis dette ikke passer deg, ta rammen.

habr.com/en/post/345540

Kilde: www.habr.com

Legg til en kommentar