Welk antwoord moet ik geven?

Dit antwoord is voor de rol van softwareontwikkelaar ( geen directe ondergeschikten ) :

Het simpele antwoord hier is de waarheid . En in dit specifieke geval, als u weet de deadline niet gehaald zal worden, is het het beste om de waarheid eerder dan later te vertellen.

In principe willen ze weten dat je het feit dat je je deadline niet gaat halen niet gaat verbergen en zijn niet bang om om hulp te vragen .

Zo'n baan krijg je nooit door een antwoord te herhalen dat je op een site als deze hebt gekregen. U moet leren hoe u die vraag in uw woorden kunt beantwoorden, gebruikmakend van uw ervaring en voorbeelden waar u daadwerkelijk deel van uitmaakt. Dat gezegd hebbende, kunt u een beter antwoord vinden om ze de volgende keer te geven. Het belangrijkste is om te begrijpen waarom ze het vragen. Ze denken dat ze weten wat ze in die situatie wel en niet moeten doen, en ze willen zien of jij dat ook doet.

Een goed antwoord bevat twee dingen. Ten eerste zou u gemakkelijk in staat moeten zijn om uw opties op te sommen: de klant vertellen dat de deadline niet gehaald zal worden, een deel van het werk laten vallen, dat soort dingen. En deze lijst mag geen dingen bevatten die niet werken, zoals het toevoegen van mensen aan het project. Ten tweede zou u moeten kunnen uitleggen hoe u uit die opties zou kiezen en hoe u in de situatie zou communiceren. Als je gewoon zegt "ik zou X" zonder enige uitleg waarom X in plaats van Y, is dat geen goed antwoord.

Als je solliciteert naar een projectmanagementfunctie, verwachten ze enigszins andere opties en denkprocessen dan wanneer je solliciteert als een ontwikkelaar die zonder de ondersteuning van PM werkt, maar de basis "Ik zou een keuze hebben uit X of Y, ik zou A of B niet overwegen, en ik zou X of Y kiezen op basis van Z "zal er nog steeds zijn.

Als je hier geen goed antwoord op hebt en het meer dan eens bent gevraagd, zorg dan voor een goed antwoord. Je hebt dit zeker meegemaakt? Zelfs als je zag dat iemand anders het afhandelde in plaats van het zelf af te handelen? Wat werkte, wat niet, wat heb je eerder in die situatie gedaan? Word beter in het vertellen van dat verhaal.

Dit is ook een gelegenheid om, na het beantwoorden van de vraag , te praten over hoe belangrijk het is om niet in die situatie terecht te komen en wat je doet om dit te voorkomen. Dit kunnen regelmatige statusbijeenkomsten zijn, frequente releases, weerstand bieden aan scoop van de scope, voortgang bijhouden of een aantal andere technieken die u in uw werk hebt geleerd. De interviewer wil weten wat u kunt doen.

Als softwareontwikkelaar is het niet mijn taak om dat soort problemen met de klant te bespreken, en als softwareontwikkelaar is er niets dat ik persoonlijk kan doen om dit op te lossen het probleem.

Dus de enige verstandige manier van handelen is om zo snel mogelijk contact op te nemen met de programmamanager om hen ervan bewust te maken dat er een probleem is, en met hen te bespreken wat er kan worden gedaan om het project terug te brengen op schema.

Het antwoord kan zijn om meer mensen aan de baan toe te wijzen, om met de klant over een latere deadline te onderhandelen, of verschillende andere opties. Maar de beslissing is niet aan mij.

Of wat verwachten ze te horen?

Ze willen zien hoe je dit soort vragen overdenkt en verwerkt.

Ze willen niet dat je probeert hen te vertellen wat je denkt dat ze willen horen. Ze willen geen standaardantwoord horen.

Het is moeilijk, maar probeer niet te raden wat ze willen horen. Luister in plaats daarvan naar de vraag, denk erover na en beantwoord eerlijk. Probeer jezelf in de gestelde situatie te verplaatsen en vertel hen hoe je zou reageren.

En als je de situatie daadwerkelijk bent tegengekomen, zorg er dan voor dat je aangeeft dat je dat hebt gedaan, wat je hebt gedaan en of je zou doen hetzelfde weer.

Grappig dat dit een van de vragen was, mijn antwoord waarop (denk ik) mij een van mijn vorige banen gaf. Het was geen goede baan, want zulke situaties kwamen daar veel voor. Maar het was relevant voor die baan (en zou me een hint moeten geven om het niet aan te nemen).

Ik vertelde wat we deden bij een van de projecten waaraan ik deelnam:

We waren in een onmogelijke situatie: in een klein bedrijf hadden we het contract nodig om ons de komende maanden in leven te houden. Het was een uitbreiding van ons (boekhoud) systeem dat we wilden implementeren, maar de deadline om het te voltooien was onmogelijk. Dus we begonnen het toch te implementeren, met onze beste inschattingen hoe het te doen, en publiceerden een groot document met veel vragen waarin we vroegen hoe ze de nieuwe functionaliteit precies wilden implementeren. En we vertelden hen dat het X maanden zou duren nadat we de definitieve antwoorden zouden ontvangen.

Raad eens: het kostte hen maanden om onderling overeen te komen wat ze precies wilden, terwijl wij implementeerden de beste gok. We hebben het contract, enkele mijlpaalbetalingen van de klant. In de meeste gevallen hadden we het goed geraden, enkele gevallen moesten we opnieuw ontwerpen, enkele functies werden uitgesteld tot fase twee, maar het bedrijf heeft het overleefd om nog een dag te vechten.

Ik weet niet zeker of je zo'n antwoord gewoon kunt vervalsen (omdat dit is een waar oorlogsverhaal, elke vervolgvraag zou je als nep kunnen onthullen als je het niet hebt meegemaakt).

In een situatie waarin je leeft of sterft, wordt je gedwongen om risico's te nemen met hoop dat je geluk zult hebben, want anders gaat het bedrijf toch dood. Niemand schrijft over de honderden mislukte startups, alleen de succesvolle worden genoemd. Zie vooringenomenheid bij overlevingskansen - u gaat ervan uit dat u het zult overleven.

Volgens Team Software Process (door Carnegie Mellon University) moet u met de belanghebbenden communiceren zodra het team weet dat de deadline niet kan worden gehaald. Hierdoor kunnen alle geïnteresseerde partijen opnieuw plannen, functies verwijderen of iets doen om het probleem op te lossen (het niet halen van de deadline).

Volgens de Mythical Man Month, door Fredrick Brooks Jr., zal het toevoegen van meer mensen aan een project de planning niet verkorten.

In termen van projectmanagement is er de driehoek met kanten van scope, tijd en budget. Als een van de zijden verandert (in lengte), moeten de andere twee ook veranderen.

Dus, om de vraag van de interviewer te beantwoorden:

1. Bereken een nieuwe deadline op basis van de huidige omstandigheden. Bepaal de kans om de deadline met succes te halen.
2. Bereken de duur die nodig is om de resterende vereisten te voltooien. Bepaal de kans om de deadline te halen met deze techniek.
3. Bereken een nieuwe deadline op basis van het toevoegen van middelen aan het project. Dothis voor 1 persoon tot 5 personen. Bepaal met deze techniek de kans om de deadline te halen.
4. Bel een vergadering met de belanghebbenden om de situatie en de herplanning te bespreken. Gebruik de informatie uit items # 1, # 2 en # 3. hierboven.

De informatie van # 1, # 2 en # 3 moet afkomstig zijn van de teamleden (die het werk doen). Ze staan ​​het dichtst bij het project en kunnen met de hoogste mate van zekerheid informatie geven.

IMHO, plan alleen overwerksessies als de doorlooptijd klein is. Er is geen garantie dat overwerk de kwaliteit van het product zal verbeteren; soms kan overwerk meer problemen opleveren en het rooster verlengen.

Bij een winkel waar ik werkte, werden vereisten uit het project verwijderd om de planning te verminderen.

Dit zou mijn antwoord zijn, als mijn rol een projectmanager was:

Als ik denk dat we een deadline niet kunnen halen, moet ik eerst vaststellen is wat er nodig is in termen van mankracht en andere middelen om het doel te bereiken.

Dan moet ik naar mijn management gaan en samen kunnen we beoordelen of het de moeite waard is om de extra middelen te besteden. om het project af te ronden.

Als het management duwt tegen extra middelen, zou ik naar de klant gaan en de situatie uitleggen, en een beperking van de omvang van het werk aanbevelen, totdat het werk haalbaar wordt in het tijdsbestek. Ik zou met de klant samenwerken om het werk te prioriteren om ervoor te zorgen dat de impact van de klant tot een minimum wordt beperkt.

Als de klant weigert de reikwijdte te verkleinen of de werkprioriteit te bespreken, zou ik de vereisten zorgvuldig analyseren om te zien wat de reeks te leveren producten die de schade aan de reputatie van mijn bedrijf beperkt, en bovendien eventuele financiële sancties die van toepassing zijn. Ik zou de klant heel duidelijk willen maken wat er in dat tijdsbestek zal worden geleverd, om de impact van de klant te verminderen.

Ik kan me voorstellen dat klanten in sommige situaties meer ontvankelijk kunnen zijn voor heronderhandeling als ze dat beseffen ze zullen niet alles krijgen wat ze willen, en ze willen een betere controle hebben over wat ze wel krijgen. Ze zijn misschien ook bereid om de "harde" deadline te verleggen.

Het is duidelijk dat het spijtig is dat elk project op een punt komt dat er tegen het einde een grote verrassing is. Idealiter zouden we de voortgang volgen, en dat zou ons in staat stellen de reikwijdte van het werk geleidelijk aan te passen om ervoor te zorgen dat aan de belangrijkste vereisten wordt voldaan.

Ik heb eerder een vraag in deze zin gehad, dus het is niet zo ongewoon. Naar mijn mening is het enige juiste antwoord als volgt:

Iemand heeft ergens een fout gemaakt om hier te komen, nu gaan we er het beste van maken door een spoedvergadering te organiseren en te zien wat is mogelijk in plaats van wat niet.

Weten dat je gaat falen en het toch doen zou het verkeerde antwoord zijn. Als het niet kan, kan het niet worden gedaan. Toch zul je vaak situaties tegenkomen die eruit zien alsof ze je vragen het onmogelijke te doen.

De absolute sleutel hier is om te achterhalen wat is mogelijk is en van daaruit werken. Dit is geen vraag over hard software engineering. Dit is een vraag over het managen van verwachtingen, omgaan met het onverwachte en een project bij elkaar houden.

Het betekent ook dat ze op zoek zijn naar meer dan iemand die alleen maar code schrijft. Ze zijn op zoek naar iemand met een vleugje leidinggevende capaciteiten of komen er in ieder geval achter of je die hebt. Want welk antwoord je ze ook geeft, hoe je ze het antwoord geeft, zal ze veel vertellen over hoe je over projecten denkt.

Een mogelijke follow-up zou kunnen zijn (ofwel als een vraag van hen of als een antwoord van jou als ze lange antwoorden verwachten) hoe om te gaan met de gevolgen en de kans te verkleinen dat het opnieuw gebeurt.

Er is dus een deadline en het is onmogelijk deze te halen. Wat je ook antwoordt, wat je ook doet, een ding dat niet zal gebeuren, is dat je de deadline haalt. Dit is wat u en uw manager kunnen doen:

1. Vertel het uw manager zo snel mogelijk om hem de kans te geven de schade tot een minimum te beperken. Het missen van een deadline met $ 10.000 aan financiële schade is een stuk beter dan het missen van een deadline met $ 100.000 aan financiële schade.

2. Raak niet in paniek, kalmeer en kalmeer alle anderen. Ernstig. Ik heb in die situaties volwassenen zien fladderen als kippen zonder kop. Ik heb ooit hetzelfde gedaan toen ik een stuk jonger was en daarvan heb geleerd. Nu weet ik dat je in plaats van rond te fladderen en niets gedaan te krijgen, het probleem in je hoofd verandert van het onoplosbare "Hoe haal ik een deadline die onmogelijk te halen is" in "Hoe minimaliseer ik de schade".

3. De methode die niet werkt, is proberen te haasten, of proberen meer mensen toe te voegen. Wat wel helpt, is om mensen secundaire dingen te laten doen. Als u bijvoorbeeld code moet schrijven en uitprobeert, schrijft u de code en probeert iemand anders het uit. Een andere methode die uw manager kan gebruiken, is uw vermogen om meer uren te werken verbeteren. Er is een leuk hotel 100 meter van mijn werkplek. Ik kan meer uren doen als mijn baas ervoor betaalt dat ik in dat hotel logeer, en gezond eten bestelt om rond lunchtijd aan te komen, en gezonder voedsel om 17.00 uur. Op een keer moest er iemand bij mij thuis zijn om meubels te laten bezorgen. De vrouw van mijn baas deed dat. Ze was niet blij, maar mijn baas had me nodig om te werken. Dat soort dingen is ook behoorlijk motiverend.

4. Er zijn twee voor de hand liggende methoden om eerder klaar te zijn: kwaliteit verlagen en functies verminderen. Dat moet worden besproken.

5. Er is een voor de hand liggende methode om een ​​deadline te halen die mensen vaak vergeten (want zie punt 2): verplaats de deadline. Er zijn maar heel weinig deadlines die niet kunnen worden verplaatst. Zie de ingenieuze methode van Peter M.. Gefeliciteerd als je dat voor elkaar kunt krijgen. Makkelijker is vaak om gewoon te onderhandelen. Dat is waarschijnlijk een of twee niveaus boven u gedaan. Maar als je de klant duidelijk maakt dat er geen kans is dat hij het beloofde ding op het beloofde tijdstip krijgt, hebben ze de keuze om de deadline te verlengen of niets te krijgen.

6. Ik hoop dat het niet zover komt, maar de eerste rat die van een zinkend schip springt, heeft de beste kansen om te overleven.

Ik heb het gevoel dat sommige anderen een te zwakke versie van "harde deadline" construeren.

Ik ben nooit premier geweest, maar bij meer dan één gelegenheid heb ik de waarheid moeten vertellen aan de CEO terwijl iedereen, inclusief de premier die het had moeten weten, stil was. We hebben bepaalde wettelijke vereisten, en wanneer de vereisten van de wet veranderen, moeten we onze code aanpassen zodat deze overeenkomt, en de deadlines worden bepaald door de overheid. De waarheid was: "Die dag is al voorbij."

Ik was er al een hele tijd. Ik wist hoe lang het zou duren van interne technische release tot productie. Ik had net de testlogboeken bekeken en wist hoe lang het testen zou duren. Ik had een heel goede schatting van het aantal items dat werd teruggestuurd naar mislukte tests, gebruikte een laag cijfer voor de doorlooptijd en een heel goed cijfer voor de hertesttijd. Ik heb de cijfers bij elkaar opgeteld en er staat dat we -1 dagen hadden om de ontwikkeling voort te zetten. Ik kan me niet herinneren hoe de uitleg van dit alles verliep (wat meteen gebeurde), maar ik herinner me alleen mijn openingsverklaring.

Vanwege beperkingen op het gebied van bronbeheer waar het management eerder niet om gaf, konden we niet besluiten voltooide functies te laten vallen om de testtijd te verminderen, zodat deze dingen niet verbeterd konden worden.

Helaas kon ik ze niet zeggen hoeveel dagen ze realistisch gezien konden verwachten, dus accepteerden ze mijn antwoord niet. Maar bij de interne demo van de wettelijk vereiste functies de volgende week vroeg het management om ingrijpende wijzigingen daarin. Kom maar.

Uiteindelijk leverden we anderhalve maand te laat op.

Tussen een rots en een harde plek? Kom aan de andere kant van de rots. Bied de klant een demo van gedeeltelijke functionaliteit in de helft van de tijd tot hun deadline. Je zult ze overrompelen en ze in het gesprek betrekken. Als je ze wekelijks binnenhaalt om te bespreken welke functionaliteit die week is verbeterd, zul je snel ontdekken dat hun vereisten niet 100% waren van wat ze nodig hadden, en tegen de tijd dat de deadline nadert, heb je misschien wel 'iets' dat ze kunnen gebruiken, zelfs als het voor 80% functioneel is, bent u uw watervalconcurrentie ver voor.

Alles gezegd tegen de nominale waarde, is de beste optie om meer werk aan dit project te beschouwen als tijdverspilling en in plaats daarvan door te gaan naar het volgende project. Dat is niet de beslissing van een softwareontwikkelaar.

Dit gebeurt niet in het echte leven. Ik ben in situaties als deze geweest en de oplossing was in feite om de klant te geven wat ze wilden zien. Die veranderde van onleesbare gegevens (niet helemaal het juiste formaat maar niet opzettelijk) in nepgegevens (gegenereerde of testgegevens die de schrijfroutines doorstaan) naar dingen die met handmatige tussenkomst zijn voorbereid, naar met de hand geselecteerde werkvoorbeelden naar het echte werk.

Dit kan betekenen dat je moet samenwerken met het feitelijke contracterende bedrijf om stroomafwaartse ontvangers te overtuigen om ook het wachtspel te spelen: dingen moeten eruitzien alsof er zo weinig ontbreekt dat het weinig zin heeft om af te breken.

Ik heb onderaannemingscontracten genomen van incompetente aannemers met goede zakenrelaties en goed betalen, waarbij de belangrijkste prioriteit was om altijd je reet te dekken, deadlines veilig te berekenen en werkend en goed gedocumenteerd materiaal te produceren dat je ze elke keer laat ondertekenen aangezien het regeringsproject beslist op weg was naar een noodlanding en je niet de zondebok wilde zijn onder het instortende landingsgestel.

Deze vuilnisbrand werd ongeveer twee jaar na de 'harde' dood geannuleerd. dline, lang nadat ik heb afgeleverd en opgehaald. Dit is de reden dat de juiste reactie op het zeker falen van een harde deadline zelden is om op te geven: sommige deadlines kunnen leiden tot sancties die men wil vermijden. Maar de deadlines die een lopend project voorgoed doden, zijn zeldzaam en de uiteindelijke beslissing kan heel goed vallen op een moment dat u zich niet bewust bent.