მოერიდეთ თქვენი დეველოპერების მიერ მძევლად აყვანას

მძევლად 100107ამ შაბათ-კვირას დავიწყე საუბარი ადგილობრივ მხატვართან, რომელიც ეხმარებოდა მის უფროსს რამდენიმე ვებ პროგრამის მართვაში, რომელსაც მისი უფროსი ფლობს.

საუბარმა რიგრიგობით მიიღო და გარკვეული ვენტილაციები განაგრძო ყოველკვირეული განვითარების საფასურის გადახდაზე, ისე რომ ვერ ნახა რაიმე პროგრესი იმ დეველოპერთან, რომელთანაც მუშაობდნენ. ახლა დეველოპერს სურს დაეკისროს მათ ერთიანი თანხის გადასახადი პროექტის შესასრულებლად, ისევე როგორც ყოველკვირეული ტექნიკური მომსახურების საფასური სხვა მოთხოვნების დასაფარავად. უარესად ხდება.

დეველოპერმა დომენური სახელების გადაცემა მოახერხა, რათა შეძლო მათი მართვა. დეველოპერი ასევე მასპინძლობს პროგრამას თავის ჰოსტინგის ანგარიშზე. მოკლედ, დეველოპერი მათ მძევლად ატარებს.

საბედნიეროდ, ქალმა, რომელთანაც ვმუშაობ, წარსულში მოითხოვა ადმინისტრაციული წვდომა საიტის ზოგიერთი შაბლონის რედაქტირებისთვის. დეველოპერს შეეძლო მისთვის შეზღუდული წვდომა ჰქონოდა, მაგრამ მან ეს ვერ გააკეთა. მან (ზარმაცი) მიაწოდა მას ადმინისტრაციული შესვლა საიტზე. დღეს მე გამოვიყენე წვდომა საიტის კოდის სარეზერვო ასლისთვის. მე ასევე მივხვდი, თუ რა მენეჯმენტ პროგრამულ პროგრამას იყენებდა და მონაცემთა ბაზის ადმინისტრაციისკენ წავედი, სადაც შევძელი როგორც აპლიკაციების მონაცემების, ისე ცხრილის სტრუქტურების ექსპორტი. უიჰ.

მფლობელი გეგმავდა საიტების ახალ დომენურ სახელებზე გადატანას, განვითარების დასრულების შემდეგ. ეს უზარმაზარია, რადგან ეს ნიშნავს, რომ ამჟამინდელი დომენების მოქმედების ვადა შეიძლება ამოიწუროს იმ შემთხვევაში, თუ დეველოპერსა და კომპანიას შორის გაბრაზებული გამიჯვნა მოხდა. ეს ადრეც მინახავს.

რამდენიმე რჩევა, თუ თქვენ აპირებთ მიიღოთ შემსრულებლის განვითარების ჯგუფი.

  1. დომენის რეგისტრაცია

    დომენური სახელების რეგისტრაცია თქვენი კომპანიის სახელით. ცუდი არ არის თქვენი დეველოპერი, როგორც ტექნიკური კონტაქტი, ანგარიშზე არასოდეს დომენის საკუთრების უფლების გადაცემა თქვენი კომპანიის გარეთ.

  2. თქვენი აპლიკაციის ან საიტის ჰოსტინგი

    ძალიან კარგია, რომ თქვენს დეველოპერს შეიძლება ჰოსტინგის კომპანია ჰყავდეს და შეუძლია თქვენი საიტი თქვენთვის უმასპინძლოს, მაგრამ ნუ გააკეთებთ ამას. ამის ნაცვლად, ჰკითხეთ მის რეკომენდაციებს, თუ სად უნდა უმასპინძლოს აპლიკაციას. მართალია, დეველოპერები ეცნობიან მენეჯმენტის პროგრამულ უზრუნველყოფას, ვერსიებს და რესურსების ადგილმდებარეობას, რაც ხელს შეუწყობს თქვენი პროდუქტის უფრო მალე დასრულებას. ამასთან, ფლობთ ჰოსტინგის ანგარიშს და დაამატეთ თქვენი დეველოპერი საკუთარი შესვლითა და წვდომით. ამ გზით, თქვენ შეძლებთ შტეფსელის გაყვანას, როცა დაგჭირდებათ.

  3. ფლობთ კოდექსს

    არ ჩათვალოთ, რომ კოდი გეკუთვნით, დაწერეთ იგი წერილობით. თუ არ გსურთ, რომ თქვენი დეველოპერი გამოიყენოს იმ გადაწყვეტილებების გამოყენებით, რომლებიც მას გადაუხადეთ, სხვაგან უნდა განვითარდეს, ეს უნდა გადაწყვიტოთ ხელშეკრულების დადების დროს. ამ გზით მე შემუშავებული მაქვს გადაწყვეტილებები, მაგრამ ასევე შევიმუშავე იქ, სადაც კოდექსზე ვიტოვებ უფლებებს. ამ უკანასკნელ შემთხვევაში, მე ვეთანხმები განაცხადის ღირებულებას უფრო დაბალ ფასად, რათა კომპანიამ ხელი შეუწყოს ჩემთვის უფლებების მინიჭებას. თუ არ გაწუხებთ, რომ თქვენი დეველოპერი თქვენს კოდს სხვაგან იყენებს, მაშინ არ უნდა გადაიხადოთ ყველაზე მაღალი დოლარი!

  4. მიიღეთ მეორე აზრი!

    ეს არ მწყინს ჩემს გრძნობებს, როდესაც ეგ მეუბნება, რომ ისინი წინადადებებს იღებენ ან კონსულტაციას უწევენ სხვა პროფესიონალებს. სინამდვილეში, მე გირჩევთ მას!

დასკვნა ისაა, რომ თქვენ იხდით თქვენი დეველოპერის ნიჭს, მაგრამ უნდა შეინარჩუნოთ კონტროლი და საკუთრება იდეაზე. შენია. თქვენ ჩადეთ მასში ინვესტიცია, თქვენ, ვინც რისკზე დააყენეთ თქვენი ბიზნესი და მოგება ... და თქვენ უნდა შეინარჩუნოთ იგი. დეველოპერები შეიძლება შეიცვალოს და ამან არასოდეს უნდა დააყენოს რისკის ქვეშ თქვენი განცხადება, ან კიდევ უარესი - თქვენი ბიზნესი.

6 კომენტარები

  1. 1

    მე ვებ აპლიკაციების შემქმნელი ვარ და ვეთანხმები თქვენს ბევრ პუნქტს (ალბათ ყველა), მაგრამ განმარტებები მინდა # 3-ზე.

    სხვა კომპანიისთვის (ან უარესი კონკურენტისთვის) გაყიდული საიტის ან პროგრამის საბითუმო დუბლირება არაეთიკურია და ყოველთვის უნდა იყოს მითითებული, როგორც მიუღებელი თქვენს კონტრაქტში. ამასთან, მე შემუშავებული მაქვს ინოვაციური გადაწყვეტილებები საერთო პრობლემების შესახებ, როდესაც ვმუშაობდი კლიენტის პროექტზე, რომელსაც საერთო არაფერი აქვს მათ კონკრეტულ ბიზნესთან და არც წარმოადგენს საერთო გადაწყვეტის მნიშვნელოვან ნაწილს.

    მაგალითი:
    კლიენტს სურდა გვერდის დონისა და ველის დონის კონტროლი, რომელიც დაკავშირებული იყო მომხმარებლის როლებზე. ASP.Net– ის ფუნქციონირება "out of box" ასრულებს საქაღალდის დონის ნებართვებს. ასე რომ, მე გავზარდე მშობლიური ნებართვები .Net– ზე და მივაწოდე გამოსავალი, როგორც ვებ – გვერდის საერთო აპლიკაციის ნაწილი.

    მე ვთვლი, რომ მათ აქვთ კოდექსის მთლიანი ბაზის (როგორც ხელშეკრულებაში მითითებული) უფლება აქვთ, მაგრამ თავს გამართლებულად ვთვლი, რომ იგივე მეთოდოლოგია და კოდების ბლოკები გამოვიყენო, რათა ამ პროექტს განვახორციელო მომავალი პროექტები.

    კიდევ ერთი ნაოჭი:
    მე ეს გავაკეთე მაშინ, როდესაც საკონსულტაციო კომპანია მეხმარებოდა. ექნებათ თუ არა საკონსულტაციო კომპანიას თქვენი აზრით უკან დაბრუნება და დააკოპირეთ ეს გამოსავალი, გაყიდოს იგი, როგორც საკუთარი?

    • 2

      Ნამდვილად არ,

      ვფიქრობ, თანახმა ვართ. ჩემი აზრი ამაში იმაში მდგომარეობს, რომ დავრწმუნდეთ, რომ კოდი გაქვთ და ამით შეგიძლიათ კარიდან გასვლა. თუ თქვენი შემქმნელი ადგენს კოდს თქვენთვის და უბიძგებს თქვენს საიტზე - თქვენ ეს კოდი არ გაქვთ. მე ვხედავდი, რომ ეს ყველაფერი ხდებოდა გრაფიკით, Flash- ით, NET- ით, Java- ით ... ყველაფერი, რაც მოითხოვს წყაროს ფაილს და გამოდის.

      Doug

  2. 3

    მე ვხედავ, საიდანაც მოდიხარ და 100% -ით არ ვეთანხმები ყველაფერს (მე მაქვს სიგნალები), კომპანიებმა ამას ყოველთვის უნდა გაითვალისწინონ.

    1. აბსოლუტურად. ამის საკმარისად სტრესი არ შეიძლება. მე ვმუშაობდი პატარა კომპანიაში, რომელმაც ეს გააკეთა და ვიგრძენი გამანადგურებელი დანაშაული ამ საქმეში. ძალიან მიხარია, რომ იქიდან გამოსვლა შევძელი. მომხმარებლებმა აბსოლუტურად უნდა გააკონტროლონ თავიანთი დომენები. თუ მათ საკმარისად საზრიანი ვინმე ჰყავთ, არ მისცეთ ამის შესაძლებლობა დეველოპერს. თუ არა, დარწმუნდით, რომ დეველოპერს აქვს გზა, რომ შეცვალოთ ინფორმაცია / დომენის გადაცემა მინიმუმ რაიმე სახის გადამყიდველის ინტერფეისით.

    2. ნაწილობრივ ამას ვეთანხმები, მაგრამ ეს დამოკიდებულია სიტუაციაზე. თუ თქვენ იყენებთ მარტივ PHP აპლიკაციას და გჭირდებათ დაბალი ჰოსტინგი, აუცილებლად მიიღეთ LunarPages ან DreamHost ანგარიში ან რამე და გადაყარეთ იქ. მიეცით დეველოპერს წვდომა. ამასთან, დაბალფასიან საერთო ჰოსტინგს ნამდვილად აქვს თავისი ნაკლი… განსაკუთრებით უფრო დიდი ნივთებისთვის. მაგრამ თუ საკმარისად დიდი ხარ იმისთვის, რომ იმაზე იდარდო, რომ პერსონალი უნდა გყავდეს ტექნიკური პერსონალით, რომელსაც შეუძლია გაუმკლავდეს მას. ბევრი მათგანი აშკარად ნდობას ეხება. რა თქმა უნდა, ჯოჯოხეთმა დადო რამე კონტრაქტში, თუ შეგიძლია ამგვარი ნივთების შესახებ (შეზღუდვები და სხვა). მესამე მხარის ჰოსტინგი შესანიშნავია, თუ დეველოპერს არ სურს რაიმე ლამაზი დიზაინის გაკეთება. ვაღიარებ, რომ მოწყვეტილი ვარ, რადგან ეს მართლაც სიტუაციური რამეა. ეს ასევე დამოკიდებულია საიტის ზომაზე, გამოყენებული ტექნოლოგიების მასაზე. თუ ეს დიდი იქნება, გაითვალისწინეთ პერსონალის დაქირავება. ყოველთვის არ არის ვარიანტი, მაგრამ უფრო უსაფრთხოა დიდი ნივთებისთვის.

    3. ესეც გააკეთა ჩემმა ყოფილმა კომპანიამ. შეგიძლიათ დატოვოთ, ისინი მოგცემთ HTML- ს, სურათებს და ა.შ.. მაგრამ კოდი არ არის. კოდი ძირითადად იყო საიჯარო მომსახურება. როგორც ითქვა, აქ არის ფლობა და ფლობა. მე ყოველთვის ვაკეთებდი არა ექსკლუზიურ გაყიდვას. ძირითადად, მე უნდა შემეძლოს ჩემი კომპონენტების ხელახლა გამოყენება. მე არანაირი პრობლემა არ მაქვს იმის შესახებ, რომ კლიენტი ფლობს მას, აკეთებს იმას, რაც მას სურთ და ვინმეს სჭირდება მასზე მუშაობა…

    4. ყოველთვის. ყოველთვის ყოველთვის

  3. 4

    სასიამოვნო პოსტია ... კარგად გაკეთებული, თუმცა არ ვეთანხმები ერთ პუნქტს (# 2):

    ”კარგია, რომ თქვენს შემქმნელს შეიძლება ჰოსტინგის კომპანია ჰყავდეს და თქვენი საიტი თქვენთვის უმასპინძლოს, მაგრამ არ გააკეთოთ ეს.”

    მიუხედავად იმისა, რომ მე მესმის ამის ლოგიკა, ზოგიერთ შემთხვევაში შეიძლება იყოს კონტრპროდუქტიული, რომ თქვენი პროექტი სხვაგან იყოს მასპინძელი. თუ თქვენს საიტს ან აპლიკაციას შემუშავებულ კომპანიას აქვს ჰოსტინგის პლატფორმა, რომლის გამოყენებას ისინი ამჯობინებენ, დიდი ალბათობით, მათი გამოყენება უფრო ეფექტური და პროდუქტიული იქნება.

    გარდა ამისა, ფილოსოფიური თვალსაზრისით, თუ თქვენ უარს იტყვით თქვენი დეველოპერის ჰოსტინგის პლატფორმის გამოყენებაზე, რადგან არ გსურთ "მძევლად გყავდეთ", ეს თავიდანვე უნდობლობას უქმნის. თუ ნამდვილად არ გჯერათ თქვენს შემქმნელს, რომ მასპინძლობს, მაშინ ნამდვილად გსურთ პირველ რიგში მათთან მუშაობა?

    მე ვიცი, რომ უამრავი საშინელებათა ისტორია არსებობს ამ ტიპის სიტუაციის შესახებ, მაგრამ ზოგადად გირჩევთ, ყურადღება გაამახვილოთ ისეთი შემქმნელის პოვნაზე, რომელსაც ენდობით. შეგიძლიათ გამოიყენოთ თქვენი დეველოპერის ჰოსტინგი და მაინც დაიცვათ თავი ადმინისტრაციული წვდომის მოთხოვნით და საკუთარი სარეზერვო ასლის შექმნით.

    კიდევ კარგი, კარგი პოსტი და ძალიან სასარგებლო ინფორმაცია.

    მადლობა!
    მაიკლ რეინოლდსი

    • 5

      Hi Michael,

      ეს შეიძლება ჩანდეს ნდობის საკითხი, მაგრამ არა მგონია, რომ ასეა - ეს ნამდვილად არის კონტროლისა და პასუხისმგებლობის საკითხი. თუ აპირებთ მნიშვნელოვანი ინვესტიციის ჩადებას ვებ – გვერდის განვითარებაში, მაშინ დარწმუნებული უნდა იყოთ, რომ მისი გარემოს კონტროლი შეგიძლიათ.

      ბიზნესში ხდება ისეთი რამ, რაც ურთიერთობას არღვევს და არ არის საჭირო ნეგატიური იყოს. შესაძლოა, თქვენი დეველოპერი / ფირმა იღებს ძალიან დიდ კლიენტს და ვერ ახერხებს დროის დათმობას. შესაძლოა, ისინი ბიზნესის მიზნებს ცვლის. ზოგჯერ მათ ჰოსტინგ კომპანიას შეიძლება პრობლემები შეექმნას.

      მე მხარს ვუჭერ თქვენ კონტროლს და პასუხისმგებლობას მასპინძლობთ თქვენს ჰოსტინგზე, ასე რომ თქვენ იქნებით დამოკიდებული თქვენს დეველოპერზე იმისთვის, თუ რაში ის შესანიშნავია - ავითარებს მას!

      მე ვაფასებ უკუქცევას, მაიკლ.

  4. 6

    მე ასევე ვებ – პროგრამების შემქმნელი ვარ და ვფიქრობ, რომ თავში მიარტყი. ზოგიერთი აზრი:

    მე ვფიქრობ, რომ ყველა ეთანხმება (და ამას ქვემოთ მოცემულ კომენტარზე დაყრდნობით) # 1 აბსოლუტურია. არასოდეს, არასოდეს გააკეთო ეს. მუდამ ნებისმიერ ვითარებაში.

    მე # განსხვავებული შეხედულება მაქვს # 2-სგან, ვიდრე ალბათ ჩემი ზოგიერთი ჩემი შემქმნელი: ჩვენ უარს ვამბობთ ჩვენი მომხმარებლისთვის საბოლოო პროდუქტის მასპინძლობაზე (რა თქმა უნდა, ჩვენ ვმასპინძლობთ ტესტირების სერვერს კლიენტებისთვის, რათა შეამოწმონ პროდუქტის მართვა განვითარების პროცესში). მოხარული ვართ, რომ კლიენტებს ვეხმარებით, რომ შექმნან მასპინძლობა მასში ან იპოვონ ჰოსტინგის პროვაიდერი. ჩვენ უბრალოდ არ გვინდა მასპინძლობის საქმეში ჩაება. თუ ეს გულისხმობს სამუშაოს გადაბრუნებას, ასეც იქნება. უამრავი ჰოსტინგის კომპანია ან ინფრასტრუქტურული ფირმა არსებობს, ვიდრე ამ სერვისის გაცილებით იაფი ფასით უზრუნველყოფა შეუძლიათ. ჩვენ ხელს ვუწყობთ ჩვენი მუშაობის პორტაბელურობას და ყველაფერს გავაკეთებთ, რომ მას უმასპინძლონ, მაშინაც კი, თუ კლიენტი მასპინძლობს პროვაიდერებს წლების განმავლობაში.

    # 3, ჩვენი კლიენტები მიიღებენ საბოლოო პროდუქტის ყველა კოდს ერთი შენიშვნით: მესამე მხარის პროდუქტებისთვის, რომლებიც გამოიყენება ხსნარში (მაგალითად, ვებ კონტროლი Telerik– დან ან კომპონენტი ერთი), ჩვენ შეგვიძლია კლიენტს მივცეთ შედგენილი DLL მესამე მხარის კონტროლი (ვთქვათ ქსელი). ჩვენი სალიცენზიო შეთანხმებები იმ მესამე მხარეთა კომპანიებთან (რომელსაც ჩვენ ვაძლევთ კლიენტს) კრძალავს ამ ტიპის კონტროლისთვის კოდის გადანაწილებას, რადგან ეს არის მესამე მხარის ინტელექტუალური საკუთრება და არა ჩვენი. ამ ტიპის პროდუქტების გამოყენება დაზოგავს განვითარების დროს კლიენტს და გაცილებით იაფია, ვიდრე იგივე ფუნქციონირების შექმნა ნულიდან. ჩვენ ამ პოლიტიკის წინააღმდეგი ვართ, სანამ რაიმე სამუშაო შესრულდება. რა თქმა უნდა, თუ მომხმარებელს სურს გადაიხადოს საბაჟო კონტროლის განვითარების საფასური (მესამე მხარისგან წინასწარ ნახმარი პროდუქტის გამოყენების ნაცვლად) ჩვენ წარმოგიდგენთ ამ პერსონალური კონტროლის კოდს ყველა დანარჩენთან ერთად.

    რაც შეეხება კოდის ხელახალ გამოყენებას, ჩვენ წინააღმდეგი ვართ იმ ფაქტის შესახებ, რომ შეიძლება გამოვიყენოთ კოდის გარკვეული ნაწილები, თუ ის არ იქნება შემუშავებული მხოლოდ კლიენტის გამოყენებისთვის (ვთქვათ საკუთრების ბიზნეს პროცესზე), სანამ რაიმე სამუშაო შესრულდება. თუ კლიენტს სურს შეიმუშაოს ექსკლუზიური კოდი, რა თქმა უნდა, ეს მათთვის ხელმისაწვდომია.

    როგორც სხვებმა თქვეს, # 4 ყოველთვის რეკომენდირებულია. ყოველთვის!

    Regards,
    ტიმ იანგი

რას ფიქრობთ?

ეს საიტი იყენებს Akismet- ს, რათა შეამციროს სპამი. შეისწავლეთ თქვენი კომენტარის მონაცემები დამუშავებული.