انتقال قدرت با مشکلاتی همراه است. تیم‌های مختلف ارزش‌های متفاوت، تجربه‌های متفاوت، تخصص‌های متفاوت، اولویت‌های متفاوت دارند و این منجر به ابزارهای متفاوت و متدولوژی‌های متفاوت می‌شود. این وسوسه انگیز است که به طراحی وب به عنوان یک پایان به انتها فکر کنید process، با تحقیق شروع می شود و با متریک به پایان می رسد. واقعیت این است که اکثر طراحان و توسعه‌دهندگان به پروژه‌ها به صورت جزئی از طریق یک پروژه پیوسته می‌پیوندند process. این ما را با انتخاب دشواری روبرو می‌کند: آیا ما سعی می‌کنیم انتظارات مشتری را با مجموعه ابزار خود برآورده کنیم یا خود را با ابزارها و فرآیندهایی که در حال حاضر وجود دارد سازگار کنیم؟ برای هر کسی که یک پروژه وب را از یک طراح/توسعه‌دهنده/آژانس متفاوت (D/D/A) به دست می‌گیرد، در اینجا یک راهنمای عملی وجود دارد که به شما کمک می‌کند تا انتقال را با موفقیت انجام دهید.

مرحله 1: پیدا کنید چه چیزی اشتباه بوده است

99.99٪ مواقع، چیزی در رابطه قبلی مشتری-D/D/A خراب شد. در تجربه من تقریباً هرگز به پول مربوط نمی شود. اگر باور داشته باشند که بازده خوبی دریافت می کنند، اکثر مشتریان مایل به پرداخت بالاتر از نرخ پایه بازار هستند روی سرمایه گذاری آنها مشتری که به شما می گوید D/D/A قبلی خیلی گران است، در حال پیش بینی مذاکره است شما هزینه ها (نقل قول)مشتریان خوشحال در اطراف خرید نمی کنند (/pullquote) گاهی اوقات متوجه می شوید که یک طراح آزاد توسط یک آژانس تحت تعقیب قرار گرفته است و دیگر در دسترس نیست. گاهی اوقات شرکت از یک D/D/A پیشی می گیرد و به مناطقی می رود که D/D/A پشتیبانی نمی کند. اما این شرایط نادر است، مشتریان خوشحال – حتی مشتریان با محتوای متوسط ​​- خرید نمی کنند. اگر آنها با شما صحبت می کنند، چیزی آنها را به انجام این کار تشویق می کند. به طور نگران کننده ای رایج است که D/D/A به سادگی AWOL می شود. این امر در پایین ترین سطح بازار رایج است، جایی که مبالغ پولی که در آن دخیل هستند کمتر باعث ایجاد اختلاف حقوقی می شود. اغلب، یک D/D/A نامعتبر، مشتری را به نفع یک فرصت بهتر و جدیدتر شبح می کند. گاهی اوقات مشتری یک مدیر جدید استخدام می کند و مدیر جدید انتظارات تجدید نظر شده ای را ارائه می دهد که D/D/A قبلی نمی تواند برآورده کند. معمولاً، D/D/A قبلی بارها توپ را رها کرده است – اشتباهات اتفاق می‌افتد، و مشتریان منطقی آنها را تحمل می‌کنند به شرطی که به سرعت اصلاح شوند، اما هر کسی محدودیت‌های خود را دارد. بیشتر مشتریان از توضیح آنچه در رابطه قبلی اشتباه بوده است، خوشحال خواهند شد. این به ناچار توضیحی یک طرفه خواهد بود، اما به شما کمک می کند تا انتظارات مشتری را درک کنید. نسبت به مشتری که نمی داند چه اشتباهی رخ داده است بسیار مراقب باشید. حتی بیشتر مراقب مشتری باشید که در مورد “ارتقا” برون سپاری خود صحبت می کند – آنها سعی می کنند شما را چاپلوسی کنند. در این موارد مشتری ممکن است چیزی را پنهان کند – مانند عدم پرداخت فاکتورها. به یاد داشته باشید: در مقطعی D/D/A قبلی جدید بود، و از داشتن مشتری جدید هیجان زده بود، به پروژه خوشبین بود و پایان خوبی نداشت. بهترین راه برای تکرار نکردن اشتباهات این است که از آنها درس بگیرید و برای انجام این کار باید بدانید آنها چه بوده اند.

مرحله 2: یک حسابرسی جامع انجام دهید

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

آیا هنوز رابطه ای با طراح/توسعه دهنده/آژانس قبلی وجود دارد؟

مشتریان به ندرت تصویر کاملی از پروژه خود دارند – آنها حرفه ای وب نیستند، اگر بودند، سایت های خود را می ساختند. بهترین منبع اطلاعات شما D/D/A قبلی است. قبل از اینکه با مشتری خود با چک قبلی D/D/A تماس بگیرید. ممکن است آنها هنوز ندانند که در حال تعویض هستند. اگر مشتری شما با آن خوب است، پس تماس بگیرید. وقتی با D/D/A قبلی صحبت می‌کنید، نسبت به این موضوع حساس باشید که پول را از جیب او در می‌آورید. مطمئناً D/D/A قبلی ممکن است به شما بگوید کجا بروید، ممکن است شما را به کلی نادیده بگیرند، اما اکثر آنها در مورد واگذاری یک پروژه عملگرا خواهند بود، اگر فقط اطمینان حاصل کنند که فاکتور نهایی آنها به مشتری فعلی سابقشان به سرعت پرداخت می شود. هر سایتی ویژگی های خاص خود را دارد، اگر بتوانید یک رابطه دوستانه با D/D/A قبلی برقرار کنید، این انتقال به میزان قابل توجهی دست انداز کمتری خواهد داشت.

چه کسی نام(های) دامنه را کنترل می کند؟

به نظر من نام(های) دامنه یک شرکت باید همیشه در اختیار شرکت باشد. این یک دارایی تجاری ضروری است که باید مانند حساب های بانکی شرکت با حسادت از آن محافظت کرد. متأسفانه کسب‌وکارهایی وجود دارند که همه کارهای مربوط به وب را برون سپاری می‌کنند. اگر شکست با D/D/A قبلی سخت باشد، ایمن کردن نام دامنه می تواند مشکل ساز باشد. وظیفه شما ایمن سازی نام دامنه نیست – شما هیچ اهرمی ندارید، مشتری این کار را دارد. وظیفه شما این است که روی مشتری تاثیرگذاری کنید که نام(های) دامنه چقدر مهم است.

چه کسی میزبانی را کنترل می کند؟

ترتیبات میزبانی از پروژه ای به پروژه دیگر متفاوت است. این غیر معمول و غیر منطقی نیست که D/D/A قبلی میزبان سایت مشتری باشد. روی فضای خودشان اگر چنین است، آماده باشید که آن را به سرعت به سرور خود یا یک فضای اختصاصی منتقل کنید. اگر در حال مهاجرت به فضای جدیدی هستید، توجه ویژه ای به ارائه ایمیل داشته باشید. تصاحب یک پروژه معمولاً به معنای در اختیار گرفتن یک پروژه زنده است و این معمولاً به معنای حساب های ایمیل است. در هر صورت شما نیاز به دسترسی کامل به فضای هاست دارید. شما مطمئناً به دسترسی FTP نیاز دارید، احتمالاً به دسترسی SSH نیاز دارید. علاوه بر میزبانی، بررسی کنید که آیا سایت مشتری شما از CDN استفاده می کند یا خیر، و اگر از آن استفاده می کند، چه کسی کنترل آن را در اختیار دارد.

کد منبع Backend

پس از دسترسی FTP به سرور میزبان، احتمالاً می توانید تمام کدهای پشتیبان را از سرور بگیرید. مزیت گرفتن کد از سرور – برخلاف پذیرش فایل‌ها از D/D/A قبلی – این است که می‌توانید کاملاً مطمئن باشید که کد فعلی (در حال کار) را دریافت می‌کنید. اگر مشتری با D/D/A قبلی شکست خورده باشد زیرا قادر به تحویل نبوده است روی یک کار خاص، شما نمی خواهید با فایل هایی که تا حدی اصلاح شده اند کار کنید.

نصب های تازه

اگر با چیزی مانند CMS کار می کنید، اغلب ایده خوبی است که یک نصب جدید را اجرا کنید روی سرور خود را، و سپس در هر قالب، پلاگین کپی کنید و پایگاه داده را انتقال دهید.

کد منبع Frontend

وقتی نوبت به دستیابی کد منبع می رسد، کد فرانت اند بسیار مشکل سازتر از باطن است. (pullquote)کد frontend بسیار مشکل سازتر از backend(/pullquote) است اگر D/D/A قبلی حتی تا حدی توانمند باشد، CSS و JavaScript روی فضای وب کوچک شده است. Minified CSS خیلی مشکل ساز نیست و می توان آن را به راحتی unminified کرد، اما شما نمی خواهید یک فایل جاوا اسکریپت کوچک شده را بردارید – من زمانی پروژه ای داشتم که در آن یک توسعه دهنده کد خودش را در همان فایل با تمام وابستگی هایش کوچک کرده بود. از جمله Vue و jQuery (بله، I دانستن). برخورد با کد منبع ظاهری ممکن است طول بکشد روی اگر متوجه شدید که D/D/A قبلی از تکنیک‌هایی استفاده می‌کرد که شما از آن استفاده نمی‌کردید، یک بعد اضافی است – استفاده از Less به جای Sass یا نوشتن اسکریپت در TypeScript.

حذف CSS و جاوا اسکریپت

حذف کردن (یا زیباسازی، یا زیبا) کد نسبتاً آسان است. ابزارهای آنلاینی وجود دارد که به شما کمک می کند، از جمله لغو کوچک کردن، CSS Unminifier آنلاین، FreeFormatter، JS Minify Unminify، و بیشتر. همچنین افزونه های زیادی برای ویرایشگرهای کد از جمله HTML-CSS-JS Prettify برای متن عالی، و Atom-Beautify برای اتم متوجه خواهید شد که برخی از ویرایشگرها دارای عملکرد داخلی هستند. یک کلمه هشدار: زیباسازی کد نظرات را بازیابی نمی کند، و در مورد جاوا اسکریپت، نام متغیرها را از بین نمی برد. کد زیباسازی جایگزین یک کپی از کد منبع اصلی و کوچک نشده نیست.

اقدامات اضطراری

اگر حذف کد منبع به هر دلیلی امکان‌پذیر نباشد، یا به احتمال زیاد، جاوا اسکریپت غیرمینی شده همچنان شبیه کد کوچک‌سازی شده به نظر می‌رسد – البته کد کوچک‌سازی شده با فرمت‌های زیبا – پس آخرین راه حل شما این است که import کد و در صورت لزوم آن را لغو کنید. اولین کاری که باید در این مورد انجام دهید این است که وضعیت را برای مشتری خود توضیح دهید. اطمینان حاصل کنید که آنها متوجه می شوند که این یک وصله موقت است که هنگام بازسازی بخش هایی از پروژه، آن را برطرف خواهید کرد. سپس، کد کوچک‌سازی شده قدیمی را کپی و در یک راه‌اندازی پروژه جدید جای‌گذاری کنید. برای CSS احتمالاً به معنای ایجاد یک است legacy.scss فایل، از جمله CSS قدیمی، و وارد کردن آن به Sass خودتان. برای جاوا اسکریپت، a ایجاد کنید legacy.js فایل، تمام JS های قدیمی را اضافه کنید و import که این منجر به مجموعه ای بسیار بزرگتر از فایل ها می شود که ممکن است در نهایت از آنها استفاده کنید !مهم در اعلان‌های سبک خود (یوک)، و بسیاری از اخطارهای Lighthouse را در مورد کد اضافی ایجاد خواهید کرد. با این حال، در صورت احتمالی که مشتری شما لیستی طولانی از تغییراتی را که دیروز می‌خواستند داشته باشد، این هک کثیف به شما یک سایت کار می‌دهد که می‌توانید آن را تکه تکه در طول زمان بازسازی کنید.

دارایی های

دارایی ها معمولاً به معنای تصاویر هستند و معمولاً می توان تصاویر را از طریق FTP گرفت. گاهی اوقات – اگرچه در حال حاضر کمتر گاهی اوقات فایل های تصویری به ندرت حاوی متن هستند – برای ایجاد تغییرات در تصاویر به فایل های منبع نیاز دارید. اینکه آیا مشتری آنها را دارد یا نه، یا اینکه D/D/A قبلی آنها را تحویل خواهد داد، تا حد زیادی بستگی دارد روی توافق بین مشتری و D/D/A قبلی. اکثر کسب و کارها به طور منطقی از اهمیت دارایی های برند آگاه هستند، بنابراین احتمالاً خواهید دید که حداقل یک کپی از لوگوی خود دارند. اینکه SVG باشد یا JPG موضوع دیگری است. بر اهمیت مکان یابی آن فایل ها برای شما تأثیر بگذارید.

کد شخص ثالث

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

مراقب محیط های ساخت و ساز باشید

هر کس روش خودش را برای انجام کارها دارد. برخی از D/D/A از محیط های ساخت استقبال می کنند، برخی نه. استفاده از برخی از محیط های ساخت ساده است، برخی نه. برخی از محیط های ساخت با شما سازگار هستند process، برخی نیستند. (pullquote) بر خلاف پذیرش یک کتابخانه یا حتی یک فریم ورک، اتخاذ یک ساخت جدید process به ندرت ایده خوبی است. تقریبا همانطور که در مورد CMS نظر دارند. به جای فایل‌های خام، غیرمعمول نیست که D/D/A قبلی به شما می‌گوید که دستور «فقط چنین و چنان CLI را اجرا کنید» تا محیط محلی خود را با محیط آن‌ها تطبیق دهید. بر خلاف پذیرش یک کتابخانه یا حتی یک چارچوب، اتخاذ یک ساخت جدید process به ندرت ایده خوبی است زیرا در زمانی که هنوز اعتماد مشتری جدید خود را جلب نکرده اید، خود را از متخصص به مبتدی تنزل می دهید. روی پای خود بایستید رویکرد آنها شکست خورد، به همین دلیل است که شما را آورده اند.

چه کسی مجوز دارد؟

هر کد قسمت سومی که پول پرداخت شده باشد دارای مجوز است. همیشه بررسی کنید که چه کسانی این مجوزها را دارند. علاوه بر الزام قانونی، مجوزهای معتبر معمولاً برای به روز رسانی، رفع اشکال و در برخی موارد پشتیبانی مورد نیاز هستند. مشکلات رایج عبارتند از: مجوزهای فونت (که ممکن است تحت اکانت Creative Cloud، Fontstand، Monotype و غیره D/D/A قبلی مجوز داشته باشند). مجوزهای تصویر استوک (که ممکن است به تنهایی برای استفاده توسط D/D/A قبلی مجوز داشته باشد). و پلاگین ها (که اغلب به صورت انبوه به D/D/As در بسته ها مجوز داده می شوند). یافتن مشتریانی که از دارایی های بدون مجوز استفاده می کنند بسیار متداول است. در بیش از یک بار مجبور شده ام عواقب بالقوه استفاده از فونت های غیرقانونی را برای مشتری توضیح دهم. خوشبختانه به طور فزاینده ای برای ارائه دهندگان شخص ثالث متداول است که یک مجوز را به یک دامنه مشخص متصل کنند، به این معنی که ممکن است بتوانید مجوز را درخواست کنید. روی از طرف مشتری شما تامین‌کنندگان اصلی مانند CMS و راه‌حل‌های تجارت الکترونیک اغلب گزینه‌ای برای توسعه‌دهنده قبلی برای انتشار مجوز دارند و به شما اجازه می‌دهند آن را ادعا کنید. در مورد صدور مجوز، اگر مطمئن نیستید، نترسید که با ارائه دهنده شخص ثالث تماس بگیرید و پس از قطع رابطه با D/D/A قبلی خود، با آنها بررسی کنید که آیا مشتری شما مجوز دارد یا خیر. تنها چیزی که سریعتر از اینکه به آنها بگوییم باید مجوزی را بخرند که فکر می کردند قبلاً برای آن پول پرداخت کرده اند، رابطه مشتری را تیره می کند، این است که به آنها بگوییم که به دلیل نقض حق چاپ از آنها شکایت می کنند. با اطمینان از اینکه همه چیز به درستی مجوز دارد، از مشتری خود محافظت کنید و از خود محافظت کنید. اگر می توانید چیزی را به صورت مکتوب از D/D/A قبلی دریافت کنید، انجام دهید.

چه کسی تحقیق و تجزیه و تحلیل دارد؟

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

ما هم وبلاگ داریم…

مشتریان تمایل دارند از اصطلاح «وب‌سایت» به عنوان یک اصطلاح فراگیر برای همه چیز دیجیتال استفاده کنند. وقتی مسئولیت یک وب سایت را بر عهده می گیرید، تقریباً همیشه از شما انتظار می رود که مسئولیت هر سرویس دیجیتالی را که مشتری از آن استفاده می کند، بپذیرید. این بدان معناست که خدمات خبرنامه مانند Mailchimp، حساب های خدمات مشتری مانند Intercom و 227000 page وبلاگ های وردپرسی که فراموش کردند در خلاصه اولیه به آنها اشاره کنند. کل را تکرار کنید گام 2 برای هر برنامه اضافی، میکرو سایت، وبلاگ و هر چیز دیگری که مشتری دارد، مگر اینکه مشتری صریحاً به شما گفته باشد که این کار را نکنید.

مرحله 3: نقطه بدون بازگشت

تا به حال، شما از مشتری نخواسته اید که امضا کند روی خط نقطه چین این کل process بخشی از تلاش شماست با بررسی این موارد می توانید مشکلات پیش بینی نشده و هزینه های احتمالی را شناسایی کنید. آیا به یک ساختمان مبهم گره خورده اید؟ process? آیا نیاز به مجوز مجدد CMS دارید؟ آیا نیاز به ایجاد مجدد همه دارایی های سایت دارید؟ (pullquote) انجام برخی از این مکالمات سخت است، اما زمان انجام آنها اکنون است (/pullquote) اگر سوالی در مورد پیچیده‌تر بودن پروژه از آنچه پیش‌بینی شده است وجود دارد، با مشتری خود گفتگوی صادقانه داشته باشید – آنها از شما قدردانی خواهند کرد. شفافیت، و آن‌ها از اطلاع‌رسانی قدردانی خواهند کرد. هر مشتری که برای تصویر واضحی از آنچه به شما پول می دهد ارزش قائل نیست، مشتری مورد نظر شما نیست. انجام برخی از این گفتگوها سخت است، اما زمان انجام آنها اکنون است، نه سه ماه دیگر. این نقطه بی بازگشت است. از این نقطه روی، هر مشکلی مربوط به D/D/A قبلی نیست، آنها مال شما هستند.

رمزهای عبور را تغییر دهید

برای هر سرویسی که دارید، از ورود به خبرنامه، ورود به سیستم مدیریت محتوا، تا جزئیات FTP، رمز عبور را تغییر دهید. (حتما به مشتری اطلاع دهید.)

یک سایت استیجینگ راه اندازی کنید

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

انتقال موفقیت آمیز یک پروژه

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

تصویر شاخص از طریق Unsplash.