Fórum Root.cz
Ostatní => Odkladiště => Téma založeno: sofa_king 31. 08. 2017, 14:30:11
-
Pro programátory
Víte, že dle bible projektového manažera má projekt jasně definovaný konec a cíl, jinak nemůže být ani nazván projektem? Divili jste se někdy, proč po vás neustále vyžadují nějaké odhady?
Pro projektové manažery
Uvědomujete si, že projekt je pouze něco, co si programátoři otevřou v Eclipsu a s žádným koncem nepočítají? To, na čem dělají je většinou tvorba nebo údržba nějakého programu, co kontinuálně generuje hodnotu. Ne až někdy po skončení projektu.
-
Hezký!
-
Myslim, ze si pletete PROJEKT a PRODUKT. Projekt je to co pisete u odstavce pro manazery, produkt to co pisete u odstavce pro programatory.
-
Myslim, ze si pletete PROJEKT a PRODUKT. Projekt je to co pisete u odstavce pro manazery, produkt to co pisete u odstavce pro programatory.
Já ten rozdíl znám, protože mám blízko k oboum rolím, ale připadá mi, že si to firmy, projektová kancelář a jednotliví programátoři moc neuvědomují.
Programátoři tomu, co nazýváte produkt, říkají projekt. Jak jsem zmínil, vývojové nástroje (IDE, editory) umožňují vytvořit "nový projekt", ne "nový produkt", když kliknete na Menu -> Nový -> Vytvořit. Vypadá to jako banalita, jenže pak se všichni baví o něčem jiném.
Z pohledu programátora to, na čem dělá (pro něj projekt), nevnímá jako produkt. Jeho práce není prodávána přímo koncovým zákazníkům. Jeho práce je vlastně vytvořit stroj, který zákazníkům, ať interním nebo externím, poskytuje službu. Takový stroj by se mohl nazvat produktem, ale přesto se každý baví "na jakém projektu právě děláš?", ne "na jakém produktu" nebo "na jakém stroji teď děláš"?
Takže tedy, proč je programátor při své denní rutině kontrolován projektovým a ne produktovým manažerem? Vždyť mají naprosto odlišné představy o náplni práce.
-
http://www.ozone3d.net/public/jegx/201110/developers-designers-pms-qa.jpg
-
stavba domu=vyvoji software pre zakaznika a to je projekt
projekt skonci ked je dom postaveny
projekt skonci ked je software odovzdany zakaznikovi
po ukonceni projektu sa vysledok hodi do 'support' modu kde sa obvykle ina skupina stara o kazdodenne problemy.
ked chces dostavat k domu dalsie poschodie, tak to je novy projekt
-
Myslim, ze si pletete PROJEKT a PRODUKT. Projekt je to co pisete u odstavce pro manazery, produkt to co pisete u odstavce pro programatory.
Já ten rozdíl znám, protože mám blízko k oboum rolím, ale připadá mi, že si to firmy, projektová kancelář a jednotliví programátoři moc neuvědomují.
Programátoři tomu, co nazýváte produkt, říkají projekt. Jak jsem zmínil, vývojové nástroje (IDE, editory) umožňují vytvořit "nový projekt", ne "nový produkt", když kliknete na Menu -> Nový -> Vytvořit. Vypadá to jako banalita, jenže pak se všichni baví o něčem jiném.
Z pohledu programátora to, na čem dělá (pro něj projekt), nevnímá jako produkt. Jeho práce není prodávána přímo koncovým zákazníkům. Jeho práce je vlastně vytvořit stroj, který zákazníkům, ať interním nebo externím, poskytuje službu. Takový stroj by se mohl nazvat produktem, ale přesto se každý baví "na jakém projektu právě děláš?", ne "na jakém produktu" nebo "na jakém stroji teď děláš"?
Takže tedy, proč je programátor při své denní rutině kontrolován projektovým a ne produktovým manažerem? Vždyť mají naprosto odlišné představy o náplni práce.
Kdyz ten rozdil znate, tak proc jste chybne oba terminy spletl dohromady hned na uvod?
To co pisete dale je pouze povrchni generalizace zalozena na vasi zkusenosti z prostredi, kde zrejme nebyly tyto dva terminy dostatecne vysvetleny.
Ja jsem dev a vim ze upravuji "produkt" v ramci nejakeho "projektu". Produkt je treba "tramvaj", projekt treba "pridani vagonu trx1000".
-
Kdyz ten rozdil znate, tak proc jste chybne oba terminy spletl dohromady hned na uvod?
Zkus sežrat nějaký maso... ::)
-
Programátoři tomu, co nazýváte produkt, říkají projekt. Jak jsem zmínil, vývojové nástroje (IDE, editory) umožňují vytvořit "nový projekt", ne "nový produkt", když kliknete na Menu -> Nový -> Vytvořit. Vypadá to jako banalita, jenže pak se všichni baví o něčem jiném.
IDE bych sem příliš nepletl, protože používají i jiné termíny. Například Visual Stduio jednotlivé projekty (výsledkem jednoho projektu je obvykle jeden binární soubor/komponenta, ne celá věc, kterou má vývojář vytvořit) sdružuje do Solution (ale ne vždy je vhodné/možné umístit celou práci na jedné věci do jednoho solution).
Spíš to vidím tak, že tady dochází k přetížení slova projekt, a to je celé. Zkrátka je třeba vždy vědět, s kým člověk mluví a v jakém kontextu, a podle toho se zachovat.
-
stavba domu=vyvoji software pre zakaznika a to je projekt
projekt skonci ked je dom postaveny
projekt skonci ked je software odovzdany zakaznikovi
po ukonceni projektu sa vysledok hodi do 'support' modu kde sa obvykle ina skupina stara o kazdodenne problemy.
ked chces dostavat k domu dalsie poschodie, tak to je novy projekt
Aa, opět porovnáváme software se stavbou. Když je v tom support módu jiná skupina než původní vývojáři, jakých změn v programu je schopná, když nemá v hlavě interní model toho, jak to funguje? Může tak udělat pár restartů nebo něco vevnitř kódu rozvrtat metodou pokus omyl.
Velké tech firmy mají samozřejmě core team na každý produkt, který svoji mašinu vybuduje a pak se o ní taky s hrdostí stará, a ne tým levných outsourcerů z Indie nebo Československa, který to po nich převezme.
Ano, je pravda že v naší kotlině se software řeší jako stavba baráku. Taky těch veleúspěšných tech firem máme, že?
-
Aa, opět porovnáváme software se stavbou. Když je v tom support módu jiná skupina než původní vývojáři, jakých změn v programu je schopná, když nemá v hlavě interní model toho, jak to funguje? Může tak udělat pár restartů nebo něco vevnitř kódu rozvrtat metodou pokus omyl.
U čehokoliv netriviálního to nemá v hlavě ani ta původní skupina. Bez ohledu na to, kdo to udržuje, je to buď v dokumentaci nebo v zadeki.
-
stavba domu=vyvoji software pre zakaznika a to je projekt
projekt skonci ked je dom postaveny
projekt skonci ked je software odovzdany zakaznikovi
po ukonceni projektu sa vysledok hodi do 'support' modu kde sa obvykle ina skupina stara o kazdodenne problemy.
ked chces dostavat k domu dalsie poschodie, tak to je novy projekt
Aa, opět porovnáváme software se stavbou. Když je v tom support módu jiná skupina než původní vývojáři, jakých změn v programu je schopná, když nemá v hlavě interní model toho, jak to funguje? Může tak udělat pár restartů nebo něco vevnitř kódu rozvrtat metodou pokus omyl.
Velké tech firmy mají samozřejmě core team na každý produkt, který svoji mašinu vybuduje a pak se o ní taky s hrdostí stará, a ne tým levných outsourcerů z Indie nebo Československa, který to po nich převezme.
Ano, je pravda že v naší kotlině se software řeší jako stavba baráku. Taky těch veleúspěšných tech firem máme, že?
... prosimte ... bez a vyrob veleuspesnou firmu z 'core teamama' - urcite to tak funguje! ... smarja zase bahno ...
-
Aa, opět porovnáváme software se stavbou. Když je v tom support módu jiná skupina než původní vývojáři, jakých změn v programu je schopná, když nemá v hlavě interní model toho, jak to funguje? Může tak udělat pár restartů nebo něco vevnitř kódu rozvrtat metodou pokus omyl.
U čehokoliv netriviálního to nemá v hlavě ani ta původní skupina. Bez ohledu na to, kdo to udržuje, je to buď v dokumentaci nebo v zadeki.
Panečku to je argument.
Manažer: Projekt je hotov, budeme outsourcovat další "vývoj" ehm support na někoho levnějšího. Původním vývojářům se to stejně zítra komplet vypaří z hlavy. Je to jedno, kdo to bude udržovat, má to všechno v dokumentaci.
Zdědil jste někdo po někom netriviální kus softwaru a mohl nám podat své pocity? To je pošušnáníčko, co? Zejména pokud dědíte po páté generaci dědiců v nějakém korporátu.
A je to za hubičku. Viz ty banky a pojišťovny, co lákají na platy CZK 100k+ chudáky, aby šli držet pohromadě softwarovou sračku, co tam léta drží sotva na drátkách.
-
Aa, opět porovnáváme software se stavbou. Když je v tom support módu jiná skupina než původní vývojáři, jakých změn v programu je schopná, když nemá v hlavě interní model toho, jak to funguje? Může tak udělat pár restartů nebo něco vevnitř kódu rozvrtat metodou pokus omyl.
U čehokoliv netriviálního to nemá v hlavě ani ta původní skupina. Bez ohledu na to, kdo to udržuje, je to buď v dokumentaci nebo v zadeki.
Panečku to je argument.
Manažer: Projekt je hotov, budeme outsourcovat další "vývoj" ehm support na někoho levnějšího. Původním vývojářům se to stejně zítra komplet vypaří z hlavy. Je to jedno, kdo to bude udržovat, má to všechno v dokumentaci.
Já psal něco trochu jiného. O outsourcování někomu levnějšímu tu zatím nikdo nepsal. Ale ano, pokud to není v dokumentaci, tak je opravdu jedno, kdo to bude udržovat. I původní autor si po půl roce pamatuje kulové.
Zdědil jste někdo po někom netriviální kus softwaru a mohl nám podat své pocity? To je pošušnáníčko, co? Zejména pokud dědíte po páté generaci dědiců v nějakém korporátu.
Ano, zdědil. Takže můžu s jistotou říct že i v docela zpraseném projektu se dá udělat víc, než jen pár restartů nebo vrtání stylem pokus omyl.
-
O outsourcování někomu levnějšímu tu zatím nikdo nepsal.
Aj, beru zpět :( Ale to o dokumentaci opravdu platí bez ohledu na to, jestli to udržují indové nebo ten core team.
-
Aa, opět porovnáváme software se stavbou. Když je v tom support módu jiná skupina než původní vývojáři, jakých změn v programu je schopná, když nemá v hlavě interní model toho, jak to funguje? Může tak udělat pár restartů nebo něco vevnitř kódu rozvrtat metodou pokus omyl.
U čehokoliv netriviálního to nemá v hlavě ani ta původní skupina. Bez ohledu na to, kdo to udržuje, je to buď v dokumentaci nebo v zadeki.
Panečku to je argument.
Manažer: Projekt je hotov, budeme outsourcovat další "vývoj" ehm support na někoho levnějšího. Původním vývojářům se to stejně zítra komplet vypaří z hlavy. Je to jedno, kdo to bude udržovat, má to všechno v dokumentaci.
Já psal něco trochu jiného. O outsourcování někomu levnějšímu tu zatím nikdo nepsal. Ale ano, pokud to není v dokumentaci, tak je opravdu jedno, kdo to bude udržovat. I původní autor si po půl roce pamatuje kulové.
Aj, beru zpět :( Ale to o dokumentaci opravdu platí bez ohledu na to, jestli to udržují indové nebo ten core team.
Nějak si nedovedu představit jiný důvod než levnější cena pro to, aby se někdo cíleně rozhodl, že na softwaru bude pokračovat někdo jiný než původní tým.
Ale ano, pokud to není v dokumentaci, tak je opravdu jedno, kdo to bude udržovat. I původní autor si po půl roce pamatuje kulové.
Takže chcete říct, že kdybychom teď vzali nějaký netriviální projekt, bylo by víceméně jedno, jestli by v dalším vývoji pokračoval původní tým nebo nějaký jiný tým?
Kdyby zítra Torvaldse srazil autobus, tak by bylo možné najít náhradu, která by to po něm byla schopná převzít? Open source projekty mají snad nejlepší dokumentaci, tak by v ní mělo být podle Vás tedy všechno. Pozn. k nasimulování proprietárního softwaru uvnitř firmy teď hypoteticky nepočítaje kohokoliv, kdo v současnosti na kódu Linuxu hackuje, protože je jaksi součásní původního týmu.
-
Nějak si nedovedu představit jiný důvod než levnější cena pro to, aby se někdo cíleně rozhodl, že na softwaru bude pokračovat někdo jiný než původní tým.
Údržba je třeba supr způsob, jak zaučit nováčka. Je tam málo vlastního programování, ale hodně čtení cizího kódu. Obzvlášt prospěšné je to, pokud je to rozumně napsaný kód.
Ale samozřejmě u každé firmy to po více či méně krocích vždycky skončí u těch peněz.
Kdyby zítra Torvaldse srazil autobus, tak by bylo možné najít náhradu, která by to po něm byla schopná převzít?
Samozřejmě. Nešlo by to okamžitě, ale nebyl by to neřešitelný problém. Tam by byl větší problém se shodnout na náhradníkovi, protože Torvalds tomu nešéfuje z rozhodnutí nějakého nadřízeného.
Jasně, že původní autoři budou mít vždycky náskok před nováčky. Ale není to žádná nepřekonatelná bariéra.