സ്ഥാപകർ തെറ്റായി എടുക്കാറുള്ള 11 ആപ്പ് വികസന തീരുമാനങ്ങൾ
ഒരു ആപ്പ് നിർമ്മിക്കുക എന്നത് പ്രയാസകരമായ കാര്യമാണ്. തുടക്കത്തിലെ തീരുമാനങ്ങൾ കാരണം മിക്ക സ്ഥാപകരും പരാജയപ്പെടുന്നു. ഈ തിരഞ്ഞെടുപ്പുകൾ ദീർഘകാല പ്രശ്നങ്ങൾക്ക് കാരണമാകുന്നു.
സാധാരണയായി സംഭവിക്കാറുള്ള 11 തെറ്റുകളും അവ എങ്ങനെ പരിഹരിക്കാമെന്നും താഴെ നൽകുന്നു:
നിങ്ങളുടെ ആദ്യ പതിപ്പിനെ അന്തിമ ഉൽപ്പന്നമായി കാണരുത്. എല്ലാ ഫീച്ചറുകളും ഉടൻ തന്നെ നിർമ്മിക്കുന്നത് നിർത്തുക. നിങ്ങളുടെ പ്രധാന ആശയം പരീക്ഷിക്കുന്നതിനുള്ള ഏറ്റവും ചെറിയ പതിപ്പ് നിർമ്മിക്കുക. ഒരു MVP എന്നത് ലക്ഷ്യബോധമുള്ള ഒരു പരീക്ഷണമാണ്. അത് ഒരു പ്രശ്നം കൃത്യമായി പരിഹരിക്കണം.
ട്രെൻഡിന് അനുസരിച്ച് ടെക് സ്റ്റാക്കുകൾ (tech stacks) തിരഞ്ഞെടുക്കരുത്. ട്രെൻഡിംഗിൽ ഉള്ളതുകൊണ്ട് മാത്രം സങ്കീർണ്ണമായ ടൂളുകൾ ഉപയോഗിക്കരുത്. താഴെ പറയുന്ന കാര്യങ്ങൾ അടിസ്ഥാനമാക്കി ടൂളുകൾ തിരഞ്ഞെടുക്കുക: • ടീമിന് പരിചയമുള്ളവ • വേഗത്തിലുള്ള വിതരണം • എളുപ്പത്തിലുള്ള പരിപാലനം (maintenance)
ഭാവിയിലെ വളർച്ചയെ അവഗണിക്കരുത്. 10,000 ഉപയോക്താക്കളിൽ വെച്ച് തകരാറിലാകുന്ന ഒരു സിസ്റ്റം നിർമ്മിക്കരുത്. നിങ്ങൾക്ക് ശക്തമായ ഒരു ഡാറ്റാബേസും മോഡുലാർ ആർക്കിടെക്ചറും ആവശ്യമാണ്. മുഴുവനായി മാറ്റം വരുത്താതെ തന്നെ കോഡ് അപ്ഡേറ്റ് ചെയ്യാൻ നിങ്ങൾക്ക് കഴിയണം.
ഉപയോക്താക്കൾക്ക് പകരം നിങ്ങൾക്കായി മാത്രം ഡിസൈൻ ചെയ്യരുത്. നിങ്ങളുടെ ആന്തരിക ലോജിക്കുകളെക്കുറിച്ച് (internal logic) ഉപയോക്താക്കൾക്ക് താൽപ്പര്യമില്ല. അവർക്ക് വേണ്ടത് വ്യക്തതയാണ്. ഓരോ സ്ക്രീനും ഒരു ചോദ്യത്തിന് ഉത്തരം നൽകണം. അതിന് സാധിക്കുന്നില്ലെങ്കിൽ, അത് ലളിതമാക്കുക.
ഓൺബോർഡിംഗിനെ (onboarding) മറന്നുപോകരുത്. ആശയക്കുഴപ്പമുണ്ടാക്കുന്ന ഒരു തുടക്കം നിങ്ങളുടെ ആപ്പിനെ നശിപ്പിക്കും. ഓൺബോർഡിംഗ് എന്നത് ഫീച്ചറുകളെ പരിചയപ്പെടുത്തൽ മാത്രമല്ല. അത് ഉപയോക്താവിന് മൂല്യം ലഭിക്കുന്ന ആദ്യ നിമിഷത്തിലേക്കുള്ള പാതയാണ്.
ഫീച്ചറുകളുടെ അമിതമായ വർദ്ധനവ് (feature creep) അനുവദിക്കരുത്. ചെറിയ ഫീച്ചറുകൾ ചേർക്കുന്നത് ലോഞ്ച് വൈകാൻ കാരണമാകും. ഇത് ചിലവ് വർദ്ധിപ്പിക്കുന്നു. മികച്ച ഉൽപ്പന്നങ്ങൾ കുറച്ച് കാര്യങ്ങൾ മികച്ച രീതിയിൽ ചെയ്യുന്നു.
ലളിതമായ ഫീച്ചറുകളെ നിസ്സാരമായി കാണരുത്. ചെറിയ ഫീച്ചറുകൾക്ക് പിന്നിൽ ഒളിഞ്ഞിരിക്കുന്ന ജോലികളുണ്ട്. ഓതന്റിക്കേഷനും (authentication) ബാക്കെൻഡ് ലോജിക്കും സമയം എടുക്കും. സമയപരിധി തെറ്റാതിരിക്കാൻ ടെസ്റ്റിംഗിനും എഡ്ജ് കേസുകൾക്കും (edge cases) ആവശ്യമായ സമയം കണക്കാക്കുക.
ഗുണദോഷങ്ങൾ (trade-offs) മനസ്സിലാക്കാതെ തീരുമാനങ്ങൾ എടുക്കരുത്. ഓരോ തീരുമാനത്തിനും ഒരു വിലയുണ്ട്. ഒരു കാര്യത്തിൽ ഉറച്ചുതീരുമാനിക്കുന്നതിന് മുമ്പ് അതിന്റെ ഗുണങ്ങളും ദോഷങ്ങളും മനസ്സിലാക്കുക.
ലോഞ്ചിന് ശേഷം കേൾക്കുന്നത് നിർത്തരുത്. ലോഞ്ച് എന്നത് പഠനത്തിന്റെ തുടക്കം മാത്രമാണ്. ഫീഡ്ബാക്ക് ലഭിക്കാൻ അനലിറ്റിക്സും (analytics) ഇന്റർവ്യൂകളും ഉപയോഗിക്കുക. നിങ്ങളുടെ അടുത്ത നീക്കം ഊഹിച്ചു തീരുമാനിക്കരുത്.
ഉപയോക്താക്കളെ ആകർഷിക്കുന്നതിൽ (acquisition) മാത്രം ശ്രദ്ധ കേന്ദ്രീകരിക്കരുത്. ഉപയോക്താക്കളെ കണ്ടെത്തുന്നത് എളുപ്പമാണ്, എന്നാൽ അവരെ നിലനിർത്തുന്നത് പ്രയാസമാണ്. സ്വയം ചോദിക്കുക: • അവർ എന്തിനാണ് വീണ്ടും വരുന്നത്? • നമ്മൾ ഏത് ശീലമാണ് വളർത്തിയെടുക്കുന്നത്? • ആവർത്തിച്ചു ലഭിക്കുന്ന മൂല്യം എന്താണ്?
എന്തൊക്കെ നിർമ്മിക്കരുത് എന്ന് തീരുമാനിക്കാൻ കഴിയാതെ വരുന്നത്. മുൻഗണനകൾ നിശ്ചയിക്കുന്നതിലൂടെയാണ് വിജയം ഉണ്ടാകുന്നത്. മിക്ക സ്ഥാപകരും പരാജയപ്പെടുന്നത് അവർ അമിതമായി നിർമ്മിക്കാൻ ശ്രമിക്കുന്നത് കൊണ്ടാണ്.
വ്യക്തതയോടെ നിർമ്മിക്കുക. ലാളിത്യത്തിന് മുൻഗണന നൽകുക.
Source: https://dev.to/deepikarajawat/11-app-development-decisions-founders-often-get-wrong-2014