ಈ ಲೇಖನದಲ್ಲಿ, ನಮ್ಮ ಉತ್ಪನ್ನಗಳ ಕ್ರಿಯಾತ್ಮಕತೆಯನ್ನು ಅಭಿವೃದ್ಧಿಪಡಿಸುವ ಕಲ್ಪನೆಗಳನ್ನು ಆಯ್ಕೆಮಾಡುವಲ್ಲಿ ನನ್ನ ಅನುಭವವನ್ನು ನಾನು ಹಂಚಿಕೊಳ್ಳುತ್ತೇನೆ ಮತ್ತು ಅಭಿವೃದ್ಧಿಯ ಮುಖ್ಯ ವಾಹಕಗಳನ್ನು ಹೇಗೆ ನಿರ್ವಹಿಸುವುದು ಎಂದು ಹೇಳುತ್ತೇನೆ.
ನಾವು ಸ್ವಯಂಚಾಲಿತ ವಸಾಹತು ವ್ಯವಸ್ಥೆ (ACP) - ಬಿಲ್ಲಿಂಗ್ ಅನ್ನು ಅಭಿವೃದ್ಧಿಪಡಿಸುತ್ತಿದ್ದೇವೆ. ಅವಧಿ
ನಮ್ಮ ಉತ್ಪನ್ನದ ಜೀವನವು 14 ವರ್ಷಗಳು. ಈ ಸಮಯದಲ್ಲಿ, ವ್ಯವಸ್ಥೆಯು ಕೈಗಾರಿಕಾ ಸುಂಕದ ವ್ಯವಸ್ಥೆಯ ಮೊದಲ ಆವೃತ್ತಿಗಳಿಂದ ಪರಸ್ಪರ ಪೂರಕವಾಗಿರುವ 18 ಉತ್ಪನ್ನಗಳನ್ನು ಒಳಗೊಂಡಿರುವ ಮಾಡ್ಯುಲರ್ ಸಂಕೀರ್ಣಕ್ಕೆ ವಿಕಸನಗೊಂಡಿದೆ. ಕಾರ್ಯಕ್ರಮಗಳಿಗೆ ದೀರ್ಘಾಯುಷ್ಯದ ಪ್ರಮುಖ ಅಂಶವೆಂದರೆ ನಿರಂತರ ಅಭಿವೃದ್ಧಿ. ಮತ್ತು ಅಭಿವೃದ್ಧಿಗೆ ಕಲ್ಪನೆಗಳು ಬೇಕಾಗುತ್ತವೆ.
ಐಡಿಯಾಸ್
ಮೂಲಗಳು
5 ಮೂಲಗಳಿವೆ:
- ಕಾರ್ಪೊರೇಟ್ ಮಾಹಿತಿ ವ್ಯವಸ್ಥೆಗಳ ಡೆವಲಪರ್‌ನ ಮುಖ್ಯ ಸ್ನೇಹಿತ ಗ್ರಾಹಕ. ಮತ್ತು ಕ್ಲೈಂಟ್ ಎನ್ನುವುದು ನಿರ್ಧಾರ ತೆಗೆದುಕೊಳ್ಳುವವರು, ಪ್ರಾಜೆಕ್ಟ್ ಪ್ರಾಯೋಜಕರು, ಮಾಲೀಕರು ಮತ್ತು ಪ್ರಕ್ರಿಯೆಗಳ ನಿರ್ವಾಹಕರು, ಆಂತರಿಕ ಐಟಿ ತಜ್ಞರು, ಸಾಮಾನ್ಯ ಬಳಕೆದಾರರು ಮತ್ತು ವಿವಿಧ ಹಂತಗಳಲ್ಲಿ ಹೆಚ್ಚಿನ ಸಂಖ್ಯೆಯ ಆಸಕ್ತಿ ಹೊಂದಿರುವ ವ್ಯಕ್ತಿಗಳ ಸಾಮೂಹಿಕ ಚಿತ್ರಣವಾಗಿದೆ. ಕ್ಲೈಂಟ್ನ ಪ್ರತಿಯೊಬ್ಬ ಪ್ರತಿನಿಧಿಗಳು ಸಂಭಾವ್ಯವಾಗಿ ಕಲ್ಪನೆಗಳ ಪೂರೈಕೆದಾರರಾಗಿದ್ದಾರೆ ಎಂಬುದು ನಮಗೆ ಮುಖ್ಯವಾಗಿದೆ. ಕೆಟ್ಟ ಸಂದರ್ಭದಲ್ಲಿ, ನಾವು ವ್ಯವಸ್ಥೆಯಲ್ಲಿನ ಸಮಸ್ಯೆಗಳ ಬಗ್ಗೆ ನಕಾರಾತ್ಮಕ ಪ್ರತಿಕ್ರಿಯೆಯನ್ನು ಮಾತ್ರ ಸ್ವೀಕರಿಸುತ್ತೇವೆ. ಉತ್ತಮ ಸಂದರ್ಭದಲ್ಲಿ, ಕ್ಲೈಂಟ್ನ ಬದಿಯಲ್ಲಿ ಒಬ್ಬ ವ್ಯಕ್ತಿಯು ಸುಧಾರಣೆಗಾಗಿ ಆಲೋಚನೆಗಳ ನಿರಂತರ ಮೂಲವಾಗಿದೆ, ಕ್ಲೈಂಟ್ನ ಅಗತ್ಯತೆಗಳ ಬಗ್ಗೆ ರಚನಾತ್ಮಕ ಮಾಹಿತಿಯನ್ನು ಒದಗಿಸುತ್ತದೆ.
- ನಮ್ಮ ಮಾರಾಟಗಾರರು ಮತ್ತು ಖಾತೆ ವ್ಯವಸ್ಥಾಪಕರು ಸುಧಾರಣೆಯ ವಿಚಾರಗಳ ಎರಡನೇ ಪ್ರಮುಖ ಮೂಲವಾಗಿದೆ. ಅವರು ಉದ್ಯಮದ ಪ್ರತಿನಿಧಿಗಳೊಂದಿಗೆ ಸಕ್ರಿಯವಾಗಿ ಮತ್ತು ವ್ಯಾಪಕವಾಗಿ ಸಂವಹನ ನಡೆಸುತ್ತಾರೆ ಮತ್ತು ಸಂಭಾವ್ಯ ಗ್ರಾಹಕರಿಂದ ಬಿಲ್ಲಿಂಗ್ ಕಾರ್ಯನಿರ್ವಹಣೆಯ ಬಗ್ಗೆ ಮೊದಲ-ಕೈ ವಿಚಾರಣೆಗಳನ್ನು ಸ್ವೀಕರಿಸುತ್ತಾರೆ. ಮಾರಾಟಗಾರರು ಮತ್ತು ಖಾತೆಗಳು ತಮ್ಮ ಕಾರ್ಯಚಟುವಟಿಕೆಗಳಲ್ಲಿನ ಎಲ್ಲಾ ಗಮನಾರ್ಹ ಬದಲಾವಣೆಗಳು ಮತ್ತು ಸ್ಪರ್ಧಿಗಳ ಸಾಫ್ಟ್‌ವೇರ್‌ಗೆ ಇತ್ತೀಚಿನ ನವೀಕರಣಗಳ ಬಗ್ಗೆ ತಿಳಿದಿರಬೇಕು ಮತ್ತು ವಿಭಿನ್ನ ಪರಿಹಾರಗಳ ಸಾಧಕ-ಬಾಧಕಗಳನ್ನು ಸಮರ್ಥಿಸಲು ಸಾಧ್ಯವಾಗುತ್ತದೆ. ಕೆಲವು ಬಿಲ್ಲಿಂಗ್ ಸಾಮರ್ಥ್ಯಗಳು ವಸ್ತುತಃ ಸ್ಟ್ಯಾಂಡರ್ಡ್ ಆಗಿದ್ದರೆ, ಅದು ಇಲ್ಲದೆ ಸಾಫ್ಟ್‌ವೇರ್ ಅನ್ನು ಸಂಪೂರ್ಣವೆಂದು ಪರಿಗಣಿಸಲಾಗುವುದಿಲ್ಲ ಎಂಬುದನ್ನು ಮೊದಲು ಗ್ರಹಿಸುವವರು ನಮ್ಮ ಉದ್ಯೋಗಿಗಳು.
- ಉತ್ಪನ್ನ ಮಾಲೀಕರು - ನಮ್ಮ ಉನ್ನತ ವ್ಯವಸ್ಥಾಪಕರಲ್ಲಿ ಒಬ್ಬರು ಅಥವಾ ಅತ್ಯಂತ ಅನುಭವಿ ಪ್ರಾಜೆಕ್ಟ್ ಮ್ಯಾನೇಜರ್. ಕಂಪನಿಯ ಕಾರ್ಯತಂತ್ರದ ಗುರಿಗಳನ್ನು ಮನಸ್ಸಿನಲ್ಲಿಟ್ಟುಕೊಳ್ಳುತ್ತದೆ ಮತ್ತು ಅವುಗಳಿಗೆ ಅನುಗುಣವಾಗಿ ಉತ್ಪನ್ನ ಅಭಿವೃದ್ಧಿ ಯೋಜನೆಗಳನ್ನು ಹೊಂದಿಸುತ್ತದೆ.
- ವಾಸ್ತುಶಿಲ್ಪಿ, ಆಯ್ಕೆ ಮಾಡಿದ/ಬಳಸಿದ ತಂತ್ರಜ್ಞಾನ ಪರಿಹಾರಗಳ ಸಾಮರ್ಥ್ಯಗಳು ಮತ್ತು ಮಿತಿಗಳನ್ನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳುವ ವ್ಯಕ್ತಿ ಮತ್ತು ಉತ್ಪನ್ನ ಅಭಿವೃದ್ಧಿಯ ಮೇಲೆ ಅವುಗಳ ಪ್ರಭಾವ.
ಅಭಿವೃದ್ಧಿ ಮತ್ತು ಪರೀಕ್ಷಾ ತಂಡಗಳು. ಉತ್ಪನ್ನ ಅಭಿವೃದ್ಧಿಯಲ್ಲಿ ನೇರವಾಗಿ ತೊಡಗಿಸಿಕೊಂಡಿರುವ ಜನರು.
ವಿನಂತಿಗಳ ವರ್ಗೀಕರಣ
ನಾವು ಮೂಲಗಳಿಂದ ಕಚ್ಚಾ ಡೇಟಾವನ್ನು ಸ್ವೀಕರಿಸುತ್ತೇವೆ - ಪತ್ರಗಳು, ಟಿಕೆಟ್‌ಗಳು, ಮೌಖಿಕ ವಿನಂತಿಗಳು. ಎಲ್ಲಾ
ಮನವಿಗಳನ್ನು ವರ್ಗೀಕರಿಸಲಾಗಿದೆ:
- ಕನ್ಸಲ್ಟಿಂಗ್ "ಅದನ್ನು ಹೇಗೆ ಮಾಡುವುದು?", "ಅದು ಹೇಗೆ ಕೆಲಸ ಮಾಡುತ್ತದೆ?", "ಅದು ಏಕೆ ಕೆಲಸ ಮಾಡುವುದಿಲ್ಲ?", "ನನಗೆ ಅರ್ಥವಾಗುತ್ತಿಲ್ಲ ..." ಎಂಬ ಅರ್ಥದೊಂದಿಗೆ. ಈ ಪ್ರಕಾರದ ವಿನಂತಿಗಳು ಹಂತ 1 ಬೆಂಬಲ ಸಾಲಿಗೆ ಹೋಗುತ್ತವೆ. ಸಮಾಲೋಚನೆಯನ್ನು ಇತರ ರೀತಿಯ ವಿನಂತಿಗಳಿಗೆ ಮರುತರಬೇತಿ ಮಾಡಲು ಸಾಧ್ಯವಿದೆ.
- ಘಟನೆಗಳು "ಕೆಲಸ ಮಾಡುವುದಿಲ್ಲ" ಮತ್ತು "ದೋಷ" ಎಂಬ ಅರ್ಥದೊಂದಿಗೆ. 2 ಮತ್ತು 3 ಬೆಂಬಲ ಸಾಲುಗಳಿಂದ ಸಂಸ್ಕರಿಸಲಾಗಿದೆ. ಪ್ರಾಂಪ್ಟ್ ತಿದ್ದುಪಡಿಗಳು ಮತ್ತು ಪ್ಯಾಚ್ ಬಿಡುಗಡೆ ಅಗತ್ಯವಿದ್ದರೆ, ಅವುಗಳನ್ನು ಬೆಂಬಲದಿಂದ ನೇರವಾಗಿ ಅಭಿವೃದ್ಧಿಗೆ ವರ್ಗಾಯಿಸಬಹುದು. ಇದನ್ನು ಬದಲಾವಣೆಯ ವಿನಂತಿಯಾಗಿ ಮರುವರ್ಗೀಕರಿಸಲು ಮತ್ತು ಬ್ಯಾಕ್‌ಲಾಗ್‌ಗೆ ಕಳುಹಿಸಲು ಸಾಧ್ಯವಿದೆ.
- ಬದಲಾವಣೆಗಳು ಮತ್ತು ಅಭಿವೃದ್ಧಿಗಾಗಿ ವಿನಂತಿಗಳು. ಅವರು ಬೆಂಬಲ ರೇಖೆಗಳನ್ನು ಬೈಪಾಸ್ ಮಾಡುವ ಮೂಲಕ ಉತ್ಪನ್ನ ಬ್ಯಾಕ್‌ಲಾಗ್‌ಗೆ ಹೋಗುತ್ತಾರೆ. ಆದರೆ ಅವುಗಳಿಗೆ ಪ್ರತ್ಯೇಕ ಸಂಸ್ಕರಣಾ ವಿಧಾನವಿದೆ.
ವಿನಂತಿಗಳ ಮೇಲೆ ಅಂಕಿಅಂಶಗಳಿವೆ: ಬಿಡುಗಡೆಯ ನಂತರ, ವಿನಂತಿಗಳ ಸಂಖ್ಯೆಯು ಅಲ್ಪಾವಧಿಗೆ 10-15% ರಷ್ಟು ಹೆಚ್ಚಾಗುತ್ತದೆ. ಹೆಚ್ಚಿನ ಸಂಖ್ಯೆಯ ಬಳಕೆದಾರರನ್ನು ಹೊಂದಿರುವ ಹೊಸ ಕ್ಲೈಂಟ್ ನಮ್ಮ ಕ್ಲೌಡ್ ಸೇವೆಗಳಿಗೆ ಬಂದಾಗ ವಿನಂತಿಗಳಲ್ಲಿ ಉಲ್ಬಣಗಳಿವೆ. ಜನರು ಹೊಸ ಸಾಫ್ಟ್‌ವೇರ್ ಸಾಮರ್ಥ್ಯಗಳನ್ನು ಬಳಸಲು ಕಲಿಯುತ್ತಿದ್ದಾರೆ, ಅವರಿಗೆ ಸಲಹೆಯ ಅಗತ್ಯವಿದೆ. ಸಣ್ಣ ಕ್ಲೈಂಟ್ ಕೂಡ, ಸಿಸ್ಟಮ್ನಲ್ಲಿ ಕೆಲಸ ಮಾಡಲು ಪ್ರಾರಂಭಿಸಿದಾಗ, ತಿಂಗಳಿಗೆ 100 ಗಂಟೆಗಳ ಸಮಾಲೋಚನೆಗಳನ್ನು ಸುಲಭವಾಗಿ ಸುಡುತ್ತದೆ. ಆದ್ದರಿಂದ, ಹೊಸ ಕ್ಲೈಂಟ್ ಅನ್ನು ಸಂಪರ್ಕಿಸುವಾಗ, ನಾವು ಯಾವಾಗಲೂ ಆರಂಭಿಕ ಸಮಾಲೋಚನೆಗಳಿಗಾಗಿ ಸಮಯವನ್ನು ಕಾಯ್ದಿರಿಸುತ್ತೇವೆ. ಆಗಾಗ್ಗೆ ನಾವು ನಿರ್ದಿಷ್ಟ ತಜ್ಞರನ್ನು ಸಹ ಆಯ್ಕೆ ಮಾಡುತ್ತೇವೆ. ಬಾಡಿಗೆ ಬೆಲೆ, ಸಹಜವಾಗಿ, ಈ ಕಾರ್ಮಿಕ ವೆಚ್ಚಗಳನ್ನು ಒಳಗೊಂಡಿರುವುದಿಲ್ಲ, ಆದರೆ ಕಾಲಾನಂತರದಲ್ಲಿ ಪರಿಸ್ಥಿತಿಯು ಸಮನಾಗಿರುತ್ತದೆ. ಹೊಂದಾಣಿಕೆಯ ಅವಧಿಯು ಸಾಮಾನ್ಯವಾಗಿ 1 ರಿಂದ 3 ತಿಂಗಳವರೆಗೆ ತೆಗೆದುಕೊಳ್ಳುತ್ತದೆ, ಅದರ ನಂತರ ಸಮಾಲೋಚನೆಯ ಅಗತ್ಯವು ಗಮನಾರ್ಹವಾಗಿ ಕಡಿಮೆಯಾಗುತ್ತದೆ.
ಹಿಂದೆ, ವಿನಂತಿಗಳನ್ನು ಸಂಗ್ರಹಿಸಲು ನಾವು ಸ್ವಯಂ-ಲಿಖಿತ ಪರಿಹಾರಗಳನ್ನು ಬಳಸಿದ್ದೇವೆ. ಆದರೆ ನಾವು ಕ್ರಮೇಣ ಅಟ್ಲಾಸಿಯನ್ ಉತ್ಪನ್ನಗಳಿಗೆ ಬದಲಾಯಿಸಿದ್ದೇವೆ. ಮೊದಲಿಗೆ, ಅಗೈಲ್ ಪ್ರಕಾರ ಕೆಲಸ ಮಾಡಲು ಸುಲಭವಾಗುವಂತೆ ನಾವು ಅಭಿವೃದ್ಧಿಯನ್ನು ವರ್ಗಾಯಿಸಿದ್ದೇವೆ, ನಂತರ ಬೆಂಬಲ. ಈಗ ಎಲ್ಲಾ ನಿರ್ಣಾಯಕ ಪ್ರಕ್ರಿಯೆಗಳು ಜಿರಾ ಎಸ್‌ಡಿಯಲ್ಲಿ ವಾಸಿಸುತ್ತವೆ, ಜೊತೆಗೆ ಅವುಗಳನ್ನು ಜಿರಾ ಮತ್ತು ಸಂಗಮಕ್ಕಾಗಿ ವಿವಿಧ ಪ್ಲಗಿನ್‌ಗಳು ಬೆಂಬಲಿಸುತ್ತವೆ. ಸ್ವಯಂ-ಲಿಖಿತ ಪರಿಹಾರಗಳು ಕಂಪನಿಯ ಚಟುವಟಿಕೆಗಳಿಗೆ ನಿರ್ಣಾಯಕವಲ್ಲದ ಪ್ರಕ್ರಿಯೆಗಳಿಗೆ ಮಾತ್ರ ಉಳಿದಿವೆ. ನಮ್ಮ ಕಾರ್ಯಗಳು ಈಗ ಅಡ್ಡ-ಕತ್ತರಿಸುತ್ತಿವೆ ಮತ್ತು ಒಂದು ವ್ಯವಸ್ಥೆಯಿಂದ ಇನ್ನೊಂದಕ್ಕೆ ಜಿಗಿಯದೆಯೇ ಬೆಂಬಲ ಮತ್ತು ಅಭಿವೃದ್ಧಿಯ ನಡುವೆ ವರ್ಗಾಯಿಸಬಹುದು ಎಂದು ಅದು ತಿರುಗುತ್ತದೆ.
ಈ ಲಿಂಕ್‌ನಿಂದ ನಾವು ಎಲ್ಲಾ ಕಾರ್ಯಗಳು, ಯೋಜಿತ ಮತ್ತು ನಿಜವಾದ ಕಾರ್ಮಿಕ ವೆಚ್ಚಗಳ ಡೇಟಾವನ್ನು ಪಡೆಯಬಹುದು, ಗ್ರಾಹಕರಿಗೆ ವಿವಿಧ ಬೆಲೆ ಆಯ್ಕೆಗಳನ್ನು ಬಳಸಬಹುದು ಮತ್ತು ಆಂತರಿಕ ಅಗತ್ಯಗಳಿಗಾಗಿ ದಾಖಲಾತಿಗಳನ್ನು ರಚಿಸಬಹುದು ಮತ್ತು ಗ್ರಾಹಕರಿಗೆ ವರದಿ ಮಾಡಬಹುದು.
ಬದಲಾವಣೆ ವಿನಂತಿಗಳನ್ನು ಪ್ರಕ್ರಿಯೆಗೊಳಿಸಲಾಗುತ್ತಿದೆ
ವಿಶಿಷ್ಟವಾಗಿ, ಅಂತಹ ವಿನಂತಿಗಳು ಕ್ರಿಯಾತ್ಮಕತೆಯ ಅಗತ್ಯತೆಗಳ ರೂಪದಲ್ಲಿ ಬರುತ್ತವೆ. ನಮ್ಮ ವಿಶ್ಲೇಷಕರು ವಿನಂತಿಯನ್ನು ಅಧ್ಯಯನ ಮಾಡುತ್ತಾರೆ, ನಿರ್ದಿಷ್ಟತೆ ಮತ್ತು ಉನ್ನತ ಮಟ್ಟದ ತಾಂತ್ರಿಕ ವಿಶೇಷಣಗಳನ್ನು ರಚಿಸುತ್ತಾರೆ. ಅನುಮೋದನೆಗಾಗಿ ಈ ವಿನಂತಿಯನ್ನು ಸಲ್ಲಿಸಿದ ವ್ಯಕ್ತಿಗೆ ನಿರ್ದಿಷ್ಟತೆ ಮತ್ತು ತಾಂತ್ರಿಕ ವಿಶೇಷಣಗಳನ್ನು ವರ್ಗಾಯಿಸುತ್ತದೆ - ನಾವು ಗ್ರಾಹಕರೊಂದಿಗೆ ಒಂದೇ ಭಾಷೆಯನ್ನು ಮಾತನಾಡುತ್ತೇವೆ ಎಂದು ನಾವು ಖಚಿತವಾಗಿರಬೇಕು.
ನಾವು ಪರಸ್ಪರ ಸರಿಯಾಗಿ ಅರ್ಥಮಾಡಿಕೊಂಡಿದ್ದೇವೆ ಎಂದು ಗ್ರಾಹಕರಿಂದ ದೃಢೀಕರಣವನ್ನು ಸ್ವೀಕರಿಸಿದ ನಂತರ, ವಿಶ್ಲೇಷಕರು ವಿನಂತಿಯನ್ನು ಉತ್ಪನ್ನ ಬ್ಯಾಕ್‌ಲಾಗ್‌ಗೆ ನಮೂದಿಸುತ್ತಾರೆ.
ಉತ್ಪನ್ನ ಕಾರ್ಯ ನಿರ್ವಹಣೆ
ಬ್ಯಾಕ್‌ಲಾಗ್ ಬದಲಾವಣೆ ಮತ್ತು ಅಭಿವೃದ್ಧಿಗಾಗಿ ಒಳಬರುವ ವಿನಂತಿಗಳನ್ನು ಸಂಗ್ರಹಿಸುತ್ತದೆ. ನಿರ್ದೇಶಕರು, ಬೆಂಬಲ, ಅಭಿವೃದ್ಧಿ, ಮಾರಾಟ ಮತ್ತು ಸಿಸ್ಟಮ್ ಆರ್ಕಿಟೆಕ್ಟ್ ಮುಖ್ಯಸ್ಥರನ್ನು ಒಳಗೊಂಡಿರುವ ತಾಂತ್ರಿಕ ಮಂಡಳಿಯು ಪ್ರತಿ ಆರು ತಿಂಗಳಿಗೊಮ್ಮೆ ಸಭೆ ಸೇರುತ್ತದೆ. ಚರ್ಚೆಯ ಸ್ವರೂಪದಲ್ಲಿ, ಕೌನ್ಸಿಲ್ ಬ್ಯಾಕ್‌ಲಾಗ್‌ನಿಂದ ಅಪ್ಲಿಕೇಶನ್‌ಗಳನ್ನು ವಿಶ್ಲೇಷಿಸುತ್ತದೆ ಮತ್ತು ಆದ್ಯತೆ ನೀಡುತ್ತದೆ ಮತ್ತು ಮುಂದಿನ ಬಿಡುಗಡೆಯಲ್ಲಿ ಅನುಷ್ಠಾನಕ್ಕಾಗಿ 5 ಅಭಿವೃದ್ಧಿ ಕಾರ್ಯಗಳನ್ನು ಒಪ್ಪಿಕೊಳ್ಳುತ್ತದೆ.
ವಾಸ್ತವವಾಗಿ, ತಾಂತ್ರಿಕ ಮಂಡಳಿಯು ಉದ್ಯಮ ಮತ್ತು ಮಾರುಕಟ್ಟೆ ಬೇಡಿಕೆಗಳಿಗೆ ಅನ್ವಯಗಳಲ್ಲಿ ವ್ಯಕ್ತಪಡಿಸಿದ ಅಗತ್ಯಗಳನ್ನು ಪರಿಶೀಲಿಸುವ ಮೂಲಕ ಪ್ರತಿಕ್ರಿಯಿಸುತ್ತದೆ. ಕಡಿಮೆ ಪ್ರಸ್ತುತತೆ ಇರುವ ಎಲ್ಲವೂ ಬ್ಯಾಕ್‌ಲಾಗ್‌ನಲ್ಲಿ ಉಳಿದಿದೆ ಮತ್ತು ಅಭಿವೃದ್ಧಿಯನ್ನು ತಲುಪುವುದಿಲ್ಲ.
ಬದಲಾವಣೆಯ ವಿನಂತಿಗಳು ಮತ್ತು ಹಣಕಾಸಿನ ವರ್ಗೀಕರಣ
ಅಭಿವೃದ್ಧಿ ದುಬಾರಿಯಾಗಿದೆ. ಆದ್ದರಿಂದ, ಬದಲಾವಣೆಯ ವಿನಂತಿಯು ಕ್ಲೈಂಟ್‌ನಿಂದ ಬಂದಿದ್ದರೆ ಮತ್ತು ಉದ್ಯೋಗಿಯಿಂದಲ್ಲದಿದ್ದರೆ ನಾವು ಯಾವ ಆಯ್ಕೆಗಳನ್ನು ಹೊಂದಬಹುದು ಎಂಬುದನ್ನು ನಾವು ತಕ್ಷಣ ನಿಮಗೆ ತಿಳಿಸುತ್ತೇವೆ.
ನಾವು ಬದಲಾವಣೆಯ ವಿನಂತಿಗಳನ್ನು ಈ ಕೆಳಗಿನಂತೆ ವರ್ಗೀಕರಿಸುತ್ತೇವೆ: ಉದ್ಯಮದ ಅಗತ್ಯತೆ ಅಥವಾ ಉದ್ಯಮದ ವೈಯಕ್ತಿಕ ಗುಣಲಕ್ಷಣ; ಗಮನಾರ್ಹ ಪ್ರಮಾಣದ ಹೊಸ ಕ್ರಿಯಾತ್ಮಕತೆ ಅಥವಾ ಸಣ್ಣ ಪರಿಹಾರ. ಸಣ್ಣ ಪರಿಹಾರಗಳು ಮತ್ತು ವೈಯಕ್ತಿಕ ವಿನಂತಿಗಳನ್ನು ಯಾವುದೇ ಅಲಂಕಾರಗಳಿಲ್ಲದೆ ಪ್ರಕ್ರಿಯೆಗೊಳಿಸಲಾಗುತ್ತದೆ. ನಿರ್ದಿಷ್ಟ ಕ್ಲೈಂಟ್‌ಗೆ ಅವನೊಂದಿಗೆ ಯೋಜನೆಯ ಕೆಲಸದ ಭಾಗವಾಗಿ ವೈಯಕ್ತಿಕ ವಿನಂತಿಗಳನ್ನು ಲೆಕ್ಕಹಾಕಲಾಗುತ್ತದೆ ಮತ್ತು ಕಾರ್ಯಗತಗೊಳಿಸಲಾಗುತ್ತದೆ.
ಇದು ಬೃಹತ್ ಉದ್ಯಮದ ಅಗತ್ಯವಿಲ್ಲದಿದ್ದರೆ ಮತ್ತು ಕಾರ್ಯದ ಪರಿಮಾಣವು ದೊಡ್ಡದಾಗಿದ್ದರೆ, ಮುಖ್ಯ ಕಾರ್ಯನಿರ್ವಹಣೆಯ ಜೊತೆಗೆ ಮಾರಾಟವಾಗುವ ಹೊಸ ಪ್ರತ್ಯೇಕ ಮಾಡ್ಯೂಲ್ ಅನ್ನು ಅಭಿವೃದ್ಧಿಪಡಿಸಲು ನಿರ್ಧಾರವನ್ನು ತೆಗೆದುಕೊಳ್ಳಬಹುದು. ಕ್ಲೈಂಟ್‌ನಿಂದ ಅಂತಹ ವಿನಂತಿಯನ್ನು ಸ್ವೀಕರಿಸಿದರೆ, ಮಾಡ್ಯೂಲ್ ಅನ್ನು ಅಭಿವೃದ್ಧಿಪಡಿಸುವ ವೆಚ್ಚವನ್ನು ನಾವು ಭರಿಸಬಹುದು, ಕ್ಲೈಂಟ್‌ಗೆ ಮಾಡ್ಯೂಲ್ ಅನ್ನು ಉಚಿತವಾಗಿ ಅಥವಾ ಭಾಗಶಃ ಪಾವತಿಯೊಂದಿಗೆ ಒದಗಿಸಬಹುದು ಮತ್ತು ಮಾಡ್ಯೂಲ್ ಅನ್ನು ಮಾರಾಟಕ್ಕೆ ಇಡಬಹುದು. ಅಂತಹ ಪರಿಸ್ಥಿತಿಯಲ್ಲಿ, ಕ್ಲೈಂಟ್ ಕ್ರಮಶಾಸ್ತ್ರೀಯ ಹೊರೆಯ ಭಾಗವನ್ನು ತೆಗೆದುಕೊಳ್ಳುತ್ತದೆ ಮತ್ತು ಮೂಲಭೂತವಾಗಿ ಮಾಡ್ಯೂಲ್ನ ಪ್ರಾಯೋಗಿಕ ಅನುಷ್ಠಾನವನ್ನು ಸ್ವತಃ ನಡೆಸುತ್ತದೆ.
ಇದು ಬೃಹತ್ ಉದ್ಯಮದ ಅಗತ್ಯವಿದ್ದಲ್ಲಿ, ಮೂಲ ಉತ್ಪನ್ನದಲ್ಲಿ ಹೊಸ ಕಾರ್ಯವನ್ನು ಸೇರಿಸಲು ನಿರ್ಧಾರವನ್ನು ತೆಗೆದುಕೊಳ್ಳಬಹುದು. ಈ ಸಂದರ್ಭದಲ್ಲಿ ವೆಚ್ಚಗಳು ಸಂಪೂರ್ಣವಾಗಿ ನಮ್ಮ ಮೇಲೆ ಬೀಳುತ್ತವೆ, ಮತ್ತು ಹೊಸ ಕಾರ್ಯವು ಕಾರ್ಯಕ್ರಮಗಳ ಪ್ರಸ್ತುತ ಆವೃತ್ತಿಯಲ್ಲಿ ಕಾಣಿಸಿಕೊಳ್ಳುತ್ತದೆ.
ಹಳೆಯ ಗ್ರಾಹಕರಿಗೆ ನವೀಕರಣವನ್ನು ಒದಗಿಸಲಾಗಿದೆ.
ಹಲವಾರು ಗ್ರಾಹಕರು ಇದೇ ರೀತಿಯ ಅಗತ್ಯವನ್ನು ಹೊಂದಿರಬಹುದು, ಆದರೆ ಇದು ಸಾಮೂಹಿಕ ಉತ್ಪನ್ನಕ್ಕೆ ಅರ್ಹತೆ ಹೊಂದಿಲ್ಲ. ಈ ಸಂದರ್ಭದಲ್ಲಿ, ನಾವು ಈ ಗ್ರಾಹಕರಿಗೆ ನಿರ್ದಿಷ್ಟತೆಯನ್ನು ಕಳುಹಿಸಬಹುದು ಮತ್ತು ಅವುಗಳ ನಡುವೆ ಅಭಿವೃದ್ಧಿ ವೆಚ್ಚವನ್ನು ವಿಭಜಿಸಲು ನೀಡಬಹುದು. ಕೊನೆಯಲ್ಲಿ, ಪ್ರತಿಯೊಬ್ಬರೂ ಗೆಲ್ಲುತ್ತಾರೆ: ಗ್ರಾಹಕರು ಕಡಿಮೆ ವೆಚ್ಚದಲ್ಲಿ ಕಾರ್ಯವನ್ನು ಸ್ವೀಕರಿಸುತ್ತಾರೆ, ನಾವು ಉತ್ಪನ್ನವನ್ನು ಉತ್ಕೃಷ್ಟಗೊಳಿಸುತ್ತೇವೆ ಮತ್ತು ಸ್ವಲ್ಪ ಸಮಯದ ನಂತರ, ಇತರ ಮಾರುಕಟ್ಟೆ ಭಾಗವಹಿಸುವವರು ತಮ್ಮ ಬಳಕೆಗಾಗಿ ಕಾರ್ಯವನ್ನು ಪಡೆಯಬಹುದು.
DevOps
ಅಭಿವೃದ್ಧಿಯು ವರ್ಷಕ್ಕೆ ಎರಡು ಪ್ರಮುಖ ಬಿಡುಗಡೆಗಳನ್ನು ಸಿದ್ಧಪಡಿಸುತ್ತದೆ. ಪ್ರತಿ ಬಿಡುಗಡೆಯಲ್ಲಿ, ತಾಂತ್ರಿಕ ಮಂಡಳಿಯಿಂದ ಪಡೆದ 5 ಕಾರ್ಯಗಳ ಅನುಷ್ಠಾನಕ್ಕೆ ಸಮಯವನ್ನು ಕಾಯ್ದಿರಿಸಲಾಗಿದೆ. ಹೀಗಾಗಿ, ದಿನಚರಿಯ ಮಧ್ಯೆ, ಉತ್ಪನ್ನ ಅಭಿವೃದ್ಧಿಯ ಬಗ್ಗೆ ನಾವು ಎಂದಿಗೂ ಮರೆಯುವುದಿಲ್ಲ.
ಪ್ರತಿ ಬಿಡುಗಡೆಯು ಸೂಕ್ತವಾದ ಪರೀಕ್ಷೆ ಮತ್ತು ದಾಖಲಾತಿಗೆ ಒಳಗಾಗುತ್ತದೆ. ಮುಂದೆ, ಈ ಬಿಡುಗಡೆಯನ್ನು ಅನುಗುಣವಾದ ಗ್ರಾಹಕರ ಪರೀಕ್ಷಾ ಪರಿಸರದಲ್ಲಿ ಸ್ಥಾಪಿಸಲಾಗಿದೆ, ಅವರು ಪ್ರತಿಯಾಗಿ, ಎಲ್ಲವನ್ನೂ ಸೂಕ್ಷ್ಮವಾಗಿ ಪರಿಶೀಲಿಸುತ್ತಾರೆ ಮತ್ತು ಅದರ ನಂತರ ಮಾತ್ರ ಬಿಡುಗಡೆಯನ್ನು ಉತ್ಪಾದನೆಗೆ ವರ್ಗಾಯಿಸಲಾಗುತ್ತದೆ.
ಬಿಡುಗಡೆ ವ್ಯವಸ್ಥೆಯ ಜೊತೆಗೆ, ಕ್ಲೈಂಟ್‌ಗಳು ಆರು ತಿಂಗಳವರೆಗೆ ದೋಷಗಳೊಂದಿಗೆ ಜೀವಿಸದಂತೆ ತ್ವರಿತ ದೋಷ ಪರಿಹಾರಗಳಿಗಾಗಿ ಒಂದು ಸ್ವರೂಪವಿದೆ. ಈ ಮಧ್ಯಂತರ ಸ್ವರೂಪವು ಮೊದಲ ಆದ್ಯತೆಯ ಘಟನೆಗಳಿಗೆ ತ್ವರಿತವಾಗಿ ಪ್ರತಿಕ್ರಿಯಿಸಲು ಮತ್ತು ಹೇಳಲಾದ SLA ಗಳನ್ನು ಪೂರೈಸಲು ನಿಮಗೆ ಅನುಮತಿಸುತ್ತದೆ.
ಮೇಲಿನ ಎಲ್ಲಾ ಪ್ರಾಥಮಿಕವಾಗಿ ಕಾರ್ಪೊರೇಟ್ ವಲಯ ಮತ್ತು ಆನ್-ಪ್ರಿಮೈಸ್ ಪರಿಹಾರಗಳಿಗೆ ನಿಜವಾಗಿದೆ. SMB ವಿಭಾಗದಲ್ಲಿ ಗುರಿಯನ್ನು ಹೊಂದಿರುವ ಕ್ಲೌಡ್ ಸೇವೆಗಳಿಗೆ, ಉತ್ಪನ್ನ ಅಭಿವೃದ್ಧಿಯಲ್ಲಿ ಭಾಗವಹಿಸಲು ಗ್ರಾಹಕರಿಗೆ ಅಂತಹ ವಿಶಾಲ ಅವಕಾಶಗಳಿಲ್ಲ. SMB ಬಾಡಿಗೆ ಸ್ವರೂಪವು ಇದನ್ನು ಊಹಿಸುವುದಿಲ್ಲ. ಕಾರ್ಪೊರೇಟ್ ಪಕ್ಷದಿಂದ ಸ್ಪಷ್ಟ ಅವಶ್ಯಕತೆಗಳ ರೂಪದಲ್ಲಿ ಬದಲಾವಣೆಯ ವಿನಂತಿಯ ಬದಲಿಗೆ, ಇಲ್ಲಿ ಸಾಮಾನ್ಯ ಪ್ರತಿಕ್ರಿಯೆ ಮತ್ತು ಸೇವೆಗಾಗಿ ಶುಭಾಶಯಗಳು ಮಾತ್ರ ಇವೆ. ನಾವು ಕೇಳಲು ಪ್ರಯತ್ನಿಸುತ್ತೇವೆ, ಆದರೆ ಉತ್ಪನ್ನವು ದೊಡ್ಡದಾಗಿದೆ ಮತ್ತು ಒಬ್ಬ ಕ್ಲೈಂಟ್ ತನ್ನ ಹಳೆಯ ಐತಿಹಾಸಿಕ ವ್ಯವಸ್ಥೆಯಿಂದ ಪರಿಚಿತವಾದದ್ದನ್ನು ತರಲು ಬಯಸುವುದು ಒಟ್ಟಾರೆಯಾಗಿ ವ್ಯವಸ್ಥೆಯ ಅಭಿವೃದ್ಧಿ ಕಾರ್ಯತಂತ್ರವನ್ನು ವಿರೋಧಿಸಬಹುದು.
ಮೂಲ: www.habr.com