V nadpise dnešního článku cituji mého kamaráda, který začal pracovat jako project manager v softwarové společnosti, a který hlavně dosud většinu svého profesního života pracoval mimo jakýkoliv softwarový vývoj. Zřejmě zvyklý z jiných oborů, kde člověk na první pohled vidí, v jakém stavu je projekt, tak zde asi celkem narazil, protože dost často se během vývoje musí člověk spoléhat na to, co řeknou programátoři. A ze své zkušenosti vím, že odpověď na stav řešeného problému vždy vypadá hodně podobně - "Mám to už skoro hotové, jen musím ještě něco dodělat". Smutné je, že tato odpověď má většinou několik pokračování, kdy zní skoro stejně, jen se přidávají další přídavná jména a příslovce, aby to vypadalo, že už se konec opravdu blíží - "Myslím, že teď už budu mít skutečně většinu hotovou, jen ještě dopsat testy, ale to už je opravdu drobnost a neměl by to být žádný problém".
Je pravda, že každý project manager chce mít pocit, že má vše pod kontrolou, a že projekt postupuje podle plánu. Co ale určitě nemá rád, když dostává špatné a nepřesné informace - pak je nejistý, neví, zvláště když to není project manager, který si sám prošel vývojem. Nejhorší úplně je, když se programátor celou dobu tváří, že "žádný problém" a pár dní před koncem se zjistí, že se to nestihne.
Programátor má často mylný pocit, že bude "špatný" programátor, když řekne přesně stav věci, když snad přizná, že něco nejde podle plánu. Pokud programátor pracuje jak má a vždy říká věci jak jsou, tak se nikdy nemusí bát, že by on byl snad ten špatný. Programování je hodně o přemýšlení, o nalézání nových cestiček, o zkoušení nepoznaného, proto se prostě musí počítat s tím, že vždy vše nepůjde podle plánu. Ale je potřeba to říkát, komunikovat! Jeden kamarád hezky vyjádřil vývoj softwaru jako "interaktivní hru mezi vývojovým týmem a zákazníkem", kde komunikace a přímé jednání jsou nezbytností pro úspěch projektu.
Programátoři (zejména ti mladší) se hodně ženou po technologiích se snahou mít co nejvíce "buzzwords" ve svém životopise. Je pravda, že toto určitě zaujme, ale z pohledu vedení týmu bych často preferoval zcela základní lidské vlastnosti:
- přímé jednání, snažím se říkat přesně jak se věci mají
- když řeknu nějaký termín, tak udělám maximum pro jeho dosažení a pokud něco nestíhám, tak na to včas upozorním
- komunikativnost
- být otevřený, mít ochotu se učit novým věcem
Došel jsem k přesvědčení, že si mě firmy najímají kvůli tomu, že jim dokážu pomoci (což neznamená, že to musím vždy dělat já sám). Firmy jsou ochotny nadstandardně zaplatit, pokud mají problém a vy jim dokážete pomoci, ale vždy za předpokladu, že "co řeknete, tak to platí". Firma má často problémy se svými zaměstnanci a nemá vůbec potřebu využívat externistu, který jí nepřináší maximální užitek.
Příspěvky
19 komentářů:
To bude asi tím, že v programování se mnohem snáze určuje co je nutno ještě udělat a co se tam ještě objěví za problémy. Projektové řízení ve vývoji softwaru je tímto docela specifické.
Prave preto by mal mat skutocny projektovy manager aj cosi odprogramovane!
Ono plánovat programování je dost těžké, protože, co na první pohled vypadá jednoduše, se může rozrůst pod rukama. Uživatelsky složitá věc může být v pozadí celkem jednoduchá nebo se jen využije a dá dohromady to, co je hotovo.
A když už pracujete, najednou přijde překážka, překvapení. Pak dáte dotaz a zainteresovaní mají o čem přemýšlet. Často se člověk zasekne při ladění, něco funguje na první šlápnutí, až to překvapí.
Ja si osobne myslim, ze project manazer, ktery poradne nerozumi projektu, je jeden z nejvetsich omylu vyvoje. Podle me je vyrazne lepsi, kdyz existuje nekdo jako team-leader/manazer/architekt, ktery ma o projektu velmi dobre technicke znalosti a ma pod palcem i planovani, ktery presne ten neduh spolehani na programatory dokaze prekonat, protoze rozumi projektu jako celku.
Se vším souhlasím, ale článek byl směřovaný trochu jinam - nechci se vůbec zastávat project managerů, ale dost často je problém v samotných programátorech, že nedokážou přesně říci, v jakém stavu řešení jsou a pokud slíbí nějaký termín, tak je dost často nesplněn.
Na mnoha pozicích jsou lidé, kterým by více seděla jiná práce. Zde byl popsán případ programátora, který by měl spíš dělat obchodního zástupce.
To souhlasím, nicméně dle mých zkušeností by potom hodně přibylo obchodních zástupců. :)
Iterativní přístup podobný problém řeší, kontrolní body jsou často (fail early, fail often). U některých úloh bohužel nevíte, kdy budou, protože náročnost se vyjeví teprve při jejich podrobném prozkoumání.
Rovněž doporučuji článek Martina Fowlera http://martinfowler.com/articles/newMethodology.html
Pokud se projekťák nechá opít rohlíkem, že "už to skoro je", tak je to jeho chyba. Pokud sleduje postupný vývoj, tedy jednotlivé úkoly z pohledu náplánovaný versus strávený čas, počet hotových versus zbývajících úkolů, tak si svůj vlastní úsudek určitě udělá i bez technických znalostí. Pokud se ale přijde zeptat jednou za měsíc, jestli už to je hotové, tak je to pozdě i kdyby programátoři mluvili vždycky pravdu.
Hluboce pravdiva je veta "Programátor má často mylný pocit, že bude špatný programátor, když řekne přesně stav věci, když snad přizná, že něco nejde podle plánu."
Programatori jsou casto introverti, kteri maji tendenci problem drzet v sobe s tim, ze "zitra to dozenu", coz se casto nepovede, problem se zvetsi a to je jen dalsi duvod to tutlat.
To je podporovano i tim, ze na zacatku projektu/ukolu byva programator "donucen" bez detailni znalosti problemu rict svuj "odhad pracnosti", ktery ale sam chape jako "zavazek".
Myslim, ze je ukolem PM s temito neduhy bojovat (v kladnem smyslu, nejaka represe asi nezafunguje). To je ovsem zrejmy "soft skill" a vyzadoval by zvednou hlavu od Excelu a Outlooku. Jednodussi je prohlasit, ze programatori jsou lhari.
Tedy pokud projmgr urcuje stav projektu tim, ze se zepta programatora, tak to je hodne diletantsky pristup - z mnoha duvodu, ktere nebudu rozpitvavat.
Nadhodim reseni - hodne se mi osvedcil kanban - rozbit projekt na hodne malych ukolu, jejichz slozitost je radove ve dnech. Kazdy ma faze specifikace, technicka priprava, implementace, testovani, opravy, schvaleno (nebo podobne). Do specifikaci keca tester, do technickych veci architekt, testovani opet tester apod. Ukoly se implementuji tak, aby stale bylo neco noveho na testovani, kazdy den.
Na kanban boardu se muze kazdy podivat v jakem stavu ukoly jsou, na cem se zrovna dela, co je hotovo atd a projmgr proste jen kontroluje, jestli se to dostatecne hybe. Kdyz se dva dny zadna karticka nepohne, vidi ze ma problem a muze ho zacit resit. A programator to neokeca, protoze tester. Programator nema duvod lakovat na ruzovo, protoze vi ze se na to stejne brzo prijde, dokud se karticky hybou, nikdo se ho nemusi na nic ptat atd. zbytek necham na fantazii kazdeho...
@prema:
Tak nějak to u sebe (programátora) vidím. Bývá například dost často problém přiznat, že jsem se na něčem seknul a v podstatě nic nového není hotového (ačkoliv jsem třeba nastudoval dost materiálu na vyřešení problému).
Pak akorát vystresovaný čekám, jestli se zrovna teď přijde někdo ptát, co je hotového. Lhát neumím, ale říct pravdu tak, aby zněla lépe, než tomu je, to se pak občas použije. Obzvlášť když projekťák k programování nečuchnul a nezažil si vlastní záseky a myslí si, že jste se týden šťoural v nose.
A přesně tak, na začátku je programátor donucen bez detailní znalosti odhadnout potřebnou dobu a to je pak souboj mezi nejistým programátorem pesimistou (já to budu muset stíhat) a asertivním PM optimistou (já/firma vás nebudem muset tak dlouho platit). Asertivní optimista má většinou dost navrch.
---
A co se týče předpokladu článku, že pořádný programátor by měl být dostatečně komunikativní a otevřený... No, kdybych to uměl, pravděpodobně by se ze mě nestal programátor.
Prehliadnem populisticky nazov clanku a skusim odpoved z druhej strany :o)
Paci sa mi, ako (kedysi)SUN zadefinoval rozdiel medzi "programmer" a "developer" a nasledne nazval prislusne Java certifikacie.
Vyhovorka PM, ze programator je lenivy/zavadza je velmi jednoducha, ale poukazuje skor na neschopnost PM samotneho to uriadit. Casto som tlaceny do "ved za hodinu to musis mat hotove", "tolko to trvat nemoze" a podobne.
PM, team leader, architekt, programator (a pod.) by mali identifikovat slabe miesta a najst nastroj/metodiku, ako to riesit.
Existuje nikolko nastrojov, ktore tento problem riesia z roznych pohladov:
- Junit testy
- Code coverage
- Continuous build/integration
- Automatizovane testovanie
A tiez metodik:
- done definition
Proste dat niekomu 50 metrov kabla, aby natiahol 100 metrov "elektriky" a potom sa cudovat, ze to nesvieti je casta chyba menezerov, s ktorou sa stretavam.
No to jsem akorát ztratil pár minut čtením článku, místo toho jsem mohl programovat :D Dozvěděl jsem se jen, že autor je dobrej (poslední odstavec) a mladí programátoři nespolehliví "lháři"... ;)
:) ukazte mi project managera, ktereho skutecne zajima pravda.
Ahoj všem
Na velký projekt, který se vytváří je třeba najmout člověka, který má za sebou minimálně 5 let vývoje. 10 let optimálně a vytvořil minimálně 3-5 větších projektů. To je základní premisa úspěšnosti SW produktu. Pokud zadáte projekt managerovi co se učil poučky ve škole tak to podle toho taky dopadne. On nedokáže rozlišit co je pravda a co ne a k lidské přirozenosti patří, že pokud si můžu trošku odpočinout a řeknu managerovi, že to vyžaduje 5 dní tak proč ne když to odkejve. Člověk s praxí dokáže odhadnout čas +- na dny. A že plánování je těžké? Není. Stačí rozbít projekt na malé části. Nikdy nezadávat velké objemy práce. Další věc je ta, že programátoři jsou zahledění do nových technologií, které třebas nemusí vůbec vyhovovat projektu a kdo to zjistí. Nikdo. Zase je potřeba mít někoho kdo to dkoáze analyzovat a vyhodnotit. Manager určitě ne.
Google - Googlr
.
Děkuji moc za suprové novinky o javičce. My jsme se v práci s javou docela dost dobře zasekali a tak jsme z toho byli trochu konsternovaní. Nicméně se nám to podařilo docela dost dobře a jednoduše vyřešit díky našemu novému programátorovi , takže máme velikou radost :-) Díky za to, že píšete tento blog :-)
Okomentovat