ನಮಸ್ಕಾರ ಗೆಳೆಯರೆ. ಆಗಾಗ್ಗೆ, ವಿಶೇಷವಾಗಿ ಹೊರಗುತ್ತಿಗೆಯಲ್ಲಿ, ನಾನು ಅದೇ ಚಿತ್ರವನ್ನು ನೋಡುತ್ತೇನೆ. ವಿವಿಧ ಯೋಜನೆಗಳಲ್ಲಿ ತಂಡಗಳಲ್ಲಿ ಸ್ಪಷ್ಟ ಕೆಲಸದ ಹರಿವಿನ ಕೊರತೆ.
ಪ್ರೋಗ್ರಾಮರ್ಗಳು ಗ್ರಾಹಕರೊಂದಿಗೆ ಮತ್ತು ಪರಸ್ಪರ ಹೇಗೆ ಸಂವಹನ ನಡೆಸಬೇಕೆಂದು ಅರ್ಥಮಾಡಿಕೊಳ್ಳುವುದಿಲ್ಲ ಎಂಬುದು ಅತ್ಯಂತ ಮುಖ್ಯವಾದ ವಿಷಯ. ಗುಣಮಟ್ಟದ ಉತ್ಪನ್ನವನ್ನು ಅಭಿವೃದ್ಧಿಪಡಿಸುವ ನಿರಂತರ ಪ್ರಕ್ರಿಯೆಯನ್ನು ಹೇಗೆ ನಿರ್ಮಿಸುವುದು. ನಿಮ್ಮ ಕೆಲಸದ ದಿನ ಮತ್ತು ಸ್ಪ್ರಿಂಟ್‌ಗಳನ್ನು ಹೇಗೆ ಯೋಜಿಸುವುದು.
ಮತ್ತು ಇವೆಲ್ಲವೂ ಅಂತಿಮವಾಗಿ ತಪ್ಪಿದ ಡೆಡ್‌ಲೈನ್‌ಗಳು, ಓವರ್‌ಟೈಮ್, ಯಾರನ್ನು ದೂಷಿಸಬೇಕೆಂಬುದರ ಬಗ್ಗೆ ನಿರಂತರ ಮುಖಾಮುಖಿ ಮತ್ತು ಎಲ್ಲವೂ ಎಲ್ಲಿ ಮತ್ತು ಹೇಗೆ ಚಲಿಸುತ್ತಿದೆ ಎಂಬುದರ ಬಗ್ಗೆ ಗ್ರಾಹಕರ ಅಸಮಾಧಾನಕ್ಕೆ ಕಾರಣವಾಗುತ್ತದೆ. ಆಗಾಗ್ಗೆ, ಇದೆಲ್ಲವೂ ಪ್ರೋಗ್ರಾಮರ್ಗಳ ಬದಲಾವಣೆಗೆ ಅಥವಾ ಸಂಪೂರ್ಣ ತಂಡಗಳಿಗೆ ಕಾರಣವಾಗುತ್ತದೆ. ಗ್ರಾಹಕರ ನಷ್ಟ, ಖ್ಯಾತಿಯ ಕ್ಷೀಣತೆ, ಇತ್ಯಾದಿ.
ಒಂದು ಸಮಯದಲ್ಲಿ, ನಾನು ಅಂತಹ ಯೋಜನೆಯಲ್ಲಿ ಕೊನೆಗೊಂಡೆ, ಅಲ್ಲಿ ಈ ಎಲ್ಲಾ ಸಂತೋಷಗಳು ಇದ್ದವು.
ಯೋಜನೆಯ ಜವಾಬ್ದಾರಿಯನ್ನು ತೆಗೆದುಕೊಳ್ಳಲು ಯಾರೂ ಬಯಸಲಿಲ್ಲ (ದೊಡ್ಡ ಸೇವಾ ಮಾರುಕಟ್ಟೆ), ವಹಿವಾಟು ಭಯಾನಕವಾಗಿತ್ತು, ಗ್ರಾಹಕರು ಸರಳವಾಗಿ ಹರಿದು ಹತಾಶೆಗೊಂಡರು. ಸಿಇಒ ಒಮ್ಮೆ ನನ್ನ ಬಳಿಗೆ ಬಂದು ನಿಮಗೆ ಅಗತ್ಯವಾದ ಅನುಭವವಿದೆ, ಆದ್ದರಿಂದ ನಿಮ್ಮ ಕೈಯಲ್ಲಿ ಕಾರ್ಡ್‌ಗಳು ಇಲ್ಲಿವೆ ಎಂದು ಹೇಳಿದರು. ನಿಮಗಾಗಿ ಯೋಜನೆಯನ್ನು ತೆಗೆದುಕೊಳ್ಳಿ. ನೀವು ಸ್ಕ್ರೂ ಅಪ್ ಮಾಡಿದರೆ, ನಾವು ಯೋಜನೆಯನ್ನು ಮುಚ್ಚುತ್ತೇವೆ ಮತ್ತು ಎಲ್ಲರನ್ನು ಹೊರಹಾಕುತ್ತೇವೆ. ಇದು ಕೆಲಸ ಮಾಡುತ್ತದೆ, ಅದು ತಂಪಾಗಿರುತ್ತದೆ, ನಂತರ ಅದನ್ನು ಮುನ್ನಡೆಸುತ್ತದೆ ಮತ್ತು ನೀವು ಸರಿಹೊಂದುವಂತೆ ಅದನ್ನು ಅಭಿವೃದ್ಧಿಪಡಿಸಿ. ಪರಿಣಾಮವಾಗಿ, ನಾನು ಯೋಜನೆಗೆ ತಂಡದ ನಾಯಕನಾದೆ ಮತ್ತು ಎಲ್ಲವೂ ನನ್ನ ಹೆಗಲ ಮೇಲೆ ಬಿದ್ದಿತು.
ನಾನು ಮಾಡಿದ ಮೊದಲ ಕೆಲಸವೆಂದರೆ ಮೊದಲಿನಿಂದಲೂ ಕೆಲಸದ ಹರಿವನ್ನು ಅಭಿವೃದ್ಧಿಪಡಿಸುವುದು, ಅದು ಆ ಸಮಯದಲ್ಲಿ ನನ್ನ ದೃಷ್ಟಿಗೆ ಹೊಂದಿಕೆಯಾಯಿತು ಮತ್ತು ತಂಡಕ್ಕೆ ಉದ್ಯೋಗ ವಿವರಣೆಯನ್ನು ಬರೆದಿದೆ. ಅದನ್ನು ಕಾರ್ಯರೂಪಕ್ಕೆ ತರುವುದು ಸುಲಭವಾಗಿರಲಿಲ್ಲ. ಆದರೆ ಒಂದು ತಿಂಗಳೊಳಗೆ ಎಲ್ಲವೂ ನೆಲೆಗೊಂಡಿತು, ಅಭಿವರ್ಧಕರು ಮತ್ತು ಕ್ಲೈಂಟ್ ಅದನ್ನು ಬಳಸಿಕೊಂಡರು, ಮತ್ತು ಎಲ್ಲವೂ ಸದ್ದಿಲ್ಲದೆ ಮತ್ತು ಆರಾಮವಾಗಿ ಹೋಯಿತು. ಇದು ಕೇವಲ "ಟೀಕಪ್‌ನಲ್ಲಿ ಚಂಡಮಾರುತ" ಅಲ್ಲ, ಆದರೆ ಪರಿಸ್ಥಿತಿಯಿಂದ ನಿಜವಾದ ಮಾರ್ಗವಾಗಿದೆ ಎಂದು ತಂಡಕ್ಕೆ ತೋರಿಸಲು, ನಾನು ತಂಡದಿಂದ ಅಹಿತಕರ ದಿನಚರಿಯನ್ನು ತೆಗೆದುಹಾಕುವ ಮೂಲಕ ಗರಿಷ್ಠ ಪ್ರಮಾಣದ ಜವಾಬ್ದಾರಿಗಳನ್ನು ತೆಗೆದುಕೊಂಡೆ.
ಒಂದೂವರೆ ವರ್ಷ ಈಗಾಗಲೇ ಕಳೆದಿದೆ, ಮತ್ತು ಯೋಜನೆಯು ಹೆಚ್ಚುವರಿ ಸಮಯವಿಲ್ಲದೆ, "ಇಲಿ ರೇಸ್" ಮತ್ತು ಎಲ್ಲಾ ರೀತಿಯ ಒತ್ತಡವಿಲ್ಲದೆ ಅಭಿವೃದ್ಧಿ ಹೊಂದುತ್ತಿದೆ. ಹಳೆಯ ತಂಡದ ಕೆಲವು ಜನರು ಹಾಗೆ ಕೆಲಸ ಮಾಡಲು ಬಯಸುವುದಿಲ್ಲ ಮತ್ತು ಹೊರಟುಹೋದರು; ಇತರರು, ಇದಕ್ಕೆ ವಿರುದ್ಧವಾಗಿ, ಪಾರದರ್ಶಕ ನಿಯಮಗಳು ಕಾಣಿಸಿಕೊಂಡಿವೆ ಎಂದು ತುಂಬಾ ಸಂತೋಷಪಟ್ಟರು. ಆದರೆ ಕೊನೆಯಲ್ಲಿ, ತಂಡದ ಪ್ರತಿಯೊಬ್ಬರೂ ಬಹಳ ಪ್ರೇರಿತರಾಗಿದ್ದಾರೆ ಮತ್ತು ಮುಂಭಾಗದ ಮತ್ತು ಹಿಂಭಾಗದ ಎರಡೂ ಸೇರಿದಂತೆ ಬೃಹತ್ ಯೋಜನೆಯನ್ನು ಸಂಪೂರ್ಣವಾಗಿ ತಿಳಿದಿದ್ದಾರೆ. ಕೋಡ್ ಬೇಸ್ ಮತ್ತು ಎಲ್ಲಾ ವ್ಯವಹಾರ ತರ್ಕ ಎರಡನ್ನೂ ಒಳಗೊಂಡಂತೆ. ಇದು ನಾವು ಕೇವಲ "ರೋವರ್‌ಗಳು" ಅಲ್ಲ ಎಂಬ ಹಂತಕ್ಕೆ ತಲುಪಿದೆ, ಆದರೆ ನಾವೇ ಅನೇಕ ವ್ಯವಹಾರ ಪ್ರಕ್ರಿಯೆಗಳು ಮತ್ತು ವ್ಯವಹಾರವು ಇಷ್ಟಪಡುವ ಹೊಸ ವೈಶಿಷ್ಟ್ಯಗಳೊಂದಿಗೆ ಬರುತ್ತೇವೆ.
ನಮ್ಮ ಕಡೆಯಿಂದ ಈ ವಿಧಾನಕ್ಕೆ ಧನ್ಯವಾದಗಳು, ಗ್ರಾಹಕರು ನಮ್ಮ ಕಂಪನಿಯಿಂದ ಮತ್ತೊಂದು ಮಾರುಕಟ್ಟೆಯನ್ನು ಆದೇಶಿಸಲು ನಿರ್ಧರಿಸಿದ್ದಾರೆ, ಇದು ಒಳ್ಳೆಯ ಸುದ್ದಿಯಾಗಿದೆ.
ಇದು ನನ್ನ ಪ್ರಾಜೆಕ್ಟ್‌ನಲ್ಲಿ ಕಾರ್ಯನಿರ್ವಹಿಸುವುದರಿಂದ, ಬಹುಶಃ ಇದು ಯಾರಿಗಾದರೂ ಸಹಾಯ ಮಾಡುತ್ತದೆ. ಆದ್ದರಿಂದ, ಯೋಜನೆಯನ್ನು ಉಳಿಸಲು ನಮಗೆ ಸಹಾಯ ಮಾಡಿದ ಪ್ರಕ್ರಿಯೆಯು ಸ್ವತಃ:
"ನನ್ನ ಮೆಚ್ಚಿನ ಯೋಜನೆ" ಯೋಜನೆಯಲ್ಲಿ ತಂಡದ ಕೆಲಸದ ಪ್ರಕ್ರಿಯೆ
ಎ) ಆಂತರಿಕ ತಂಡದ ಪ್ರಕ್ರಿಯೆ (ಡೆವಲಪರ್‌ಗಳ ನಡುವೆ)
- ಜಿರಾ ವ್ಯವಸ್ಥೆಯಲ್ಲಿ ಎಲ್ಲಾ ಸಮಸ್ಯೆಗಳನ್ನು ರಚಿಸಲಾಗಿದೆ
- ಪ್ರತಿಯೊಂದು ಕೆಲಸವನ್ನು ಸಾಧ್ಯವಾದಷ್ಟು ವಿವರಿಸಬೇಕು ಮತ್ತು ಕಟ್ಟುನಿಟ್ಟಾಗಿ ಒಂದು ಕ್ರಿಯೆಯನ್ನು ಮಾಡಬೇಕು
- ಯಾವುದೇ ವೈಶಿಷ್ಟ್ಯವು ಸಾಕಷ್ಟು ಸಂಕೀರ್ಣವಾಗಿದ್ದರೆ, ಅನೇಕ ಸಣ್ಣ ಕಾರ್ಯಗಳಾಗಿ ವಿಂಗಡಿಸಲಾಗಿದೆ
- ತಂಡವು ವೈಶಿಷ್ಟ್ಯಗಳ ಮೇಲೆ ಒಂದೇ ಕಾರ್ಯವಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ. ಮೊದಲಿಗೆ, ನಾವೆಲ್ಲರೂ ಒಂದು ವೈಶಿಷ್ಟ್ಯದಲ್ಲಿ ಒಟ್ಟಾಗಿ ಕೆಲಸ ಮಾಡುತ್ತೇವೆ, ಅದನ್ನು ಪರೀಕ್ಷೆಗೆ ಕಳುಹಿಸಿ, ನಂತರ ಮುಂದಿನದನ್ನು ತೆಗೆದುಕೊಳ್ಳಿ.
- ಪ್ರತಿ ಕೆಲಸವನ್ನು ಬ್ಯಾಕೆಂಡ್ ಅಥವಾ ಮುಂಭಾಗಕ್ಕಾಗಿ ಗುರುತಿಸಲಾಗಿದೆ
- ಕಾರ್ಯಗಳು ಮತ್ತು ದೋಷಗಳ ವಿಧಗಳಿವೆ. ನೀವು ಅವುಗಳನ್ನು ಸರಿಯಾಗಿ ಸೂಚಿಸಬೇಕು.
- ಕಾರ್ಯವನ್ನು ಪೂರ್ಣಗೊಳಿಸಿದ ನಂತರ, ಅದನ್ನು ಕೋಡ್ ವಿಮರ್ಶೆ ಸ್ಥಿತಿಗೆ ವರ್ಗಾಯಿಸಲಾಗುತ್ತದೆ (ಈ ಸಂದರ್ಭದಲ್ಲಿ, ಸಹೋದ್ಯೋಗಿಗಾಗಿ ಪುಲ್ ವಿನಂತಿಯನ್ನು ರಚಿಸಲಾಗುತ್ತದೆ)
- ಕಾರ್ಯವನ್ನು ಪೂರ್ಣಗೊಳಿಸಿದ ವ್ಯಕ್ತಿಯು ಈ ಕಾರ್ಯಕ್ಕಾಗಿ ತನ್ನ ಸಮಯವನ್ನು ತಕ್ಷಣವೇ ಟ್ರ್ಯಾಕ್ ಮಾಡುತ್ತಾನೆ.
- ಕೋಡ್ ಅನ್ನು ಪರಿಶೀಲಿಸಿದ ನಂತರ, PR ಅನುಮೋದಿಸುತ್ತದೆ ಮತ್ತು ಅದರ ನಂತರ, ಈ ಕಾರ್ಯವನ್ನು ನಿರ್ವಹಿಸಿದವರು ಸ್ವತಂತ್ರವಾಗಿ ಅದನ್ನು ಮಾಸ್ಟರ್ ಶಾಖೆಗೆ ವಿಲೀನಗೊಳಿಸುತ್ತಾರೆ, ನಂತರ ಅವರು ಅದರ ಸ್ಥಿತಿಯನ್ನು ದೇವ್ ಸರ್ವರ್ಗೆ ನಿಯೋಜಿಸಲು ಸಿದ್ಧವಾಗುವಂತೆ ಬದಲಾಯಿಸುತ್ತಾರೆ.
- ದೇವ್ ಸರ್ವರ್ಗೆ ನಿಯೋಜಿಸಲು ಸಿದ್ಧವಾಗಿರುವ ಎಲ್ಲಾ ಕಾರ್ಯಗಳನ್ನು ಟೀಮ್ ಲೀಡ್ (ಅವರ ಜವಾಬ್ದಾರಿಯ ಪ್ರದೇಶ), ಕೆಲವೊಮ್ಮೆ ತಂಡದ ಸದಸ್ಯರಿಂದ, ಏನಾದರೂ ತುರ್ತು ವೇಳೆ ನಿಯೋಜಿಸಲಾಗುತ್ತದೆ. ನಿಯೋಜನೆಯ ನಂತರ, ನಿಯೋಜನೆಗೆ ಸಿದ್ಧದಿಂದ ದೇವ್‌ಗೆ ಎಲ್ಲಾ ಕಾರ್ಯಗಳನ್ನು ಸ್ಥಿತಿಗೆ ವರ್ಗಾಯಿಸಲಾಗುತ್ತದೆ - dev ನಲ್ಲಿ ಪರೀಕ್ಷೆಗೆ ಸಿದ್ಧವಾಗಿದೆ
- ಎಲ್ಲಾ ಕಾರ್ಯಗಳನ್ನು ಗ್ರಾಹಕರು ಪರೀಕ್ಷಿಸುತ್ತಾರೆ
- ಗ್ರಾಹಕರು dev ನಲ್ಲಿ ಕಾರ್ಯವನ್ನು ಪರೀಕ್ಷಿಸಿದಾಗ, ಅವರು ಅದನ್ನು ಉತ್ಪಾದನೆಗೆ ನಿಯೋಜಿಸಲು ಸಿದ್ಧವಾಗಿರುವ ಸ್ಥಿತಿಗೆ ವರ್ಗಾಯಿಸುತ್ತಾರೆ.
- ಉತ್ಪಾದನೆಗೆ ನಿಯೋಜನೆಗಾಗಿ, ನಾವು ಪ್ರತ್ಯೇಕ ಶಾಖೆಯನ್ನು ಹೊಂದಿದ್ದೇವೆ, ಅಲ್ಲಿ ನಾವು ನಿಯೋಜನೆಯ ಮೊದಲು ಮಾತ್ರ ಮಾಸ್ಟರ್ ಅನ್ನು ವಿಲೀನಗೊಳಿಸುತ್ತೇವೆ
- ಪರೀಕ್ಷೆಯ ಸಮಯದಲ್ಲಿ ಗ್ರಾಹಕರು ದೋಷಗಳನ್ನು ಕಂಡುಕೊಂಡರೆ, ಅವರು ಪರಿಷ್ಕರಣೆಗಾಗಿ ಕಾರ್ಯವನ್ನು ಹಿಂತಿರುಗಿಸುತ್ತಾರೆ, ಪರಿಷ್ಕರಣೆಗಾಗಿ ಹಿಂದಿರುಗಿದ ಸ್ಥಿತಿಯನ್ನು ಹೊಂದಿಸುತ್ತಾರೆ. ಈ ರೀತಿಯಾಗಿ ನಾವು ಪರೀಕ್ಷೆಯಲ್ಲಿ ಉತ್ತೀರ್ಣರಾಗದವರಿಂದ ಹೊಸ ಕಾರ್ಯಗಳನ್ನು ಪ್ರತ್ಯೇಕಿಸುತ್ತೇವೆ.
- ಪರಿಣಾಮವಾಗಿ, ಎಲ್ಲಾ ಕಾರ್ಯಗಳು ರಚನೆಯಿಂದ ಪೂರ್ಣಗೊಳ್ಳುವವರೆಗೆ ಹೋಗುತ್ತವೆ: ಮಾಡಲು → ಅಭಿವೃದ್ಧಿಯಲ್ಲಿ → ಕೋಡ್ ವಿಮರ್ಶೆ → ಡೆವಲಪ್‌ಗೆ ಸಿದ್ಧವಾಗಿದೆ → dev ನಲ್ಲಿ QA → (dev ಗೆ ಹಿಂತಿರುಗಿ) → ಉತ್ಪನ್ನಕ್ಕೆ ಸಿದ್ಧ ನಿಯೋಜನೆ → ಉತ್ಪನ್ನದಲ್ಲಿ QA → ಮುಗಿದಿದೆ
- ಪ್ರತಿಯೊಬ್ಬ ಡೆವಲಪರ್ ತನ್ನ ಕೋಡ್ ಅನ್ನು ಸ್ವತಂತ್ರವಾಗಿ ಪರೀಕ್ಷಿಸುತ್ತಾನೆ, ಸೈಟ್ ಬಳಕೆದಾರರಂತೆ. ಕೋಡ್ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ ಎಂದು ಖಚಿತವಾಗಿ ತಿಳಿದಿಲ್ಲದ ಹೊರತು ಶಾಖೆಯನ್ನು ಮುಖ್ಯ ಶಾಖೆಗೆ ವಿಲೀನಗೊಳಿಸಲು ಅನುಮತಿಸಲಾಗುವುದಿಲ್ಲ.
- ಪ್ರತಿಯೊಂದು ಕಾರ್ಯಕ್ಕೂ ಆದ್ಯತೆಗಳಿರುತ್ತವೆ. ಆದ್ಯತೆಗಳನ್ನು ಗ್ರಾಹಕರು ಅಥವಾ ತಂಡದ ನಾಯಕರಿಂದ ಹೊಂದಿಸಲಾಗಿದೆ.
- ಡೆವಲಪರ್‌ಗಳು ಮೊದಲು ಆದ್ಯತೆಯ ಕಾರ್ಯಗಳನ್ನು ಪೂರ್ಣಗೊಳಿಸುತ್ತಾರೆ.
- ಸಿಸ್ಟಮ್‌ನಲ್ಲಿ ವಿಭಿನ್ನ ದೋಷಗಳು ಕಂಡುಬಂದರೆ ಅಥವಾ ಒಂದು ಕಾರ್ಯವು ಹಲವಾರು ತಜ್ಞರ ಕೆಲಸವನ್ನು ಒಳಗೊಂಡಿದ್ದರೆ ಡೆವಲಪರ್‌ಗಳು ಪರಸ್ಪರ ಕಾರ್ಯಗಳನ್ನು ನಿಯೋಜಿಸಬಹುದು.
- ಗ್ರಾಹಕರು ರಚಿಸುವ ಎಲ್ಲಾ ಕಾರ್ಯಗಳು ತಂಡದ ನಾಯಕನಿಗೆ ಹೋಗುತ್ತವೆ, ಅವರು ಅವುಗಳನ್ನು ಮೌಲ್ಯಮಾಪನ ಮಾಡುತ್ತಾರೆ ಮತ್ತು ಗ್ರಾಹಕರನ್ನು ಮಾರ್ಪಡಿಸಲು ಕೇಳುತ್ತಾರೆ ಅಥವಾ ತಂಡದ ಸದಸ್ಯರಲ್ಲಿ ಒಬ್ಬರಿಗೆ ನಿಯೋಜಿಸುತ್ತಾರೆ.
- dev ಅಥವಾ prod ಗೆ ನಿಯೋಜನೆಗೆ ಸಿದ್ಧವಾಗಿರುವ ಎಲ್ಲಾ ಕಾರ್ಯಗಳು ಸಹ ತಂಡದ ನಾಯಕನಿಗೆ ಹೋಗುತ್ತವೆ, ಅವರು ನಿಯೋಜನೆಯನ್ನು ಯಾವಾಗ ಮತ್ತು ಹೇಗೆ ಕೈಗೊಳ್ಳಬೇಕು ಎಂಬುದನ್ನು ಸ್ವತಂತ್ರವಾಗಿ ನಿರ್ಧರಿಸುತ್ತಾರೆ. ಪ್ರತಿ ನಿಯೋಜನೆಯ ನಂತರ, ತಂಡದ ಪ್ರಮುಖರು (ಅಥವಾ ತಂಡದ ಸದಸ್ಯರು) ಇದರ ಬಗ್ಗೆ ಗ್ರಾಹಕರಿಗೆ ಸೂಚಿಸಬೇಕು. ಮತ್ತು dev/cont ಗಾಗಿ ಪರೀಕ್ಷೆಗೆ ಸಿದ್ಧವಾಗಿರುವ ಕಾರ್ಯಗಳ ಸ್ಥಿತಿಗಳನ್ನು ಬದಲಾಯಿಸಿ.
- ಪ್ರತಿದಿನ ಅದೇ ಸಮಯದಲ್ಲಿ (ನಮಗೆ ಇದು 12.00 ಕ್ಕೆ) ನಾವು ಎಲ್ಲಾ ತಂಡದ ಸದಸ್ಯರ ನಡುವೆ ಸಭೆ ನಡೆಸುತ್ತೇವೆ
- ಸಭೆಯಲ್ಲಿರುವ ಪ್ರತಿಯೊಬ್ಬರೂ, ತಂಡದ ನಾಯಕ ಸೇರಿದಂತೆ, ಅವರು ನಿನ್ನೆ ಏನು ಮಾಡಿದರು ಮತ್ತು ಅವರು ಇಂದು ಏನು ಮಾಡಲು ಯೋಜಿಸಿದ್ದಾರೆ ಎಂಬುದರ ಕುರಿತು ವರದಿ ಮಾಡುತ್ತಾರೆ. ಏನು ಕೆಲಸ ಮಾಡುವುದಿಲ್ಲ ಮತ್ತು ಏಕೆ. ಈ ಮೂಲಕ ಇಡೀ ತಂಡಕ್ಕೆ ಯಾರು ಏನು ಮಾಡುತ್ತಿದ್ದಾರೆ ಮತ್ತು ಪ್ರಾಜೆಕ್ಟ್ ಯಾವ ಹಂತದಲ್ಲಿದೆ ಎಂಬುದು ಅರಿವಾಗುತ್ತದೆ. ಅಗತ್ಯವಿದ್ದಲ್ಲಿ, ನಮ್ಮ ಅಂದಾಜುಗಳು ಮತ್ತು ಗಡುವನ್ನು ಊಹಿಸಲು ಮತ್ತು ಸರಿಹೊಂದಿಸಲು ಇದು ನಮಗೆ ಅವಕಾಶವನ್ನು ನೀಡುತ್ತದೆ.
- ಸಭೆಯಲ್ಲಿ, ತಂಡದ ಪ್ರಮುಖರು ಯೋಜನೆಯಲ್ಲಿನ ಎಲ್ಲಾ ಬದಲಾವಣೆಗಳು ಮತ್ತು ಗ್ರಾಹಕರು ಕಂಡುಹಿಡಿದಿಲ್ಲದ ಪ್ರಸ್ತುತ ದೋಷಗಳ ಮಟ್ಟವನ್ನು ಕುರಿತು ಮಾತನಾಡುತ್ತಾರೆ. ಎಲ್ಲಾ ದೋಷಗಳನ್ನು ವಿಂಗಡಿಸಲಾಗಿದೆ ಮತ್ತು ಅವುಗಳನ್ನು ಪರಿಹರಿಸಲು ಪ್ರತಿ ತಂಡದ ಸದಸ್ಯರಿಗೆ ನಿಯೋಜಿಸಲಾಗಿದೆ.
- ಸಭೆಯಲ್ಲಿ, ತಂಡದ ಮುಖ್ಯಸ್ಥರು ಪ್ರತಿ ವ್ಯಕ್ತಿಗೆ ಕಾರ್ಯಗಳನ್ನು ನಿಯೋಜಿಸುತ್ತಾರೆ, ಡೆವಲಪರ್‌ಗಳ ಪ್ರಸ್ತುತ ಕೆಲಸದ ಹೊರೆ, ಅವರ ವೃತ್ತಿಪರ ತರಬೇತಿಯ ಮಟ್ಟ ಮತ್ತು ಡೆವಲಪರ್ ಪ್ರಸ್ತುತ ಏನು ಮಾಡುತ್ತಿದ್ದಾರೆ ಎಂಬುದಕ್ಕೆ ನಿರ್ದಿಷ್ಟ ಕಾರ್ಯದ ಸಾಮೀಪ್ಯವನ್ನು ಗಣನೆಗೆ ತೆಗೆದುಕೊಳ್ಳುತ್ತಾರೆ.
- ಸಭೆಯಲ್ಲಿ, ತಂಡದ ಮುಖ್ಯಸ್ಥರು ವಾಸ್ತುಶಿಲ್ಪ ಮತ್ತು ವ್ಯವಹಾರ ತರ್ಕಕ್ಕೆ ಸಾಮಾನ್ಯ ತಂತ್ರವನ್ನು ಅಭಿವೃದ್ಧಿಪಡಿಸುತ್ತಾರೆ. ಅದರ ನಂತರ ಇಡೀ ತಂಡವು ಇದನ್ನು ಚರ್ಚಿಸುತ್ತದೆ ಮತ್ತು ಹೊಂದಾಣಿಕೆಗಳನ್ನು ಮಾಡಲು ಅಥವಾ ಈ ತಂತ್ರವನ್ನು ಅಳವಡಿಸಿಕೊಳ್ಳಲು ನಿರ್ಧರಿಸುತ್ತದೆ.
- ಪ್ರತಿಯೊಬ್ಬ ಡೆವಲಪರ್ ಕೋಡ್ ಬರೆಯುತ್ತಾರೆ ಮತ್ತು ಒಂದೇ ಆರ್ಕಿಟೆಕ್ಚರ್ ಮತ್ತು ವ್ಯವಹಾರ ತರ್ಕದ ಚೌಕಟ್ಟಿನೊಳಗೆ ಸ್ವತಂತ್ರವಾಗಿ ಅಲ್ಗಾರಿದಮ್‌ಗಳನ್ನು ನಿರ್ಮಿಸುತ್ತಾರೆ. ಪ್ರತಿಯೊಬ್ಬರೂ ತಮ್ಮ ಅನುಷ್ಠಾನದ ದೃಷ್ಟಿಕೋನವನ್ನು ವ್ಯಕ್ತಪಡಿಸಬಹುದು, ಆದರೆ ಯಾರೂ ಯಾರನ್ನೂ ಈ ರೀತಿ ಮಾಡಲು ಒತ್ತಾಯಿಸುವುದಿಲ್ಲ ಮತ್ತು ಇಲ್ಲದಿದ್ದರೆ ಅಲ್ಲ. ಪ್ರತಿಯೊಂದು ನಿರ್ಧಾರವು ಸಮರ್ಥನೀಯವಾಗಿದೆ. ಉತ್ತಮ ಪರಿಹಾರವಿದ್ದರೆ, ಆದರೆ ಈಗ ಅದಕ್ಕೆ ಸಮಯವಿಲ್ಲದಿದ್ದರೆ, ಕೋಡ್‌ನ ನಿರ್ದಿಷ್ಟ ಭಾಗದ ಭವಿಷ್ಯದ ಮರುಫಲಕಕ್ಕಾಗಿ ಕೊಬ್ಬಿನಲ್ಲಿ ಕಾರ್ಯವನ್ನು ರಚಿಸಲಾಗುತ್ತದೆ.
- ಡೆವಲಪರ್ ಕಾರ್ಯವನ್ನು ತೆಗೆದುಕೊಂಡಾಗ, ಅವನು ಅದನ್ನು ಅಭಿವೃದ್ಧಿ ಸ್ಥಿತಿಗೆ ವರ್ಗಾಯಿಸುತ್ತಾನೆ. ಗ್ರಾಹಕರೊಂದಿಗೆ ಕಾರ್ಯದ ಸ್ಪಷ್ಟೀಕರಣದ ಬಗ್ಗೆ ಎಲ್ಲಾ ಸಂವಹನವು ಡೆವಲಪರ್ನ ಭುಜದ ಮೇಲೆ ಬೀಳುತ್ತದೆ. ತಾಂತ್ರಿಕ ಪ್ರಶ್ನೆಗಳನ್ನು ತಂಡದ ನಾಯಕ ಅಥವಾ ಸಹೋದ್ಯೋಗಿಗಳಿಗೆ ಕೇಳಬಹುದು.
- ಡೆವಲಪರ್ ಕಾರ್ಯದ ಸಾರವನ್ನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳದಿದ್ದರೆ ಮತ್ತು ಗ್ರಾಹಕರು ಅದನ್ನು ಸ್ಪಷ್ಟವಾಗಿ ವಿವರಿಸಲು ಸಾಧ್ಯವಾಗದಿದ್ದರೆ, ಅವರು ಮುಂದಿನ ಕಾರ್ಯಕ್ಕೆ ಮುಂದುವರಿಯುತ್ತಾರೆ. ಮತ್ತು ತಂಡದ ನಾಯಕನು ಪ್ರಸ್ತುತವನ್ನು ತೆಗೆದುಕೊಳ್ಳುತ್ತಾನೆ ಮತ್ತು ಅದನ್ನು ಗ್ರಾಹಕರೊಂದಿಗೆ ಚರ್ಚಿಸುತ್ತಾನೆ.
- ಪ್ರತಿದಿನ, ಡೆವಲಪರ್ ಕ್ಲೈಂಟ್‌ನ ಚಾಟ್‌ನಲ್ಲಿ ಅವರು ನಿನ್ನೆ ಯಾವ ಕಾರ್ಯಗಳಲ್ಲಿ ಕೆಲಸ ಮಾಡಿದರು ಮತ್ತು ಇಂದು ಅವರು ಯಾವ ಕಾರ್ಯಗಳಲ್ಲಿ ಕೆಲಸ ಮಾಡುತ್ತಾರೆ ಎಂಬುದರ ಕುರಿತು ಬರೆಯಬೇಕು
- ಸ್ಕ್ರಮ್ ಪ್ರಕಾರ ಕೆಲಸದ ಪ್ರಕ್ರಿಯೆಯು ನಡೆಯುತ್ತದೆ. ಎಲ್ಲವನ್ನೂ ಸ್ಪ್ರಿಂಟ್ಗಳಾಗಿ ವಿಂಗಡಿಸಲಾಗಿದೆ. ಪ್ರತಿ ಸ್ಪ್ರಿಂಟ್ ಎರಡು ವಾರಗಳವರೆಗೆ ಇರುತ್ತದೆ.
- ತಂಡದ ನಾಯಕರಿಂದ ಸ್ಪ್ರಿಂಟ್‌ಗಳನ್ನು ರಚಿಸಲಾಗುತ್ತದೆ, ತುಂಬಿಸಲಾಗುತ್ತದೆ ಮತ್ತು ಮುಚ್ಚಲಾಗುತ್ತದೆ.
- ಯೋಜನೆಯು ಕಟ್ಟುನಿಟ್ಟಾದ ಗಡುವನ್ನು ಹೊಂದಿದ್ದರೆ, ನಂತರ ನಾವು ಎಲ್ಲಾ ಕಾರ್ಯಗಳನ್ನು ಅಂದಾಜು ಮಾಡಲು ಪ್ರಯತ್ನಿಸುತ್ತೇವೆ. ಮತ್ತು ನಾವು ಅವುಗಳನ್ನು ಸ್ಪ್ರಿಂಟ್ ಆಗಿ ಒಟ್ಟಿಗೆ ಸೇರಿಸುತ್ತೇವೆ. ಗ್ರಾಹಕರು ಸ್ಪ್ರಿಂಟ್‌ಗೆ ಹೆಚ್ಚಿನ ಕಾರ್ಯಗಳನ್ನು ಸೇರಿಸಲು ಪ್ರಯತ್ನಿಸಿದರೆ, ನಾವು ಆದ್ಯತೆಗಳನ್ನು ಹೊಂದಿಸುತ್ತೇವೆ ಮತ್ತು ಕೆಲವು ಇತರ ಕಾರ್ಯಗಳನ್ನು ಮುಂದಿನ ಸ್ಪ್ರಿಂಟ್‌ಗೆ ವರ್ಗಾಯಿಸುತ್ತೇವೆ.
ಬಿ) ಗ್ರಾಹಕರೊಂದಿಗೆ ಕೆಲಸ ಮಾಡುವ ಪ್ರಕ್ರಿಯೆ
- ಪ್ರತಿಯೊಬ್ಬ ಡೆವಲಪರ್ ಗ್ರಾಹಕರೊಂದಿಗೆ ಸಂವಹನ ನಡೆಸಬಹುದು ಮತ್ತು ಮಾಡಬೇಕು
- ಗ್ರಾಹಕನು ತನ್ನದೇ ಆದ ಆಟದ ನಿಯಮಗಳನ್ನು ಹೇರಲು ಅನುಮತಿಸಲಾಗುವುದಿಲ್ಲ. ನಾವು ನಮ್ಮ ಕ್ಷೇತ್ರದಲ್ಲಿ ತಜ್ಞರು ಎಂದು ಗ್ರಾಹಕರಿಗೆ ಸಭ್ಯ ಮತ್ತು ಸ್ನೇಹಪರ ರೀತಿಯಲ್ಲಿ ಸ್ಪಷ್ಟಪಡಿಸುವುದು ಅವಶ್ಯಕ, ಮತ್ತು ನಾವು ಮಾತ್ರ ಕೆಲಸದ ಪ್ರಕ್ರಿಯೆಗಳನ್ನು ನಿರ್ಮಿಸಬೇಕು ಮತ್ತು ಗ್ರಾಹಕರನ್ನು ಅದರಲ್ಲಿ ತೊಡಗಿಸಿಕೊಳ್ಳಬೇಕು.
- ಯಾವುದೇ ಕಾರ್ಯವನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸಲು ಪ್ರಾರಂಭಿಸುವ ಮೊದಲು, ವೈಶಿಷ್ಟ್ಯಕ್ಕಾಗಿ (ವರ್ಕ್‌ಫ್ಲೋ) ಸಂಪೂರ್ಣ ತಾರ್ಕಿಕ ಪ್ರಕ್ರಿಯೆಯ ಫ್ಲೋಚಾರ್ಟ್ ಅನ್ನು ರಚಿಸಲು ಇದು ಅವಶ್ಯಕವಾಗಿದೆ. ಮತ್ತು ದೃಢೀಕರಣಕ್ಕಾಗಿ ಅದನ್ನು ಗ್ರಾಹಕರಿಗೆ ಕಳುಹಿಸಿ. ಇದು ಸಂಕೀರ್ಣ ಮತ್ತು ಸ್ಪಷ್ಟವಾದ ಕಾರ್ಯನಿರ್ವಹಣೆಗೆ ಮಾತ್ರ ಅನ್ವಯಿಸುತ್ತದೆ, ಉದಾಹರಣೆಗೆ, ಪಾವತಿ ವ್ಯವಸ್ಥೆ, ಅಧಿಸೂಚನೆ ವ್ಯವಸ್ಥೆ, ಇತ್ಯಾದಿ. ಇದು ಗ್ರಾಹಕರಿಗೆ ನಿಖರವಾಗಿ ಏನು ಬೇಕು ಎಂಬುದನ್ನು ಹೆಚ್ಚು ನಿಖರವಾಗಿ ಅರ್ಥಮಾಡಿಕೊಳ್ಳಲು, ವೈಶಿಷ್ಟ್ಯಕ್ಕಾಗಿ ದಾಖಲಾತಿಗಳನ್ನು ಉಳಿಸಲು ಮತ್ತು ಗ್ರಾಹಕರು ಅವರು ಕೇಳಿದ್ದನ್ನು ನಾವು ಮಾಡಿಲ್ಲ ಎಂದು ಭವಿಷ್ಯದಲ್ಲಿ ಹೇಳಬಹುದು ಎಂಬ ಅಂಶದ ವಿರುದ್ಧ ನಮ್ಮನ್ನು ವಿಮೆ ಮಾಡಿಕೊಳ್ಳಲು ಅನುಮತಿಸುತ್ತದೆ.
- ಎಲ್ಲಾ ರೇಖಾಚಿತ್ರಗಳು/ಫ್ಲೋಚಾರ್ಟ್‌ಗಳು/ತರ್ಕ ಇತ್ಯಾದಿ. ನಾವು ಅದನ್ನು ಕಾನ್ಫ್ಲುಯೆನ್ಸ್/ಫ್ಯಾಟ್‌ನಲ್ಲಿ ಉಳಿಸುತ್ತೇವೆ, ಅಲ್ಲಿ ಕಾಮೆಂಟ್‌ಗಳಲ್ಲಿ ಭವಿಷ್ಯದ ಅನುಷ್ಠಾನದ ಸರಿಯಾದತೆಯನ್ನು ಖಚಿತಪಡಿಸಲು ನಾವು ಗ್ರಾಹಕರನ್ನು ಕೇಳುತ್ತೇವೆ.
- ತಾಂತ್ರಿಕ ವಿವರಗಳೊಂದಿಗೆ ಗ್ರಾಹಕರಿಗೆ ಹೊರೆಯಾಗದಂತೆ ನಾವು ಪ್ರಯತ್ನಿಸುತ್ತೇವೆ. ಗ್ರಾಹಕರು ಅದನ್ನು ಹೇಗೆ ಬಯಸುತ್ತಾರೆ ಎಂಬುದರ ಕುರಿತು ನಮಗೆ ತಿಳುವಳಿಕೆ ಬೇಕಾದರೆ, ಗ್ರಾಹಕರು ಎಲ್ಲವನ್ನೂ ಸ್ವತಃ ಅರ್ಥಮಾಡಿಕೊಳ್ಳಬಹುದು ಮತ್ತು ಸರಿಪಡಿಸಬಹುದು/ಮಾರ್ಪಡಿಸಬಹುದಾದ ಫ್ಲೋಚಾರ್ಟ್ ರೂಪದಲ್ಲಿ ನಾವು ಪ್ರಾಚೀನ ಅಲ್ಗಾರಿದಮ್‌ಗಳನ್ನು ಸೆಳೆಯುತ್ತೇವೆ.
- ಗ್ರಾಹಕರು ಯೋಜನೆಯಲ್ಲಿ ದೋಷವನ್ನು ಕಂಡುಕೊಂಡರೆ, ಅದನ್ನು ಝಿರಾದಲ್ಲಿ ಹೆಚ್ಚು ವಿವರವಾಗಿ ವಿವರಿಸಲು ನಾವು ನಿಮ್ಮನ್ನು ಕೇಳುತ್ತೇವೆ. ಯಾವ ಸಂದರ್ಭಗಳಲ್ಲಿ ಇದು ಸಂಭವಿಸಿತು, ಯಾವಾಗ, ಪರೀಕ್ಷೆಯ ಸಮಯದಲ್ಲಿ ಗ್ರಾಹಕರು ಯಾವ ಕ್ರಮಗಳ ಅನುಕ್ರಮವನ್ನು ನಡೆಸಿದರು. ದಯವಿಟ್ಟು ಸ್ಕ್ರೀನ್‌ಶಾಟ್‌ಗಳನ್ನು ಲಗತ್ತಿಸಿ.
- ದೇವ್ ಸರ್ವರ್ಗೆ ನಿಯೋಜಿಸಲು ನಾವು ಪ್ರತಿದಿನವೂ, ಹೆಚ್ಚೆಂದರೆ ಪ್ರತಿ ದಿನವೂ ಪ್ರಯತ್ನಿಸುತ್ತೇವೆ. ಗ್ರಾಹಕರು ನಂತರ ಕಾರ್ಯವನ್ನು ಪರೀಕ್ಷಿಸಲು ಪ್ರಾರಂಭಿಸುತ್ತಾರೆ ಮತ್ತು ಯೋಜನೆಯು ನಿಷ್ಕ್ರಿಯವಾಗಿ ನಿಲ್ಲುವುದಿಲ್ಲ. ಅದೇ ಸಮಯದಲ್ಲಿ, ಯೋಜನೆಯು ಪೂರ್ಣ ಅಭಿವೃದ್ಧಿಯಲ್ಲಿದೆ ಮತ್ತು ಯಾರೂ ಅವನಿಗೆ ಕಾಲ್ಪನಿಕ ಕಥೆಗಳನ್ನು ಹೇಳುತ್ತಿಲ್ಲ ಎಂದು ಗ್ರಾಹಕರಿಗೆ ಇದು ಮಾರ್ಕರ್ ಆಗಿದೆ.
- ಗ್ರಾಹಕರು ತನಗೆ ಬೇಕಾದುದನ್ನು ಸಂಪೂರ್ಣವಾಗಿ ಅರ್ಥಮಾಡಿಕೊಳ್ಳುವುದಿಲ್ಲ ಎಂದು ಆಗಾಗ್ಗೆ ಸಂಭವಿಸುತ್ತದೆ. ಏಕೆಂದರೆ ಅವನು ತನಗಾಗಿ ಹೊಸ ವ್ಯವಹಾರವನ್ನು ರಚಿಸುತ್ತಿದ್ದಾನೆ, ಇನ್ನೂ ಸ್ಥಾಪಿಸದ ಪ್ರಕ್ರಿಯೆಗಳೊಂದಿಗೆ. ಆದ್ದರಿಂದ, ನಾವು ಸಂಪೂರ್ಣ ಕೋಡ್ ತುಣುಕುಗಳನ್ನು ಕಸದೊಳಗೆ ಎಸೆದಾಗ ಮತ್ತು ಅಪ್ಲಿಕೇಶನ್ ತರ್ಕವನ್ನು ಮರುವಿನ್ಯಾಸಗೊಳಿಸಿದಾಗ ಬಹಳ ಸಾಮಾನ್ಯವಾದ ಪರಿಸ್ಥಿತಿಯಾಗಿದೆ. ನೀವು ಎಲ್ಲವನ್ನೂ ಪರೀಕ್ಷೆಗಳೊಂದಿಗೆ ಸಂಪೂರ್ಣವಾಗಿ ಒಳಗೊಳ್ಳಬಾರದು ಎಂದು ಇದರಿಂದ ಅನುಸರಿಸುತ್ತದೆ. ಪರೀಕ್ಷೆಗಳೊಂದಿಗೆ ನಿರ್ಣಾಯಕ ಕಾರ್ಯವನ್ನು ಮಾತ್ರ ಒಳಗೊಳ್ಳಲು ಇದು ಅರ್ಥಪೂರ್ಣವಾಗಿದೆ, ಮತ್ತು ನಂತರ ಮಾತ್ರ ಮೀಸಲಾತಿಗಳೊಂದಿಗೆ.
- ನಾವು ಗಡುವನ್ನು ಪೂರೈಸುತ್ತಿಲ್ಲ ಎಂದು ತಂಡವು ಅರಿತುಕೊಂಡಾಗ ಸಂದರ್ಭಗಳಿವೆ. ನಂತರ ನಾವು ಕಾರ್ಯಗಳ ತ್ವರಿತ ಲೆಕ್ಕಪರಿಶೋಧನೆಯನ್ನು ನಡೆಸುತ್ತೇವೆ ಮತ್ತು ಅದರ ಬಗ್ಗೆ ಗ್ರಾಹಕರಿಗೆ ತಕ್ಷಣವೇ ತಿಳಿಸುತ್ತೇವೆ. ಪರಿಸ್ಥಿತಿಯಿಂದ ಹೊರಬರುವ ಮಾರ್ಗವಾಗಿ, ಸಮಯಕ್ಕೆ ಪ್ರಮುಖ ಮತ್ತು ನಿರ್ಣಾಯಕ ಕಾರ್ಯವನ್ನು ಪ್ರಾರಂಭಿಸಲು ನಾವು ಸಲಹೆ ನೀಡುತ್ತೇವೆ ಮತ್ತು ಉಳಿದವುಗಳನ್ನು ಬಿಡುಗಡೆಯ ನಂತರ ಬಿಡುತ್ತೇವೆ.
- ಗ್ರಾಹಕನು ತನ್ನ ತಲೆಯಿಂದ ವಿಭಿನ್ನ ಕಾರ್ಯಗಳನ್ನು ಮಾಡಲು ಪ್ರಾರಂಭಿಸಿದರೆ, ಅವನ ಬೆರಳುಗಳಿಂದ ಅತಿರೇಕವಾಗಿ ಮತ್ತು ವಿವರಿಸಲು ಪ್ರಾರಂಭಿಸಿದರೆ, ನಂತರ ನಾವು ನಮಗೆ ಪುಟ ವಿನ್ಯಾಸವನ್ನು ಒದಗಿಸಲು ಮತ್ತು ಸಂಪೂರ್ಣ ವಿನ್ಯಾಸದ ನಡವಳಿಕೆಯನ್ನು ಸಂಪೂರ್ಣವಾಗಿ ವಿವರಿಸುವ ತರ್ಕದೊಂದಿಗೆ ಹರಿಯುವಂತೆ ಕೇಳುತ್ತೇವೆ. ಅದರ ಅಂಶಗಳು.
- ಯಾವುದೇ ಕೆಲಸವನ್ನು ತೆಗೆದುಕೊಳ್ಳುವ ಮೊದಲು, ಈ ವೈಶಿಷ್ಟ್ಯವನ್ನು ನಮ್ಮ ಒಪ್ಪಂದದ/ಒಪ್ಪಂದದ ನಿಯಮಗಳಲ್ಲಿ ಸೇರಿಸಲಾಗಿದೆಯೇ ಎಂಬುದನ್ನು ನಾವು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳಬೇಕು. ಇದು ನಮ್ಮ ಆರಂಭಿಕ ಒಪ್ಪಂದಗಳನ್ನು ಮೀರಿದ ಹೊಸ ವೈಶಿಷ್ಟ್ಯವಾಗಿದ್ದರೆ, ನಾವು ಈ ವೈಶಿಷ್ಟ್ಯಕ್ಕೆ ಬೆಲೆ ನೀಡಬೇಕು ((ಅಂದಾಜು ಪೂರ್ಣಗೊಳಿಸುವ ಸಮಯ + 30%) x 2) ಮತ್ತು ಅದನ್ನು ಪೂರ್ಣಗೊಳಿಸಲು ನಮಗೆ ಇಷ್ಟು ಸಮಯ ತೆಗೆದುಕೊಳ್ಳುತ್ತದೆ ಎಂದು ಗ್ರಾಹಕರಿಗೆ ಸೂಚಿಸಬೇಕು, ಜೊತೆಗೆ ಅಂದಾಜು ಸಮಯವನ್ನು ಎರಡರಿಂದ ಗುಣಿಸಿದಾಗ ಗಡುವನ್ನು ಬದಲಾಯಿಸಲಾಗುತ್ತದೆ. ಕಾರ್ಯವನ್ನು ವೇಗವಾಗಿ ಮಾಡೋಣ - ಅದ್ಭುತವಾಗಿದೆ, ಪ್ರತಿಯೊಬ್ಬರೂ ಅದರಿಂದ ಪ್ರಯೋಜನ ಪಡೆಯುತ್ತಾರೆ. ಇಲ್ಲದಿದ್ದರೆ, ನಾವು ನಿಮಗೆ ರಕ್ಷಣೆ ನೀಡಿದ್ದೇವೆ.
ಸಿ) ತಂಡದಲ್ಲಿ ನಾವು ಏನು ಸ್ವೀಕರಿಸುವುದಿಲ್ಲ:
- ಬದ್ಧತೆ ಇಲ್ಲದಿರುವುದು, ಹಿಡಿತದ ಕೊರತೆ, ಮರೆವು
- "ಉಪಹಾರವನ್ನು ನೀಡುವುದು." ನೀವು ಕೆಲಸವನ್ನು ಪೂರ್ಣಗೊಳಿಸಲು ಸಾಧ್ಯವಾಗದಿದ್ದರೆ ಮತ್ತು ಹೇಗೆ ಎಂದು ತಿಳಿದಿಲ್ಲದಿದ್ದರೆ, ನೀವು ಅದರ ಬಗ್ಗೆ ತಕ್ಷಣ ತಂಡದ ನಾಯಕನಿಗೆ ತಿಳಿಸಬೇಕು ಮತ್ತು ಕೊನೆಯ ನಿಮಿಷದವರೆಗೆ ಕಾಯಬೇಡಿ.
- ತನ್ನ ಸಾಮರ್ಥ್ಯಗಳು ಮತ್ತು ವೃತ್ತಿಪರತೆಯನ್ನು ಇನ್ನೂ ಸಾಬೀತುಪಡಿಸದ ವ್ಯಕ್ತಿಯಿಂದ ಹುಬ್ಬುಗಳು ಮತ್ತು ಹೆಗ್ಗಳಿಕೆಗಳು. ಅದು ಸಾಬೀತಾದರೆ, ಸಭ್ಯತೆಯ ಮಿತಿಯಲ್ಲಿ ಅದು ಸಾಧ್ಯ :)
- ಅದರ ಎಲ್ಲಾ ರೂಪಗಳಲ್ಲಿ ವಂಚನೆ. ಕಾರ್ಯವನ್ನು ಪೂರ್ಣಗೊಳಿಸದಿದ್ದರೆ, ನೀವು ಅದರ ಸ್ಥಿತಿಯನ್ನು ಪೂರ್ಣಗೊಳಿಸಲು ಬದಲಾಯಿಸಬಾರದು ಮತ್ತು ಕ್ಲೈಂಟ್ ಚಾಟ್‌ನಲ್ಲಿ ಅದು ಸಿದ್ಧವಾಗಿದೆ ಎಂದು ಬರೆಯಿರಿ. ಕಂಪ್ಯೂಟರ್ ಮುರಿದುಹೋಯಿತು, ಸಿಸ್ಟಮ್ ಕ್ರ್ಯಾಶ್ ಆಗಿದೆ, ನಾಯಿ ಲ್ಯಾಪ್ಟಾಪ್ನಲ್ಲಿ ಅಗಿಯಿತು - ಇವೆಲ್ಲವೂ ಸ್ವೀಕಾರಾರ್ಹವಲ್ಲ. ನಿಜವಾದ ಫೋರ್ಸ್ ಮೇಜರ್ ಈವೆಂಟ್ ಸಂಭವಿಸಿದಲ್ಲಿ, ತಂಡದ ನಾಯಕನಿಗೆ ತಕ್ಷಣವೇ ಸೂಚಿಸಬೇಕು.
- ತಜ್ಞರು ಸಾರ್ವಕಾಲಿಕ ಆಫ್‌ಲೈನ್‌ನಲ್ಲಿರುವಾಗ ಮತ್ತು ಕೆಲಸದ ಸಮಯದಲ್ಲಿ ಅವರನ್ನು ತಲುಪಲು ಕಷ್ಟವಾಗುತ್ತದೆ.
- ತಂಡದಲ್ಲಿ ವಿಷತ್ವವನ್ನು ಅನುಮತಿಸಲಾಗುವುದಿಲ್ಲ! ಯಾರಿಗಾದರೂ ಏನಾದರೂ ಭಿನ್ನಾಭಿಪ್ರಾಯವಿದ್ದರೆ, ಎಲ್ಲರೂ ಒಟ್ಟಾಗಿ ಸಭೆ ನಡೆಸಿ ಚರ್ಚಿಸಿ ನಿರ್ಧರಿಸುತ್ತಾರೆ.
ಮತ್ತು ಎಲ್ಲಾ ತಪ್ಪುಗ್ರಹಿಕೆಗಳನ್ನು ತೆರವುಗೊಳಿಸಲು ನಾನು ಕೆಲವೊಮ್ಮೆ ನನ್ನ ಗ್ರಾಹಕರನ್ನು ಕೇಳುವ ಹಲವಾರು ಪ್ರಶ್ನೆಗಳು/ಪ್ರಬಂಧಗಳು:
- ನಿಮ್ಮ ಗುಣಮಟ್ಟದ ಮಾನದಂಡಗಳು ಯಾವುವು?
- ಯೋಜನೆಯು ಸಮಸ್ಯೆಗಳನ್ನು ಹೊಂದಿದೆಯೇ ಅಥವಾ ಇಲ್ಲವೇ ಎಂಬುದನ್ನು ನೀವು ಹೇಗೆ ನಿರ್ಧರಿಸುತ್ತೀರಿ?
- ವ್ಯವಸ್ಥೆಯನ್ನು ಬದಲಾಯಿಸುವ/ಸುಧಾರಿಸುವ ಕುರಿತು ನಮ್ಮ ಎಲ್ಲಾ ಶಿಫಾರಸುಗಳು ಮತ್ತು ಸಲಹೆಗಳನ್ನು ಉಲ್ಲಂಘಿಸುವ ಮೂಲಕ, ಎಲ್ಲಾ ಅಪಾಯಗಳನ್ನು ನೀವು ಮಾತ್ರ ಭರಿಸುತ್ತೀರಿ
- ಯೋಜನೆಗೆ ಯಾವುದೇ ಪ್ರಮುಖ ಬದಲಾವಣೆಗಳು (ಉದಾಹರಣೆಗೆ, ಎಲ್ಲಾ ರೀತಿಯ ಹೆಚ್ಚುವರಿ ಹರಿವು) ದೋಷಗಳ ಸಂಭವನೀಯ ನೋಟಕ್ಕೆ ಕಾರಣವಾಗುತ್ತದೆ (ನಾವು ಅದನ್ನು ಸರಿಪಡಿಸುತ್ತೇವೆ)
- ಯೋಜನೆಯಲ್ಲಿ ಯಾವ ರೀತಿಯ ಸಮಸ್ಯೆ ಸಂಭವಿಸಿದೆ ಎಂಬುದನ್ನು ಒಂದೆರಡು ನಿಮಿಷಗಳಲ್ಲಿ ಅರ್ಥಮಾಡಿಕೊಳ್ಳುವುದು ಅಸಾಧ್ಯ, ಅದನ್ನು ತಕ್ಷಣವೇ ಸರಿಪಡಿಸಿ
- ನಾವು ನಿರ್ದಿಷ್ಟ ಉತ್ಪನ್ನದ ಹರಿವಿನ ಮೇಲೆ ಕೆಲಸ ಮಾಡುತ್ತೇವೆ (ಜಿರಾದಲ್ಲಿನ ಕಾರ್ಯಗಳು - ಅಭಿವೃದ್ಧಿ - ಪರೀಕ್ಷೆ - ನಿಯೋಜಿಸಿ). ಇದರರ್ಥ ನಾವು ಚಾಟ್‌ನಲ್ಲಿ ವಿನಂತಿಗಳು ಮತ್ತು ದೂರುಗಳ ಸಂಪೂರ್ಣ ಹರಿವಿಗೆ ಪ್ರತಿಕ್ರಿಯಿಸಲು ಸಾಧ್ಯವಿಲ್ಲ.
- ಪ್ರೋಗ್ರಾಮರ್ಗಳು ಪ್ರೋಗ್ರಾಮರ್ಗಳು, ವೃತ್ತಿಪರ ಪರೀಕ್ಷಕರು ಅಲ್ಲ ಮತ್ತು ಪ್ರಾಜೆಕ್ಟ್ ಪರೀಕ್ಷೆಯ ಸರಿಯಾದ ಗುಣಮಟ್ಟವನ್ನು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳಲು ಸಾಧ್ಯವಿಲ್ಲ
- ಅಂತಿಮ ಪರೀಕ್ಷೆ ಮತ್ತು ಉತ್ಪಾದನಾ ಕಾರ್ಯಗಳ ಸ್ವೀಕಾರದ ಜವಾಬ್ದಾರಿಯು ಸಂಪೂರ್ಣವಾಗಿ ನಿಮ್ಮೊಂದಿಗೆ ಇರುತ್ತದೆ
- ನಾವು ಈಗಾಗಲೇ ಕಾರ್ಯವನ್ನು ತೆಗೆದುಕೊಂಡಿದ್ದರೆ, ಪ್ರಸ್ತುತವನ್ನು ಪೂರ್ಣಗೊಳಿಸುವವರೆಗೆ ನಾವು ತಕ್ಷಣ ಇತರರಿಗೆ ಬದಲಾಯಿಸಲು ಸಾಧ್ಯವಿಲ್ಲ (ಇಲ್ಲದಿದ್ದರೆ ಇದು ಇನ್ನಷ್ಟು ದೋಷಗಳು ಮತ್ತು ಹೆಚ್ಚಿನ ಅಭಿವೃದ್ಧಿ ಸಮಯಕ್ಕೆ ಕಾರಣವಾಗುತ್ತದೆ)
- ತಂಡದಲ್ಲಿ ಕಡಿಮೆ ಜನರಿದ್ದಾರೆ (ರಜೆಗಳು ಅಥವಾ ಅನಾರೋಗ್ಯದ ಕಾರಣ), ಆದರೆ ಹೆಚ್ಚಿನ ಕೆಲಸವಿದೆ ಮತ್ತು ದೈಹಿಕವಾಗಿ ನಿಮಗೆ ಬೇಕಾದ ಎಲ್ಲದಕ್ಕೂ ಪ್ರತಿಕ್ರಿಯಿಸಲು ನಮಗೆ ಸಮಯವಿರುವುದಿಲ್ಲ
- dev ನಲ್ಲಿ ಪರೀಕ್ಷಿಸಿದ ಕಾರ್ಯಗಳಿಲ್ಲದೆ ಉತ್ಪಾದನೆಗೆ ನಿಯೋಜನೆ ಮಾಡಲು ನಾವು ನಿಮ್ಮನ್ನು ಕೇಳುತ್ತೇವೆ - ಇದು ನಿಮ್ಮ ಅಪಾಯವಾಗಿದೆ, ಡೆವಲಪರ್‌ಗಳಲ್ಲ
- ನೀವು ಅಸ್ಪಷ್ಟ ಕಾರ್ಯಗಳನ್ನು ಹೊಂದಿಸಿದಾಗ, ಸರಿಯಾದ ಹರಿವು ಇಲ್ಲದೆ, ವಿನ್ಯಾಸ ವಿನ್ಯಾಸಗಳಿಲ್ಲದೆ, ಇದಕ್ಕೆ ನಮ್ಮಿಂದ ಹೆಚ್ಚಿನ ಶ್ರಮ ಮತ್ತು ಅನುಷ್ಠಾನದ ಸಮಯ ಬೇಕಾಗುತ್ತದೆ, ಏಕೆಂದರೆ ನಿಮ್ಮ ಬದಲಿಗೆ ನಾವು ಹೆಚ್ಚುವರಿ ಪ್ರಮಾಣದ ಕೆಲಸವನ್ನು ಮಾಡಬೇಕಾಗಿದೆ.
- ದೋಷಗಳ ಮೇಲಿನ ಯಾವುದೇ ಕಾರ್ಯಗಳು, ಅವುಗಳ ಸಂಭವಿಸುವಿಕೆ ಮತ್ತು ಸ್ಕ್ರೀನ್‌ಶಾಟ್‌ಗಳ ವಿವರವಾದ ವಿವರಣೆಯಿಲ್ಲದೆ, ಏನು ತಪ್ಪಾಗಿದೆ ಮತ್ತು ಈ ದೋಷವನ್ನು ನಾವು ಹೇಗೆ ಸರಿಪಡಿಸಬಹುದು ಎಂಬುದನ್ನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳಲು ನಮಗೆ ಅವಕಾಶವನ್ನು ನೀಡುವುದಿಲ್ಲ.
- ಕಾರ್ಯಕ್ಷಮತೆ ಮತ್ತು ಸುರಕ್ಷತೆಯನ್ನು ಸುಧಾರಿಸಲು ಯೋಜನೆಗೆ ನಿರಂತರ ಪರಿಷ್ಕರಣೆ ಮತ್ತು ಸುಧಾರಣೆಗಳ ಅಗತ್ಯವಿದೆ. ಆದ್ದರಿಂದ, ತಂಡವು ಈ ಸುಧಾರಣೆಗಳಲ್ಲಿ ತನ್ನ ಸಮಯದ ಭಾಗವನ್ನು ಕಳೆಯುತ್ತದೆ
- ನಾವು ಗಂಟೆಗೆ ಅಧಿಕ ಸಮಯವನ್ನು ಹೊಂದಿದ್ದೇವೆ (ತುರ್ತು ಪರಿಹಾರಗಳು), ಇತರ ದಿನಗಳಲ್ಲಿ ನಾವು ಅವುಗಳನ್ನು ಸರಿದೂಗಿಸಬೇಕು
ನಿಯಮದಂತೆ, ಸಾಫ್ಟ್ವೇರ್ ಅಭಿವೃದ್ಧಿಯಲ್ಲಿ ಎಲ್ಲವೂ ತುಂಬಾ ಸರಳವಲ್ಲ ಎಂದು ಗ್ರಾಹಕರು ತಕ್ಷಣವೇ ಅರ್ಥಮಾಡಿಕೊಳ್ಳುತ್ತಾರೆ ಮತ್ತು ಬಯಕೆ ಮಾತ್ರ ಸ್ಪಷ್ಟವಾಗಿ ಸಾಕಾಗುವುದಿಲ್ಲ.
ಸಾಮಾನ್ಯವಾಗಿ, ಅಷ್ಟೆ. ನಾನು ತೆರೆಮರೆಯಲ್ಲಿ ಬಹಳಷ್ಟು ಮಾತುಕತೆಗಳನ್ನು ಮತ್ತು ಎಲ್ಲಾ ಪ್ರಕ್ರಿಯೆಗಳ ಆರಂಭಿಕ ಡೀಬಗ್ ಮಾಡುವುದನ್ನು ಬಿಟ್ಟುಬಿಡುತ್ತೇನೆ, ಆದರೆ ಪರಿಣಾಮವಾಗಿ, ಎಲ್ಲವೂ ಕಾರ್ಯರೂಪಕ್ಕೆ ಬಂದವು. ಈ ಪ್ರಕ್ರಿಯೆಯು ನಮಗೆ ಒಂದು ರೀತಿಯ "ಸಿಲ್ವರ್ ಬುಲೆಟ್" ಆಯಿತು ಎಂದು ನಾನು ಹೇಳಬಲ್ಲೆ. ಯೋಜನೆಗೆ ಬಂದ ಹೊಸ ಜನರು ಮೊದಲ ದಿನದಿಂದ ತಕ್ಷಣವೇ ಕೆಲಸದಲ್ಲಿ ತೊಡಗಿಸಿಕೊಳ್ಳಬಹುದು, ಏಕೆಂದರೆ ಎಲ್ಲಾ ಪ್ರಕ್ರಿಯೆಗಳನ್ನು ವಿವರಿಸಲಾಗಿದೆ ಮತ್ತು ರೇಖಾಚಿತ್ರಗಳ ರೂಪದಲ್ಲಿ ದಾಖಲಾತಿ ಮತ್ತು ವಾಸ್ತುಶಿಲ್ಪವು ನಾವೆಲ್ಲರೂ ಇಲ್ಲಿ ಏನು ಮಾಡುತ್ತಿದ್ದೇವೆ ಎಂಬ ಕಲ್ಪನೆಯನ್ನು ತಕ್ಷಣವೇ ನೀಡಿತು.
ಪಿಎಸ್ ನಮ್ಮ ಕಡೆ ಯಾವುದೇ ಪ್ರಾಜೆಕ್ಟ್ ಮ್ಯಾನೇಜರ್ ಇಲ್ಲ ಎಂದು ಸ್ಪಷ್ಟಪಡಿಸಲು ಬಯಸುತ್ತೇನೆ. ಇದು ಗ್ರಾಹಕರ ಬದಿಯಲ್ಲಿದೆ. ಟೆಕ್ಕಿಯೇ ಅಲ್ಲ. ಯುರೋಪಿಯನ್ ಯೋಜನೆ. ಎಲ್ಲಾ ಸಂವಹನವು ಇಂಗ್ಲಿಷ್‌ನಲ್ಲಿ ಮಾತ್ರ.
ನಿಮ್ಮ ಯೋಜನೆಗಳಲ್ಲಿ ಎಲ್ಲರಿಗೂ ಶುಭವಾಗಲಿ. ಸುಟ್ಟುಹೋಗಬೇಡಿ ಮತ್ತು ನಿಮ್ಮ ಪ್ರಕ್ರಿಯೆಗಳನ್ನು ಸುಧಾರಿಸಲು ಪ್ರಯತ್ನಿಸಿ.
ನನ್ನಲ್ಲಿ ಮೂಲ .
ಮೂಲ: www.habr.com