Autor Zpráva
Pavel Krátký
Profil *
Vím, že tohle je na "flejm" a klidně mě to vykopněte, milí admini, možná to tu už někde bude k dohledání, ovšem mám chuť se trochu odreagovat a taky znát názor ostatních, také zkušených :)

The question will be: Jak řešíte termíny? Mám na mysli hlavně sliby, které dáváte Vy, klientům. 100% se to stalo každému, jsem o tom přesvědčen a já si od jisté doby do cé-véčka píšu poznámečku "Snažím se neslibovat nemožné a to mi pomáhá plnit termíny.."

Ovšem, "Neštěstí nechodí po horách, chodí po lidech." říká jedna lidová moudrost a mě se to stalo naposledy minulý týden, kdy jsem zaregistroval zdravotní problém a našel odvahu se klientovi omluvit až dva dny před "dedlajnem". Nabídl jsem mu slevu a dokončení prací s dvoudenním zpožděním, on to tedy vzal velmi sportovně a řekl, že nebude mít problém sehnat náhradu, která to vyřeší "přes noc", respektive v rámci původního termínu.

Máte třeba k dispozici nějaké "kamarády", kteří by Vás mohli zastoupit? Uznávám výhody týmové práce, ovšem do hry vstupuje taky ještě fakt(or) "a new client, would he pay me?" a já bych se pak dostal do situace, že bych musel dlužit kamarádovi nebo šahat do rezerv a do těch se dá šahat pouze tehdy, když nějaké existují :)

Díky za Vaše komentáře!

Pavel Krátký aka BlanikKnight aka numerouno.cz
Chamurappi
Profil
Reaguji na Pavla Krátkého:
Snažím se mít stabilní klienty se zajímavými tvůrčími projekty, kterým časový skluz nepůsobí existenční problémy. Termíny slibuji velmi nerad, nestíhám je v podstatě nikdy, protože vylepšuji zadání a kvůli vylepšeným (komplikovanějším a zajímavějším) cílům pak nemám čas na stihnutí jiných termínů :-)

Máte třeba k dispozici nějaké "kamarády", kteří by Vás mohli zastoupit?
Pokouším se mít, ale často jsou všichni zaneprázdnění.
Joker
Profil
Pavel Krátký:
Podle mě to nějaký zásadní „flejm“ či „problém“ není… Nebo ho tam nevidím.

Termín a co se stane při jeho nesplnění je přece věc dohody o té zakázce. Některému klientovi na termínech moc nezáleží, jiný je striktně vyžaduje.

Máte třeba k dispozici nějaké "kamarády", kteří by Vás mohli zastoupit?
Tak v situaci, kdy tři dny před termínem jsou na projektu ještě dva dny práce a já je nemůžu odpracovat, si neumím moc představit shánět nějakého kamaráda.
Navíc když ten projekt předtím neviděl, za poslední tři dny na něm stejně nejspíš dva dny práce neodpracuje.

U projektu, na kterém už od začátku dělá tým lidí, je to samozřejmě jinak, tam často není problém. (Možná přesněji řečeno v tom není jiný problém, než že pak někdo pracuje 14 hodin denně a podobně, ale s takovou možností se asi v závěru projektu tak nějak počítá :) )
Martin2
Profil *
Pavel Krátký:

No a jak je teda řešíme? U dražších zakázek a nových klientů smluvně – včetně záloh, výše slevy při nedodržení termínu a výše penále při zpoždění platby.

Moderátor juriad: Odmazán atak na Pavla Krátkého; prosím, zkus se trošku více krotit.
Tomáš123
Profil
Pavel Krátký:
ovšem do hry vstupuje taky ještě fakt(or) "a new client, would he pay me?"
Ako zvykneš riešiť vec platby bez toho, aby klienta akokoľvek urazilo, že si myslíš, že nezaplatí?

Jak řešíte termíny?
Väčšinou som schopný zhruba čas odhadnúť a ak sa jedná o niečo väčšie, pridám si aspoň deň ak by nastali komplikácie. Na nejakom globálnejšom projekte tvorby celého webu som ešte nepracoval. Spravidla tam je vyžadované viac než viem.

Chamurappi:
protože vylepšuji zadání a kvůli vylepšeným (komplikovanějším a zajímavějším) cílům pak nemám čas na stihnutí jiných termínů :-)
Ako zvykne druhá strana reagovať na takýto komfort? Posledne, keď som niečo prerábal, chcel som iba, aby všetko čo som robil ja fungovalo. Zvyšok bol otrasný, ale nemal som snahu skúšať to prerábať. Platia ti zákazníci za to, že prirobíš ešte niečo nové? Prípadne, ako sa s nimi dohaduješ? Dávaš im nejaké argumenty, prečo je dobré dať si niečo prerobiť alebo proste vystúpiš s tým, že si tam prirobil ešte pár ďalších vecí a necháš zákazníka oceniť tvoju iniciatívu?

Inak, chcel by som sa vrámci tohoto vlákna opýtať, ako riešite samotnú časť platby. Ja zvyknem zopakovať všetky práce, ktoré som vykonal, ak treba poslať nejaké súbory, pošlem aspoň časť z nich s tým, že po prevedení platby na účet dodám zvyšok a podrobné inštrukcie na uloženie. Prípadne, ak mi dá zákazník prístup na FTP, viem, že on mi dôveruje a tak pociťujem aj ja akúsi dôveru k tomu, že všetko prebehne ako má. V takom prípade zákazník tiež vidí všetky zmeny a môže pripomienkovať všetko s čím nie je spokojný.

Celkovo nerád prijímam platbu ak si nie som istý, či som všetko spravil podľa predstáv druhej strany.
Pavel Krátký
Profil *
Chamurappi:
Snažím se mít stabilní klienty se zajímavými tvůrčími projekty, kterým časový skluz nepůsobí existenční problémy.
To je krásně napsaný, konkrétně existenční problémy. Právě prožívám situaci, kdy mě klient "trénuje" s nějakými, z mého pohledu, drobnostmi, například nedotažený překlad getTextu u jednoho z third-party modulů, takže se tam občas objeví originální anglický text jako tlačítka next-> a send atd.. a znáte to, občas jsou ty texty taky natvrdo ve zdrojácích a stresuje a já se mu už přitom měsíc snažím vysvětlit, jak je pro něj "existenčně" důležité, abychom si sedli a já ho naučil pracovat s administrací, aby tam mohl vkládat nové posty, například. Aneb další příklad, proč je důležité míti Projektového manažera :)

Vzpomněl jsem si právě na rozhovor s jedním potencionálním klientem, kdysi:
Klient Potřebuju stránky, nutně, hned!
Ok, pro koho ty stránky budou, co budou umět...?
Klient, 10 vteřin ticha... Hmm, tak nic.


Tomáš123:
Tomáši, tobě taky děkuju.
a necháš zákazníka oceniť tvoju iniciatívu
To je taky zásadní část tématu (celý odstavec). Kdysi mě bratranec, architekt, poučil: Až budeš vystavovat fakturu, rozepiš to do co největšího množství položek. Já zpravidla, když odevzdávám web, tak klient v adminu vidí Report, kde je roll-out prací, odlišnou barvou vyznačeny práce, které jsem udělal "navíc", jak ty píšeš, žes to prerábal, protože ses na to jednoduše nemohl koukat nebo jsi dobře věděl, že tě to bude v budoucnu brzdit (nebo klienta) a v sólo tabu Návrhy, kdy mu doporučuji udělat to a to a hned to nacením. Málokdy se mi stane, že by si tam klient hned něco sám vybral :)

Celkovo nerád prijímam platbu ak si nie som istý, či som všetko spravil podľa predstáv druhej strany.
To je taky můj problém, asi jsem, asi jestli nejsem ... jestli von se vás .. plachej? :) Pak znám firmy, který si řeknou o 150.000 zálohu a pak půl roku s klientem nekomunikují a pak jsem po nich opravoval dalšího půl roku já, když klient pochopil, že oni už to nedodělaj, když jim nedoplatí zbytek.


Martin2:
Díky! Jinak, jsem jednočlenný tým, už x-krát klient přerušil komunikaci, když jsem mu poslal návrh smlouvy (kde je odstaveček o záloze). Aneb, jak je důležité míti Obchoďáka :)


Joker Děkuju!
ještě dva dny práce a já je nemůžu odpracovatTo je právě ono! Jak to řešíš, když den má jenom 24h?


moderátor Juriad & odmazán atak na Pavla Krátkého
Díky! Nemohl bych to vidět (pk11 na centrum.cz)? Čistě ze zvědavosti...
Tomáš123
Profil
Pavel Krátký:
To je taky zásadní část tématu (celý odstavec).
Ďakujem za názor, otázku som ale smeroval na Chamurappiho. Takisto sme sa asi zle pochopili v mojej vete: „Zvyšok bol otrasný, ale nemal som snahu skúšať to prerábať.“. Ja som to neprerobil. Obdivoval som Chamurappiho, že urobí prácu navyše a zaujímalo ma, ako to potom pokračuje. Pravda nemohol som sa na ten hnusný kód pozerať, ale zabralo by mi to dni práce všetko prerobiť. Keby mi za to niekto ponúkol odmenu, možno by som o tom uvažoval inak, ale keďže sám klient na to kašľal a záležalo mu iba na tom, aby to navonok dobre vyzeralo, prečo by som ja mal dbať?
Str4wberry
Profil
Tak ona je otázka, co si představit pod vylepšení zadání.

„Hnusný kód“ zpravidla na funkci nemá moc vliv, takže někdo jiný než programátor jeho zkrášlení neocení. Zatímco když v zadání bude „kreslit kolečka“ a člověk umožní kromě koleček kreslit i trojúhelníčky, tak to může být pro zadavatele zajímavé.

Jinak k původní otázce: Hrozně záleží na vztahu mezi programátorem a zadavatelem; kdo koho víc potřebuje:

1) U relativně nekvalifikované činnosti může zadavatel programátora honit, protože není zase takový problém najít za pár hodin náhradu.

2) U složitějších věcí je nabídka programátorů značně omezená, navíc se programátor v průběhu projektu stává obtížně nahraditelným (nabídka programátorů ochotných se hrabat v cizím kódu je ještě menší, navíc to zabere další čas), takže se ho zadavatel spíš snaží neztratit, nehoní ho termíny, platí mu víc, než požadoval, a podobně. Zkrátka ten pracovní trh funguje jaksi opačně, než bývá zvykem.
Pavel Krátký
Profil *
Tomáš123:
otázku som ale smeroval na Chamurappiho
Tomáši, já si toho všiml. A reagoval jsem na tebe.

Takisto sme sa asi zle pochopili v mojej vete: ‚Zvyšok bol otrasný...
Ano, to jsem pochopil jinak, než jak jsi to napsal. Nevadí(?)

Keby mi za to niekto ponúkol odmenu, možno by som o tom uvažoval...
To je součást většího problému, někdy se ti vyplatí ty změny udělat s ohledem na to, že to tobě ušetří práci v budoucnu, když děláš na projektu dlouhodobě. Záleží na situaci.

klient na to kašľal
To je kolikrát horší, než když ti nezaplatí. Kolik referencí už jsem musel kvůli tomu vyhodit z portfolia!

Díky!


Str4wberry: Díky.
záleží na vztahu mezi programátorem a zadavatelem
Hezky jsi to shrnul!

Zkrátka ten pracovní trh funguje jaksi opačně
To je zajímavý postřeh...
Joker
Profil
Tomáš123:
Ako zvykne druhá strana reagovať na takýto komfort? Posledne, keď som niečo prerábal, chcel som iba, aby všetko čo som robil ja fungovalo. Zvyšok bol otrasný, ale nemal som snahu skúšať to prerábať.

Str4wberry:
‚Hnusný kód‘ zpravidla na funkci nemá moc vliv, takže někdo jiný než programátor jeho zkrášlení neocení. Zatímco když v zadání bude ‚kreslit kolečka‘ a člověk umožní kromě koleček kreslit i trojúhelníčky, tak to může být pro zadavatele zajímavé.

Ale pozor, četl jsem například teď nějaké knihy o testování a tam bylo napsané, že situace „software má funkčnost, která ve specifikaci není“ by měla být nahlášená jako chyba!
Čímž se naznačuje, že je špatně do aplikace svévolně přidávat funkčnost.
Podle mě ani není správné aplikaci svévolně vylepšovat, pokud to nesouvisí s tím, co na ní mám dělat.

Vývoj není jen programování. Změna, která není součástí žádného požadavku, případně dokonce nikdo neví, že se programátor v té části aplikace hrabal, se těžko může otestovat.
Takhle programátor může do aplikace zanést chyby, které se objeví až v ostrém provozu.

Samozřejmě u malých projektů to není tak dramatické.

A samozřejmě když se ta změna protáhne celým „kolečkem“, tj. nechá odsouhlasit jako změna zadání, není problém.


Inak, chcel by som sa vrámci tohoto vlákna opýtať, ako riešite samotnú časť platby.
Tak pokud si od klienta necháte podepsat objednávku a potvrdit zadání, není pro něj tak snadné to pak nezaplatit a dělat mrtvého brouka.

Jinak že mi někdo nezaplatil se mi stalo jen u nějakých drobností, kde prostě dotyčného dám na blacklist a dál to neřeším.

Teď jsem dokonce v opačné situaci, kdy dlužím já peníze klientovi a když mu to čas od času připomenu, řekne, že si u mě určitě nějakou práci ještě objedná a tím se to vyrovná :-)

Pavel Krátký:
Vzpomněl jsem si právě na rozhovor s jedním potencionálním klientem, kdysi:
Klient Potřebuju stránky, nutně, hned!
Já Ok, pro koho ty stránky budou, co budou umět...?
Klient, 10 vteřin ticha... Hmm, tak nic.

Z toho by podle mě stejně bylo lepší vycouvat, protože obvykle dobrat se k tomu, co vlastně klient chce (de facto analýza problému) trvá hrozně dlouho, přičemž tihle klienti většinou nepočítají s tím, že by za to měli platit.
Tj. ve finále to je tři dny snahy se dobrat k nějakému rozumnému zadání, plus dva dny programování. Přičemž klient očekává, že zaplatí ty dva dny programování.

Nemluvě o případě, kdy po pracné analýze přijde s tím, že takhle to nechtěl.
A nejlepší hláška: No, tu analýzu jsem sice podepsal, ale to jsme si o tom jen tak povídali, já netušil, že to podle toho skutečně uděláte! :-)

‚ještě dva dny práce a já je nemůžu odpracovat‘ To je právě ono! Jak to řešíš, když den má jenom 24h?

Tak to je pochopitelně už těžko řešitelné.
Respektive:
Jedna věc je samozřejmě to ideálně nenechávat až na poslední chvíli a druhá věc udělat důležité věci jako první.
Čekal bych, že tři dny před koncem vývoje bude hotového už něco použitelného a problém bude např. že tam nejsou zanesené poslední změny nebo chybí nějaké kosmetické věci.
Takže klient dostane alespoň něco funkčního, byť ne úplně hotového.

Ale v mém případě jsou vesměs klienti laxnější, než já. A klient, kterého tři měsíce upomínám o dodání podkladů, nemá moc silnou pozici ke stěžování si na délku vývoje :-)
Pavel Krátký
Profil *
Joker aka Nomen Omen (tvůj humor se mi líbí)

Opravovat / neopravovat: budu trvat na svém, že jsou případy, kdy hlavní důvod úprav kódu, které jsem po někom zdědil, mi v budoucnu ušetřily práci. Ano, souhlasím, že u menších, jednodušších projektů, je to omluvitelnější než u týmového, většího / velkého projektu. Příklad za všechny, kdysi jsem z 2 MB knihovny udělal 10 souborů o celkové velikosti 300 kB.

Z toho by podle mě stejně bylo lepší vycouvat
On právě tím "Hmm, tak nic." z toho v tu chvíli vycouval. Dodnes nemá web. Zjistil(i jsme), že důvod jeho zájmu byl obligátní: když maj stránky všichni, tak já taky.

Ana a Lýza :) Tyhle 2 dámy málokdo z klientů zná. A když je neznaj, tak proč by za ně utráceli peníze. To je stejné jako s Danou. Daně taky nikdo nechce platit :)

A klient, kterého tři měsíce upomínám o dodání podkladů, nemá moc silnou pozici ke stěžování si na délku vývoje :-)
Tohle je jeden z těch argumentů, kvůli kterým jsem zakládal tohle téma. Znáte to, absolvujete nějakou situaci, může to být obchodní rozhovor s klientem nebo hádka s partnerkou. Odcházíte rozčarovaní, frustrovaní, zmatení a to další slovo začíná na "nasra" a končí na "ní". Za 2 hodiny a pár panáků najednou vyskočíte a zvoláte: "Proč já wwwůl mu to neřekl takhle!?

Díky, hezký víkend!
Str4wberry
Profil
Reakce na Jokera:
situace ‚software má funkčnost, která ve specifikaci není‘ by měla být nahlášená jako chyba!

Při práci ve větším týmu, kdy jsou činnosti rozděleny mezi více lidí, to má dobrý důvod. Ale myslím, že se tady bavíme spíš o situaci, kdy analysu, návrh, programování i testování dělá tentýž člověk (nebo nikdo).

Potom může nastat v zásadě jen problém, že to zadavatel nebude chtít zaplatit nebo se mu daná funkce nebude líbit a bude se muset odebrat.
Martin2
Profil *
Pavel Krátký:
Díky! Jinak, jsem jednočlenný tým, už x-krát klient přerušil komunikaci, když jsem mu poslal návrh smlouvy (kde je odstaveček o záloze). Aneb, jak je důležité míti Obchoďáka :)
Nejde o zálohu, ta není nutná, jde o smlouvu. Prostě o to jasně určit kdo, co všechno, za kolik a do kdy udělá a co se stane když neudělá. Zabraňuje to situacím typu "Ale vy jste říkal … a my jsme mysleli …".

Díky! Nemohl bych to vidět (pk11 na centrum.cz)? Čistě ze zvědavosti...
Něco ve smyslu, že jsi kecal ukecaný bez schopnosti rozlišit co je v tématu důležité a co už plácání játrama. Snad to stihneš, než juriad zakročí :)
Chamurappi
Profil
Reaguji na Tomáše123:
Dávaš im nejaké argumenty, prečo je dobré dať si niečo prerobiť alebo proste vystúpiš s tým, že si tam prirobil ešte pár ďalších vecí a necháš zákazníka oceniť tvoju iniciatívu?
To je různé, záleží na okolnostech (= kdy mě zlepšení napadne, jestli je zákazník zrovna vzhůru, jak moc se obávám nesouhlasu, zda ho chci příjemně překvapit atd.).
Ještě jsem měl podotknout, že zdaleka ne vždy ta vlastní iniciativa končí něčím pracnějším. Občas detailnějším rozborem (který nebyl žádán a který také zabírá čas) dospěji k tomu, že bude lepší, když požadovaná součinnost nevznikne, nebo když se odloží do vzdálenějšího budoucna, kdy do projektu lépe zapadne.

Poslední dobou se snažím nepracovat na projektech, ke kterým nemám žádný bližší vztah. Zůstávají mi dlouhodobé (mnohaměsíční) spolupráce, kde funguji do značné míry i jako konzultant, nikoliv jen jako programátor. Jsem si vědom, že moje situace není moc přenositelná.
Pokud se pustím do něčeho menšího, je to menší o několik řádů, třeba na pár hodin (typicky opravit někomu web, aby fungoval ve všech prohlížečích) a tam termín dodržím.

Jo a ještě bych chtěl vyjasnit, že předělávám spíš zadání, ne cizí hnusné kódy. Částečně i díky zkušenostem z diskuse se umím celkem obstojně zorientovat v cizím chaosu a pokud klient chce přistavět mezipatro do svého domečku z karet a bláta, obejdu se obvykle bez velkého bourání. I kdybych všechno přepsal, stejně se stanu součástí tradičního koloběhu programátorské kritiky předchůdců:



Reaguji na Martina2:
Snad to stihneš, než juriad zakročí :)
Také to zatím najde v kontejneru. Popichovat můžeš, ale stále platí pravidlo, že bys měl s ostatními jednat slušně. A moderátor na tebe přivolaný stojí před jinou volbou než mlčenlivý přihlížející vědoucí váhající :-)
Joker
Profil
Pavel Krátký:
budu trvat na svém, že jsou případy, kdy hlavní důvod úprav kódu, které jsem po někom zdědil, mi v budoucnu ušetřily práci.

Proto se taky obvykle dělají :-)
Na druhé straně mám i případy, kdy taková i celkem nevinná „vedlejší úprava“ zanesla do kódu nepříjemnou chybu, nebo dokonce odstartovala celý řetěz dalších problémů.

Čímž samozřejmě nechci zatracovat refaktoring, refaktoring je potřeba. Spíš je možná riziko u těch drobných změn ke snižování laťky standardů. Ve smyslu, že „hlavní požadavek“ je celkem solidně zanalyzovaný, pak implementovaný a otestovaný… A někdy na konci testů programátora napadne nějaká „drobnost“, tak to tam střelí ještě před nasazením.

Ještě k tomu přepisování cizího kódu, zvážil bych, nakolik je to potřeba a nakolik je to spíš NIH syndrom.
Četl jsem článek o tom, že zahodit původní kód a začít znovu od začátku je principiálně špatně a nikdy by se to nemělo dělat.
Že refaktoring je správně, ale jako vylepšování, ne původní kód zahodit a začít znovu.
Důvodem je, že pokud ten stávající kód nějak funguje, během jeho fungování se nejspíš vynořila a opravila hromada chyb, během provozu se objevily překážky a problémy a implementovalo se jejich řešení.
Takže zahozením starého kódu se ta „zkušenost“ ztratí a nový kód nejspíš znovu bude obsahovat velkou část z chyb, které ten původní už opravil.

Podotýkám ale, že autor asi neviděl některé kódy, které jsem viděl já :-)
Podle mě existují případy, kdy původní kód je tak strašný a sám o sobě generuje tolik problémů, že se přesto vyplatí ho zahodit a začít znovu.
Abych se třeba některých návštěvníků nedotkl, tím nemyslím kódy tady na diskusi, když se to někdo učí, je v pořádku, že to neudělá hned správně. Na druhé straně, pokud si někdo říká odborník a nechá si za to platit, dodání kódu otřesné kvality je těžko omluvitelné.

On právě tím "Hmm, tak nic." z toho v tu chvíli vycouval.
To jsem pochopil.
Já měl na mysli, že by asi bylo lepší z toho vycouvat i v pozici toho programátora (kdyby to neudělal klient).

Str4wberry:
Potom může nastat v zásadě jen problém, že to zadavatel nebude chtít zaplatit nebo se mu daná funkce nebude líbit a bude se muset odebrat.
Tak.
Asi jen výjimečně bude zadavatel takový šmejd, že počítá od začátku s tím, že tu práci nezaplatí.
Obvykle je problém v tom, že dodaný produkt se liší od představy zadavatele, jak to mělo vypadat.
Právě k tomu je dobrá ta analýza a právě proto mi připadá riskantní brát práci, u které mám problém zjistit, co klient vlastně chce.
Alphard
Profil
A někdy na konci testů programátora napadne nějaká ‚drobnost‘, tak to tam střelí ještě před nasazením.
Na omezení (nebo aspoň lepší promyšlení) těchto živelných úprav je dobré používat verzovací systém. Tam se neschová ani drobnost, takže vývojář musí promyslet, jestli ta úprava stojí za to, aby pro ni vytvářel commit. Když se rozhodne, že ano, udělá to pořádně (protože nechce mít v historii bordel). Před commitem si ještě projde, co vlastně odesílá, takže takový vlastní code review (teď nemluvím o týmech, kde dělá code review někdo jiný). Tuhle změnu pak uvidí kolegové, případně i testeři, takže se na to mohou dodatečně podívat a když už by se přecejen něco rozbilo, lze v historii hledat příčinu a vzít ji zpět/opravit.

Vaše odpověď

Mohlo by se hodit

Příspěvky nesouvisející s webem budou odstraněny.

Prosím používejte diakritiku a interpunkci.

Ochrana proti spamu. Napište prosím číslo dvě-sta čtyřicet-sedm: