Archiv rubriky: Práce, programování

někteří lidé se živí v průmyslu, někteří v zemědělství, někteří ve službách a já blázen jídlem …

Jednání … kdo ho má vyvolat?

Podobně jako pozdrav, usednutí, podání ruky má i samotné jednání nějaká pravidla, která jsou stanovena částečně zvyklostmi, částečně společností (firmou, okolím, …). Asi každý se jistě dostal do situace, kdy zaváhal, jestli má být tím, kdo začne/vyvolá jednání o nějakém problému. Nicméně ten první bývá v mnoha případech znevýhodněn – nebo naopak. Zjevně tím dává najevo, že má na řešení zájem, často, že ho potřebuje řešit co nejdříve, … to může být nevýhoda, ale někdy i výhoda. Podívejte se třeba, jak často rozhoduje, kdo první položí na stůl otázku platu – ten, kdo jako první „odpoví“/řekne svojí představu nastavil laťku, ten druhý se jí již bude snažit posunout jenom tam, kam potřebuje, na druhou strnu už to bude mnohem obtížnější. Proto při přijímacích pohovorech personalista/přijímající tuto otázku pokládá poměrně brzo, místo toho, aby sám s návrhem přišel. Berme to jako ukázkový příklad – tedy dohoda o platu mezi zaměstnancem a zaměstnavatelem. I zde existují úhybné manévry – v okamžiku odsouhlasení platu, kde má zaměstnanec pocit, že to šlo až podezřele snadno (málo se ocenil) lze následně jednat o to tvrději o jiných benefitech. Nebo naopak, pokud přestřelil, pak lze přejít k benefitům a s platem couvat, protože „s tímhle jsem nepočítal“. V každém případě doporučuji soudnost a navrhnout něco, co se v okolí vyskytuje, něco co víme, že máme reálnou šanci získat jinde, …

Ale to byla odbočka – k té prvotní otázce, kdo má samotné jednání vyvolat … pravidlo je jednoduché – ten, kdo v daném okamžiku má z rozdílu „úspěšné jednání“ x „nejednání/neúspěšné jednání“ větší profit. Takže pokud umíte něco, co je jedinečné, ale nový zaměstnavatel nabízí o 5% vyšší plat, s tím, že jiného asi nesežene, je na něm, aby začal. Pokud naopak cítíte, že jste jeden z mnoha a nové místo Vám přinese velký bonus, neváhejte a oslovte zaměstnavatele sami. Podobné je to samozřejmě u změny platu – pokud cítíte, že máte šanci na lepší pozici jinde, neváhejte oslovit zaměstnavatele a říci si o víc, stejně tak ale zaměstnavatel musí zvážit, jestli by případným odchodem zaměstnance hodně neztratil a v tu chvíli s ním jednat aktivně.

V každém případě musí být jednání férové a čestné – při jednání o platu i o místu jednají dva „obchodní“ partneři – jeden nabízí svoje schopnosti (práci) a chce za to zisk (peníze), druhý chce práci a nabízí zisk (peníze). Žádná podřízenost v tu chvíli neplatí – něco mám a něco chci, ty jsi na tom stejně => jednáme jako rovný s rovným. Ne namyšleně, ne ustrašeně. Ta jako zaměstnanec bez práce je nezaměstnaný a má problém, stejně i zaměstnavatel bez zaměstnanců má problém. Ostatně generál bez armády má většinou menší hodnotu než prostý voják, protože umí „jen“ velet, ale nemá komu.

Staré projekty

Asi každý, kdo podnikal má nějaké historické projekty, které jsou v různých stádiích – některé jenom „v šuplíku“, tedy  ve stádiu úvah, třeba zjištění prvních informací o trhu, … Další třeba započal, udělal si rozpočty, koupil doménu v případě webových projektů, ale prostě málo času, nebo nedostatek nadšení pro ně způsobil, že opět nepostoupily dál. No a určitě je i pár takových „otazníků“ – použijme terminus technicus BSC matice – tedy projekty, které započaly, nějak si žijí, není čas/chuť/síla se o ně starat a je to takové „třeba se k tomu někdy vrátím, třeba ne“, možná se to rozjede samo, nebo až dokončím něco důležitějšího (často výnosnějšího).

Má smysl se k těmto projektům vracet? Má cenu je udržovat? Zrovna nedávno jsem udělal menší inventuru – mám pár věcí, u kterých bych určtě věděl, jak je pošťouchnout dopředu, ale prostě čas na to není. Pokud má někdo zkušenosti s projekty, které takto po letech otevřel a začlo se jim dařit, svěřte se.

Můj soukromý názor je, že 90% podobných projektů nikdy nedospěje dál, ale pokud je energie na jejich udržení minimální, nebo nulová, asi nemá smysl je hned rušit. Na druhou stranu by si asi měl každý stanovit hranici – pokud se k projektu nevrátím po dobu řekněme 5 let, asi nemá smysl ho „udržovat ve stádiu hibernace“.

projekt knihovna -požadavky x Use Case x Use Case diagram

Když už jsme si připravili Use Case diagram (a není ještě úplný), měly bychom si říci, jaký je vlastně rozdíl resp. vztah mezi požadavky, Use Case a Use Case diagramem. Čtenáře poprosím o schovívavost, ale budu používat anglický termín Use Case namísto českého Případy Užití, který je i u nás obecně používaný a nechci být jazykový puritán.

Takže shrňme si to:

Požadavky

Jsou seznam operací, které bude systém provádět, respektive, které budou jednotliví uživatele používat, většinou by mělo být alespoň trochu popsáno o co jde (často jen slovně) a kdo činnost provádí/má k ní oprávnění.

Diagram Use Case

Obsahuje jednotlivé uživatele/role (Actors) a procesy (Use Cases) s naznačením, co kdo má oprávnění provádět. Zde již je vidět jistý náznak objektové hierarchie – mezi uživateli se často používá vztahu generalizace. Což je vlastně zobecnění, tedy „nadtřída“ a naopak vztah specializace, což je potomek, tedy podtřída. Mezi procesy pak existují vztahy <<include>> a <<extends>> – píše se na šipku spojující procesy (Use Case-y, jestli to tak mohu skloňovat) a vede směrem k případu, který se v tom prvním používá – tedy například šipka s include vede od rezervovat knihu k procesu najít knihu … když chceme knihu zarezervovat, musíme jí předtím najít – velmi často je proces ke kterému vede vztah <<include>> sám o sobě nepoužitelný. Spojení extends je méně časté a ukazuje rozšíření dané funkce, případu, které nemusí vždy nastat – při přidávání knihy bychom mohli zakládat kategorii (žánr), ale to jenom tehdy, pokud by již daný žánr neexistoval … Určitě sek tomu při zpřeňování ještě dostaneme.

Use Case – Případy užití

A konečně poslední varianta – není to graf, ale seznam jednotlivých Use Case, spolu s popisem jednotlivých kroků a jejich odpovědností – vhodné je pro popis používat jistý pseudokód – ať už anglický, nebo čestký, tedy „když/if, jinak/else, dokud/while …“ nejdůležitější je abychom myi zákazník popisu rozumněli.

Nejjednodušší je asi zápis do tabulky

Rezervování knihy
krok role popis
1 uživatel vyhledání knihy
3 uživatel/knihovník IF knihovník
2.1 knihovník – vyhledat uživatele
2.2 knihovník END
3 system ověřit stav uživatele
4 system IF uživatel není zablokován
4.1 system – založit rezervaci knihy
4.2 system END

Všimněme si jedné drobnosti – v tuhle fázi často ignorujeme stavy kniha nenalezena, uživatel nenalezen – většinou procházíme typické scénáře. Na výjimky/speciální případy bude snad čas později. Jde spíše o to si popsat s uživatelem standardní běh systému.

Projekt knihovna – Use Case

Protože jsme si posledně definovali požadavky a kreslili si je do grafu podobně jako Use Case, jediné co nyní potřebujeme je uvědomut si – spolu s uživatelem, kdo jaké dělá/používá. Identifikovali jsme čtyři možné role – host, uživatel, knihovník a administrátor. Tak jim tedy přiřaďmě jednotlivé akce – zde je určitě prostor pro diskuzi se zákazníkem, protože na něm je určit, jestli host smí prohlížet seznam knih, uživatel si sám půjčit knihu, …

Výsledný UML diagram vypadá následovně:

Use CaseJestli se ptáte, v čem je diagram vytvořen, je to IDE NetBeans, aktuálně v 6.7. Volba prostředí již asi i přeurčuje, kam budu dále směřovat a jaké možnosti budeme mít.

Projekt knihovna – zadání … požadavky

Po nějaké době (resp. po kurzu) se vracím k projektu knihovna – vzhledem k tomu, že se snažím vpravit se do projektového řízení, rozhodl jsem se „začít znovu“ a vyzkoušt teoretické znalosti a poučky v praxi.

Takže od začátku

No jak začít – asi tím, že nás někdo osloví tím, že potřebuje vyřešit nějaký problém. Řekněme tedy, že přijde někdo (proč ho nenazývat zákazníkem) a chce asi následující:

„Víte, potřebovali bychom evidovat/zlepšit naší knihovnu. Zdá se mi, že systém lístků pro jednotlivé knihy není to nejlepší a strašně špatně se zjišťuje, co máme a případně kdo to zrovna má, případně co všechno má někdo půjčeno. Chtěli bychom, aby se uživatelé mohli zaregistrovat přes síť, ale pak je ještě vlastně někdo musí potvrdit a ověřit, že zadali údaje správně. Měli by mít možnost si prohlídnout naše tituly a případně jestli je půjčený, nebo v knihovně. No a samozřejmě musí jít si knihu půjčit a zase vrátit – to dělá naše knihovnice. Ta se taky stará o seznam knih – edituje je, přidává a případně maže, když se nějaká ztratí, nebo se již opotřebuje. Ta taky posílá upomínky, ale to bych řešil asi až později. A taky si členové – myslím tím registrovaní uživatelé – mohou knihu zablokovat, aby ji knihovnice dala stranou, když se ta kniha vrátí. Občas taky musím někoho zakázat – protože třeba nevrátil knížky a nemůžeme ho normálně sehnat.“

Asi každého napadne sáhnout po nějaké hotové aplikaci, ale to by nebylo o čem psát (možná o výběru, ale to nechci), takže proč se do toho nevrhnout. Nejprve se zamysleme nad požadavky, které z tohoto textu plynou … nakreslil jsem je do následujícího grafu, abych už rovnou směřoval k USE-CSE (případy užití) diagramu … určitě se k němu dostaneme příště, stejně jako k třídám a balíčkům.

library_requirements

Projekt knihovna

Dlouho jsem tak procházel programy a jejich zdrojové kódy a stále mám pocit, že objektové programování se sice prosazuje, ale čistých objektových modelů je v reálném světě stále dost málo. Zkusím tedy napsat jednoduchý prográmek objektově a popsat postup řešení + snažit se co nejvíce používat moderní nástroje …

Takže projekt knihovna (webová aplikace) může začít …