Plánování organizační struktury

Azure DevOps Services | Azure DevOps Server | Azure DevOps Server 2022

Obchodní strukturu můžete použít jako vodítko pro počet organizací, projektů a týmů, které vytvoříte v Azure DevOps. Tento komplexní průvodce plánováním vám pomůže navrhnout optimální organizační struktury, které odpovídají pracovním postupům vývoje s obchodními cíli.

Tip

Můžete použít AI k pomoci s tímto úkolem dále v tomto článku, nebo si můžete prostudovat Povolit asistenci AI s Azure DevOps MCP Serverem pro začátek.

Rámec strategického plánování

Pomocí následující architektury můžete provádět klíčová rozhodnutí o struktuře Azure DevOps na jednotlivých úrovních – organizace, projekt, tým a úložiště.

Rozhodnutí o primární struktuře

Vyřešte tyto základní otázky, které vás provedou strukturou Azure DevOps:

Organizační úroveň:

Kolik organizací potřebujete? - Zvažte oddělení bezpečnostních jednotek, dodržování předpisů a obchodních jednotek.
Jak mapovat organizace na organizační jednotky – sladění se strukturou podniku a potřebami zásad správného řízení

Úroveň projektu:

Kolik projektů potřebujete? - Vyvážení spolupráce se zabezpečením a autonomií.
Strategie mapování projektů – Umožňuje propojit projekty s obchodními funkcemi a týmovou strukturou.

Úroveň týmu a úložiště:

Návrh týmové struktury – Optimalizace pro agilní doručování a vlastnictví produktů
Organizace úložiště – Zajistí podporu pracovních procesů vývoje a nasazení.

Podpůrné úvahy

Správa přístupu: Definujte, kdo potřebuje přístup k jakým informacím a prostředkům.
Požadavky na vykazování: Plánování viditelnosti mezi týmy a správy portfolia
Standardizace procesů: Zvyšte konzistentní postupy a zároveň povolte flexibilitu týmu.
Kulturní sladění: Podpora agilního myšlení a kultury pro spolupráci.

Tip

Začněte s jednoduššími strukturami a vyvíjet se s tím, jak vaše organizace roste. Rozdělení velkého projektu je jednodušší než sloučení samostatných organizací.

Principy organizací Azure DevOps

Organizace v Azure DevOps slouží jako kontejner nejvyšší úrovně pro vaše projekty, který poskytuje hranice fakturace, zabezpečení a správy. Pomocí organizací můžete:

Centralizace fakturace a licencování napříč souvisejícími projekty a týmy
Vytvořte hranice zabezpečení s odlišnými řízeními přístupu a zásadami.
Zajištění izolace správy pro různé obchodní jednotky nebo požadavky na dodržování předpisů.
Připojte se k zprostředkovatelům identity, jako je Microsoft Entra ID pro jednotné ověřování.

Výhody organizace a bezplatná úroveň

Každá organizace zahrnuje služby úrovně Free až pro pět uživatelů:

Service	Výhody bezplatné úrovně
Kanály Azure	Jedna hostovaná úloha s 1 800 minutami za měsíc pro CI/CD plus jedna samostatně hostovaná úloha
Azure Boards	Sledování pracovních položek a panely Kanbanu pro řízení projektů
Azure Repos	Neomezená privátní úložiště Git pro správu zdrojového kódu
Azure Artifacts	Správa balíčkového systému pro závislosti a artefakty sestavení
Přístup účastníků	Neomezené zúčastněné strany pro zobrazení a základní účast na projektu

Prvních pět uživatelů zdarma (licence Basic)
Azure Pipelines:
- Jedna CI/CD hostovaná Microsoftem (jedna souběžná úloha, až 30 hodin za měsíc)
- Jedna souběžná úloha CI/CD v místním prostředí
Azure Boards: Sledování pracovních položek a tabule
Azure Repos: neomezená privátní úložiště Git
Azure Artifacts: Dva GiB zdarma na organizaci

Poznámka:

Cloudová služba zátěžového testování Azure DevOps je zastaralá, ale zátěžové testování Azure zůstává dostupné. Tato plně spravovaná služba zátěžového testování umožňuje generovat zatížení ve velkém měřítku pomocí existujících skriptů Apache JMeter. Další informace najdete v tématu Co je zátěžové testování Azure? a změny funkcí zátěžového testu v sadě Visual Studio a cloudovém zátěžového testování v Azure DevOps.

Běžné vzory organizace:

Jedna organizace: Používejte jednu organizaci pro jednotnou spolupráci.
Organizace organizačních jednotek: Pro různé požadavky na dodržování předpisů nebo zabezpečení používejte samostatné organizace.
Geografické organizace: Použijte regionální rozdělení pro rezidenci dat nebo místní správu.

Kolik organizací potřebujete?

Začněte s jednou organizací a rozšiřte pouze v případech, kdy máte specifické obchodní požadavky, které vyžadují oddělení.

Rozhodovací kritéria pro více organizací

Pokud potřebujete, vytvořte další organizace:

Oddělení zabezpečení a dodržování předpisů:

Různé zákonné požadavky, jako jsou SOX, HIPAA nebo PCI-DSS
Jedinečné požadavky na izolaci zákaznických dat
Samostatné záznamy auditu a zprávy o souladu s předpisy

Požadavky na obchodní strukturu:

Nezávislé organizační jednotky se samostatnými zásadami správného řízení IT
Různé požadavky na fakturaci a nákladové středisko
Samostatná připojení zprostředkovatelů identity, jako jsou různí tenanti Microsoft Entra

Hranice správy:

Různé skupiny správců bez překrývání
Oddělení organizačních zásad a ovládacích prvků
Nezávislé smlouvy o úrovni služeb

Hodnotící rámec

Faktor	Jedna organizace	Více organizací
Spolupráce	Maximální viditelnost a sdílení	Izolované, omezené sdílení mezi organizacemi
Administrace	Centralizovaná, jednodušší správa	Distribuované a větší režijní náklady na správu
Podávání zpráv	Sjednocené řídicí panely a analýzy	Samostatné systémy generování sestav
Cost	Jedna fakturační entita	Více fakturačních entit
Security	Sdílené hranice, sjednocené zásady	Pevné hranice, nezávislé zásady

Důležité

U organizací Microsoft Entra vlastněných společností zvažte omezení vytváření organizace , aby chránila duševní vlastnictví a zachovala zásady správného řízení.

Co je tým?

Tým je jednotka, která podporuje mnoho nástrojů konfigurovatelných týmem. Tyto nástroje vám pomůžou plánovat a spravovat práci a usnadňují spolupráci.

Vytvoření týmu pro každý samostatný produkt nebo tým funkcí

Každý tým má svůj vlastní backlog. Pokud chcete vytvořit nový backlog, vytvořte nový tým. Nakonfigurujte týmy a backlogy do hierarchické struktury, aby vlastníci programů mohli snadněji sledovat průběh napříč týmy, spravovat portfolia a generovat souhrnná data. Když vytvoříte tým, vytvoříte také skupinu týmů. Tuto skupinu můžete použít v dotazech nebo nastavit oprávnění pro váš tým.

Porozumění projektům

Projekty poskytují kontejner pro vaši vývojovou práci, která obsahuje tyto integrované služby:

Azure Boards: Agilní plánování s využitím backlogů, sprintů a sledování pracovních položek
Azure Pipelines: Průběžná integrace a automatizace nasazování
Azure Repos: Úložiště Git nebo TFVC pro správu zdrojového kódu
Azure Test Plans: Ruční a automatizovaná integrace testování
Sdílené zdroje: Nastavení wikiwebu, řídicích panelů a nastavení na úrovni projektu.

V následujícím příkladu společnost Contoso Manufacturing používá k uspořádání různých řad produktů čtyři projekty:

Diagram organizace se čtyřmi projekty

Výhody a aspekty projektu

Projekty umožňují:

Sdílené plány iterace a taxonomie napříč týmy
Konzistentní šablony procesů a typy pracovních položek
Integrované vykazování a řízení portfolia
Zjednodušená správa uživatelů a řízení přístupu

Projekty poskytují hranice pro:

Oprávnění k zabezpečení a přístupu.
Přizpůsobení procesů a sledování práce
Zásady správy a zásady správného řízení.
Sledování přidělování prostředků a fakturace

Kolik projektů potřebujete?

Pro začátek používání služby Azure DevOps, jako je Azure Boards, Azure Repos nebo Azure Pipelines, mějte alespoň jeden projekt připravený. Když vytvoříte organizaci, vytvoříte pro sebe výchozí projekt. Ve výchozím projektu je k dispozici úložiště kódu, ve kterém můžete začít pracovat, backlog pro sledování práce a aspoň jeden kanál, který začne automatizovat sestavování a vydávání.

V rámci organizace můžete použít některý z následujících přístupů:

Vytvořte jeden projekt, který obsahuje mnoho úložišť a týmů.
Vytvářejte mnoho projektů, z nichž každý má vlastní sadu týmů, úložiště, sestavení, úkolů a dalších prvků.

I když máte mnoho týmů pracujících na stovkách různých aplikací a softwarových projektů, můžete je spravovat v rámci jednoho projektu v Azure DevOps. Pokud ale chcete spravovat podrobnější zabezpečení mezi softwarovými projekty a jejich týmy, zvažte použití mnoha projektů. Na nejvyšší úrovni izolace je organizace, ve které je každá organizace připojená k jednomu tenantovi Microsoft Entra. Jeden tenant Microsoft Entra ale může být připojený k mnoha organizacím Azure DevOps.

Poznámka:

Pokud povolíte funkci Omezit viditelnost a spolupráci uživatelů na konkrétní projekty ve verzi Preview pro organizaci, uživatelé přidaní do skupiny Project-Scoped Uživatelé nemají přístup k projektům, ke kterým nejsou přidáni. Další informace a důležité popisky související se zabezpečením najdete v tématu Správa organizace, omezení viditelnosti uživatelů pro projekty a další.

Rozhodovací rámec projektu

Zvolte odpovídající strukturu projektu na základě vašich potřeb spolupráce:

Přístup k jednomu projektu:

Nejvhodnější pro: Menší organizace nebo týmy s úzkou spolupráci
Výhody: Maximální viditelnost, sdílené prostředky, jednotné vytváření sestav
Zvažte, kdy: Teams pracuje na souvisejících produktech s podobnými cykly vydávání verzí

Přístup k více projektům:

Nejlepší pro: Nezávislé týmy s odlišnými požadavky
Výhody: Lepší hranice zabezpečení, přizpůsobitelné procesy, samostatnost týmu
Zvažte, kdy: Různé potřeby dodržování předpisů nebo samostatné obchodní jednotky

Azure DevOps poskytuje prostředí napříč projekty pro správu práce napříč několika projekty.

Zvažte více projektů pro:

Omezení nebo správa přístupu k určitým informacím
Podpora vlastních procesů sledování práce pro různé obchodní jednotky
Podpora samostatných obchodních jednotek pomocí nezávislých zásad správy
Testování přizpůsobení nebo rozšíření před uvedením do produkčního prostředí

Důležité

Přenositelnost úložiště Git usnadňuje migraci úložišť (včetně úplné historie) mezi projekty. Mezi projekty ale nemůžete migrovat další historii, jako jsou push požadavky a pull požadavky.

Když mapujete projekty na organizační jednotky, vaše společnost získá jednu organizaci a nastaví mnoho projektů s jedním nebo více projekty představujícími obchodní jednotku. Tato organizace obsahuje všechny prostředky Azure DevOps společnosti a nachází se v dané zeměpisné oblasti (například v Evropě). Při mapování projektů na organizační jednotky zvažte následující doprovodné materiály:

	Jeden projekt, mnoho týmů	Jedna organizace, mnoho projektů a týmů	Mnoho organizací
Obecné pokyny	Nejvhodnější pro menší organizace nebo větší organizace s vysoce sladěnými týmy.	Dobré, když různé snahy vyžadují různé procesy.	Užitečné jako součást starších migrací a pro pevné hranice zabezpečení mezi organizacemi. Používá se s více projekty a týmy v rámci každé organizace.
Měřítko	Podporuje desítky tisíc uživatelů a stovek týmů, ale nejlépe v tomto měřítku, pokud všechny týmy pracují na souvisejícím úsilí.	Stejné jako u jednoho projektu, ale mnoho projektů může být jednodušší.
Proces	Sladěné procesy napříč týmy; Flexibilita týmu pro přizpůsobení panelů, řídicích panelů atd.	Nezávislé procesy pro každý projekt. Například různé typy pracovních položek, vlastní pole atd.	Stejné jako mnoho projektů.
Spolupráce	Nejvyšší výchozí viditelnost a znovupoužití mezi prací a zdroji různých týmů.	Je možné získat dobrou viditelnost a opakované použití, ale je snazší skrýt prostředky mezi projekty, ať už úmyslně nebo ne.	Špatná viditelnost, spolupráce a opakované použití mezi organizacemi.
Sestavování agregovaných zpráv a správa portfolia	Nejlepší schopnost integrovat týmy a koordinovat činnost mezi nimi.	Možné dobré reportování mezi projekty. Obtížnější pro koordinaci mezi projekty a týmovou koordinaci.	Mezi organizacemi není žádná sloučení ani koordinace.
Zabezpečení/izolace	Může uzamknout zdroje na úrovni týmu, ale ve výchozím nastavení je otevřený přístup a spolupráce.	Lepší schopnost zabezpečení mezi projekty. Ve výchozím nastavení poskytuje dobrou viditelnost v rámci projektů a dobrou izolaci napříč projekty.	Pevné hranice napříč organizacemi; vynikající izolace a minimální schopnost sdílet mezi organizacemi.
Přepínání kontextu	Nejjednodušší je, aby týmy spolupracovaly a aby uživatelé mohli přepínat mezi úsilím.	Je pro uživatele poměrně snadné spolupracovat a přepínat kontexty mezi projekty.	Pro uživatele, kteří musí pracovat v různých organizacích, je obtížnější.
Přetížení informací	Ve výchozím nastavení jsou všechny prostředky viditelné uživatelům, kteří používají "oblíbené" a podobné mechanismy, aby se zabránilo "přetížení informací".	Snížené riziko informačního zahlcení; většina prostředků projektu je skryta napříč projektovými hranicemi.	Prostředky napříč organizacemi jsou izolované a snižují riziko přetížení informací.
Administrativní režie	Mnoho správy je delegováno na jednotlivé týmy. Nejjednodušší pro licencování uživatelů a správu na úrovni organizace. V případě potřeby sladění mezi úsilím může být potřeba více práce.	Další správa na úrovni projektu. Větší režijní náklady, ale může být užitečné, když mají projekty různé potřeby správy.	Stejně jako u více projektů existuje větší režijní náklady na správu, což umožňuje větší flexibilitu mezi organizací.

Strukturování úložišť a správy verzí v rámci projektu

Zvažte konkrétní strategickou práci vymezenou na jednu z organizací, které jste vytvořili dříve a které potřebují přístup. Tyto informace použijte k pojmenování a vytvoření projektu. Tento projekt má adresu URL definovanou v organizaci, ve které jste ho vytvořili, a můžete k němu přistupovat na adrese https://dev.azure.com/{organization-name}/{project-name}.

Nakonfigurujte projekt v nastavení projectu.

Snímek obrazovky s tlačítkem Nastavení projektu

Další informace o správě projektů najdete v tématu Správa projektů v Azure DevOps. Projekt můžete přesunout do jiné organizace migrací dat. Další informace o migraci projektu najdete v přehledu migrace.

Strategie úložiště a správa verzí

Nakonfigurujte strategii úložiště na základě velikosti týmu, architektury produktu a požadavků na nasazení.

Výběr systému správy verzí

Volba mezi Gitem a správou verzí Team Foundation (TFVC):

Úložiště Git:

Doporučený přístup pro pracovní postupy moderního vývoje
Neomezená úložiště na jeden projekt
Distribuovaná správa verzí s flexibilním větvení
Integruje se s většinou vývojových nástrojů a systémů CI/CD.

Team Foundation Version Control (TFVC) (Správa verzí Team Foundation):

Centralizovaný systém správy verzí
Jedno úložiště na jeden projekt s organizací založenou na složce
Vhodné pro týmy, které preferují centralizované pracovní postupy

Tip

Projekty můžou používat úložiště Git i TFVC, pokud mají vaše týmy jiné předvolby pracovního postupu.

Vzory organizace úložiště

Strategie Monorepo:

Nejlepší pro: Malé týmy, které nabírají na síle se souvisejícími službami
Výhody: Zjednodušené sdílení a koordinované změny
Výzvy: Složitost znalostí se zvyšuje s růstem týmu; nezamýšlená servisní spojka; obtížné sledování změn

Samostatná strategie úložišť:

Nejvhodnější pro: Větší týmy s nezávislými nasazeními služeb
Výhody: Vymazání hranic služeb, jednodušší onboarding, nezávislé cykly vydávání verzí
Důležité informace: Vyžaduje větší počáteční nastavení, ale efektivně se škáluje s růstem týmu.

Tip

Začněte s monorepo pro malé týmy a poté přejděte na samostatná úložiště, jakmile vaše organizace roste a složitost se zvyšuje.

Strategie sladění úložišť a projektů

Jeden projekt s více úložišti:

Nejvhodnější pro: Produkty a služby s harmonogramy koordinovaných verzí
Výhody: Sdílené procesy, konzistentní řízení přístupu, zjednodušená správa
Použití: Vývojáři často pracují napříč různými úložišti a vyžadují konzistentní nástroje

Více projektů s vyhrazenými úložišti:

Nejvhodnější pro: Produkty s nezávislými plány nebo odlišnými požadavky
Výhody: Nezávislé přizpůsobení, samostatné zásady správného řízení, jasné hranice

Poznámka:

Přenositelnost úložiště Git umožňuje snadnou migraci mezi projekty s úplnou historií potvrzení.

Rozhodovací faktory pro organizaci úložiště:

Závislosti kódu: Umístění nezávisle nasaditelných produktů a služeb do samostatných úložišť
Potřeby koordinace: Udržování souvisejících základů kódu pohromadě, pokud se očekává koordinované změny
Architektura: Udržovat existující monolitické objekty v jednom úložiště; samostatné odpojené služby
Přístup týmu: Implementace správné správy oprávnění pro řízení vytváření úložiště

Tip

Zvažte správu svých oprávnění, aby ne každý ve vaší organizaci mohl vytvářet úložiště. Pokud máte příliš mnoho úložišť, je obtížné sledovat, kdo vlastní kód nebo jiný obsah uložený v těchto úložištích.

Sdílené úložiště vs. forkovaná úložiště

Použijte sdílené úložiště v rámci důvěryhodné organizace. Vývojáři používají větve, aby jejich změny zůstaly oddělené od sebe. Díky dobré strategii větvení a vydávání verzí může jedno úložiště podporovat souběžný vývoj pro více než tisíc vývojářů. Další informace o strategii větvení a vydávání verzí najdete v tématu Adopt a Git branching strategy and Release Flow: Our Branching Strategy.

Forky jsou užitečné, když pracujete s týmy dodavatelů, které by neměly mít přímý přístup k aktualizaci hlavního úložiště. Forky jsou také užitečné ve scénářích, kdy mnoho vývojářů přispívá zřídka, například v opensourcového projektu. Při práci s forky můžete zvážit zachování samostatného repozitáře, který izoluje forknuté repozitáře od hlavního repozitáře. Přibyly režijní náklady na správu, ale hlavní projekt je přehlednější. Další informace najdete v článku Forks.

Následující obrázek ukazuje, jak by vaše společnost mohla strukturovat své organizace, projekty, pracovní položky, týmy a úložiště.

Diagram znázorňující organizační strukturu pro společnost

Správa dočasných a sdílených prostředků

Zvažte efektivní správu dočasných a sdílených prostředků s využitím následujících osvědčených postupů:

Dočasná prostředí: Dočasná prostředí jsou krátkodobá a používají se pro úlohy, jako je testování, vývoj nebo příprava. Efektivní správa těchto prostředí:
- Samostatná úložiště a kanály: Každé dočasné prostředí a související prostředky, jako je Azure Functions, by měly mít vlastní úložiště a kanál. Toto oddělení znamená, že můžete nasadit a vrátit zpět prostředí a jeho prostředky současně. Je jednodušší je podle potřeby zapnout a zahodit.
- Příklad: Vytvořte úložiště a kanál speciálně pro vaše vývojové prostředí, včetně všech potřebných prostředků, jako jsou Azure Functions, účty úložiště a další služby.
Sdílené prostředky: Sdílené prostředky jsou obvykle dlouhodobé a používají se v různých prostředích. Tyto prostředky často mají delší dobu spouštění a vyšší náklady. Efektivní správa sdílených prostředků:
- Samostatná úložiště a kanály: Sdílené prostředky, jako je Azure SQL Database, by měly mít vlastní úložiště a kanál. Toto oddělení zajišťuje, že dočasná prostředí můžou tyto sdílené prostředky používat, aby jejich nasazení byla rychlejší a nákladově efektivnější.
- Příklad: Vytvořte úložiště a kanál pro službu Azure SQL Database, které může používat několik dočasných prostředí.
Sdílené prostředky infrastruktury: Sdílené prostředky infrastruktury, jako jsou virtuální privátní cloudy (VPN) a podsítě, označované také jako cílové zóny, by měly mít také vlastní úložiště a kanály. Tento přístup zajišťuje, že infrastrukturu spravujete konzistentně a můžete ji opakovaně používat v různých prostředích.
- Příklad: Vytvořte úložiště a kanál pro konfiguraci VPC a podsítě, na která můžou odkazovat další úložiště a kanály.

Další informace o organizační struktuře

Zvolte typ účtu správce vaší organizace.

Při vytváření organizace určují přihlašovací údaje, které používáte k přihlášení, které zprostředkovatele identity vaše organizace používá. Vytvořte organizaci pomocí účtu Microsoft nebo instance Microsoft Entra. Pomocí těchto přihlašovacích údajů se přihlaste jako správce ve vaší nové organizaci na adrese https://dev.azure.com/{YourOrganization}.

Použití účtu Microsoft

Pokud nepotřebujete ověřovat uživatele pro organizaci pomocí ID Microsoft Entra, použijte svůj účet Microsoft. Všichni uživatelé se musí přihlásit k vaší organizaci pomocí účtu Microsoft. Pokud ho nemáte, vytvořte si účet Microsoft.

Zadejte heslo a přihlaste se.

Pokud nemáte instanci Microsoft Entra, vytvořte si ji zdarma na webu Azure Portal nebo použijte svůj účet Microsoft k vytvoření organizace. Pak můžete svou organizaci připojit k Microsoft Entra ID.

Použití účtu Microsoft Entra

Účet Microsoft Entra už možná máte, pokud používáte Azure nebo Microsoft 365. Pokud pracujete pro společnost, která ke správě uživatelských oprávnění používá Microsoft Entra ID, pravděpodobně máte účet Microsoft Entra.

Pokud nemáte účet Microsoft Entra, zaregistrujte si Microsoft Entra ID, aby se vaše organizace automaticky připojila k vašemu ID Microsoft Entra. Všichni uživatelé musí být členy v daném adresáři, aby měli přístup k vaší organizaci. Pokud chcete přidat uživatele z jiných organizací, použijte spolupráci Microsoft Entra B2B.

Azure DevOps ověřuje uživatele prostřednictvím vašeho ID Microsoft Entra, aby k vaší organizaci měli přístup jenom uživatelé, kteří jsou členy v daném adresáři. Když odeberete uživatele z daného adresáře, nebudou už mít přístup k vaší organizaci. Pouze konkrétní správci Microsoft Entra spravují uživatele ve vašem adresáři, takže správci řídí, kdo přistupuje k vaší organizaci.

Další informace o správě uživatelů najdete v tématu Správa uživatelů.

Mapování organizací na organizační jednotky

Každá obchodní jednotka ve vaší společnosti získá vlastní organizaci v Azure DevOps spolu s vlastním tenantem Microsoft Entra. Podle potřeby můžete nastavit projekty v rámci těchto jednotlivých organizací na základě týmů nebo probíhající práce.

Pro větší společnost můžete vytvořit více organizací pomocí různých uživatelských účtů (s největší pravděpodobností účty Microsoft Entra). Zvažte, jaké skupiny a uživatelé sdílejí strategie a pracují, a seskupte je do konkrétních organizací.

Fiktivní společnost Fabrikam například vytvořila následující tři organizace:

Fabrikam-Marketing
Fabrikam -Engineering
Fabrikam-Sales

Každá organizace má samostatnou adresu URL, například:

https://dev.azure.com/Fabrikam-Marketing
https://dev.azure.com/Fabrikam-Engineering
https://dev.azure.com/Fabrikam-Sales

Organizace jsou určené pro stejnou společnost, ale většinou jsou navzájem izolované. Tímto způsobem nemusíte nic oddělit. Hranice můžete vytvářet jenom tehdy, když dává smysl pro vaši firmu.

Tip

Existující organizaci můžete snadněji rozdělit na projekty, než kombinovat různé organizace.