Nemrégiben, véletlenül, egy jó ember javaslatára született egy ötlet — minden cikkhez rövid összefoglalót csatolni. Nem annotációt, nem csalogatót, hanem valódi rövid összefoglalót. Olyat, amelyet elolvasva nem szükséges a cikket egyáltalán elolvasni.
Megpróbáltam, és borzasztóan tetszett. De ez lényegtelen — a legfontosabb, hogy a közelmúlt olvasóinak is tetszett. Kezdtek visszatérni azok, akik régóta nem olvastak, kifogásolva, hogy grafomán vagyok. Egy másik jó ember azt javasolta, hogy készítsek rövid összefoglalót minden régi cikkhez. Beleegyeztem, és most, közben, írom ezeket a rövid összefoglalókat. Ezeket „shortoknak” neveztem el.
Figyelmébe ajánlom ezekből néhány ilyen shortot, néhány publikáció alapján. Hátha hasznosat talál magának.
A macska meghalt, a farka kopasz.
A megbeszélések nagyon gyakran eredménytelenül zajlanak. Összegyűlnek, csevegnek, majd szétszélednek.
A megbeszélés eredményei vagy termékei – ezek a döntések. Nos, ezek általában nincsenek. Ha pedig vannak, akkor nem mindig jó minőségűek.
Ha a megbeszélés időben korlátozott, és döntést kell hozni, akkor az (döntés) alacsony minőségű lehet.
Ha a megbeszélés nincs időben korlátozva, és a döntés meghozatala a megbeszélés végéig tart, akkor bármilyen döntést hoznak, csak hogy véget érjen a megbeszélés.
Ha a döntést a megbeszélés során hozzák meg, akkor azt fogják elfogadni — egyszerűen azért, mert az agy értékeli azt, amit kitalált.
A gyenge minőségű döntések megértése később fog bekövetkezni, de akkor már késő lesz.
A hatékony döntés meghozatalához jobb, ha nem veszel részt a vitában, hanem csendben figyeled.
Először is, az agyad nem lesz lekötve a válaszok kitalálásával.
Másodszor, nem nyomja a szükségesség, hogy döntést hozz.
A megbeszélés után nyugodtan átgondolhatod és meghozhatod a döntést. Az sokkal magasabb minőségű lesz.
A kulcs: a megbeszélés során hallgass és figyelj. Hogy a körülötted lévők ne aggódjanak, mondd, hogy ez egy tudatos álláspont.
→
Latens paraziták
Alapvetően két megközelítés létezik a feladatok felállítására és végrehajtásuk ellenőrzésére: parazita és szimbiotikus.
A szimbiotikus megközelítés — a feladatot úgy megoldani, hogy az megoldódjon.
A parazita megközelítés — a feladatot úgy megoldani, hogy az NE oldódjon meg.
A szimbiotikus megközelítés közvetlen és egyszerű, de a megvalósítása bonyolult. Ezért viszonylag ritka.
A feladatot úgy kell megfogalmazni, hogy minden világos legyen — a célok, az erőforrások és a korlátok.
A felügyeletet úgy hajtják végre, hogy a feladat pontosan megoldódjon.
A szimbiotikus megközelítés az, hogy a feladat kiírójának a felelősség egy részét (ráadásul a nagyobbik részét) kell hagyni a feladat megoldásában.
A parazita megközelítés csavaros és ravasz, de könnyen megvalósítható. Ezért gyakran előfordul.
A feladatot úgy állítják fel, hogy semmi ne legyen világos. Minél kevesebb a megértés, annál jobb.
A felügyeletet lehetőleg egyáltalán ne gyakorolják.
A feladat kiírójának nincs felelőssége, az egész "majom" a végrehajtó nyakába kerül.
A parazita megközelítés célja: manipuláció, önértékelés, önérvényesítés. Ezért gyakran előfordul szakmai mentorok és kezdő alkalmazottak közötti munkában.
Természetesen a szimbiotikus megközelítés a jobb.
→
Mérések vs Illúziók
Ha a saját tevékenységei folyamatát és eredményeit mérések nélkül értékeli, állandóan hibázni fog.
A számok nélküli értékelés a hangulattól függ. Rossz hangulatban úgy tűnhet, hogy rosszul dolgozik. Jó hangulatban éppen ellenkezőleg.
Így hetekig ülhet és rosszul dolgozhat, de pénteken kiadhat egy "formához" illő eredményt, és úgy tűnhet, hogy az egész hét jól telt.
Alapvetően kétféle metrika létezik: mennyiségi és alternatív (ami a programozók számára ismertebb, mint logikai).
"A feladat határidőre elkészült" — ez logikai. Ugyanaz, mint az "alkatrész alkalmas" (alternatív minőségi jelző, amikor nem tudják számokban mérni).
"Jól dolgozunk", "Megvalósítjuk a tervet", "Én tip-top vagyok" — ez is logikai.
A logikai típusú értékeléseken nehéz irányítást építeni. Ajánlott a lehető leghamarabb áttérni a mennyiségi metrikákra.
A logikai rendszer bürokráciát és formalitásokat szül. Például a feladatok határidőre történő végrehajtását el lehet érni a határidők meghosszabbításával, saját feladatok kitalálásával, felesleges munkavégzéssel.
A logikai mutatók alapján való irányításhoz sok időt kell költeni — ülésekre, elemzésre és így tovább. Mert az információ túl kevés.
Ajánlott a folyamatot és az eredményt egyaránt mérni. Így a kép a legteljesebb.
A programozóknak ajánlott a Scrum "Tervezési póker" módszere.
→
Ez Spárta
Tegyük fel, hogy programozó vagy, és egy komoly feladatot hoztak neked. De te úgy érzed, hogy a feladat megoldására nincs szükség — ostoba és káros.
A tipikus viselkedés egy ilyen helyzetben: a feladatot nyilvános szférába emelni. Beszélje meg a főnökkel, indítson egy belső projektet, rögzítse a rendszerben stb.
Itt törik össze minden. Az a személy, aki a feladatot hozta, nem akarja, hogy hülyének tartsák. Mivel a nyilvánosság elé léptek, védelmi pozíciót foglal el.
Az ember számára fontos, hogy megőrizze az arcát, politikai értelemben. A politikában az a legfontosabb, hogy soha ne ismerje el a hibáit. Lehet, hogy semmit sem csinál, de a lényeg, hogy ne legyenek elismert hibái.
Az ember mindent meg fog tenni, hogy bizonyítsa, hogy a programozó egy gonosz, idióta, a változások ellenálló személy. A programozónak egyébként is meg kell oldania a feladatot.
Egyes esetekben az ember úgy alakítja a dolgokat, hogy a programozó egyáltalán ne oldja meg a feladatot. Akkor az ember "fehér", a programozó pedig teljesen "fekete" (ellenállt, és végül nem tudta megoldani).
Több megoldás van.
Az első - vállalati programozóvá válni, megérteni a kapcsolódó területeket, és saját magának meghatározni, hogy mit és hogyan kell automatizálni ott.
A második - fő változásokkal foglalkozó cikk. Például a fejlesztési igazgató.
A harmadik - ne kérdőjelezze meg, és csak azt tegye, amit mondanak.
A negyedik - a Spárta útja, gyors selejtezés. Érdekesebben ismert, mint fail fast, fail cheap (gyorsan bukj meg, olcsón bukj meg).
A legfontosabb - ne vonjuk be a nyilvánosságot. Mondja az embernek - ne pazaroljunk sok időt, készítsünk prototípust, és nézzük meg, hogy a megoldás életképes-e vagy sem.
A prototípushoz nem sok idő kell. Ha sikerül, mindkét fél megkapja a magáét - és a megoldás rendben lesz, és politikai pontokat is szerez.
Ha nem sikerül, senki sem szenved. Nos, az ember jobban fogja nézni a programozót.
→
Helyettesítők
Az üzlet nem szereti az 1C-t és termékeit, a webfejlesztőket, a KMK-t, a könyvelést, a közgazdászokat, a fejlesztési projekteket, a Scrum-ot, a TOC-t, a controllingot, a KPI-t és a motivációs rendszereket.
A vállalkozások szeretnek profitot növelni automatizálás révén, az internetes promóciók által növelni a forgalmat, javítani a termékek minőségét, egyszerű és világos képet kapni a vállalkozás pénzügyeiről, előrejelzéseket készíteni a vállalat állapotáról, valódi hatékonyságot növelni, 2-4-szer gyorsítani a projektek végrehajtását, többszörös profitnövekedést és a készletek csökkentését elérni, pontos irányítási rendszert kialakítani és egyértelmű, könnyen érthető rendszert kialakítani az üzleti helyzetek értékelésére, valamint egy munkértékelési rendszert, amely lehetővé teszi a menedzserek felének elbocsátását.
A vállalkozások szeretik elérni üzleti céljaikat. A vállalkozások nem szeretik a szürkeállományokat.
A szürkeállomány az, amikor azt kérik, hogy érjék el az üzleti célt, de egy automatizálási projektet, weboldalt, egy halom papírt, zavaros alkalmazottakat vagy olvashatatlan riportokat kapnak.
A szürkeállomány az, amikor az utazás célját egy eszköz váltja fel. A célra már senki sem emlékszik.
A szürkeállomány gyártása három pilléren nyugszik: formalizmus, fokozatosság és kölcsönös felelősségvállalás.
A formalizmus a célok papírra való átvitelét jelenti részletezésükkel. Valójában a figyelmet a nagy célról a kis részletekre tereli. A célról senki sem emlékszik — mindenki a részletekről beszél.
A fokozatosság az, amikor az átmenet a célokból az eszközökbe lassú. Eleinte a cél még néha szóba kerül. De fokozatosan, lépésről lépésre, egyre ritkábban említik. Amíg az ügyfél el nem felejti, elmerülve a részletekben.
A kölcsönös felelősségvállalás abban rejlik, hogy minden szolgáltató nagyjából hasonlóan cselekszik. Nincs egyetlen automatizáló sem, aki valóban növelné a profitot. Ezért az ügyfélnek alig van választása.
Mit tegyünk?
Kerülni kell a szürkeállományokat és az első lépést azok létrehozása felé: a formalizmust. Legalább a belső projektek esetében. Határozzák meg a célt, és állandóan beszélgessenek a végrehajtóval róla. A méretekről, forrásokról, tervekről stb. — ezekről is. De a legfontosabb: a célról.
Különben a figyelem mindenképpen el fog tolódni, és megint csak egy újabb szürkeállományt kapnak.
→
Vladimir Klicsko
Van egy bokszoló — Vladimir Klicsko. Van egy jellemzője — a folyamatos jab használata. Nos, ez a más bokszolókhoz képest fokozatosabb.
A jab folyamatosan stresszben tartja az ellenfelet, kimeríti őt.
A Klicsko jab kulcsfontosságú jellemzői: a végrehajtás egyszerűsége (relatív értelemben, természetesen) és a folyamatosság.
Sokan beszélnek arról, hogy a folyamatosan végzett, hasznos, de egyszerű tevékenységek sok előnnyel járhatnak.
Én is úgy döntöttem, hogy kipróbálom. Készítettem egy egyszerű nyilvántartási rendszert – hogy melyik jebb során végeztem el ma.
Ez egy gyárban történt. Ebéd alatt végeztem a jebbjeimet (nem ebédelek), azaz napi 1 órát. Olyan dolgokat csináltam, amit mások nem tesznek (állítólag ez sikerhez vezet).
Önfejlesztő rendszer ellenőrzéseket állítottam be, ötleteket találtam ki a fejlesztéshez, mások ötleteit valósítottam meg, automatizált feladatokat állítottam be, refaktoroztam és optimalizáltam a kódot.
Minden nap – bármely feladat ebből a listából. Végezz el egy feladatot – ügyes vagy. Lehet több is.
Három hónapon át gyűjtöttem megfigyeléseket. Ez idő alatt 30 ellenőrzést végeztem, 200 ötletet találtam ki, 80 másik ötletet valósítottam meg, két osztály automatizált folyamatait alakítottam ki, három nagyszerű optimalizálást végeztem.
Nagyszerű, mi? Ez csak a 'mellékállásban' történt. Mindenkinek ajánlom.
→
Rugalmas szubsztitútum
A 'Scrum' szó alatt legalább két entitás értendő: filozófia és keretrendszer.
A filozófia, vagy a munka megközelítése, Jeff Sutherland könyvében van leírva.
A keretrendszer, azaz a tevékenységek algoritmusát a Scrum Guide nevű dokumentumban találjuk.
A filozófia keretrendszerré alakult, mert a filozófia szerzői pénzt akartak keresni vele (saját szavaikkal).
A keretrendszer sokkal leegyszerűsödött a filozófiához képest. A fő különbség az, hogy a cél leegyszerűsítve, vagyis elhagyva lett.
A filozófia célja: az eredmények gyorsabb elérése. Méghozzá, többszörösen. A könyvben vannak példák az 8-szoros gyorsításra.
A keretrendszer célja: hogy Scrum-od legyen. Olyan van benne, hogy ha az utasítások szerint végzed el – akkor lesz Scrum-od, ha megszeged az utasítást – akkor nem lesz Scrum-od.
A keretrendszer nem feltételezi az eredmények gyorsabb elérését, egyáltalán.
Azok az emberek, akik Scrum-ot tanítanak vagy bevezetnek, a keretrendszerrel dolgoznak. Elmondják és bevezetik a gépkönyvet, ami nem vezet más eredményhez, mint hogy 'most van Scrum-unk'.
A lényeg világos. A filozófiát nagyon nehéz eladni. A keretrendszer – egyszerűbb.
A keretrendszer – ez egy termék. Ahogy kell, átment az 'csomagoláson'. Egyszerű, érthető, van támogatás és sok szakértő. Nem emlékeztet semmire?
Minden rendben van, kivéve az eredményt – az nincs.
Ha a megrendelő nem ismeri a Scrum filozófiáját, a keretrendszer bevezetése teljesen megfelelő lesz számára.
Ha az ügyfél ismeri a Scrum filozófiáját, akkor a keretrendszer bevezetése csalódást fog okozni - nem lesz gyorsabb a cél elérése.
Divatos, modern és menő lesz, de semmilyen üzleti cél nem lesz elérve (kivéve a büdzsé "újdonságra" történő felhasználását).
Mi a teendő? Meg kell tanulmányozni a Scrum filozófiáját. Ez a japán minőségirányítási filozófián alapul, amelynek lényege: mérés és végtelen fejlesztések.
Sajnos here sokat kell gondolkozni, kísérletezni, figyelni és, sajnálom, dolgozni. Ha ez nem megfelelő önnek - válassza a keretrendszert.
→
Forrás: habr.com
