നോയിഡയിലെ ഏതൊരു ടെക് ഹബ്ബിലും ചെന്നാൽ, എൻഡ്-ടു-എൻഡ് വെബ് സൊല്യൂഷനുകൾ വാഗ്ദാനം ചെയ്യുന്ന ഡസൻ കണക്കിന് ഏജൻസികളെ നിങ്ങൾക്ക് കാണാം. അവരുടെ പിച്ച് ഡെക്കുകൾ ആകർഷകമായിരിക്കും. അവരുടെ സെയിൽസ് ടീമുകൾ ആത്മവിശ്വാസം പ്രകടിപ്പിക്കും. എന്നാൽ അതിന്റെ ആഴത്തിലേക്ക് നോക്കിയാൽ പരിചിതമായ ഒരു പാറ്റേൺ കാണാം. ആകർഷകമായ ഇന്റർഫേസുകൾ കൊണ്ട് നിങ്ങളെ അത്ഭുതപ്പെടുത്തിയ പോർട്ട്ഫോളിയോയ്ക്ക് പിന്നിൽ, ഒരു ഡാറ്റാബേസ് ക്വറി പോലും എഴുതാൻ ബുദ്ധിമുട്ടുന്ന ഒരു ടീം ഒളിച്ചിരിക്കാം. അല്ലെങ്കിൽ Laravel, Node.js എന്നിവയെക്കുറിച്ച് അഹങ്കരിക്കുന്ന ഒരു സ്ഥാപനം, 2003-ലെ ഒരു സ്പ്രെഡ്ഷീറ്റ് പോലെ തോന്നിക്കുന്ന ഒരു യൂസർ എക്സ്പീരിയൻസ് നൽകിയേക്കാം. കരാർ ഒപ്പിട്ട്, ഡെപ്പോസിറ്റ് നൽകി, പ്രോജക്റ്റ് പാളം തെറ്റി തുടങ്ങിക്കഴിഞ്ഞാൽ മാത്രമേ ഉപഭോക്താക്കൾക്ക് ഈ വ്യത്യാസം തിരിച്ചറിയാൻ കഴിയൂ. അപ്പോഴേക്കും നാശനഷ്ടങ്ങൾ സംഭവിച്ചു കഴിഞ്ഞിരിക്കും.
നിങ്ങൾക്ക് ഈ കുഴപ്പങ്ങൾ ഒഴിവാക്കാം. വെബ് ഡിസൈനും വെബ് ഡെവലപ്മെന്റും ഒരേ മേഖലയല്ല എന്ന് മനസ്സിലാക്കുന്നതിലൂടെ ഇത് തുടങ്ങാം. ഇവ രണ്ടും തമ്മിൽ തെറ്റിദ്ധരിക്കുന്ന ഒരാളെ നിയമിക്കുന്നത് ബജറ്റ് പാഴാക്കാനുള്ള എളുപ്പവഴിയാണ്.
പിക്സലുകളും പ്രൊഡക്ഷനും തമ്മിലുള്ള വ്യത്യാസം
വെബ് ഡിസൈൻ എന്നത് ഒരു സൈറ്റ് എങ്ങനെ കാണപ്പെടുന്നു, എങ്ങനെ അനുഭവപ്പെടുന്നു എന്നതിനെക്കുറിച്ചാണ്. ഒരു ഡിസൈനർ ഹൈരാർക്കി (hierarchy), വൈറ്റ് സ്പേസ് (white space), കളർ സൈക്കോളജി, കൂടാതെ ഒരു ലാൻഡിംഗ് പേജിൽ നിന്ന് ചെക്ക്ഔട്ട് അല്ലെങ്കിൽ കോൺടാക്റ്റ് ഫോമിലേക്കുള്ള ഉപയോക്താവിന്റെ പാത എന്നിവയെക്കുറിച്ച് ചിന്തിക്കുന്നു. അവർ Figma അല്ലെങ്കിൽ Adobe XD പോലുള്ള ടൂളുകളാണ് ഉപയോഗിക്കുന്നത്. അവർ നൽകുന്ന ഫൈനൽ ഡെലിവറബിൾ എന്നത് സ്റ്റാറ്റിക് സ്ക്രീനുകളുടെ ഒരു കൂട്ടമോ അല്ലെങ്കിൽ ക്ലിക്ക് ചെയ്യാവുന്ന ഒരു പ്രോട്ടോടൈപ്പോ ആണ്. അത് നിങ്ങളുടെ കാഴ്ചപ്പാട് കാണിച്ചുതരുന്നു. എന്നാൽ അത് ഫോം ഡാറ്റ ശേഖരിക്കുകയോ, പേയ്മെന്റ് പ്രോസസ്സ് ചെയ്യുകയോ, ആയിരക്കണക്കിന് സന്ദർശകർക്ക് പേജുകൾ കാണിച്ചു കൊടുക്കുകയോ ചെയ്യില്ല. അത് ഒരു ബ്ലൂപ്രിന്റ് മാത്രമാണ്, ഒരു കെട്ടിടമല്ല.
വെബ് ഡെവലപ്മെന്റ് എന്നത് എൻജിനീയറിംഗ് ഘട്ടമാണ്. ഒരു ഡെവലപ്പർ ആ ബ്ലൂപ്രിന്റുകൾ എടുത്ത് ബ്രൗസറിൽ കാണാൻ കഴിയുന്ന HTML, CSS, JavaScript എന്നിവ എഴുതുന്നു. പ്രോജക്റ്റിന് ആവശ്യമാണെങ്കിൽ, അവർ ബാക്കെൻഡ് ലോജിക് നിർമ്മിക്കുകയും, സെർവർ കോൺഫിഗർ ചെയ്യുകയും, ഡാറ്റാബേസ് സ്കീമ ഡിസൈൻ ചെയ്യുകയും, പേയ്മെന്റ് ഗേറ്റ്വേകൾ, ഷിപ്പിംഗ് API-കൾ അല്ലെങ്കിൽ ഓതന്റിക്കേഷൻ പ്രൊവൈഡറുകൾ പോലുള്ള തേർഡ് പാർട്ടി സർവീസുകൾ സംയോജിപ്പിക്കുകയും ചെയ്യുന്നു. ഇതിന്റെ ഫലം യഥാർത്ഥത്തിൽ പ്രവർത്തിക്കുന്ന ഒരു ലൈവ് URL ആണ്.
ഈ രണ്ട് ലോകങ്ങളും സംസാരിക്കുന്നത് വ്യത്യസ്ത ഭാഷകളാണ്. ഒരു ബട്ടൺ കാണാൻ ആകർഷകമാണോ എന്ന് ഒരു ഡിസൈനർ ആശങ്കപ്പെടുന്നു. എന്നാൽ അതേ ബട്ടൺ നെറ്റ്വർക്ക് ലേറ്റൻസി (network latency) ഉള്ളപ്പോൾ ഒരു API കോൾ ശരിയായി പ്രവർത്തിക്കുന്നുണ്ടോ എന്ന് ഒരു ഡെവലപ്പർ ആശങ്കപ്പെടുന്നു. രണ്ട് കാര്യങ്ങളും പ്രധാനമാണ്. എന്നാൽ ഒരു ഭാഷ മാത്രം സംസാരിക്കുന്ന ഒരു ഏജൻസി മറ്റേ പകുതിയും അപൂർണ്ണമായി വിടും.
"ഫുൾ സർവീസ്" എന്ന മിഥ്യാധാരണ
നോയിഡയിലെ ഏജൻസി വിപണി തിങ്ങിനിറഞ്ഞതാണ്. മത്സരം കഠിനമാണ്. അതിനാൽ ഡിസൈൻ മുതൽ ഡിപ്ലോയ്മെന്റ് വരെ എല്ലാം തങ്ങൾ ചെയ്യുന്നു എന്ന് സ്ഥാപനങ്ങൾ സ്വാഭാവികമായും അവകാശപ്പെടുന്നു. എന്നാൽ യാഥാർത്ഥ്യം പലപ്പോഴും ഒരു വശത്തേക്ക് മാത്രം ചായുന്നു. ഒരു സ്ഥാപനത്തിന് മൂന്ന് കഴിവുള്ള വിഷ്വൽ ഡിസൈനർമാരും പാർട്ട് ടൈം കോഡിംഗ് ചെയ്യുന്ന ഒരു ജൂനിയർ ഡെവലപ്പറും ഉണ്ടാകാം. അല്ലെങ്കിൽ തിരിച്ചും: ടൈപ്പോഗ്രാഫിയെ (typography) ഒരു രണ്ടാം നിര കാര്യമായി കാണുന്ന മിടുക്കരായ എൻജിനീയർമാർ. ഈ രണ്ട് അസന്തുലിതാവസ്ഥയും ഉപഭോക്താവിന് ഗുണകരമല്ല.
ഇതിലെ അപകടം സൗന്ദര്യശാസ്ത്രപരമായത് മാത്രമല്ല. ഡിസൈനിന് പ്രാധാന്യം നൽകുന്ന ഒരു ടീം മനോഹരമായ മക്കപ്പുകൾ (mockups) നിർമ്മിച്ചേക്കാം, എന്നാൽ അവ റെസ്പോൺസീവ് ആയി നിർമ്മിക്കുന്നത് വലിയൊരു തലവേദനയാകാം. ഡെവലപ്മെന്റിന് പ്രാധാന്യം നൽകുന്ന ഒരു ടീം നിങ്ങളുടെ ഉൽപ്പന്നത്തിൽ ഒരു ജനറിക് അഡ്മിൻ ടെംപ്ലേറ്റ് വെച്ച് അതിനെ ബ്രാൻഡഡ് എന്ന് വിളിച്ചേക്കാം. സൈറ്റ് അംഗീകരിച്ച കൺസെപ്റ്റിന് സമാനമല്ലെന്ന് അല്ലെങ്കിൽ ആ കൺസെപ്റ്റ് പ്രായോഗികമല്ലെന്ന് നിങ്ങൾ തിരിച്ചറിയുന്ന യൂസർ അക്സെപ്റ്റൻസ് ടെസ്റ്റിംഗ് (user acceptance testing) സമയത്ത് മാത്രമേ ഈ വിടവ് വ്യക്തമാകൂ.
ആശയക്കുഴപ്പങ്ങൾ ഒഴിവാക്കാൻ ചോദിക്കേണ്ട മൂന്ന് ചോദ്യങ്ങൾ
നിങ്ങൾ എന്തെങ്കിലും ഒപ്പിടുന്നതിന് മുമ്പ്, ഒരു ഏജൻസിക്ക് രണ്ട് മേഖലകളിലും പ്രാവീണ്യമുണ്ടോ എന്ന് പരിശോധിക്കാൻ ഈ ചോദ്യങ്ങൾ ഉപയോഗിക്കുക.
നിങ്ങൾ ഡിസൈൻ ചെയ്തതും നിർമ്മിച്ചതുമായ മൂന്ന് സൈറ്റുകൾ കാണിച്ചുതരിക. അവർ ഒരു ഭാഗം മാത്രം ചെയ്ത ഉദാഹരണങ്ങൾ സ്വീകരിക്കരുത്. സാധിക്കുമെങ്കിൽ Figma ഫയലുകളും ലൈവ് Git റെപ്പോസിറ്ററിയും കാണിക്കാൻ ആവശ്യപ്പെടുക. ഡെവലപ്മെന്റ് നടക്കുമ്പോൾ ഒരു ഡിസൈൻ മാറ്റം വന്നാൽ അവർ അത് എങ്ങനെ കൈകാര്യം ചെയ്തു എന്ന് ചോദിക്കുക. അവർക്ക് മറുപടി നൽകാൻ പ്രയാസമാണെങ്കിൽ, അവർ പ്രോസസ്സിന്റെ ഒരു ഭാഗം ഔട്ട്സോഴ്സ് ചെയ്യുന്നുണ്ടാകാം അല്ലെങ്കിൽ അവരുടെ പങ്കിനെക്കുറിച്ച് അതിശയോക്തി പറയുകയാണോ എന്ന് സംശയിക്കാം.
ലോഞ്ചിന് ശേഷം CMS അഡ്മിൻ ആരുടെ ഉടമസ്ഥതയിലായിരിക്കും? ഇത് കേൾക്കുമ്പോൾ വളരെ ലളിതമായി തോന്നാം, എന്നാൽ സൈറ്റ് ലൈവ് ആകുന്നതിന്റെ ആവേശത്തിൽ ഇത് പലപ്പോഴും അവഗണിക്കപ്പെടുന്നു. ആദ്യ ദിവസം മുതൽ കണ്ടന്റ് മാനേജ്മെന്റ് സിസ്റ്റത്തിന്മേൽ (CMS) നിങ്ങൾക്ക് വ്യക്തമായ ക്രെഡൻഷ്യലുകളും ഡോക്യുമെന്റേഷനും നിയന്ത്രണവും ഉണ്ടായിരിക്കണം. ചില ഏജൻസികൾ അവരുടെ ഹോസ്റ്റിംഗിൽ നിങ്ങളെ തളച്ചിടുന്നതോ അല്ലെങ്കിൽ ഓരോ ചെറിയ മാറ്റത്തിനും പണം ഈടാക്കുന്നതോ ആയ പ്രൊപ്രൈറ്ററി സെറ്റപ്പുകൾ ഉപയോഗിക്കാറുണ്ട്. ഉടമസ്ഥാവകാശം നേരത്തെ തന്നെ ഉറപ്പാക്കുക.
എട്ട് മാസത്തിന് ശേഷം ഒരു പുതിയ പേജ് ടൈപ്പ് ചേർക്കാൻ എന്താണ് പ്രക്രിയ? സൈറ്റ് എത്രത്തോളം കൃത്യമായി ആർക്കിടെക്റ്റ് ചെയ്തിരിക്കുന്നു എന്ന് ഇത് വെളിപ്പെടുത്തുന്നു. ഒരു ദുർബലമായ കോഡ്ബേസ് ഉണ്ടെങ്കിൽ ഓരോ ചെറിയ മാറ്റത്തിനും ഡെവലപ്പറുടെ സഹായം ആവശ്യമായി വരും. എന്നാൽ നന്നായി നിർമ്മിച്ച ഒരു സൈറ്റ്, ഒരു ടിക്കറ്റ് ഓപ്പൺ ചെയ്യാതെ തന്നെ പുതിയ ലാൻഡിംഗ് പേജ് ലേഔട്ടുകൾ നിർമ്മിക്കാൻ നിങ്ങളുടെ മാർക്കറ്റിംഗ് ടീമിന് CMS വഴി സ്വാതന്ത്ര്യം നൽകുന്നു. ഈ ചോദ്യം കേട്ട് ഏജൻസി ആശയക്കുഴപ്പത്തിലാകുന്നുണ്ടെങ്കിൽ, അവരുടെ ഡെവലപ്മെന്റ് പ്രക്രിയ ലോഞ്ചിനൊപ്പം അവസാനിച്ചതാകാം, ദീർഘകാല പരിപാലനത്തിന് (maintainability) വേണ്ടിയല്ല അവർ ചെയ്തത്.
CMS ബ്ലൈൻഡ് സ്പോട്ട്
ലോഞ്ചിന് ശേഷം മിക്ക പ്രോജക്റ്റുകളും പരാജയപ്പെടുന്നത് ഇവിടെയാണ്.
ക്ലയന്റുകൾ ഹോംപേജിലെ ഹീറോ സെക്ഷനിൽ (hero section) മാത്രം ശ്രദ്ധ കേന്ദ്രീകരിക്കുകയും ദൈനംദിന പ്രവർത്തനങ്ങൾ (workflow) മറന്നുപോവുകയും ചെയ്യുന്നു. ലോഞ്ച് കഴിഞ്ഞ് ആറ് ആഴ്ചകൾക്ക് ശേഷം, നിങ്ങളുടെ സെയിൽസ് ടീമിന് വില പുതുക്കേണ്ടി വരുന്നു. നിങ്ങളുടെ കണ്ടന്റ് മാനേജർക്ക് ഒരു കേസ് സ്റ്റഡി പ്രസിദ്ധീകരിക്കണം. നിങ്ങളുടെ എച്ച്ആർ ഹെഡിന് മൂന്ന് പുതിയ ജോലി ഒഴിവുകൾ പോസ്റ്റ് ചെയ്യണം. ഇവയിൽ ഏതെങ്കിലും ഒന്ന് ചേർക്കാൻ ഒരു സപ്പോർട്ട് ടിക്കറ്റ് ഫയൽ ചെയ്യേണ്ടതും, ഒരു PHP ടെംപ്ലേറ്റ് എഡിറ്റ് ചെയ്യാൻ ഡെവലപ്പർക്കായി രണ്ട് പ്രവൃത്തിദിവസങ്ങൾ കാത്തിരിക്കേണ്ടതുമാണെങ്കിൽ, നിങ്ങളുടെ വെബ്സൈറ്റ് ഇതിനകം തന്നെ ഒരു തടസ്സമായി (bottleneck) മാറിക്കഴിഞ്ഞു.
അതുകൊണ്ടാണ് ഒരു CMS-first സ്ട്രാറ്റജി പ്രധാനമാകുന്നത്. കണ്ടന്റ് മാനേജ്മെന്റ് സിസ്റ്റം (CMS) ആദ്യത്തെ ഡിസ്കവറി കോൾ മുതൽ ചർച്ചകളുടെ ഭാഗമാകണം, അല്ലാതെ അവസാനം വെറുതെ കൂട്ടിച്ചേർക്കുന്ന ഒന്നാകരുത്. കോഡിംഗിൽ തൊടാതെ തന്നെ ടെക്സ്റ്റ് എഡിറ്റ് ചെയ്യാനും, ചിത്രങ്ങൾ മാറ്റാനും, പുതിയ പേജുകൾ പ്രസിദ്ധീകരിക്കാനും നിങ്ങളുടെ ടീമിന് കഴിയണം. ലോഞ്ചിന് ശേഷം കണ്ടന്റ് ആരാണ് മാനേജ് ചെയ്യുക എന്ന് ഏജൻസി നിങ്ങളോട് ചോദിച്ചില്ലെങ്കിൽ, അവർ നിങ്ങളുടെ പ്രവർത്തനപരമായ യാഥാർത്ഥ്യങ്ങളെക്കുറിച്ച് (operational reality) ചിന്തിച്ചിട്ടില്ല എന്നാണ് അർത്ഥം.
രണ്ട് ടീമുകൾ പൂജ്യമായി മാറുന്നപ്പോൾ
ചില ബിസിനസ്സുകൾ ഡിസൈൻ-ഡെവലപ്മെന്റ് വിഭജനത്തെ പരിഹരിക്കാൻ പ്രത്യേക വെണ്ടർമാരെ (vendors) നിയമിക്കാൻ ശ്രമിക്കുന്നു. ലുക്കിനും ഫീലിനും വേണ്ടി ഡൽഹിയിലെ ഒരു ഡിസൈൻ സ്റ്റുഡിയോയെ കൊണ്ടുവരുന്നു, തുടർന്ന് നിർമ്മാണത്തിനായി ഫയലുകൾ നോയിഡയിലെ ഒരു ഡെവലപ്മെന്റ് ഷോപ്പിന് കൈമാറുന്നു. പേപ്പറിൽ നോക്കിയാൽ എല്ലാവരും വിദഗ്ധരാണ്. എന്നാൽ പ്രായോഗികമായി നോക്കിയാൽ, ആശയവിനിമയ പിശകുകൾ വർദ്ധിക്കുന്നു.
സ്റ്റാറ്റിക് സ്ക്രീനുകൾ റെസ്പോൺസീവ് ബിഹേവിയർ (responsive behavior) വിശദീകരിക്കുന്നില്ല. ഒരു സെർച്ച് റിസൾട്ട് ലഭിക്കാത്തപ്പോൾ എന്ത് സംഭവിക്കണം എന്ന് മക്കപ്പുകൾ (mockups) വ്യക്തമാക്കുന്നില്ല. ഹോവർ സ്റ്റേറ്റുകൾ (hover states), ലോഡിംഗ് സ്കെലിറ്റനുകൾ (loading skeletons), എറർ മെസ്സേജിംഗ് (error messaging), അല്ലെങ്കിൽ എംപ്റ്റി സ്റ്റേറ്റുകൾ (empty states) എന്നിവയെക്കുറിച്ച് അവ വിവരിക്കുന്നില്ല. ഡെവലപ്പർക്ക് ഉദ്ദേശ്യം ഊഹിച്ചെടുക്കേണ്ടി വരുന്നു. പലപ്പോഴും അവർ തെറ്റായി ഊഹിക്കുന്നു. തുടർന്ന് ഡിസൈനർ സ്റ്റേജിംഗ് സൈറ്റ് (staging site) പരിശോധിച്ച് അത് തകരാറിലാണെന്ന് പ്രഖ്യാപിക്കുന്നു. ഡിസൈൻ അപൂർണ്ണമായിരുന്നു എന്ന് ഡെവലപ്പർ വാദിക്കുന്നു. രണ്ട് ടീമുകൾ സ്ലാക്ക് (Slack) വഴിയും ഇമെയിൽ വഴിയും തർക്കിച്ചു സമയം കളയുമ്പോൾ ക്ലയന്റ് ഈ പുനർനിർമ്മാണത്തിന് പണം നൽകേണ്ടി വരുന്നു.
ഇതിന്റെ നഷ്ടം സാമ്പത്തികമായി മാത്രമല്ല. അത് നിങ്ങളുടെ മുന്നേറ്റത്തെയാണ് (momentum) ബാധിക്കുന്നത്. പ്രൊഡക്റ്റ് ലോഞ്ചുകൾ വൈകുന്നു. മാർക്കറ്റിംഗ് കലണ്ടറുകൾ തടസ്സപ്പെടുന്നു. നിങ്ങളുടെ ടീമുകൾ ഒരിക്കലും ഉണ്ടാകാൻ പാടില്ലാത്ത വിടവുകൾ പരിഹരിക്കാൻ ശ്രമിക്കുമ്പോൾ എതിരാളികൾ വേഗത്തിൽ മുന്നേറുന്നു.
കൈമാറ്റത്തിന്റെ യഥാർത്ഥ വില
നിങ്ങൾ ഇതൊന്ന് വായിക്കുന്ന ഒരു ഫ്രീലാൻസർ ആണെങ്കിൽ, ഇതെല്ലാം വെറും സിദ്ധാന്തങ്ങളല്ല. നിങ്ങൾ ഒരുപക്ഷേ ഇതിന്റെ തകർച്ചകൾ ഏറ്റെടുക്കേണ്ടി വന്നിട്ടുണ്ടാകാം. ഒരു ക്ലയന്റിന്റെ Figma ഫയൽ തുറക്കുമ്പോൾ മൊബൈൽ ബ്രേക്ക്പോയിന്റുകൾ (mobile breakpoints) ഇല്ലാത്ത ഇരുപതോളം ആർട്ട്ബോർഡുകൾ കണ്ടിട്ടുണ്ടാകാം. മുൻപത്തെ ഡെവലപ്പർ ഡിസൈനറെ കണ്ടുമുട്ടിയിട്ടില്ലാത്തതിനാൽ ഓരോ കണ്ടന്റ് ഫീൽഡും ഹാർഡ്കോഡഡ് (hardcoded) ആയ ഒരു ബാക്കെൻഡ് നിങ്ങൾ കണ്ടിട്ടുണ്ടാകാം. രണ്ട് ദിവസത്തെ ജോലി എന്ന് നിങ്ങൾ കണക്കാക്കിയ കാര്യം മുഴുവൻ കണ്ടന്റ് ആർക്കിടെക്ചർ തന്നെ പുനർനിർമ്മിക്കേണ്ടി വരുന്ന ഒന്നാണെന്ന് നിങ്ങൾ തിരിച്ചറിഞ്ഞിട്ടുണ്ടാകാം.
ഈ വിടവുകൾ നികത്തുന്നത് ചെലവേറിയ കാര്യമാണ്, കാരണം അവ സാങ്കേതികമായ പ്രശ്നങ്ങൾ മാത്രമല്ല. അവ കോഡിൽ തറഞ്ഞുപോയ ആശയവിനിമയ പരാജയങ്ങളാണ്.
പാഠം
ഒരു വെബ്സൈറ്റ് എന്നത് വെറുമൊരു ലോഗോ അല്ല. അത് വിഷ്വലുകളിലൂടെയും ഇൻഫ്രാസ്ട്രക്ചറിലൂടെയും നിങ്ങളുടെ ബിസിനസ്സിനെ ഉപഭോക്താക്കളുമായി ബന്ധിപ്പിക്കുന്ന ഒരു സജീവ സംവിധാനമാണ്. ഏതെങ്കിലും ഏജൻസിയെ നിയമിക്കുന്നതിന് മുമ്പ്, ആ സമവാക്യത്തിന്റെ ഏത് ഭാഗമാണ് നിങ്ങൾ യഥാർത്ഥത്തിൽ വാങ്ങുന്നതെന്ന് മനസ്സിലാക്കുക. അവരുടെ പ്രക്രിയ പരിശോധിക്കുക, എൻഡ്-ടു-എൻഡ് ഉടമസ്ഥാവകാശത്തിന് (end-to-end ownership) തെളിവ് ആവശ്യപ്പെടുക, റിബൺ കട്ടിംഗ് കഴിഞ്ഞതിന് ശേഷം മാത്രം CMS-നെ അവഗണിക്കാൻ തയ്യാറാകരുത്. ലോഞ്ച് ദിവസം അതിജീവിക്കുന്ന പ്രോജക്റ്റ് എന്നത്, എട്ടു മാസത്തിന് ശേഷം ആർക്കും വിളിക്കാതെ തന്നെ ഒരു വില മാറ്റം വരുത്തേണ്ടി വരുന്ന ഒരു ചൊവ്വാഴ്ചയെ മുൻകൂട്ടി കാണുന്ന പ്രോജക്റ്റാണ്.