Softwarová sebevražda

Často jsem lidem říkal příběh o tom, jak moc špatně to může dopadnout, když vývojáři aktivně vytvářejí technický dluh a business lidé tlačí na přidávání dalších a dalších nesmyslných funkcí. Svou oblíbenou hlášku „… a jednoho dne přijde okamžik, kdy pro samý technický dluh nebudete schopni provést ani trivialní změnu aplikace a veškerou energii budete pálit na fixování defektů.“ jsem bral jako záměrně přehnanou nadsázku. Dokud jsem neměl tu čest spolupracovat se společností Sinking Ship, s.r.o…

sinking_ship

Nasledující řádky popisují reálnou situaci v reálné společnosti. Přesto, že celý příběh může působit lehce apokalypticky, popisuji zde pouze skutečné situace tak, jak jsem jim byl svědkem. Doufám, že nikdo z vás, kdo tento článek čte, v podobné situaci není. Je ale možné, že některé jednotlivé problémy se objevují i ve vaší společnosti. Berte to, prosím, jako popis stavu, ve kterém můžete skončit, když budete problémy příliš dlouho ignorovat.

Společnost Sinking Ship s.r.o. se svojí dlouhodobou obchodní a technologickou strategií dostala do bodu, ve kterém skutečně veškeré usílí vývojářů primárně končilo na hašení urgentních problémů. Vytížení bylo tak velké, že zde už nezbýval žádný čas na jakákoliv systémová řešení. Alespoň podle lidí, kteří tam pracovali. Občas se podařilo managementu protlačit požadavek na nějakou featuru. Ta ale byla vždy do aplikace víceméně vhackována a stala se zdrojem nových problémů. Obvykle okamžitě poté, co byla poslána do produkce. Stav věcí byl všemi technickými pracovníky přijat jako standard a pocit, že to jsou právě oni, kdo hrdině hasí požáry, v nich dokonce vytvořil pocit absolutní nenahraditelnosti a heroismu. Stali se odborníky na chaos, který každým dnem rozšiřovali.

V průběhu práce s touto společností jsem zachytil několik vzorů v přístupu a myšlení celé společnosti a některých důležitých lidí. Seznam vzorů není úplný. Popravdě byly jich desítky. V tomto článku zmíním pouze takové, které jsem potkal i u jiných projektů.

pattern #1

„Není na to čas“

Asi nejpopulárnější a nejvíce opakovaná hláška software vývojářů na téměř cokoliv smysluplného, co by měli dělat, ale nedělají.

„píšete testy?“ „ne, na to není čas“

„děláte code review?“ „ne, na to není čas“

„zkoušeli jste automatizovat deploy process?“ „ne, na to není čas“

„děláte retrospektivy“ „ne, na to není čas“

a tak dále…

Důvodem, proč na nic nebyl čas, byla potřeba řešit urgentní problémy a defekty nebo hláška, že management stále tlačí pouze na nové featury. Krásná ukázka toho, že když řežeme dříví tupou pilou, tak pro samé řezání nemáme čas pilu nabrousit.

Po krátké době jsem přišel na to, že čas není jen na ty vzletné aktivity jako je psaní testů, ale že jaksi chybí i na to, aby se dodržovaly základní pravidla psaní kódu, commit hlášek a prodiskutování práce s ostatními kolegy. To logicky pouze zvyšovalo počet defektů a celý kolotoč nabíral na velikosti a otáčkách.

Neschopnost kohokoliv z vývojového týmu tento hloupý cyklus zastavit a zamyslet se nad ním, byla asi problémem číslo jedna. Bohužel, nebyl na to čas…

Proč tuto zodpovědnost podsouvám lidem z vývojového týmu? Protože business lidi budou vždy primárně tlačit na pilu, budou vždy chtít nové featury a budou je chtít rychle. Ve firmě, která vydělává peníze na psaní software je úkolem software lidí business lidem vysvětlovat, proč je důležité psát kód kvalitně, investovat čas do psaní testů a refactoringu. Toto je ale téma na samostatný článek.

pattern #2

Náš system je moc složitý a speciální

Kdysi jsem slyšel hlášku, že každý národ si myslí, že právě jeho jazyk je ten nejsložitější na světě. Asi to vychází z faktu, že lidem dělá dobře, když jsou něčím speciální a zvládají něco obtížného. Podobný přístup jsem pozoroval u spousty software společností. Jejich vlastní produkt byl vždycky velice komplikovaný a plně chápat ho mohlo jen pár vyvolených – většinou těch, co stáli u jeho zrodu nebo těch, co ve firmě strávili podstatnou část svého života.

Lidé v Sinking Ship s.r.o. to viděli úplně stejně. Možná ale vlastně ne, jako téměř se vším, měli pocit, že jejich systém je ještě více komplexní a ještě více složitý.

Sinking Ship s.r.o. začala svůj business od píky. Lehce inspirováni někým, kdo už na trhu byl, začali vytvářet službu, která dodavatelům banánů umožnila najít odběratele banánů. To je v principu vše. Nebylo to strukturální lodní inženýrství, neposílali družice do vesmíru, nezkoumali DNA. Vytvořili databázi banánů s přístupem přes web. Nechci snižovat složitost prodeje banánů, ale chci se dostat k jádru věci. Složitost nebyla ve službě, kterou doručovali svým zákazníkům, ale v tom, jak systém navrhnuli a divoce a neřízeně rozšiřovali. Složitost tedy byla 100% v implementaci, způsobená nedostatkem zkušeností, vědomostí, disciplíny, odkládáním jakýchkoliv systémových změn či prostého zamyšlení nad tím, jestli to, co a jak dělají je užitečné.

Katastrofy jsou často výsledkem několika problémů, které se sejdou ve stejný okamžik. Tato souhra ale nemusí být náhodná, určitě se mnou budete souhlasit, že pattern #1 úzce souvisí s patternem #2.

Nedostatek času samozřejmě nedovoluje vývojářům, aby se zdokonalovali ve svém oboru, zkoušeli si nové technologie, postupy a nástroje.

Ponaučení, které plyne z patternu #2 je zjistit, zda-li složitost tkví v službě, kterou software doručuje nebo v tom, jak je software napsán.

pattern #3

Ti noví tomu nerozumí

Stejně jako problém složitosti systému byl tak nějak produktem nedostatku času, tak i pattern #3 „Ti noví tomu nerozumí“ je logickým výsledkem uměle vytvořené složitosti systému.

Osobně si myslím, že tento vzor je ale obzvášť záludný a nebezpečný. Důvodem je fakt, že rozděluje lidi na skupinu nových nezkušených a starých moudrých, ale strašně vytížených.

Ale nechme obecné hlášky stranou a pojdmě se podívat na Sinking Ship s.r.o.  Bylo tam samozřejmě několik zkušených matadorů, kteří stáli u kolébky rodícího se projektu. V prvních bouřlivých letech obětovali práci na projektu všechno a všechno technické přišlo skrze ně. Jako každý startup se dostali do bodu, kdy zjistili, že by se všechno mělo nějak víc začit organizovat, a že by bylo dobré přijmout nové lidi. Jenže už v té době byli zkušení zaměstnanci natolik vytížení látáním děr v aplikaci, že neměli čas nové zaškolit. Něměli ani čas jim vysvětlit, jak systém funguje, z čeho se skládá, kdo je za co odpovědný. Noví lidé přicházeli a po krátké době odcházeli plni frustrace z toho, s čím se to vlastně potkali. Případně byli vyhozeni, protože po několika týdnech nebo měsících v kanceláři nic neudělali. Otázkou, proč nic neudělali, se nikdo nezabýval. Nebyl na to čas…

Opět zde byl krásný cirkulární systém, noví lidé přicházeli a odcházeli. V očích těch starých zkušených byli k ničemu a proto pro ně nemělo žádný smysl se jim věnovat. Byla to ztráta času…

pattern #4

Upřímní vyjebávači

Nerad užívám sprostá slova, ale jedno sprosté slovo občas vydá za tisíc slušných. Z výše uvedeného textu byste mohli nabýt dojmu, že ti starší a zkušení vývojáři jsou tak trochu chudáci, co se udřou a co pro firmu udělají první i poslední. Bohužel nejsou. Oni totiž vědí, že dělají svou práci špatně. V dnešní době je pro jakéhokoliv vývojáře téměř nemožné, aby alespoň jednou neslyšel nebo nečetl o věcech jako je clean code, test driven development a tak dále. Zároveň vědí, že rozkopírovávání kodů dál a dál, nesmyslně dlouhé metody, promněné nazvané hello1, hello2, atd. věci jen dál zhoršují.

Proč ale vyjebávači? Protože kdykoliv si sedli s kýmkoliv z obchodníků nebo product managerů a ti po nich chěli edukované odhady, například jak dlouho bude určitý projekt trvat nebo jak moc složité je implementovat nějakou featuru, nebyli upřímní. Ani nemohli. Upřímnou odpovědí vysvětlující, proč i relativně jednoduché projekty trvají tak dlouho, by si sami připravili půdu na to, aby byli vyhozeni. A tak vznikaly různé příběhy, proč něco nejde, proč něco bude trvat hrozně dlouho a tak dále.

Pozor, nezapomeňte, že zde popisuji příběh vývojářů Sinking Ship s.r.o.

Jako konzultant jsem se dostal do pozice, kdy bylo mou povinností své poznatky reportovat managementu. Věřte, že to byla role velice nepříjemná a vytvářela atmosféru emočně velice turbuletní. Pokud jsem si já osobně z celého konzultačního projektu něco odnesl, tak to byl poznatek, že s tímhle se musí pracovat v rukavičkách a s jemností pyrotechnika zneškodňujícícho starou a hluboko uloženou bombu.

pattern #5

Pojdmě to dát do cloudu

Outsourcujeme a nakupujme. Pokud vytváříte aplikaci, která je technicky špatně implementovaná a speciálně pokud tato aplikace zpracovává větší objem dat pomocí databáze, problémy s výkonem vám brzy zaklepou na dveře.

Sinking Ship s.r.o. byla v takové situaci. Prodej banánů je jednoduchá věc, ale banánů se prodává opravdu hodně. Sinking Ship s.r.o. měla velkou část aplikace implementovanou přímo na databázové úrovni. Protože datový model byl extrémně špatně navržen a divoce se rozšiřoval a implemetace databázového API byla ještě horší, problémy s výkonem se řešily každý den. Buď byla služba pomalá nebo nefungovala vůbec. To ale není to, o čem tady chci mluvit. Co bylo zajímavé, bylo to, jak se k tomu stavěli všichni technicky orientovaní zamětstnanci a jak to bylo prezentováno ostatním.

Hlavním důvodem pomalosti podle nich byla samozřejmě extrémní složitost jejich aplikace – pattern #2. Druhým důvodem pak byly neustálé DDoS útoky ze strany konkurenčních firem. Jako nezávislý konzultant a zároveň člověk, který se problematikou DDoS útoků poměrně dlouho zabýval, jsem bohužel nenašel žádné důkazy, že by takový útok probíhal. Viděl jsem requesty přicházející na servery, které byly příliš pomalé na to, aby je stačily obsluhovat. Myslím si, že vývojáři a sysadmini to věděli, také věděli, že jejich databáze má zásadní problém na úrovni datového modelu. Podle patternu #4 – upřímní vyjebávači ale zásobovali vedení příběhy o DDoS útoku, o potřebě nakupování lepšího hardware, prací na pseudo-projektech vlastní implementace partitions na úrovni databáze. V neposlední řadě pak byl připravován plán migrace databáze do cloudu s pocitem, že tam to poběží určitě rychleji.

Faktem, že nákupem nového hardware pro databázi zlepšíte odezvy třeba čtyřikrát, zatímco změnou datového modelu tisíckrát a více, se nikdo nezabýval. Na změnu datového modelu nebyl čas a nákup hardware a migrace na nové železo byla mnohem snazší.

Úžasné bylo, že na diskuze o těchto zástupných problémech a o plánech, jak je řešit, si čas, i přes svou obrovskou pracovní vytíženost, našli. Závěry diskuzí nikdy neadresovaly hlavní příčinu problému a většinou vyústily v utrácení nemalých peněz, za věci, které vlastně nepotřebovali a které dále zvyšovaly komplexnost celého systému.

Management technickým pracovníkům plně důvěřoval, peníze se utrácely, a problémy s výkonem stále zůstávaly. Nikdo se nad tím ani moc nepozastavoval a vždy se našel nějaký dobrý důvod, proč se nic nezlepšilo.

pattern #6

Jsme agilní až to bolí, au…

Sinking Ship s.r.o. o sobě ráda tvrdila, že je mladou a velice agilní společností.  Anna byla tahounem agilních ideí. Byla to ona, kdo v minulosti přišel s tím, že chaos musí dostat nějakou formu a musí se pracovat podle nějaké metodiky. To je dobrá idea, jenže Annino pojetí agilního vývoje se stalo dokonalou škatulkou na kocourkovatost celé firmy.

Vybrala Scrum, vypracovala metodické příručky, harmonogramy. Zavedla sprinty a obvyklé rituály jako jsou každodenní standupy, dema, restrospektivy. Všechny nástroje byly na místě… tedy většinou když na to byl čas. To byl první problém. Mít standupy se jim, jako všude, tak nějak docela i dařilo. Retrospektivy naopak byly pořád odsouvány. To ale nebyl ten největší problém. Ten tkvěl v tom, že všem rituálům chyběl skutečný obsah, skutečná komunikace, upřímnost a nikdo nechápal jejich smysl. Nástroje jsou dobrá věc, ale pokud vám uniká princip jejich použití, moc vám nepomůžou.

A tak vývojáři na standupech říkali věci, které chtěla Anna jako scrummaster slyšet. Ona si pak mohla zaškrtnout položku kolečko splněno a pokud si dobře vzpomínám, dokonce to zapsala do jejich wiki systému. Na kolečku nikdy nikdo nemluvil o skutečných problémech, nikdy vývojáři neříkali věci svým kolegům, pouze reportovali Anně. Anna pak s jejich pomocí plánovala Sprint Part #1, Sprint Part #2, Sprint Part #3 a tak dále a nikomu nepřišlo nic divné. Místo odhadů času zbývajícího trackovali čas odpracovaný a nedokončená práce se přelévala z jednoho sprintu do dalšího a tak dále.

Nejroztomilejší byly okamžiky, kdy jsem zmínil, že některé procesy by šly vylepšit. Odpověď byla jednoznačná: „všechno už máme a všechno děláme spravně„. Přesně podle příruček od Anny. Agilní a iterativně smýšlející firma odrazila jakoukoliv možnou změnu s razancí baseballové pálky.

pattern #7

A kde byl management?

Celé to pusobí dojmem, že na vině všemu byli pouze vývojáři. Ale není tomu tak, hlavní příčinou problému byl management společnosti. Nebo spíše fakt, že management ve společnosti Sinking Ship s.r.o. vůbec nebyl. Zodpovědností manažerů je udávat směr, řídit, kontrolovat, motivovat a tak dále. To se ale v Sinking Ship s.r.o. nedělo, místo toho management  vytvářel klamný dojem rodinné atmosféry a pohody. Jsem velkým příznivcem horizontálně uspořádaných společností, svobodných firem, agilních projektů, je ale velice důležité uvědomit si, že alternativní modely řízení je možné aplikovat, pokud je striktní hierarchický systém kontroly nahrazen jiným modelem a principy, například osobní disciplínou a kompetentností jednotlivých zaměstnanců. Pokud tomu tak není, nemluvíme zde o funkčním systému, ale neproduktivním chaosu.

V návaznosti na tento článek jsem nedávno jsem sepsal zamyšlení nad agilním managementem a častých chýbách v jeho zavádění a důležitosti Product Ownera jako člověka, který definuje smysluplnost existence firmy.

Pár slov na konec

Název společnosti Sinking Ship s.r.o., stejně jako logistika prodeje banánů jsou smyšlené. Vše ostatní je popis existující společnosti, která se vypracovala z malého startupu na společnost se zastoupením v mnoha zemích a vývojovým týmem distribuovaným do několika geograficky oddělených lokalit. Přestože celý článek vyzněl nejspíš hodně negativně, je zde jedna opravdu obdivuhodná věc – schopnost takových společností prodlužovat svoji agonii…

V tomto článku nechci hledat a popisovat řešení jednotlivých problémů, spíše jsem chtěl vypíchnout vzory, které možná můžete pozorovat i u sebe. Protože v Sinking Ship s.r.o. bylo vše dovedeno do extrému, berte to jako popis toho kam až ignorování některých neduhů může vést. Cesta ven z této situace existuje, jen je potřeba jí dát prostor a alespoň část lidí musí být ochotna měnit už zaběhlé vzory chování.

 

Článek je k dispozici i v anglické verzi na www.softwaresuicide.com

 

Úvodní obrázek „Sinking Ship“ od Billa Fredericka, http://williamlewisfrederick.com/  – Thank you!

 

 

 

 

 

 

Advertisements

28 thoughts on “Softwarová sebevražda

  1. Jirka napsal:

    Chybí mi jen rozuzlení zápletky, zda firma zkrachovala, byla odkoupena nebo je stále v agonii. Sám jsem v podobném prostredí pracoval, tak mi ukápla slza. Nejhezcí na tomto stavu je, že takovéto firmy nám ostatním dávají práci.

    • martinpavlas napsal:

      Právě probíhá akvizice jinou společností. Popis toho, co se během této transkace děje, by si zasloužil samostatný článek.

      • Thom napsal:

        Velmi zajímavé čtení, děkuji.
        Máte v plánu napsat i o té akvizici?
        Měl byste, prosím, doporučení na nějakou vhodnou literaturu, která se podobným vzorcům pracovního chování věnuje? Hlavně, aby tam byly také ty správné;)

      • martinpavlas napsal:

        Průběh akvizice rozhodně zajímavý je. Kupující rozhodně podcenil due diligence v oblasti kvality software a lidí. Z toho teď vzniká spoustí zláštních situací. Napsání článku zvážím.

        Existuje spousta dobrých knih, ale asi záleží, jestli vás zajímají ty orientované speciálně na vývoj software nebo obecné. Naslepo bych doporučil „Lean software development“ od Tom & Marry Poppendieckových ze sw oblasti a cokoliv od Stafforda Beera pokud to má být obecné. Ale je to výstřel od boku. Kdyžtak to upřesněte.

  2. Kolisko napsal:

    Hezkej článek.
    Připomíná mi to úvodní zapletku výborný knihy The Project Phoenix – pohádky o tom, jak jeden IT guy napravil IT oddělení a tím zachránil celou firmu. I když je to pohádka, je v ní spousta nápadů k zamyšlení a tipů jak z toho bahna ven. Určitě stojí za přečtení.

  3. Karl napsal:

    Ahoj, Sinking ship s.r.o. mi napadne pripomina jednu spolecnost pro kterou jsem pracoval. Management tlacil na vytvareni funkcnosti, kterou by mohli prodavat, vrsily se bugy, ktere bylo nutne okamzite resit, ale refactoring v nedohlednu. Ted uz se situace trochu lepsi – management byl nucen uznat, ze soucasna situace je dlouhodobe neudrzitelna a posvetila zasadni zmeny v navrhu. Styl „potrebujeme neco noveho, co muzeme prodat“ ovsem zustal.

    • martinpavlas napsal:

      ano, dost často se firmy pokouší zlepšit pouze to, jak pracují software lidi. Management a business lidi si dál jedou podle svých zajetých kolejí. Tohle běžný problém při zavádění agile. Nevede to k dobrým koncům. Pracujte na tom, aby postupně došlo ke změně i v tom, jak fungují business lidi. Na tom, že chtějí něco nového, co se bude prodávat, není nic špatného. Otázkou je:

      – jestli se to skutečně prodávat bude
      – kdo a proč to chce
      – kolik to bude stát (peníze, energie, frustrace)
      – jestli to musí být být hned od začátku komplexní mega-featura
      – jestli sliby, které dávají jsou reálné a s někým konzultované
      – atd, atd.

      Důležité je uvědomit si, že speciálně malých SW firmách se musí minimalizovat tření a řevnivost mezi software a business lidmi. Já osobně to chápu jako jeden z největších a nejběžnějších problémů.

      Nechci ale zobecňovat, v každé firmě je to jiné a musí se vždy řešit konktrétní situace v konkrétním kontextu.

  4. Tohle je parádní čtení, dal bych do osnov povinné četby 🙂 Vždycky jsem myslel, že tyhle příklady jsou jen hyperbola, varování před tím co se může stát, je trochu smutný vidět, že neni.

  5. Tomáš Kapler napsal:

    no osobně bych to tipnul na nějakou firmu z těch, které se teď spojují – czc, heuréka …

    • martinpavlas napsal:

      tyhle spekulace se začali kvůli článku množit 🙂 Sinking Ship a ani kupující firma nejsou české firmy. Dokonce ani v jedné nepracoval žadný čech.

  6. Petr napsal:

    Čtivě napsané, díky! Většinu paternů už bohužel znám… A párkrát se to i povedlo narovnat. Ale bolelo to 🙂

  7. Ondra napsal:

    Super článek, co k tomu dodat, je to asi všude stejné 😀

    • martinpavlas napsal:

      Dobrý den, není to všude stejné. Naštestí jsou firmy, které tento bludný kruh opustily. O tom, jak z toho ven , budu psát v následujících článcích.

      • Martin R. napsal:

        Na články o tom, jak z toho ven, se těším a zároveň jsem zvědav, jak se moje představy o návrzích na zlepšení budou/nebudou lišit. Podobné situace se dají pozorovat i v mimo IT prostředí, jen škoda, že se vedení i po několika mnoha připomínkách nechtělo zaměřit na „léčení“, ale stále navrhovalo nové projekty…

  8. shortiest napsal:

    Dobrý den,
    článek se mi líbí a u nás ve firmě, na některých odděleních, vidím podobnou situaci a podobné typy pracovníků. Mohu, s Vaším dovolením, tento článek citovat na našem interním blogu?
    Děkuji
    Leoš K.

    • martinpavlas napsal:

      Dobrý dne, ano, samozřejmě citovat můžete. Když tam zmíníte, že citace pochází z think-forth.com, budu rád. Zvažte, čeho chete citací docílit a v jakém kontextu bude uvedana. Pokud by byla pojata pouze jako kritika kolegů nebo celého prostředí, celé věci to asi moc nepomůže.

      • shortiest napsal:

        Nejde mi o rýpání, ale o to, aby se zodpovědní lidé zamysleli a snažili se nás směrovat k otevřenosti a upřímnosti a k ohlédnutí se zpět na chyby, ze kterých se můžeme poučit. To se neděje a tak je projekt za projektem stále stejný, bez posunu a ponaučení se…
        Děkuji za svolení, článek sdílím.

  9. Jenny napsal:

    Uzasny clanok, hovori mi z duse. Nanestastie, Sinking Ship by som kludne mohla nahradit menom sucasneho projektu… 😦 Nahodou v anglictine by to nebolo?

  10. Pavel Franta napsal:

    Hezky napsaný článek. Prakticky stejné je to i ve firmách zabývajících výrobou a prodejem čehokoliv jiného. Stejné manýry managementu. Stejné výmluvy výroby.

    Nejsem vůbec překvapen tímto příběhem. A zároveň nemohu ani odsoudit všechny v popisované firmě jako hloupé lidi a programátory za vyjebávače. Prostě jim to uteklo, ale co teď když mě to může stát židli a nejsem přesvědčen o tom, že jsem jediným viníkem ?

    Kolik lidí se chová ze stejných obav ze ztráty jako dobytek i v osobních životech, natož v práci ?

    V téhle fázi už prakticky neexistuje cesta ven. Všichni už jsou uvařeni a musejí být buď nahrazeni a nebo ve stejný moment všichni dostatečně šokování nějakým impulzem. Připomíná mi to hru ze serie Caesar. Dostanete se do bodu kdy už nestačí kanalizace, infrastruktura, voda… a co jako teď ? domy lemující silnici jsou již postavené, akvadukty jsou zavedené do těch domů. Takže když chci rozšířit silnici tak budu bourat domy ? A akvadukt zbořím a přeprojektuji nakonec celé město, protože mi nic jiného už nepomůže ?

    … exit > new game

  11. Miloš napsal:

    Podat hlášení managementu, na to jste se musel asi těšit. Připomnělo mi to knihu Richarda Feynmana „To nemyslíte vážně pane Feynmane“. Byl v Brazilii a měl ohodnotit výuku fyziky na univerzitě. Tak jim řek pravdu…

    Taky jsem si vzpomněl na technický dluh, který se táhl a táhla a nevím, jestli už je napraveny.

  12. Bill Frederick napsal:

    Sinking Ship, painting by Bill Frederick

  13. Teď koukám, že jsem napsal něco podobného, o technickém dluhu jsem psal už dřív, ale o jednom fatálním problému managementu až v červenci. Ten problém totiž dlouho nebyl vidět, vývojářům nedocházelo, že kapitáni jsou nevzdělaní šílenci. O kapitánech neměli nejlepší mínění, ale přeci jen se zdálo, že aspoň „nekazí“ a to, co dělají, má nějakou nesrozumitelnou manažerskou logiku. Opak byl pravdou.
    http://dmatej.blogspot.cz/2017/07/manday-neni-jednotka.html

    S technickým dluhem se bojovat dá, ale jak je zmíněno v textu – musí to pokrýt výdělek z nových vlastností produktu, které se už nesmí „prasit“. Je to náročné a drahé, bolí to, ale na druhou stranu pokrok těší, zvlášť některé větší „technologické skoky“.

    Co se nátlaku týče – jste experti, profíci; pokud jste experti, nemůžete odsouhlasit laikovi cokoliv ho napadne, i kdyby se tvářil jako váš šéf. Statik nebo projektant vám taky nepodepíšou cokoliv, za co by později nesli odpovědnost.

Zanechat Odpověď

Vyplňte detaily níže nebo klikněte na ikonu pro přihlášení:

WordPress.com Logo

Komentujete pomocí vašeho WordPress.com účtu. Odhlásit / Změnit )

Twitter picture

Komentujete pomocí vašeho Twitter účtu. Odhlásit / Změnit )

Facebook photo

Komentujete pomocí vašeho Facebook účtu. Odhlásit / Změnit )

Google+ photo

Komentujete pomocí vašeho Google+ účtu. Odhlásit / Změnit )

Připojování k %s

%d bloggers like this: