دامنه، سرور، حساب استور و مخزن کد به نام کیست؟

قرارداد شما میگوید سورس کد متعلق به شماست. بسیار خب. حالا همین الان، بدون تماس با پیمانکار، میتوانید دامنهٔ سایتتان را به سرور دیگری وصل کنید؟ میتوانید نسخهٔ جدید اپ را در فروشگاه اپلیکیشن منتشر کنید؟ میدانید سرور اصلی به نام کیست؟
اگر جواب هر کدام «نه» یا «نمیدانم» است، آنچه مالکش هستید، فایلی است که بدون این حسابها کار زیادی با آن نمیشود کرد.
این مقاله دربارهٔ یک خلأ مشخص است: حق مالکیت روی کاغذ، و کنترل واقعی روی حسابها. بندهای قرارداد و وابستگی به تأمینکننده را جداگانه نوشتهایم؛ اینجا فقط یک سؤال داریم: کلیدها دست کیست؟
چرا این اتفاق میافتد
بدخواهی در کار نیست، تقریباً هیچوقت. در هفتهٔ اول پروژه، کسی باید سریع حساب سرور بسازد تا کار شروع شود. پیمانکار با ایمیل خودش میسازد، چون ایمیل شما هنوز دست نیامده، یا چون سادهتر است. قرار است «بعداً منتقل شود». بعداً همیشه دیر میشود: هر بار که منتقل نشده، چیز تازهای هم به آن وصل شده.
دو سال بعد، حساب ثبتشده با ایمیل کسی است که دیگر در آن شرکت نیست، و بازیابی رمز به آن میرود.
فهرست حسابها
برای هر نرمافزار، این چند دسته وجود دارد. نه همهشان برای هر پروژه لازماند، ولی باید بدانید کدام را دارید:
| حساب | نام صاحب | پیمانکار چه دسترسی دارد |
|---|---|---|
| ثبت دامنه و تنظیمات DNS | شرکت شما | کاربر اضافهشده، با دسترسی محدود |
| سرور، میزبانی یا حساب ابری | شرکت شما | کاربر اضافهشده، نه ریشه |
| مخزن کد | شرکت شما | عضو مخزن |
| حساب توسعهدهنده در فروشگاههای اپلیکیشن | شرکت شما | نقش توسعهدهنده یا ناشر، نه مالک |
| درگاه پرداخت و حساب بانکی مرتبط | شرکت شما | معمولاً هیچ، یا دسترسی فنی محدود |
| سرویس پیامک و ایمیل | شرکت شما | کلید API، قابل ابطال |
| گواهی SSL و تمدیدش | شرکت شما، یا خودکار | — |
| مجوز اجزای پولی (کتابخانه، قالب، نقشه) | شرکت شما | استفاده در همان پروژه |
| ابزار تحلیل و رصد خطا | شرکت شما | عضو |
| نسخهٔ پشتیبان | جایی که شما به آن دسترسی دارید | هیچ، یا فقط نوشتن |
| پنل مدیر خود نرمافزار | شما، با حساب اصلی | حساب جداگانه با نقش مشخص |
قاعدهای که از این جدول بیرون میآید، یک جمله است: صاحب حساب شما هستید، پیمانکار «مهمان» است. مهمانی که بیاید و برود و شما چیزی را از دست ندهید.
ایمیلی که باید ثبتنام را بگیرد
حسابها را با ایمیل شرکت بسازید، ترجیحاً یک نشانی مشترک مثل tech@ یا admin@ که چند نفر به آن دسترسی دارند، نه ایمیل شخصی یک نفر. وقتی آن فرد رفت، صندوق شما هنوز هست و بازیابی رمز به جای درستی میرسد.
و دو نفر: هر حساب مهم دستکم دو نفر از طرف شما بتوانند به آن برسند. یک نفر با یک گوشی برای تأیید دومرحلهای، نقطهٔ شکست است.
آزمون دهدقیقهای
همین الان، بدون هیچکس، اینها را انجام بدهید:
- وارد حساب ثبتکنندهٔ دامنه شوید. دامنه به نام شماست؟ تاریخ انقضایش کی است؟
- وارد پنل سرور شوید. شما مدیر هستید، یا مهمان؟
- مخزن کد را باز کنید. میتوانید یک عضو تازه اضافه کنید؟
- حساب فروشگاه اپلیکیشن: ناشر کیست؟
- پیامک و ایمیل: قبض به نام کیست؟
- نسخهٔ پشتیبان کجاست و چه کسی میتواند بازیابیاش کند؟
هر جا یک «نمیتوانم» پیدا کردید، یک خط در یک فهرست بنویسید. این فهرست اولین چیزی است که به پیمانکار میدهید.
اگر حسابها به نام پیمانکار است
آرام باشید؛ معمولاً قابل حل است، و درخواست انتقال هیچ توهینی نیست.
اول ترتیب را بدانید. دامنه، بعد سرور، بعد مخزن، بعد بقیه. دامنه اگر از دست برود، بقیه هم بیمعنی میشود و بازگرداندنش سختترین است.
درخواست را مکتوب و ساده بنویسید. «برای سیاست داخلی شرکت، همهٔ حسابها باید به نام شرکت باشد؛ چه زمانی میتوانید انتقال دهید؟» اغلب بدون اصطکاک انجام میشود، چون پیمانکار هم نمیخواهد مسئول حساب شما باشد.
انتقال را بدون وقفه برنامهریزی کنید. بعضی انتقالها (مثل حساب فروشگاه اپلیکیشن) روزها طول میکشند و بعضی چند دقیقه. بهتر است کسی که کار را میشناسد کنارتان باشد.
اگر پیمانکار طفره رفت یا بهانه آورد، این خودش اطلاعات است؛ در مقالهٔ انتخاب پیمانکار از نشانههای هشدار نوشتهایم.
و از روز اول
اگر هنوز شروع نکردهاید، سادهترین کار این است که در همان جلسهٔ اول، پیش از اولین خط کد، یک جمله به قرارداد یا صورتجلسه اضافه شود: «همهٔ حسابها به نام کارفرما ثبت میشود و پیمانکار بهعنوان کاربر دعوت میشود.» و در پایان پروژه، همین فهرست جدول، تکمیلشده، بخشی از تحویل باشد.
از هر پیمانکاری که با این جمله مشکل دارد، چیزی یاد میگیرید که تا قبل از امضا برایتان مهمتر از قیمت است.