از گروگان گرفتن توسط توسعه دهندگان خودداری کنید

100107آخر این هفته من با یک هنرمند محلی که به رئیس خود در مدیریت چند برنامه وب که رئیسش مالک او است کمک می کند ، مکالمه ای را شروع کردم.

مکالمه به نوبه خود انجام شد و برخی از تخلیه ها در مورد پرداخت هزینه های توسعه هفتگی بدون دیدن پیشرفت با توسعه دهنده ای که با آنها کار کرده اند ادامه یافت. اکنون سازنده می خواهد برای تکمیل پروژه و همچنین هزینه تعمیر و نگهداری هفتگی برای جبران سایر درخواست ها ، هزینه یکجا را از آنها بگیرد. بدتر میشود.

توسعه دهنده نام دامنه ها را منتقل کرده تا بتواند آنها را مدیریت کند. توسعه دهنده همچنین برنامه را در حساب میزبانی خود میزبانی می کند. به طور خلاصه ، توسعه دهنده اکنون آنها را به گروگان گرفته است.

خوشبختانه ، زنی که با او کار می کنم در گذشته خواستار دسترسی اداری برای ویرایش برخی از پرونده های الگو برای سایت شده است. توسعه دهنده می توانست دسترسی محدودی برای او ایجاد کند اما این کار را نکرد. او (با تنبلی) ورود به سیستم سایت را برای او فراهم کرد. امشب از این دسترسی برای پشتیبان گیری از همه کدهای سایت استفاده کردم. من همچنین فهمیدم که وی از چه نرم افزاری مدیریتی استفاده می کند و راهی اداره بانک اطلاعاتی شدم ، جایی که می توانم داده های برنامه ها و ساختار جدول را صادر کنم. وای

مالک در حال برنامه ریزی برای انتقال سایت ها به نام دامنه های جدید پس از تکمیل توسعه بود. این بزرگ است زیرا به این معنی است که دامنه های فعلی در صورت ایجاد یک جدایی عصبانی بین توسعه دهنده و شرکت ، منقضی می شوند. من قبلاً این اتفاق را دیده ام.

برخی از نکات در صورتی که می خواهید تیم توسعه خارج از سازمان خود را بدست آورید:

  1. ثبت دامنه

    نام دامنه های خود را به نام شرکت خود ثبت کنید. بد نیست که توسعه دهنده خود را به عنوان یک تماس فنی در حساب کاربری داشته باشید ، اما هرگز مالکیت دامنه را به هر کسی خارج از شرکت خود انتقال دهید.

  2. میزبانی برنامه یا سایت شما

    بسیار خوب است که توسعه دهنده شما ممکن است یک شرکت میزبان داشته باشد و بتواند سایت شما را برای شما میزبانی کند ، اما این کار را نکنید. درعوض ، از توصیه های وی برای محل میزبانی برنامه بپرسید. درست است که توسعه دهندگان با نرم افزار مدیریت ، نسخه ها و مکان منابع آشنا می شوند و این می تواند به تکمیل محصول شما زودتر کمک کند. هرچند که گفته شد ، صاحب حساب میزبانی شوید و توسعه دهنده خود را با ورود به سیستم و دسترسی خود اضافه کنید. به این ترتیب می توانید هر زمان که بخواهید دوشاخه را بکشید.

  3. مالک کد باشید

    تصور نکنید که کد شما متعلق به شماست ، آن را به صورت کتبی قرار دهید. اگر نمی خواهید سازنده خود از راه حل هایی که به او پرداخت کرده اید استفاده کند تا در جای دیگری توسعه یابد ، باید در زمان عقد قرارداد تصمیم بگیرید. من راه حل هایی را از این طریق توسعه داده ام اما در مواردی که حقوق کد را حفظ می کنم نیز آنها را توسعه داده ام. در مورد دوم ، من هزینه برنامه را کاهش دادم تا انگیزه ای برای شرکت برای دادن حق به من ایجاد شود. اگر مخالف نیستید که توسعه دهنده از کد شما در جای دیگری استفاده کند ، پس نباید بالاترین دلار را بپردازید!

  4. نظر دوم را بگیرید!

    وقتی افراد به من می گویند که پیشنهاد می دهند یا با متخصصان دیگر مشورت می کنند ، این احساسات من را آزار نمی دهد. در واقع ، من آن را توصیه می کنم!

نکته اصلی این است که شما برای استعداد توسعه دهنده خود هزینه می کنید اما باید کنترل و مالکیت ایده را حفظ کنید. مال شماست این شما بودید که روی آن سرمایه گذاری کردید ، شما بودید که تجارت و سودآوری خود را برای آن به خطر انداختید ... و این شما هستید که باید آن را حفظ کنید. توسعه دهندگان می توانند جایگزین شوند و این هرگز نباید برنامه شما یا بدتر از آن - کسب و کار شما را در معرض خطر قرار دهد.

6 نظرات

  1. 1

    من یک توسعه دهنده برنامه وب هستم و با اکثر نکات شما موافقم (شاید همه) اما می خواهم در مورد شماره 3 توضیحی ارائه کنم.

    تکثیر عمده سایت یا اپلیکیشن فروخته شده به یک شرکت دیگر (یا بدتر از آن یک رقیب) غیراخلاقی است و همیشه باید در قرارداد شما قید شود که قابل قبول نیست. با این حال، من در حین کار بر روی پروژه مشتری راه‌حل‌های نوآورانه‌ای برای مشکلات رایج ایجاد کرده‌ام که هیچ ربطی به شغل خاص آن‌ها ندارد و همچنین بخش قابل توجهی از راه‌حل کلی را نشان نمی‌دهد.

    مثال:
    مشتری می خواست سطح صفحه و کنترل سطح زمینه مرتبط با نقش های کاربر. عملکرد "خارج از جعبه" برای ASP.Net مجوزهای سطح پوشه را انجام می دهد. بنابراین من مجوزهای اصلی را برای Net گسترش دادم و راه حل را به عنوان بخشی از یک برنامه وب کلی ارائه کردم.

    من معتقدم که آنها مستحق کل پایگاه کد (همانطور که در قرارداد ذکر شده است) هستند، اما من برای استفاده از همان روش و تکه‌های کد برای انجام این توسعه در پروژه‌های آینده توجیه می‌کنم.

    چین و چروک دیگر:
    من این کار را در حالی انجام دادم که توسط یک شرکت مشاوره مزرعه داشتم. آیا به نظر شما شرکت مشاور حق دارد به عقب برگردد و آن راه حل را کپی کند و آن را به عنوان راه حل خود بازاریابی کند؟

    • 2

      نه واقعا،

      فکر کنم موافقیم هدف من در این مورد این است که اطمینان حاصل کنم که کد را دارید و می توانید با آن از در خارج شوید. اگر برنامه‌نویس شما در حال کامپایل کردن کد برای شما است و آن را به سایت شما ارسال می‌کند - شما کد را ندارید. من این اتفاق را با همه چیز از گرافیک، فلش، دات نت، جاوا... هر چیزی که نیاز به فایل منبع داشته باشد و خروجی داشته باشد، دیده ام.

      داگ

  2. 3

    من می بینم که شما از کجا آمده اید و در حالی که من با همه چیز 100٪ موافق نیستم (اخطارهایی دارم)، شرکت ها باید همیشه این را در نظر داشته باشند.

    1. کاملا. نمی توان به اندازه کافی بر این موضوع تاکید کرد. من برای یک شرکت کوچک کار کرده‌ام که این کار را انجام می‌داد و به خاطر درگیر بودنم احساس گناه می‌کردم. خیلی خوشحالم که توانستم از آنجا بیرون بیایم. مشتریان باید کاملاً کنترل دامنه های خود را حفظ کنند. اگر آنها فردی باهوش دارند، به توسعه دهنده اجازه دسترسی به این را ندهید. اگر نه، مطمئن شوید که توسعه‌دهنده راهی برای تغییر اطلاعات/انتقال دامنه از طریق یک رابط نمایندگی فروش حداقل برای شما دارد.

    2. من تا حدی با این موافق هستم، اما بستگی به موقعیت دارد. اگر یک برنامه ساده PHP راه‌اندازی می‌کنید و نیاز به میزبانی کم‌هزینه دارید، به‌هرحال یک حساب LunarPages یا DreamHost یا چیزی دیگر دریافت کنید و آن را در آنجا رها کنید. به توسعه دهنده اجازه دسترسی بدهید. با این حال، هاست اشتراکی کم هزینه قطعاً دارای معایبی است ... به خصوص برای چیزهای بزرگتر. اما اگر آنقدر بزرگ هستید که نگران این موضوع باشید، باید یک نفر فنی در کارکنان داشته باشید که بتواند با آن مقابله کند. بسیاری از آن به وضوح در مورد اعتماد است. مطمئناً اگر می توانید در مورد این نوع چیزها (محدودیت ها و موارد دیگر) چیزی را در یک قرارداد قرار دهید. میزبانی شخص ثالث عالی است اگر توسعه دهنده نیازی به انجام کار فانتزی نداشته باشد. اعتراف می کنم که پاره شده ام زیرا این واقعاً یک چیز موقعیتی است. همچنین به اندازه سایت، آرایه فناوری های مورد استفاده بستگی دارد. اگر قرار است بزرگ باشد، به استخدام یک نفر در کارکنان فکر کنید. همیشه یک گزینه نیست، اما برای چیزهای بزرگ امن تر است.

    3. این نیز کاری است که شرکت سابق من انجام داده است. شما می توانید ترک کنید، آنها HTML، تصاویر و غیره را به شما می دهند. اما بدون کد کد اساساً یک سرویس اجاره ای بود. که گفته شد، مالکیت و مالکیت وجود دارد. من همیشه یک فروش غیر انحصاری انجام داده ام. اساساً باید بتوانم از اجزای خود دوباره استفاده کنم. من هیچ مشکلی با مشتری ندارم که آن را داشته باشد، کاری که او می خواهد با آن انجام دهد و شخص دیگری روی آن کار کند... اما من خودم را رهن نمی کنم و مجبور نیستم هر بار چرخ را دوباره اختراع کنم.

    4. همیشه. همیشه. همیشه.

  3. 4

    پست خوبی بود... آفرین، اگرچه من با یک مورد مخالفم (#2):

    "خیلی خوب است که توسعه دهنده شما ممکن است یک شرکت میزبان داشته باشد و بتواند سایت شما را برای شما میزبانی کند، اما این کار را نکنید."

    اگرچه من منطق پشت این موضوع را درک می کنم، اما در برخی موارد می تواند اجباری باشد که پروژه شما در جای دیگری میزبانی شود. اگر شرکتی که سایت یا برنامه شما را توسعه می‌دهد، پلتفرم میزبانی دارد که ترجیح می‌دهند از آن استفاده کنند، به احتمال زیاد استفاده از آن برای آنها کارآمدتر و سازنده‌تر خواهد بود.

    علاوه بر این، از دیدگاه فلسفی، اگر از استفاده از پلتفرم میزبانی توسعه‌دهنده خود امتناع می‌کنید، زیرا نمی‌خواهید «گروگان» نگه داشته شوید، از همان ابتدا یک لحن بی‌اعتمادی ایجاد می‌کند. اگر واقعاً به اندازه کافی به توسعه دهنده خود برای میزبانی با آنها اعتماد ندارید، آیا واقعاً می خواهید در وهله اول با آنها کار کنید؟

    من می‌دانم که داستان‌های ترسناک زیادی درباره این نوع موقعیت‌ها وجود دارد، اما به طور کلی توصیه می‌کنم روی یافتن توسعه‌دهنده‌ای متمرکز شوید که به آن اعتماد دارید. شما می توانید از میزبانی توسعه دهنده خود استفاده کنید و همچنان با درخواست دسترسی مدیریت و تهیه نسخه پشتیبان از خود محافظت کنید.

    باز هم پست خوب و اطلاعات بسیار مفید.

    با تشکر!
    مایکل رینولدز

    • 5

      سلام مایکل،

      ممکن است مانند یک مسئله اعتماد به نظر برسد، اما فکر نمی‌کنم اینطور باشد - این واقعاً یک مسئله کنترل و مسئولیت است. اگر قصد دارید مبلغ قابل توجهی در توسعه وب سایت خود سرمایه گذاری کنید، پس باید مطمئن باشید که می توانید محیط آن را کنترل کنید.

      چیزهایی در تجارت اتفاق می افتد که روابط را قطع می کند و لازم نیست منفی باشد. شاید توسعه دهنده/شرکت شما مشتری بسیار بزرگی داشته باشد و نتواند وقت شما را تامین کند. شاید آنها اهداف تجاری را تغییر می دهند. گاهی اوقات شرکت میزبان آنها ممکن است مشکلاتی داشته باشد.

      من از شما حمایت می کنم که میزبانی خود را کنترل کنید و مسئولیت آن را بر عهده بگیرید تا بتوانید به توسعه دهنده خود برای آنچه که در آن عالی است - در حال توسعه - تکیه کنید!

      مایکل از عقب نشینی قدردانی می کنم.

  4. 6

    من همچنین یک توسعه دهنده برنامه های وب هستم و فکر می کنم شما ضربه ای به سر زده اید. برخی تفکرات:

    من فکر می کنم اکثر همه موافق هستند (و بر اساس نظرات زیر) شماره 1 مطلق است. هرگز، هرگز آن را انجام نده. همیشه. تحت هر شرایطی

    من در مورد شماره 2 نظر متفاوتی نسبت به برخی از توسعه دهندگان دیگر دارم: ما از میزبانی محصول نهایی برای مشتریان خود خودداری می کنیم (البته، ما میزبان یک سرور آزمایشی برای مشتریان هستیم تا محصول را در طول توسعه آزمایش کنند). ما خوشحالیم که به مشتریان کمک می کنیم تا خودشان میزبانی کنند یا یک ارائه دهنده میزبانی پیدا کنند. ما به سادگی نمی خواهیم وارد تجارت میزبانی شویم. اگر این به معنای دور زدن کار است، همینطور باشد. شرکت‌های میزبانی بزرگ یا شرکت‌های زیرساختی زیادی وجود دارند که می‌توانند این خدمات را با قیمت بسیار ارزان‌تری ارائه دهند. ما قابل حمل بودن کار خود را تشویق می کنیم، و هر کاری که از دستمان بر می آید برای کمک به میزبانی آن انجام می دهیم، حتی اگر مشتری سال ها بعد ارائه دهنده هاستینگ را تغییر دهد.

    برای شماره 3، مشتریان ما تمام کد منبع محصول نهایی را با یک اخطار دریافت می‌کنند: برای محصولات شخص ثالثی که در راه حل استفاده می‌شوند (مانند کنترل‌های وب از Telerik یا Component One)، می‌توانیم dll کامپایل‌شده را به مشتری بدهیم. کنترل شخص ثالث (مثلاً یک شبکه). قراردادهای مجوز ما با آن شرکت‌های شخص ثالث (که به مشتری ارائه می‌کنیم) ما را از توزیع مجدد کد منبع برای آن نوع کنترل‌ها منع می‌کند، زیرا مالکیت معنوی اشخاص ثالث است، نه مال ما. استفاده از این نوع محصولات باعث صرفه جویی در زمان توسعه برای مشتری می شود و بسیار ارزان تر از ساخت یک عملکرد مشابه از ابتدا است. ما قبل از انجام هر کاری از این سیاست آگاه هستیم. البته، اگر مشتری بخواهد برای توسعه کنترل سفارشی هزینه کند (به جای استفاده از محصول از پیش ساخته شده از شخص ثالث)، ما کد منبع آن کنترل سفارشی را همراه با هر چیز دیگری ارائه می کنیم.

    وقتی صحبت از استفاده مجدد از کد به میان می آید، ما پیش از هر کاری در مورد این واقعیت هستیم که ممکن است بخشی از کد را مجدداً استفاده کنیم، مگر اینکه صراحتاً به طور انحصاری برای استفاده مشتری (مثلاً برای یک فرآیند تجاری اختصاصی) قبل از انجام هر کاری ایجاد شده باشد. البته اگر مشتری بخواهد کد انحصاری توسعه داده باشد، این کد در دسترس اوست.

    همانطور که دیگران گفته اند، شماره 4 همیشه توصیه می شود. همیشه!

    با احترام،
    تیم یانگ

شما چه فکر میکنید؟

این سایت از Akismet برای کاهش هرزنامه استفاده می کند. بدانید که چگونه نظر شما پردازش می شود.