A korai stádiumú induló vállalkozásokban ugyanazt a mintát látom: a mérnökök mestereket állítanak fel és fejlesztik az ágaikat, a formális kibocsátási ciklusokat és a színpadi környezeteket. Ez a sorozatom harmadik cikke a mentális modellekről az induló vállalkozások számára (kérjük, ellenőrizze, sok érdekes anyag van). Ez általában akkor történik, amikor a termék csak most kezdődik. A mérnöki gyakorlatok szokásból származnak, nem szükségszerűségből, és általában a nagyobb vállalatok korábbi munkahelyeiből származnak, ahol a termelési meghibásodások drágák voltak, és a nehéz folyamat volt a helyes válasz. The real challenge not stability, it is finding revenue and users De egy indulóban, ha ezeket a folyamatokat túl korán bevezeti, a fókusz elvonja a tanulástól és a szertartás felé. Ez az összeférhetetlenség között, hogy mi az üzleti ténylegesen szüksége, és hogyan a csapat kiadja a kódot, ahol az alábbi mentális modellek jönnek. mindegyik kínál egy másik módja annak, hogy gondolkodni a kiadás döntéseket, valamint gyakorlati tanácsot, hogy mi valójában működik, ha előzetes bevételt, és még mindig keres a megfelelő. Ez olyan alapítóknak és mérnököknek szól, akik úgy érzik, hogy a folyamatuk lelassítja őket, de nem biztosak abban, hogy miért. Who is this for? A mentális modell 1 vagy a felszabadulásod folyamata a félelem vetítése A kiadási folyamat nem semleges infrastruktúra, de tükrözi azt, amit a csapat leginkább fél megtörni. (regressziók, megszakítások, elveszett bizalom) erődítményeket építesz: színpadi környezetek, jóváhagyási kapuk, hosszú felülvizsgálatok, felszabadító vonatok. If the deepest fear is breaking production (időpocsékolás funkciókra senki sem akarja, hiányzik a termék-piaci illeszkedés) érzékelőket építesz: gyors telepítések, gyors visszajelzések, állandó kísérletezés. If the deepest fear is building the wrong thing A legtöbb csapat soha nem hozza meg ezt a döntést tudatosan. Ők öröklik a munkafolyamatokat a múltbeli munkahelyekből, másolják a „legjobb gyakorlatokat” a Big Tech blogokból, vagy alapértelmezés szerint bármi, ami professzionálisnak tűnik. Az eredmény egy olyan folyamat, amelyet valaki más valósága alakít ki, és szinte mindig egy érett vállalat valósága az ügyfelek fizetésével, a megfelelési igényekkel és a leállás súlyos következményeivel. Minden szoftvercég két félelemmel él, amelyek soha nem tűnnek el teljesen: 
 
 
 Végrehajtási kockázat: szállítási hibák, megszakítás, ami működik, károsítja a termelést. Felfedezési kockázat: Rossz dolgot építeni, nem illeszkedni, kilépni a pályáról. Ezek a félelmek ellentétes irányba húzódnak, és a felszabadítási folyamat az a mechanizmus, amely közülük választhat. Nehéz folyamatok, mint a bejárati kapuk, jóváhagyások és felszabadítási vonatok biztosítják a végrehajtás kockázatát. Könnyű folyamatok, mint a törzsalapú fejlesztés, a folyamatos telepítés és a funkció zászlók biztosítják a felfedezés kockázatát. A kompromisszum valóságos, de nem szimmetrikus.A gyártási hiba egy olyan probléma, amelyet egy órán belül meg lehet oldani.Hat hónapig rossz terméket építeni olyan probléma, amelyből nem lehet felépülni. A megfelelő választás szinte mindig a vállalat szakaszát követi: 
 
 
 Előzetes bevétel, előzetes PMF: Még mindig bizonyítja a fő hipotézist, így szinte senki a csapaton kívül nem használja a terméket. A ház alig létezik még - a tűz elleni biztosítás korai. Félelem a jelentéktelenségtől, nem az instabilitástól. Hajózz gyakran, tanulj gyorsabban, mint a versenytársak. A hibák kínosak, de túlélhetőek. Építs valamit, amit senki sem akar, halálos kimenetelű. Post-PMF, bevétellel: A valódi ügyfelek ragaszkodnak hozzád, így a leállási idő azt jelenti, hogy elveszett bevételek, csúszás, hírnév károsodása. Most a végrehajtás kockázata létezővé válik. Itt az ideje, hogy fektessen be a stabilitásba: kapuk, tesztelések, visszafordulások, megfigyelhetőség. A félelemnek ugyanúgy kell fejlődnie, mint az üzletnek.Az egyik szakaszban tökéletes folyamat a másikban aktívan káros lesz. 
 
 
 Mielőtt megvitatná a fióktelepet, a csővezetéket, vagy felülvizsgálná a szabályokat, szünetet tartson, és válaszoljon három kérdésre: 
 
 
 
 What am I actually most afraid of right now: breaking something that works, or building something that doesn't matter? Do I have paying customers who depend on reliability, or am I still searching for the first ones? Is this process shaped by my current reality, or am I carrying forward someone else's old fears? Mielőtt megvitatná a fióktelepet, a csővezetéket, vagy felülvizsgálná a szabályokat, szünetet tartson, és válaszoljon három kérdésre: 
 
 
 
 Mitől félek most a legjobban: megtörni valamit, ami működik, vagy építeni valamit, ami nem számít? Van olyan fizetős ügyfelem, aki a megbízhatóságra támaszkodik, vagy még mindig az elsőket keresem? Ezt a folyamatot a jelenlegi valóságom formálja, vagy mások régi félelmeit hordozom? Mentális modell 2 – kölcsönzött érettség Az érett vállalatokból származó kibocsátási struktúrák importálása a haladás illúzióját hozza létre, miközben csendben csökkenti a tanulási sebességet. Amikor a termék-piaci illeszkedés bizonytalan, és a következő pivot holnap lehet, egy ismerős munkafolyamat úgy érzi, mint egy szilárd talaj. Process is comfort. Conway törvénye szerint a szoftverarchitektúra tükrözi a szervezeti struktúrát.Egy következtetésnek kell lennie: a kiadás folyamata tükrözi az üzleti bizonyosságot. A company that knows what it's building releases differently than one still figuring it out. Én láttam ezt a mintát első kézből. Egy jövedelem előtti indulás nulla fizetős felhasználóval, ahol a termék még mindig hipotézis volt. Ahelyett, hogy teszteltem volna ezt a hipotéziset, az első hónap a "megfelelő" infrastruktúrába ment: a fejlesztés és a fő ágak, a különálló színpadi és prod környezetek, a CI / CD csővezetékek, a Jira és a Jira sablonok. Professzionálisnak tűnt, de két környezetünk volt a szoftverek számára, amelyeket a csapaton kívüli emberek nem érintettek. Szabadítási folyamatok: Valóságellenőrzés 
 
 
 
 
 
 
 
 
 
 
 
 Process 
 How It Works 
 Startup Fit (pre-PMF) 
 Why 
 
 
 
 
 
 GitFlow 
 Work happens on a separate develop branch while main stays stable. Features and fixes are merged in batches, with dedicated release and hotfix branches used to control when changes reach production. 
 Poor ❌ 
 Batching delays feedback and hides problems. 
 
 
 
 
 
 GitHub Flow 
 New work is done on short-lived feature branches. Each change goes through a pull request, is reviewed, merged into main, and then deployed continuously. 
 Good ✅ 
 Reviews add latency to learning. 
 
 
 
 
 
 Trunk Based 
 Developers commit small changes directly to main or merge very short-lived branches. Unfinished features are hidden with flags and deployments happen frequently. 
 Good ✅ 
 Fast feedback, break it all faster. 
 
 
 
 
 
 Release Trains 
 Releases happen on a fixed schedule. Features that are ready ship with the next train, while unfinished work waits for the following one. 
 Poor ❌ 
 Calendars slow discovery. GitFlow A munka egy külön fejlesztési ágban történik, miközben a főbb változások stabilak maradnak.A funkciók és javítások tételekben egyesülnek, a dedikált kiadásokat és a gyorsjavításokat a változások termelés elérésének ellenőrzésére használják. Szegény 🙂 A párosítás késlelteti a visszajelzést és elrejti a problémákat. GitHub Flow Új munkát végeznek a rövid élettartamú funkciók ágain. Minden változás egy húzási kérésen megy keresztül, felülvizsgálják, a főbe egyesítik, majd folyamatosan telepítik. Szép 🙂 A visszajelzések hozzáadják a tanulási késleltetést. Trunk Based A fejlesztők kis változtatásokat hajtanak végre közvetlenül a fő ágakra, vagy összeolvadnak a nagyon rövid életű ágakkal. Szép 🙂 Gyors visszajelzés, minden gyorsabban megtörik. Release Trains Olyan funkciók, amelyek készen állnak a következő vonattal, míg a befejezetlen munkák a következőre várnak. Szegény 🙂 Lassú felfedezés ütemterve. Az induló vállalatok és az érett vállalatok különböző világokban élnek - és minden világnak megvan a saját túlélési szabálya. A nagy csapatok, a párhuzamos munkafolyamatok, a magas termelési költségek miatt a GitFlow és hasonló folyamatok ésszerű választássá válnak, minimalizálva a pokol és a káosz összefonódását. Mature companies optimize for coordination risk. Az uralkodó kockázat nem a termelés megszakítása (szinte nincs felhasználója). A gyorsaság mindent meghatároz. Startups need to optimize for learning latency. feedback A GitFlow másolása (vagy bármilyen nehéz folyamat) a felfedezéstől a szertartásig áthelyezi. A versenytársa egy zavaros Git-történettel a múlt héten három kísérletet küldött. még mindig várja a kiadás ága stabilizálódását. 
 
 
 
 
 
 A kölcsönzött érettség hamis biztonságérzetet teremt. A hosszú ciklusok drágákká teszik a pivotokat A nagyméretű funkcióágak későn elrejtik az integrációs problémákat A felülvizsgálat során a felhasználók jobban használják fel a kognitív energiát A folyamat kívülről komolynak tűnik. belül, késlelteti a tanulást, amely meghatározza, hogy a vállalat él-e vagy hal meg. A kölcsönzött érettség a . false sense of safety A hosszú ciklusok drágákká teszik a pivotokat A nagyméretű funkcióágak későn elrejtik az integrációs problémákat A felülvizsgálat során a felhasználók jobban használják fel a kognitív energiát A folyamat kívülről komolynak tűnik. belül, késlelteti a tanulást, amely meghatározza, hogy a vállalat él-e vagy hal meg. gyakorlati   Egy védett Rövid élettartamú funkciókkal rendelkező ágak, amelyek órákat vagy napokat tartanak, nem heteket. A termelés nem nincs kiadási ág, nincs hotfix ág. Ha három mérnöknek szüksége van egy ága-stratégiai diagramra, valami már rossz. 1. GitHub Flow is enough. main main develop   A funkcionális zászlókkal és a szilárd megfigyelhetőséggel a produkció az egyetlen környezet, amely igazat mond, és a színpadi környezetek drága hazugságok, amelyeket biztonságban érezhet. 2. Test in production.   Lehetővé teszik, hogy elkülönítse a szállítást a kiadástól, ami azt jelenti, hogy naponta telepítheti a kódot, és átkapcsolhatja a funkciókat, amikor készen állnak.A zászlók lehetővé teszik, hogy láthatatlanul küldjön hiányos munkát, A / B tesztelést valós felhasználókkal, fizetett szegmenseket a kísérleti funkciókkal szemben, és azonnal megöli a kudarcokat. 3. Feature flags are non-negotiable. Az olyan eszközök, mint a Vercel, a Netlify, a Render és a Railway, egyedi előnézeti URL-eket generálnak minden egyes PR-hez, így az érdekeltek azonnal látják a valódi változásokat, anélkül, hogy megosztott színpadi környezetet kellene fenntartaniuk, és anélkül, hogy „munkát végeznének a gépen”. 4. Preview deployments for every change. Ebben a szakaszban az egységes tesztelési lefedettség túlértékelt, mert nem kell 80% -os lefedettség, gyors fogásokra van szükség. Eszközök, mint a GitHub Copilot, a Cursor vagy a dedikált PR felülvizsgálati botok azonnal nyilvánvaló problémákat jelentenek, ami gyorsabb és olcsóbb, mint a csapattársak blokkolása. 5. AI-assisted code reviews over waiting for humans. Használja a Sentry-t a hibákra és a PostHog vagy a Mixpanel-t a felhasználói viselkedésre, és minden közvetlenül figyelmezteti a Slack-t, így másodpercek alatt tudhatja, amikor valami megszakad, nem pedig amikor egy frusztrált felhasználó e-maileket küld. 6. Observability over exhaustive testing. Útjelző hibajelentések, telepítési értesítések, elemzési események és in-app visszajelzések dedikált csatornákhoz, és adjon hozzá egy egyszerű visszajelzési widgetet a termékhez, hogy a felhasználók váljanak a valós idejű QA csapat. 7. Slack as mission control. **8. Optimalizáljuk a gyors helyreállításhoz, nem a tökéletes megelőzéshez.** Az 5 perces visszalépés legyőzi a 2 napos QA ciklust, így gyakran hajózzon, figyelje meg szorosan, és azonnal forduljon vissza, ha valami megszakad. alsó vonal A kiadás folyamata egy fogadás arra, hogy mi öl meg először.Mielőtt a termékpiac illeszkedik, a veszély a rossz dolog felépítése, miközben a futópálya összehúzódik. 
 
 
 
 A folyamat tükrözi a félelmet. Tudja meg, hogy melyik félelem illeszkedik a színpadhoz. A kölcsönzött érettség drága. hogy a GitFlow telepítése értelme volt az utolsó cégnél. Valószínűleg most nem. Optimalizáld, hogy milyen gyorsan tudod megváltoztatni az irányt, nem pedig, hogy milyen szilárd az alapítvány. Gyorsabb a hajózás, gyorsabb a tanulás

The writer was physically present in relevant location(s) to this story. The location is also a prevalent aspect of this story be it news or otherwise.

Read My Stories

Ez a hanganyag a történet eredeti nyelvén készült!

A felszabadulási folyamatod a félelem projekciója

About Author

HOZZÁSZÓLÁSOK

HANG TAGOK

EZT A CIKKET BEMUTATTA

Related Stories

Hubble Protocol, a DeFi project on Solana Raises $10 Million Led By Crypto.com Capital, DCG and CMS

Of The First and Last Things: Part 1

THE LAST DAY OF NEW YORK

On OpenAI Failed Board Coup of Sam Altman & the Danger of Leaving AI Fate in the Hands of a Few

Hubble Protocol, a DeFi project on Solana Raises $10 Million Led By Crypto.com Capital, DCG and CMS

Of The First and Last Things: Part 1

THE LAST DAY OF NEW YORK

On OpenAI Failed Board Coup of Sam Altman & the Danger of Leaving AI Fate in the Hands of a Few

Light-Mode

Classic

Newspaper

Minty

Dark-Mode

Neon Noir

Minty

HN StartUps