Anpassade tjänster för mjukvaruutvecklingsföretag

Vi är ett företag som bygger digitala fjärrteam för byråer, IT-tjänsteleverantörer och IT-avdelningar.

Här diskuterar vi utmaningarna, möjliga lösningar, fördelarna med outsourcing och ytterligare information om utveckling av anpassad programvara.

Inledning: utmaningar

När man bygger IT-lösningar finns det många utmaningar. När en tredje part säljs blir det ännu mer komplicerat.

Några av dessa utmaningar är:

  1. Frågor om öppenhet : Se till att tredjepartsleverantören ger insikter om hur mjukvaran utvecklas och att det inte finns någon ”rökskärm” som projektledare och säljare som förhindrar en närmare titt på de interna processerna.
  2. Vem arbetar med projektet : I vissa fall vet inte den partner som outsourcer arbetet vem som faktiskt arbetar med IT-projektet. Frågor som ”Vilken typ av programmerare är inblandade?”, ”Är de alla erfarna IT-proffs?”, ”Är det de som arbetade med provprojekten, som nämndes i försäljningsfasen?”, ”Finns det testare / kvalitet analytiker och applikationsarkitekter inblandade? ”,” Eller är det bara juniorprogrammerare på laget? ” förblir i vissa fall obesvarade.
  3. Tillitsproblem : Hur uppriktig är IT-tjänsteleverantören? Arbetar de med hög integritet? Är de helt öppna om något negativt händer? Eller gömmer de eventuella problem som kan uppstå i framtiden? Som systemets underhållsbarhet eller skalbarhet, som bara kan upptäckas i framtiden och inte omedelbart efter överlämnandet av projektet.
  4. Faktureringsrelaterad öppenhet : Räknar de fler timmar än vad som behövs? Sätter de en för stor marginal på sina kostnader?

Vanligtvis kommer transparens i fråga om vem som arbetar med projektet och även faktureringsrelaterade frågor att urholka förhållandet mellan leverantör och den partner som har lagt ut arbetet.

Orsakerna till dessa frågor finns på outsourcingföretagssidan, liksom på partnersidan.

Leverantörsproblem (IT-leverantör):

  1. Känner inte till klientens betalningsbeteende : Kommer kunden att betala alla sina räkningar i tid? Kommer de att dra betalningarna över en lång tid? Kommer de inte att betala sina räkningar och säga att projektet inte levererades i rätt kvalitet eller tid? Allt detta kommer att få tjänsteleverantören att tveka att ta med sitt “A” -team till projektet och undviker att spendera för mycket tid till att börja med innan han har svar på dessa frågor.
  2. Har inte erforderlig expertis men behöver projektet på grund av intern kostnadsstruktur : Ibland har anpassade applikationstjänstleverantörer höga månatliga kostnader på grund av löner och annan infrastruktur (hyra, datorer, internet, allmänna kostnader etc.). Detta gör att vissa leverantörer tar projekt, vilket de inte kan göra i hög kvalitet till bästa möjliga pris. För att täcka sina utgifter kommer de ändå att ta projektet.
  3. Vill undvika pochering av anställda : Genom att dölja programmerarna bakom projektledare och säljare kommer IT-leverantören att se till att en eventuell pochering av talanger undviks. För om säljaren inte känner till partnerns beteende kan det vara så att de börjar anställa dem. Denna ”rökskärm” kommer att orsaka kommunikationsproblem, eftersom alla meddelanden måste gå via olika personer som inte lägger mycket värde på diskussionen.
  4. Vill se till att fakturering och ansträngningar är i balans : Säljaren kan vara djupt involverad i processen för att se till att fakturering och ansträngningar är i balans. Men detta hjälper inte projektet som sådant och är istället bara användbart för säljaren.

Partnerproblem (klient):

  1. Kan jag vara säker på att slutresultatet är vad jag förväntade mig?: När ett team på 5 personer arbetar i 7 månader på projektet betalas alla räkningar och ansökan levereras, kommer jag att vara säker på att jag får en lösning som är skalbar och underhållbar? Detta kan partnern först veta efter flera månaders interntestning, samt ytterligare feedback från slutkunder.
  2. Kommer jag att betala för mycket för tjänster av låg kvalitet?: Som nämnts i början kan partnern inte vara säker på vem som arbetar med applikationen om transparens saknas. Detta kan i sin tur påverka kvaliteten på utmatningen.
  3. Hur kan jag se till att produkten kan underhållas i framtiden?: Vad sägs om kodningsstandarder, dokumentation och underhåll? Kan vårt eget team eller ett team från en annan leverantör enkelt veta vad som händer i koden och bygga vidare på det? Det här är saker som är viktiga vid anpassad mjukvaruutveckling. Eftersom en bra andel av projekten misslyckas i nästa steg.

Möjliga lösningar

Tredjepartsleverantören som bygger applikationen måste vara säker på att han får ersättning för sina tjänster och på andra sidan vill arbeta med pålitliga partners.

Partnern vill se till att få bästa möjliga värde för en rimlig budget. En lösning som är skalbar, snabb och underhållbar.
Vi har arbetat många år med flera kunder från hela världen. För att vara ärlig: Några av dessa projekt misslyckades på grund av de skäl som nämns i början av texten.

Sedan 2014 ändrade vi vår modell till att tillhandahålla dedikerade IT-experter till våra partners, detta har varit den punkt där saker och ting blir mycket positiva. Med de flesta kunder från dessa tider arbetar vi fortfarande idag.

Hur dedikerade team fungerar

Istället för att göra det traditionella outsourcing-samarbetet, där säljaren tar alla krav från början till slut, kommer det att finnas ett större engagemang på klientsidan.

För detta krävs följande saker på partnersidan:

  • a) En projektledare : Den här personen borde redan ha gjort projekt relaterade till applikationsutveckling. Han / hon kommer därmed att ha kunskap om vilka utmaningar som kan komma i IT-projekt och hur man löser dem.
  • b) En kodningsexpert : Någon på partnersidan, som känner kodning inifrån och ut. Detta ser till att den levererade programmeringen kan kontrolleras av partnerföretaget. Mycket snabbt kan alla problem hittas på det här sättet.

För att spara arbetskraft kan projektledaren också vara personen som är kodningsexpert.

Följande saker krävs från leverantörssidan:

  • a) Direkt tillgång till programmerarna: Säljaren ger direkt åtkomst till utvecklarna för att säkerställa att kommunikationen är smidig och att kommunikationsbrister undviks. I de flesta fall kommer IT-experten på leverantörssidan och kodningsexperten på partnersidan att hitta rätt lösning på de arkitektoniska problemen som kan komma upp.
  • b) Uttryck i valet av teammedlemmar : Säljaren ger partnern möjlighet att välja de teammedlemmar som ska arbeta med projektet. Detta är viktigt eftersom partnern kan ha sin egen arbetskultur, kvalitetskrav och sina egna IT- och projektledningsverktyg. För detta kommer leverantören att tillhandahålla CV: n för programmerarna och klienten kan välja därefter.
  • c) Möjlighet att besöka varandra : Leverantören av mjukvaruutvecklingstjänster ska tillåta klienten att besöka sin egen plats eller att teammedlemmarna kan besöka klienten om det behövs. Detta kommer att se till att ett starkare band skapas mellan lag och plats. Att träffa varandra direkt kommer att göra stor skillnad för lagsamarbetet.

Här en videofilm om hur en sådan process kan se ut:

Slutsats

Arbeta med externa företag för utveckling av anpassad programvara kan vara en bra idé. Speciellt om den erforderliga arbetskraften inte är tillgänglig inom det egna laget.

Att få det att fungera kan ibland vara en utmaning. Enligt flera studier och vår egen erfarenhet misslyckas en stor del av IT-projekten. Anledningarna till detta och möjliga lösningar nämns i denna text.

Vad är din erfarenhet av outsourcing av programvara? Vi vill höra från dig.

Intressanta artiklar:
Topputvecklare för anpassad utveckling
Mjukvarudesign och utveckling av oxagile – om du letar efter en smidig strategi

Bilder: Flickr.com/ Official GDC / Sonin


Författaren: Sascha Thattil arbetar som VD och projektledare på www.Software-Developer-India.com som ingår i YUHIRO Group. YUHIRO är ett tysk-indiskt företag som tillhandahåller programmerare till små och medelstora IT-företag, byråer och IT-avdelningar.

Lämna ett svar

Denna webbplats använder Akismet för att minska skräppost. Lär dig hur din kommentardata bearbetas.