ಗುಣಮಟ್ಟಕ್ಕೆ ಯಾರು ಹೊಣೆ?

ಹಲೋ, ಹಬ್ರ್!

ನಾವು ಹೊಸ ಪ್ರಮುಖ ವಿಷಯವನ್ನು ಹೊಂದಿದ್ದೇವೆ - ಐಟಿ ಉತ್ಪನ್ನಗಳ ಉತ್ತಮ ಗುಣಮಟ್ಟದ ಅಭಿವೃದ್ಧಿ. HighLoad++ ನಲ್ಲಿ ನಾವು ಸಾಮಾನ್ಯವಾಗಿ ಕಾರ್ಯನಿರತ ಸೇವೆಗಳನ್ನು ಹೇಗೆ ವೇಗವಾಗಿ ಮಾಡುವುದು ಎಂಬುದರ ಕುರಿತು ಮಾತನಾಡುತ್ತೇವೆ ಮತ್ತು Frontend Conf ನಲ್ಲಿ ನಾವು ನಿಧಾನಗೊಳಿಸದ ತಂಪಾದ ಬಳಕೆದಾರ ಇಂಟರ್ಫೇಸ್ ಬಗ್ಗೆ ಮಾತನಾಡುತ್ತೇವೆ. ನಾವು ನಿಯಮಿತವಾಗಿ ಪರೀಕ್ಷೆಯ ಕುರಿತು ವಿಷಯಗಳನ್ನು ಹೊಂದಿದ್ದೇವೆ ಮತ್ತು ಪರೀಕ್ಷೆ ಸೇರಿದಂತೆ ವಿವಿಧ ಪ್ರಕ್ರಿಯೆಗಳನ್ನು ಸಂಯೋಜಿಸುವ ಕುರಿತು DevOpsConf. ಆದರೆ ಸಾಮಾನ್ಯವಾಗಿ ಗುಣಮಟ್ಟ ಎಂದು ಕರೆಯಬಹುದಾದ ಬಗ್ಗೆ ಮತ್ತು ಅದರ ಮೇಲೆ ಸಮಗ್ರವಾಗಿ ಹೇಗೆ ಕೆಲಸ ಮಾಡುವುದು - ಇಲ್ಲ.

ಇದನ್ನು ಸರಿಪಡಿಸೋಣ ಗುಣಮಟ್ಟ ಕಾನ್ಫ್ — ನಾವು ಅಭಿವೃದ್ಧಿಯ ಪ್ರತಿಯೊಂದು ಹಂತದಲ್ಲೂ ಬಳಕೆದಾರರಿಗೆ ಅಂತಿಮ ಉತ್ಪನ್ನದ ಗುಣಮಟ್ಟದ ಬಗ್ಗೆ ಚಿಂತನೆಯ ಸಂಸ್ಕೃತಿಯನ್ನು ಅಭಿವೃದ್ಧಿಪಡಿಸುತ್ತೇವೆ. ನಿಮ್ಮ ಜವಾಬ್ದಾರಿಯ ಪ್ರದೇಶದ ಮೇಲೆ ಕೇಂದ್ರೀಕರಿಸದ ಅಭ್ಯಾಸ, ಮತ್ತು ಪರೀಕ್ಷಕರೊಂದಿಗೆ ಮಾತ್ರವಲ್ಲದೆ ಗುಣಮಟ್ಟವನ್ನು ಸಂಯೋಜಿಸುವುದು.

ಕಟ್ ಕೆಳಗೆ ನಾವು ಪ್ರೋಗ್ರಾಂ ಸಮಿತಿಯ ಮುಖ್ಯಸ್ಥರೊಂದಿಗೆ ಮಾತನಾಡುತ್ತೇವೆ, Tinkoff.Business ನಲ್ಲಿ ಪರೀಕ್ಷಾ ಮುಖ್ಯಸ್ಥ, ರಷ್ಯನ್-ಮಾತನಾಡುವ QA ಸಮುದಾಯದ ಸೃಷ್ಟಿಕರ್ತ ಅನಸ್ತಾಸಿಯಾ ಆಸೀವಾ-ನ್ಗುಯೆನ್ QA ಉದ್ಯಮದ ಸ್ಥಿತಿ ಮತ್ತು ಹೊಸ ಸಮ್ಮೇಳನದ ಉದ್ದೇಶದ ಬಗ್ಗೆ.

- ನಾಸ್ತಿಯಾ ಹಲೋ. ದಯವಿಟ್ಟು ನಿಮ್ಮ ಬಗ್ಗೆ ನಮಗೆ ತಿಳಿಸಿ.

ಅನಸ್ತಾಸಿಯಾ: ನಾನು ಬ್ಯಾಂಕಿನಲ್ಲಿ ಪರೀಕ್ಷೆಯನ್ನು ನಿರ್ವಹಿಸುತ್ತೇನೆ, ನಾನು ದೊಡ್ಡ ತಂಡಕ್ಕೆ ಜವಾಬ್ದಾರನಾಗಿರುತ್ತೇನೆ - ನಾವು 90 ಕ್ಕಿಂತ ಹೆಚ್ಚು ಜನರಿದ್ದೇವೆ. ನಾವು ಪ್ರಮುಖ ವ್ಯಾಪಾರ ಮಾರ್ಗವನ್ನು ಹೊಂದಿದ್ದೇವೆ; ಕಾನೂನು ಘಟಕಗಳಿಗೆ ಪರಿಸರ ವ್ಯವಸ್ಥೆಗೆ ನಾವು ಜವಾಬ್ದಾರರಾಗಿದ್ದೇವೆ.

ನಾನು ಮೆಕ್ಯಾನಿಕ್ಸ್ ಮತ್ತು ಗಣಿತಶಾಸ್ತ್ರವನ್ನು ಅಧ್ಯಯನ ಮಾಡಿದ್ದೇನೆ ಮತ್ತು ಆರಂಭದಲ್ಲಿ ಪ್ರೋಗ್ರಾಮರ್ ಆಗಲು ಬಯಸಿದ್ದೆ. ಆದರೆ ನಾನು ಆಸಕ್ತಿದಾಯಕ ಪ್ರಸ್ತಾಪವನ್ನು ಪಡೆದಾಗ, ನಾನು ಪರೀಕ್ಷಕನಾಗಿ ಪ್ರಯತ್ನಿಸಲು ನಿರ್ಧರಿಸಿದೆ. ವಿಚಿತ್ರವೆಂದರೆ, ಇದು ನನ್ನ ಕರೆ ಎಂದು ಬದಲಾಯಿತು. ಈಗ ನಾನು ಈ ಉದ್ಯಮದಲ್ಲಿ ನನ್ನ ಎಲ್ಲಾ ಕೆಲಸಗಳನ್ನು ನೋಡುತ್ತೇನೆ.

ನಾನು ಕ್ವಾಲಿಟಿ ಅಶ್ಯೂರೆನ್ಸ್ ಶಿಸ್ತಿನ ಕಟ್ಟಾ ಅನುಯಾಯಿಯಾಗಿದ್ದೇನೆ. ಯಾವ ಉತ್ಪನ್ನಗಳನ್ನು ರಚಿಸಲಾಗಿದೆ, ಕಂಪನಿಯಲ್ಲಿ, ತಂಡದಲ್ಲಿ ಮತ್ತು ತಾತ್ವಿಕವಾಗಿ, ಅಭಿವೃದ್ಧಿ ಪ್ರಕ್ರಿಯೆಯಲ್ಲಿ ಗುಣಮಟ್ಟವನ್ನು ಹೇಗೆ ಪರಿಗಣಿಸಲಾಗುತ್ತದೆ ಎಂಬುದರ ಬಗ್ಗೆ ನಾನು ಅಸಡ್ಡೆ ಹೊಂದಿಲ್ಲ.

ಅದು ನನಗೆ ಸ್ಪಷ್ಟವಾಗಿದೆ ಈ ದಿಕ್ಕಿನಲ್ಲಿ ಸಮುದಾಯವು ಸಾಕಷ್ಟು ಪ್ರಬುದ್ಧವಾಗಿಲ್ಲ, ಕನಿಷ್ಠ ರಷ್ಯಾದಲ್ಲಿ. ಗುಣಮಟ್ಟದ ಭರವಸೆಯು ಅವಶ್ಯಕತೆಗಳ ಅನುಸರಣೆಗಾಗಿ ಅಪ್ಲಿಕೇಶನ್ ಅನ್ನು ಪರೀಕ್ಷಿಸುವ ಸತ್ಯ ಮಾತ್ರವಲ್ಲ ಎಂದು ನಾವು ಯಾವಾಗಲೂ ಅರ್ಥಮಾಡಿಕೊಳ್ಳುವುದಿಲ್ಲ. ನಾನು ಈ ಪರಿಸ್ಥಿತಿಯನ್ನು ಬದಲಾಯಿಸಲು ಬಯಸುತ್ತೇನೆ.

— ನೀವು ಗುಣಮಟ್ಟ ಭರವಸೆ ಮತ್ತು ಪರೀಕ್ಷೆ ಪದಗಳನ್ನು ಬಳಸುತ್ತೀರಿ. ಸರಾಸರಿ ವ್ಯಕ್ತಿಯ ದೃಷ್ಟಿಯಲ್ಲಿ, ಈ ಎರಡು ಪದಗಳು ಆಗಾಗ್ಗೆ ಅತಿಕ್ರಮಿಸುತ್ತವೆ. ನೀವು ಆಳವಾಗಿ ಅಗೆದರೆ ಅವು ಹೇಗೆ ಭಿನ್ನವಾಗಿರುತ್ತವೆ?

ಅನಸ್ತಾಸಿಯಾ: ಬದಲಿಗೆ, ಅವರು ಭಿನ್ನವಾಗಿಲ್ಲ. ಪರೀಕ್ಷೆಯು ಗುಣಮಟ್ಟದ ಭರವಸೆಯ ಶಿಸ್ತಿನ ಭಾಗವಾಗಿದೆ; ಇದು ನೇರ ಚಟುವಟಿಕೆಯಾಗಿದೆ - ನಾನು ಏನನ್ನಾದರೂ ಪರೀಕ್ಷಿಸುತ್ತಿದ್ದೇನೆ. ವಾಸ್ತವವಾಗಿ ಬಹಳಷ್ಟು ರೀತಿಯ ಪರೀಕ್ಷೆಗಳಿವೆ, ಮತ್ತು ವಿವಿಧ ರೀತಿಯ ಪರೀಕ್ಷೆಗಳಿಗೆ ವಿವಿಧ ಜನರು ಜವಾಬ್ದಾರರಾಗಿರುತ್ತಾರೆ. ಆದರೆ ಇಲ್ಲಿ ರಷ್ಯಾದಲ್ಲಿ, ಕಂಪನಿಗಳಿಗೆ ಪರೀಕ್ಷಕರನ್ನು ಪೂರೈಸುವ ಹೊರಗುತ್ತಿಗೆದಾರರ ಅಲೆ ಕಾಣಿಸಿಕೊಂಡಾಗ, ಪರೀಕ್ಷೆಯನ್ನು ಒಂದೇ ಪ್ರಕಾರಕ್ಕೆ ಇಳಿಸಲಾಯಿತು.

ಹೆಚ್ಚಿನ ಸಂದರ್ಭಗಳಲ್ಲಿ, ಅವು ಕ್ರಿಯಾತ್ಮಕ ಪರೀಕ್ಷೆಗೆ ಮಾತ್ರ ಸೀಮಿತವಾಗಿವೆ: ಡೆವಲಪರ್‌ಗಳು ಕೋಡ್ ಮಾಡಿರುವುದು ನಿರ್ದಿಷ್ಟತೆಗೆ ಅನುಗುಣವಾಗಿದೆಯೇ ಎಂದು ಅವರು ಪರಿಶೀಲಿಸುತ್ತಾರೆ ಮತ್ತು ಅಷ್ಟೆ.

— ದಯವಿಟ್ಟು ನಮಗೆ ತಿಳಿಸಿ ಇತರ ಯಾವ ಗುಣಮಟ್ಟದ ಭರವಸೆ ವಿಭಾಗಗಳಿವೆ? ಇಲ್ಲಿ ಪರೀಕ್ಷೆಯ ಹೊರತಾಗಿ ಇನ್ನೇನು ಸೇರಿಸಲಾಗಿದೆ?

ಅನಸ್ತಾಸಿಯಾ: ಗುಣಮಟ್ಟದ ಭರವಸೆ, ಮೊದಲನೆಯದಾಗಿ, ಗುಣಮಟ್ಟದ ಉತ್ಪನ್ನವನ್ನು ರಚಿಸುವುದು. ಅಂದರೆ, ನಮ್ಮ ಉತ್ಪನ್ನವು ಯಾವ ಗುಣಮಟ್ಟದ ಗುಣಲಕ್ಷಣಗಳನ್ನು ಹೊಂದಿರಬೇಕು ಎಂದು ನಾವು ನಮ್ಮನ್ನು ಕೇಳಿಕೊಳ್ಳುತ್ತೇವೆ. ಅಂತೆಯೇ, ನಾವು ಇದನ್ನು ಅರ್ಥಮಾಡಿಕೊಂಡರೆ, ಈ ಗುಣಮಟ್ಟದ ಗುಣಲಕ್ಷಣಗಳನ್ನು ಯಾರು ಪ್ರಭಾವಿಸುತ್ತಾರೆ ಎಂಬುದನ್ನು ನಾವು ಹೋಲಿಸಬಹುದು. ಪರವಾಗಿಲ್ಲ, ಡೆವಲಪರ್, ಪ್ರಾಜೆಕ್ಟ್ ಮ್ಯಾನೇಜರ್ ಅಥವಾ ಉತ್ಪನ್ನ ತಜ್ಞ ಉತ್ಪನ್ನದ ಅಭಿವೃದ್ಧಿ, ಅದರ ಬ್ಯಾಕ್‌ಲಾಗ್ ಮತ್ತು ಅದರ ಕಾರ್ಯತಂತ್ರದ ಮೇಲೆ ಪ್ರಭಾವ ಬೀರುವ ವ್ಯಕ್ತಿ.

ಪರೀಕ್ಷಕನು ತನ್ನ ಪಾತ್ರದ ಬಗ್ಗೆ ಹೆಚ್ಚು ತಿಳಿದುಕೊಳ್ಳುತ್ತಾನೆ. ಅವಶ್ಯಕತೆಗಳ ಅನುಸರಣೆಯನ್ನು ಪರೀಕ್ಷಿಸುವುದು ಮಾತ್ರವಲ್ಲ, ಅವಶ್ಯಕತೆಗಳನ್ನು ಪರೀಕ್ಷಿಸುವುದು, ಉತ್ಪನ್ನ ತಜ್ಞರಿಂದ ಬರುವ ಸೂತ್ರೀಕರಣಗಳನ್ನು ಪ್ರಶ್ನಿಸುವುದು ಮತ್ತು ಕ್ಲೈಂಟ್‌ನ ಎಲ್ಲಾ ಸೂಚ್ಯ ಅವಶ್ಯಕತೆಗಳು ಮತ್ತು ನಿರೀಕ್ಷೆಗಳನ್ನು ಬಹಿರಂಗಪಡಿಸುವುದು ಅವರ ಕಾರ್ಯವಾಗಿದೆ ಎಂದು ಅವರು ಅರ್ಥಮಾಡಿಕೊಳ್ಳುತ್ತಾರೆ. ನಾವು ನಮ್ಮ ಗ್ರಾಹಕರಿಗೆ ಹೊಸ ಕಾರ್ಯವನ್ನು ತಲುಪಿಸಿದಾಗ, ನಾವು ಅವರ ನಿರೀಕ್ಷೆಗಳನ್ನು ನಿಜವಾಗಿಯೂ ಪೂರೈಸಬೇಕು ಮತ್ತು ಅವರ ನೋವನ್ನು ಪರಿಹರಿಸಬೇಕು. ನಾವು ಗುಣಮಟ್ಟದ ಎಲ್ಲಾ ಗುಣಲಕ್ಷಣಗಳ ಬಗ್ಗೆ ಯೋಚಿಸಿದರೆ, ಕ್ಲೈಂಟ್ ತೃಪ್ತರಾಗುತ್ತಾರೆ ಮತ್ತು ಅವರ ಉತ್ಪನ್ನವನ್ನು ಬಳಸುವ ಕಂಪನಿಯು ನಿಜವಾಗಿಯೂ ಅವರ ಆಸಕ್ತಿಗಳ ಬಗ್ಗೆ ಕಾಳಜಿ ವಹಿಸುತ್ತದೆ ಮತ್ತು "ಕೇವಲ ವೈಶಿಷ್ಟ್ಯವನ್ನು ಬಿಡುಗಡೆ ಮಾಡಲು" ತತ್ವದ ಮೇಲೆ ಕಾರ್ಯನಿರ್ವಹಿಸುವುದಿಲ್ಲ ಎಂದು ಅರ್ಥಮಾಡಿಕೊಳ್ಳುತ್ತಾರೆ.

— ನೀವು ಈಗ ವಿವರಿಸಿರುವುದು ಉತ್ಪನ್ನ ತಜ್ಞರ ಕಾರ್ಯವಾಗಿದೆ ಎಂದು ತೋರುತ್ತದೆ. ಇದು ತಾತ್ವಿಕವಾಗಿ, ಪರೀಕ್ಷೆಯ ಬಗ್ಗೆ ಅಲ್ಲ ಮತ್ತು ಗುಣಮಟ್ಟದ ಬಗ್ಗೆ ಅಲ್ಲ - ಇದು ಸಾಮಾನ್ಯವಾಗಿ ಉತ್ಪನ್ನ ನಿರ್ವಹಣೆಯ ಬಗ್ಗೆ ಅಲ್ಲವೇ?

ಅನಸ್ತಾಸಿಯಾ: ಸೇರಿದಂತೆ. ಗುಣಮಟ್ಟದ ಭರವಸೆಯು ಒಬ್ಬ ನಿರ್ದಿಷ್ಟ ವ್ಯಕ್ತಿ ಜವಾಬ್ದಾರರಾಗಿರುವ ಒಂದು ಶಿಸ್ತು ಅಲ್ಲ. ಈಗ ಪರೀಕ್ಷೆಯಲ್ಲಿ ಜನಪ್ರಿಯ ನಿರ್ದೇಶನವಿದೆ, ಒಂದು ವಿಧಾನವನ್ನು ಕರೆಯಲಾಗುತ್ತದೆ ಅಗೈಲ್ ಪರೀಕ್ಷೆ. ಇದು ಪರೀಕ್ಷೆಗೆ ತಂಡದ ವಿಧಾನವಾಗಿದೆ ಎಂದು ಅವರ ವ್ಯಾಖ್ಯಾನವು ಸ್ಪಷ್ಟವಾಗಿ ಹೇಳುತ್ತದೆ, ಇದು ಒಂದು ನಿರ್ದಿಷ್ಟ ಅಭ್ಯಾಸಗಳನ್ನು ಒಳಗೊಂಡಿರುತ್ತದೆ. ಈ ವಿಧಾನವನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸಲು ಇಡೀ ತಂಡವು ಜವಾಬ್ದಾರವಾಗಿದೆ; ತಂಡದಲ್ಲಿ ಪರೀಕ್ಷಕನಿರುವುದು ಸಹ ಅಗತ್ಯವಿಲ್ಲ. ಸಂಪೂರ್ಣ ತಂಡವು ಗ್ರಾಹಕರಿಗೆ ಮೌಲ್ಯವನ್ನು ತಲುಪಿಸಲು ಮತ್ತು ಮೌಲ್ಯವು ಗ್ರಾಹಕರ ನಿರೀಕ್ಷೆಗಳನ್ನು ಪೂರೈಸುತ್ತದೆ ಎಂದು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳಲು ಕೇಂದ್ರೀಕೃತವಾಗಿದೆ.

- ಗುಣಮಟ್ಟವು ಬಹುತೇಕ ಎಲ್ಲಾ ಸುತ್ತಮುತ್ತಲಿನ ವಿಭಾಗಗಳೊಂದಿಗೆ ಛೇದಿಸುತ್ತದೆ, ಸುತ್ತಲಿನ ಎಲ್ಲದರ ಮೇಲೆ ಚೌಕಟ್ಟನ್ನು ಹೇರುತ್ತದೆ ಎಂದು ಅದು ತಿರುಗುತ್ತದೆ?

ಅನಸ್ತಾಸಿಯಾ: ಸರಿ. ನಾವು ಗುಣಮಟ್ಟದ ಉತ್ಪನ್ನವನ್ನು ಹೇಗೆ ರಚಿಸಲು ಬಯಸುತ್ತೇವೆ ಎಂಬುದರ ಕುರಿತು ನಾವು ಯೋಚಿಸಿದಾಗ, ನಾವು ಗುಣಮಟ್ಟದ ವಿವಿಧ ಗುಣಲಕ್ಷಣಗಳ ಬಗ್ಗೆ ಯೋಚಿಸಲು ಪ್ರಾರಂಭಿಸುತ್ತೇವೆ. ಉದಾಹರಣೆಗೆ, ನಮ್ಮ ಕ್ಲೈಂಟ್‌ಗೆ ಅಗತ್ಯವಿರುವ ವೈಶಿಷ್ಟ್ಯವನ್ನು ನಾವು ನಿಜವಾಗಿಯೂ ಮಾಡಿದ್ದೇವೆ ಎಂಬುದನ್ನು ಪರಿಶೀಲಿಸುವುದು ಹೇಗೆ.

ಈ ರೀತಿಯ ಪರೀಕ್ಷೆಯು ಇಲ್ಲಿ ಬರುತ್ತದೆ: ಯುಎಟಿ (ಬಳಕೆದಾರರ ಸ್ವೀಕಾರ ಪರೀಕ್ಷೆ). ದುರದೃಷ್ಟವಶಾತ್, ಇದನ್ನು ರಷ್ಯಾದಲ್ಲಿ ವಿರಳವಾಗಿ ಅಭ್ಯಾಸ ಮಾಡಲಾಗುತ್ತದೆ, ಆದರೆ ಕೆಲವೊಮ್ಮೆ SCRUM ತಂಡಗಳಲ್ಲಿ ಅಂತಿಮ ಕ್ಲೈಂಟ್‌ಗಾಗಿ ಡೆಮೊ ಆಗಿ ಇರುತ್ತದೆ. ವಿದೇಶಿ ಕಂಪನಿಗಳಲ್ಲಿ ಇದು ಸಾಕಷ್ಟು ಸಾಮಾನ್ಯ ರೀತಿಯ ಪರೀಕ್ಷೆಯಾಗಿದೆ. ಎಲ್ಲಾ ಕ್ಲೈಂಟ್‌ಗಳಿಗೆ ಕಾರ್ಯವನ್ನು ತೆರೆಯುವ ಮೊದಲು, ನಾವು ಮೊದಲು UAT ಅನ್ನು ಮಾಡುತ್ತೇವೆ, ಅಂದರೆ, ಉತ್ಪನ್ನವು ನಿಜವಾಗಿಯೂ ನಿರೀಕ್ಷೆಗಳನ್ನು ಪೂರೈಸುತ್ತದೆಯೇ ಮತ್ತು ನೋವನ್ನು ಪರಿಹರಿಸುತ್ತದೆಯೇ ಎಂಬುದನ್ನು ಪರೀಕ್ಷಿಸುವ ಮತ್ತು ತಕ್ಷಣವೇ ಪ್ರತಿಕ್ರಿಯೆ ನೀಡುವ ಅಂತಿಮ ಬಳಕೆದಾರರನ್ನು ನಾವು ಆಹ್ವಾನಿಸುತ್ತೇವೆ. ಇದರ ನಂತರವೇ ಎಲ್ಲಾ ಇತರ ಕ್ಲೈಂಟ್‌ಗಳಿಗೆ ಸ್ಕೇಲಿಂಗ್ ಸಂಭವಿಸುತ್ತದೆ.

ಅಂದರೆ, ನಾವು ವ್ಯಾಪಾರದ ಮೇಲೆ ಕೇಂದ್ರೀಕರಿಸುತ್ತೇವೆ, ಅಂತಿಮ ಕ್ಲೈಂಟ್ ಮೇಲೆ, ಆದರೆ ಅದೇ ಸಮಯದಲ್ಲಿ ತಂತ್ರಜ್ಞಾನದ ಬಗ್ಗೆ ಮರೆಯಬೇಡಿ. ಉತ್ಪನ್ನದ ಗುಣಮಟ್ಟವು ತಂತ್ರಜ್ಞಾನದ ಮೇಲೆ ಹೆಚ್ಚು ಅವಲಂಬಿತವಾಗಿರುತ್ತದೆ. ನಾವು ಕೆಟ್ಟ ವಾಸ್ತುಶಿಲ್ಪವನ್ನು ಹೊಂದಿದ್ದರೆ, ವೈಶಿಷ್ಟ್ಯಗಳನ್ನು ತ್ವರಿತವಾಗಿ ಬಿಡುಗಡೆ ಮಾಡಲು ಮತ್ತು ಗ್ರಾಹಕರ ನಿರೀಕ್ಷೆಗಳನ್ನು ಪೂರೈಸಲು ನಮಗೆ ಸಾಧ್ಯವಾಗುವುದಿಲ್ಲ. ಅಳೆಯಲು ಪ್ರಯತ್ನಿಸುವಾಗ ಬಹಳಷ್ಟು ದೋಷಗಳು ಇರಬಹುದು ಅಥವಾ ರಿಫ್ಯಾಕ್ಟರ್ ಮಾಡಲು ಪ್ರಯತ್ನಿಸುವಾಗ ನಾವು ಏನನ್ನಾದರೂ ಮುರಿಯಬಹುದು. ಇದೆಲ್ಲವೂ ಗ್ರಾಹಕರ ತೃಪ್ತಿಯ ಮೇಲೆ ಪರಿಣಾಮ ಬೀರುತ್ತದೆ.

ಈ ದೃಷ್ಟಿಕೋನದಿಂದ, ವಾಸ್ತುಶಿಲ್ಪವು ನಾವು ಕ್ಲೀನ್ ಕೋಡ್ ಅನ್ನು ಬರೆಯಬಹುದು ಅದು ನಮಗೆ ತ್ವರಿತವಾಗಿ ಬದಲಾವಣೆಗಳನ್ನು ಮಾಡಲು ಅನುವು ಮಾಡಿಕೊಡುತ್ತದೆ ಮತ್ತು ನಾವು ಎಲ್ಲವನ್ನೂ ಮುರಿಯುತ್ತೇವೆ ಎಂದು ಹೆದರುವುದಿಲ್ಲ. ಆದ್ದರಿಂದ ಪರಿಷ್ಕರಣೆ ಪುನರಾವರ್ತನೆಗಳು ಹಲವಾರು ತಿಂಗಳುಗಳವರೆಗೆ ವಿಸ್ತರಿಸುವುದಿಲ್ಲ ಏಕೆಂದರೆ ನಾವು ತುಂಬಾ ಪರಂಪರೆಯನ್ನು ಹೊಂದಿದ್ದೇವೆ ಮತ್ತು ನಾವು ದೀರ್ಘ ಪರೀಕ್ಷೆಯ ಹಂತಗಳನ್ನು ಮಾಡಬೇಕಾಗಿದೆ.

— ಒಟ್ಟಾರೆಯಾಗಿ, ಡೆವಲಪರ್‌ಗಳು, ವಾಸ್ತುಶಿಲ್ಪಿಗಳು, ಉತ್ಪನ್ನ ವಿಜ್ಞಾನಿಗಳು, ಉತ್ಪನ್ನ ನಿರ್ವಾಹಕರು ಮತ್ತು ಪರೀಕ್ಷಕರು ಈಗಾಗಲೇ ತಮ್ಮನ್ನು ತೊಡಗಿಸಿಕೊಂಡಿದ್ದಾರೆ. ಗುಣಮಟ್ಟದ ಭರವಸೆ ಪ್ರಕ್ರಿಯೆಯಲ್ಲಿ ಬೇರೆ ಯಾರು ತೊಡಗಿಸಿಕೊಂಡಿದ್ದಾರೆ?

ಅನಸ್ತಾಸಿಯಾ: ಈಗ ನಾವು ಈಗಾಗಲೇ ಕ್ಲೈಂಟ್‌ಗೆ ವೈಶಿಷ್ಟ್ಯವನ್ನು ತಲುಪಿಸಿದ್ದೇವೆ ಎಂದು ಊಹಿಸೋಣ. ನಿಸ್ಸಂಶಯವಾಗಿ, ಉತ್ಪನ್ನವು ಈಗಾಗಲೇ ಉತ್ಪಾದನೆಯಲ್ಲಿದ್ದಾಗಲೂ ಅದರ ಗುಣಮಟ್ಟವನ್ನು ಮೇಲ್ವಿಚಾರಣೆ ಮಾಡಬೇಕಾಗುತ್ತದೆ. ಈ ಹಂತದಲ್ಲಿ, ದೋಷಗಳು ಎಂದು ಕರೆಯಲ್ಪಡುವ ಸ್ಪಷ್ಟವಲ್ಲದ ಸನ್ನಿವೇಶಗಳು ಕಾಣಿಸಿಕೊಳ್ಳಬಹುದು.

ನಾವು ಈಗಾಗಲೇ ಉತ್ಪನ್ನವನ್ನು ಬಿಡುಗಡೆ ಮಾಡಿದ ನಂತರ ನಾವು ಈ ದೋಷಗಳನ್ನು ಹೇಗೆ ಎದುರಿಸುತ್ತೇವೆ ಎಂಬುದು ಮೊದಲ ಪ್ರಶ್ನೆಯಾಗಿದೆ? ಉದಾಹರಣೆಗೆ, ನಾವು ಒತ್ತಡಕ್ಕೆ ಹೇಗೆ ಪ್ರತಿಕ್ರಿಯಿಸುತ್ತೇವೆ? ಪುಟವನ್ನು ಲೋಡ್ ಮಾಡಲು 30 ಸೆಕೆಂಡುಗಳಿಗಿಂತ ಹೆಚ್ಚು ಸಮಯ ತೆಗೆದುಕೊಂಡರೆ ಕ್ಲೈಂಟ್ ತುಂಬಾ ಸಂತೋಷವಾಗುವುದಿಲ್ಲ.

ಇಲ್ಲಿ ಶೋಷಣೆಯು ಕಾರ್ಯರೂಪಕ್ಕೆ ಬರುತ್ತದೆ ಅಥವಾ ಅವರು ಈಗ ಕರೆಯುವಂತೆ, DevOps. ವಾಸ್ತವವಾಗಿ, ಉತ್ಪನ್ನವು ಈಗಾಗಲೇ ಉತ್ಪಾದನೆಯಲ್ಲಿರುವಾಗ ಅದನ್ನು ನಿರ್ವಹಿಸಲು ಜವಾಬ್ದಾರರಾಗಿರುವ ಜನರು ಇವರು. ಇದು ವಿವಿಧ ರೀತಿಯ ಮೇಲ್ವಿಚಾರಣೆಯನ್ನು ಒಳಗೊಂಡಿದೆ. ಪರೀಕ್ಷೆಯ ಉಪವಿಧವೂ ಇದೆ - ಉತ್ಪಾದನೆಯ ಮೇಲೆ ಪರೀಕ್ಷೆ, ರೋಲ್‌ಔಟ್ ಮಾಡುವ ಮೊದಲು ಏನನ್ನಾದರೂ ಪರೀಕ್ಷಿಸದಿರಲು ಮತ್ತು ಉತ್ಪಾದನೆಯಲ್ಲಿ ತಕ್ಷಣವೇ ಪರೀಕ್ಷಿಸಲು ನಾವು ಅನುಮತಿಸಿದಾಗ. ಇದು ಮೂಲಸೌಕರ್ಯವನ್ನು ಸಂಘಟಿಸುವ ದೃಷ್ಟಿಕೋನದಿಂದ ಕ್ರಮಗಳ ಸರಣಿಯಾಗಿದ್ದು ಅದು ಘಟನೆಗೆ ತ್ವರಿತವಾಗಿ ಪ್ರತಿಕ್ರಿಯಿಸಲು, ಅದರ ಮೇಲೆ ಪ್ರಭಾವ ಬೀರಲು ಮತ್ತು ಅದನ್ನು ಸರಿಪಡಿಸಲು ನಿಮಗೆ ಅನುವು ಮಾಡಿಕೊಡುತ್ತದೆ.

ಮೂಲಸೌಕರ್ಯವೂ ಮುಖ್ಯವಾಗಿದೆ. ಪರೀಕ್ಷೆಯ ಸಮಯದಲ್ಲಿ, ನಾವು ಕ್ಲೈಂಟ್‌ಗೆ ನೀಡಲು ಬಯಸುವ ಎಲ್ಲವನ್ನೂ ನಾವು ನಿಜವಾಗಿಯೂ ಹೊಂದಿದ್ದೇವೆ ಎಂದು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳುವುದು ಅಸಾಧ್ಯವಾದ ಸಂದರ್ಭಗಳಿವೆ. ನಾವು ಅದನ್ನು ಉತ್ಪಾದನೆಗೆ ಸುತ್ತಿಕೊಳ್ಳುತ್ತೇವೆ ಮತ್ತು ಸ್ಪಷ್ಟವಲ್ಲದ ಸಂದರ್ಭಗಳನ್ನು ಹಿಡಿಯಲು ಪ್ರಾರಂಭಿಸುತ್ತೇವೆ. ಮತ್ತು ಎಲ್ಲಾ ಏಕೆಂದರೆ ಪರೀಕ್ಷೆಯಲ್ಲಿನ ಮೂಲಸೌಕರ್ಯವು ಉತ್ಪಾದನೆಯಲ್ಲಿನ ಮೂಲಸೌಕರ್ಯಕ್ಕೆ ಹೊಂದಿಕೆಯಾಗುವುದಿಲ್ಲ. ಇದು ಹೊಸ ರೀತಿಯ ಪರೀಕ್ಷೆಗೆ ಕಾರಣವಾಗುತ್ತದೆ - ಮೂಲಸೌಕರ್ಯ ಪರೀಕ್ಷೆ. ಇವು ವಿವಿಧ ಕಾನ್ಫಿಗರೇಶನ್‌ಗಳು, ಸೆಟ್ಟಿಂಗ್‌ಗಳು, ಡೇಟಾಬೇಸ್ ವಲಸೆ, ಇತ್ಯಾದಿ.

ಇದು ಪ್ರಶ್ನೆಯನ್ನು ಹುಟ್ಟುಹಾಕುತ್ತದೆ - ಬಹುಶಃ ತಂಡವು ಮೂಲಸೌಕರ್ಯವನ್ನು ಕೋಡ್‌ನಂತೆ ಬಳಸಬೇಕಾಗುತ್ತದೆ.

ಮೂಲಸೌಕರ್ಯವು ಉತ್ಪನ್ನದ ಗುಣಮಟ್ಟವನ್ನು ನೇರವಾಗಿ ಪರಿಣಾಮ ಬೀರುತ್ತದೆ ಎಂದು ನಾನು ನಂಬುತ್ತೇನೆ.

ಸಮ್ಮೇಳನದಲ್ಲಿ ನೈಜ ಪ್ರಕರಣದ ವರದಿ ಬರುತ್ತದೆ ಎಂದು ನಾನು ಭಾವಿಸುತ್ತೇನೆ. ಕೋಡ್‌ನಂತೆ ಮೂಲಸೌಕರ್ಯವು ಗುಣಮಟ್ಟದ ಮೇಲೆ ಹೇಗೆ ಪರಿಣಾಮ ಬೀರುತ್ತದೆ ಎಂಬುದನ್ನು ನಿಮ್ಮ ಸ್ವಂತ ಅನುಭವದಿಂದ ನಮಗೆ ಹೇಳಲು ನೀವು ಸಿದ್ಧರಿದ್ದರೆ ನಮಗೆ ಬರೆಯಿರಿ. ಕೋಡ್‌ನಂತೆ ಮೂಲಸೌಕರ್ಯವು ಎಲ್ಲಾ ಸೆಟ್ಟಿಂಗ್‌ಗಳನ್ನು ಪರಿಶೀಲಿಸಲು ಮತ್ತು ಸರಳವಾಗಿ ಸಾಧ್ಯವಾಗದ ವಿಷಯಗಳನ್ನು ಪರೀಕ್ಷಿಸಲು ಸುಲಭಗೊಳಿಸುತ್ತದೆ. ಆದ್ದರಿಂದ, ಗುಣಮಟ್ಟದ ಉತ್ಪನ್ನವನ್ನು ಅಭಿವೃದ್ಧಿಪಡಿಸುವ ಪ್ರಕ್ರಿಯೆಯಲ್ಲಿ ಕಾರ್ಯಾಚರಣೆಯು ಸಹ ಒಳಗೊಂಡಿರುತ್ತದೆ.

- ವಿಶ್ಲೇಷಣೆ ಮತ್ತು ದಾಖಲೆಗಳ ಬಗ್ಗೆ ಏನು?

ಅನಸ್ತಾಸಿಯಾ: ಇದು ಎಂಟರ್‌ಪ್ರೈಸ್ ಸಿಸ್ಟಮ್‌ಗಳಿಗೆ ಹೆಚ್ಚು ಅನ್ವಯಿಸುತ್ತದೆ. ನಾವು ಎಂಟರ್‌ಪ್ರೈಸ್ ಬಗ್ಗೆ ಮಾತನಾಡುವಾಗ, ವಿಶ್ಲೇಷಕರು ಮತ್ತು ಸಿಸ್ಟಮ್ ವಿಶ್ಲೇಷಕರಂತಹ ಜನರು ತಕ್ಷಣ ನೆನಪಿಗೆ ಬರುತ್ತಾರೆ. ಅವರನ್ನು ಕೆಲವೊಮ್ಮೆ ತಾಂತ್ರಿಕ ಬರಹಗಾರರು ಎಂದು ಕರೆಯಲಾಗುತ್ತದೆ. ನಿರ್ದಿಷ್ಟತೆಯನ್ನು ಬರೆಯಲು ಮತ್ತು ಅದನ್ನು ಪೂರ್ಣಗೊಳಿಸಲು ಅವರು ಕಾರ್ಯವನ್ನು ಸ್ವೀಕರಿಸುತ್ತಾರೆ, ಉದಾಹರಣೆಗೆ, ಒಂದು ತಿಂಗಳವರೆಗೆ.

ಅಂತಹ ದಸ್ತಾವೇಜನ್ನು ಬರೆಯುವುದು ಬಹಳ ದೀರ್ಘವಾದ ಅಭಿವೃದ್ಧಿ ಪುನರಾವರ್ತನೆಗಳು ಮತ್ತು ಪರಿಷ್ಕರಣೆಯ ದೀರ್ಘ ಪುನರಾವರ್ತನೆಗಳಿಗೆ ಕಾರಣವಾಗುತ್ತದೆ ಎಂದು ಪದೇ ಪದೇ ಸಾಬೀತಾಗಿದೆ, ಏಕೆಂದರೆ ಪರೀಕ್ಷಾ ಪ್ರಕ್ರಿಯೆಯಲ್ಲಿ ದೋಷಗಳನ್ನು ಗುರುತಿಸಲಾಗುತ್ತದೆ ಮತ್ತು ಆದಾಯವು ಪ್ರಾರಂಭವಾಗುತ್ತದೆ. ಪರಿಣಾಮವಾಗಿ, ಅಭಿವೃದ್ಧಿ ವೆಚ್ಚವನ್ನು ಹೆಚ್ಚಿಸುವ ಬಹಳಷ್ಟು ಕುಣಿಕೆಗಳು ಇವೆ. ಹೆಚ್ಚುವರಿಯಾಗಿ, ಇದು ದುರ್ಬಲತೆಗಳನ್ನು ಪರಿಚಯಿಸಬಹುದು. ನಾವು ಉಲ್ಲೇಖ ಕೋಡ್ ಅನ್ನು ಬರೆದಿರುವಂತೆ ತೋರುತ್ತಿದೆ, ಆದರೆ ನಂತರ ನಾವು ಸಂಪೂರ್ಣವಾಗಿ ಯೋಚಿಸಿದ ವಾಸ್ತುಶಿಲ್ಪವನ್ನು ಮುರಿಯುವ ಬದಲಾವಣೆಗಳನ್ನು ಮಾಡಿದ್ದೇವೆ.

ಅಂತಿಮ ಫಲಿತಾಂಶವು ಸಂಪೂರ್ಣವಾಗಿ ಉತ್ತಮ-ಗುಣಮಟ್ಟದ ಉತ್ಪನ್ನವಲ್ಲ, ಏಕೆಂದರೆ ಆರ್ಕಿಟೆಕ್ಚರ್‌ನಲ್ಲಿ ಪ್ಯಾಚ್‌ಗಳು ಈಗಾಗಲೇ ಕಾಣಿಸಿಕೊಂಡಿವೆ, ಕೆಲವು ಸ್ಥಳಗಳಲ್ಲಿನ ಕೋಡ್ ಪರೀಕ್ಷೆಗಳಿಂದ ಸಾಕಷ್ಟು ಆವರಿಸಲ್ಪಟ್ಟಿಲ್ಲ, ಏಕೆಂದರೆ ಗಡುವು ಮುಗಿದಿದೆ, ಎಲ್ಲಾ ದೋಷಗಳನ್ನು ತ್ವರಿತವಾಗಿ ಮುಚ್ಚಬೇಕಾಗಿದೆ. ಮತ್ತು ಎಲ್ಲಾ ಏಕೆಂದರೆ ಮೂಲ ವಿವರಣೆಯು ಕಾರ್ಯಗತಗೊಳಿಸಬೇಕಾದ ಎಲ್ಲಾ ಅಂಶಗಳನ್ನು ಗಣನೆಗೆ ತೆಗೆದುಕೊಳ್ಳಲಿಲ್ಲ.

ಡೆವಲಪರ್‌ಗಳು ಕೀಟಗಳಲ್ಲ ಮತ್ತು ಉದ್ದೇಶಪೂರ್ವಕವಾಗಿ ದೋಷಗಳೊಂದಿಗೆ ಕೋಡ್ ಅನ್ನು ಬರೆಯಬೇಡಿ.

ಅಗತ್ಯವಿರುವ ಎಲ್ಲಾ ಅಂಶಗಳನ್ನು ಒಳಗೊಂಡಿರುವ ನಿರ್ದಿಷ್ಟತೆಯ ಮೂಲಕ ನಾವು ಆರಂಭದಲ್ಲಿ ಯೋಚಿಸಿದ್ದರೆ, ನಂತರ ಎಲ್ಲವನ್ನೂ ಅಗತ್ಯವಿರುವಂತೆ ನಿಖರವಾಗಿ ಕಾರ್ಯಗತಗೊಳಿಸಲಾಗುತ್ತದೆ. ಆದರೆ ಇದು ರಾಮರಾಜ್ಯ.

ಪರಿಪೂರ್ಣ 100-ಪುಟ ವಿವರಣೆಯನ್ನು ಬರೆಯುವುದು ಬಹುಶಃ ಅಸಾಧ್ಯ. ಅದಕ್ಕೇ ದಸ್ತಾವೇಜನ್ನು ಬರೆಯುವ ಪರ್ಯಾಯ ಮಾರ್ಗಗಳ ಬಗ್ಗೆ ಯೋಚಿಸಬೇಕು, ವಿಶೇಷಣಗಳು, ಡೆವಲಪರ್ ಅಗತ್ಯವಿರುವುದನ್ನು ನಿಖರವಾಗಿ ಮಾಡುತ್ತಾರೆ ಎಂದು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳಲು ನಮ್ಮನ್ನು ಹತ್ತಿರ ತರುವ ಕಾರ್ಯಗಳನ್ನು ಹೊಂದಿಸುವುದು.

ಇಲ್ಲಿ ಅಗೈಲ್‌ನ ವಿಧಾನಗಳು ಮನಸ್ಸಿಗೆ ಬರುತ್ತವೆ - ಸ್ವೀಕಾರ ಮಾನದಂಡಗಳೊಂದಿಗೆ ಬಳಕೆದಾರರ ಕಥೆಗಳು. ಸಣ್ಣ ಪುನರಾವರ್ತನೆಗಳಲ್ಲಿ ಅಭಿವೃದ್ಧಿಪಡಿಸುವ ತಂಡಗಳಿಗೆ ಇದು ಹೆಚ್ಚು ಅನ್ವಯಿಸುತ್ತದೆ.

— ಉಪಯುಕ್ತತೆ ಪರೀಕ್ಷೆ, ಉತ್ಪನ್ನ ಉಪಯುಕ್ತತೆ, ವಿನ್ಯಾಸದ ಬಗ್ಗೆ ಏನು?

ಅನಸ್ತಾಸಿಯಾ: ಇದು ಬಹಳ ಮುಖ್ಯವಾದ ಅಂಶವಾಗಿದೆ, ಏಕೆಂದರೆ ತಂಡದಲ್ಲಿ ವಿನ್ಯಾಸಕರು ಇದ್ದಾರೆ. ಹೆಚ್ಚಾಗಿ, ವಿನ್ಯಾಸಕರನ್ನು ಸೇವೆಯಾಗಿ ಬಳಸಲಾಗುತ್ತದೆ - ವಿನ್ಯಾಸ ವಿಭಾಗದಿಂದ ಅಥವಾ ಹೊರಗುತ್ತಿಗೆ ವಿನ್ಯಾಸಕರಿಂದ. ಡಿಸೈನರ್ ಉತ್ಪನ್ನ ತಜ್ಞರಿಗೆ ಕಿವಿಗೊಟ್ಟು ಅವನು ಅರ್ಥಮಾಡಿಕೊಂಡದ್ದನ್ನು ಮಾಡಿದನೆಂದು ತೋರುವ ಸಂದರ್ಭಗಳಿವೆ. ಆದರೆ ನಾವು ಪುನರಾವರ್ತನೆಯನ್ನು ಪ್ರಾರಂಭಿಸಿದಾಗ, ನಿಜವಾಗಿ ಏನು ಮಾಡಲ್ಪಟ್ಟಿದೆ ಎಂಬುದು ನಿರೀಕ್ಷಿತವಾಗಿಲ್ಲ ಎಂದು ಅದು ತಿರುಗುತ್ತದೆ: ಡಿಸೈನರ್ ಏನನ್ನಾದರೂ ಮರೆತಿದ್ದಾರೆ, ನಡವಳಿಕೆಯ ಮೂಲಕ ಸಂಪೂರ್ಣವಾಗಿ ಯೋಚಿಸಲಿಲ್ಲ, ಏಕೆಂದರೆ ಅವರು ತಂಡದಲ್ಲಿಲ್ಲ ಮತ್ತು ಸನ್ನಿವೇಶದಲ್ಲಿ ಅಥವಾ ಮುಂಭಾಗದಲ್ಲಿಲ್ಲ. -ಎಂಡ್ ಡೆವಲಪರ್ ಅದರ ವಿನ್ಯಾಸವನ್ನು ಸಂಪೂರ್ಣವಾಗಿ ಅರ್ಥಮಾಡಿಕೊಳ್ಳಲಿಲ್ಲ. ಮುಂಭಾಗದ ಡೆವಲಪರ್ ವಿನ್ಯಾಸವನ್ನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳುವಲ್ಲಿ ಸಮಸ್ಯೆ ಇರುವುದರಿಂದ ಇದು ಹಲವಾರು ಪುನರಾವರ್ತನೆಗಳನ್ನು ತೆಗೆದುಕೊಳ್ಳಬಹುದು.

ಜೊತೆಗೆ ಇನ್ನೂ ಒಂದು ಸಮಸ್ಯೆ ಇದೆ. ವಿನ್ಯಾಸ ವ್ಯವಸ್ಥೆಗಳು ಈಗ ಜನಪ್ರಿಯತೆಯನ್ನು ಗಳಿಸುತ್ತಿವೆ. ಅವರು ಪ್ರಚಾರದಲ್ಲಿದ್ದಾರೆ, ಆದರೆ ಅವುಗಳಿಂದ ಪ್ರಯೋಜನಗಳು ಸಂಪೂರ್ಣವಾಗಿ ಸ್ಪಷ್ಟವಾಗಿಲ್ಲ.

ವಿನ್ಯಾಸ ವ್ಯವಸ್ಥೆಗಳು, ಒಂದೆಡೆ, ಅಭಿವೃದ್ಧಿಯನ್ನು ಸರಳಗೊಳಿಸುತ್ತದೆ, ಆದರೆ ಮತ್ತೊಂದೆಡೆ, ಅವರು ಇಂಟರ್ಫೇಸ್ನಲ್ಲಿ ಬಹಳಷ್ಟು ನಿರ್ಬಂಧಗಳನ್ನು ವಿಧಿಸುತ್ತಾರೆ ಎಂಬ ಅಭಿಪ್ರಾಯವನ್ನು ನಾನು ಎದುರಿಸುತ್ತೇನೆ.

ಪರಿಣಾಮವಾಗಿ, ಕ್ಲೈಂಟ್ ಬಯಸಿದ ವೈಶಿಷ್ಟ್ಯವನ್ನು ನಾವು ಮಾಡುವುದಿಲ್ಲ, ಆದರೆ ನಮಗೆ ಅನುಕೂಲಕರವಾದದ್ದು, ಏಕೆಂದರೆ ನಾವು ಈಗಾಗಲೇ ಕೆಲವು ಘನಗಳನ್ನು ಹೊಂದಿದ್ದೇವೆ.

ವಿನ್ಯಾಸವನ್ನು ಸುಲಭಗೊಳಿಸಲು ಪ್ರಯತ್ನಿಸುವಾಗ ನಾವು ನಿಜವಾಗಿಯೂ ಕ್ಲೈಂಟ್ ನೋವಿನ ಬಿಂದುವನ್ನು ಪರಿಹರಿಸುತ್ತಿದ್ದೇವೆಯೇ ಎಂದು ಯೋಚಿಸಲು ಇದು ಯೋಗ್ಯವಾದ ವಿಷಯವಾಗಿದೆ ಎಂದು ನಾನು ಭಾವಿಸುತ್ತೇನೆ.

— ಗುಣಮಟ್ಟದ ಭರವಸೆಗೆ ಸಂಬಂಧಿಸಿದ ಆಶ್ಚರ್ಯಕರ ಸಂಖ್ಯೆಯ ವಿಷಯಗಳಿವೆ. ರಷ್ಯಾದಲ್ಲಿ ಅವರೆಲ್ಲರನ್ನೂ ಚರ್ಚಿಸಬಹುದಾದ ಸಮ್ಮೇಳನವಿದೆಯೇ?

ಅನಸ್ತಾಸಿಯಾ: ಅತ್ಯಂತ ಹಳೆಯ ಪರೀಕ್ಷಾ ಸಮ್ಮೇಳನವಿದೆ, ಇದನ್ನು ಈ ವರ್ಷ 25 ನೇ ಬಾರಿಗೆ ನಡೆಸಲಾಗುತ್ತದೆ ಮತ್ತು ಇದನ್ನು SQA ಡೇಸ್ ಕ್ವಾಲಿಟಿ ಅಶ್ಯೂರೆನ್ಸ್ ಕಾನ್ಫರೆನ್ಸ್ ಎಂದು ಕರೆಯಲಾಗುತ್ತದೆ. ಇದು ಮುಖ್ಯವಾಗಿ ಪರಿಕರಗಳು ಮತ್ತು ಕ್ರಿಯಾತ್ಮಕ ಪರೀಕ್ಷಕರಿಗೆ ನಿರ್ದಿಷ್ಟ ಪರೀಕ್ಷಾ ವಿಧಾನಗಳನ್ನು ಚರ್ಚಿಸುತ್ತದೆ. ನಿಯಮದಂತೆ, SQA ಡೇಸ್‌ನಲ್ಲಿನ ವರದಿಗಳು ಪರೀಕ್ಷಕರ ಜವಾಬ್ದಾರಿಯ ಪ್ರದೇಶದಲ್ಲಿ ನಿರ್ದಿಷ್ಟ ಪ್ರದೇಶಗಳನ್ನು ಆಳವಾಗಿ ಪರಿಶೀಲಿಸುತ್ತವೆ, ಆದರೆ ಸಂಕೀರ್ಣ ಚಟುವಟಿಕೆಗಳಲ್ಲ.

ವಿಭಿನ್ನ ಪರಿಕರಗಳು ಮತ್ತು ವಿಧಾನಗಳನ್ನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳಲು ಇದು ಬಹಳಷ್ಟು ಸಹಾಯ ಮಾಡುತ್ತದೆ, ಡೇಟಾಬೇಸ್‌ಗಳು, API ಗಳು ಇತ್ಯಾದಿಗಳನ್ನು ಪರೀಕ್ಷಿಸುವುದು ಹೇಗೆ. ಆದರೆ ಅದೇ ಸಮಯದಲ್ಲಿ, ಒಂದು ಕಡೆ, ಉತ್ತಮ ಉತ್ಪನ್ನದ ರಚನೆಯಲ್ಲಿ ಕೇವಲ ಪರೀಕ್ಷೆಗಿಂತ ಹೆಚ್ಚಿನದನ್ನು ಒಳಗೊಳ್ಳಲು ಇದು ಪ್ರೇರೇಪಿಸುವುದಿಲ್ಲ. ಮತ್ತೊಂದೆಡೆ, ಉತ್ಪನ್ನದ ಜಾಗತಿಕ ಗುರಿ ಮತ್ತು ಅದರ ವ್ಯಾಪಾರ ಘಟಕದ ಬಗ್ಗೆ ಯೋಚಿಸಲು ಪರೀಕ್ಷಕರು ಪ್ರಕ್ರಿಯೆಯಲ್ಲಿ ಹೆಚ್ಚು ತೊಡಗಿಸಿಕೊಳ್ಳುವುದಿಲ್ಲ.

ನಾನು ದೊಡ್ಡ ವಿಭಾಗವನ್ನು ನಡೆಸುತ್ತೇನೆ ಮತ್ತು ಒಟ್ಟಾರೆಯಾಗಿ ಉದ್ಯಮದ ಸ್ಥಿತಿಯ ಒಳನೋಟವನ್ನು ನೀಡುವ ಬಹಳಷ್ಟು ಸಂದರ್ಶನಗಳನ್ನು ನಡೆಸುತ್ತೇನೆ. ನಿಯಮದಂತೆ, ನಮ್ಮ ವ್ಯಕ್ತಿಗಳು ಉದ್ಯಮಗಳಲ್ಲಿ ಕೆಲಸ ಮಾಡುತ್ತಾರೆ ಮತ್ತು ಅವರು ಜವಾಬ್ದಾರಿಯ ಸ್ಪಷ್ಟ ಪ್ರದೇಶವನ್ನು ಹೊಂದಿದ್ದಾರೆ. ವಿದೇಶಿ ಯೋಜನೆಗಳಲ್ಲಿ ಕೆಲಸ ಮಾಡುವ ಸಹೋದ್ಯೋಗಿಗಳು ವಿವಿಧ ರೀತಿಯ ಪರೀಕ್ಷೆಗಳನ್ನು ಬಳಸುತ್ತಾರೆ: ಅವರು ಸ್ವತಃ ಲೋಡ್ ಪರೀಕ್ಷೆ, ಕಾರ್ಯಕ್ಷಮತೆ ಪರೀಕ್ಷೆ ಮತ್ತು ಕೆಲವೊಮ್ಮೆ ಭದ್ರತಾ ಪರೀಕ್ಷೆಯನ್ನು ಮಾಡಬಹುದು, ಏಕೆಂದರೆ ಅವರು ಉತ್ಪನ್ನದ ಗುಣಮಟ್ಟವನ್ನು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳಲು ತಂಡಕ್ಕೆ ನಿಜವಾಗಿಯೂ ಸಹಾಯ ಮಾಡುತ್ತಾರೆ.

ಉದ್ಯಮವು ಕ್ರಿಯಾತ್ಮಕ ಪರೀಕ್ಷೆಯೊಂದಿಗೆ ಕೊನೆಗೊಳ್ಳುವುದಿಲ್ಲ ಎಂದು ರಷ್ಯಾದ ಹುಡುಗರು ಯೋಚಿಸಲು ಪ್ರಾರಂಭಿಸಬೇಕೆಂದು ನಾನು ಬಯಸುತ್ತೇನೆ.

- ಈ ಉದ್ದೇಶಕ್ಕಾಗಿ, ನಾವು ಹೊಸ ಸಮ್ಮೇಳನವನ್ನು ಆಯೋಜಿಸುತ್ತಿದ್ದೇವೆ, ಕ್ವಾಲಿಟಿಕಾನ್ಫ್, ಇದು ಅವಿಭಾಜ್ಯ ಶಿಸ್ತಾಗಿ ಗುಣಮಟ್ಟಕ್ಕೆ ಸಮರ್ಪಿತವಾಗಿದೆ. ವಿಚಾರದ ಬಗ್ಗೆ ಹೆಚ್ಚಿನ ಮಾಹಿತಿ ತಿಳಿಸಿ, ಸಮ್ಮೇಳನದ ಮುಖ್ಯ ಗುರಿ ಏನು?

ಅನಸ್ತಾಸಿಯಾ: ನಾವು ಗುಣಮಟ್ಟದ ಉತ್ಪನ್ನಗಳನ್ನು ತಯಾರಿಸಲು ಆಸಕ್ತಿ ಹೊಂದಿರುವ ಜನರ ಸಮುದಾಯವನ್ನು ರಚಿಸಲು ಬಯಸುತ್ತೇವೆ. ಗುಣಮಟ್ಟವನ್ನು ಸುಧಾರಿಸಲು ಏನನ್ನು ಬದಲಾಯಿಸಬೇಕು ಎಂಬುದರ ಕುರಿತು ನಿರ್ದಿಷ್ಟ ತಿಳುವಳಿಕೆಯೊಂದಿಗೆ ಅವರು ಬರಲು, ವರದಿಗಳನ್ನು ಆಲಿಸಲು ಮತ್ತು ಸಮ್ಮೇಳನದ ನಂತರ ಹೊರಡಲು ವೇದಿಕೆಯನ್ನು ಒದಗಿಸಿ.

ಇತ್ತೀಚಿನ ದಿನಗಳಲ್ಲಿ ಪರೀಕ್ಷೆ ಮತ್ತು ಗುಣಮಟ್ಟದಲ್ಲಿ ಸಮಸ್ಯೆಗಳಿದ್ದಾಗ ಏನು ಮಾಡಬೇಕೆಂದು ಸಮಾಲೋಚಿಸುವ ವಿನಂತಿಯನ್ನು ನಾನು ಆಗಾಗ್ಗೆ ಕೇಳುತ್ತೇನೆ. ನೀವು ತಂಡಗಳೊಂದಿಗೆ ಸಂವಹನ ನಡೆಸಲು ಪ್ರಾರಂಭಿಸಿದಾಗ, ಸಮಸ್ಯೆಯು ಪರೀಕ್ಷಕರೊಂದಿಗೆ ಅಲ್ಲ, ಆದರೆ ಪ್ರಕ್ರಿಯೆಯು ಹೇಗೆ ರಚನೆಯಾಗಿದೆ ಎಂಬುದನ್ನು ನೀವು ನೋಡುತ್ತೀರಿ. ಉದಾಹರಣೆಗೆ, ಡೆವಲಪರ್‌ಗಳು ಕೋಡ್ ಬರೆಯಲು ಮಾತ್ರ ಜವಾಬ್ದಾರರು ಎಂದು ನಂಬಿದಾಗ, ಅವರು ಕೆಲಸವನ್ನು ಪರೀಕ್ಷೆಗೆ ಹಸ್ತಾಂತರಿಸಿದ ಕ್ಷಣದಲ್ಲಿ ಅವರ ಜವಾಬ್ದಾರಿಯು ಕೊನೆಗೊಳ್ಳುತ್ತದೆ.

ಕಳಪೆ ವಾಸ್ತುಶಿಲ್ಪದೊಂದಿಗೆ ಕಳಪೆಯಾಗಿ ಬರೆದ, ಕಡಿಮೆ-ಗುಣಮಟ್ಟದ ಕೋಡ್ ಯೋಜನೆಗೆ ದೊಡ್ಡ ಸಮಸ್ಯೆಗಳನ್ನು ಬೆದರಿಸುತ್ತದೆ ಎಂಬ ಅಂಶದ ಬಗ್ಗೆ ಎಲ್ಲರೂ ಯೋಚಿಸುವುದಿಲ್ಲ. ದೋಷಗಳ ವೆಚ್ಚದ ಬಗ್ಗೆ ಅವರು ಯೋಚಿಸುವುದಿಲ್ಲ, ಉತ್ಪಾದನೆಯಲ್ಲಿ ಕೊನೆಗೊಳ್ಳುವ ದೋಷಗಳು ಕಂಪನಿ ಮತ್ತು ತಂಡಕ್ಕೆ ದೊಡ್ಡ ವೆಚ್ಚವನ್ನು ಉಂಟುಮಾಡಬಹುದು. ಈ ಬಗ್ಗೆ ಯೋಚಿಸುವ ಸಂಸ್ಕೃತಿ ಇಲ್ಲ. ನಾವು ಅದನ್ನು ಸಮ್ಮೇಳನದಲ್ಲಿ ವಿತರಿಸಲು ಪ್ರಾರಂಭಿಸಬೇಕೆಂದು ನಾನು ಬಯಸುತ್ತೇನೆ.

ಇದು ನಾವೀನ್ಯತೆ ಅಲ್ಲ ಎಂದು ನಾನು ಅರ್ಥಮಾಡಿಕೊಂಡಿದ್ದೇನೆ.ಎಡ್ವರ್ಡ್ ಡೆಮಿಂಗ್, ಗುಣಮಟ್ಟದ 14 ತತ್ವಗಳ ಲೇಖಕ, ಕಳೆದ ಶತಮಾನದಲ್ಲಿ ದೋಷದ ವೆಚ್ಚದ ಬಗ್ಗೆ ಬರೆದಿದ್ದಾರೆ. ಒಂದು ಶಿಸ್ತಾಗಿ ಗುಣಮಟ್ಟದ ಭರವಸೆ ಈ ಪುಸ್ತಕವನ್ನು ಆಧರಿಸಿದೆ, ಆದರೆ, ದುರದೃಷ್ಟವಶಾತ್, ಆಧುನಿಕ ಅಭಿವೃದ್ಧಿಯು ಅದನ್ನು ಮರೆತುಬಿಡುತ್ತದೆ.

— ಪರೀಕ್ಷೆ ಮತ್ತು ಪರಿಕರಗಳ ಕುರಿತು ನೇರವಾಗಿ ವಿಷಯಗಳ ಮೇಲೆ ಸ್ಪರ್ಶಿಸಲು ನೀವು ಯೋಜಿಸುತ್ತೀರಾ?

ಅನಸ್ತಾಸಿಯಾ: ಪರಿಕರಗಳ ಬಗ್ಗೆ ವರದಿಗಳು ಇರುತ್ತವೆ ಎಂದು ನಾನು ಒಪ್ಪಿಕೊಳ್ಳುತ್ತೇನೆ. ಕಂಪನಿಗಳು ಮತ್ತು ತಂಡಗಳು ಉತ್ಪನ್ನದ ಮೇಲೆ ಪ್ರಭಾವ ಬೀರುವ ಸಾರ್ವತ್ರಿಕ ಸಾಧನಗಳಿವೆ.

ಎಲ್ಲಾ ವರದಿಗಳು ಜಾಗತಿಕವಾಗಿ ಒಂದು ಸಾಮಾನ್ಯ ಮಿಷನ್ ಮೂಲಕ ಏಕೀಕರಿಸಲ್ಪಡುತ್ತವೆ: ಈ ವಿಧಾನ, ಸಾಧನ, ವಿಧಾನ, ಪ್ರಕ್ರಿಯೆ, ಪರೀಕ್ಷೆಯ ಪ್ರಕಾರದ ಸಹಾಯದಿಂದ ನಾವು ಉತ್ಪನ್ನದ ಗುಣಮಟ್ಟವನ್ನು ಪ್ರಭಾವಿಸಿದ್ದೇವೆ ಮತ್ತು ಕ್ಲೈಂಟ್‌ನ ಜೀವನವನ್ನು ಸುಧಾರಿಸಿದ್ದೇವೆ ಎಂದು ಪ್ರೇಕ್ಷಕರಿಗೆ ತಿಳಿಸಲು.

ಉಪಕರಣದ ಸಲುವಾಗಿ ನಾವು ಖಂಡಿತವಾಗಿಯೂ ಉಪಕರಣದ ಕುರಿತು ವರದಿಗಳನ್ನು ಹೊಂದಿರುವುದಿಲ್ಲ. ಪ್ರೋಗ್ರಾಂನಲ್ಲಿ ಸೇರಿಸಲಾದ ಎಲ್ಲಾ ವರದಿಗಳು ಸಾಮಾನ್ಯ ಗುರಿಯಿಂದ ಒಂದಾಗುತ್ತವೆ.

- ನೀವು ಏನು ಮಾತನಾಡುತ್ತಿದ್ದೀರಿ ಎಂಬುದರ ಬಗ್ಗೆ ಯಾರು ಆಸಕ್ತಿ ವಹಿಸುತ್ತಾರೆ, ಸಮ್ಮೇಳನದ ಅತಿಥಿಗಳಾಗಿ ನೀವು ಯಾರನ್ನು ನೋಡುತ್ತೀರಿ?

ಅನಸ್ತಾಸಿಯಾ: ತಮ್ಮ ಪ್ರಾಜೆಕ್ಟ್, ಉತ್ಪನ್ನ, ವ್ಯವಸ್ಥೆಯ ಭವಿಷ್ಯದ ಬಗ್ಗೆ ಕಾಳಜಿವಹಿಸುವ ಡೆವಲಪರ್‌ಗಳಿಗಾಗಿ ನಾವು ವರದಿಗಳನ್ನು ಹೊಂದಿದ್ದೇವೆ. ಅಂತೆಯೇ, ಇದು ಪರೀಕ್ಷಕರಿಗೆ ಆಸಕ್ತಿಯಾಗಿರುತ್ತದೆ ಮತ್ತು ಇದು ನನಗೆ ತೋರುತ್ತದೆ, ವಿಶೇಷವಾಗಿ ವ್ಯವಸ್ಥಾಪಕರಿಗೆ. ನಿರ್ವಾಹಕರು ಎಂದರೆ, ನಿರ್ಧಾರಗಳನ್ನು ತೆಗೆದುಕೊಳ್ಳುವ ಜನರು ಮತ್ತು ಉತ್ಪನ್ನ, ವ್ಯವಸ್ಥೆ, ತಂಡದ ಭವಿಷ್ಯ ಮತ್ತು ಅಭಿವೃದ್ಧಿಯ ಮೇಲೆ ಪ್ರಭಾವ ಬೀರಬಹುದು.

ಉತ್ಪನ್ನ ಅಥವಾ ವ್ಯವಸ್ಥೆಯ ಗುಣಮಟ್ಟವನ್ನು ಹೇಗೆ ಸುಧಾರಿಸುವುದು ಎಂದು ಆಶ್ಚರ್ಯಪಡುವ ಜನರು ಇವರು. ನಮ್ಮ ಸಮ್ಮೇಳನದಲ್ಲಿ, ಅವರು ವಿವಿಧ ಕ್ರಮಗಳ ಬಗ್ಗೆ ಕಲಿಯುತ್ತಾರೆ ಮತ್ತು ಈಗ ಅವರಲ್ಲಿ ಏನು ತಪ್ಪಾಗಿದೆ ಮತ್ತು ಏನನ್ನು ಬದಲಾಯಿಸಬೇಕಾಗಿದೆ ಎಂಬುದನ್ನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳಲು ಸಾಧ್ಯವಾಗುತ್ತದೆ.

ಗುಣಮಟ್ಟದಲ್ಲಿ ಏನಾದರೂ ತಪ್ಪಾಗಿದೆ ಮತ್ತು ಅದರ ಮೇಲೆ ಪ್ರಭಾವ ಬೀರಲು ಬಯಸುವುದನ್ನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳುವುದು ಮುಖ್ಯ ಮಾನದಂಡವಾಗಿದೆ ಎಂದು ನಾನು ಭಾವಿಸುತ್ತೇನೆ. ಇದು ಮೊದಲ ಬಾರಿಗೆ ಆಗುತ್ತದೆ ಎಂದು ಭಾವಿಸುವ ಜನರನ್ನು ತಲುಪಲು ನಮಗೆ ಬಹುಶಃ ಸಾಧ್ಯವಾಗುವುದಿಲ್ಲ.

- ಒಟ್ಟಾರೆಯಾಗಿ ಉದ್ಯಮವು ಪರೀಕ್ಷೆಯ ಬಗ್ಗೆ ಮಾತ್ರವಲ್ಲ, ಗುಣಮಟ್ಟದ ಸಂಸ್ಕೃತಿಯ ಬಗ್ಗೆ ಮಾತನಾಡಲು ಪ್ರಬುದ್ಧವಾಗಿದೆ ಎಂದು ನೀವು ಭಾವಿಸುತ್ತೀರಾ?

ಅನಸ್ತಾಸಿಯಾ: ನಾನು ಪ್ರಬುದ್ಧನಾಗಿದ್ದೇನೆ ಎಂದು ನಾನು ಭಾವಿಸುತ್ತೇನೆ. ಈಗ ಅನೇಕ ಕಂಪನಿಗಳು ಸಾಂಪ್ರದಾಯಿಕ ಜಲಪಾತದ ವಿಧಾನದಿಂದ ಅಗೈಲ್ ಕಡೆಗೆ ಚಲಿಸುತ್ತಿವೆ. ಗ್ರಾಹಕರ ಗಮನವಿದೆ, ತಂಡಗಳಲ್ಲಿನ ಜನರು ನಿಜವಾಗಿಯೂ ಗುಣಮಟ್ಟದ ಉತ್ಪನ್ನವನ್ನು ಹೇಗೆ ರಚಿಸುವುದು ಎಂಬುದರ ಕುರಿತು ಯೋಚಿಸಲು ಪ್ರಾರಂಭಿಸುತ್ತಿದ್ದಾರೆ. ಎಂಟರ್‌ಪ್ರೈಸ್ ಕಂಪನಿಗಳು ಸಹ ಗುಣಮಟ್ಟವನ್ನು ಸುಧಾರಿಸುವತ್ತ ಗಮನಹರಿಸುತ್ತಿವೆ.

ಸಮುದಾಯದಲ್ಲಿ ಉದ್ಭವಿಸುವ ವಿನಂತಿಗಳ ಸಂಖ್ಯೆಯಿಂದ ನಿರ್ಣಯಿಸುವುದು, ಇದು ಸಮಯ ಎಂದು ನಾನು ನಂಬುತ್ತೇನೆ. ಇದು ದೊಡ್ಡ ಪ್ರಮಾಣದ ಕ್ರಾಂತಿಯಾಗಲಿದೆ ಎಂದು ನನಗೆ ಖಚಿತವಿಲ್ಲ, ಆದರೆ ಪ್ರಜ್ಞೆಯಲ್ಲಿ ಈ ಕ್ರಾಂತಿ ಸಂಭವಿಸಬೇಕೆಂದು ನಾನು ಬಯಸುತ್ತೇನೆ.

- ಒಪ್ಪಿದೆ! ನಾವು ಸಂಸ್ಕೃತಿಯನ್ನು ಹುಟ್ಟುಹಾಕುತ್ತೇವೆ ಮತ್ತು ಪ್ರಜ್ಞೆಯನ್ನು ಬದಲಾಯಿಸುತ್ತೇವೆ.

ಐಟಿ ಉತ್ಪನ್ನಗಳ ಉನ್ನತ-ಗುಣಮಟ್ಟದ ಅಭಿವೃದ್ಧಿ ಕುರಿತು ಸಮ್ಮೇಳನ ಗುಣಮಟ್ಟ ಕಾನ್ಫ್ ನಡೆಯಲಿದೆ ಜೂನ್ 7 ರಂದು ಮಾಸ್ಕೋದಲ್ಲಿ. ಉತ್ತಮ ಗುಣಮಟ್ಟದ ಉತ್ಪನ್ನವನ್ನು ಯಾವ ಹಂತಗಳು ರೂಪಿಸುತ್ತವೆ ಎಂದು ನಿಮಗೆ ತಿಳಿದಿದೆ, ಉತ್ಪಾದನೆಯಲ್ಲಿ ದೋಷಗಳನ್ನು ಯಶಸ್ವಿಯಾಗಿ ಎದುರಿಸುವ ಪ್ರಕರಣಗಳನ್ನು ನಾವು ಹೊಂದಿದ್ದೇವೆ, ನಮ್ಮ ಅಭ್ಯಾಸದಲ್ಲಿ ನಾವು ಜನಪ್ರಿಯ ವಿಧಾನಗಳನ್ನು ಪರೀಕ್ಷಿಸಿದ್ದೇವೆ - ನಮಗೆ ನಿಮ್ಮ ಅನುಭವ ಬೇಕು. ಕಳುಹಿಸು ತಮ್ಮ ಮೇ 1 ರ ಮೊದಲು ಅರ್ಜಿಗಳು, ಮತ್ತು ಕಾರ್ಯಕ್ರಮ ಸಮಿತಿಯು ಸಮ್ಮೇಳನದ ಒಟ್ಟಾರೆ ಸಮಗ್ರತೆಗಾಗಿ ಥೀಮ್ ಅನ್ನು ಕೇಂದ್ರೀಕರಿಸಲು ಸಹಾಯ ಮಾಡುತ್ತದೆ.

ಗೆ ಸಂಪರ್ಕಪಡಿಸಿ ಚಾಟ್, ಇದರಲ್ಲಿ ನಾವು ಗುಣಮಟ್ಟದ ಸಮಸ್ಯೆಗಳು ಮತ್ತು ಸಮ್ಮೇಳನವನ್ನು ಚರ್ಚಿಸುತ್ತೇವೆ, ಚಂದಾದಾರರಾಗಿ ಟೆಲಿಗ್ರಾಮ್ ಚಾನಲ್ಕಾರ್ಯಕ್ರಮದ ಸುದ್ದಿಗಳೊಂದಿಗೆ ನವೀಕೃತವಾಗಿರಲು.

ಮೂಲ: www.habr.com