Als je al eens een softwareontwikkelingsproject hebt gedaan of erbij betrokken geweest bent, dan zal je het met me eens zijn dat de softwareontwikkelaars daarbij van essentieel belang zijn. Het is dan ook zaak om goed met hen door één door te kunnen.

Om het je makkelijker te maken en de kans op een succesvol project te vergroten deel ik hieronder 10 tips voor het werken met softwareontwikkelaars.

1. Niets is onmogelijk, maar alles heeft een prijs

Sommige dingen zijn verdomd bijna onmogelijk, maar als het op software ontwikkeling aankomt is bijna alles mogelijk.

Maar die uitspraak komt met een caveat: niets is onmogelijk, het kan alleen meer tijd kosten dan je hebt, meer geld kosten dan je je kunt veroorloven, of meer ontwikkelaars vereisen dan je momenteel in dienst hebt. Naar alle waarschijnlijkheid, is het een combinatie van de drie.

Hetzelfde geldt voor het bereiken van ambitieuze doelstellingen in software, maar het zal niet van de ene dag op de andere gebeuren en je zult misschien meer geld moeten uitgeven dan je dacht.

Het is niet zo dat iets niet kan; sommige dingen zijn gewoon niet praktisch.

2. Vraag ontwikkelaars niet waarom software bugs bevat

Dat is hetzelfde als een schrijver vragen waarom er typefouten bestaan.

Dat is hetzelfde als aan Lionel Messi vragen waarom hij af en toe 100% kansen mist.

Niets en niemand is perfect. Software ontwikkelaars zijn geen uitzondering.

3. Software ontwikkelaars zijn slimmer dan jij

Het zou kunnen dan je een IQ van 147 hebt, maar dan hoop ik dat je je tijd niet verdoet met dit te lezen. Ik hoop dat je ergens bezig bent de wereld te redden.

Naar alle waarschijnlijkheid zijn de software ontwikkelaars waar je mee werkt slimmer dan jij. En dat is niet erg.

Laat het je ego niet beïnvloeden of hoe je je werk doet. Leg je er bij neer. Je mag dan je hele leven bovenaan in de klas hebben gezeten, maar als het op software aankomt, sta je op hun speelveld en zijn zij de experts.

4. Respecteer de mensen die de software bouwen

Softwareontwikkelaars zijn geen robots. Ze zitten niet achter hun computer te wachten op jouw commando's.

Hoewel hun werk vaak bestaat uit mensen die hen vragen dingen te doen, betekent dat niet dat ze ervan genieten als mensen bevelen naar hen blaffen.

Naast het feit dat je iedereen met respect moet behandelen, ongeacht wie ze zijn, moet je echt aardig zijn tegen de ontwikkelaars met wie je werkt. Je moet niet alleen respectvol zijn omdat hun vaardigheden ongelooflijk gewild zijn of omdat een goede ontwikkelaar zijn gewicht in goud waard is.

Je zou respectvol moeten zijn omdat wat zij kunnen bereiken echt en geweldig is.

Als je hen respecteert zal het jouw leven gemakkelijker maken, het zal hun leven gemakkelijker maken, en je zou zelfs een paar dingen kunnen leren.

5. Luister naar de ontwikkelaars met wie je werkt

De ontwikkelaars met wie je werkt kennen de ins en outs van het platform dat ze hebben gebouwd en ze weten wanneer iets extreem moeilijk is om te doen. Of dat bepaalt hoe je te werk gaat is ter discussie, maar het is noodzakelijk dat iedereen op dezelfde lijn zit.

Je kunt proberen te vechten voor wat je wilt, en je zou kunnen winnen, maar zelfs de best geïnformeerde niet-technische mensen zien waarschijnlijk slechts 10-15% van het landschap over waarom iets wel of niet moet worden gedaan vanuit een technisch standpunt.

Onveranderlijk zullen zakelijke behoeften en de technische kant van de zaak elkaar kruisen en bepaalde handelwijzen dicteren. Dat is een feit. Maar zorg ervoor dat je flexibel bent en praat met de ontwikkelaars voordat je de wereld belooft, en het niet kunt waarmaken.

Vergeet niet: de ontwikkelaars zijn degenen die deze beloften uiteindelijk tot leven brengen. Zij kunnen maar beter instemmen met wat er ook beloofd wordt.

6. Een gesprek van vijf minuten kan op termijn grote problemen besparen

Ga er niet van uit dat iets gemakkelijk te doen is. Ga er niet van uit dat, omdat een vorig project op een bepaalde manier werkte, het volgende project hetzelfde zal doen.

Ik kan je niet vertellen hoe vaak een gesprek van vijf minuten grote problemen had kunnen voorkomen en ieders leven makkelijker had kunnen maken.

Je moet 100% communiceren van wat het ook is dat je bespreekt. Niet 80% communiceren en ervan uitgaan dat de andere 20% impliciet is of dat de andere 20% geen probleem is. Ik heb me verbaasd over het feit dat iets waarvan ik dacht dat het eenvoudig of impliciet was, niet eenvoudig is en niet impliciet was.

Zoals Cosmo Kramer zei: "Aannemen? Neem nooit iets aan!" To Assume makes an ASS of U and ME!

7. Schattingen zijn een onnauwkeurige wetenschap, en dingen zullen langer duren als de specificaties halverwege het project veranderen

Om voor de hand liggende redenen is één van de eerste dingen die software ontwikkelaars wordt gevraagd te doen, aan het begin van een nieuw project, is schatten hoe lang het zal duren om het af te ronden.

Maar als de project deliverables en specificaties niet vastliggen, kan het bijna onmogelijk zijn om een accurate schatting te geven.

In gevallen waarin de juiste informatie beschikbaar is, moet je er rekening mee houden dat er altijd complicaties optreden. Schattingen worden niet voor niets schattingen genoemd. Het is een beste schatting van hoe lang dingen zullen duren, op basis van wat nu bekend is.

Maar als de specificaties van het project zes weken later veranderen, kun je er zeker van zijn dat de schatting ook zal veranderen.

Veranderingen aanbrengen in wat de ontwikkelaars aan het bouwen zijn halverwege een project is hetzelfde als een kunstschilder vertellen dat je wilt dat hij een appel schildert en dan als ze halverwege klaar zijn met het schilderen van de appel van gedachten veranderen en vragen of ze in plaats daarvan een BigMac willen schilderen.

Het zijn allebei schilderijen van eten, toch? Wat is het probleem?

Er gebeuren dingen. Er zijn miscommunicaties. Mensen veranderen van gedachten. Mensen maken fouten. Maar verwachten dat veranderingen in het project geen invloed zullen hebben op de tijdslijnen is naïef en een geweldige manier om ontwikkelaars kwaad te maken.

8. Als je ontwikkelaars enthousiast kunt maken voor een project, doe het dan

Ik hoop dat dit niet als een schok komt voor iedereen, maar hier gaat het:

ontwikkelaars zullen meer geïnteresseerd zijn in het schrijven van code als ze enthousiast zijn over waar ze aan werken.

Voor zover ik heb kunnen nagaan, is code schrijven niet anders dan elke andere job in de zin dat als je gemotiveerd bent, je over het algemeen beter werk zal leveren.

Met het risico in herhaling te vallen; de ontwikkelaars met wie je werkt zijn geen robots. Het is heel wat anders voor hen om hersenloos bezig te zijn dan om aan iets uitdagends en interessants te werken.

De aard van waar ze aan werken en de algemene teammoraal rond een project kunnen een enorm verschil maken. Het zal je verbazen hoe snel dingen gedaan worden als mensen echt enthousiast zijn om ergens aan te werken.

(Een korte opmerking over dit punt: als een project niet spannend is, probeer dan geen lippenstift op een varken te doen. Ga terug naar #3. Software ontwikkelaars doorzien elek onoprechte poging om het team achter iets te krijgen waar niemand echt om geeft)

Wanneer je de perfecte app gebruikt of op een mooi ontworpen website surft, voelt dat echt als magie.

Maar voor elke app of website die als magisch aanvoelt, zijn er duizenden regels code die door een mens zijn geschreven. Het is gemakkelijk om het eindproduct te zien en te denken dat de softwareontwikkelaars magische tovenaars zijn die gewoon met hun vingers knippen en mooie, functionele dingen laten verschijnen. Maar wees reëel.

De eerste paar builds van een app of website zullen ruw zijn. Het zal tijd kosten. Er zullen bugs zijn. Er zullen regressies zijn. En het is allemaal deel van het proces. Het eindproduct mag dan als magisch aanvoelen, maar alles tot dan toe zal dat vrijwel zeker niet zijn.

10. Geniet van het proces van eerste schets tot eindproduct

Tegen de tijd dat het product gelanceerd wordt, is iedereen waarschijnlijk uitgeput en is het misschien een klein wonder dat alle betrokkenen nog in dezelfde kamer kunnen zijn. Maar hoe moeilijk het ook was tijdens het ontwikkelingsproces, vergeet niet om een stapje terug te doen en te waarderen wat er is gebouwd.

Het feit dat een hoop ideeën en schetsen nu iets zijn dat je kunt aanraken en in je zak kunt meedragen, is een klein wonder. Geniet ervan en geniet ervan dat je werkt met geweldige ontwikkelaars die een grote rol hebben gespeeld om dit mogelijk te maken.



Als je al eens een softwareontwikkelingsproject hebt gedaan of erbij betrokken geweest bent, dan zal je het met me eens zijn dat de softwareontwikkelaars daarbij van essentieel belang zijn. Het is dan ook zaak om goed met hen door één door te kunnen. 

10 tips voor het werken met softwareontwikkelaars

 Alleen op die manier kunnen we de allerbeste service garanderen aan onze klanten, aan u. Hoe we dat doen?

Dat zal als volgt gaan. In de loop van 2022 zal Byte24 zich onder andere bezig gaan houden met het ontwikkelen van haar eigen SaaS. Dat staat voor ‘Software as a Service’. Dit is een methode om software en applicaties te bezorgen via het internet als een abonnement. Met de oude traditionele software moeten gebruikers zelf de software managen, installeren en upgraden op lokale servers of computers. Met SaaS kun je een server in de cloud aanbieden waarmee dat in een aantal uren gebeurt, bedrijven kunnen dus via het internet computer resources afnemen. Zie het als een bedrijf dat haar water en elektriciteit afneemt bij een energieleverancier. Het klinkt misschien als een ver-van-mijn-bed-show, maar in werkelijkheid maak je iedere dag gebruik van dit soort services. Denk maar eens aan Gmail, MS Office en Netflix. Al deze bedrijven werken met SaaS!

Waar je vroeger een cd-rom kocht, installeerde en vervolgens kon gebruiken op een enkele computer, heb je nu overal toegang tot de software. Het enige wat je nodig hebt is een smart device met een internetconnectie en je bent good-to-go. Maar op wat voor manier kunnen wij jouw bedrijf hiermee helpen? Dat gaat als volgt:

De services zijn overal toegankelijk vanaf ieder apparaat met een internetconnectie. Met de persoonlijke inloggegevens die wij verstrekken, kun je overal ter wereld toegang krijgen tot de software. Je hoeft niets te installeren, niets te downloaden en hebt hier geen technische kennis voor nodig. Daar zijn wij voor!


Vergeleken met een IT-oplossing is de set-up binnen no time gereed om mee aan de slag te gaan. Voor een bedrijf kan dit dus enorm tijd- en geldbesparend zijn!


Iedere week of maand (afhankelijk van de afspraken) verzorgen wij alle updates. Dat betekent dat je nooit meer verouderde softwares aan de praat hoeft te houden en altijd toegang hebt tot de nieuwste versies van de software.


De toegang tot jouw service wordt met een maand- of jaarabonnement voor een aantal licenties geregeld, dus bedrijven nemen echt alleen af wat ze nodig hebben (het water en elektriciteits principe). Dit is enorm makkelijk, effectief en opnieuw kostenbesparend.

Deze industrie is al een tijdje in opmars en de ontwikkelingen gaan steeds harder. Bedrijven worden gerund vanuit een broekzak door mobiele SaaS oplossingen. Mobile marketing, e-mail campagnes en web engagement zijn allemaal toegankelijk vanaf jouw telefoon. SaaS is geschikt voor bedrijven in alle soorten en maten. Voor kleine ondernemingen is het een voordelige manier om IT-taken uit te besteden. Grote bedrijven kunnen er bijvoorbeeld alle interne communicatie mee regelen.

Byte24 is op dit moment hard bezig met het realiseren van deze ontwikkeling. Dit doen wij door grondig marktonderzoek te doen. We kijken naar de behoeften van onze klant, naar de ontwikkelingen op dit gebied en wat de rol van SaaS daarin zal zijn. Bent u benieuwd naar deze ontwikkelingen binnen ons bedrijf? Schroom niet om contact met ons op te nemen, dan leggen we u graag de stand van zaken uit :).

Alleen op die manier kunnen we de allerbeste service garanderen aan onze klanten, aan u. Hoe we dat doen?

BYTE24 gaat mee met de tijd - Software as a Service

Bij softwareontwikkeling zijn er twee soorten vereisten: functioneel en niet-functioneel.

Dit zijn de productkenmerken die het ontwikkelteam gaat ontwerpen, coderen en testen. Ze definiëren de functionaliteit van het softwareproduct dat zal helpen bij het oplossen van de pijnpunten van gebruikers. Deze vereisten worden gedefinieerd door "wat"-vragen zoals:

Welke functies of functionaliteit ondersteunt het product?

Welke informatie of gegevens gaat het ondersteunen?

deze beschrijven hoe elke functie zich onder bepaalde omstandigheden moet gedragen en welke beperkingen ze moeten hebben. Ze dienen als beschrijving van de functies die voor de belanghebbenden van belang zijn. Deze vereisten worden gedefinieerd door "hoe"-vragen, zoals: "Hoe zal het systeem doen waarvoor het is ontworpen?"
 Ze stellen normen vast voor:

Wat zijn de niet-functionele vereisten bij softwareontwikkeling?

Zodra je het softwareontwikkelingsproces begrijpt en de zakelijke eisen en ontwikkelingsmethodologie hebt gedefinieerd, ben je klaar om de softwareontwikkelingseisen te documenteren.

Volg deze vijf stappen om een ​​specificatiedocument voor kwaliteitssoftware te maken voor het product dat je wilt (laten) bouwen.

1. Maak een specificatie van de software-eisen

De eerste stap bij het definiëren van het softwareontwikkelingseisen document is het maken van een schets voor de Software Eisen Specificatie (SES).

Dit overzicht moet de volgende hoofdstukken bevatten:

Door elk van deze items tedefiniëren in je specificaties voor software-eisen en deze in te vullen, ben je klaar om door te gaan naar de volgende stap.

2. Definieer het doel en de verwachtingen van het product

Het allereerste hoofdstuk in je SES-documenten gaat over het doel van het product. Het bepaalt de verwachtingen voor de softwareoplossing die je aan het bouwen bent.

in dit deel moet je allemensen/rollen in het project beschrijven die toegang hebben tot het document en hoe ze het moeten gebruiken. Dit kunnen ontwikkelaars, projectmanagers, testers, sales- en marketingmensen of belanghebbenden in andere afdelingen zijn.

deze sectie is bedoeld voor het definiëren van het product dat je specificeert. Het moet de doelstellingen van de softwareoplossing en de voordelen ervan op hoofdlijnen beschrijven.

3. Maak een overzicht van een voltooid softwareproduct

De beschrijving van het productgedeelte van de SES moet een overzicht geven van de software die je aan het bouwen bent.

Om ervoor te zorgen dat iedereen in het project weet wat ze bouwen, moet je deze vragen vooraf beantwoorden:

Is het product een nieuw soort oplossing?

Is het een update of een aanpassing op een bestaand product?

Is het een add-on voor een reeds gemaakt product?

Het beantwoorden van de bovenstaande vragen helpt bij het definiëren van het volgende:

: je doelgroep - de mensen die je softwareoplossing gaan gebruiken - behoort tot dit onderdeel. Het is van essentieel belang om gebruikers te definiëren die het softwareproduct dat je aan het bouwen bent, nodig hebben: er zijn primaire en secundaire gebruikers die de oplossing regelmatig zullen gebruiken en er kunnen afzonderlijke kopers zijn wiens behoeften je ook moet definiëren.

in dit specifieke gedeelte moeten de factoren worden beschreven die van invloed kunnen zijn op de naleving van de SES-eisen. Het moet ook veronderstellingen bevatten die SES maakt en die onjuist kunnen zijn. Noteer ook eventuele externe factoren waarvan het softwareontwikkelingsproject afhankelijk is.

Het ontwikkelteam zal veel gebruik maken van dit deel van het document, omdat je hier de specifieke eisen voor het bouwen van de softwareoplossing moet specificeren.
Ze bestaan ​​uit functionele en niet-functionele eisen. Daarover kan je meer lezen in een volgend artikel.

Bedrijfsdoelstellingen op hoog niveau van het bedrijf dat de softwareoplossing gaat bouwen

 Eisen die de behoeften van de markt en de doelgroepen schetsen.

 Soorten functionele vereisten die schetsen hoe het product zal integreren met andere software.

Specificaties die schetsen hoe de UI eruit zal zien en zal aanvoelen. Dit bepaalt de gebruikerservaring van het product.

deze beschrijven de vereisten waar het systeem aan moet voldoen om het product te laten functioneren.

5. Laat belanghebbenden de softwareontwikkelingseisen goedkeuren

Zodra u uw softwareontwikkelingseisen hebt gedefinieerd en gedocumenteerd in je SES-document, is de laatste stap die overblijft het versturen ervan naar belanghebbenden voor revisie en goedkeuring.

Iedereen moet de definitieve versie van dit document bekijken - het ontwikkelings- en ontwerpteam dat eraan heeft gewerkt, het bedrijf of de onderneming die de opdracht heeft gegeven, de sponsors die het hebben gefinancierd en een steekproef van het doelpubliek om de functies en kenmerken te beoordelen.

Dit is de laatste stap om ervoor te zorgen dat iedereen op dezelfde lijn zit voordat de productie van de oplossing begint.

Dit is het moment waarop SES-reviewers hun last-minute suggesties, klachten en ideeën voor de verbetering van het proces en het eindproduct kunnen indienen.

Dit waren de vijf stappen om tot softwareontwikkelingseisen te komen.

Ik ben benieuwd of jij wel eens een Software Eisen Specificatie document maakt en wat voor stappen pas jij toe?

Blog

10 tips voor het werken met softwareontwikkelaars

BYTE24 gaat mee met de tijd - Software as a Service

Wat zijn de niet-functionele vereisten bij softwareontwikkeling?

In vijf stappen naar softwareontwikkelingseisen