Als we er met een duidelijke logica naar kijken, worden wij frontend developers aan het einde van deze stroom beschouwd, omdat er een behoefte of probleem opduikt, er ideeën voor dit probleem worden gegenereerd, ontwerpen worden gemaakt en daarna komt het naar de developer, wordt er een output gemaakt en aan de gebruikers gepresenteerd. Echter, wat we bij een eerste blik over het hoofd zien, maar wat het belangrijkste bepalende element van deze stroom is, zijn wij die de output gaan leveren. Daarom zijn onze competenties, beschikbaarheid, de ideeën die we kunnen bijdragen en onze prioritaire taken parameters die niet genegeerd kunnen worden in het vinden van een oplossing voor dit probleem, omdat het werk dat tot dit punt snel is gekomen, niet echt nuttig is als het bij ons vastloopt en niet wordt afgerond. Stel dat we een nieuw product hebben dat door X is geproduceerd en er een geschikt panel geschreven moet worden. De meest fundamentele wens hier is dat dit panel uiterlijk samen met het product is afgerond en volledig voldoet aan de behoeften. Nadat deze wens bij ons is aangekomen, kan hoe we hierop reageren, onze gesprekken hierover, onze feedback met betrekking tot geschiktheid, enzovoort, de stroom beïnvloeden en kan het zelfs leiden tot een volledige wijzigingsbehoefte voor sommige modules.
Als we dieper ingaan, voordat op deze wens wordt gereageerd, begint de discussie voor de frontend-kant, of het wordt door onze hogere managers geleid voordat het verzoek bij ons aankomt. Het meest fundamentele onderwerp dat wordt besproken en het eerste punt is hoe dit project zal worden uitgevoerd, met welk framework, op welk systeem kan het worden opgebouwd. Laten we aannemen dat er opties bestaan zoals a, b en c die gekozen kunnen worden en die qua resultaat voor de eindgebruiker vergelijkbaar zijn. Hier komt de bekwaamheid van de developers die aan het project kunnen werken om de hoek kijken bij het nemen van de beslissing. Als het met A gedaan zou worden, omdat de gekozen developers voor dit project niet voldoende zijn, zou de leertijd 10 maanden zijn; als het volgens methode b zou worden gedaan, hebben we 1 developer die hiervoor geschikt is, dus 8 maanden; als het volgens methode c gedaan zou worden, zijn er 2 developers wiens vaardigheden hiervoor geschikt zijn, dus kunnen we in een korte tijd van 3 maanden een output verkrijgen. Hier wordt verder gegaan met de optie c, die zowel voor het afronden van het werk als in termen van kosten geschikt is. In dit soort gevallen komt de bal steeds bij ons terug, en omdat de meest geschikte manier is gevonden en zowel de workflow als de ontwerpen in deze richting zijn gegaan, kan het project zowel in een zeer korte tijd als foutloos worden afgerond, omdat bekend is hoe verder te gaan.
Als het hier niet zo zou zijn en de stroom eenvoudigweg zou voortzetten; idee gevormd, ontwerp is dit, jullie gaan dit zo doen, zou de mogelijkheid van een gebrek aan beheersing van het onderwerp en de kans op ongepaste keuzes ervoor zorgen dat er mogelijk niet 100% op de verzoeken kan worden geantwoord, het voltooien van het project zou kunnen worden vertraagd en zou kunnen leiden tot een onvoorspelbaar resultaat in termen van kosten.
Het is mogelijk om dergelijke voorbeelden te vermenigvuldigen, maar als we fundamenteel kijken, zijn de uitspraken van ons als frontend developers van groot belang bij het nemen van beslissingen over elke stap die aan de gebruiker zal worden getoond, om het werk zo snel en zo geschikt mogelijk te kunnen afronden.
