Page 2 of 2 FirstFirst 1 2
Results 16 to 20 of 20

Thread: Gestandaardiseerd programmeren

  1. #16
    Dan ga je datgene bouwen wat je samen met de klant op dit moment kunt bedenken. Mijn ervaring leert (en niet alleen die van mij heb ik het idee) dat veel muntjes bij de klant (en bij de analist) pas gaan vallen tijdens het ontwikkelproces. Je kunt je dan inderdaad strak aan het document houden zodat je binnen budget en op tijd klaar bent. Maar dan heb je een product waarvan de klant inmiddels weet dat hij het niet wil. Dat is veel duurder dan tijdens het ontwikkelproces bijsturen in wat je doet waardoor tijd en/of budget misschien wel worden overschreden, maar er wel een product komt waar de klant direct mee aan de slag kan.

    Ik weet van mijn klanten wel voor welke optie ze kiezen.
    Marcel

  2. #17
    Jup, en dat geldt intern net zo goed als extern. Het laatste grote project voor we gingen scrummen, is gebouwd op basis van duimendikke FO's en TO's. Het heeft een jaar intensief proggen gekost. In die tussentijd is de hele koers van het bedrijf veranderd en hadden we die functionaliteit eigenlijk niet in die vorm nodig, maar daar kwamen we eigenlijk pas achter toen de eerste pilot in gebruik genomen werd. Daarna heeft het nog maanden gekost voor het weer teruggebracht was tot 'bruikbaar', maar we zitten alsnog met een groot systeem dat niet doet wat we nodig hebben.
    Het is een beetje alsof je briefjes zit te typen in Excel i.v.p. Word. Een prima werkende Excel, dat wel, maar het is geen Word.

    Maargoed. Een boekadvies..

    Een boekje dat je na een paar jaar wel ontgroeit, maar dat erg leuk is als beginnende professional:
    http://www.nldelphi.com/Forum/showthread.php?t=27125

    Staat los van welke 'methode' je gebruikt; het bevat vooral een hoop gezond verstand.
    1+1=b

  3. #18
    mov rax,marcov; push rax marcov's Avatar
    Join Date
    Apr 2004
    Location
    Ehv, Nl
    Posts
    10,357
    A.s. onze klanten zijn typisch vestigingen van de kleinere, niet zo high tech multinationals. Productie bedrijven. Wat onze klanten betreft de uitzonderingen daarop, zijn van hetzelfde soort, maar dan typisch een site met een soort voortrekkersrol binnen het concern vanwege b.v. een research afdeling erbij, of meer experimentele techniek

    Quote Originally Posted by Marcel View Post
    Dan ga je datgene bouwen wat je samen met de klant op dit moment kunt bedenken.
    Dat is precies wat je niet wil in een fixed price situatie. Het probleem is dat de klant die specificeert, en de klant die betaalt in ons geval typisch verschillend zijn (normaal resp. technische dienst en inkoop). TD zal geen probleem hebben met creep, maar inkoop rekent je daar keihard op af, en interesseert het in eerste magnitude totaal niet wat er operationeel gebeurd. Hun taak is dat projecten niet over budget gaan, en andere dingen kunnen ze niet beoordelen. Verder geeft TD alleen een vastgesteld budget uit, en qua grote uitgaven kunnen en mogen ze daar ook niets.

    In theorie zou er een management moeten zijn om dit soort tegengestelde belangen van afdelingen in goede banen te leiden, maar die kom ik in praktijk maar zelden tegen. Strak operationeel management op de werkvloer is erg, erg zeldzaam. Er is wel iemand met de titel, maar die vaak meer bezig met concern communicatie dan de werkvloer.

    Mijn ervaring leert (en niet alleen die van mij heb ik het idee) dat veel muntjes bij de klant (en bij de analist) pas gaan vallen tijdens het ontwikkelproces.
    Dat is waar. Maar dat is geen reden om dan stuurloos te worden. Dit wordt bij ons typisch opgelost door bij onzekerheid projecten kort te houden. B.v. kort lopende onderzoeks projecten.

    (de fout om dit niet te doen kan je goed in Goleztrol analyse zien. Daar wordt er vanuit gegaan dat SCRUMM betekent dat je het project in SCRUMM zin van te voren de maximale omvang geeft.)

    Je kunt je dan inderdaad strak aan het document houden zodat je binnen budget en op tijd klaar bent. Maar dan heb je een product waarvan de klant inmiddels weet dat hij het niet wil.
    Dit is ook niet waar. Het enige wat dan gebeurt als de klant dit ziet aankomen is dat er onderhandeld moet worden. Dit vermijdt dat een strak ingestuurd project door een boel kleine koerswijzigingen en details over budget gaat.

    Maar bij grote problemen valt er altijd wat te regelen, en is het VEEL makkelijker de klant in te laten zien dat de koers verandert (door de huidige situatie met de oude documenten te vergelijken) is dan wanneer dat door creep gebeurd, en de klant het gevoel heeft dat het allemaal "wel lekker" gaat. Terwijl jij de financiële bui al ziet hangen.

    Oftewel, het is vooral van belang dat de doelen op elk moment vast staan, niet dat ze totaal invariant zijn. Een andere belangrijke reden om een strakke project omschijving met voldoende detail vooraf te hebben is om mogelijk bepaalde trajecten te kunnen parallelliseren. (want met name in multinationals met hun gecentraliseerde service departments (IT,finance,centrale TD, inkoop, externe partijen) zijn sommige processen relatief traag)

    Dat is veel duurder dan tijdens het ontwikkelproces bijsturen in wat je doet waardoor tijd en/of budget misschien wel worden overschreden, maar er wel een product komt waar de klant direct mee aan de slag kan.

    Ik weet van mijn klanten wel voor welke optie ze kiezen.
    Kies:

    1) doe maar allebei met een selectie mogelijkheid
    2) eigenlijk willen ze een doosje met twee knoppen. Eentje met "Doe wat ik denk" en "reset" (de laatste voor de controle freaks)

    Andere fundamentele keuzes heb ik zelden van klanten gezien als ik ze niet gesouffleerd heb.

    In de laatste situatie is er soms een probleem tussen "doe wat ik denk" en wat er achteraf had _moeten_ gebeuren. Maar dan geef ik aan dat onze machines goed zijn, maar nog niet toekomst voorspellend zijn. Dat bewaar ik voor (major release op dit moment +1)

    P.s. het moge duidelijk zijn dat dit allemaal ietwat overdreven is. Maar dat komt deels ook doordat grote koerswijzigingen veel zeldzamer zijn dan in deze thread voorgespiegeld wordt.
    Last edited by marcov; 19-Jan-12 at 13:02.

  4. #19
    Korte projecten, tussendoor onderhandelen, kijken of er wat te regelen is. Volgens mij hebben we het gewoon over dezelfde projectaanpak?
    Marcel

  5. #20
    mov rax,marcov; push rax marcov's Avatar
    Join Date
    Apr 2004
    Location
    Ehv, Nl
    Posts
    10,357
    Nee. Ik doe het niet uit principe, alleen als ik onzekerheid bij opstellen originele specs ontwaar. Oftewel 90% van de projecten komt wel met ruwweg de voorafgestelde specs af. En belangrijker, op tijd en binnen budget.

Page 2 of 2 FirstFirst 1 2

Thread Information

Users Browsing this Thread

There are currently 1 users browsing this thread. (0 members and 1 guests)

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •