პროგრამული აუთსორსინგის პრაქტიკული გზამკვლევი
როგორ გავაკეთოთ პროგრამული აუთსორსინგი წარმატებით — სწორი მოდელის არჩევა, პარტნიორების შეფასება და გავრცელებული შეცდომების თავიდან აცილება.
რატომ მიმართავენ კომპანიები პროგრამული უზრუნველყოფის განვითარების აუთსორსინგს
პროგრამული უზრუნველყოფის განვითარების აუთსორსინგი აღარ არის ხარჯების შემცირების უკანასკნელი საშუალება. ეს არის გააზრებული სტრატეგია უფრო სწრაფი მოქმედებისთვის, იმ უნარების მისაწვდომად, რომლებიც შიდა გუნდში არ გაგაჩნიათ, და გუნდის გასაზრდელად ან შესამცირებლად მუდმივი დაქირავების ტვირთის გარეშე.
მიზეზები, რის გამოც კომპანიები გარე პარტნიორს მიმართავენ, ჩვეულებრივ რამდენიმე ნიმუშად იყოფა. პირველი არის სიჩქარე: გაქვთ დროის ფანჯარა პროდუქტის გასაშვებად კონკურენტამდე, და სამიდან ექვს თვემდე ლოდინი ადგილობრივად სრული გუნდის დასაქირავებლად ვარიანტი არ არის. მეორე არის შესაძლებლობა: გჭირდებათ უნარი — მობილური პლატფორმა, გადახდების ინტეგრაცია, მანქანური სწავლების მილსადენი — რომელიც თქვენს გუნდში არავის აუგია, და გირჩევნიათ ისწავლოთ მათგან, ვინც ეს უკვე გააკეთა, ვიდრე ისწავლოთ თქვენი მომხმარებლების ხარჯზე. მესამე არის ელასტიკურობა: გაქვთ ექვსთვიანი სამუშაო ნაკადი და არ გსურთ ამ პერსონალის მუდმივად შენარჩუნება, როცა იგი დასრულდება.
კარგად შესრულებისას, აუთსორსინგი გაძლევთ ძლიერ საინჟინრო შესაძლებლობას კვირებში და არა თვეებში. ცუდად შესრულებისას, ის წარმოშობს გაცდენილ ვადებს, მყიფე კოდს და პროდუქტს, რომელსაც თქვენი მხრიდან არავინ ბოლომდე ესმის. განსხვავება თითქმის ყოველთვის იმაშია, თუ როგორ არის მოწყობილი თანამშრომლობა — და არა ქვეყანაში ან საათობრივ განაკვეთში. კომპანიები, რომლებიც ზარალდებიან, ჩვეულებრივ აუთსორსინგს ტრანზაქციად აღიქვამენ; ხოლო ისინი, ვინც წარმატებას აღწევენ, მას სამუშაო ურთიერთობად განიხილავენ მკაფიო წესებით.
აირჩიეთ სწორი თანამშრომლობის მოდელი
არ არსებობს აუთსორსინგის ერთადერთი „საუკეთესო" გზა. სწორი მოდელი დამოკიდებულია იმაზე, რამდენად კარგად არის თქვენი პროექტი განსაზღვრული და რამდენ კონტროლს ისურვებთ ყოველდღიურ სამუშაოზე.
- პროექტზე დაფუძნებული (ფიქსირებული მასშტაბი). გადასცემთ მკაფიო სპეციფიკაციას და მომწოდებელი ერთ შეთანხმებულ ფასად გაწვდით დასრულებულ პროდუქტს. საუკეთესოა, როცა მოთხოვნები სტაბილური და კარგად გასაგებია — მარკეტინგული საიტი, მონაცემთა მიგრაცია, მკაფიოდ განსაზღვრული შიდა ხელსაწყო.
- გამოყოფილი გუნდი. იღებთ გრძელვადიან გუნდს, რომელიც მხოლოდ თქვენს პროდუქტზე მუშაობს და თქვენს პროცესებშია ინტეგრირებული. საუკეთესოა განვითარებადი პროდუქტებისა და მიმდინარე გეგმებისთვის. ამას დეტალურად განვიხილავთ ჩვენს გამოყოფილი განვითარების გუნდების მიმოხილვაში.
- პერსონალის გაძლიერება / აუთსტაფინგი. ამატებთ ცალკეულ ინჟინრებს თქვენს არსებულ გუნდს კონკრეტული უნარების ხარვეზების შესავსებად. საუკეთესოა, როცა უკვე გყავთ ძლიერი ტექნიკური ხელმძღვანელობა. თუ ამას სრულ გუნდთან აწონ-დაწონით, ჩვენი პერსონალის გაძლიერების გვერდი მოიცავს კომპრომისებს.
ყველაზე წარუმატებელი თანამშრომლობა არასწორი მოდელით იწყება. კლასიკური შეცდომა არის ფიქსირებული ფასის კონტრაქტის თავსმოხვევა პროდუქტზე, რომლის მოთხოვნებიც ჯერ კიდევ ყოველ კვირას იცვლება: ყოველი ცვლილება სადავო ცვლილების ორდერად იქცევა, მომწოდებელი ზრდის შეფასებებს თავისი მარჟის დასაცავად, და ნდობა თვის განმავლობაში ეცემა. საპირისპირო შეცდომა არის გამოყოფილი გუნდის გამოყენება მცირე, ერთჯერადი მიწოდებისთვის, სადაც იხდით უწყვეტობაში, რომელიც არ გჭირდებათ. მოდელი დააკავშირეთ თქვენი მოთხოვნების სტაბილურობასთან, და არა იმასთან, რაც ქაღალდზე ყველაზე იაფი ჩანს.
სათანადოდ შეაფასეთ თქვენი პარტნიორი
ფასი ყველაზე ადვილად შესადარებელი და ყველაზე ცუდი რამ არის პირველ რიგში ოპტიმიზაციისთვის. ვიდრე ციფრებზე ისაუბრებთ, დააკვირდით:
- შესაბამის გამოცდილებას. გაუშვიათ თუ არა პროდუქტები თქვენს სფეროში ან თქვენი ტექნოლოგიური სტეკით? სთხოვეთ კოდის ან ცოცხალი პროდუქტის ნახვა, და არა მხოლოდ პრეზენტაცია.
- საინჟინრო პრაქტიკას. იყენებენ თუ არა კოდის მიმოხილვას, ავტომატიზებულ ტესტირებას, CI/CD-ს და ვერსიების კონტროლს ნაგულისხმევად — თუ მხოლოდ მოთხოვნისას? გუნდი, რომელსაც არ შეუძლია აღწეროს თავისი დატოტვის სტრატეგია ან როგორ ამუშავებს ჩავარდნილ აგებას, რაღაცას გეუბნებათ.
- კომუნიკაციას. დროის სარტყლების გადაფარვა, ენის თავისუფლად ფლობა და სახელით დასახელებული საკონტაქტო პირი უფრო მნიშვნელოვანია, ვიდრე ადამიანების უმეტესობა ფიქრობს. სამუშაო დღის ოთხსაათიანი გადაფარვა ჩვეულებრივ პრაქტიკული მინიმუმია.
- რეკომენდაციებს. ესაუბრეთ წარსულ კლიენტებს, იდეალურად იმ პროექტზე, რომელიც გართულდა. ის, თუ როგორ ეგებება პარტნიორი პრობლემებს, უფრო მეტყველია, ვიდრე უნაკლო შემთხვევის შესწავლა.
შეფასების დროს სასარგებლო ტექნიკაა მცირე, ანაზღაურებადი ცდის ჩატარება — ორკვირიანი განსაზღვრული ამოცანა რეალური შედეგით. უფრო მეტს ისწავლით იმით, თუ როგორ ეგებება გუნდი ერთ ნამდვილ დავალებას, ვიდრე თვიანი გაყიდვების ზარებიდან. დააკვირდით, როგორ სვამენ დამაზუსტებელ კითხვებს, როგორ აფასებენ და არის თუ არა მათ მიერ დაბრუნებული კოდი ისეთი, რომლის შენახვაც კომფორტული იქნება.
მოამზადეთ ნიადაგი წარმატებისთვის კოდის დაწყებამდე
თანამშრომლობის პირველი ორი კვირა განსაზღვრავს მომდევნო ორ წელს. ჩადეთ ინვესტიცია:
- მკაფიო მასშტაბსა და წარმატების მეტრიკაში. ყველამ უნდა შეათანხმოს, როგორ გამოიყურება „დასრულებული" და როგორ იზომება ის. „ააგე დაფა" არ არის მასშტაბი; „მომხმარებლებს შეუძლიათ შეკვეთების გაფილტვრა თარიღის მიხედვით და CSV-ში ექსპორტი ორ წამზე ნაკლებ დროში" — ეს მასშტაბია.
- საერთო ხელსაწყოებსა და წვდომაში. რეპოზიტორიები, პროექტის დაფები, დიზაინის ფაილები და სატესტო გარემოები პირველ დღესვე მზად უნდა იყოს. ინჟინერი, რომელიც პირველ კვირას GitHub-ზე წვდომის მოლოდინში ატარებს, ძვირადღირებული ფლანგვაა.
- კომუნიკაციის რიტმში. ყოველდღიური ასინქრონული განახლებები, ყოველკვირეული დემო და ერთი ესკალაციის გზა ხელს უშლის სიურპრიზებს. ყოველკვირეული დემო ყველაზე მნიშვნელოვანია: ეკრანზე ნაჩვენები მომუშავე პროგრამა გასჭრის სტატუს-ანგარიშების ოპტიმიზმს.
- კოდის ბაზის საკუთრებაში. დარწმუნდით, რომ კონტრაქტი ინტელექტუალურ საკუთრებას თქვენ განიჭებთ და რომ თავიდანვე გაქვთ სრული წვდომა წყაროზე. უნდა შეგეძლოთ რეპოზიტორიის კლონირება პირველ დღესვე და ყოველ დღე ამის შემდეგ.
ასევე ღირს დასრულების განსაზღვრების მკაფიოდ დადგენა: მოიცავს თუ არა „დასრულებული" ტესტებს, დოკუმენტაციასა და კოდის მიმოხილვას, თუ მხოლოდ კოდს, რომელიც დეველოპერის მანქანაზე გაეშვება? აქ არსებული ბუნდოვანება ის ადგილია, სადაც ხარისხი ჩუმად ისხლტება.
ფასების მოდელები და რას მალავენ ისინი
ის, თუ როგორ იხდით, აყალიბებს სტიმულებს ორივე მხარეზე, ამიტომ ის უფრო მეტ ფიქრს იმსახურებს, ვიდრე „რა არის განაკვეთი?"
- დრო და მასალები. იხდით ნამუშევარ საათებში შეთანხმებული განაკვეთით. ეს არის გულწრფელი ნაგულისხმევი არჩევანი განვითარებადი სამუშაოსთვის: ინარჩუნებთ პრიორიტეტების სრულ კონტროლს და შეგიძლიათ მიმართულების შეცვლა ხელახალი მოლაპარაკების გარეშე. რისკი თქვენზეა, შეინარჩუნოთ ბექლოგი მკაცრად, რადგან იხდით ყველაფერში, რაც აიგება.
- ფიქსირებული ფასი. თანხმდებით ჯამზე განსაზღვრული მასშტაბისთვის. მომწოდებელი ატარებს მიწოდების რისკს, რაც მიმზიდველად ჟღერს — მაგრამ ეს მხოლოდ მაშინ მუშაობს, როცა მასშტაბი ნამდვილად ფიქსირებულია. იმ წამს, როცა მოთხოვნები იცვლება, ცვლილების ორდერების ტერიტორიაზე ხართ, და მომწოდებლის სტიმული გადაიხრება იქით, რომ გააკეთოს მინიმუმი, რასაც კონტრაქტი სიტყვასიტყვით მოითხოვს.
- გამოყოფილი გუნდი (ყოველთვიური). იხდით პროგნოზირებად ყოველთვიურ ხარჯს სტაბილური გუნდისთვის. საუკეთესოა მიმდინარე პროდუქტებისთვის, სადაც უწყვეტობასა და სიმძლავრეს ერთჯერად მიწოდებაზე მაღლა აფასებთ.
დახვეწილი მახე არის დაბალფასიანი ფიქსირებული შეთავაზება. მომწოდებელი, რომელიც ყველაზე ბევრად დაბალ ფასს გასცემს, ჩვეულებრივ გეგმავს მარჟის უკან დაბრუნებას ცვლილების ორდერებით, ან არასწორად გაიგო მასშტაბი და მეორე თვისთვის ფულს დაკარგავს — არცერთი ამათგანი კარგად არ მთავრდება თქვენთვის. საეჭვოდ იაფ ფიქსირებულ შეთავაზებას მოეპყარით, როგორც გაფრთხილებას და არა გამარჯვებას.
ოფშორი, ნირშორი და დროის სარტყლები
სად ზის თქვენი პარტნიორი, კომუნიკაციაზე ბევრად მეტ გავლენას ახდენს, ვიდრე ფასზე. ნირშორი (რამდენიმე დროის სარტყლის მოშორებით) გაძლევთ გადამფარავ სამუშაო საათებსა და უფრო მარტივ რეალურ დროში თანამშრომლობას. ოფშორი (რვა ან მეტი საათის მოშორებით) შეიძლება იყოს შესანიშნავი ღირებულება და კარგად მუშაობს კარგად განსაზღვრული, ასინქრონული სამუშაოსთვის, მაგრამ ის სჯის ბუნდოვან მოთხოვნებს — გაუგებრობა, რომელიც თქვენი დროით 9 საათზე აღმოაჩინეს, შეიძლება მხოლოდ მეორე დღეს მოგვარდეს.
პრაქტიკული წესია დროის სარტყლის მანძილის შესაბამისობა იმასთან, რამდენ რეალურ დროში თანამშრომლობას მოითხოვს სამუშაო. მჭიდროდ დაკავშირებული პროდუქტის სამუშაო ყოველდღიური გადაწყვეტილებებით სარგებლობს გადაფარვით. მკაფიოდ განსაზღვრულ უკანა მხარის სერვისს ან მონაცემთა მიგრაციას შესანიშნავად შეუძლია ოფშორში მუშაობა. მიზნად დაისახეთ მაინც სამიდან ოთხ საათამდე სამუშაო დღის გადაფარვა, რათა რაიმე ბლოკატორმა არასოდეს დაგიჯდეთ მთელი დღე.
გავრცელებული შეცდომები, რომელთა თავიდან აცილებაც სჭირდება
- მომწოდებლის შავ ყუთად მოპყრობა. საუკეთესო შედეგები თანამშრომლობით მოდის, და არა გადაცემითა და გაქრობით. გუნდები, რომლებიც ერთვებიან, კონტექსტს იზიარებენ და პარტნიორს კოლეგებად ექცევიან, მნიშვნელოვნად უკეთეს შედეგს იღებენ.
- შიდა მფლობელის არარსებობა. თქვენი მხრიდან ვინმემ უნდა ფლობდეს ურთიერთობასა და პროდუქტის ხედვას. შიდა პროდუქტის მფლობელის გარეშე, რომელსაც გადაწყვეტილებების მიღება შეუძლია, ყოველი კითხვა ჩერდება.
- დოკუმენტაციის გამოტოვება. თუ ცოდნა მხოლოდ მომწოდებლის თავებში ცხოვრობს, ჩაკეტილი ხართ. დააჟინეთ README-ზე, არქიტექტურის ჩანაწერებსა და სამუშაო ინსტრუქციებზე, როგორც მიწოდების ნაწილზე.
- ყველაზე დაბალ შეთავაზებაზე ოპტიმიზაცია. იაფი გუნდები, რომლებსაც მუდმივი გადაკეთება სჭირდებათ, საბოლოოდ ყველაზე ძვირადღირებული ვარიანტია. პროდუქციაში აღმოჩენილი ხარვეზი ბევრად მეტი ჯდება, ვიდრე ის საათები, რომლებიც განაკვეთზე დაზოგეთ.
- ბუნდოვანი მიღების კრიტერიუმები. თუ ვერ შეძლებთ შეამოწმოთ, დასრულდა თუ არა ფუნქცია, ვერ გაიგებთ, მოგაწოდეს თუ არა ის.
რეალისტური მაგალითი
განვიხილოთ საშუალო ზომის საცალო მოვაჭრე, რომელსაც სურს მომხმარებლის ლოიალურობის აპლიკაცია სეზონური კამპანიისთვის. მოთხოვნები ჯერ კიდევ მოქნილია — მარკეტინგის გუნდი მუდმივად ამატებს იდეებს — ამიტომ ფიქსირებული ფასის კონტრაქტი მომწამვლელი იქნებოდა. სწორი გადაწყვეტა არის მცირე გამოყოფილი გუნდი მკაფიო ბექლოგით, ყოველკვირეული დემოთი და მკაცრი გაშვების თარიღით, რომელიც შეზღუდვად მოქმედებს. მასშტაბი იქ თარიღის შიგნით იხრება; თარიღი არ იცვლება. ამის საპირისპიროდ, იმავე მოვაჭრის შემდგომი საჭიროება — შეკვეთების ხუთწლიანი ისტორიის მიგრაცია ახალ მონაცემთა ბაზაში — სრულყოფილი ფიქსირებული მასშტაბის პროექტია: მოთხოვნები წინასწარ შეცნობადია, ამიტომ შედეგზე დაფუძნებული კონტრაქტი ორივე მხარისგან რისკს აშორებს. იგივე კომპანია, ორი ძალიან განსხვავებული მოდელი, თითოეული მორგებული იმაზე, რამდენად კარგად არის სამუშაო განსაზღვრული.
როგორ უდგება Techies აუთსორსინგს
Techies-ში ჩვენ ვაშენებთ აუთსორსინგის თანამშრომლობას გამჭვირვალობისა და საკუთრების ირგვლივ. იღებთ გამოცდილ ინჟინრებს, მკაფიო ანგარიშგებას და კოდს, რომელიც თქვენს გუნდს შეუძლია აიღოს და გააგრძელოს — არასოდეს შავ ყუთს. გჭირდებათ თუ არა სრული პროდუქტის გუნდი თუ რამდენიმე სპეციალისტი, მიზანი ერთია: ხარისხიანი პროგრამული უზრუნველყოფის გაშვება მასზე კონტროლის დაკარგვის გარეშე.
თუ თქვენს ვარიანტებს აწონ-დაწონით, ჩვენი პროგრამული უზრუნველყოფის აუთსორსინგის გვერდი ანაწევრებს თითოეულ მოდელს და სად ერგება ის.
დასკვნა
წარმატებული აუთსორსინგი ძირითადად მოწყობასთან არის დაკავშირებული და არა შერჩევასთან. აირჩიეთ მოდელი, რომელიც ემთხვევა იმას, რამდენად განსაზღვრულია თქვენი პროექტი, შეაფასეთ საინჟინრო ხარისხი ფასზე მაღლა, გაუშვით მცირე ცდა, ვიდრე ვალდებულებას აიღებთ, და ჩადეთ ინვესტიცია პირველ ორ კვირაში. სწორად შეასრულეთ ეს და აუთსორსინგი ერთ-ერთ ყველაზე ეფექტურ გადაწყვეტილებად იქცევა, რომელიც შეგიძლიათ მიიღოთ — არა აზარტული თამაში, არამედ შესაძლებლობის მოთხოვნისამებრ დამატების განმეორებადი გზა.
ფიქრობთ თქვენი მომდევნო პროექტის აუთსორსინგზე? დაგვიკავშირდით.
