ನೋಯ್ಡಾದ ಯಾವುದೇ ಟೆಕ್ ಹಬ್ಗೆ ನೀವು ಕಾಲಿಟ್ಟರೆ, ಎಂಡ್-ಟು-ಎಂಡ್ ವೆಬ್ ಪರಿಹಾರಗಳನ್ನು ಭರವಸೆ ನೀಡುವ ಡಜನ್ಗಟ್ಟಲೆ ಏಜೆನ್ಸಿಗಳನ್ನು ನೀವು ಕಾಣಬಹುದು. ಅವುಗಳ ಪಿಚ್ ಡೆಕ್ಗಳು (pitch decks) ಆಕರ್ಷಕವಾಗಿ ಕಾಣಿಸಬಹುದು. ಅವುಗಳ ಸೇಲ್ಸ್ ತಂಡಗಳು ಆತ್ಮವಿಶ್ವಾಸದಿಂದ ಮಾತನಾಡಬಹುದು. ಆದರೆ ಮೇಲ್ನೋಟಕ್ಕೆ ಮಾತ್ರ ನೋಡಿದರೆ, ಪರಿಚಿತವಾದ ಒಂದು ಮಾದರಿ ಕಾಣಿಸಿಕೊಳ್ಳುತ್ತದೆ. ಅತ್ಯಾಧುನಿಕ ಇಂಟರ್ಫೇಸ್ಗಳೊಂದಿಗೆ ನಿಮ್ಮನ್ನು ಬೆರಗುಗೊಳಿಸಿದ ಪೋರ್ಟ್ಫೋಲಿಯೋ, ಕೇವಲ ಒಂದು ಡೇಟಾಬೇಸ್ ಕ್ವೆರಿಯನ್ನು (database query) ಬರೆಯಲು ಕಷ್ಟಪಡುವ ತಂಡವನ್ನು ಅಡಗಿಸಿರಬಹುದು. ಅಥವಾ Laravel ಮತ್ತು Node.js ಬಗ್ಗೆ ಹೆಮ್ಮೆಯಿಂದ ಹೇಳಿಕೊಳ್ಳುವ ಸಂಸ್ಥೆಯು, 2003ರ ಕಾಲದ ಸ್ಪ್ರೆಡ್ಶೀಟ್ನಂತೆ ಅನುಭವ ನೀಡುವ ಯೂಸರ್ ಎಕ್ಸ್ಪೀರಿಯನ್ಸ್ ಅನ್ನು ನೀಡಬಹುದು. ಸಾಮಾನ್ಯವಾಗಿ ಕರಾರು ಸಹಿ ಮಾಡಿದ ನಂತರ, ಠೇವಣಿ ಹಣ ಪಾವತಿಸಿದ ನಂತರ ಮತ್ತು ಪ್ರಾಜೆಕ್ಟ್ ಹಾದಿ ತಪ್ಪಿದ ನಂತರವೇ ಕ್ಲೈಂಟ್ಗಳಿಗೆ ಈ ವ್ಯತ್ಯಾಸ ತಿಳಿಯುತ್ತದೆ. ಅಷ್ಟರಲ್ಲಾಗಲೇ ಹಾನಿ ಆಗಿರುತ್ತದೆ.
ನೀವು ಈ ಗೊಂದಲವನ್ನು ತಪ್ಪಿಸಬಹುದು. ವೆಬ್ ಡಿಸೈನ್ ಮತ್ತು ವೆಬ್ ಡೆವಲಪ್ಮೆಂಟ್ ಎಂಬುದು ಒಂದೇ ವಿಷಯವಲ್ಲ ಎಂಬ ಅರಿವಿನೊಂದಿಗೆ ಇದು ಪ್ರಾರಂಭವಾಗುತ್ತದೆ. ಈ ಎರಡನ್ನೂ ಗೊಂದಲ ಮಾಡಿಕೊಳ್ಳುವವರನ್ನು ನೇಮಿಸಿಕೊಳ್ಳುವುದು ಬಜೆಟ್ ವ್ಯರ್ಥ ಮಾಡುವ ವೇಗದ ಹಾದಿಯಾಗಿದೆ.
ಪಿಕ್ಸೆಲ್ ಮತ್ತು ಪ್ರೊಡಕ್ಷನ್ ನಡುವಿನ ಅಂತರ
ವೆಬ್ ಡಿಸೈನ್ ಎನ್ನುವುದು ಒಂದು ಸೈಟ್ ಹೇಗೆ ಕಾಣುತ್ತದೆ ಮತ್ತು ಹೇಗೆ ಅನುಭವಿಸುತ್ತದೆ ಎಂಬುದಕ್ಕೆ ಸಂಬಂಧಿಸಿದೆ. ಒಬ್ಬ ಡಿಸೈನರ್ ಹೈರಾರ್ಕಿ (hierarchy), ವೈಟ್ ಸ್ಪೇಸ್ (white space), ಕಲರ್ ಸೈಕಾಲಜಿ (color psychology) ಮತ್ತು ಬಳಕೆದಾರರು ಲ್ಯಾಂಡಿಂಗ್ ಪೇಜ್ನಿಂದ ಚೆಕ್ಔಟ್ ಅಥವಾ ಕಾಂಟ್ಯಾಕ್ಟ್ ಫಾರ್ಮ್ಗೆ ಹೋಗುವ ಹಾದಿಯ ಬಗ್ಗೆ ಯೋಚಿಸುತ್ತಾರೆ. ಅವರು Figma ಅಥವಾ Adobe XD ನಂತಹ ಪರಿಕರಗಳಲ್ಲಿ ಕೆಲಸ ಮಾಡುತ್ತಾರೆ. ಅಂತಿಮವಾಗಿ ಸಿಗುವ ಫಲಿತಾಂಶವು ಸ್ಟ್ಯಾಟಿಕ್ ಸ್ಕ್ರೀನ್ಗಳ ಸೆಟ್ ಅಥವಾ ಕ್ಲಿಕ್ ಮಾಡಬಹುದಾದ ಪ್ರೊಟೊಟೈಪ್ (prototype) ಆಗಿರುತ್ತದೆ. ಇದು ನಿಮಗೆ ದೃಷ್ಟಿಕೋನವನ್ನು ತೋರಿಸುತ್ತದೆ. ಆದರೆ ಇದು ಫಾರ್ಮ್ ಡೇಟಾವನ್ನು ಸಂಗ್ರಹಿಸುವುದಿಲ್ಲ, ಪಾವತಿಯನ್ನು ಪ್ರಕ್ರಿಯೆಗೊಳಿಸುವುದಿಲ್ಲ ಅಥವಾ ಸಾವಿರಾರು ಏಕಕಾಲಿಕ ಸಂದರ್ಶಕರಿಗೆ ಪೇಜ್ಗಳನ್ನು ತೋರಿಸುವುದಿಲ್ಲ. ಇದು ಒಂದು ನೀಲನಕ್ಷೆ (blueprint) ಅಷ್ಟೆ, ಕಟ್ಟಡವಲ್ಲ.
ವೆಬ್ ಡೆವಲಪ್ಮೆಂಟ್ ಎನ್ನುವುದು ಎಂಜಿನಿಯರಿಂಗ್ ಹಂತವಾಗಿದೆ. ಒಬ್ಬ ಡೆವಲಪರ್ ಆ ನೀಲನಕ್ಷೆಗಳನ್ನು ತೆಗೆದುಕೊಳ್ಳುತ್ತಾರೆ ಮತ್ತು ಬ್ರೌಸರ್ನಲ್ಲಿ ಪ್ರದರ್ಶನವಾಗುವ HTML, CSS ಮತ್ತು JavaScript ಅನ್ನು ಬರೆಯುತ್ತಾರೆ. ಪ್ರಾಜೆಕ್ಟ್ಗೆ ಅಗತ್ಯವಿದ್ದರೆ, ಅವರು ಬ್ಯಾಕ್ಎಂಡ್ ಲಾಜಿಕ್ (backend logic) ಅನ್ನು ನಿರ್ಮಿಸುತ್ತಾರೆ, ಸರ್ವರ್ ಅನ್ನು ಕಾನ್ಫಿಗರ್ ಮಾಡುತ್ತಾರೆ, ಡೇಟಾಬೇಸ್ ಸ್ಕೀಮಾವನ್ನು ವಿನ್ಯಾಸಗೊಳಿಸುತ್ತಾರೆ ಮತ್ತು ಪೇಮೆಂಟ್ ಗೇಟ್ವೇಗಳು, ಶಿಪ್ಪಿಂಗ್ APIಗಳು ಅಥವಾ ಅಥೆಂಟಿಕೇಶನ್ ಪ್ರೊವೈಡರ್ಗಳಂತಹ ಥರ್ಡ್-ಪಾರ್ಟಿ ಸೇವೆಗಳನ್ನು ಸಂಯೋಜಿಸುತ್ತಾರೆ. ಇದರ ಫಲಿತಾಂಶವು ನಿಜವಾಗಿಯೂ ಕೆಲಸ ಮಾಡುವ ಲೈವ್ URL ಆಗಿರುತ್ತದೆ.
ಈ ಎರಡು ಪ್ರಪಂಚಗಳು ಬೇರೆ ಬೇರೆ ಭಾಷೆಗಳನ್ನು ಮಾತನಾಡುತ್ತವೆ. ಬಟನ್ ಬಳಸಲು ಸುಲಭವಾಗಿದೆಯೇ ಎಂದು ಡಿಸೈನರ್ ಚಿಂತಿಸುತ್ತಾರೆ. ಅದೇ ಬಟನ್ ನೆಟ್ವರ್ಕ್ ವಿಳಂಬದ (network latency) ಸಂದರ್ಭದಲ್ಲಿ API ಕಾಲ್ ಅನ್ನು ಸರಿಯಾಗಿ ಟ್ರಿಗ್ಗರ್ ಮಾಡುತ್ತದೆಯೇ ಎಂದು ಡೆವಲಪರ್ ಚಿಂತಿಸುತ್ತಾರೆ. ಎರಡೂ ಕಾಳಜಿಗಳು ಮುಖ್ಯವಾಗಿವೆ. ಆದರೆ ಕೇವಲ ಒಂದು ಭಾಷೆಯನ್ನು ಮಾತ್ರ ಮಾತನಾಡುವ ಏಜೆನ್ಸಿ ಇನ್ನರ್ಧ ಕೆಲಸವನ್ನು ಪೂರ್ಣಗೊಳಿಸದೆ ಬಿಡುತ್ತದೆ.
"ಫುಲ್ ಸರ್ವಿಸ್" ಎಂಬ ಭ್ರಮೆ
ನೋಯ್ಡಾದ ಏಜೆನ್ಸಿ ಮಾರುಕಟ್ಟೆಯು ಜನಸಂದಣಿಯಿಂದ ಕೂಡಿದೆ. ಸ್ಪರ್ಧೆಯು ತೀವ್ರವಾಗಿದೆ. ಆದ್ದರಿಂದ ಸಂಸ್ಥೆಗಳು ಸಹಜವಾಗಿಯೇ ವಿನ್ಯಾಸದಿಂದ ಅನ್ವಯಿಸುವವರೆಗೆ (design to deployment) ಎಲ್ಲವನ್ನೂ ತಾವು ಮಾಡುತ್ತೇವೆ ಎಂದು ಹೇಳಿಕೊಳ್ಳುತ್ತವೆ. ಆದರೆ ವಾಸ್ತವವು ಅಸಮತೋಲಿತವಾಗಿರುತ್ತದೆ. ಒಂದು ಸಂಸ್ಥೆಯು ಮೂವರು ಪ್ರತಿಭಾವಂತ ವಿನ್ಯಾಸಕರು ಮತ್ತು ಅರೆಕಾಲಿಕವಾಗಿ ಕೋಡಿಂಗ್ ಮಾಡುವ ಒಬ್ಬ ಜೂನಿಯರ್ ಡೆವಲಪರ್ ಅನ್ನು ಹೊಂದಿರಬಹುದು. ಅಥವಾ ಇದರ ವಿರುದ್ಧವಾಗಿ: ಟೈಪೋಗ್ರಫಿಯನ್ನು (typography) ಕಡೆಗಣಿಸುವ ಅದ್ಭುತ ಎಂಜಿನಿಯರ್ಗಳನ್ನು ಹೊಂದಿರಬಹುದು. ಈ ಎರಡೂ ಅಸಮತೋಲನಗಳು ಕ್ಲೈಂಟ್ಗೆ ಪ್ರಯೋಜನಕಾರಿಯಲ್ಲ.
ಅಪಾಯವು ಕೇವಲ ಸೌಂದರ್ಯಾತ್ಮಕವಾಗಿಲ್ಲ. ಡಿಸೈನ್-ಹೆವಿ (design-heavy) ತಂಡವು ಅದ್ಭುತವಾದ ಮಾಕಪ್ಗಳನ್ನು (mockups) ತಯಾರಿಸಬಹುದು, ಆದರೆ ಅವುಗಳನ್ನು ರೆಸ್ಪಾನ್ಸಿವ್ ಆಗಿ (responsively) ನಿರ್ಮಿಸುವುದು ಕಷ್ಟವಾಗಬಹುದು. ಡೆವಲಪ್ಮೆಂಟ್-ಹೆವಿ (development-heavy) ತಂಡವು ನಿಮ್ಮ ಉತ್ಪನ್ನಕ್ಕೆ ಕೇವಲ ಒಂದು ಸಾಮಾನ್ಯ ಅಡ್ಮಿನ್ ಟೆಂಪ್ಲೇಟ್ ಅನ್ನು ಅಂಟಿಸಿ ಅದನ್ನು ಬ್ರ್ಯಾಂಡೆಡ್ ಎಂದು ಕರೆಯಬಹುದು. ಬಳಕೆದಾರರ ಸ್ವೀಕೃತಿ ಪರೀಕ್ಷೆಯ (user acceptance testing) ಸಮಯದಲ್ಲಿ ಮಾತ್ರ ಈ ವ್ಯತ್ಯಾಸವು ಗೋಚರಿಸುತ್ತದೆ, ಅಂದರೆ ಸೈಟ್ ಅನುಮೋದಿತ ಪರಿಕಲ್ಪನೆಯಂತೆ ಕಾಣುತ್ತಿಲ್ಲ ಅಥವಾ ಆ ಪರಿಕಲ್ಪನೆಯು ಮೊದಲ부터 ಕಾರ್ಯಸಾಧ್ಯವಾಗಿರಲಿಲ್ಲ ಎಂಬುದು ನಿಮಗೆ ತಿಳಿಯುತ್ತದೆ.
ಗೊಂದಲವನ್ನು ನಿವಾರಿಸುವ ಮೂರು ಪ್ರಶ್ನೆಗಳು
ನೀವು ಯಾವುದನ್ನೂ ಸಹಿ ಮಾಡುವ ಮೊದಲು, ಒಂದು ಏಜೆನ್ಸಿ ನಿಜವಾಗಿಯೂ ಎರಡೂ ಕಲೆಗಳಲ್ಲಿ ಪರಿಣತಿ ಹೊಂದಿದೆಯೇ ಎಂದು ಪರೀಕ್ಷಿಸಲು ಈ ಪ್ರಶ್ನೆಗಳನ್ನು ಬಳಸಿ.
ನೀವು ವಿನ್ಯಾಸಗೊಳಿಸಿದ ಮತ್ತು ನಿರ್ಮಿಸಿದ ಮೂರು ಸೈಟ್ಗಳನ್ನು ನನಗೆ ತೋರಿಸಿ. ಅವರು ಕೇವಲ ಒಂದು ಭಾಗವನ್ನು ಮಾತ್ರ ನಿರ್ವಹಿಸಿದ ಉದಾಹರಣೆಗಳನ್ನು ಒಪ್ಪಬೇಡಿ. ಸಾಧ್ಯವಾದರೆ Figma ಫೈಲ್ಗಳು ಮತ್ತು ಲೈವ್ Git ರೆಪೊಸಿಟರಿಯನ್ನು ನೋಡಲು ಕೇಳಿ. ಅಭಿವೃದ್ಧಿಯ ಮಧ್ಯದಲ್ಲಿ ವಿನ್ಯಾಸದ ಬದಲಾವಣೆಯನ್ನು ಅವರು ಹೇಗೆ ನಿಭಾಯಿಸಿದರು ಎಂದು ಕೇಳಿ. ಅವರು ತಡಬಡಾಯಿಸಿದರೆ, ಅವರು ಬಹುಶಃ ಪ್ರಕ್ರಿಯೆಯ ಒಂದು ಭಾಗವನ್ನು ಹೊರಗಿನವರಿಗೆ ನೀಡುತ್ತಿದ್ದಾರೆ (outsourcing) ಅಥವಾ ತಮ್ಮ ಪಾತ್ರವನ್ನು ಅತಿಶಯೋಕ್ತಿಯಾಗಿ ಹೇಳುತ್ತಿದ್ದಾರೆ ಎಂದರ್ಥ.
ಲಾಂಚ್ ಮಾಡಿದ ನಂತರ CMS ಅಡ್ಮಿನ್ ಯಾರ ವಶದಲ್ಲಿರುತ್ತದೆ? ಇದು ಸ್ಪಷ್ಟವಾಗಿ ಕೇಳಿಸಿದರೂ, ಲೈವ್ ಹೋಗುವ ಉತ್ಸಾಹದಲ್ಲಿ ಇದನ್ನು ನಿರ್ಲಕ್ಷಿಸಲಾಗುತ್ತದೆ. ಮೊದಲ ದಿನದಿಂದಲೇ ನಿಮಗೆ ಸ್ಪಷ್ಟವಾದ ಕ್ರೆಡೆನ್ಶಿಯಲ್ಸ್ (credentials), ಡಾಕ್ಯುಮೆಂಟೇಶನ್ ಮತ್ತು ಕಂಟೆಂಟ್ ಮ್ಯಾನೇಜ್ಮೆಂಟ್ ಸಿಸ್ಟಮ್ ಮೇಲೆ ನಿಯಂತ್ರಣ ಇರಬೇಕು. ಕೆಲವು ಏಜೆನ್ಸಿಗಳು ತಮ್ಮ ಹೋಸ್ಟಿಂಗ್ನಲ್ಲಿ ನಿಮ್ಮನ್ನು ಕಟ್ಟಿಹಾಕುವ ಅಥವಾ ಪ್ರತಿ ಸಣ್ಣ ಬದಲಾವಣೆಗೂ ಹಣ ವಿಧಿಸುವ ಸ್ವಂತ ಸೆಟಪ್ಗಳನ್ನು ಬಳಸುತ್ತವೆ. ಮಾಲೀಕತ್ವವನ್ನು ಮೊದಲೇ ಸ್ಥಾಪಿಸಿ.
ಎಂಟು ತಿಂಗಳ ನಂತರ ಹೊಸ ಪೇಜ್ ಟೈಪ್ ಅನ್ನು ಸೇರಿಸುವ ಪ್ರಕ್ರಿಯೆ ಏನು? ಇದು ಸೈಟ್ ಅನ್ನು ಎಷ್ಟು ಯೋಚನಾಪೂರ್ವಕವಾಗಿ ವಿನ್ಯಾಸಗೊಳಿಸಲಾಗಿದೆ ಎಂಬುದನ್ನು ಬಹಿರಂಗಪಡಿಸುತ್ತದೆ. ದುರ್ಬಲವಾದ ಕೋಡ್ ಬೇಸ್ (codebase) ಪ್ರತಿಯೊಂದು ಸಣ್ಣ ರಚನಾತ್ಮಕ ಬದಲಾವಣೆಗೂ ಡೆವಲಪರ್ ಹಸ್ತಕ್ಷೇಪವನ್ನು ಬಯಸುತ್ತದೆ. ಉತ್ತಮವಾಗಿ ನಿರ್ಮಿಸಲಾದ ಸೈಟ್ ನಿಮ್ಮ ಮಾರ್ಕೆಟಿಂಗ್ ತಂಡಕ್ಕೆ ಯಾವುದೇ ಟಿಕೆಟ್ ತೆರೆಯುವ ಅಗತ್ಯವಿಲ್ಲದೆ CMS ಮೂಲಕ ಹೊಸ ಲ್ಯಾಂಡಿಂಗ್ ಪೇಜ್ ಲೇಔಟ್ಗಳನ್ನು ರಚಿಸುವ ನಮ್ಯತೆಯನ್ನು (flexibility) ನೀಡುತ್ತದೆ. ಏಜೆನ್ಸಿಯು ಈ ಪ್ರಶ್ನೆಗೆ ಗೊಂದಲಕ್ಕೊಳಗಾದರೆ, ಅವರ ಡೆವಲಪ್ಮೆಂಟ್ ಪ್ರಕ್ರಿಯೆಯು ಕೇವಲ ಲಾಂಚ್ನಲ್ಲಿ ಕೊನೆಗೊಂಡಿದೆಯೇ ಹೊರತು ದೀರ್ಘಕಾಲದ ನಿರ್ವಹಣೆಯನ್ನಲ್ಲ.
CMS ಬ್ಲೈಂಡ್ ಸ್ಪಾಟ್
ಇಲ್ಲಿಯೇ ಹೆಚ್ಚಿನ ಪ್ರಾಜೆಕ್ಟ್ಗಳು ಲಾಂಚ್ ಆದ ನಂತರ ಮೌನವಾಗಿ ವಿಫಲವಾಗುತ್ತವೆ.
ಗ್ರಾಹಕರು ಹೋಮ್ಪೇಜ್ನ ಹೀರೋ ಸೆಕ್ಷನ್ (hero section) ಬಗ್ಗೆ ಅತಿಯಾಗಿ ಗಮನ ಹರಿಸುತ್ತಾರೆ ಮತ್ತು ದೈನಂದಿನ ಕೆಲಸದ ಹರಿವನ್ನು (workflow) ಮರೆಯುತ್ತಾರೆ. ಲಾಂಚ್ ಆದ ಆರು ವಾರಗಳ ನಂತರ, ನಿಮ್ಮ ಸೇಲ್ಸ್ ತಂಡವು ಬೆಲೆಗಳನ್ನು (pricing) ಅಪ್ಡೇಟ್ ಮಾಡಲು ಬಯಸುತ್ತದೆ. ನಿಮ್ಮ ಕಂಟೆಂಟ್ ಮ್ಯಾನೇಜರ್ಗೆ ಒಂದು ಕೇಸ್ ಸ್ಟಡಿ ಪ್ರಕಟಿಸಬೇಕಾಗಿರುತ್ತದೆ. ನಿಮ್ಮ HR ಮುಖ್ಯಸ್ಥರು ಮೂರು ಹೊಸ ಉದ್ಯೋಗಾವಕಾಶಗಳನ್ನು ಪೋಸ್ಟ್ ಮಾಡಲು ಬಯಸುತ್ತಾರೆ. ಇವುಗಳಲ್ಲಿ ಯಾವುದನ್ನಾದರೂ ಸೇರಿಸಲು ಸಪೋರ್ಟ್ ಟಿಕೆಟ್ ಸಲ್ಲಿಸಬೇಕಾಗಿ ಮತ್ತು PHP ಟೆಂಪ್ಲೇಟ್ ಎಡಿಟ್ ಮಾಡಲು ಡೆವಲಪರ್ನಿಗಾಗಿ ಎರಡು ಕೆಲಸದ ದಿನಗಳ ಕಾಲ ಕಾಯಬೇಕಾಗಿ ಬಂದರೆ, ನಿಮ್ಮ ವೆಬ್ಸೈಟ್ ಈಗಾಗಲೇ ಒಂದು ಅಡಚಣೆಯಾಗಿ (bottleneck) ಪರಿಣಮಿಸಿದೆ ಎಂದರ್ಥ.
ಅದಕ್ಕಾಗಿಯೇ 'CMS-first' ಕಾರ್ಯತಂತ್ರವು ಮುಖ್ಯವಾಗುತ್ತದೆ. ಕಂಟೆಂಟ್ ಮ್ಯಾನೇಜ್ಮೆಂಟ್ ಸಿಸ್ಟಮ್ (CMS) ಮೊದಲೇ ಚರ್ಚೆಯ ಭಾಗವಾಗಿರಬೇಕು, ಕೊನೆಯಲ್ಲಿ ಅಂಟಿಸುವ ಒಂದು ಹೆಚ್ಚುವರಿ ವಿಷಯವಾಗಿರಬಾರದು. ನಿಮ್ಮ ತಂಡವು ಕೋಡ್ ಅನ್ನು ಮುಟ್ಟದೆಯೇ ಪಠ್ಯವನ್ನು ಎಡಿಟ್ ಮಾಡಲು, ಚಿತ್ರಗಳನ್ನು ಬದಲಾಯಿಸಲು ಮತ್ತು ಹೊಸ ಪುಟಗಳನ್ನು ಪ್ರಕಟಿಸಲು ಸಾಧ್ಯವಾಗಬೇಕು. ಲಾಂಚ್ ಆದ ನಂತರ ಕಂಟೆಂಟ್ ಅನ್ನು ಯಾರು ನಿರ್ವಹಿಸುತ್ತಾರೆ ಎಂದು ಏಜೆನ್ಸಿಯು ನಿಮ್ಮನ್ನು ಕೇಳದಿದ್ದರೆ, ಅವರು ನಿಮ್ಮ ಕಾರ್ಯಾಚರಣೆಯ ವಾಸ್ತವದ (operational reality) ಬಗ್ಗೆ ಯೋಚಿಸಿರಲಿಲ್ಲ ಎಂದರ್ಥ.
ಎರಡು ತಂಡಗಳು ಶೂನ್ಯ ತಂಡಗಳಾದಾಗ
ಕೆಲವು ವ್ಯವಹಾರಗಳು ವಿನ್ಯಾಸ (design) ಮತ್ತು ಅಭಿವೃದ್ಧಿ (dev) ನಡುವಿನ ವ್ಯತ್ಯಾಸವನ್ನು ಪರಿಹರಿಸಲು ಪ್ರತ್ಯೇಕ ವೆಂಡರ್ಗಳನ್ನು ನೇಮಿಸಿಕೊಳ್ಳಲು ಪ್ರಯತ್ನಿಸುತ್ತವೆ. ಅವರು ನೋಟದ ಮತ್ತು ಅನುಭವದ (look and feel) ವಿಷಯಕ್ಕಾಗಿ ದೆಹಲಿಯ ಡಿಸೈನ್ ಸ್ಟುಡಿಯೊವನ್ನು ತರುತ್ತಾರೆ, ನಂತರ ಬಿಲ್ಡ್ ಮಾಡಲು ಫೈಲ್ಗಳನ್ನು ನೋಯ್ಡಾದ ಡೆವ್ ಶಾಪ್ಗೆ ನೀಡುತ್ತಾರೆ. ಕಾಗದದ ಮೇಲೆ ಎಲ್ಲರೂ ಪರಿಣಿತರಾಗಿರುತ್ತಾರೆ. ಆದರೆ ಪ್ರಾಯೋಗಿಕವಾಗಿ, ಅನುವಾದದ ತಪ್ಪುಗಳು (translation errors) ಹೆಚ್ಚಾಗುತ್ತವೆ.
ಸ್ಟ್ಯಾಟಿಕ್ ಸ್ಕ್ರೀನ್ಗಳು ರೆಸ್ಪಾನ್ಸಿವ್ ವರ್ತನೆಯನ್ನು (responsive behavior) ವಿವರಿಸುವುದಿಲ್ಲ. ಸರ್ಚ್ ಮಾಡಿದಾಗ ಯಾವುದೇ ಫಲಿತಾಂಶ ಬರದಿದ್ದರೆ ಏನಾಗುತ್ತದೆ ಎಂಬುದನ್ನು ಮಾಕಪ್ (mockup) ತಿಳಿಸುವುದಿಲ್ಲ. ಇದು ಹೋವರ್ ಸ್ಟೇಟ್ಸ್ (hover states), ಲೋಡಿಂಗ್ ಸ್ಕೆಲೆಟನ್ಸ್ಗಳು (loading skeletons), ಎರರ್ ಮೆಸೇಜಿಂಗ್ ಅಥವಾ ಎಂಪ್ಟಿ ಸ್ಟೇಟ್ಗಳನ್ನು ವಿವರಿಸುವುದಿಲ್ಲ. ಡೆವಲಪರ್ ಉದ್ದೇಶವನ್ನು ಊಹಿಸಬೇಕಾಗುತ್ತದೆ. ಹೆಚ್ಚಾಗಿ ಅವರು ತಪ್ಪಾಗಿ ಊಹಿಸುತ್ತಾರೆ. ನಂತರ ಡಿಸೈನರ್ ಸ್ಟೇಜಿಂಗ್ ಸೈಟ್ ಅನ್ನು ಪರಿಶೀಲಿಸಿ ಅದು ಕೆಟ್ಟುಹೋಗಿದೆ ಎಂದು ಘೋಷಿಸುತ್ತಾರೆ. ಡಿಸೈನ್ ಅಪೂರ್ಣವಾಗಿತ್ತು ಎಂದು ಡೆವಲಪರ್ ವಾದಿಸುತ್ತಾರೆ. ಎರಡು ತಂಡಗಳು ಸ್ಲ್ಯಾಕ್ (Slack) ಮತ್ತು ಇಮೇಲ್ ಚೇನ್ಗಳಲ್ಲಿ ವಾರಗಟ್ಟಲೆ ವಾದಿಸುತ್ತಿರುವಾಗ, ಕ್ಲೈಂಟ್ ಈ ಪುನರ್ಕೆಲಸಕ್ಕಾಗಿ (rework) ಹಣ ಪಾವತಿಸುತ್ತಾರೆ.
ಇದರ ವೆಚ್ಚ ಕೇವಲ ಹಣಕಾಸಿನದ್ದಲ್ಲ. ಇದು ವೇಗಕ್ಕೆ (momentum) ಸಂಬಂಧಿಸಿದ್ದು. ಉತ್ಪನ್ನಗಳ ಲಾಂಚ್ ವಿಳಂಬವಾಗುತ್ತದೆ. ಮಾರ್ಕೆಟಿಂಗ್ ಕ್ಯಾಲೆಂಡರ್ಗಳು ಸ್ಥಗಿತಗೊಳ್ಳುತ್ತವೆ. ನಿಮ್ಮ ತಂಡಗಳು ಎಂದಿಗೂ ಇರಬಾರದಲ್ಲಿದ್ದ ಕೊರತೆಗಳನ್ನು ಸರಿಪಡಿಸುತ್ತಿರುವಾಗ, ಸ್ಪರ್ಧಿಗಳು ವೇಗವಾಗಿ ಮುನ್ನಡೆಯುತ್ತಾರೆ.
ಹ್ಯಾಂಡ್ಆಫ್ನ (Handoff) ನಿಜವಾದ ವೆಚ್ಚ
ನೀವು ಇದನ್ನು ಓದುತ್ತಿರುವ ಫ್ರೀಲ್ಯಾನ್ಸರ್ ಆಗಿದ್ದರೆ, ಇದೆಲ್ಲವೂ ಕೇವಲ ಸಿದ್ಧಾಂತವಲ್ಲ. ನೀವು ಬಹುಶಃ ಈ ಅವ್ಯವಸ್ಥೆಯನ್ನು ಎದುರಿಸಿರಬಹುದು. ಮೊಬೈಲ್ ಬ್ರೇಕ್ಪಾಯಿಂಟ್ಗಳಿಲ್ಲದ ಇಪ್ಪತ್ತು ಆರ್ಟ್ಬೋರ್ಡ್ಗಳನ್ನು ಹೊಂದಿರುವ ಕ್ಲೈಂಟ್ನ Figma ಫೈಲ್ ಅನ್ನು ನೀವು ತೆರೆದಿರಬಹುದು. ಹಿಂದಿನ ಡೆವಲಪರ್ ಡಿಸೈನರ್ ಅನ್ನು ಎಂದಿಗೂ ಭೇಟಿ ಮಾಡದ ಕಾರಣ, ಪ್ರತಿಯೊಂದು ಕಂಟೆಂಟ್ ಫೀಲ್ಡ್ ಕೂಡ ಹಾರ್ಡ್ಕೋಡ್ ಆಗಿರುವ ಬ್ಯಾಕ್ಎಂಡ್ ಅನ್ನು ನೀವು ನೋಡಿರಬಹುದು. ನೀವು ಎರಡು ದಿನಗಳ ಕೆಲಸ ಎಂದು ಬೆಲೆ ನಿಗದಿಪಡಿಸಿ, ನಂತರ ಇಡೀ ಕಂಟೆಂಟ್ ಆರ್ಕಿಟೆಕ್ಚರ್ ಅನ್ನು ಮರುನಿರ್ಮಿಸಬೇಕಾಗುತ್ತದೆ ಎಂದು ಕಂಡುಕೊಂಡಿರಬಹುದು.
ಈ ಅಂತರಗಳನ್ನು ತುಂಬುವುದು ದುಬಾರಿಯಾಗುತ್ತದೆ ಏಕೆಂದರೆ ಅವು ಕೇವಲ ತಾಂತ್ರಿಕ ಸಮಸ್ಯೆಗಳಲ್ಲ. ಅವು ಕೋಡ್ನಲ್ಲಿ ಸ್ಥಿರಗೊಂಡಿರುವ ಸಂವಹನ ವೈಫಲ್ಯಗಳು (communication failures).
ಸಾರಾಂಶ
ವೆಬ್ಸೈಟ್ ಎಂಬುದು ಕೇವಲ ಒಂದು ಲೋಗೋ ಅಲ್ಲ. ಇದು ದೃಶ್ಯಗಳು ಮತ್ತು ಮೂಲಸೌಕರ್ಯಗಳ ಮೂಲಕ ನಿಮ್ಮ ವ್ಯವಹಾರವನ್ನು ನಿಮ್ಮ ಗ್ರಾಹಕರೊಂದಿಗೆ ಸಂಪರ್ಕಿಸುವ ಒಂದು ಜೀವಂತ ವ್ಯವಸ್ಥೆ. ನೀವು ಯಾವುದೇ ಏಜೆನ್ಸಿಯನ್ನು ನೇಮಿಸಿಕೊಳ್ಳುವ ಮೊದಲು, ಆ ಸಮೀಕರಣದ ಯಾವ ಭಾಗವನ್ನು ನೀವು ವಾಸ್ತವವಾಗಿ ಖರೀದಿಸುತ್ತಿದ್ದೀರಿ ಎಂಬುದನ್ನು ತಿಳಿಯಿರಿ. ಅವರ ಪ್ರಕ್ರಿಯೆಯನ್ನು ಪರೀಕ್ಷಿಸಿ, ಎಂಡ್-ಟು-ಎಂಡ್ ಮಾಲೀತ್ವದ (end-to-end ownership) ಪುರಾವೆಯನ್ನು ಕೇಳಿ ಮತ್ತು ರಿಬ್ಬನ್ ಕತ್ತರಿಸುವವರೆಗೆ CMS ಅನ್ನು ನಿರ್ಲಕ್ಷಿಸಲು ನಿರಾಕರಿಸಿ. ಲಾಂಚ್ ದಿನದ ನಂತರವೂ ಉಳಿದುಕೊಳ್ಳುವ ಪ್ರಾಜೆಕ್ಟ್ ಎಂದರೆ, ಎಂಟು ತಿಂಗಳ ನಂತರದ ಯಾವುದೋ ಮಂಗಳವಾರ, ನೀವು ಯಾರಿಗೂ ಕರೆ ಮಾಡದೆ ಬೆಲೆಯನ್ನು ಬದಲಾಯಿಸಬೇಕಾದಾಗ ಸುಲಭವಾಗಿ ಕೆಲಸ ಮಾಡುವಂತೆ ಯೋಜಿಸಿದ ಪ್ರಾಜೆಕ್ಟ್.