Správa vendors a přístupů do nich rubrika: Folklór

5 Petr Konůpek
položil/-a 2.2. 10:21

Všichni to známe.
V dnešní době webový software není ve vzduchoprázdnu, ale má obvykle hromadu vnějších vendors, jako jsou např. platební brány, Facebook, Twitter, AWSko, iTunes Connect atd atd...
Ke všem existují přístupy s různou úrovní práv.

Jelikož jsme vývojářské studio a pracujeme pro mnoho klientů napříč obory, velice často narážíme na to, že například potřebujeme v rámci vývoje zpřístupnit právě iTunes Connect a u klienta propukne detektivní pátrání, protože se ukáže, že nikdo z firmy netuší, kdo tam vlastně má přístup. Obvykle se děje to, že se hrabeme v systému, na který nikdo třebas 4 roky nesáhnul, takže už si to nikdo nepamatuje, nebo člověk, který se o to staral, už jednoduše ve firmě nepracuje.

Moje otázka zní:
Znáte, nebo používáte nějaké spolehlivé bezpečné nástroje/postupy na správu vendors a přístupů do nich?

odkaz
10 rmaslo
odpověděl/-a 5.2. 17:06
 
upravil/-a 5.2. 17:08

To je jenom jeden z mnoha problémů, který je součástí většího celku zvaného "komunikace se zákazníkem".

V komunikaci se zákazníkem někdo vyžaduje pečlivě právně ošetřené smlouvy, jiný stostránková zadání programu, třetí maluje nějaké UML, atd... Já osobně vždy vyžaduji, aby zákazník stanovil "metodického gestora" aplikace. Metodický gestor je člověk stanovený zákazníkem, který má rozhodující slovo při tvorbě aplikace. Rozhodující ve smyslu, že má konečné slovo při rozhodování o tom co a jak se udělá. Zákazníkovi kladu na srdce, aby ho vybral zodpovědně, z pracovníků kteří v organizaci již nějaký ten rok jsou, kteří vědí co má aplikace dělat a kteří znají její uživatele (pokud je přes víc oddělení). A také se mu zmíním o tom, že mu na tuto činnost musí vyčlenit nějaký čas a pokud to vše dobře dopadne, tak by měl dostat nějakou odměnu. A že když někdy časem M.G. odejde tak musí vybrat jiného.

Jako analytik s metodickým gestorem samozřejmě úzce spolupracuji a kromě toho, že děláme schůzky s jinými uživateli (kteří specifikují své požadavky) a že mu předkládám ty různé návrhy řešení (včetně jejich výhod a nevýhod) o kterých on pak rozhodne, mu říkám několik věcí:

  1. Že jeho práce je klíčová pro přijetí programu v organizaci a ovlivní tím jeho další kariéru tam.
  2. Že on je ten, který má nejvyšší práva v programu (zřizování uživatelů a přiřazování do skupin).
  3. Že si ty přístupové údaje, jak do programu tak do dalších služeb musí zapsat a při případném odchodu je předat.
  4. Že musí být schopen v používání programu vyškolit další lidi a odpovědět na jejich otázky.
  5. Že by za to měl dostat nějakou odměnu.

Já osobně si během tvorby aplikace na pravidelných (většinou 1x týdně) schůzkách s M.G. zapisuji úkoly na další týden přímo do tvořené aplikace (nesnáším papíry a často pracuji z různých míst) udělám si tam na to jednoduchou agendu id, nazev, popis-TinyMCE. Což se často M.G. zalíbí a jako součást aplikace uděláme to samé (přístupné jen jemu), kam on si zase zapisuje co znamenají jednotlivé skupiny, jaký vliv přesně mají položky globální konfigurace (třeba přechod na nový rok), případně tam má předpřipravené odpovědi na časté otázky uživatelů. A vůbec mi nevadí, když přístupy k nějakým externím zdrojům aplikace skončí také tam.

PS: Nedělám weby, dělám databázové podnikové intranetové aplikace.

Pro zobrazení všech 4 odpovědí se prosím přihlaste:

Rychlé přihlášení přes sociální sítě:

Nebo se přihlaste jménem a heslem:

Zadejte prosím svou e-mailovou adresu.
Zadejte své heslo.