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

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

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

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

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

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

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

  1. ثبت دامنه

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

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

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

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

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

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

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

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

6 نظرات

  1. 1

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

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

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

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

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

    • 2

      نه واقعا،

      فکر می کنم موافقیم منظور من در این مورد اطمینان از داشتن کد است و می توانید با آن از در خارج شوید. اگر توسعه دهنده شما برای شما کد تهیه می کند و آن را به سمت سایت شما سوق می دهد - شما این کد را ندارید. من این اتفاق را در مورد همه چیز دیده ام ، از گرافیک ، Flash ، .NET ، Java ... هر چیزی که به یک فایل منبع نیاز دارد و از آن خارج می شود.

      داگ

  2. 3

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

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

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

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

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

  3. 4

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

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

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

    علاوه بر این ، از نظر فلسفی ، اگر شما از استفاده از بستر میزبانی برنامه نویس خود امتناع می کنید زیرا نمی خواهید "گروگان شوید" ، این از همان ابتدا بی اعتمادی را ایجاد می کند. اگر واقعاً به توسعه دهنده خود به اندازه کافی برای میزبانی از او اعتماد ندارید ، پس واقعاً از ابتدا می خواهید با او کار کنید؟

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

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

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

    • 5

      سلام مایکل،

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

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

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

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

  4. 6

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

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

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

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

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

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

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

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

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