Zeptali jste se, aneb dotazy a odpovědi

Na této stránce uvádíme odpovědi na otázky, které naši konzultanti dostali nebo které jste nám zaslali emailem a přišly nám zajímavé. Zásadně neuvádíme autora dotazu, aby to někoho neodradilo od chuti se na nás obrátit. Vždy také měníme kontext, pokud by hrozilo, že by se někdo mohl v situaci poznat nebo poznat svou firmu.

Pokud se sami chcete na něco zeptat, neváhejte se na nás obrátit, rádi pomůžeme a nebo přiznáme, že nevíme.

Řadu otázek dostáváme a odpovídáme v angličtině a proto Vaší pozornosti doporučujeme i anglickou verzi této stránky.

2016


jaká KPI / cíle má smysl definovat pro implementaci projektu enterprise architektury a co to firmě objektivně (měřitelně) přinese?

Jak velký bude v absolutních číslech přínos, samozřejmě závisí zejména na tom, jak "špatná" je situace před implementací i jak pořádně se implementace architektury udělá. Následující čísla odpovídají nejběžnější situaci, kdy firma dělá pro své projekty analýzy, ale ty zůstávají projektovou dokumentací a v dalších projektech se využívají minimálně nebo vůbec.

  • Zrychlení implementačních prací projektů (část analýza až o 40% - analýza současného stavu a vyšší kvalita analýzy); relevantní je měřitelný úspěch o 30%
  • Snížení počtu předělávek a oprav zjištěných v průběhu testování a zkušebního provozu úprav; lze předpokládat zlepšení cca o 30%
  • Snížení závislosti na konkrétních lidech resp. jejich znalosti a zvýšení zastupitelnosti; v optimálním případě lze předpokládat 100% zastupitelnost u analytiků a to i v průběhu projektu (předpokládá se zastupitelnost jinými analytiky se znalostí business domény
  • Zlepšení škálovatelnosti týmů provádějících analýzu a dynamické přidělování kapacit (jde o přímý důsledek předchozího bodu)
  • Snížení rizikovosti celého IT díky lepší analýze rizik a závislostí; v ideálním případě lze u 100% elementů (SW i HW) možné říct, jaký důsledek na business má jejich výpadek/porucha a mít tak kvalitně připravené recovery plány

Důležité je upozornit, že Enterprise architektura je dlouhodobá investice, a její přínosy jsou tomu podobně - projevují se s časem a většinou nejdříve rok po skutečném zavedení principů do praxe. Proto bývá i obtížné vázat přínosy s KPI, které jsou v naprosté většině vyhodnocovány s periodou roku nebo méně.

Jaké jsou vhodné nástroje pro modelování organizace (procesů nebo celé enterprise architektury)?

Takto položenou otázku je těžké odpovědět bez toho, abychom dělali nějakému nástroji reklamu a jiný zatracovali. A stejně tak se vystavujeme riziku, že budeme nařčeni z neporozumění či neznalosti toho kterého nástroje a náš soud bude lynčován pro nekorektnost. Přesto se pokusíme odpovědět, i když trochu obecně.

Za zásadní oblasti, které doporučujeme ověřit a ohlídat před rozhodnutím pro ten který nástroj, jsou:

Umožňuje vytvářet modely, které potřebujeme? Podporuje např. procesní modelování v BPMN, enterprise architekturu v ArchiMate? Samozřejmě existují další potřebné jazyky, např. pro návrh software může být důležitý jazyk UML.

Podporuje nástroj modelování obecně? I tato otázka je důležitá, řada nástrojů modelování fakticky téměř nepodporuje.

Umožňuje výstupy tak, aby s nimi mohli všichni pracovat? Dokážeme výstupy sdílet, publikovat, odesílat apod.? Není přístup k informacím vázán na nástroj, které je obtížné pochopit? Je třeba rozlišit mezi autory informací - aktivní tvůrci modelu a příjemci informaci, kterými jsou typicky metodici, manažeři, ale i dodavatelé IS. Pro ně musí být informace snadno dostupné a přehledné.

Umožňuje sdílení a omezování přístupu k informacím? Zdaleka není samozřejmé, aby nástroje umožňovaly sdílení modelů a současně umožnili přístup jen k určitým částem modelu.

Podporuje skutečně práci s modelem? Možnost pracovat s prvky modelu nezávisle na schématech je pro seriozní práci fakticky nezbytná a snad komerční nástroje to podporují (pokud nejsou primárně "kreslítky"). U free nástrojů už to zdaleka tak samozřejmé není.

Kolik bude nástroj stát jednorázově a ročně? Peníze až na posledním místě, nicméně náklady na jednotlivé nástroje se liší (skutečně!) řádově. Nezapomeňte dobře spočítat, kolik lidí by s informacemi mělo ideálně pracovat. Nejedna dobrá snaha skončila na tom, že licencí organizace pořídila tak málo, že se nástroj stal v praxi nevyužitelný. Na celkových nákladech se v případě některých nástrojů hodně podepisuje i faktická nemožnost nástroj používat bez soustavné pomoci dodavatelské firmy. Příkladem je situace, kdy si bez dodavatele nemůžete nastavit metodiku, vytvořit datový výstup, tiskovou sestavu apod. Tyto dodatečné náklady často představují o to větší limit, že jejich potřeba nastává nenadále a oddělení na ně nemají rozpočet.

Hodilo by se na závěr říct, který nástroj vyhovuje. Ale v tom je potíž: žádný z nástrojů, se kterými jsme dosud pracovali, nevyhověl ve všech kritériích podle potřeby. Vždy je výběr postaven na kompromisu mezi tužbami, potřebami, možnostmi i znalostmi lidí. Rádí vám pomůžeme vybrat, ale víme, že co se hodí pro jednoho, není dobré pro všechny.

2015


Musí být business analytik schopný modelovat data v 3NF (datový model v 3 normální formě)?

Na tuto otázku je odpověď alibistická: Jak kdy. Rozhodující totiž není, jak se ta která pracovní role jmenuje, ale jak jsou rozložené úkoly v týmu.

Směrodatnější je, co očekáváme od business analytiků u přijímacích pohovorů a tady mohu odpovědět jednoznačně, že ať jsme dělali přijímací pohovory na analytiky pro pořizovatele software (banky, apod.) nebo dodavatele (softwarové firmy), ani v jednom případě nebyla role definována tak, že by přípravu dat do podrobnosti datového modelu vyžadovali.

V praxi lze očekávat, že od business analytika kdekoli jinde než v softwarové firmě, se tato schopnost neočekává. Není důvod pro to důvod.

Naopak - i když to tak vedoucí a tým nepožadoval - pokud jde někdo dělat analytika do softwarového týmu, spíš bych doporučil, aby význam 3NF alespoň chápal, protože pak bude lépe rozumět tomu, jak s datovým návrhem pracují designeři.

Proč na začátku odpovídám ?Jak kdy?, když odpověď je nakonec docela jednoznačná? Protože zejména v malých týmech (a mohou to být i týmy vytvořené velkými firmami o stovkách SW specialistů), je prostě nezbytné, aby analytik kvalitní návrh databáze zvládl, protože nikdo jiný to za něj dělat nebude. Stejně tak nemálo projektů skončí tak, že analytik připraví data v nástroji typu Access nebo Excel a pokud bude chápat teorie správné práce s daty, tedy mj. i 3NF, má šanci udělat řešení, které bude sloužit spolehlivě a bez závad.

Z našich vlastních projektů můžeme potvrdit, že dodržování teoretických modelů návrhu aplikace i dat se nám maximálně vyplatilo - jejich důsledné dodržování snižuje náklady na údržbu aplikace na méně než 10% toho, co jinak aplikace běžně vyžadují. Bohužel, mnohé současné ?rapidní? přístupy k vývoji, házejí teorie za hlavu a nahrazují je rychlostí - tedy rychlostí z počátku vývoje. Z hlediska celého životního cyklu aplikace spíš než o rychlost jde o dohánění hrubou silou. Ale to už jsme u zcela jiného tématu.

Pokud chcete dělat analýzy kvalitně, pomůže k tomu náš cyklus školení pro analytiky.

2014


Jaké informace o IT aplikacích by měl sledovat vrcholový management organizace?

Vrcholový management je v principu odpovědný za vše, co se v organizaci děje, ale jeho role je vzhledem k Enterprise architektuře stejná, jako vzhledem k ostatním částem firmy:

  • Kontrola, že výkonný management se o oblast správně stará
  • Sbírat podklady pro upřesňování globální strategie a tuto strategii definovat
  • Vést péči v souladu se strategií organizace

Z tohoto úhlu pohledu lze říct, že vrcholový management v podstatě zajímají informace, které by IT mělo o aplikacích kontinuálně udržovat a vyhodnocovat. Vrcholové vedení tak navazuje na dobrou práci odpovědného hospodáře, který má přehled o tom, o co se stará.

Konkrétně pro oblast IT aplikací by management (CEO) měl po vedoucím IT (CIO) chtít informace o pohledech

Finanční pohled

  • Kolik stojí provoz (správa, údržba)
  • Kolik se do ní ročně investuje (rozvoj)
  • Jak se náklady na provoz vyvíjí

Strategický pohled

  • O jaké klíčové informace se aplikace stará
  • Jaký je překryv funkčnosti aplikace s jinou aplikací (kolik by dalo práce její funkčnost integrovat do jiné)?
  • Jaký je objem ročních změn aplikace
  • Jaká je strategie IT s dalším rozvojem aplikace
  • Jaké strategické projekty v posledním roce vyžadovaly implementaci do aplikace a jak dlouho se na implementaci čekalo

Ochrana rizik

  • Kdo se o ní stará
  • Jaké je riziko, že se starat přestane (jak se s rizikem pracuje)
  • Co by se stalo, kdyby o ní nebylo postaráno
  • Jak budeme fungovat, když aplikace selže/nebude dostupná

Pro posuzování všech hledisek je podstatné:

  • Jaké vnitřní služby (schopnosti) nebo produkty (služby klientům)  jsou na aplikaci závislé
  • Na jakých dalších aplikacích je tato aplikace závislá

Jak uspět dnes na trhu s výrobkem - softwarem?

Udržet se na trhu nebo dokonce přijít na něj nově je pro většinu oborů náročné. IT trh byl donedávna tzv. emergency market - rychle se rozvíjející a tento problém se jej tolik netýkal. Dnes už je ale standardním trhem a situace se změnila - více o tom v tomto článu.

2013


Našel jsem na vašich stránkách, že pomáháte rozvoji businessu a podnikání. Máte nějaká doporučení, co je nejlepší marketingová strategie pro malou firmu, abychom naše produkty lépe prodávali?

Především musíme rozdělit pojmy marketingová strategie a propagace (pravděpodobně existujících) produktů.

Marketingová strategie

Marketingová strategie začíná dlouho předtím, než máme hotový produkt. Začíná ve chvíli, kdy si klademe otázku, kam chceme s firmou dlouhodobě směrovat:

  • Jaký trh chceme oslovovat - zaměřujeme se na B2B korporace, malé firmy nebo B2C - bohaté klienty nebo širokou veřejnost?
  • Jakou chceme mít strategii, s čím na trh přicházet - chceme být leadery trhu nebo přicházet s levnými variantami existujících produktů?
  • Jakou jedinečnou vlastnost budou naše produkty mít - cenu, konkrétní vlastnost, souhrn vlastností apod.
  • ... a řada dalších témat, bez kterých bude business strategie neužitečná nebo dokonce nebezpečná

Těmto rozhodnutím musíme přizpůsobit celou firmu (vývojové, výrobní, obchodní i marketingové oddělení), produkty, jejich propagaci atd. Rozhodnutí o změně marketingové strategie je jedním z nejzávažnějších, které firmy dělají a pokud se udělá špatně, může i velkou nadnárodní firmu zlikvidovat, historie zná takových případů řadu.

Už kvůli závažnosti rozhodnutí není možné dát jakoukoli radu ?naslepo? bez detailní znalosti firmy, jejího potenciálu postavení na trhu a konkurence. Neexistuje ani žádná univerzálně použitelná strategie. PDQM má zkušenosti, jaké kroky udělat, aby změna business strategie proběhla úspěšně a pro firmu nepředstavovala velké riziko. Se změnou můžeme pomoci, ale jedině v úzké spolupráci s managementem firmy.

Propagace

Samotná propagace, na kterou dotaz v úvodu mířil, je součástí celkové strategie. Má pomoci dostat se a udržet na trzích vytipovaných v rámci strategie. Každý trh a každý produkt vyžaduje svou vlastní metodu propagace. Jinak nabízíte levná jídla z bistra a jinak klenoty Jinak masáže a jinak školení pro firmy. Ani v tomto případě nelze radit bez znalosti strategie a síly firmy.

A upřímně: PDQM pomáhá vytvářet business a marketingové strategie, ale nejsme PR / reklamní firmou a pokud jde o samotnou propagaci na vytipovaném trhu, využíváme partnerů, se kterými dlouhodobě spolupracujeme. Rádi Váš kontakt předáme jim, víme, že na propagaci jsou zkušenými odborníky.

Červenec 2013


Jakou notaci používáte pro popis procesů? BPMN má přes 150 různých symbolů a i technicky zdatný odborník se v modelu ztrácí

Jednoduchou odpovědí je ano, BPMN používáme. Má to však svá ale, o kterých je více v příspěvku o zkušenostech s BPMN. Důležité přitom je, že tam, kde modely v BPMN používáme, uživatele a tvůrce v používání BPMN také školíme.

Červen 2013


Zkoušel jsem ukecat naši novou vedoucí analytiků, aby se dalšímu rozvoji procesů věnovala. Máte nějaké náměty, jak další zlepšování práce analytiků u nás rozhýbat?

Jakékoli zlepšování v organizacích funguje pouze pokud za ním stojí lidé, kteří mají sílu lidi ve firmě přesvědčit, aby změny realizovali. Upřímně, musí to být management, nebo neformální leader skupiny, nikdo jiný ten potenciál nemá. Když za změnou nestojí přesvědčení vedení, je možné změnit konkrétní techniky, ale rozhodně ne návyky a postupy.

Druhá zásada zlepšování je, že lidé musí cítit potřebnost ? naprostá většina lidí o změny nestojí, ráda dělá vše zaběhaným způsobem a teprve vědomí, že se řítí do maléru, je přesvědčí, aby změnili směr. Když aktivně pracuji s lidmi, tak základem zlepšení je, aby pochopili, proč je současná praxe problémová. Ostatně je to i správná kontrola práce ? pokud by mě osobně nebyla potřeba zlepšení jasná, nemám právo změny navrhovat (nemohu přece zlepšovat něco, co funguje optimálně, nebo nevím, proč to nefunguje). Druhým - a často těžším - úkolem je lidi přesvědčit. Bohužel, řada procesních problémů a následných malérů je totiž toho charakteru, že nepálí zrovna ty, kdo je způsobují (např. špatné hospodářské výsledky, nespokojenost uživatelů nedoléhá na analytiky vždy natolik přímo, aby je skutečně motivovaly).

Třetí podmínkou je vize ? musím mít představu, kam se chci zlepšováním dostat. Tuto vizi dáváme dohromady na workshopech v úvodu práce. Nová vedoucí ale vizi nemá (nebo dříve vytvořenou vizi nesdílí). Do jisté míry je to pochopitelné ? když převzala tým a odpovědnost za něj, vizi, kam jej chce dostat, si musí teprve vytvořit. Vize se nedají příliš předávat, manažer by měl mít vlastní. K tomu, aby si ji vytvořil, nejvíc pomáhá, když je ve firmě skutečně živá kultura zlepšování; firma se vždy chce někam posouvat, rozvíjet. V takových firmách se od každého manažera očekává, že vizi rozvoje má. (Naopak, firmy, kde tato kultura není. mají manažery zvyklé přežívat, nikoli rozvíjet). Jsme tak opět u odpovědnosti zejména vrcholového vedení, protože tah na rozvoj musí přicházet shora a týká se celé organizace.

Co se dá dělat ve chvíli, kdy se vedoucí rozvoji nevěnuje a problémy neřeší? V podstatě bych doporučil dva přístupy:

  • Artikulovat ve firmě potřebu změny založenou na identifikaci problémů, které nám současný stav způsobuje a důsledků, ke kterým vede. Čím více lidí ochotných problémy řešit si je bude uvědomovat, tím spíše se s nimi bude něco dělat. Je přitom ale nezbytné, když se současně s problémy prezentuje i vize řešení. Bez vize to může vést jenom k šíření ?blbé nálady?, negativních postojů k práci bez konstruktivního přístupu. V důsledku by to tým rozkládalo.
  • Využít kontaktů na vrcholové vedení, aby od středního managementu vizi rozvoje vyžadoval.

Obojí může pomoci týmu další rozvoj nastartovat ať už pro to využije do budoucna jakékoli metody. PDQM může pomoci s vytvořením vize zlepšování i s její realizací, ale pomoc musí vyplývat ze zájmu vedení; bez toho ke skutečnému zlepšení nedojde.

Březen 2013


Je těžké řídit chytré lidi?

Mám pěkné úsloví: Chytrému poraď, hloupého nakopni. Řídit tým chytrých lidí je velmi odlišná práce, než tým průměrných pracovníků.

S týmem chytrých lidí vedoucí projektu potřebuje především

* Motivovat (přičemž motivuje výzva, existence problému)

* Koordinovat (což bývá složitější, protože chytří lidé častěji pracují ?po svém?)

* Zajistit zdroje (není závislé na konkrétních lidech)

S průměrnými pracovníky naproti tomu práce vedoucího projektu vyžaduje zejména zajistit

* Motivaci (postavenou většinou na odměně nebo zážitku nesouvisejícím s vlastní prací)

* Vedení krok za krokem (časově velmi náročné)

* Řešení problémů (Všechno je problém a žádný problém se nevyřeší sám)

* Koordinaci na úrovni mikromanagementu

* Účinnou kontrolu kvality

Únor 2013


2012

Naše firma má zaměstnává kolem 15 zaměstnanců. Většinu ze zaměstnanců tvoří dělníci a řidiči stavebních strojů. Předmětem podnikání je stavební činnost, rekultivační činnost a zemědělská činnost. Cílem firmy je si co nejdéle udržet už zaběhlé pracovníky a tím zajistit určitou stálou kvalitu svých poskytovaných služeb.

Chceme zhodnotit, co by nám přinesl a co stál kariérní řád např. od PDQM, co by takový řád obsahoval a podle jakých bodů ho sestavujete.

Předtím, než se pustíme s klientem do přípravy kariérního řádu (KŘ) nebo jakéhokoli jiného organizačního dokumentu, musíme vědět, jaký cíl tím klient sleduje. U KŘ tím je většinou snaha motivovat zaměstnance ke vzdělávání a zlepšování kvalifikace. Na druhou stranu pro KŘ je potřeba, aby organizace mohla nabídnout odpovídající odměnu - nové pracovní možností a příležitosti, postup v organizační nebo profesní hierarchii, růst základního platu spojený s vyšší odpovědností apod.

Obsahem řádu je popis pozic, jejich role, odpovědnosti, kompetence, cíle vzdělávání a rozvoje osobních schopností tak, aby rozvoj byl v souladu s business strategií organizace (tj. byl pro ni užitečný). Za to řád nabízí "benefity" - zajímavější resp. různorodější práci, již zmiňovaný postup v hierarchii organizace po manažerské linii (předák, vedoucí,...) nebo odborné (samostatný pracovník, senior, kouč...) a s tím odpovídající pracovní výhody.

Z hlediska kalkulace ceny je výše uvedená úvaha významná z hlediska posouzení pracnosti přípravy plány. Hlavním kritériem určujícím cenu je počet pracovních pozic, kterých se řád týká, cože podle Vašeho organizačního diagramu bude 5 pozic (ve schématu nejsou výkonní pracovníci - členové čet), naopak pro jednatele, majitele, sekretářky (pardon, asistentky) se většinou nedělá.

16.5.2012


2011

Co pro Vás udělá mentor a kde ho najít?

Otázky jsou dvě:

Co pro vás mentor udělá - kvalitní mentor pomůže překlenout mezeru mezi teorií a praxí. Školení a semináře, byť sebelépe připravené a vedené, dávají pouze teoretický základ, ale začlenění jejich poznatků do praxe je obtížné. Více o tom píšeme v článku o vzdělávání a mentoringu.

Kde ho najít - mentor má vést, být expertem na oblast, kterou mentoruje. Má pomoci s praxí a je proto důležité, aby sám aktivní praxi měl. Vzhledem k tomu, že skutečně efektivní zlepšení pracovních návyků jednotlivců je ideálně spojeno i se změnami pracovních standardů organizace, je žádoucí, když se mentor orientuje i v této oblasti. Bez jejich změny narážejí všechna zlepšení na odpor typu "vždycky to všichni dělali takto".

Při výběru mentora je proto nejlepší hledat člověka s praxí shrnující vlastní odbornou práci, vzdělávání i rozvoj interních procesů.

A kde ho tedy najít? Logicky ve firmách, které se všemi třemi oblastmi zabývají. Pokud máte zájem o pomoc mentora v oblasti business a technických analýz, objektového designu, kvaltního testování, projektového řízení nebo organizačních změn, pak můžete hledat přímo u nás, protože my tyto zkušenosti máme.

17.11.2011


Jaké parametry sledovat u chyb v softwarové aplikaci?

Je snadné vysypat řadu možných parametrů pro sledování testování software, ale je obtížné říct, které jsou kdy vhodné. Rada bez znalosti situace bude téměř jistě neužitečná. Zobrazit celou odpověď - parametry pro sledování testování.

15.02.2011


2010

Můžete doporučit společnost/freelancera na zpracování Corporate Identity? Na co při zadání zpracování CI nezapomenout?

Záleží na tom, pro koho to potřebujete. Menší společnost si s freelance službami jistě vystačí, pro větší společnost bych doporučoval spíš firmu, která má samostatné analytiky, PR specialisty, samostatné grafiky a front-end vývojáře. U takové firmy lze očekávat podstatně větší porozumění tomu, jak jinou organizaci vhodně reprezentovat. V takové firmě jsou lidé, kteří se zaměřují na obsah prezentace, jiní se zaměří na formu a zase jiný na technologii řešení. Když dělá všechno 1 člověk, nelze očekávat ve všech - a to velmi odlišných - směrech stejně kvalitní výsledek ani a/nebo kvalitu specialisty.

Při výběru a v rámci další komunikace bych dával pozor především na porozumění smyslu, principům a cílům organizace. To není vůbec samozřejmé, většina společností se chlubí a i skutečně zaměřuje jenom na SEO resp. "mainstream" internetových i tištěných publikací a jedinečnost organizace samotné je ve skutečnosti v podstatě nezajímá (v lepším případě se zeptají na firemní barvy). Bohužel, naprostá většina prezentací ať už internetových, tak papírových (informační letáky, obálky atd.) se jen velmi málo odlišuje jedna od druhých, protože je snazší vymyslet a klientovi prodat typické řešení, než si lámat hlavu se skutečným kreativním nápadem. A přitom jenom takový má opravdu reprezentační smysl.

Pokud máte čas, tak myslím, že je dobré projít si profily organizací podobného zaměření (ale ne přímo konkurenci), rozmyslet si, jak se která prezentuje a pak ideálně oslovit firmu, která připravila profil, který se vám zdál nejlepší.


Vybíráme dodavatele z oblasti IT. Co nám o něm řeknou certifikáty?

Každý certifikát má své specifika a liší se tím jeho vypovídací hodnota. Otázka je obecná, ale obecná odpověď neexistuje.

Především řada certifikátů je osobních, tj. týkají se konkrétního pracovníka firmy. Mezi takové patří např. ISACA certifikáty, PMP certifikace projektového manažera nebo stupně znalosti ITIL. S mírnou nadsázkou se dá říci, že pokud certifikát nemá z firmy zrovna ten pracovník, který bude řešit váš projekt, je vám informace o certifikátu k ničemu. Není to ale tak úplně: pokud lidé získali certifikáty za dobu svého působení v dané firmě, vypovídá to o jejím zájmu mít kvalitní pracovníky. Pokud se ale firma chlubí osobními certifikáty a nemají je pracovníci, kteří pro vás budou pracovat, asi nejste pro dodavatele zrovna klíčový zákazník.

Zajímavější pochopitelně jsou certifikáty firemní resp. týmové. Patří k dobrému jménu firmy v ČR mít certifikát ISO 9001. Jeho vypovídací hodnota o skutečně kvalitě práce a její organizace je, bohužel, velmi nízká. Právě tím, že se díky pravidlům státní správy stal de facto povinnou výbavou firmy, vypovídá držení tohoto certifikátu ze všeho nejvíc o zájmu firmy účastnit se výběrových řízení a získat za certifikát body navíc. Devalvace hodnoty tohoto certifikátu je smutná, protože samotné myšlenky a požadavky normy jsou rozumné.

Z hlediska IT firem jsou zajímavé zejména certifikáty s přímým vztahem k IT službám: ISO 20000, ISO 17999 a zejména CMMI nebo SPICE či Automotive SPICE. Díky podstatně menšímu rozšíření těchto standardů je i kvalita auditorů a mechanismů certifikace průměrně na výrazně vyšší úrovni než u zmiňované ISO 9000. U všech certifikátů ale úroveň kolísá a všechny mají jednu nepochybnou vlastnost: vyjadřují stav, který byl v minulosti a navíc téměř jistě mírně přikrášlen.

Držení standardu každopádně vyjadřuje schopnost firmy či jednotlivce pracovat s technickým materiálem, přizpůsobit se požadavkům normy a pracovat na sobě. Nesporně vyjadřuje i zájem brát kvalitu a celé podnikání vážně.

Pokud vám záleží na tom, jak dodavatel interně pracuje, je nejlepší si jeho interní standardy ověřit před zahájením spolupráce. Jeden zkušený auditor radí jednoduchou otázku: Zeptejte se, v čem firma pracuje lépe, než před rokem a jakými daty to může doložit. Pokud má skutečně smysluplná data o tom, jak nějaká práce probíhala před rokem, záznamy o tom, kdy a jak ji zlepšili a co to skutečně přineslo, můžete si být jisti, že to s kvalitou myslí skutečně vážně.

2009

Otázky a odpovědi týkající se CMMI klikněte na tuto stránku.


K čemu je nezávislé oddělení jakosti?

Chce se mi odpovědět, že k ničemu. Navzdory tomu, že jej každá velká profesionální firma většinou má. Nezávislé oddělení jakosti, nebo anglicky Independent Quality Group či v terminologii CMM (předchůdce CMMI) SEPG (Software Engineering Process Group) to všechno jsou pozůstatky strnulé liniové organizační struktury 20. století, které fungovaly jako kontrolní orgán nezávislý na výkonných složkách a pokud byl kvalitní, tak kromě interních auditů a řízení výstupní kontroly, pomáhal vrcholovému vedení identifikovat vnitrofiremní problémy a zlepšovat procesy.

Všechny činnosti uvedené v předchozím odstavci jsou jistě užitečné. Nic proti nim nenamítám, doplňuji však jedno podstatné ale: Ale neměla by je dělat nějaká nezávislá, tj. od reality odtržená skupinka úředníků / intelektuáků / policistů / nemakačenků (vyberte si podle své zkušenosti) nýbrž měla by fungovat v rámci normální organizace.

Měl jsem možnost seznámit se s pěkným modelem, jak oddělení kvality organizovat a tento model mi přišel následováníhodný: Ponechme toto oddělení i se všemi jeho fakticky rozsáhlými úkoly a pravomocemi, ale odstraňme z něj všechny stálé pracovníky. Že je to bláznovství? Kdo tu práci udělá? Podívejte se znovu na předchozí odstavec: nezpochybňuji užitečnost činností, ale smysluplnost odtržených pracovníků. A to právě nabízí kouzelné řešení. Oddělení kvality může být plovoucí povinností, na které se podle nějakého deterministického klíče střídají všichni pracovníci firmy včetně vedoucích pracovníků. Náhle jde o pracovní skupinu, jakých jistě máte ve firmě řadu, která solní své úkoly, předá je a žezlo s dalšími úkoly vezmou noví lidé. Díky tomu, bude mezi všemi převládat pragmatický, odborný náhled na problémy a řešení a můžete se spolehnout, že např. navržená zlepšení budou téměř jistě použitelná a změny procesů budou určitě efektivnější, než když je vymýšlení teoreticky fundovaní "kvalitámři, kteří vědí, že podle těch procesů nikdy sami pracovat nebudou. Když vymýšlíte práci, která ale nejde za vámi ani za vašimi penězi, můžete se úžasně rozmáchnout a navymýšlet takových činností, že z toho výkonným i řídícím pracovníkům půjde hlava kolem.

K čemu že tedy to oddělení kvality je? Ano jistě, aby dbalo na kvalitu. Ale aby to dělalo kvalitně, musí to dělat lidé, kteří rozumí skvěle celé práci a jejím problémům. A to jsou nejlépe ti, kdo ji přímo vykonávají. Mějte tedy oddělení kvality naplněné lidmi, kteří tu práci dělají. Že vám to něco připomíná? Ale ano, jistě; jde přece o všem světa znalým dobře známé pracovní skupinky z TQM zajišťující - Kaizen, stálé zlepšování. Všechny modely jakosti od ISO 9000 až po CMMI tak znovu objevují něco, co TQM zná již desítky let. I když spíš než modely, tak ti opravdoví kvalitáři, kterým záleží na tom, aby jejich práce byla pro firmu skutečným přínosem.


Zdravím, můžete nám podle standardů doporučit, jak vést provozní deník k serveru?

Standardy samozřejmě můžeme využít (třeba ITIL, CobIT), ale za podstatný považuji účel provozního deníku. Jako každá evidence, má provozní deník smysl pouze pokud je jasné, k čemu slouží. Od toho se také musí odvíjet kým je vytvářena a jaké obsahuje informace. Teprve na třetím místě se bavme o formě evidence.

Účel provozního deníku

Typickým účelem evidence je protokolování, co se se serverem stalo proto, aby se v případě vzniklých problémů dalo snadno dohledat, co může být příčinou a snadněji tuto příčinu odstranit. Často uváděný bezpečnostní důvod ("aby se vedělo, kdo tam co udělal") má smysl pouze pro automticky generované logy, které nelze vypnout a obejít. Pro ručně vytvářený deník je tento bezpečnostní důvod nesmyslný " nikdo přece nezaznamená, že vymazal či změnil databázi, když to dělat neměl.

Druhým, pravděpodobně ještě častějším důvodem deníku je audit. Firma (interní auditor) vedoucí příslušného oddělení (např. CIO) potřebuje mít nástroj, jak kontrolovat, jestli jsou dodržovány dohodnuté pracovní postupy typu kontrol, zálohování, aktualizací atd. Někdy to dělá díky vlastní pečlivosti, častěji proto, že nemá úplně důvěru k administrátorům, někdy i z obav, jestli je všechno v pořádku. Úplně nejčastěji to ale dělá proto, že to požadují zákazníci nebo externí pravidla jako např. standard SOX. Pokud je toto důvodem vedení deníku, je pochopitelně třeba formu i obsah přizpůsobit externím požadavkům, které jeho vedení určují.

Obsah deníku

Obsah deníku je pochopitelně určen jeho účelem. Vycházím z předpokladu, že deník musí být co nejjednodušší, aby zbytečně nezdržoval, ale současně musí plnit svůj účel, za který považuji poskytování přehledu, kdo, kdy kde, s čím, co a proč dělal:

Kdo - osoba (administrátor), vzdálený skript apod.

Kdy - datum a čas, často se hodí čas začátku i konce

Kde - pokud se deník vede společně pro více serverů, tak samozřejmě evidence serveru (např. virtuálního, apod.)

S čím - Aplikace, modul, knihovna, aplikační server - prostě jednotka, která byla předmětem administračního zásahu. Důležité je pamatovat na to, že zvláště produkční servery obsahují často řadu stejných instancí (např. web servery různých zákazníků, více print serverů apod.) a je třeba identifikovat, jestli byl zásah prováděn se všemi nebo pouze s jedním s tedy s kterým

Co - Prováděná aktivita. Mnohé z aktivit jsou anebo by alespoň měly být administrátorskými zásahy definovanými nějakými pracovními postupy. V položce Co pak je pouze odkaz na daný postup. Pak samozřejmě přibude ještě nepovinné pole poznámka, kam se píšou proměnné daného procesu, pokud jsou (parametry, instance apod.) nebo výjimky, pokud nastaly.

Je třeba ale pamatovat na to, že vždy se vyskytnou případy, kdy je třeba dělat i činnosti žádným procesem nepopsané. Je třeba mí možnost zaznamenat i tyto činnosti a záznam to musí podporovat. Míra podrobnosti popisu takové mimořádné činnosti samozřejmě plně závisí na požadavcích, které jsou na evidenci kladené.

Proč - Velmi důležitá a kupodivu často zapomínaná položka, která identifikuje, z jakého důvodu vůbec byl administrátorský zásah prováděn. Šlo o chybu, upgrade, pravidelnou činnost nebo něco jiného? Pokud má firma jiný systém pro sledování tasků (úkolů), chyb nebo požadavků, většinou postačí odkaz do této evidence.

Forma

Forma deníku bývá různá a závisí na možnostech a vybavení příslušné organizace. Někde postačí jednoduchý deník ve formě tabulky v tabulkovém editoru, jinde mají webovou aplikaci, větší firmy mívají některou z aplikací pro System Maanagement, které deníky podporují. Pokud organizace provozuje některé z řešení pro dálkovou správu a monitoring svých systémů, je vždy vhodné, aby byl deník veden podle pravidel daného systému, protože jinak by vznikala duplicitní, neprovázaná a tedy vzájemně nevyužitelná evidence. Ale popravdě řečeno, firmy s takovými systémy už mají své evidence dávno zavedené, ale potřebují mnohem detailnější pomoc.

Příklady provozního deníku

Příklad provozního deníku si lze stáhnout ve formátu OpenOffice nebo prolédnout jako HTML export.


Potrebovali bychom nejake informace o "typickych" velikostech aplikaci v nejakych strojove meritelnych metrikach (SLOC, class count, nesting depth, atd.).

S tím dotazem máme jeden zásadní problém: Co je to typická aplikace? I když aplikace není postavená na SOA architektuře, je každá "rozumná aplikace" postavená z desítek modulů a většinou i samostatných komponent. Pokud jde o produktovou aplikaci, pak jsou moduly stavěné tak, aby bylo možné nasadit ty, které mají pro zákazníka smysl, takže 2 konkrétní aplikace jednoho produktu se mohou lišit v počtu nasazených tříd třeba i několikanásobně.

Relativně malý procesní OSS systém pro telekomunikačního operátora má cca 80 000 vlastních řádek kódu, ale využívá knihovny s dalšími cca 300 000 řádkami.

Počty třídy jsou v řádu stovek (580 podle posledního měření). Nesting Depth jsme přestali sledovat, protože stačí pár rozhodovacích metod typu

if (a)  {?}

else if (b) {?}

...Kiviat graf

else if (z) {?}

else error

které vytvoří hloubku klidně 30 - 50 (měli jsme i 120, to po rozdělení kleslo na 20). I v průměru takové funkce hodnotu dost křiví, ale průměr byl někde na 8. Chtělo by to počítat medián, ale zase automatické nástroje nedělají. Když jsme vyřadili tyto výjimky z pravidla, dostali jsme se na 8. Něco z toho ukáže Kiviat Graf projektu (viz obrázek).

Uvedená aplikace je nativní Windows aplikace (tlustý klient) s aplikačním serverem. Totéž postavené na SOA architektuře a přístupu přes internet má cca 3x tolik řádek kódu, ale složitost kódu je skoro stejná. (Tato složitost nic nevypovídá o složitosti správy a údržby.)


Existuje nejaky statisticky vyznamny prehled (treba neco jako dela Standish Group s Chaos Reportem, ktery je postaveny na rozumnem prehledu dotazovanych spolecnosti)?

V PDQM používáme SourceMonitor od Campwoodsoftware.com. Jeho výhodou bylo, že problémy, které měl, jeho autor opravil, takže pak fungoval dobře. Pro Vás možná bude příliš jednoduchý, nám ale postačil. V praxi totiž metriky měření nad kódem spíš pomáhají určit, jak velký kód skutečně je a z toho odhadovat potřebu testování apod., v menší míře se uplatní odhad jeho správnosti v návrhu, ale tam právě některé maličkosti zcela zkreslí výsledky (např. zakomentovaný kód, který zvýší podíl komentářů). Kromě metrik pro testování, které se jeví jako dobře použitelné, se jako nejlepší jeví modifikovaná varianta funkčních bodů. Modifikace ale musí být podle typu projektů, které daná firma dělá, původní počítající vstupy a výstupy je nedostačující.

Pro metriky nad analýzami postačily nástroje v Enterprise Architect.

Pro metriky nad testovacími scénáři a chybami mi posloužil excel a SQL dotazy do repository.

Co se týče benchmarku, tak k jejich používání jsem více než skeptický a to bez ohledu na to, o jakou oblast software jde. Osobně si myslím (ač sám konzultant), že jejich hlavním užitkem je, že konzultantům pomáhají ukázat, že mají nějaké know-how, které klient ve firmě nemá. Sám mám nějaké publikace o metrikách, které obsahují i typické výsledky metrik, včetně např. porovnávacích funkcí pro jednotlivé programovací jazyky, ale ze zkušenosti vím, že jediná použitelná data pro nějaké sledování ve firmách jsou historická data dané firmy. A i ty jsou použitelné pouze tehdy, když existuje manuál pro správné programování, dokumentaci, testování apod. Bez něj jsou výsledky od různých programátorů, analytiků či testerů neporovnatelné. I proto jsem se po ničem moc nepídil.

Spíš mi jako užitečné přišly např. pro metriky testování teoretické křivky (Rayleigh curve, S-curve), které předpovídají vývoj chyb podle matematického modelu rozložení chyb. Když se podle historických dat nastaví správně parametry, tak jsou podle mě docela použitelné.


Jaký je Váš postoj k personálním agenturám? Poskytují dle Vašeho mínění externí firmy kvalitní služby?

Sám teď jedné firmě pomáhám ualožit nový SW tým a zavést v něm procesy CMMI. Sice nejsem primárně odpovědný za nábor lidí, na to mají vlastní HR, ale s výběrem pomáhám. Překvapilo nás, kdo všechno je schopen tvrdit, že má kvalifikaci odborníka, aby podrobnější pohovor ukázal, že ji nemá. Přitom i CV má řadu projektů, kde se k podobné práci hlásí. Hodně se nyní projevuje nedostatek lidí v minulých letech, kdy se na odborně náročné pozice dostávali lidé, kteří na ne ve skutečnosti neměli potřebné znalosti a zkušenosti. Teď už se považují za odborníky s praxí, ale při pohovoru se ukazuje, že mají jen povrchní zkušenosti, ale chybí jim teoretické základy i důkladné porozumění práci. A to jsou věci, které neodhalí personální agentura, leda že by měla skutečně odborníka na danou profesi. Takových ale mnoho není (přesněji řečeno, takové neznám). Závěr tedy pro nás je, že přímý kontakt je účinnější a agentura za nás nezajistí efektivní filtr.