Tilpasset softwareudvikling firma tjenester

Tilpasset softwareudvikling firma tjenester

Vi er en Selskab der bygger fjerntliggende digitale teams til agenturer, it-tjenesteudbydere og it-afdelinger.

Her diskuterer vi udfordringerne, mulige løsninger, fordelene ved outsourcing og yderligere information om udvikling af brugerdefineret software.

Introduktion: Udfordringer

Når man bygger it-løsninger, er der mange udfordringer. Når en tredjepartsleverandør inddrages, bliver det endnu mere kompleks.

Nogle af disse udfordringer er:

1. Gennemsigtighedsspørgsmål : Sørg for, at tredjepartsleverandøren giver indsigt i, hvordan softwaren udvikles, og at der ikke er nogen “røgskærm” som projektledere og sælgere, der forhindrer et tæt kig på de interne processer.
2. Hvem arbejder på projektet : I nogle tilfælde ved den partner, der outsourcer arbejdet, ikke, hvem der rent faktisk arbejder på it-projektet. Spørgsmål som “Hvilken type programmører er involveret?”, “Er det alle erfarne it-fagfolk?”, “Er det dem, der har arbejdet med prøveprojekterne, som blev nævnt i salgsfasen?”, “Er der testere / kvalitet involverede analytikere og applikationsarkitekter? ”,“ Eller er der kun juniorprogrammerere på holdet? ” forbliver i nogle tilfælde ubesvarede.
3. Tillidsproblemer : Hvor oprigtig er udbyderen af it-tjenester? Arbejder de ud fra høj integritet? Er de helt åbne, hvis der sker noget negativt? Eller skjuler de eventuelle problemer, der kan opstå i fremtiden? Ligesom systemets vedligeholdelighed eller skalerbarhed, som kun kan findes i fremtiden og ikke umiddelbart efter aflevering af projektet.
4. Faktureringsrelateret gennemsigtighed : Fakturerer de flere timer end nødvendigt? Sætter de en for stor margen på deres omkostninger?

Normalt vil gennemsigtighed med hensyn til, hvem der arbejder på projektet og også faktureringsrelaterede spørgsmål, ødelægge forholdet mellem sælger og den partner, der har outsourcet arbejdet.

Årsagerne til disse problemer findes på outsourcingvirksomhedssiden såvel som på partnersiden.

Problemer med leverandør (it-udbyder):

1. Kender ikke klientens betalingsadfærd : Vil klienten betale alle sine regninger til tiden? Vil de trække betalingerne over en lang periode? Vil de ikke betale deres regninger og sige, at projektet ikke blev leveret i den rigtige kvalitet eller tid? Alt dette vil få tjenesteudbyderen til at tøve med at bringe sit “A” -team videre til projektet og undgår at bruge for meget tid i starten, inden han har svar på disse spørgsmål.
2. Har ikke den nødvendige ekspertise, men har brug for projektet på grund af intern omkostningsstruktur : Nogle gange har brugerdefinerede applikationstjenesteudbydere høje månedlige omkostninger på grund af lønninger og anden infrastruktur (leje, computere, internet, overhead osv.). Dette får nogle leverandører til at tage projekter, hvilket de ikke kan udføre i høj kvalitet til den bedst mulige pris. For at imødekomme deres udgifter tager de projektet alligevel.
3. Ønsker at undgå krybskytteri af ansatte : Ved at skjule programmørerne bag projektledere og sælgere vil it-leverandøren sørge for, at en mulig pochering af talent undgås. For hvis sælgeren ikke kender partnerens opførsel, kan det være, at de begynder at ansætte dem væk. Denne “røgskærm” vil forårsage problemer med kommunikation, fordi alle meddelelser skal gå via forskellige mennesker, der ikke tilføjer megen værdi til diskussionen.
4. Ønsker at sikre, at fakturering og indsats er i balance : Sælger kan være dybt involveret i processen for at sikre, at fakturering og indsats er i balance. Men dette hjælper ikke projektet som sådan og er i stedet kun nyttigt for sælgeren.

Partner (klient) problemer:

1. Kan jeg være sikker på, at slutresultatet er, hvad jeg forventede?: Når et team på 5 personer arbejder i 7 måneder på projektet, betales alle regninger, og applikationen leveres, vil jeg være sikker på, at jeg får en løsning, der er skalerbar og vedligeholdelig? Dette kan partneren kun vide efter flere måneders intern test samt yderligere feedback fra slutkunder.
2. Vil jeg betale for meget for tjenester af lav kvalitet?: Som nævnt i starten kan partneren ikke være sikker på, hvem der arbejder på applikationen, hvis gennemsigtighed mangler. Dette vil igen kunne påvirke kvaliteten af output.
3. Hvordan kan jeg sikre, at produktet kan vedligeholdes i fremtiden?: Hvad med kodningsstandarder, dokumentation og vedligeholdelsesevne? Kan vores eget team eller et team fra en anden leverandør let vide, hvad der foregår inde i koden, og bygge videre på det? Dette er ting, der er vigtige i brugerdefineret softwareudvikling. Fordi en god procentdel af projekter mislykkes på dette næste trin.

Mulige løsninger

Tredjepartsleverandøren, der bygger applikationen, skal være sikker på, at han får løn for sine tjenester og på den anden side ønsker at arbejde med pålidelige partnere.

Partneren vil sørge for at få den bedste værdi til et rimeligt budget. En løsning, der er skalerbar, hurtig og vedligeholdelig.
Vi har arbejdet mange år med flere klienter fra hele verden. For at være ærlig: Nogle af disse projekter mislykkedes på grund af årsagerne nævnt i begyndelsen af teksten.

Siden 2014 ændrede vi vores model til at levere dedikerede it-eksperter til vores partnere, dette har været det punkt, hvor tingene bliver meget positive. Med de fleste kunder fra disse tider arbejder vi stadig i dag.

Hvordan dedikerede teams fungerer

I stedet for at udføre det traditionelle outsourcing-samarbejde, hvor sælgeren tager alle kravene fra start til slut, vil der være højere engagement på klientsiden.

Til dette kræves følgende ting på partnersiden:

• a) En projektleder : Denne person skulle allerede have udført projekter relateret til applikationsudvikling. Han / hun vil således have viden om, hvilke udfordringer der kan komme op i it-projekter, og hvordan man løser dem.
• b) En kodningsekspert : En på partnersiden, der kender kodning indefra og ud. Dette vil sikre, at den leverede programmering kan kontrolleres af partnerfirmaet. Meget hurtigt kan eventuelle problemer findes på denne måde.

For at spare arbejdskraft kan projektlederen også være den person, der er kodningseksperten.

Følgende ting kræves fra leverandørsiden:

• a) Direkte adgang til programmørerne: Sælgeren giver direkte adgang til udviklerne for at sikre, at kommunikationen er glat, og at kommunikationshuller undgås. I de fleste tilfælde finder IT-eksperten på leverandørsiden og kodeksperten på partnersiden den rigtige løsning på de arkitektoniske problemer, der kan komme op.
• b) Et ord i valg af teammedlemmer : Sælgeren giver partneren mulighed for at vælge de teammedlemmer, der skal arbejde på projektet. Dette er vigtigt, da partneren måske har deres egen arbejdskultur, kvalitetskrav og deres egne it- og projektledelsesværktøjer. Til dette vil leverandøren give CV’erne til programmørerne, og klienten kan vælge det.
• c) Mulighed for at besøge hinanden : Udbyderen af softwareudviklingstjenester skal give klienten mulighed for at besøge deres egen placering eller for teammedlemmerne at besøge klienten, hvis det er nødvendigt. Dette vil sikre, at der skabes et stærkere bånd mellem onsite- og offsite-holdene. Direkte møde med hinanden vil gøre en stor forskel for teamsamarbejdet.

Her en forklaringsvideo om, hvordan en sådan proces kan se ud:

Konklusion

Arbejde med eksterne virksomheder til udvikling af brugerdefineret software kan være en god idé. Især hvis den krævede arbejdskraft ikke er tilgængelig inden for det eget hold.

At få det til at fungere kan til tider være en udfordring. Ifølge flere undersøgelser og vores egen erfaring mislykkes en god del af it-projekter. Årsagerne til dette og mulige løsninger er nævnt i denne tekst.

Hvad er din erfaring med software outsourcing? Vi vil gerne høre fra dig.

Interessante artikler:
Topudviklere til tilpasset udvikling
Software design og udvikling af oxagile – hvis du leder efter en smidig tilgang

Billeder: Flickr.com/ Official GDC / Sonin

Forfatteren: Sascha Thattil arbejder som CEO og projektleder på www.Software-Developer-India.com, som er en del af YUHIRO Group. YUHIRO er en tysk-indisk virksomhed, der leverer programmører til små til mellemstore it-virksomheder, agenturer og it-afdelinger.