Als we er met een rechttoe-rechtaan logica naar kijken, worden wij frontend developers aan het einde van deze stroom gedacht, omdat er een behoefte of probleem opkomt, er ideeën worden gegenereerd om dit probleem aan te pakken, ontwerpen worden gemaakt en vervolgens gaat het naar de developer om een output te creëren die aan de gebruikers wordt gepresenteerd. Maar wat we bij de eerste blik over het hoofd zien, maar wat het belangrijkste element is dat deze stroom bepaalt, zijn wij die de output zullen geven, daarom zijn onze competenties, beschikbaarheid, de ideeën die we aan het project kunnen bijdragen, onze prioritaire taken en dergelijke parameters cruciaal in het vinden van een oplossing voor dit probleem. Want totdat het werk zo ver gevorderd is en bij ons vastloopt, heeft het niet veel nut. Stel dat we een nieuw product van een eenheid X hebben en er moet een passend paneel worden geschreven. Hier is de belangrijkste wens dat dit paneel uiterlijk samen met het product wordt afgerond en compleet is om 100% aan de vereisten te voldoen. Nadat deze wens ons heeft bereikt, kunnen onze reacties op hoe we hierop zullen reageren, onze gesprekken hierover, de feedback die we geven over geschiktheid, enzovoorts de stroom beïnvloeden, en kunnen ze zelfs de behoefte aan een volledige wijziging voor sommige modules met zich meebrengen.
Als we iets dieper ingaan, voordat er op deze wens wordt gereageerd, wordt de discussie over de frontend kant ofwel gestart nadat de wens ons is bereikt ofwel door onze hogere managers geleid, de basiskwestie die in de discussie wordt aangekaart en het eerste punt is hoe dit project zal worden uitgevoerd, met welk framework en op welk systeem het gebouwd kan worden. Laten we aannemen dat we opties a, b en c hebben die kunnen worden gekozen en die qua uiteindelijke resultaten voor de eindgebruikers vergelijkbaar zijn. Bij het nemen van deze beslissing komt de bekwaamheid van de developers die aan het project kunnen werken in beeld. Als optie A wordt gekozen en de geselecteerde developers voor dit project niet voldoende zijn, zou het 10 maanden duren door het leerproces; als optie B wordt gekozen, hebben we 1 developer die eraan voldoet, dus het zou 8 maanden duren; als optie C wordt gekozen, zijn de vaardigheden van 2 developers hiervoor geschikt, waardoor we het in bijvoorbeeld 3 maanden kunnen afronden. In dit geval wordt verder gegaan met optie C, die zowel geschikt is om het werk te voltooien als kosteneffectief is. In dit soort gevallen komt de bal steeds bij ons terug, en aangezien de meest geschikte weg is gevonden, en zowel de workflow als de ontwerpen in deze richting zijn voortgezet, kan het project zowel zeer snel als foutloos worden afgerond, omdat duidelijk is hoe verder te gaan.
Als het hier niet zo was en er een rechttoe-rechtaan stroom was gevolgd; als er een idee werd gecreëerd, werd het ontwerp dit, en jullie zouden het zo doen, dan zou het gebrek aan beheersing van het onderwerp en de kans op een onnauwkeurige keuze ervoor kunnen zorgen dat er geen 100% antwoord op de verzoeken kon worden gegeven, de voltooiing van het project zou kunnen vertragen, en het zou kunnen leiden tot een niet-voorspelbaar resultaat wat betreft kosten.
Het is mogelijk om meer van dit soort voorbeelden te vermenigvuldigen, maar als we er op een fundamentele manier naar kijken, is het van groot belang dat de uitspraken van ons frontend developers worden meegenomen bij het nemen van beslissingen bij elke stap die aan de gebruiker wordt getoond, zodat het werk zo snel en efficiënt mogelijk kan worden afgerond.
