Het project op het juiste spoor houden is een veelvoorkomende uitdaging voor veel technologische bedrijven die zich primair richten op tijdige en efficiënte productontwikkeling. Ik lees dit tussen de regels door van regelmatige gesprekken met onze klanten en partners. Ik wil graag een interessant verhaal met jullie delen in de hoop dat het jullie ook zal inspireren en zal helpen bij het oplossen van jullie veelvoorkomende problemen met betrekking tot het effectief beheren van softwareontwikkelingsprojecten.
Wat is de kern van de zaak?
Hier zijn enkele redenen die we vaak horen:
- We werken aan ons nieuwe product/start-up en de time-to-market is cruciaal voor ons en onze investeerder(s).
- We hebben belangrijke releases of nieuwe functies in de pijplijn en moeten deze echt op tijd uitbrengen.
- We hebben de ontwikkelingspijplijn gepland tot het einde van het jaar en willen een comfortabele situatie hebben in het vierde kwartaal, zodat we onnodige haast en stress vermijden.
Zoals je kunt zien, is het beheren van de project bezorgt elke technische manager heel wat hoofdpijn. Ze vragen zich vaak af hoe ze het werk van de ontwikkelaars moeten organiseren. team om vertragingen te voorkomen en ervoor te zorgen dat alle geplande product functies soepel en tijdig worden ontwikkeld. Onnodig te zeggen dat een potentieel 'gat' en stagnatie in de ontwikkeling pijnlijke gevolgen kan hebben. Te optimistische planningen, gebrek aan ontwikkelaars, slecht georganiseerd werk, enz. kunnen ertoe leiden dat je project achterloopt op de deadline.

De methode van Moskou
Laten we beginnen met een korte uitleg over wat de MOSCOW-methode precies is. Het is een speciale prioriteringstechniek die wordt gebruikt in projectmanagement en softwareontwikkeling overeenstemming bereiken met belanghebbenden (klanten of leden die betrokken zijn bij een project) over het belang dat zij hechten aan de levering van elke vereiste.
Dus ik denk dat een goede oplossing voor elke technische manager is om de MOSCOW-methode (met zijn categorieën zoals 'moeten', 'zouden moeten', 'zouden kunnen', 'zullen niet') bij te spijkeren. De uitvoering van de eerste twee categorieën - 'moeten' en 'zouden kunnen' - is meestal moeilijk. Het aantal taken dat moet worden uitgevoerd - soms met beperkte personele middelen, naderende deadlines of andere obstakels - is misschien niet haalbaar.
In principe hebben bedrijven verschillende benaderingen om met dit soort problemen om te gaan. Goed risicobeheer is de sleutel tot het omzetten van bedreigingen in overwinningen. Laat me een recent voorbeeld geven dat met dit onderwerp te maken heeft. Een paar weken geleden nam een projectmanager van een SaaS-productbedrijf contact met me op over de mogelijkheid om outsourcing drie software engineers voor een vaste periode van begin oktober tot eind november. Het komt voor dat bedrijven in sommige periodes ondersteuning van meer ontwikkelaars nodig hebben vanwege het aantal taken dat moet worden uitgevoerd en om het project op het gewenste ontwikkelingstempo te houden.
De genoemde Project Manager kwam met het idee om een toegewijd team van backend engineers in te huren, omdat hij wist dat onze technische stapel overeenkomt met hun core product stack. We startten het project in een flexibel en comfortabel pay-as-you-go model. Er waren niet veel lange vergaderingen, telefoongesprekken of het tekenen van een stapel ingewikkelde contracten voor nodig. We kregen een duidelijk beeld van de aard van het verzoek en in de wetenschap dat tijd hier van essentieel belang is, hebben we de set-up soepel geregeld, zodat het reddingsteam er klaar voor is.
Er zijn nog veel meer voordelen van het samenwerken met een technische partner die relevant is voor je groeiplannen. Externe ondersteuning is vooral kosteneffectief (het bespaart tot 35% van uw budget). Ontwikkelaars die zich aansluiten bij uw intern team brengt vaak extra kennis en een frisse blik in het geïmplementeerde project. Dankzij een dergelijke samenwerking elimineert de klant risico's en knelpunten met betrekking tot de deadlines, vertragingen en een lange lijst van achterstallige taken. Om terug te komen op de genoemde MOSCOW-methode: is het tempo van het leveren van taken in de categorieën 'moeten' en 'zouden moeten' het waard om compromissen te sluiten?

Is het een oplossing voor jou?
Dit is onze kijk op hoe we de projecten op schema kunnen houden. Ik ben benieuwd of jullie soortgelijke ervaringen hebben met de opzet van jullie engineeringteam? Hoe plan je de workload voor belangrijke features in je pijplijn tijdens de vakantieperiode? Welke andere methoden gebruiken jullie en raden jullie andere techmanagers aan, zodat ze een geweldige zomer hebben, niet alleen tijdens de vakantie, maar ook tijdens het soepele verloop. productontwikkeling? Laat het me weten in een privébericht hier.
Veel plezier met plannen!
Lees meer: