AAble · průvodce
⚖ Náš přístup

Proč to děláme takhle.

Šest rozhodnutí, podle kterých stavíme všechno v Able. Pochop je jednou a budou ti dávat smysl volby, které uvidíš kolem sebe.

Tyhle principy nejsou marketingové fráze — jsou kodifikované jako anti-hype invarianty v repozitáři (9 pravidel v .able/ecosystem-rules.yaml) a každý návrh nové komponenty se proti nim kontroluje. Když pravidlo porušíme, musí to být vědomé rozhodnutí s důvodem — sepsaným.

⌬ Šest zásad

Co děláme jinak.

1

Jedna identita, jedna paměť, jedna infra

Místo šesti systémů, které spolu nemluví, máme jeden ekosystém. Jeden login, jedna firemní paměť, jedna platforma. Méně komplexity = méně chyb = méně tření v denní práci.

2

Bez hype-driven architecture

Nepřidáváme nástroj jen proto, že je modní. Před každým novým bodem se ptáme: máme reálný problém, který tohle řeší? Pokud ne, nebereme. Postgres + Slack + Keycloak řeší 90 % věcí.

3

Co firma ví, neztrácí

Rozhodnutí se neztrácí v Slack vláknech. Nová znalost se zapíše a najde. Když někdo odejde, kontext zůstane. Firma má paměť delší než lidé v ní.

4

Decisions se nepřepisují

Když změníme názor, předchozí rozhodnutí nemažeme — vznikne nové, které ho navazuje. Vidíš celý řetězec myšlení. Audit zadarmo, žádné „kdo to změnil a proč".

5

Open-source, žádný vendor lock-in

Vše, co tu používáme, máme my pod kontrolou. Postgres, Keycloak, Vaultwarden, Grafana — standardy, které vyměníme, kdyby bylo třeba. Žádné „přivázání na 5 let".

6

AI-native, ale s rozumem

AI je v Able partner, ne sólová hračka. Funguje proto, že má kontext — firemní paměť, rozhodnutí, projekty. Bez kontextu halucinuje. S ním odpovídá přesně.

🛑 Anti-hype filtr

Než přidáme cokoliv nového.

Máme jednoduché pravidlo: přidáme nový nástroj jen tehdy, když máme reálný problém, který řeší. Ne proto, že je cool. Když odpověď na všechny otázky níže je „ano", jdeme. Jinak počkáme.

  • ?
    Máme reálný problém?Ne hypotetický. Stalo se to, koho to bolelo.
  • ?
    Existuje OSS řešení?Před placeným SaaSem se vždy ptáme.
  • ?
    Stačí Postgres / Slack / Keycloak?Většinou ano. Méně komplexity, víc spolehlivosti.
  • ?
    Není to druhá DB / druhý IdP / druhý task tracker?Jeden už máme. Druhý nepotřebujeme.
🚦 Jak se u nás reálně pracuje

„Funguje mi to lokálně" není hotovo.

Nejsilnější pravidlo, které máme, není o technologii — je o poctivosti. Žádná změna není „hotová", dokud není doložené, že běží v produkci. Ne „nasadil jsem to a mělo by to jet". Doložené: otevřel jsem to, projel logy, nic nehoří.

  • 1
    Lokálněrozběhat u sebe, projet testy
  • 2
    Zabalitimage s konkrétní verzí — nikdy „nejnovější"
  • 3
    Nasaditpřes manifest v gitu, ne ručním sáhnutím do serveru
  • 4
    Ověřit živěotevřít, projet logy — nula chyb, ne „mělo by to jet"
  • 5
    Zapsatco a proč — aby to za měsíc dávalo smysl

Vypadá to jako byrokracie. Není. Každý krok, který jsme někdy přeskočili, se vrátil — jako „vždyť to tam je" nad něčím, co tam roky nebylo, nebo jako výpadek, o kterém jsme se dozvěděli od klienta.

Proto taky dokumentace nesmí lhát. Když někde píšeme „nasazeno", je to nasazené. Když něco nemáme — třeba zálohy databází — napíšeme, že to nemáme, i když to vypadá blbě. Dokumentace, které se nedá věřit, je horší než žádná, protože podle ní někdo něco slíbí klientovi.

„Cíl není mít nejvíc nástrojů. Cíl je mít co nejméně nástrojů, které dělají všechno co potřebujeme. Méně přepínání, méně bordelu, víc soustředění."