Tilpassede tjenester for programvareutvikling

Tilpassede tjenester for programvareutvikling

Vi er en selskap som bygger eksterne digitale team for byråer, IT-tjenesteleverandører og IT-avdelinger.

Her diskuterer vi utfordringene, mulige løsninger, fordelene med outsourcing og tilleggsinformasjon om utvikling av tilpasset programvare.

Innledning: Utfordringer

Når man bygger IT-løsninger, er det mange utfordringer. Når du involverer en tredjepartsleverandør blir det enda mer komplisert.

Noen av disse utfordringene er:

1. Åpenhetsspørsmål : Å sørge for at tredjepartsleverandøren gir innsikt i hvordan programvaren er utviklet, og at det ikke er noen «røykskjerm» som prosjektledere og selgere som forhindrer en nærmere gjennomgang av de interne prosessene.
2. Hvem jobber med prosjektet : I noen tilfeller vet ikke partneren som outsourcer arbeidet, hvem som faktisk jobber med IT-prosjektet. Spørsmål som “Hvilken type programmerere er involvert?”, “Er de alle erfarne IT-fagfolk?”, “Er det de som jobbet med prøveprosjektene, som ble nevnt i salgsfasen?”, “Er det testere / kvalitet analytikere og applikasjonsarkitekter involvert? ”,“ Eller er det bare juniorprogrammerere på laget? ” forbli i noen tilfeller ubesvart.
3. Tillit problemer : Hvor oppriktig er leverandøren av IT-tjenester? Arbeider de med høy integritet? Er de helt åpne, hvis noe negativt skjer? Eller skjuler de mulige problemer som kan oppstå i fremtiden? Som vedlikehold eller skalerbarhet i systemet, som bare kan bli funnet i fremtiden og ikke umiddelbart etter overlevering av prosjektet.
4. Faktureringsrelatert gjennomsiktighet : Fakturerer de flere timer enn nødvendig? Setter de for store marginer på kostnadene?

Vanligvis vil gjennomsiktighet når det gjelder hvem som jobber med prosjektet og faktureringsrelaterte spørsmål, ødelegge forholdet mellom leverandør og partneren som har outsourcet arbeidet.

Årsakene til disse problemene er å finne på outsourcingbedriftens side, så vel som på partnersiden.

Problemer med leverandør (IT-leverandør):

1. Kjenner ikke betalingsadferden til klienten : Vil klienten betale alle regningene i tide? Vil de trekke betalingene over lang tid? Vil de ikke betale regningene og si at prosjektet ikke ble levert i riktig kvalitet eller tid? Alt dette vil få tjenesteleverandøren til å nøle med å ta med seg “A” -teamet sitt til prosjektet og unngår å bruke for mye tid i utgangspunktet, før han har svar på spørsmålene.
2. Har ikke den nødvendige kompetansen, men trenger prosjektet på grunn av intern kostnadsstruktur : Noen ganger har tilpassede applikasjonstjenesteleverandører høye månedlige kostnader på grunn av lønn og annen infrastruktur (leie, datamaskiner, internett, overhead osv.). Dette vil få noen leverandører til å ta prosjekter, noe de ikke kan gjøre i høy kvalitet til best mulig pris. For å dekke utgiftene vil de ta prosjektet uansett.
3. Ønsker å unngå krypskyting av ansatte : Ved å skjule programmererne bak prosjektledere og selgere, vil IT-leverandøren sørge for at en mulig pochering av talent unngås. Fordi hvis leverandøren ikke kjenner partnerenes oppførsel, kan det være at de begynner å ansette dem bort. Denne «røykskjermen» vil forårsake problemer med kommunikasjonen, fordi alle meldinger må gå via forskjellige mennesker, som ikke gir diskusjonen mye verdi.
4. Ønsker å sørge for at fakturering og innsats er i balanse : Selgeren kan være dypt involvert i prosessen, for å sikre at fakturering og innsats er i balanse. Men dette vil ikke hjelpe prosjektet som sådan, og er i stedet bare nyttig for leverandøren.

Partner (klient) problemer:

1. Kan jeg være sikker på at sluttresultatet er det jeg forventet?: Når et team på 5 personer jobber i 7 måneder på prosjektet, blir alle regningene betalt og søknaden levert, vil jeg være sikker på at jeg får en løsning som er skalerbar og vedlikeholdbar? Dette kan partneren bare vite etter flere måneders interntesting, samt ytterligere tilbakemeldinger fra sluttkunder.
2. Vil jeg betale for mye for tjenester av lav kvalitet?: Som nevnt i begynnelsen, kan partneren ikke være sikker på hvem som jobber med applikasjonen, hvis transparens mangler. Dette vil igjen kunne påvirke kvaliteten på utgangen.
3. Hvordan kan jeg sørge for at produktet kan vedlikeholdes i fremtiden?: Hva med kodestandarder, dokumentasjon og vedlikeholdsevne? Kan vårt eget team eller et team fra en annen leverandør enkelt vite hva som skjer i koden og bygge videre på det? Dette er ting som er viktige i tilpasset programvareutvikling. Fordi en god prosentandel av prosjektene mislykkes på neste trinn.

Mulige løsninger

Tredjepartsleverandøren som bygger applikasjonen, må være sikker på at han får lønn for tjenestene og på den andre siden ønsker å samarbeide med pålitelige partnere.

Partneren ønsker å sørge for å få den beste verdien for et rimelig budsjett. En løsning som er skalerbar, rask og vedlikeholdbar.
Vi har jobbet mange år med flere kunder fra hele verden. For å være ærlig: Noen av disse prosjektene mislyktes på grunn av årsakene nevnt i begynnelsen av teksten.

Siden 2014 endret vi modellen vår til å tilby dedikerte IT-eksperter til våre partnere, dette har vært poenget der ting blir veldig positive. Med de fleste klientene fra den tiden jobber vi fremdeles i dag.

Hvordan dedikerte team fungerer

I stedet for å gjøre det tradisjonelle outsourcing-samarbeidet, hvor leverandøren tar alle kravene fra start til slutt, vil det være høyere involvering på klientsiden.

For dette kreves følgende ting på partnersiden:

• a) En prosjektleder : Denne personen burde allerede ha gjort prosjekter knyttet til applikasjonsutvikling. Han / hun vil dermed ha kunnskap om hvilke utfordringer som kan komme opp i IT-prosjekter og hvordan de kan løses.
• b) En kodeekspert : Noen på partnersiden, som kjenner koding ut og inn. Dette vil sørge for at den leverte programmeringen kan kontrolleres av partnerselskapet. Svært raskt kan eventuelle problemer bli funnet på denne måten.

For å spare arbeidskraft, kan prosjektlederen også være personen som er kodingsekspert.

Følgende ting kreves fra leverandørsiden:

• a) Direkte tilgang til programmererne: Leverandøren vil gi direkte tilgang til utviklerne, for å sikre at kommunikasjonen er jevn og at kommunikasjonshull unngås. I de fleste tilfeller vil IT-eksperten på leverandørsiden og kodingseksperten på partnersiden finne den rette løsningen på de arkitektoniske problemene, som kan komme opp.
• b) Et ordtak i valg av teammedlemmer : Leverandøren vil gi partneren muligheten til å velge teammedlemmene som skal jobbe med prosjektet. Dette er viktig, ettersom partneren kan ha sin egen arbeidskultur, kvalitetskrav og egne IT- og prosjektledelsesverktøy. For dette vil leverandøren levere CV-ene til programmererne, og klienten kan velge det.
• c) Mulighet for å besøke hverandre : Programvareutviklingstjenesteleverandøren skal tillate klienten å besøke sin egen plassering, eller at teammedlemmene kan besøke klienten om nødvendig. Dette vil sørge for at det blir opprettet et sterkere bånd mellom teamene på stedet og utenfor stedet. Å møte hverandre direkte vil gjøre en stor forskjell for lagsamarbeidet.

Her en forklaringsvideo om hvordan en slik prosess kan se ut:

Konklusjon

Arbeide med eksterne selskaper for utvikling av tilpasset programvare kan være en god idé. Spesielt hvis den nødvendige arbeidskraften ikke er tilgjengelig i eget lag.

Å få det til å fungere kan til tider være en utfordring. I følge flere studier og vår egen erfaring mislykkes en god del av IT-prosjektene. Årsakene til dette og mulige løsninger er nevnt i denne teksten.

Hva er din erfaring med outsourcing av programvare? Vi vil gjerne høre fra deg.

Interessante artikler:
Topp utviklere for tilpasset utvikling
Programvaredesign og utvikling av oxagile – hvis du er ute etter en smidig tilnærming

Bilder: Flickr.com/ Official GDC / Sonin

Forfatteren: Sascha Thattil jobber som administrerende direktør og prosjektleder på www.Software-Developer-India.com som er en del av YUHIRO Group. YUHIRO er en tysk-indisk bedrift som tilbyr programmerere til små og mellomstore IT-selskaper, byråer og IT-avdelinger.