Na této stránce píšeme 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. 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.
Vetšinu 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.
All about the business analysis, project management and software process improvement.
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) {?}
...
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.
Chci Vás požádat o stručnou informaci. Potřebuji vědět, zda existuje (příp. kde ji nalézt, stáhnout...) adresářová struktura pro řízení projektů.
Předpokládám, že adresářovou strukturou myslíte skutečně adresáře na disku ať už lokálním projektového manažera nebo sdílenou projektovou kancelář na serveru.
Neexistuje obecně platná struktura vhodná pro každý projekt. Vždy se využívá struktura odpovídající oblastem, které je třeba v projektu třeba řešit. Dále záleží na firemním standard. My např., když ve firmách vytváříme pravidla projektového řízení, tak standardně v každé projektové kanceláři máme složky _Rizeni-projektu, _Archiv, _Contract (ten má často omezený přístup pouze pro lidi, kteří vidí do kontraktů), někdy také _Audit (podle pravidel firmy). Další složky už se řídí činnostmi.
Např. když se podíváte na poslední příspěvek v našem blogu (http://www.pdqm.cz/Blog/Blog-List.html) , tak tam je obrázek konceptu jednoho projektu ve formě myšlenkové mapy a podle ní jsou i složky v projektové kanceláři: Zrizeni-pobocky, Lide, Prace, ? taková struktura by ale pro jiný typ projektu byla samozřejmě nesmyslná, nenapadá mě mnoho projektů, ve kterých bych měl složku Práce :-)
