Millaset aikataulut ja dead linet teillä annetaan ohjelmoinnille? Kuinka paljon ohjelmoijalla sananvaltaa aikatauluihin ?
Koulussa ja itekseen harrastellessa ohjelmointi oli lepposta puuhaa, mutta töissä saa painaa hiki hatussa kauheella stressillä. Testata ei sitten täysin kunnolla edes ehitä. Ja lopulta kun saanu homman kasaan ja on ihan puhki niin paskaa tulee pomoilta ja asiakkailta kun joku juttu ei sitten kunnolla toimikaan.
Varsinkin kun on ollut alalla töissä vasta vuoden niin utta opeteltavaakin on aika paljon eikä noita juttuja hetkessä tee. 10 vuoden työkokemuksella varmaan helpompaa jos pää kestää sinne asti.
Sun kokemuksia?
ohjelmoinnin dead linet
huuuuh
27
3641
Vastaukset
- RuoskaaJaPiiskaa
Välillä pääsee itse määrittämään aikataulut, välillä ei. Välillä deadline kusee, välillä ei.
Liian löysä aikataulu johtaa löysäilemiseen ja työmotivaatio ainakin itsellä kärsii tuostakin.
Liian kireä aikataulu taas johtaa kiirehtimiseen ja huonoon työnjälkeen, ja lopputuloksena työn tekeminen kestää kauemmin kuin löysemmällä aikataululla.
Parhaiten homma toimii kun aikataulu on sopivan tiukka ja työn eteneminen selvää. Joka päivä saa tehdä kunnolla töitä, mutta tietää myös että homma etenee aikataulussa.
Aikataulu ei saisi koskaan johtaa työn huonoon tekemiseen, koska silloin ongelmat vain kasvavat.
Nämähän on kyllä vissiin tiedetty jo ensimmäistä reikäkorteista lähtien, mutta tilanne pääsee aina vaan välillä yllättämään kokeneemmankin :-)
Pitäisi osata sanoa välillä "ei", tai "en ehdi millään". Itseään ei kannata työllä tappaa.- RuoskaajaPiiskaa
Niin tosiaan alussa homma oli kyllä yhtä helvettiä. Silloin tulikin kyllä tehtyä semmoisia suorituksia paineen alla, joita en enää kyllä lähtisi vääntämään...
- kodari76
No meillä homma toimii näin:
Pomot tulee ja kysyy kauanko minulta kestää tehdä gizmo-orgazmo palikka, jollaista en ole ikinä ennen tehnyt enkä tiedä miten se edes tehdään. Sanon heille että en minä tiedä. He pyytävät arvioimaan edes jotain. Sanon että kolme kuukautta. Se kuulemma kuulostaa aika kovalta, mutta kävisikö minulle vaikkapa kaksi kuukautta. Mitäs siihen sanomaan. Sanon että ihan miten vaan.
Mitään speksejä ym. ei tietenkään ole. Ja kontaktihenkilöt on ainakin vuoden vaihteeseen asti lomalla. Mutta kaiken tämän kestää kun jo valmiiksi tietää että myöhässä ollaan. Ja vaikka saisitkin ajoissa valmiiksi, niin joku muu on myöhässä ja koko projekti myöhästyy.- Tsukutsuku
Olet huono työssäsi...
- kodari76
Tsukutsuku kirjoitti:
Olet huono työssäsi...
No sehän voi hyvinkin pitää paikkaansa.
Mutta millä perustelet väittämäsi?
- peepee
Näin projektipäällikön näkökulmasta:
ensin otetaan lähtökriteerit:
- koska pitäisi olla valmis (asiakkaan vaatimus)
- paljonko saa maksaa (asiakkaan vaatimus)
- kuka on tarjolla tehtävän tekemään (voi olla myös alihankintana tehtävä)
arvioin ensin itse osittamalla tehtävän yleensä 0,5 - 5 htp suuruisiin osiin. Suhteutan tämän lähtökriteereihin. Mietin mistä voi tinkiä - aikataulu, budjetti vai sisältö. Poistan osituksesta omat työmääräarvioni ja esitän tehtävän ohjelmoijalle joka tekee omat arvionsa. Arviossa keskeinen asia ovat arviointiperusteet - "miksi sanot 4 htp? miksi ei 2 tai 20?"
Näiden pohjalta tehdään tarjous tehtävästä asiakkaalle. Jos asiakas tinkii, nyrkkisääntö on että jos hinnasta putoaa 20% niin sisällöstä putoaa 30% - emme ole turkkilainen basaari vaan asiantuntijaorganisaatio.
Ja tämä toimii hyvin kunhan joku puusilmä myyjä tai pikkujohtaja ei änkeä väliin antamaan "omia arvioitaan".
Mainittakoon myös että kokemuksieni mukaan useimmat ohjelmoijat ovat perin kehnoja arvioijia...- RuoskaajaPiiskaa
"Mainittakoon myös että kokemuksieni mukaan useimmat ohjelmoijat ovat perin kehnoja arvioijia..."
Pitää paikkansa myös omien havaintojeni mukaan. Jos itse tekee myös työn, sortuu hyvin helposti yliarvioimaan omaa työtehoaan tai aliarvioimaan työn määrää. Useasti saattaa olla myös paineita esittää mahdollisimman optimistinen aikataulu.
Työmäärän arviointi saattaakin olla useimmiten järkevää pitää erillään työn suorittajasta. Lisäksi, jos arvio ei pidä paikkaansa, "syyn" pitäisi oletusarvoisesti olla silloin väärässä arviossa.
Huonoa arviointia ei pystytä enää koodamalla paikkamaan, korkeintaan tilannetta voidaan huonontaa entisestään.
Tietysti markkinat asettavat aina ylärajan työmäärälle. Ongelma ei kuitenkaan poistu työmääristä tinkimällä. Jos esimerkiksi paperia joudutaan myymään alihintaan jossain tilanteessa, niin eihän tilannetta kai yritetä korjata ajamalla paperikonetta yli maksimikapasiteetilla? - peepee
RuoskaajaPiiskaa kirjoitti:
"Mainittakoon myös että kokemuksieni mukaan useimmat ohjelmoijat ovat perin kehnoja arvioijia..."
Pitää paikkansa myös omien havaintojeni mukaan. Jos itse tekee myös työn, sortuu hyvin helposti yliarvioimaan omaa työtehoaan tai aliarvioimaan työn määrää. Useasti saattaa olla myös paineita esittää mahdollisimman optimistinen aikataulu.
Työmäärän arviointi saattaakin olla useimmiten järkevää pitää erillään työn suorittajasta. Lisäksi, jos arvio ei pidä paikkaansa, "syyn" pitäisi oletusarvoisesti olla silloin väärässä arviossa.
Huonoa arviointia ei pystytä enää koodamalla paikkamaan, korkeintaan tilannetta voidaan huonontaa entisestään.
Tietysti markkinat asettavat aina ylärajan työmäärälle. Ongelma ei kuitenkaan poistu työmääristä tinkimällä. Jos esimerkiksi paperia joudutaan myymään alihintaan jossain tilanteessa, niin eihän tilannetta kai yritetä korjata ajamalla paperikonetta yli maksimikapasiteetilla?Haluan kyllä aina myös tekijän arvion jotta saadaan hieman stereonäköä arvioon (jos itse arvioin vaikka 20 htp ja tekijä 10 htp, voin vertailla kummankin käyttämiä kriteerejä ja lopputulos voikin olla vaikka 25 htp)
Mutta yleensä ohjelmoijat ovat aavistuksen välinpitämättömiä arvioissaan ja se on yleisin syy miksi heidän arvionsa ovat kehnoja. "olisko joku 10 htp, emmä tiedä, ihan sama" perin paradoksaalista koska kyseessä kuitenkin on mahdollisuus vaikuttaa omaan työhönsä.
Se miksi moitin "myyjiä ja pikkujohtajia" on se, että he usein subventoivat myyntiä puuttumalla työmääräarvioihin. Minusta subventointi pitää pitää erillään arvioista: jos työmäärä on minun ja ohjelmoijan mukaan vaikka 20 htp ja myyjä haluaa asiakkaan voitelemiseksi, omien bonareidensa lisäämiseksi tai mistä syystä nyt vaan myydä työn 12 htp hinnalla niin se pitää kirjanpidossa näkyä, ja 12-20 htp haarukkaan osuva toteuma on myyjän, ei projektipäällikön ja ohjelmoijan vastuulla. Vrt. jos olisin kodinkonekauppias: voin myydä pesukoneen alle omakustannushinnan, mutta en voi väärentää kirjanpidon sisäänostohintaa jotta näyttäisi siltä että tein voittoa. - Aleksi
Onkohan ohjelmointihommissa sama kuin muussa tuotekehitystyössä, eli itse suunnitteljoiden ja toteuttajien on todella vaikeaa sanoa kuinka kauan aikaa kuluu, koska harvoin on olemassa sellaisia yhteismitallisia samanlaisia hommia joista voisi aikaisempien kokemusten perusteella sanoa kuinka kauan kestää?
Itse olen ollut yli 5 vuotta tuotekehitysprojekteissa ja jokakerta on ollut sama juttu. Tullaan kysmyään kauanko kestää, ja kyseessä on sellaiset tuotteet joiden toteuttamista ei pysty mitenkään vertaamaan aikaisempaan kokemukseeni. Revi siitä sitten aikataulu.
Projektipäällikkökään ei yleensä pysty realistisia aikataluja vetämään koska eivät hekään tiedä, ei heillä välttämättä ole kokemusta asiakkaan tilaamasta tuotteista.
En usko että aikataulutuksessa projektipäällikkö on sen parempi kuin suunnittelijakaan. - Aleksi
peepee kirjoitti:
Haluan kyllä aina myös tekijän arvion jotta saadaan hieman stereonäköä arvioon (jos itse arvioin vaikka 20 htp ja tekijä 10 htp, voin vertailla kummankin käyttämiä kriteerejä ja lopputulos voikin olla vaikka 25 htp)
Mutta yleensä ohjelmoijat ovat aavistuksen välinpitämättömiä arvioissaan ja se on yleisin syy miksi heidän arvionsa ovat kehnoja. "olisko joku 10 htp, emmä tiedä, ihan sama" perin paradoksaalista koska kyseessä kuitenkin on mahdollisuus vaikuttaa omaan työhönsä.
Se miksi moitin "myyjiä ja pikkujohtajia" on se, että he usein subventoivat myyntiä puuttumalla työmääräarvioihin. Minusta subventointi pitää pitää erillään arvioista: jos työmäärä on minun ja ohjelmoijan mukaan vaikka 20 htp ja myyjä haluaa asiakkaan voitelemiseksi, omien bonareidensa lisäämiseksi tai mistä syystä nyt vaan myydä työn 12 htp hinnalla niin se pitää kirjanpidossa näkyä, ja 12-20 htp haarukkaan osuva toteuma on myyjän, ei projektipäällikön ja ohjelmoijan vastuulla. Vrt. jos olisin kodinkonekauppias: voin myydä pesukoneen alle omakustannushinnan, mutta en voi väärentää kirjanpidon sisäänostohintaa jotta näyttäisi siltä että tein voittoa.Kysy ihmeessä niiltä ohjemoijilta miksi ne antavat ylimalkaisia arvioita ja vaadi arvioissa tarkkuutta hyvä ihminen. Älä jää asiaa ihmettelmään vaan nosta epäsuomalaisella tavalla kissa pöydälle.
Aikataulutuksen sopiminen yhdessä siten että sopijat ottavat asian vakavasti on erittäin tärkeää. Jos näin ei tehdä, silloin on ongelmia projektin vetäjän henkilöstön johtamistaidoissa. - peepee
Aleksi kirjoitti:
Kysy ihmeessä niiltä ohjemoijilta miksi ne antavat ylimalkaisia arvioita ja vaadi arvioissa tarkkuutta hyvä ihminen. Älä jää asiaa ihmettelmään vaan nosta epäsuomalaisella tavalla kissa pöydälle.
Aikataulutuksen sopiminen yhdessä siten että sopijat ottavat asian vakavasti on erittäin tärkeää. Jos näin ei tehdä, silloin on ongelmia projektin vetäjän henkilöstön johtamistaidoissa.Aivan totta, pitääkin ryhtyä pyytämään "tarkkoja arvioita aikuisten oikeesti". Kas kun en tuota ole hoksannut. Äijä on guru.
Puhe olikin siitä, mitä useat ohjelmoijat omien kokemusteni mukaan oletusarvoisesti tekevät eli vetävät hihasta sattumanvaraisen arvion. Ammattilaisten tulee kyetä vaatimattakin parempaan. - RuoskaajaPiiskaa
Aleksi kirjoitti:
Onkohan ohjelmointihommissa sama kuin muussa tuotekehitystyössä, eli itse suunnitteljoiden ja toteuttajien on todella vaikeaa sanoa kuinka kauan aikaa kuluu, koska harvoin on olemassa sellaisia yhteismitallisia samanlaisia hommia joista voisi aikaisempien kokemusten perusteella sanoa kuinka kauan kestää?
Itse olen ollut yli 5 vuotta tuotekehitysprojekteissa ja jokakerta on ollut sama juttu. Tullaan kysmyään kauanko kestää, ja kyseessä on sellaiset tuotteet joiden toteuttamista ei pysty mitenkään vertaamaan aikaisempaan kokemukseeni. Revi siitä sitten aikataulu.
Projektipäällikkökään ei yleensä pysty realistisia aikataluja vetämään koska eivät hekään tiedä, ei heillä välttämättä ole kokemusta asiakkaan tilaamasta tuotteista.
En usko että aikataulutuksessa projektipäällikkö on sen parempi kuin suunnittelijakaan.Joo, monestihan tuo on tilanne, että joko välineet ovat uusia tai sovellusalue on tuntematon tai tekijät ovat uusia.
Omat kokemukseni rajoittuvat tietojärjestelmäpuolelle. Mielestäni niissä hommissa ei kuitenkaan ole mitään niin ihmeellistä, etteikö kohtuullisia arvioita pystyisi tekemään, vaikka tuntemattomia tekijöitä onkin. Kysymys on vertauskuvallisesti useimmiten pikemminkin uuden talon rakentamisesta kuin jostakin apollo-projektista.
Projektipäällikkö pystyy katsomaan asioita hieman etäämmältä ja näkemään paremmin kokonaiskuvaa. Siksi mielestäni arviointi ja arvioinnin kehitys pitäisi olla ensisijaisesti projektipäälliköllä.
Mutta myös toteuttajan arvio on tärkeä; sehän on tavallaan sopimus projektipäällikön ja toteuttajan välillä ja pitäisi sitoa toteuttajaa. - väiski
peepee kirjoitti:
Haluan kyllä aina myös tekijän arvion jotta saadaan hieman stereonäköä arvioon (jos itse arvioin vaikka 20 htp ja tekijä 10 htp, voin vertailla kummankin käyttämiä kriteerejä ja lopputulos voikin olla vaikka 25 htp)
Mutta yleensä ohjelmoijat ovat aavistuksen välinpitämättömiä arvioissaan ja se on yleisin syy miksi heidän arvionsa ovat kehnoja. "olisko joku 10 htp, emmä tiedä, ihan sama" perin paradoksaalista koska kyseessä kuitenkin on mahdollisuus vaikuttaa omaan työhönsä.
Se miksi moitin "myyjiä ja pikkujohtajia" on se, että he usein subventoivat myyntiä puuttumalla työmääräarvioihin. Minusta subventointi pitää pitää erillään arvioista: jos työmäärä on minun ja ohjelmoijan mukaan vaikka 20 htp ja myyjä haluaa asiakkaan voitelemiseksi, omien bonareidensa lisäämiseksi tai mistä syystä nyt vaan myydä työn 12 htp hinnalla niin se pitää kirjanpidossa näkyä, ja 12-20 htp haarukkaan osuva toteuma on myyjän, ei projektipäällikön ja ohjelmoijan vastuulla. Vrt. jos olisin kodinkonekauppias: voin myydä pesukoneen alle omakustannushinnan, mutta en voi väärentää kirjanpidon sisäänostohintaa jotta näyttäisi siltä että tein voittoa.Kyse ei ole aina välinpitämättömyydestä. Kun ei tiedä niin ei tiedä. Tuossa yksi kaveri jo ehdotti "kissan nostmista pöydälle". Joskus olen ollut mukana tuollaisessa keskustelussa. Kysyivät että kauanko menee X:n valmistamiseen, sanoin etten tiedä. Ja siitä se lähtee..."no miksi et tiedä?" Voi vittu että pitää aikuisen ihmisen tuommoista kysyä. No miksi et itse tiedä että miksi minä en tiedä? ;)
Ehkä olen hieman vanhankantainen, mutta IMHO tällaiset asiat ovat niitä mistä pomoille maksetaan. Meillä monesti työntekijät kertovat aikataulut ym. ja sitten meitä pidetään vastuullisina päivämääristä. Pomo se on mielestäni se joka kertoo mitä tehdään ja ottaa vastuun. Oikein vituttaa joskus istua "tiimipalaverissa" miettimässä mitä minun pitäisi tehdä, koska ja miten jne. Mitä virkaa sillä dirikalla sitten on? Nämä lienevät kuitenkin enemmän isojen firmojen ongelmia?
- coderiz
Ei koodausta kenenkään pää kestä muutamaa vuotta kauemmin
- Jani
Joo,
Näin se yleensä menee mun projekteissa:
Annetaan homma väljästi speksattuna ja pyydetään aika arviota. Kysyn koodaajalta parhaan arvauksen tai yleensä sellaisen haarukan millä välillä tuon olettuu valmistuvan valmiista spekseistä riippuen. Haarukka voi olla vaikkapa 2-4 kk tässä vaiheessa. Sitten yleensä lisään molempiin lukuihin noin 30% ei siis haarukka onkin 3-6 kk.
Kerron tuotepäällikölle, joka tuumaa, että eihän siihen voi noin kauan mennä, mutta tyytyy sitten arvioon itkien, että tää on luvattu myynnille jo 2kk:n päästä. Tuotepäällikkö tekee speksin loppuun ja aiemman speksin vaatimukset ovat tuplaantuneet varmaankin myyjien tarjoamalla pitkällä lounaalla.
Arvioitan aikatulun uudelleen koodareilla ja aikatauluun tulee 20-30% lisää. Lisään vielä itse vähän ja teen lopullisen aikataulun. Varsinainen ohjelmointi 8kk testaus & bugien korjaus 3 kk ja se mahtuu tuohon justiinsa muutamalla ylityöviikonlopulla. :)
Tämän jälkeen tullaan kertomaan, että tämä on jo myyty ja toimitus on 3,5kk:n päästä. Sitten vain karsimaan "pakollisista" ominaisuuksista ja lisäämään kokemattomia koodareita projektiin ja käynnistämään projektia, joka ei mitenkään voi realistisesti ehtiä annettuun aikatauluun. :)
Ja koodi on tämän jälkeen todella hyvää ... - Dogg
Jos et ole ennen tehnyt juuri samanlaista juttua et millään tiedä kauanko hommaan menee. Voi tulla vaikka mitä ongelmia eteen. Ja tuollaiset projektipäälliköt jotka vaatimalla vaativat että arvioi asian jota ei voi tietää voivat mennä *PIIP* Sama juttu on tutkimushommissa joissa olen ollut projektitutkijana - et -------kaan tiedä kuinka paljon aikaa hommaan tulee menemään koska kaikki on epäselvää. Sitten arviot tehdään hatusta vetäisemällä. HUOM! Tietojenkäsittelytieteiden työmäärän arviointimenetelmät on aika hanurista..kaikki varmaan muistavat ne kertoimet jotka eivät merkitse hevon -----a.
Miksi it-alalla homma on vielä niin lastenkengissä? Retoriikka on jotakin mahtipontista markkinointishaissea, jossa ei pystytä puhumaan rehellisesti asioista. Et voi arvioida sellaista mitä et tiedä. Jos yrität niin mennään metsään enemmän tai vähemmän.- Jani
En tiedä kenelle tuo oli suunnattu, mutta kommentoin tähän nyt kuitenkin:
"Jos et ole ennen tehnyt juuri samanlaista juttua et millään tiedä kauanko hommaan menee."
Tuo on totta, mutta hommalla on pakko joku aikataulu antaa ja kokenut koodari osaa antaa kohtuullisen lähelle oikean arvion kun siihen tekee sellaisen optimismikorjauksen (~ 30%). Helpon tilanne yleensä on, jos annetaan vapaat kädet antaa realistinen arvio, eikä tarvitse alusta asti yrittää vääntää sitä valmiiksi annettua epärealistista loppupäivää eteenpäin.
"Voi tulla vaikka mitä ongelmia eteen."
Niitä tulee joka projektissa kaikesta huolimatta. Tärkeintä on vain huomata ne ajoissa ja reagoida niihin.
"Ja tuollaiset projektipäälliköt jotka vaatimalla vaativat että arvioi asian jota ei voi tietää voivat mennä *PIIP*"
Ei ne projektipäälliköt sitä vaadi, koska ovat itsekin kusessa jos aikataulu ei pidä. Myynti vaatii, asiakkaat vaativat, tuotepäällikkö vaatii ja eivät voi ymmärtää, että jonkin tekemiseen menee juuri niin kauan kuin menee katsoo sitä millaisten lasien läpi tahansa.
"Tietojenkäsittelytieteiden työmäärän arviointimenetelmät on aika hanurista..kaikki varmaan muistavat ne kertoimet jotka eivät merkitse hevon -----a."
Tuo on täyttä faktaa.
"Miksi it-alalla homma on vielä niin lastenkengissä?"
Koska jokainen projekti on niin erillainen. Tuottavuuserot koodareiden välillä suuria. Teknologia uutta jne. Lisäksi liiketoimintajohtoa on vaikea saada ymmärtämään, että et voi todellakaan antaa aikataulua, jollekin mitä ei vielä ole määritelty riittävän tarkkaan. Sama kun talonrakentajan pitäisi arvioida kauanko rakentaminen vie tietämättä onko kyse mummon mökistä vai 500 neliön luksusasunnosta.
"Et voi arvioida sellaista mitä et tiedä. Jos yrität niin mennään metsään enemmän tai vähemmän."
Juuri näin, mutta et voi myöskään sanoa asiakkaalle, että "kyllä se sitten valmistuu kun valmistuu." Kaikki aikataulut ovat aina keinotekoisia ja arvioita. Taito onkin osua edes lähelle todellista...
- kolmiyhteys
Kolmiyhteyshän on raha, laatu ja aikataulu. Jos joku pettää muut antavat samassa suhteessa periksi...
- neliyhteys
Puhutaan myos neljannesta muuttujasta eli "scope", tyopaketti. Yhtalo voidaan laittaa matsaamaan karsimalla ominaisuuksia projektin edetessa. Tai sitten joku lisaa siihen uusia juttuja :-)
- ohjelmoijak
vastauksena on työmääräarviointi, kunnolla tehty työmääräarviointi helpottaa henkisesti kun ei tarvitse hikoilla dead-lineja vasten vaan voi tehdä työtä siinä puitteissa kun se vie aikaa. katso esim https://www.linkedin.com/pulse/työmääräarviointi-ohjelmistokehitysprojekteissa-ilkka-korhonen?trk=mp-author-card
- Hei_oikeesti
Miksette työ käytä Agilea?
- fkdkksjsjsj
ai sekö poistaa arvionnit vai? Ei kuule poista, hintalappu (eli työmääräarvio) pitää silti antaa ellei ostaja ole niin tyhmä että ostaa sian säkissä
- Kehari79
Noin se just toimii, kuten koodari76 sanoi.
On turhaa käyttää aikaa arvioimiseen, jos deadline tulee jo jonkun toisen suusta. Silloinkin vain tehdään töitä ja jos ei ehditä, niin harmitellaan ja kuitenkin vaan jatketaan hommia. Jos joku muu kärsii siitä, että aikataulu ei sitten pidäkään, niin hän kyllä oppii äkkiä. Softa ei ole maitokauppaa.
Tämä on hyvin yksinkertaista, kun sen ymmärtää ja stressikin helpottaa, kun tiedät ettet pystyisi parempaankaan suoritukseen. Sinä tiedät jo etukäteen miten asiat tulevat menemään, joten sen päälle on helppoa rakentaa uraa. Anna hölmöjen hölmöillä - se ei ole ollenkaan sinun ongelmasi.
Minusta olisi paljon hirveämpää olla myynnissä tekemässä lupauksia asiakkaan kasvojen edessä kuin koodailemassa kahvikupposen ääressä.
Maanantaina taas iloisena hommiin!- kekdkkndnsks
Vai että kahvikupposen ääressä. Tehostamista tarvitaan! Kyllä ne välineet sinunkin tuottavuuden arviointiin löytyy!!!
- Anonyymi
kekdkkndnsks kirjoitti:
Vai että kahvikupposen ääressä. Tehostamista tarvitaan! Kyllä ne välineet sinunkin tuottavuuden arviointiin löytyy!!!
Olet selvästi ymmärtänyt tuottavuuden ja tehokkuuden käsitteet täysin väärin. Projektin myöhästyminen aikataulusta ja budjetin ylitys eivät ole merkittäviä ongelmia. Sellaista sattuu jatkuvasti ympäristössä jossa kilpailu on kovaa. Ylimääräinen työ saadaan nimittäin laskutettua asiakkaalta, kunhan sopimukset ovat toimittajan puolella kunnossa ja ”selvityksiä” riittää.
Tärkeintä projekteissa on saada syy ongelmista jonkun muun kuin asioista päättäneiden johtajien niskaan, jotta yhteistyö sopimuksen toisen osapuolen kanssa voi jatkua. Tämä pätee erityisesti pääkaupunkiseudulla, missä suorittavan tason työntekijöitä löytyy huomattavasti helpommin kuin uusia asiakkaita.
- qröjlk
Itsekin olen törmännyt vastaavaan tilanteeseen, että aikataulut on joku soppariin jo laittanut mun puolesta ja työmäärä on vähintään puolet liian pieni. Ihan kivahan siinä on sitten projektia vääntää kun tietää jo lähdössä, että ei ehdi tekemään. Sitten vaan mietitään, että mihinköhän nää tunnit pitäisi kirjata kun budjetti on jo käytetty ja asiakas ei maksa enempää.
- Anonyymi
Yleensä ne deadlinet määrittää ihminen, jolla ei ole alalle mitään kokemusta tai asiaa.
Aina kannattaa muistaa, ettei ei kannata vetää itseään hirteen muiden virheistä tai osaamattomuudesta.
Ketjusta on poistettu 0 sääntöjenvastaista viestiä.
Luetuimmat keskustelut
Mielessäni vieläkin T
Harmi että siinä kävi niinkuin kävi, rakastin sinua. Toivotan sulle kaikkea hyvää. Toivottavasti löydät sopivan ja hyvän381903Pupuhuhdasta löytyi lähes sadan kilon miljoonalasti huumeita
Pupuhuhdasta löytyi lähes sadan kilon miljoonalasti huumeita – neljä Jyväskylän Outlaws MC:n jäsentä vangittu: "Määrät p431476Nellietä Emmaa ja Amandaa stressaa
Ukkii minnuu Emmaa ja Amandaa stressaa ihan sikana joten voidaanko me koko kolmikko hypätä ukin kainaloon ja syleilyyn k61411- 171408
Persut petti kannattajansa, totaalisesti !
Peraujen fundamentalisteille, vaihtkaa saittia. Muille, näin sen näimme. On helppo luvata kehareille, eikä ne ymmärrä,131384Nähtäiskö ylihuomenna taas siellä missä viimeksikin?
Otetaan ruokaöljyä, banaaneita ja tuorekurkkuja sinne messiin. Tehdään taas sitä meidän salakivaa.11375Sinäkö se olit...
Vai olitko? Jostain kumman syystä katse venyi.. Ajelin sitten miten sattuu ja sanoin ääneen siinä se nyt meni😅😅... Lis21347Housuvaippojen käyttö Suomi vs Ulkomaat
Suomessa housuvaippoja aletaan käyttämään vauvoilla heti, kun ne alkavat ryömiä. Tuntuu, että ulkomailla housuvaippoihin11280Hyvää yötä ja kauniita unia!
Täytyy alkaa taas nukkumaan, että jaksaa taas tämän päivän haasteet. Aikainen tipu madon löytää, vai miten se ärsyttävä21220Lepakot ja lepakkopönttö
Ajattelin tehdä lepakkopöntön. Tietääkö joku ovatko lepakot talvella lepakkopöntössä ´vai jossain muualla nukkumassa ta51207