ಎಪಿಗ್ರಾಫ್:
ಒಂದು ಕಾಲದಲ್ಲಿ, ಮುಳ್ಳುಹಂದಿ ಮತ್ತು ಲಿಟಲ್ ಕರಡಿ ಕಾಡಿನಲ್ಲಿ ಭೇಟಿಯಾದವು.
- ಹಲೋ, ಹೆಡ್ಜ್ಹಾಗ್!
- ಹಲೋ, ಲಿಟಲ್ ಬೇರ್!
ಆದ್ದರಿಂದ, ಪದದಿಂದ ಪದ, ಜೋಕ್ ಮೂಲಕ ಜೋಕ್, ಹೆಡ್ಜ್ಹಾಗ್ ಲಿಟಲ್ ಕರಡಿಯಿಂದ ಮುಖಕ್ಕೆ ಹೊಡೆದಿದೆ ...
ಕೆಲಸದ ಸಂಘರ್ಷಗಳ ನಿಶ್ಚಿತಗಳು ಮತ್ತು ಅವುಗಳನ್ನು ನಿರ್ವಹಿಸುವ ಸಂಭವನೀಯ ವಿಧಾನಗಳ ಬಗ್ಗೆ ನಮ್ಮ ತಂಡದ ನಾಯಕ ಮತ್ತು RAS ಉತ್ಪನ್ನ ಅಭಿವೃದ್ಧಿ ನಿರ್ದೇಶಕ ಇಗೊರ್ ಮರ್ನಾಟ್ ಅವರ ಚರ್ಚೆಯನ್ನು ಕೆಳಗೆ ನೀಡಲಾಗಿದೆ.
ಕೆಲಸದಲ್ಲಿ ನಾವು ಎದುರಿಸುವ ಹೆಚ್ಚಿನ ಘರ್ಷಣೆಗಳು ಮೇಲಿನ ಎಪಿಗ್ರಾಫ್‌ನಲ್ಲಿ ವಿವರಿಸಿದಂತೆಯೇ ಒಂದು ಸನ್ನಿವೇಶದ ಪ್ರಕಾರ ಅಭಿವೃದ್ಧಿಗೊಳ್ಳುತ್ತವೆ. ಆರಂಭದಲ್ಲಿ ಪರಸ್ಪರ ಅನುಕೂಲಕರವಾಗಿ ವಿಲೇವಾರಿ ಮಾಡುವ ಹಲವಾರು ಭಾಗವಹಿಸುವವರು ಇದ್ದಾರೆ; ಅವರು ಕೆಲವು ಸಮಸ್ಯೆಯನ್ನು ಪರಿಹರಿಸಲು ಪ್ರಯತ್ನಿಸುತ್ತಿದ್ದಾರೆ, ಆದರೆ ಕೊನೆಯಲ್ಲಿ ಸಮಸ್ಯೆ ಬಗೆಹರಿಯದೆ ಉಳಿದಿದೆ, ಮತ್ತು ಕೆಲವು ಕಾರಣಗಳಿಂದ ಚರ್ಚೆಯಲ್ಲಿ ಭಾಗವಹಿಸುವವರ ನಡುವಿನ ಸಂಬಂಧಗಳು ಹಾಳಾಗುತ್ತವೆ.
ಜೀವನವು ವೈವಿಧ್ಯಮಯವಾಗಿದೆ ಮತ್ತು ಮೇಲೆ ವಿವರಿಸಿದ ಸನ್ನಿವೇಶದಲ್ಲಿ ವ್ಯತ್ಯಾಸಗಳು ಸಂಭವಿಸುತ್ತವೆ. ಕೆಲವೊಮ್ಮೆ ಭಾಗವಹಿಸುವವರ ನಡುವಿನ ಸಂಬಂಧವು ಆರಂಭದಲ್ಲಿ ಉತ್ತಮವಾಗಿಲ್ಲ, ಕೆಲವೊಮ್ಮೆ ನೇರ ಪರಿಹಾರದ ಅಗತ್ಯವಿರುವ ಸಮಸ್ಯೆಯೂ ಇರುವುದಿಲ್ಲ (ಉದಾಹರಣೆಗೆ, ಎಪಿಗ್ರಾಫ್‌ನಲ್ಲಿ), ಕೆಲವೊಮ್ಮೆ ಚರ್ಚೆಯ ನಂತರ ಸಂಬಂಧವು ಪ್ರಾರಂಭವಾಗುವ ಮೊದಲಿನಂತೆಯೇ ಇರುತ್ತದೆ, ಆದರೆ ಸಮಸ್ಯೆಯನ್ನು ಅಂತಿಮವಾಗಿ ಪರಿಹರಿಸಲಾಗಿಲ್ಲ.
ಕೆಲಸದ ಸಂಘರ್ಷದ ಪರಿಸ್ಥಿತಿ ಎಂದು ವ್ಯಾಖ್ಯಾನಿಸಬಹುದಾದ ಎಲ್ಲಾ ಸಂದರ್ಭಗಳಲ್ಲಿ ಸಾಮಾನ್ಯವಾದದ್ದು ಯಾವುದು?
ಮೊದಲನೆಯದಾಗಿ, ಎರಡು ಅಥವಾ ಹೆಚ್ಚಿನ ಬದಿಗಳಿವೆ. ಈ ಪಕ್ಷಗಳು ಸಂಸ್ಥೆಯಲ್ಲಿ ವಿವಿಧ ಸ್ಥಳಗಳನ್ನು ಆಕ್ರಮಿಸಿಕೊಳ್ಳಬಹುದು, ಸಮಾನತೆಯ ಸಂಬಂಧದಲ್ಲಿರಬಹುದು (ತಂಡದಲ್ಲಿ ಸಹೋದ್ಯೋಗಿಗಳು), ಅಥವಾ ಶ್ರೇಣಿಯ ವಿವಿಧ ಹಂತಗಳಲ್ಲಿ (ಬಾಸ್ - ಅಧೀನ), ವೈಯಕ್ತಿಕ (ಉದ್ಯೋಗಿ) ಅಥವಾ ಗುಂಪು (ಒಂದು ನಡುವಿನ ಸಂಘರ್ಷದ ಸಂದರ್ಭಗಳಲ್ಲಿ ಉದ್ಯೋಗಿ ಮತ್ತು ಒಂದು ತಂಡ ಅಥವಾ ಎರಡು ತಂಡಗಳು), ಇತ್ಯಾದಿ. ಸಂಘರ್ಷದ ಸಾಧ್ಯತೆ ಮತ್ತು ಅದರ ಪರಿಹಾರದ ಸುಲಭತೆಯು ಭಾಗವಹಿಸುವವರ ನಡುವಿನ ನಂಬಿಕೆಯ ಮಟ್ಟದಿಂದ ಹೆಚ್ಚು ಪ್ರಭಾವಿತವಾಗಿರುತ್ತದೆ. ಪಕ್ಷಗಳು ಒಬ್ಬರಿಗೊಬ್ಬರು ಚೆನ್ನಾಗಿ ತಿಳಿದಿದ್ದರೆ, ನಂಬಿಕೆಯ ಮಟ್ಟವು ಹೆಚ್ಚಾಗುತ್ತದೆ, ಅವರು ಒಪ್ಪಂದಕ್ಕೆ ಬರುವ ಸಾಧ್ಯತೆ ಹೆಚ್ಚು. ಉದಾಹರಣೆಗೆ, ಎಂದಿಗೂ ಮುಖಾಮುಖಿಯಾಗಿ ಸಂವಹನ ನಡೆಸದ ವಿತರಣಾ ತಂಡದ ಸದಸ್ಯರು ಕನಿಷ್ಠ ಕೆಲವು ಮುಖಾಮುಖಿ ಸಂವಾದಗಳನ್ನು ಹೊಂದಿರುವ ಜನರಿಗಿಂತ ಸರಳವಾದ ಕೆಲಸದ ಸಮಸ್ಯೆಯಲ್ಲಿ ಸಂಘರ್ಷವನ್ನು ಅನುಭವಿಸುವ ಸಾಧ್ಯತೆ ಹೆಚ್ಚು. ಆದ್ದರಿಂದ, ವಿತರಿಸಿದ ತಂಡಗಳಲ್ಲಿ ಕೆಲಸ ಮಾಡುವಾಗ, ಎಲ್ಲಾ ತಂಡದ ಸದಸ್ಯರು ನಿಯತಕಾಲಿಕವಾಗಿ ಪರಸ್ಪರ ವೈಯಕ್ತಿಕವಾಗಿ ಭೇಟಿಯಾಗುವುದನ್ನು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳುವುದು ಬಹಳ ಮುಖ್ಯ.
ಎರಡನೆಯದಾಗಿ, ಕೆಲಸದಲ್ಲಿ ಸಂಘರ್ಷದ ಪರಿಸ್ಥಿತಿಯಲ್ಲಿ, ಪಕ್ಷಗಳು ಒಂದು ಪಕ್ಷಕ್ಕೆ, ಇಬ್ಬರಿಗೆ ಅಥವಾ ಒಟ್ಟಾರೆಯಾಗಿ ಸಂಘಟನೆಗೆ ಮುಖ್ಯವಾದ ಕೆಲವು ಸಮಸ್ಯೆಯನ್ನು ಪರಿಹರಿಸುವ ಪರಿಸ್ಥಿತಿಯಲ್ಲಿದೆ. ಅದೇ ಸಮಯದಲ್ಲಿ, ಪರಿಸ್ಥಿತಿಯ ವಿಶಿಷ್ಟತೆಗಳಿಂದಾಗಿ, ಪಕ್ಷಗಳು ಸಾಮಾನ್ಯವಾಗಿ ಸಾಕಷ್ಟು ಸಮಯ ಮತ್ತು ಅದನ್ನು ಪರಿಹರಿಸಲು ವಿವಿಧ ಮಾರ್ಗಗಳನ್ನು ಹೊಂದಿರುತ್ತವೆ (ಔಪಚಾರಿಕ, ಅನೌಪಚಾರಿಕ, ಸಭೆಗಳು, ಪತ್ರಗಳು, ನಿರ್ವಹಣಾ ನಿರ್ಧಾರಗಳು, ತಂಡದ ಗುರಿಗಳು ಮತ್ತು ಯೋಜನೆಗಳ ಉಪಸ್ಥಿತಿ, ಕ್ರಮಾನುಗತದ ಸಂಗತಿ, ಇತ್ಯಾದಿ). ಸಂಸ್ಥೆಯಲ್ಲಿನ ಕೆಲಸದ (ಅಥವಾ ಕೆಲಸ ಮಾಡದ) ಸಮಸ್ಯೆಯನ್ನು ಪರಿಹರಿಸುವ ಪರಿಸ್ಥಿತಿಯಿಂದ ಇದು ವಿಭಿನ್ನವಾಗಿದೆ, ಉದಾಹರಣೆಗೆ, ಒಂದು ಪ್ರಮುಖ ಪ್ರಶ್ನೆಯನ್ನು ಪರಿಹರಿಸುವುದು: "ಓಹ್, ಮಗು, ನೀವು ಯಾವ ಪ್ರದೇಶದವರು?!" ಬೀದಿಯಲ್ಲಿ, ಅಥವಾ ಶಿಲಾಶಾಸನದಿಂದ ಸಂಘರ್ಷ. ಕೆಲಸದ ಸಮಸ್ಯೆಯನ್ನು ಪರಿಹರಿಸುವ ಸಂದರ್ಭದಲ್ಲಿ, ಕೆಲಸದ ಪ್ರಕ್ರಿಯೆಯ ಗುಣಮಟ್ಟ ಮತ್ತು ತಂಡದ ವಿಷಯದಲ್ಲಿ ಸಮಸ್ಯೆಗಳನ್ನು ಪರಿಹರಿಸುವ ಸಂಸ್ಕೃತಿ.
ಮೂರನೆಯದಾಗಿ, ಸಂಘರ್ಷದ ನಿರ್ಣಾಯಕ ಅಂಶವೆಂದರೆ (ನಮ್ಮ ಚರ್ಚೆಯ ದೃಷ್ಟಿಕೋನದಿಂದ) ಪ್ರಕ್ರಿಯೆಯ ಪಕ್ಷಗಳು ಸ್ವತಂತ್ರವಾಗಿ ಎಲ್ಲಾ ಪಕ್ಷಗಳಿಗೆ ಸೂಕ್ತವಾದ ಸಮಸ್ಯೆಯನ್ನು ಪರಿಹರಿಸಲು ಸಾಧ್ಯವಿಲ್ಲ. ಪರಿಸ್ಥಿತಿಗೆ ಮೂರನೇ ವ್ಯಕ್ತಿಯ ಹಸ್ತಕ್ಷೇಪದ ಅಗತ್ಯವಿದೆ, ಬಾಹ್ಯ ಮಧ್ಯಸ್ಥಗಾರ. ಈ ಅಂಶವು ವಿವಾದಾಸ್ಪದವಾಗಿ ಕಾಣಿಸಬಹುದು, ಆದರೆ ಮೂಲಭೂತವಾಗಿ, ಬಾಹ್ಯ ಮಧ್ಯಸ್ಥಿಕೆಯಿಲ್ಲದೆ ಸಂಘರ್ಷದ ಪರಿಸ್ಥಿತಿಯನ್ನು ಯಶಸ್ವಿಯಾಗಿ ಪರಿಹರಿಸಿದರೆ, ಸಮಸ್ಯೆಯನ್ನು ಯಶಸ್ವಿಯಾಗಿ ಪರಿಹರಿಸಲಾಗಿದೆ ಮತ್ತು ಪಕ್ಷಗಳ ಸಂಬಂಧಗಳು ಹದಗೆಡಲಿಲ್ಲ, ಇದು ನಾವು ಶ್ರಮಿಸಬೇಕಾದ ಪರಿಸ್ಥಿತಿಯಾಗಿದೆ. . ಅಂತಹ ಸಂಘರ್ಷದ ಬಗ್ಗೆ ನಮಗೆ ತಿಳಿದಿರುವುದಿಲ್ಲ, ಅಥವಾ ಅದನ್ನು ಪರಿಹರಿಸಿದ ನಂತರ ನಾವು ಆಕಸ್ಮಿಕವಾಗಿ ಕಂಡುಕೊಳ್ಳುತ್ತೇವೆ. ತಂಡವು ತನ್ನದೇ ಆದ ಮೇಲೆ ಹೆಚ್ಚು ಸಮಸ್ಯೆಗಳನ್ನು ಪರಿಹರಿಸಬಹುದು, ಅದು ಹೆಚ್ಚು ಪರಿಣಾಮಕಾರಿಯಾಗಿರುತ್ತದೆ.
ಸ್ಪರ್ಶಕ್ಕೆ ಯೋಗ್ಯವಾದ ಸಂಘರ್ಷದ ಮತ್ತೊಂದು ವಿಶಿಷ್ಟ ಲಕ್ಷಣವೆಂದರೆ ನಿರ್ಧಾರದ ಸಮಯದಲ್ಲಿ ಭಾವನಾತ್ಮಕ ತೀವ್ರತೆಯ ಮಟ್ಟ. ಸಂಘರ್ಷವು ಹೆಚ್ಚಿನ ಭಾವನಾತ್ಮಕ ಮಟ್ಟದೊಂದಿಗೆ ಅಗತ್ಯವಾಗಿ ಸಂಬಂಧಿಸಿಲ್ಲ. ಸನ್ನಿವೇಶವು ಮೂಲಭೂತವಾಗಿ ಸಂಘರ್ಷವಾಗಲು ಭಾಗವಹಿಸುವವರು ಕೂಗು ಮತ್ತು ಕೈಗಳನ್ನು ಬೀಸಬೇಕಾಗಿಲ್ಲ. ಸಮಸ್ಯೆಯನ್ನು ಪರಿಹರಿಸಲಾಗಿಲ್ಲ, ಒಂದು ನಿರ್ದಿಷ್ಟ ಭಾವನಾತ್ಮಕ ಉದ್ವೇಗವಿದೆ (ಬಹುಶಃ ಅದು ಸ್ಪಷ್ಟವಾಗಿ ಬಾಹ್ಯವಾಗಿ ವ್ಯಕ್ತಪಡಿಸಲಾಗಿಲ್ಲ), ಅಂದರೆ ನಾವು ಸಂಘರ್ಷದ ಪರಿಸ್ಥಿತಿಯನ್ನು ಎದುರಿಸುತ್ತಿದ್ದೇವೆ.
ಸಂಘರ್ಷದ ಸಂದರ್ಭಗಳಲ್ಲಿ ಮಧ್ಯಪ್ರವೇಶಿಸುವುದು ಅಗತ್ಯವೇ ಅಥವಾ ಅವರ ಪರಿಹಾರವು ಅದರ ಕೋರ್ಸ್ ಅನ್ನು ತೆಗೆದುಕೊಳ್ಳಲು ಮತ್ತು ಸಮಸ್ಯೆಯು ಸ್ವತಃ ಪರಿಹರಿಸಲು ಕಾಯಲು ಅವಕಾಶ ನೀಡುವುದು ಉತ್ತಮವೇ? ಅಗತ್ಯವಿದೆ. ಸಂಘರ್ಷವನ್ನು ಸಂಪೂರ್ಣವಾಗಿ ಪರಿಹರಿಸುವುದು ಯಾವಾಗಲೂ ನಿಮ್ಮ ಶಕ್ತಿ ಅಥವಾ ಸಾಮರ್ಥ್ಯದಲ್ಲಿಲ್ಲ, ಆದರೆ ಯಾವುದೇ ಪರಿಸ್ಥಿತಿಯಲ್ಲಿ, ಯಾವುದೇ ಪ್ರಮಾಣದ ಸಂಘರ್ಷದಲ್ಲಿ, ನೀವು ವಯಸ್ಕ ಸ್ಥಾನವನ್ನು ತೆಗೆದುಕೊಳ್ಳಬಹುದು, ಆ ಮೂಲಕ ನಿಮ್ಮ ಸುತ್ತಲಿರುವ ಹಲವಾರು ಜನರನ್ನು ಅದಕ್ಕೆ ತರಬಹುದು, ಋಣಾತ್ಮಕ ಪರಿಣಾಮಗಳನ್ನು ತಗ್ಗಿಸಬಹುದು. ಸಂಘರ್ಷ ಮತ್ತು ಅದರ ಪರಿಹಾರಕ್ಕೆ ಕೊಡುಗೆ ನೀಡಿ.
ಸಂಘರ್ಷದ ಸಂದರ್ಭಗಳ ಕೆಲವು ಉದಾಹರಣೆಗಳನ್ನು ನೋಡುವ ಮೊದಲು, ಎಲ್ಲಾ ಸಂಘರ್ಷಗಳಿಗೆ ಸಾಮಾನ್ಯವಾದ ಕೆಲವು ಪ್ರಮುಖ ಅಂಶಗಳನ್ನು ನೋಡೋಣ.
ಸಂಘರ್ಷವನ್ನು ಪರಿಹರಿಸುವಾಗ, ಹೋರಾಟಕ್ಕಿಂತ ಮೇಲಿರುವುದು ಮುಖ್ಯ, ಮತ್ತು ಅದರೊಳಗೆ ಅಲ್ಲ (ಇದನ್ನು "ಮೆಟಾ-ಸ್ಥಾನವನ್ನು ತೆಗೆದುಕೊಳ್ಳುವುದು" ಎಂದೂ ಕರೆಯುತ್ತಾರೆ), ಅಂದರೆ, ನಿರ್ಣಯ ಪ್ರಕ್ರಿಯೆಯಲ್ಲಿ ಪಕ್ಷಗಳ ಒಂದು ಭಾಗವಾಗಿರಬಾರದು. ಇಲ್ಲದಿದ್ದರೆ, ನಿರ್ಧಾರಕ್ಕೆ ಸಹಾಯ ಮಾಡುವ ಬಾಹ್ಯ ಮಧ್ಯಸ್ಥಿಕೆಯು ಇತರ ಪಕ್ಷಕ್ಕೆ ಹಾನಿಯಾಗುವಂತೆ ಪಕ್ಷಗಳಲ್ಲಿ ಒಬ್ಬರ ಸ್ಥಾನವನ್ನು ಬಲಪಡಿಸುತ್ತದೆ. ನಿರ್ಧಾರವನ್ನು ತೆಗೆದುಕೊಳ್ಳುವಾಗ, ಅದನ್ನು ಎಲ್ಲಾ ಪಕ್ಷಗಳು ನೈತಿಕವಾಗಿ ಒಪ್ಪಿಕೊಳ್ಳುವುದು ಮುಖ್ಯ, ಅವರು ಹೇಳಿದಂತೆ, "ಖರೀದಿಸಲಾಗಿದೆ". ಆದ್ದರಿಂದ, ಪಕ್ಷಗಳು ಮಾಡಿದ ನಿರ್ಧಾರದಿಂದ ಸಂತೋಷವಾಗದಿದ್ದರೂ, ಅವರು ಅದನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸಲು ಪ್ರಾಮಾಣಿಕವಾಗಿ ಒಪ್ಪಿಕೊಂಡರು. ಅವರು ಹೇಳಿದಂತೆ, ಒಪ್ಪುವುದಿಲ್ಲ ಮತ್ತು ಬದ್ಧರಾಗಲು ಸಾಧ್ಯವಾಗುತ್ತದೆ. ಇಲ್ಲದಿದ್ದರೆ, ಸಂಘರ್ಷವು ಅದರ ನೋಟವನ್ನು ಸರಳವಾಗಿ ಬದಲಾಯಿಸುತ್ತದೆ, ಹೊಗೆಯಾಡಿಸುವ ಬೆಂಕಿಯು ಪೀಟ್ ಬಾಗ್ ಅಡಿಯಲ್ಲಿ ಉಳಿಯುತ್ತದೆ ಮತ್ತು ಕೆಲವು ಹಂತದಲ್ಲಿ ಅನಿವಾರ್ಯವಾಗಿ ಮತ್ತೆ ಭುಗಿಲೆದ್ದಿದೆ.
ಎರಡನೆಯ ಅಂಶವೆಂದರೆ, ಮೊದಲನೆಯದಕ್ಕೆ ಭಾಗಶಃ ಸಂಬಂಧಿಸಿದೆ, ನೀವು ಈಗಾಗಲೇ ಸಂಘರ್ಷವನ್ನು ಪರಿಹರಿಸುವಲ್ಲಿ ಭಾಗವಹಿಸಲು ನಿರ್ಧರಿಸಿದ್ದರೆ, ಸಂವಹನಗಳ ದೃಷ್ಟಿಕೋನದಿಂದ ಮತ್ತು ಸಂದರ್ಭವನ್ನು ಅಧ್ಯಯನ ಮಾಡುವ ದೃಷ್ಟಿಯಿಂದ ಅದನ್ನು ಗಂಭೀರವಾಗಿ ಪರಿಗಣಿಸಿ. ಪ್ರತಿಯೊಂದು ಪಕ್ಷಗಳೊಂದಿಗೆ ವೈಯಕ್ತಿಕವಾಗಿ ಮಾತನಾಡಿ. ಪ್ರತಿಯೊಂದಕ್ಕೂ ಪ್ರತ್ಯೇಕವಾಗಿ, ಆರಂಭಿಕರಿಗಾಗಿ. ಮೇಲ್ಗಾಗಿ ನೆಲೆಗೊಳ್ಳಬೇಡಿ. ವಿತರಿಸಿದ ತಂಡದ ಸಂದರ್ಭದಲ್ಲಿ, ಕನಿಷ್ಠ ವೀಡಿಯೊ ಲಿಂಕ್ ಮೂಲಕ ಮಾತನಾಡಿ. ಕಿವಿಮಾತು ಮತ್ತು ಪ್ರತ್ಯಕ್ಷದರ್ಶಿಗಳ ವರದಿಗಳಿಂದ ತೃಪ್ತರಾಗಬೇಡಿ. ಕಥೆಯನ್ನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳಿ, ಪ್ರತಿಯೊಂದು ಕಡೆಯವರು ಏನು ಬಯಸುತ್ತಾರೆ, ಅವರು ಏಕೆ ಬಯಸುತ್ತಾರೆ, ಅವರು ಏನನ್ನು ನಿರೀಕ್ಷಿಸುತ್ತಾರೆ, ಅವರು ಈ ಸಮಸ್ಯೆಯನ್ನು ಮೊದಲು ಪರಿಹರಿಸಲು ಪ್ರಯತ್ನಿಸಿದ್ದಾರೆ, ಅದನ್ನು ಪರಿಹರಿಸದಿದ್ದರೆ ಏನಾಗುತ್ತದೆ, ಅವರು ಯಾವ ಪರಿಹಾರಗಳನ್ನು ನೋಡುತ್ತಾರೆ, ಅವರು ಯಾವ ಸ್ಥಾನವನ್ನು ಊಹಿಸುತ್ತಾರೆ ಇನ್ನೊಂದು ಕಡೆ, ಅವರು ಏನು ಯೋಚಿಸುತ್ತಾರೆ, ಸರಿ ಅಥವಾ ತಪ್ಪು, ಇತ್ಯಾದಿ. ಎಲ್ಲರೂ ಸರಿ ಎಂದು ಭಾವಿಸಿ, ಮುಕ್ತ ಮನಸ್ಸಿನಿಂದ ನಿಮ್ಮ ತಲೆಗೆ ಎಲ್ಲಾ ಸಂಭವನೀಯ ಸಂದರ್ಭಗಳನ್ನು ಲೋಡ್ ಮಾಡಿ. ನೀವು ಸಂಘರ್ಷದ ಒಳಗೆ ಇಲ್ಲ, ನೀವು ಅದರ ಹೊರಗೆ, ಒಂದು ರೂಪಾಂತರದಲ್ಲಿ. ಸಂದರ್ಭವು ಪೋಸ್ಟ್ ಥ್ರೆಡ್‌ನಲ್ಲಿ ಮಾತ್ರ ಲಭ್ಯವಿದ್ದರೆ, ಕನಿಷ್ಠ ಅದನ್ನು ಸಂಪೂರ್ಣವಾಗಿ ಮತ್ತು ಅದಕ್ಕೆ ಸಂಬಂಧಿಸಿದ ಥ್ರೆಡ್‌ಗಳು ಮತ್ತು ದಾಖಲೆಗಳನ್ನು ಓದಿ. ನೀವು ಅದನ್ನು ಓದಿದ ನಂತರ, ಇನ್ನೂ ನಿಮ್ಮ ಧ್ವನಿಯಲ್ಲಿ ಮಾತನಾಡಿ. ಮೇಲ್‌ನಲ್ಲಿ ಇಲ್ಲದ ಯಾವುದೋ ಮುಖ್ಯವಾದುದನ್ನು ಕೇಳಲು ನಿಮಗೆ ಬಹುತೇಕ ಖಾತ್ರಿಯಿದೆ.
ಮೂರನೆಯ ಪ್ರಮುಖ ಅಂಶವೆಂದರೆ ಸಂವಹನದ ಸಾಮಾನ್ಯ ವಿಧಾನ. ಇವು ಸಾಮಾನ್ಯ ವಿಷಯಗಳು, ಕಾಸ್ಮಿಕ್ ಏನೂ ಇಲ್ಲ, ಆದರೆ ಅವು ಬಹಳ ಮುಖ್ಯ. ನಾವು ಸಮಯವನ್ನು ಉಳಿಸಲು ಪ್ರಯತ್ನಿಸುವುದಿಲ್ಲ, ನಾವು ಎಲ್ಲಾ ಭಾಗವಹಿಸುವವರೊಂದಿಗೆ ಮಾತನಾಡುತ್ತೇವೆ, ನಾವು ವ್ಯಕ್ತಿಯನ್ನು ಟೀಕಿಸುವುದಿಲ್ಲ, ಆದರೆ ನಾವು ಅವರ ಕ್ರಿಯೆಗಳ ಪರಿಣಾಮಗಳನ್ನು ಪರಿಗಣಿಸುತ್ತೇವೆ ("ನೀವು ಅಸಭ್ಯ" ಅಲ್ಲ, ಆದರೆ "ಬಹುಶಃ ಹುಡುಗರಿಗೆ ಮನನೊಂದಿರಬಹುದು. ಈ ವಿಷಯ”), ನಾವು ಮುಖವನ್ನು ಉಳಿಸಲು ಅವಕಾಶವನ್ನು ನೀಡುತ್ತೇವೆ, ನಾವು ವೈಯಕ್ತಿಕವಾಗಿ ಚರ್ಚೆಗಳನ್ನು ನಡೆಸುತ್ತೇವೆ, ರೇಖೆಯ ಮುಂದೆ ಅಲ್ಲ.
ಘರ್ಷಣೆಗಳು ಸಾಮಾನ್ಯವಾಗಿ ಎರಡು ಕಾರಣಗಳಲ್ಲಿ ಒಂದರಿಂದ ಉಂಟಾಗುತ್ತವೆ. ಮೊದಲನೆಯದು ಸಂಘರ್ಷದ ಸಮಯದಲ್ಲಿ ಒಬ್ಬ ವ್ಯಕ್ತಿಯು ವಯಸ್ಕ ಅಥವಾ ಮಗುವಿನ ಸ್ಥಾನದಲ್ಲಿದೆಯೇ ಎಂಬುದಕ್ಕೆ ಸಂಬಂಧಿಸಿದೆ (ಇದನ್ನು ಕೆಳಗೆ ಹೆಚ್ಚು). ಇದು ಅವನ ಭಾವನಾತ್ಮಕ ಪರಿಪಕ್ವತೆಯಿಂದಾಗಿ, ಅವನ ಭಾವನೆಗಳನ್ನು ನಿರ್ವಹಿಸುವ ಸಾಮರ್ಥ್ಯ (ಇದು ಯಾವಾಗಲೂ ಅವನ ವಯಸ್ಸಿಗೆ ಸಂಬಂಧಿಸಿಲ್ಲ). ಎರಡನೆಯ ಸಾಮಾನ್ಯ ಕಾರಣವೆಂದರೆ ಕೆಲಸದ ಪ್ರಕ್ರಿಯೆಯ ಅಪೂರ್ಣತೆ, ಇದು ಭಾಗವಹಿಸುವವರ ನಡುವೆ ಜವಾಬ್ದಾರಿಯನ್ನು ಹರಡುವ ಬೂದು ಪ್ರದೇಶಗಳ ಸಂದರ್ಭಗಳನ್ನು ಸೃಷ್ಟಿಸುತ್ತದೆ, ಪಕ್ಷಗಳ ನಿರೀಕ್ಷೆಗಳು ಪರಸ್ಪರ ಪಾರದರ್ಶಕವಾಗಿರುವುದಿಲ್ಲ ಮತ್ತು ಪ್ರಕ್ರಿಯೆಯಲ್ಲಿನ ಪಾತ್ರಗಳು ಮಸುಕಾಗಿರುತ್ತವೆ.
ಅಂತೆಯೇ, ಸಂಘರ್ಷವನ್ನು (ಹಾಗೆಯೇ ಇತರ ಯಾವುದೇ ಸಮಸ್ಯೆ) ಪರಿಹರಿಸುವಲ್ಲಿ, ವ್ಯವಸ್ಥಾಪಕರು ಮೂರು ದೃಷ್ಟಿಕೋನಗಳನ್ನು ನೆನಪಿನಲ್ಲಿಟ್ಟುಕೊಳ್ಳಬೇಕು: ಅಲ್ಪಾವಧಿಯ - ಇಲ್ಲಿ ಮತ್ತು ಈಗ ಸಮಸ್ಯೆ/ಸಂಘರ್ಷವನ್ನು ಪರಿಹರಿಸಲು, ಮಧ್ಯಮಾವಧಿ - ಮತ್ತೊಂದು ಸಂಘರ್ಷದ ಸಂಭವನೀಯತೆಯನ್ನು ಕಡಿಮೆ ಮಾಡಲು ಅದೇ ಕಾರಣಕ್ಕಾಗಿ, ಮತ್ತು ದೀರ್ಘಕಾಲದ - ತಂಡದ ವ್ಯಕ್ತಿಯಲ್ಲಿ ವಯಸ್ಕ ಸಂಸ್ಕೃತಿಯನ್ನು ಬೆಳೆಸಲು.
ನಮ್ಮಲ್ಲಿ ಪ್ರತಿಯೊಬ್ಬರಿಗೂ ಒಳಗಿನ ಮಗುವಿದೆ, ಸುಮಾರು ಮೂರು ಅಥವಾ ನಾಲ್ಕು ವರ್ಷಗಳು. ಅವನು ಕೆಲಸದಲ್ಲಿ ಹೆಚ್ಚಿನ ಸಮಯವನ್ನು ನಿದ್ರಿಸುತ್ತಾನೆ, ಆದರೆ ಕೆಲವೊಮ್ಮೆ ಎಚ್ಚರಗೊಂಡು ನಿಯಂತ್ರಣವನ್ನು ತೆಗೆದುಕೊಳ್ಳುತ್ತಾನೆ. ಮಗುವಿಗೆ ತನ್ನದೇ ಆದ ಆದ್ಯತೆಗಳಿವೆ. ಇದು ಅವನ ಸ್ಯಾಂಡ್‌ಬಾಕ್ಸ್ ಎಂದು ಒತ್ತಾಯಿಸುವುದು ಅವನಿಗೆ ಮುಖ್ಯವಾಗಿದೆ, ಅವನ ತಾಯಿ ಅವನನ್ನು ಹೆಚ್ಚು ಪ್ರೀತಿಸುತ್ತಾಳೆ, ಅವನ ಯಂತ್ರವು ಅತ್ಯುತ್ತಮವಾಗಿದೆ (ವಿನ್ಯಾಸವು ಅತ್ಯುತ್ತಮವಾಗಿದೆ, ಅವನು ಅತ್ಯುತ್ತಮವಾಗಿ ಪ್ರೋಗ್ರಾಂ ಮಾಡುತ್ತಾನೆ, ...). ಸಂಘರ್ಷದ ಪರಿಸ್ಥಿತಿಯಲ್ಲಿ, ಮಗುವು ಆಟಿಕೆಗಳನ್ನು ಒತ್ತಬಹುದು, ಕಾಲುಗಳನ್ನು ಹೊಡೆಯಬಹುದು ಮತ್ತು ಸ್ಪಾಟುಲಾವನ್ನು ಒಡೆಯಬಹುದು, ಆದರೆ ವಯಸ್ಕ ಸಮಸ್ಯೆಗಳನ್ನು ಪರಿಹರಿಸಲು ಸಾಧ್ಯವಿಲ್ಲ (ಪರಿಹಾರ ವಾಸ್ತುಶಿಲ್ಪ, ಸ್ವಯಂಚಾಲಿತ ಪರೀಕ್ಷೆಯ ವಿಧಾನಗಳು, ಬಿಡುಗಡೆ ದಿನಾಂಕಗಳು, ಇತ್ಯಾದಿ), ಅವನು ಪ್ರಯೋಜನಗಳ ವಿಷಯದಲ್ಲಿ ಯೋಚಿಸುವುದಿಲ್ಲ. ತಂಡಕ್ಕಾಗಿ. ಸಂಘರ್ಷದಲ್ಲಿರುವ ಮಗುವನ್ನು ತನ್ನ ವಯಸ್ಕನನ್ನು ಕರೆಯುವಂತೆ ಕೇಳುವ ಮೂಲಕ ಪ್ರೋತ್ಸಾಹಿಸಬಹುದು, ಸಮಾಧಾನಪಡಿಸಬಹುದು ಮತ್ತು ಮಲಗಲು ಕಳುಹಿಸಬಹುದು. ಸಂಘರ್ಷದ ಪರಿಸ್ಥಿತಿಯಲ್ಲಿ ಚರ್ಚೆಯನ್ನು ಪ್ರಾರಂಭಿಸುವ ಮೊದಲು, ನೀವು ವಯಸ್ಕರೊಂದಿಗೆ ಮಾತನಾಡುತ್ತಿದ್ದೀರಿ, ಮಗುವಿನೊಂದಿಗೆ ಅಲ್ಲ ಮತ್ತು ನೀವೇ ವಯಸ್ಕರ ಸ್ಥಾನದಲ್ಲಿದೆ ಎಂದು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳಿ. ಈ ಸಮಯದಲ್ಲಿ ನಿಮ್ಮ ಪ್ರಾಮಾಣಿಕ ಗುರಿಯು ಗಂಭೀರ ಸಮಸ್ಯೆಯನ್ನು ಪರಿಹರಿಸುವುದಾಗಿದ್ದರೆ, ನೀವು ವಯಸ್ಕರ ಸ್ಥಾನದಲ್ಲಿರುತ್ತೀರಿ. ನಿಮ್ಮ ಪಾದಗಳನ್ನು ಸ್ಟಾಂಪ್ ಮಾಡುವುದು ಮತ್ತು ನಿಮ್ಮ ಭುಜದ ಬ್ಲೇಡ್ ಅನ್ನು ಬಿರುಕುಗೊಳಿಸುವುದು ನಿಮ್ಮ ಗುರಿಯಾಗಿದ್ದರೆ, ಇದು ಬಾಲಿಶ ಸ್ಥಾನವಾಗಿದೆ. ನಿಮ್ಮ ಒಳಗಿನ ಮಗುವನ್ನು ಮಲಗಲು ಕಳುಹಿಸಿ ಮತ್ತು ವಯಸ್ಕರನ್ನು ಕರೆ ಮಾಡಿ ಅಥವಾ ಚರ್ಚೆಯನ್ನು ಮರುಹೊಂದಿಸಿ. ಒಬ್ಬ ವ್ಯಕ್ತಿಯು ಭಾವನಾತ್ಮಕ ನಿರ್ಧಾರವನ್ನು ತೆಗೆದುಕೊಳ್ಳುತ್ತಾನೆ ಮತ್ತು ಅದಕ್ಕೆ ತರ್ಕಬದ್ಧ ಸಮರ್ಥನೆಯನ್ನು ಹುಡುಕುತ್ತಾನೆ. ಮಕ್ಕಳ ಆದ್ಯತೆಗಳ ಆಧಾರದ ಮೇಲೆ ಮಗುವಿನ ನಿರ್ಧಾರವು ಸೂಕ್ತವಾಗಿರುವುದಿಲ್ಲ.
ಸಂಘರ್ಷದ ಸಮಯದಲ್ಲಿ ನಡವಳಿಕೆಯ ಜೊತೆಗೆ, ಮಗುವಿನ ಅಥವಾ ವಯಸ್ಕನ ಸ್ಥಾನವು ಒಬ್ಬ ವ್ಯಕ್ತಿಯು ತನ್ನನ್ನು ತಾನೇ ತೆಗೆದುಕೊಳ್ಳಲು ಸಿದ್ಧವಾಗಿರುವ ಜವಾಬ್ದಾರಿಯ ಮಟ್ಟದಿಂದ ಕೂಡ ನಿರೂಪಿಸಲ್ಪಡುತ್ತದೆ. ಅದರ ವಿಪರೀತ ಅಭಿವ್ಯಕ್ತಿಗಳಲ್ಲಿ, ನಾನು ಒಂದಕ್ಕಿಂತ ಹೆಚ್ಚು ಬಾರಿ ಭೇಟಿಯಾದ ಪ್ರೋಗ್ರಾಮರ್ನ ಬಾಲಿಶ ಸ್ಥಾನವು ಈ ರೀತಿ ಕಾಣುತ್ತದೆ: ನಾನು ಕೋಡ್ ಅನ್ನು ಬರೆದಿದ್ದೇನೆ, ಅದನ್ನು ವಿಮರ್ಶೆಗೆ ಕಳುಹಿಸಿದೆ - ನನ್ನ ಕೆಲಸ ಮುಗಿದಿದೆ. ವಿಮರ್ಶಕರು ಅದನ್ನು ಪರಿಶೀಲಿಸಬೇಕು ಮತ್ತು ಅನುಮೋದಿಸಬೇಕು, QA ಅದನ್ನು ಪರಿಶೀಲಿಸಬೇಕು, ಸಮಸ್ಯೆಗಳಿದ್ದರೆ, ಅವರು ನನಗೆ ತಿಳಿಸುತ್ತಾರೆ. ವಿಚಿತ್ರವೆಂದರೆ, ಸಾಕಷ್ಟು ಪ್ರಬುದ್ಧ ಮತ್ತು ಅನುಭವಿ ಜನರು ಕೆಲವೊಮ್ಮೆ ಈ ರೀತಿ ವರ್ತಿಸುತ್ತಾರೆ. ಮಾಪಕದ ಇನ್ನೊಂದು ತುದಿಯೆಂದರೆ, ಒಬ್ಬ ವ್ಯಕ್ತಿಯು ತನ್ನ ಕೋಡ್ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತಿದೆಯೆ ಎಂದು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳಲು ಸ್ವತಃ ಜವಾಬ್ದಾರನಾಗಿರುತ್ತಾನೆ, ಪರೀಕ್ಷೆಗಳಿಂದ ಆವರಿಸಲ್ಪಟ್ಟಿದೆ, ಅವನು ವೈಯಕ್ತಿಕವಾಗಿ ಪರಿಶೀಲಿಸಿದ್ದಾನೆ, ವಿಮರ್ಶೆಯಲ್ಲಿ ಯಶಸ್ವಿಯಾಗಿ ಉತ್ತೀರ್ಣನಾಗಿದ್ದಾನೆ (ಅಗತ್ಯವಿದ್ದರೆ, ವಿಮರ್ಶಕರನ್ನು ಪಿಂಗ್ ಮಾಡಲು, ಸಮಸ್ಯೆಗಳನ್ನು ಚರ್ಚಿಸಲು ಯಾವುದೇ ಸಮಸ್ಯೆ ಇಲ್ಲ. ಧ್ವನಿಯ ಮೂಲಕ, ಇತ್ಯಾದಿ) ಮತ್ತು ನಿಗ್ರಹಿಸಲಾಗಿದೆ , ಅಗತ್ಯವಿದ್ದರೆ QA ಸಹಾಯವನ್ನು ನೀಡುತ್ತದೆ, ಪರೀಕ್ಷಾ ಸನ್ನಿವೇಶಗಳನ್ನು ವಿವರಿಸಲಾಗುತ್ತದೆ, ಇತ್ಯಾದಿ. ಸಾಮಾನ್ಯ ಸಂದರ್ಭಗಳಲ್ಲಿ, ಪ್ರೋಗ್ರಾಮರ್ ಸ್ಕೇಲ್‌ನ ವಯಸ್ಕರ ಅಂತ್ಯಕ್ಕೆ ಹತ್ತಿರವಾಗಿ ಪ್ರಾರಂಭಿಸುತ್ತಾನೆ, ಅಥವಾ ಅವನು ಅನುಭವವನ್ನು ಪಡೆದಂತೆ ಅಲ್ಲಿಗೆ ಚಲಿಸುತ್ತಾನೆ (ತಂಡದಲ್ಲಿ ಸರಿಯಾದ ಸಂಸ್ಕೃತಿಯನ್ನು ಬೆಳೆಸಿದರೆ). ವಿಪರೀತ ಸಂದರ್ಭಗಳಲ್ಲಿ, ಅವರು ಕೆಲಸ ಮಾಡುವುದನ್ನು ಮುಂದುವರೆಸುತ್ತಾರೆ, ಸಾಮಾನ್ಯವಾಗಿ ಬಾಲಿಶ ಸ್ಥಾನವನ್ನು ತೆಗೆದುಕೊಳ್ಳುತ್ತಾರೆ, ನಂತರ ಅವರು ಮತ್ತು ತಂಡವು ನಿಯತಕಾಲಿಕವಾಗಿ ಸಮಸ್ಯೆಗಳು ಮತ್ತು ಘರ್ಷಣೆಗಳನ್ನು ಹೊಂದಿರುತ್ತಾರೆ.
ತಂಡದಲ್ಲಿ ಸರಿಯಾದ, ಪ್ರಬುದ್ಧ ಸಂಸ್ಕೃತಿಯನ್ನು ಬೆಳೆಸುವುದು ಯಾವುದೇ ವ್ಯವಸ್ಥಾಪಕರಿಗೆ ಪ್ರಮುಖ ಕಾರ್ಯವಾಗಿದೆ. ಇದು ದೀರ್ಘ ಸಮಯ ಮತ್ತು ದೈನಂದಿನ ಪ್ರಯತ್ನವನ್ನು ತೆಗೆದುಕೊಳ್ಳುತ್ತದೆ, ಆದರೆ ಫಲಿತಾಂಶವು ಯೋಗ್ಯವಾಗಿರುತ್ತದೆ. ತಂಡದ ಸಂಸ್ಕೃತಿಯ ಮೇಲೆ ಪ್ರಭಾವ ಬೀರಲು ಎರಡು ಮಾರ್ಗಗಳಿವೆ - ಉದಾಹರಣೆಯ ಮೂಲಕ ಮುನ್ನಡೆಸುವುದು (ಖಂಡಿತವಾಗಿಯೂ ಅನುಸರಿಸಲಾಗುವುದು; ತಂಡವು ಯಾವಾಗಲೂ ನಾಯಕನ ಕಡೆಗೆ ನೋಡುತ್ತದೆ) ಮತ್ತು ಸರಿಯಾದ ನಡವಳಿಕೆಯನ್ನು ಚರ್ಚಿಸುವುದು ಮತ್ತು ಪುರಸ್ಕರಿಸುವುದು. ಇಲ್ಲಿ ಅಸಂಬದ್ಧ ಅಥವಾ ಔಪಚಾರಿಕ ಏನೂ ಇಲ್ಲ, ಸಮಸ್ಯೆಗಳನ್ನು ಚರ್ಚಿಸುವಾಗ, ಇಲ್ಲಿ ಏನನ್ನಾದರೂ ಮಾಡಬಹುದೆಂದು ಗಮನಿಸಿ, ಅದನ್ನು ಸರಿಯಾಗಿ ನಿರ್ಧರಿಸಿದಾಗ ನೀವು ಗಮನಿಸಿದ್ದೀರಿ ಎಂದು ಒತ್ತಿಹೇಳಿ, ಹೊಗಳಿಕೆ, ಬಿಡುಗಡೆ ವಿಮರ್ಶೆಯ ಸಮಯದಲ್ಲಿ ಗಮನಿಸಿ ಇತ್ಯಾದಿ.
ಸರಳದಿಂದ ಸಂಕೀರ್ಣಕ್ಕೆ ಹಲವಾರು ವಿಶಿಷ್ಟ ಸಂಘರ್ಷದ ಸಂದರ್ಭಗಳನ್ನು ಪರಿಗಣಿಸೋಣ:
ಘರ್ಷಣೆಗಳು ಕೆಲಸದ ಸಮಸ್ಯೆಗಳಿಗೆ ಸಂಬಂಧಿಸಿಲ್ಲ
ಕೆಲಸದ ಸಮಸ್ಯೆಗಳಿಗೆ ಸಂಬಂಧಿಸದ ಕೆಲಸದಲ್ಲಿ ಆಗಾಗ್ಗೆ ಸಂಘರ್ಷಗಳಿವೆ. ಅವರ ಸಂಭವ ಮತ್ತು ನಿರ್ಣಯದ ಸುಲಭತೆಯು ಸಾಮಾನ್ಯವಾಗಿ ಭಾಗವಹಿಸುವವರ ಭಾವನಾತ್ಮಕ ಬುದ್ಧಿವಂತಿಕೆಯ ಮಟ್ಟ, ಅವರ ಪ್ರಬುದ್ಧತೆಯ ಮಟ್ಟಕ್ಕೆ ನೇರವಾಗಿ ಸಂಬಂಧಿಸಿದೆ ಮತ್ತು ಕೆಲಸದ ಪ್ರಕ್ರಿಯೆಯ ಪರಿಪೂರ್ಣತೆ ಅಥವಾ ಅಪೂರ್ಣತೆಗೆ ಸಂಬಂಧಿಸಿರುವುದಿಲ್ಲ.
ವಿಶಿಷ್ಟ ಉದಾಹರಣೆಗಳು: ಯಾರಾದರೂ ವಾಷಿಂಗ್ ಮೆಷಿನ್ ಅಥವಾ ಶವರ್ ಅನ್ನು ಸಾಕಷ್ಟು ಬಾರಿ ಬಳಸುವುದಿಲ್ಲ, ಅದು ಇತರರು ಇಷ್ಟಪಡುವುದಿಲ್ಲ, ಯಾರಾದರೂ ಉಸಿರುಕಟ್ಟಿಕೊಳ್ಳುತ್ತಾರೆ, ಇತರರು ಕಿಟಕಿಯನ್ನು ತೆರೆದರೆ ಗಾಳಿ ಬೀಸುತ್ತದೆ, ಯಾರಾದರೂ ತುಂಬಾ ಗದ್ದಲ ಮಾಡುತ್ತಾರೆ ಮತ್ತು ಇತರರು ಕೆಲಸ ಮಾಡಲು ಮೌನವಾಗಿರಬೇಕು, ಮತ್ತು ಹೀಗೆ. ಈ ರೀತಿಯ ಘರ್ಷಣೆಗಳ ಪರಿಹಾರವನ್ನು ವಿಳಂಬ ಮಾಡದಿರುವುದು ಮತ್ತು ಅವರ ಹಾದಿಯನ್ನು ತೆಗೆದುಕೊಳ್ಳಲು ಬಿಡದಿರುವುದು ಉತ್ತಮ. ಅವರು ತಾವಾಗಿಯೇ ಪರಿಹರಿಸುವುದಿಲ್ಲ ಮತ್ತು ಪ್ರತಿದಿನ ನಿಮ್ಮನ್ನು ಕೆಲಸದಿಂದ ದೂರವಿಡುತ್ತಾರೆ ಮತ್ತು ತಂಡದಲ್ಲಿನ ವಾತಾವರಣವನ್ನು ವಿಷಪೂರಿತಗೊಳಿಸುತ್ತಾರೆ. ಅದೃಷ್ಟವಶಾತ್, ಅವುಗಳನ್ನು ಪರಿಹರಿಸುವುದು ಸಾಮಾನ್ಯವಾಗಿ ದೊಡ್ಡ ಸಮಸ್ಯೆಯಲ್ಲ - ನೈರ್ಮಲ್ಯವನ್ನು ನಿರ್ಲಕ್ಷಿಸುವ ಸಹೋದ್ಯೋಗಿಯೊಂದಿಗೆ ಶಾಂತವಾಗಿ ಮಾತನಾಡಿ (ಒಂದೊಂದಾಗಿ) , ಇತ್ಯಾದಿ
ನನ್ನ ಕೆಲಸದ ಸಮಯದಲ್ಲಿ ನಾನು ಹಲವಾರು ಬಾರಿ ಎದುರಿಸಿದ ಇನ್ನೊಂದು ಉದಾಹರಣೆಯೆಂದರೆ ತಂಡದ ಸದಸ್ಯರ ಮಾನಸಿಕ ಅಸಾಮರಸ್ಯ. ಕೆಲವು ಕಾರಣಗಳಿಗಾಗಿ, ಜನರು ಸರಳವಾಗಿ ಒಟ್ಟಿಗೆ ಕೆಲಸ ಮಾಡಲು ಸಾಧ್ಯವಿಲ್ಲ; ಪ್ರತಿ ಸಂವಹನವು ಹಗರಣದಲ್ಲಿ ಕೊನೆಗೊಳ್ಳುತ್ತದೆ. ಕೆಲವೊಮ್ಮೆ ಜನರು ಕೆಲವು ಒತ್ತುವ ವಿಷಯದ ಬಗ್ಗೆ (ಸಾಮಾನ್ಯವಾಗಿ ರಾಜಕೀಯ) ಧ್ರುವೀಯ ದೃಷ್ಟಿಕೋನಗಳನ್ನು ಹೊಂದಿದ್ದಾರೆ ಮತ್ತು ಕೆಲಸದಿಂದ ಹೊರಗೆ ಅವರನ್ನು ಹೇಗೆ ಬಿಡಬೇಕು ಎಂದು ತಿಳಿದಿಲ್ಲ ಎಂಬ ಅಂಶದಿಂದಾಗಿ ಇದು ಸಂಭವಿಸುತ್ತದೆ. ಒಬ್ಬರನ್ನೊಬ್ಬರು ಸಹಿಸಿಕೊಳ್ಳಲು ಅಥವಾ ಅವರ ನಡವಳಿಕೆಯನ್ನು ಬದಲಾಯಿಸಲು ಅವರಿಗೆ ಮನವರಿಕೆ ಮಾಡುವುದು ನಿರರ್ಥಕ ಕೆಲಸವಾಗಿದೆ. ನಾನು ಎದುರಿಸಿದ ಏಕೈಕ ಅಪವಾದವೆಂದರೆ ತೆರೆದ ಗ್ರಹಿಕೆಗಳನ್ನು ಹೊಂದಿರುವ ಯುವ ಸಹೋದ್ಯೋಗಿಗಳು; ಆವರ್ತಕ ಸಂಭಾಷಣೆಗಳ ಮೂಲಕ ಅವರ ನಡವಳಿಕೆಯನ್ನು ಇನ್ನೂ ಕ್ರಮೇಣ ಬದಲಾಯಿಸಬಹುದು. ಸಾಮಾನ್ಯವಾಗಿ ಸಮಸ್ಯೆಯನ್ನು ವಿವಿಧ ತಂಡಗಳಾಗಿ ಬೇರ್ಪಡಿಸುವ ಮೂಲಕ ಯಶಸ್ವಿಯಾಗಿ ಪರಿಹರಿಸಲಾಗುತ್ತದೆ, ಅಥವಾ ಕನಿಷ್ಠ ಕೆಲಸದಲ್ಲಿ ಅತಿಕ್ರಮಿಸುವ ಅವಕಾಶವನ್ನು ಬಹಳ ವಿರಳವಾಗಿ ಒದಗಿಸುತ್ತದೆ.
ಮೇಲಿನ ಎಲ್ಲಾ ಸಂದರ್ಭಗಳಲ್ಲಿ, ಎಲ್ಲಾ ಭಾಗವಹಿಸುವವರೊಂದಿಗೆ ವೈಯಕ್ತಿಕವಾಗಿ ಮಾತನಾಡುವುದು, ಪರಿಸ್ಥಿತಿಯನ್ನು ಚರ್ಚಿಸುವುದು, ಈ ಸಂದರ್ಭದಲ್ಲಿ ಅವರು ಸಮಸ್ಯೆಯನ್ನು ನೋಡುತ್ತಾರೆಯೇ ಎಂದು ಕೇಳುವುದು, ಅವರ ಅಭಿಪ್ರಾಯದಲ್ಲಿ, ಪರಿಹಾರಗಳು ಯಾವುವು ಎಂದು ಕೇಳುವುದು ಮತ್ತು ಇದನ್ನು ಮಾಡುವಲ್ಲಿ ಅವರ ಭಾಗವಹಿಸುವಿಕೆಯನ್ನು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳುವುದು ಯೋಗ್ಯವಾಗಿದೆ. ನಿರ್ಧಾರ.
ಕೆಲಸದ ಪ್ರಕ್ರಿಯೆಯನ್ನು ಉತ್ತಮಗೊಳಿಸುವ ದೃಷ್ಟಿಕೋನದಿಂದ (ನಾನು ಪ್ರಸ್ತಾಪಿಸಿದ ಮಧ್ಯಮ-ಅವಧಿಯ ದೃಷ್ಟಿಕೋನ), ಇಲ್ಲಿ ಹೆಚ್ಚಿನದನ್ನು ಮಾಡಲಾಗುವುದಿಲ್ಲ; ತಂಡವನ್ನು ರಚಿಸುವಾಗ ಹೊಂದಾಣಿಕೆಯ ಅಂಶವನ್ನು ಗಣನೆಗೆ ತೆಗೆದುಕೊಳ್ಳುವುದು ಆಪ್ಟಿಮೈಸೇಶನ್‌ನ ಏಕೈಕ ಅಂಶವಾಗಿದೆ ಮತ್ತು ಜನರನ್ನು ಹಾಕಬಾರದು. ಮುಂಚಿತವಾಗಿ ಒಟ್ಟಿಗೆ ಯಾರು ಸಂಘರ್ಷ ಮಾಡುತ್ತಾರೆ.
ತಂಡದ ಸಂಸ್ಕೃತಿಯ ದೃಷ್ಟಿಕೋನದಿಂದ, ಪ್ರಬುದ್ಧ ಸಂಸ್ಕೃತಿಯನ್ನು ಹೊಂದಿರುವ ತಂಡಗಳಲ್ಲಿ ಇಂತಹ ಸಂದರ್ಭಗಳು ಕಡಿಮೆ ಬಾರಿ ಉದ್ಭವಿಸುತ್ತವೆ, ಅಲ್ಲಿ ಜನರು ತಂಡ ಮತ್ತು ಸಹೋದ್ಯೋಗಿಗಳನ್ನು ಗೌರವಿಸುತ್ತಾರೆ ಮತ್ತು ಸಮಸ್ಯೆಗಳನ್ನು ಸ್ವತಂತ್ರವಾಗಿ ಹೇಗೆ ಪರಿಹರಿಸಬೇಕೆಂದು ತಿಳಿದಿರುತ್ತಾರೆ. ಹೆಚ್ಚುವರಿಯಾಗಿ, ಹೆಚ್ಚಿನ ಮಟ್ಟದ ನಂಬಿಕೆ ಇರುವ ತಂಡಗಳಲ್ಲಿ ಇಂತಹ ಸಂಘರ್ಷಗಳನ್ನು ಹೆಚ್ಚು ಸುಲಭವಾಗಿ (ಸಾಮಾನ್ಯವಾಗಿ ಸ್ವಯಂಚಾಲಿತವಾಗಿ) ಪರಿಹರಿಸಲಾಗುತ್ತದೆ, ಜನರು ದೀರ್ಘಕಾಲ ಒಟ್ಟಿಗೆ ಕೆಲಸ ಮಾಡುತ್ತಾರೆ ಮತ್ತು/ಅಥವಾ ಕೆಲಸದ ಹೊರಗೆ ಆಗಾಗ್ಗೆ ಸಂವಹನ ನಡೆಸುತ್ತಾರೆ.
ಕೆಲಸದ ಸಮಸ್ಯೆಗಳಿಗೆ ಸಂಬಂಧಿಸಿದ ಸಂಘರ್ಷಗಳು:
ಅಂತಹ ಘರ್ಷಣೆಗಳು ಸಾಮಾನ್ಯವಾಗಿ ಎರಡೂ ಕಾರಣಗಳಿಂದ ಏಕಕಾಲದಲ್ಲಿ ಉಂಟಾಗುತ್ತವೆ, ಎರಡೂ ಭಾವನಾತ್ಮಕ (ಭಾಗವಹಿಸುವವರಲ್ಲಿ ಒಬ್ಬರು ವಯಸ್ಕರ ಸ್ಥಾನದಲ್ಲಿಲ್ಲ ಎಂಬ ಅಂಶ) ಮತ್ತು ಕೆಲಸದ ಪ್ರಕ್ರಿಯೆಯ ಅಪೂರ್ಣತೆ. ಬಹುಶಃ ನಾನು ಎದುರಿಸಿದ ಸಾಮಾನ್ಯ ರೀತಿಯ ಘರ್ಷಣೆಗಳು ಕೋಡ್ ವಿಮರ್ಶೆಗಳು ಅಥವಾ ಡೆವಲಪರ್‌ಗಳ ನಡುವಿನ ಆರ್ಕಿಟೆಕ್ಚರ್ ಚರ್ಚೆಗಳ ಸಮಯದಲ್ಲಿ ಸಂಘರ್ಷಗಳಾಗಿವೆ.
ನಾನು ಇಲ್ಲಿ ಎರಡು ವಿಶಿಷ್ಟ ಪ್ರಕರಣಗಳನ್ನು ಹೈಲೈಟ್ ಮಾಡುತ್ತೇನೆ:
1) ಮೊದಲ ಪ್ರಕರಣದಲ್ಲಿ, ಡೆವಲಪರ್ ಸಹೋದ್ಯೋಗಿಯಿಂದ ಕೋಡ್ ವಿಮರ್ಶೆಯನ್ನು ಪಡೆಯಲು ಸಾಧ್ಯವಿಲ್ಲ. ಪ್ಯಾಚ್ ಅನ್ನು ಪರಿಶೀಲನೆಗೆ ಕಳುಹಿಸಲಾಗಿದೆ ಮತ್ತು ಏನೂ ಆಗುವುದಿಲ್ಲ. ಮೊದಲ ನೋಟದಲ್ಲಿ, ಎರಡು ಬದಿಗಳ ನಡುವೆ ಯಾವುದೇ ಸ್ಪಷ್ಟವಾದ ಸಂಘರ್ಷವಿಲ್ಲ, ಆದರೆ ನೀವು ಅದರ ಬಗ್ಗೆ ಯೋಚಿಸಿದರೆ, ಇದು ಸಾಕಷ್ಟು ಸಂಘರ್ಷವಾಗಿದೆ. ಕೆಲಸದ ಸಮಸ್ಯೆಯನ್ನು ಪರಿಹರಿಸಲಾಗಿಲ್ಲ, ಪಕ್ಷಗಳಲ್ಲಿ ಒಬ್ಬರು (ವಿಮರ್ಶೆಗಾಗಿ ಕಾಯುತ್ತಿದ್ದಾರೆ) ಸ್ಪಷ್ಟ ಅಸ್ವಸ್ಥತೆಯನ್ನು ಅನುಭವಿಸುತ್ತಾರೆ. ಈ ಪ್ರಕರಣದ ತೀವ್ರ ಉಪವಿಭಾಗವು ಸಮುದಾಯದಲ್ಲಿ ಅಥವಾ ವಿವಿಧ ತಂಡಗಳಲ್ಲಿನ ಅಭಿವೃದ್ಧಿಯಾಗಿದೆ, ಆದರೆ ವಿಮರ್ಶಕರು ಈ ನಿರ್ದಿಷ್ಟ ಕೋಡ್‌ನಲ್ಲಿ ಆಸಕ್ತಿ ಹೊಂದಿರದಿರಬಹುದು, ಲೋಡ್ ಆಗುವ ಅಥವಾ ಇತರ ಸಂದರ್ಭಗಳ ಕಾರಣ, ವಿಮರ್ಶೆ ವಿನಂತಿಯ ಬಗ್ಗೆ ಗಮನ ಹರಿಸದಿರಬಹುದು ಮತ್ತು ಬಾಹ್ಯ ಮಧ್ಯಸ್ಥಗಾರ (ಎರಡೂ ಕಡೆ ಸಾಮಾನ್ಯ ಮ್ಯಾನೇಜರ್) ) ಅಸ್ತಿತ್ವದಲ್ಲಿಲ್ಲದಿರಬಹುದು.
ಅಂತಹ ಪರಿಸ್ಥಿತಿಯಲ್ಲಿ ಸಹಾಯ ಮಾಡುವ ಪರಿಹಾರ ವಿಧಾನವು ದೀರ್ಘಾವಧಿಯ ದೃಷ್ಟಿಕೋನಕ್ಕೆ, ವಯಸ್ಕರ ಸಂಸ್ಕೃತಿಗೆ ನಿಖರವಾಗಿ ಸಂಬಂಧಿಸಿದೆ. ಮೊದಲನೆಯದಾಗಿ, ಸ್ಮಾರ್ಟ್ ಚಟುವಟಿಕೆಯು ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ. ವಿಮರ್ಶೆಯಲ್ಲಿ ನೇತಾಡುವ ಕೋಡ್ ವಿಮರ್ಶಕರ ಗಮನವನ್ನು ಸೆಳೆಯುತ್ತದೆ ಎಂದು ನೀವು ನಿರೀಕ್ಷಿಸಬಾರದು. ವಿಮರ್ಶಕರು ಅವನನ್ನು ಗಮನಿಸಲು ನಾವು ಸಹಾಯ ಮಾಡಬೇಕಾಗಿದೆ. ಪಿಂಗಾಣಿ ಒಂದೆರಡು ಜನರು, ಸಿಂಕೇಪ್ ಬಗ್ಗೆ ಪ್ರಶ್ನೆ ಕೇಳಿ, ಚರ್ಚೆಗಳಲ್ಲಿ ಭಾಗವಹಿಸಿ. ನಿಸ್ಸಂಶಯವಾಗಿ, ಆಮದು ಸಹಾಯಕ್ಕಿಂತ ಹಾನಿ ಮಾಡುವ ಸಾಧ್ಯತೆಯಿದೆ, ನೀವು ಸಾಮಾನ್ಯ ಜ್ಞಾನವನ್ನು ಬಳಸಬೇಕಾಗುತ್ತದೆ. ಎರಡನೆಯದಾಗಿ, ಪೂರ್ವ ತಯಾರಿ ಚೆನ್ನಾಗಿ ಕೆಲಸ ಮಾಡುತ್ತದೆ. ಏನಾಗುತ್ತಿದೆ ಮತ್ತು ಏಕೆ, ಈ ಕೋಡ್ ಏಕೆ ಬೇಕು ಎಂದು ತಂಡವು ಅರ್ಥಮಾಡಿಕೊಂಡರೆ, ವಿನ್ಯಾಸವನ್ನು ಚರ್ಚಿಸಲಾಗಿದೆ ಮತ್ತು ಎಲ್ಲರೊಂದಿಗೆ ಮುಂಚಿತವಾಗಿ ಒಪ್ಪಿಕೊಳ್ಳಲಾಗಿದೆ, ಜನರು ಅಂತಹ ಕೋಡ್ಗೆ ಗಮನ ಕೊಡುತ್ತಾರೆ ಮತ್ತು ಅದನ್ನು ಕೆಲಸಕ್ಕಾಗಿ ಸ್ವೀಕರಿಸುತ್ತಾರೆ. ಮೂರನೆಯದಾಗಿ, ಅಧಿಕಾರವು ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ. ನೀವು ಪರಿಶೀಲಿಸಲು ಬಯಸಿದರೆ, ಬಹಳಷ್ಟು ವಿಮರ್ಶೆಗಳನ್ನು ನೀವೇ ಮಾಡಿ. ನೈಜ ಪರಿಶೀಲನೆಗಳು, ನೈಜ ಪರೀಕ್ಷೆಗಳು ಮತ್ತು ಉಪಯುಕ್ತ ಕಾಮೆಂಟ್‌ಗಳೊಂದಿಗೆ ಉತ್ತಮ ಗುಣಮಟ್ಟದ ವಿಮರ್ಶೆಗಳನ್ನು ಮಾಡಿ. ತಂಡದಲ್ಲಿ ನಿಮ್ಮ ಅಡ್ಡಹೆಸರು ಚೆನ್ನಾಗಿ ತಿಳಿದಿದ್ದರೆ, ನಿಮ್ಮ ಕೋಡ್ ಅನ್ನು ಗಮನಿಸುವ ಹೆಚ್ಚಿನ ಅವಕಾಶವಿದೆ.
ವರ್ಕ್‌ಫ್ಲೋ ದೃಷ್ಟಿಕೋನದಿಂದ, ಇಲ್ಲಿ ಸಂಭವನೀಯ ಸುಧಾರಣೆಗಳು ಡೆವಲಪರ್‌ಗೆ ಅವನ ಮತ್ತು ತಂಡದ ಗುರಿಗಳನ್ನು ಸಾಧಿಸಲು ಸಹಾಯ ಮಾಡುವ ಸರಿಯಾದ ಆದ್ಯತೆಯಾಗಿದೆ (ಇತರರನ್ನು ಪರಿಶೀಲಿಸಿ, ಸಮುದಾಯಕ್ಕೆ ಪತ್ರಗಳನ್ನು ಬರೆಯಿರಿ, ವಾಸ್ತುಶಿಲ್ಪದ ವಿವರಣೆ, ದಾಖಲಾತಿ, ಪರೀಕ್ಷೆಗಳೊಂದಿಗೆ ಕೋಡ್‌ನೊಂದಿಗೆ ಚರ್ಚೆಯಲ್ಲಿ ಭಾಗವಹಿಸಿ. ಸಮುದಾಯ, ಇತ್ಯಾದಿ), ಪ್ಯಾಚ್‌ಗಳು ಸರದಿಯಲ್ಲಿ ಹೆಚ್ಚು ಕಾಲ ನೇತಾಡುವುದನ್ನು ತಡೆಯುವುದು, ಇತ್ಯಾದಿ.
2) ಕೋಡ್ ಅಥವಾ ವಿನ್ಯಾಸ ವಿಮರ್ಶೆಗಳ ಸಮಯದಲ್ಲಿ ಸಂಘರ್ಷಗಳ ಎರಡನೇ ಸಾಮಾನ್ಯ ಪ್ರಕರಣವೆಂದರೆ ತಾಂತ್ರಿಕ ಸಮಸ್ಯೆಗಳು, ಕೋಡಿಂಗ್ ಶೈಲಿ ಮತ್ತು ಪರಿಕರಗಳ ಆಯ್ಕೆಯ ಬಗ್ಗೆ ವಿಭಿನ್ನ ದೃಷ್ಟಿಕೋನಗಳು. ಈ ಸಂದರ್ಭದಲ್ಲಿ ಹೆಚ್ಚಿನ ಪ್ರಾಮುಖ್ಯತೆಯು ಭಾಗವಹಿಸುವವರ ನಡುವಿನ ನಂಬಿಕೆಯ ಮಟ್ಟ, ಒಂದೇ ತಂಡಕ್ಕೆ ಸೇರಿದವರು ಮತ್ತು ಒಟ್ಟಿಗೆ ಕೆಲಸ ಮಾಡುವ ಅನುಭವ. ಭಾಗವಹಿಸುವವರಲ್ಲಿ ಒಬ್ಬರು ಬಾಲಿಶ ಸ್ಥಾನವನ್ನು ಪಡೆದಾಗ ಮತ್ತು ಸಂವಾದಕನು ಅವನಿಗೆ ತಿಳಿಸಲು ಬಯಸುತ್ತಿರುವುದನ್ನು ಕೇಳಲು ಪ್ರಯತ್ನಿಸದಿದ್ದಾಗ ಡೆಡ್ ಎಂಡ್ ಸಂಭವಿಸುತ್ತದೆ. ಸಾಮಾನ್ಯವಾಗಿ, ಇತರ ಪಕ್ಷವು ಪ್ರಸ್ತಾಪಿಸಿದ ವಿಧಾನ ಮತ್ತು ಆರಂಭದಲ್ಲಿ ಪ್ರಸ್ತಾಪಿಸಿದ ವಿಧಾನ ಎರಡೂ ಯಶಸ್ವಿಯಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸಬಹುದು ಮತ್ತು ಯಾವುದನ್ನು ಆಯ್ಕೆ ಮಾಡುವುದು ತಾತ್ವಿಕವಾಗಿ ಅಪ್ರಸ್ತುತವಾಗುತ್ತದೆ.
ಒಂದು ದಿನ, ನನ್ನ ತಂಡದ ಪ್ರೋಗ್ರಾಮರ್ (ನಾವು ಅವನನ್ನು ಪಾಶಾ ಎಂದು ಕರೆಯೋಣ) ಪ್ಯಾಕೇಜ್ ನಿಯೋಜನೆ ವ್ಯವಸ್ಥೆಯಲ್ಲಿ ಬದಲಾವಣೆಗಳೊಂದಿಗೆ ಪ್ಯಾಚ್ ಅನ್ನು ಸಿದ್ಧಪಡಿಸಿದರು, ಇದನ್ನು ನೆರೆಯ ಇಲಾಖೆಯ ಸಹೋದ್ಯೋಗಿಗಳು ಅಭಿವೃದ್ಧಿಪಡಿಸಿದರು ಮತ್ತು ಬೆಂಬಲಿಸಿದರು. ಪ್ಯಾಕೇಜ್‌ಗಳನ್ನು ನಿಯೋಜಿಸುವಾಗ ಲಿನಕ್ಸ್ ಸೇವೆಗಳನ್ನು ಹೇಗೆ ಕಾನ್ಫಿಗರ್ ಮಾಡಬೇಕು ಎಂಬುದರ ಕುರಿತು ಅವರಲ್ಲಿ ಒಬ್ಬರು (ಇಗೊರ್) ತಮ್ಮದೇ ಆದ ಬಲವಾದ ಅಭಿಪ್ರಾಯವನ್ನು ಹೊಂದಿದ್ದರು. ಈ ಅಭಿಪ್ರಾಯವು ಪ್ಯಾಚ್ನಲ್ಲಿ ಪ್ರಸ್ತಾಪಿಸಲಾದ ವಿಧಾನದಿಂದ ಭಿನ್ನವಾಗಿದೆ ಮತ್ತು ಅವರು ಒಪ್ಪಿಕೊಳ್ಳಲು ಸಾಧ್ಯವಾಗಲಿಲ್ಲ. ಎಂದಿನಂತೆ, ಗಡುವು ಮುಗಿದಿದೆ, ಮತ್ತು ಕೆಲವು ರೀತಿಯ ನಿರ್ಧಾರಕ್ಕೆ ಬರುವುದು ಅಗತ್ಯವಾಗಿತ್ತು; ಅವರಲ್ಲಿ ಒಬ್ಬರು ವಯಸ್ಕ ಸ್ಥಾನವನ್ನು ತೆಗೆದುಕೊಳ್ಳುವುದು ಅಗತ್ಯವಾಗಿತ್ತು. ಎರಡೂ ವಿಧಾನಗಳು ಬದುಕುವ ಹಕ್ಕನ್ನು ಹೊಂದಿವೆ ಎಂದು ಪಾಷಾ ಗುರುತಿಸಿದರು, ಆದರೆ ಅವರು ತಮ್ಮ ಆಯ್ಕೆಯನ್ನು ರವಾನಿಸಲು ಬಯಸಿದ್ದರು, ಏಕೆಂದರೆ ಒಂದು ಅಥವಾ ಎರಡನೆಯ ಆಯ್ಕೆಯು ಯಾವುದೇ ಸ್ಪಷ್ಟ ತಾಂತ್ರಿಕ ಪ್ರಯೋಜನಗಳನ್ನು ಹೊಂದಿಲ್ಲ.
ನಮ್ಮ ಚರ್ಚೆಯು ಈ ರೀತಿ ಕಾಣುತ್ತದೆ (ಬಹಳ ಕ್ರಮಬದ್ಧವಾಗಿ, ಸಹಜವಾಗಿ, ಸಂಭಾಷಣೆ ಅರ್ಧ ಘಂಟೆಯವರೆಗೆ ನಡೆಯಿತು):
- ಪಾಶಾ, ನಾವು ಕೆಲವು ದಿನಗಳಲ್ಲಿ ವೈಶಿಷ್ಟ್ಯವನ್ನು ಫ್ರೀಜ್ ಮಾಡಿದ್ದೇವೆ. ನಾವು ಎಲ್ಲವನ್ನೂ ಒಟ್ಟುಗೂಡಿಸುವುದು ಮತ್ತು ಸಾಧ್ಯವಾದಷ್ಟು ಬೇಗ ಪರೀಕ್ಷೆಯನ್ನು ಪ್ರಾರಂಭಿಸುವುದು ಮುಖ್ಯವಾಗಿದೆ. ಇಗೊರ್ ಮೂಲಕ ನಾವು ಹೇಗೆ ಹೋಗಬಹುದು?
- ಅವರು ವಿಭಿನ್ನವಾಗಿ ಸೇವೆಗಳನ್ನು ಹೊಂದಿಸಲು ಬಯಸುತ್ತಾರೆ, ಅವರು ನನಗೆ ಅಲ್ಲಿ ಕಾಮೆಂಟ್ಗಳನ್ನು ಅಂಟಿಸಿದ್ದಾರೆ ...
- ಮತ್ತು ಅಲ್ಲಿ ಏನಿದೆ, ದೊಡ್ಡ ಬದಲಾವಣೆಗಳು, ಬಹಳಷ್ಟು ಗಡಿಬಿಡಿ?
- ಇಲ್ಲ, ಒಂದೆರಡು ಗಂಟೆಗಳ ಕಾಲ ಕೆಲಸವಿದೆ, ಆದರೆ ಕೊನೆಯಲ್ಲಿ ಯಾವುದೇ ವ್ಯತ್ಯಾಸವಿಲ್ಲ, ಅದು ಎರಡೂ ರೀತಿಯಲ್ಲಿ ಕೆಲಸ ಮಾಡುತ್ತದೆ, ಇದು ಏಕೆ ಅಗತ್ಯ? ನಾನು ಏನಾದರೂ ಕೆಲಸ ಮಾಡಿದ್ದೇನೆ, ಅದನ್ನು ಒಪ್ಪಿಕೊಳ್ಳೋಣ.
- ಆಲಿಸಿ, ನೀವು ಎಷ್ಟು ಸಮಯದವರೆಗೆ ಇದೆಲ್ಲವನ್ನೂ ಚರ್ಚಿಸುತ್ತಿದ್ದೀರಿ?
- ಹೌದು, ನಾವು ಈಗ ಒಂದೂವರೆ ವಾರದಿಂದ ಸಮಯವನ್ನು ಗುರುತಿಸುತ್ತಿದ್ದೇವೆ.
- ಉಮ್... ಈಗಾಗಲೇ ಒಂದೂವರೆ ವಾರ ತೆಗೆದುಕೊಂಡಿರುವ ಸಮಸ್ಯೆಯನ್ನು ನಾವು ಒಂದೆರಡು ಗಂಟೆಗಳಲ್ಲಿ ಪರಿಹರಿಸಬಹುದೇ ಮತ್ತು ಅದನ್ನು ಮಾಡದೆಯೇ?
- ಸರಿ, ಹೌದು, ಆದರೆ ಇಗೊರ್ ನಾನು ಒಳಗಾಯಿತು ಎಂದು ಯೋಚಿಸಲು ನಾನು ಬಯಸುವುದಿಲ್ಲ ...
- ಆಲಿಸಿ, ನಿಮಗೆ ಹೆಚ್ಚು ಮುಖ್ಯವಾದುದು, ಬಿಡುಗಡೆಯನ್ನು ನೀಡಲು, ನಿಮ್ಮ ನಿರ್ಧಾರದೊಂದಿಗೆ ಒಳಗೆ, ಅಥವಾ ಇಗೊರ್ ಅನ್ನು ಕೊಲ್ಲಲು? ನಾವು ಅದನ್ನು ನಿರ್ಬಂಧಿಸಬಹುದು, ಆದರೆ, ಬಿಡುಗಡೆಯೊಂದಿಗೆ ಹಾರಲು ಉತ್ತಮ ಅವಕಾಶವಿದೆ.
- ಸರಿ ... ಇದು ತಂಪಾಗಿರುತ್ತದೆ, ಸಹಜವಾಗಿ, ಇಗೊರ್ನ ಮೂಗು ಒರೆಸುವುದು, ಆದರೆ ಸರಿ, ಬಿಡುಗಡೆಯು ಹೆಚ್ಚು ಮುಖ್ಯವಾಗಿದೆ, ನಾನು ಒಪ್ಪುತ್ತೇನೆ.
- ಇಗೊರ್ ಏನು ಯೋಚಿಸುತ್ತಾನೆ ಎಂಬುದು ನಿಮಗೆ ನಿಜವಾಗಿಯೂ ಮುಖ್ಯವೇ? ಪ್ರಾಮಾಣಿಕವಾಗಿ ಹೇಳಬೇಕೆಂದರೆ, ಅವನು ಯಾವುದೇ ಹಾನಿಯನ್ನುಂಟುಮಾಡುವುದಿಲ್ಲ, ಅವನು ಜವಾಬ್ದಾರನಾಗಿರುವ ವಿಷಯದ ವಿವಿಧ ಸ್ಥಳಗಳಲ್ಲಿ ಏಕೀಕೃತ ವಿಧಾನವನ್ನು ಬಯಸುತ್ತಾನೆ.
- ಸರಿ, ಸರಿ, ಅವರು ಕಾಮೆಂಟ್‌ಗಳಲ್ಲಿ ಕೇಳುವಂತೆ ಮಾಡೋಣ ಮತ್ತು ಪರೀಕ್ಷೆಯನ್ನು ಪ್ರಾರಂಭಿಸೋಣ.
- ಧನ್ಯವಾದಗಳು, ಪಾಶಾ! ಇಗೊರೆಕ್ ನಿಮಗಿಂತ ದೊಡ್ಡವರಾಗಿದ್ದರೂ ನಿಮ್ಮಿಬ್ಬರಲ್ಲಿ ನೀವು ಹೆಚ್ಚು ಪ್ರಬುದ್ಧರಾಗಿರುತ್ತೀರಿ ಎಂದು ನನಗೆ ಖಾತ್ರಿಯಿದೆ :)
ಸಮಸ್ಯೆಯನ್ನು ಪರಿಹರಿಸಲಾಗಿದೆ, ಬಿಡುಗಡೆಯು ಸಮಯಕ್ಕೆ ಬಿಡುಗಡೆಯಾಯಿತು, ಪಾಷಾ ಹೆಚ್ಚು ಅಸಮಾಧಾನವನ್ನು ಅನುಭವಿಸಲಿಲ್ಲ, ಏಕೆಂದರೆ ಅವರೇ ಪರಿಹಾರವನ್ನು ಪ್ರಸ್ತಾಪಿಸಿದರು ಮತ್ತು ಅದನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸಿದರು. ಇಗೊರ್ ಸಾಮಾನ್ಯವಾಗಿ ಸಂತೋಷಪಟ್ಟರು, ಏಕೆಂದರೆ ... ಅವರ ಅಭಿಪ್ರಾಯವನ್ನು ಗಣನೆಗೆ ತೆಗೆದುಕೊಂಡು ಅವರು ಸೂಚಿಸಿದಂತೆಯೇ ಮಾಡಿದರು.
ಮೂಲಭೂತವಾಗಿ ಒಂದೇ ರೀತಿಯ ಸಂಘರ್ಷದ ಮತ್ತೊಂದು ಪ್ರಕಾರವೆಂದರೆ ಯೋಜನೆಯಲ್ಲಿನ ತಾಂತ್ರಿಕ ಪರಿಹಾರಗಳು/ಗ್ರಂಥಾಲಯಗಳು/ವಿಧಾನಗಳ ನಡುವಿನ ಆಯ್ಕೆಯಾಗಿದೆ, ವಿಶೇಷವಾಗಿ ವಿತರಿಸಿದ ತಂಡದಲ್ಲಿ. C/C++ ಅನ್ನು ಬಳಸುವಂತೆ ಇರಿಸಲಾದ ಪ್ರಾಜೆಕ್ಟ್‌ಗಳಲ್ಲಿ ಒಂದರಲ್ಲಿ, ಯೋಜನೆಯ ತಾಂತ್ರಿಕ ನಿರ್ವಹಣೆಯು STL (ಸ್ಟ್ಯಾಂಡರ್ಡ್ ಟೆಂಪ್ಲೇಟ್ ಲೈಬ್ರರಿ) ಅನ್ನು ಬಳಸುವುದಕ್ಕೆ ವಿರುದ್ಧವಾಗಿದೆ ಎಂದು ತಿಳಿದುಬಂದಿದೆ. ಇದು ಪ್ರಮಾಣಿತ ಭಾಷಾ ಗ್ರಂಥಾಲಯವಾಗಿದ್ದು ಅದು ಅಭಿವೃದ್ಧಿಯನ್ನು ಸರಳಗೊಳಿಸುತ್ತದೆ ಮತ್ತು ನಮ್ಮ ತಂಡವು ಅದನ್ನು ತುಂಬಾ ಬಳಸಿಕೊಳ್ಳುತ್ತದೆ. ಯೋಜನೆಯು C ++ ಗಿಂತ C ಗೆ ಹೆಚ್ಚು ಹತ್ತಿರದಲ್ಲಿದೆ ಎಂದು ಅದು ಬದಲಾಯಿತು, ಇದು ತಂಡಕ್ಕೆ ಹೆಚ್ಚು ಸ್ಫೂರ್ತಿ ನೀಡಲಿಲ್ಲ, ಏಕೆಂದರೆ ನಿರ್ವಹಣೆಯು ತಮ್ಮ ಅತ್ಯುತ್ತಮ ಪ್ರಯತ್ನವನ್ನು ಮಾಡಿದೆ ಮತ್ತು ನಿಜವಾಗಿಯೂ ಕೂಲ್ ಪ್ಲಸ್ ಆಟಗಾರರನ್ನು ನೇಮಿಸಿಕೊಂಡಿದೆ. ಅದೇ ಸಮಯದಲ್ಲಿ, ತಂಡದ ಅಮೇರಿಕನ್ ಭಾಗವು, ಎಂಜಿನಿಯರ್‌ಗಳು ಮತ್ತು ವ್ಯವಸ್ಥಾಪಕರು, ಕಂಪನಿಯಲ್ಲಿ ದೀರ್ಘಕಾಲ ಕೆಲಸ ಮಾಡುತ್ತಿದ್ದರು, ಅಸ್ತಿತ್ವದಲ್ಲಿರುವ ವ್ಯವಹಾರಗಳಿಗೆ ಒಗ್ಗಿಕೊಂಡಿದ್ದರು ಮತ್ತು ಎಲ್ಲದರಲ್ಲೂ ಸಂತೋಷವಾಗಿದ್ದರು. ತಂಡದ ರಷ್ಯಾದ ಭಾಗವನ್ನು ಇತ್ತೀಚೆಗೆ, ಕೆಲವು ವಾರಗಳಲ್ಲಿ (ನನ್ನನ್ನೂ ಒಳಗೊಂಡಂತೆ) ಒಟ್ಟಿಗೆ ತರಲಾಯಿತು. ತಂಡದ ರಷ್ಯಾದ ಭಾಗವು ಅಭಿವೃದ್ಧಿಯ ಸಾಮಾನ್ಯ ವಿಧಾನವನ್ನು ತ್ಯಜಿಸಲು ನಿರ್ದಿಷ್ಟವಾಗಿ ಇಷ್ಟವಿರಲಿಲ್ಲ.
ಎರಡು ಖಂಡಗಳ ನಡುವೆ ಅಂತ್ಯವಿಲ್ಲದ ಲಿಖಿತ ಚರ್ಚೆಗಳು ಪ್ರಾರಂಭವಾದವು, ಮೂರು ಅಥವಾ ನಾಲ್ಕು ಪರದೆಯ ಮೇಲಿನ ಪತ್ರಗಳು ಹಿಂದಕ್ಕೆ ಮತ್ತು ಮುಂದಕ್ಕೆ ಹಾರಿಹೋಯಿತು, ಗುಂಪು ಮೇಲಿಂಗ್‌ಗಳು ಮತ್ತು ವೈಯಕ್ತಿಕ ವಿಷಯಗಳಲ್ಲಿ, ಪ್ರೋಗ್ರಾಮರ್‌ಗಳಿಂದ ಪ್ರೋಗ್ರಾಮರ್‌ಗಳು ಮತ್ತು ಮ್ಯಾನೇಜರ್‌ಗಳವರೆಗೆ. ಸಾಮಾನ್ಯವಾಗಿ ಕಂಡುಬರುವಂತೆ, ಈ ಉದ್ದದ ಪತ್ರಗಳನ್ನು ಲೇಖಕರು ಮತ್ತು ಅವರ ಕಟ್ಟಾ ಬೆಂಬಲಿಗರನ್ನು ಹೊರತುಪಡಿಸಿ ಯಾರೂ ಓದಲಿಲ್ಲ. STL ನ ತಾಂತ್ರಿಕ ಅನುಕೂಲಗಳು, ಅದನ್ನು ಎಷ್ಟು ಚೆನ್ನಾಗಿ ಪರೀಕ್ಷಿಸಲಾಗಿದೆ, ಅದು ಎಷ್ಟು ಸುರಕ್ಷಿತವಾಗಿದೆ ಮತ್ತು ಸಾಮಾನ್ಯವಾಗಿ, ಅದರೊಂದಿಗೆ ಜೀವನವು ಎಷ್ಟು ಅದ್ಭುತವಾಗಿದೆ ಮತ್ತು ಅದು ಇಲ್ಲದೆ ಎಷ್ಟು ಭಯಾನಕವಾಗಿದೆ ಎಂಬುದರ ಕುರಿತು ವಿವಿಧ ದಿಕ್ಕುಗಳಲ್ಲಿ ಬಹು-ಪರದೆಯ ಆಲೋಚನೆಗಳನ್ನು ರವಾನಿಸುವ ಉದ್ವೇಗದಿಂದ ಚಾಟ್‌ಗಳು ಹುಟ್ಟಿಕೊಂಡಿವೆ. .
ನಾವು ಸಮಸ್ಯೆಯ ತಾಂತ್ರಿಕ ಅಂಶಗಳನ್ನು ಚರ್ಚಿಸುತ್ತಿದ್ದೇವೆ ಎಂದು ನಾನು ಅಂತಿಮವಾಗಿ ಅರಿತುಕೊಳ್ಳುವವರೆಗೂ ಇದೆಲ್ಲವೂ ಬಹಳ ಕಾಲ ಉಳಿಯಿತು, ಆದರೆ ಸಮಸ್ಯೆಯು ವಾಸ್ತವದಲ್ಲಿ ತಾಂತ್ರಿಕವಾಗಿಲ್ಲ. ಸಮಸ್ಯೆಯು STL ನ ಅನುಕೂಲಗಳು ಅಥವಾ ಅನಾನುಕೂಲಗಳು ಅಥವಾ ಅದು ಇಲ್ಲದೆ ಕೆಲಸ ಮಾಡುವ ತೊಂದರೆ ಅಲ್ಲ. ಸಮಸ್ಯೆ ಸಾಂಸ್ಥಿಕವಾಗಿದೆ. ನಾವು ಕೆಲಸ ಮಾಡಿದ ಕಂಪನಿಯು ಹೇಗೆ ಕೆಲಸ ಮಾಡಿದೆ ಎಂಬುದನ್ನು ನಾವು ಅರ್ಥಮಾಡಿಕೊಳ್ಳಬೇಕಾಗಿದೆ. ಅಂತಹ ಕಂಪನಿಯಲ್ಲಿ ಕೆಲಸ ಮಾಡಿದ ಅನುಭವ ನಮ್ಮಲ್ಲಿ ಯಾರಿಗೂ ಇರಲಿಲ್ಲ. ವಿಷಯವೆಂದರೆ ಕೋಡ್ ಅನ್ನು ಅಭಿವೃದ್ಧಿಪಡಿಸಿದ ಮತ್ತು ಉತ್ಪಾದನೆಗೆ ಬಿಡುಗಡೆ ಮಾಡಿದ ನಂತರ, ಬೆಂಬಲವನ್ನು ಇತರ ತಂಡಗಳಿಂದ, ಇತರ ದೇಶಗಳಿಂದ ಸಂಪೂರ್ಣವಾಗಿ ವಿಭಿನ್ನ ಜನರು ನಿರ್ವಹಿಸಿದ್ದಾರೆ. ಹಲವಾರು ಹತ್ತಾರು ಸಾವಿರ ಇಂಜಿನಿಯರ್‌ಗಳ (ಒಟ್ಟು) ಈ ಬೃಹತ್ ಎಂಜಿನಿಯರಿಂಗ್ ತಂಡವು ಸಂಪೂರ್ಣವಾಗಿ ಮೂಲಭೂತ ಕನಿಷ್ಠ ತಾಂತ್ರಿಕ ವಿಧಾನಗಳನ್ನು ಮಾತ್ರ ನಿಭಾಯಿಸಬಲ್ಲದು, ಆದ್ದರಿಂದ ಮಾತನಾಡಲು, ಕನಿಷ್ಠ ಕನಿಷ್ಠ. ಕಂಪನಿಯಲ್ಲಿ ಭೌತಿಕವಾಗಿ ಸ್ಥಾಪಿಸಲಾದ ಎಂಜಿನಿಯರಿಂಗ್ ಮಾನದಂಡವನ್ನು ಮೀರಿದ ಯಾವುದನ್ನಾದರೂ ಭವಿಷ್ಯದಲ್ಲಿ ಬೆಂಬಲಿಸಲಾಗುವುದಿಲ್ಲ. ತಂಡದ ಮಟ್ಟವನ್ನು ಅದರ ದುರ್ಬಲ ಸದಸ್ಯರ ಮಟ್ಟದಿಂದ ನಿರ್ಧರಿಸಲಾಗುತ್ತದೆ. ನಾವು ಅರ್ಥಮಾಡಿಕೊಂಡ ನಂತರ ನಿಜವಾದ ಪ್ರೇರಣೆ ತಂಡದ ಅಮೇರಿಕನ್ ಭಾಗದ ಕ್ರಮಗಳು, ಈ ಸಮಸ್ಯೆಯನ್ನು ಕಾರ್ಯಸೂಚಿಯಿಂದ ತೆಗೆದುಹಾಕಲಾಗಿದೆ ಮತ್ತು ಒಟ್ಟಾಗಿ ನಾವು ಕಂಪನಿಯು ಅಳವಡಿಸಿಕೊಂಡ ಮಾನದಂಡಗಳನ್ನು ಬಳಸಿಕೊಂಡು ಉತ್ಪನ್ನವನ್ನು ಯಶಸ್ವಿಯಾಗಿ ಅಭಿವೃದ್ಧಿಪಡಿಸಿದ್ದೇವೆ ಮತ್ತು ಬಿಡುಗಡೆ ಮಾಡಿದ್ದೇವೆ. ಈ ಸಂದರ್ಭದಲ್ಲಿ ಪತ್ರಗಳು ಮತ್ತು ಚಾಟ್‌ಗಳು ಸರಿಯಾಗಿ ಕೆಲಸ ಮಾಡಲಿಲ್ಲ; ಇದು ಸಾಮಾನ್ಯ ಛೇದಕ್ಕೆ ಬರಲು ಹಲವಾರು ಪ್ರವಾಸಗಳು ಮತ್ತು ಸಾಕಷ್ಟು ವೈಯಕ್ತಿಕ ಸಂವಹನವನ್ನು ತೆಗೆದುಕೊಂಡಿತು.
ಕೆಲಸದ ಹರಿವಿನ ದೃಷ್ಟಿಕೋನದಿಂದ, ಈ ನಿರ್ದಿಷ್ಟ ಸಂದರ್ಭದಲ್ಲಿ, ಬಳಸಿದ ಸಾಧನಗಳ ವಿವರಣೆ, ಅವುಗಳಿಗೆ ಅವಶ್ಯಕತೆಗಳು, ಹೊಸದನ್ನು ಸೇರಿಸುವ ನಿರ್ಬಂಧಗಳು ಮತ್ತು ಅಂತಹ ನಿರ್ಬಂಧಗಳಿಗೆ ಸಮರ್ಥನೆಯನ್ನು ಹೊಂದಲು ಇದು ಸಹಾಯ ಮಾಡುತ್ತದೆ. ಅಂತಹ ದಾಖಲೆಗಳು ಸ್ಥೂಲವಾಗಿ "ಸಾಫ್ಟ್‌ವೇರ್ ಡೆವಲಪ್‌ಮೆಂಟ್‌ಗಾಗಿ ಮ್ಯಾನೇಜರ್ ಹ್ಯಾಂಡ್‌ಬುಕ್" ನ ಮರುಬಳಕೆಯ ತಂತ್ರ ಮತ್ತು ಅಭಿವೃದ್ಧಿ ಪರಿಸರದ ಪ್ಯಾರಾಗಳಲ್ಲಿ ವಿವರಿಸಿದ ದಾಖಲೆಗಳಿಗೆ ಸಂಬಂಧಿಸಿವೆ. . ಅದರ ವಯಸ್ಸಿನ ಹೊರತಾಗಿಯೂ, ಇದು ಈ ರೀತಿಯ ಸಾಫ್ಟ್‌ವೇರ್ ಅಭಿವೃದ್ಧಿಯ ಎಲ್ಲಾ ಮುಖ್ಯ ಚಟುವಟಿಕೆಗಳು ಮತ್ತು ಯೋಜನಾ ಹಂತಗಳನ್ನು ಸಂಪೂರ್ಣವಾಗಿ ವಿವರಿಸುತ್ತದೆ. ಈ ರೀತಿಯ ದಾಖಲೆಗಳನ್ನು ಹೊಂದಿರುವುದು ಉತ್ಪನ್ನದಲ್ಲಿ ಯಾವ ಘಟಕಗಳು ಮತ್ತು ವಿಧಾನಗಳನ್ನು ಬಳಸಬಹುದು ಮತ್ತು ಏಕೆ ಎಂದು ಚರ್ಚಿಸಲು ತುಂಬಾ ಸುಲಭವಾಗುತ್ತದೆ.
ಸಾಂಸ್ಕೃತಿಕ ದೃಷ್ಟಿಕೋನದಿಂದ, ನಿಸ್ಸಂಶಯವಾಗಿ, ಹೆಚ್ಚು ಪ್ರಬುದ್ಧ ಸ್ಥಾನದೊಂದಿಗೆ, ಇದರಲ್ಲಿ ಪಕ್ಷಗಳು ತಮ್ಮ ಸಹೋದ್ಯೋಗಿಗಳ ಕ್ರಿಯೆಗಳ ನೈಜ ಪ್ರೇರಣೆಯನ್ನು ಕೇಳಲು ಮತ್ತು ಅರ್ಥಮಾಡಿಕೊಳ್ಳಲು ಪ್ರಯತ್ನಿಸುತ್ತವೆ ಮತ್ತು ಯೋಜನೆ ಮತ್ತು ತಂಡದ ಆದ್ಯತೆಗಳ ಆಧಾರದ ಮೇಲೆ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತವೆ, ಆದರೆ ವೈಯಕ್ತಿಕ ಅಹಂಕಾರವಲ್ಲ. , ಸಂಘರ್ಷವನ್ನು ಸುಲಭವಾಗಿ ಮತ್ತು ವೇಗವಾಗಿ ಪರಿಹರಿಸಲಾಗುವುದು.
ತಾಂತ್ರಿಕ ಪರಿಹಾರದ ಆಯ್ಕೆಯ ಮೇಲಿನ ಮತ್ತೊಂದು ಸಂಘರ್ಷದಲ್ಲಿ, ಒಂದು ಪಕ್ಷಗಳ ಪ್ರೇರಣೆಯನ್ನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳಲು ನನಗೆ ಗಮನಾರ್ಹವಾದ ಸಮಯವನ್ನು ತೆಗೆದುಕೊಂಡಿತು (ಇದು ತುಂಬಾ ಅಸಾಮಾನ್ಯ ಪ್ರಕರಣ), ಆದರೆ ಪ್ರೇರಣೆ ಸ್ಪಷ್ಟವಾದ ನಂತರ, ಪರಿಹಾರವು ಸ್ಪಷ್ಟವಾಗಿದೆ.
ಪರಿಸ್ಥಿತಿ ಹೀಗಿದೆ: ಸುಮಾರು 20 ಜನರ ತಂಡದಲ್ಲಿ ಹೊಸ ಡೆವಲಪರ್ ಕಾಣಿಸಿಕೊಳ್ಳುತ್ತಾನೆ, ನಾವು ಅವನನ್ನು ಸ್ಟಾಸ್ ಎಂದು ಕರೆಯೋಣ. ಆ ಸಮಯದಲ್ಲಿ, ತಂಡವಾಗಿ ಸಂವಹನಕ್ಕಾಗಿ ನಮ್ಮ ಪ್ರಮಾಣಿತ ಸಾಧನ ಸ್ಕೈಪ್ ಆಗಿತ್ತು. ಇದು ನಂತರ ಬದಲಾದಂತೆ, ಸ್ಟಾಸ್ ಮುಕ್ತ ಮಾನದಂಡಗಳು ಮತ್ತು ಮುಕ್ತ ಮೂಲ ಸಾಫ್ಟ್‌ವೇರ್‌ನ ದೊಡ್ಡ ಅಭಿಮಾನಿಯಾಗಿದ್ದರು ಮತ್ತು ಸಾರ್ವಜನಿಕವಾಗಿ ಲಭ್ಯವಿರುವ ಮತ್ತು ಸಾರ್ವಜನಿಕವಾಗಿ ವಿವರಿಸಿದ ಪ್ರೋಟೋಕಾಲ್‌ಗಳನ್ನು ಬಳಸುವ ಉಪಕರಣಗಳು ಮತ್ತು ಆಪರೇಟಿಂಗ್ ಸಿಸ್ಟಮ್‌ಗಳನ್ನು ಮಾತ್ರ ಬಳಸುತ್ತಿದ್ದರು. ಸ್ಕೈಪ್ ಈ ಉಪಕರಣಗಳಲ್ಲಿ ಒಂದಲ್ಲ. ಈ ವಿಧಾನದ ಅನುಕೂಲಗಳು ಮತ್ತು ಅನಾನುಕೂಲಗಳನ್ನು ಚರ್ಚಿಸಲು ನಾವು ಸಾಕಷ್ಟು ಸಮಯವನ್ನು ಕಳೆದಿದ್ದೇವೆ, ವಿಭಿನ್ನ ಆಪರೇಟಿಂಗ್ ಸಿಸ್ಟಮ್‌ಗಳಲ್ಲಿ ಸ್ಕೈಪ್‌ನ ಅನಲಾಗ್‌ಗಳನ್ನು ಪ್ರಾರಂಭಿಸುವ ಪ್ರಯತ್ನಗಳು, ಇತರ ಮಾನದಂಡಗಳಿಗೆ ಬದಲಾಯಿಸಲು ತಂಡವನ್ನು ಮನವೊಲಿಸುವ ಸ್ಟಾಸ್ ಅವರ ಪ್ರಯತ್ನಗಳು, ಮೇಲ್ ಮೂಲಕ ಅವರಿಗೆ ವೈಯಕ್ತಿಕವಾಗಿ ಬರೆಯಿರಿ, ವೈಯಕ್ತಿಕವಾಗಿ ಅವರನ್ನು ಕರೆ ಮಾಡಿ ಫೋನ್, ಅವನಿಗೆ ನಿರ್ದಿಷ್ಟವಾಗಿ ಸ್ಕೈಪ್‌ಗಾಗಿ ಎರಡನೇ ಕಂಪ್ಯೂಟರ್ ಖರೀದಿಸಿ, ಇತ್ಯಾದಿ. ಅಂತಿಮವಾಗಿ, ಈ ಸಮಸ್ಯೆಯು ಮೂಲಭೂತವಾಗಿ ತಾಂತ್ರಿಕ ಅಥವಾ ಸಾಂಸ್ಥಿಕವಲ್ಲ ಎಂದು ನಾನು ಅರಿತುಕೊಂಡೆ, ಇದು ಸೈದ್ಧಾಂತಿಕವಾಗಿದೆ, ಒಬ್ಬರು ಹೇಳಬಹುದು, ಧಾರ್ಮಿಕ (ಸ್ಟಾಸ್‌ಗಾಗಿ). ನಾವು ಅಂತಿಮವಾಗಿ ಸ್ಟಾಸ್ ಮತ್ತು ಸ್ಕೈಪ್ ಅನ್ನು ಸಂಪರ್ಕಿಸಿದರೂ (ಇದು ಹಲವಾರು ತಿಂಗಳುಗಳನ್ನು ತೆಗೆದುಕೊಂಡಿತು), ಯಾವುದೇ ನಂತರದ ಸಾಧನದಲ್ಲಿ ಸಮಸ್ಯೆ ಮತ್ತೆ ಉದ್ಭವಿಸುತ್ತದೆ. ಸ್ಟಾಸ್ ಅವರ ವಿಶ್ವ ದೃಷ್ಟಿಕೋನವನ್ನು ಬದಲಾಯಿಸಲು ನನ್ನ ವಿಲೇವಾರಿ ಯಾವುದೇ ನೈಜ ವಿಧಾನಗಳನ್ನು ಹೊಂದಿಲ್ಲ ಮತ್ತು ಈ ಪರಿಸರದಲ್ಲಿ ಸಂಪೂರ್ಣವಾಗಿ ಕೆಲಸ ಮಾಡಿದ ತಂಡದ ವಿಶ್ವ ದೃಷ್ಟಿಕೋನವನ್ನು ಬದಲಾಯಿಸಲು ಯಾವುದೇ ಕಾರಣವಿಲ್ಲ. ವ್ಯಕ್ತಿ ಮತ್ತು ಕಂಪನಿಯು ಅವರ ವಿಶ್ವ ದೃಷ್ಟಿಕೋನದಲ್ಲಿ ಸರಳವಾಗಿ ಆರ್ಥೋಗೋನಲ್ ಆಗಿತ್ತು. ಅಂತಹ ಸಂದರ್ಭಗಳಲ್ಲಿ, ಉತ್ತಮ ಪರಿಹಾರವು ಸಾಂಸ್ಥಿಕವಾಗಿದೆ. ನಾವು ಸ್ಟಾಸ್ ಅನ್ನು ಮತ್ತೊಂದು ತಂಡಕ್ಕೆ ವರ್ಗಾಯಿಸಿದ್ದೇವೆ, ಅಲ್ಲಿ ಅವರು ಹೆಚ್ಚು ಸಾವಯವರಾಗಿದ್ದರು.
ಈ ಸಂಘರ್ಷಕ್ಕೆ ಕಾರಣ, ನನ್ನ ಅಭಿಪ್ರಾಯದಲ್ಲಿ, ನಿರ್ದಿಷ್ಟ ವ್ಯಕ್ತಿಯ ವೈಯಕ್ತಿಕ ಸಂಸ್ಕೃತಿ (ಅವನಿಗೆ ರಾಜಿ ಮಾಡಿಕೊಳ್ಳಲು ಅನುಮತಿಸದ ಬಲವಾದ ಅಭಿಪ್ರಾಯವನ್ನು ಹೊಂದಿರುವ) ಮತ್ತು ಕಂಪನಿಯ ಸಂಸ್ಕೃತಿಯ ನಡುವಿನ ವ್ಯತ್ಯಾಸವಾಗಿದೆ. ಈ ಸಂದರ್ಭದಲ್ಲಿ, ಇದು ಸಹಜವಾಗಿ, ವ್ಯವಸ್ಥಾಪಕರ ತಪ್ಪು. ಈ ರೀತಿಯ ಯೋಜನೆಗೆ ಅವರನ್ನು ಕರೆದೊಯ್ಯುವುದು ಆರಂಭದಲ್ಲಿ ತಪ್ಪಾಗಿತ್ತು. ಸ್ಟಾಸ್ ಅಂತಿಮವಾಗಿ ಓಪನ್ ಸೋರ್ಸ್ ಸಾಫ್ಟ್‌ವೇರ್ ಅಭಿವೃದ್ಧಿ ಯೋಜನೆಗೆ ತೆರಳಿದರು ಮತ್ತು ಅಲ್ಲಿ ಉತ್ತಮ ಸಾಧನೆ ಮಾಡಿದರು.
ಡೆವಲಪರ್‌ನ ಬಾಲಿಶ ವರ್ತನೆ ಮತ್ತು ಕೆಲಸದ ಪ್ರಕ್ರಿಯೆಯ ನ್ಯೂನತೆಗಳಿಂದ ಉಂಟಾದ ಸಂಘರ್ಷದ ಉತ್ತಮ ಉದಾಹರಣೆಯೆಂದರೆ, ಮಾಡಿದ ವ್ಯಾಖ್ಯಾನದ ಅನುಪಸ್ಥಿತಿಯಲ್ಲಿ, ಡೆವಲಪರ್ ಮತ್ತು ಕ್ಯೂಎ ತಂಡವು ಸನ್ನದ್ಧತೆಯ ಬಗ್ಗೆ ವಿಭಿನ್ನ ನಿರೀಕ್ಷೆಗಳನ್ನು ಹೊಂದಿದೆ. ವೈಶಿಷ್ಟ್ಯವನ್ನು QA ಗೆ ವರ್ಗಾಯಿಸಲಾಗಿದೆ. ಕೋಡ್ ಅನ್ನು ಬರೆಯಲು ಮತ್ತು ವೈಶಿಷ್ಟ್ಯವನ್ನು QA ಗೆ ಬೇಲಿಯ ಮೇಲೆ ಎಸೆಯಲು ಸಾಕು ಎಂದು ಡೆವಲಪರ್ ನಂಬಿದ್ದರು - ಅವರು ಅದನ್ನು ಅಲ್ಲಿಯೇ ವಿಂಗಡಿಸುತ್ತಾರೆ. ಸಾಕಷ್ಟು ಪ್ರಬುದ್ಧ ಮತ್ತು ಅನುಭವಿ ಪ್ರೋಗ್ರಾಮರ್, ಮೂಲಕ, ಆದರೆ ಅದು ಗುಣಮಟ್ಟಕ್ಕಾಗಿ ಅವರ ಆಂತರಿಕ ಮಿತಿಯಾಗಿತ್ತು. QA ಇದನ್ನು ಒಪ್ಪಲಿಲ್ಲ ಮತ್ತು ಅವರು ಸ್ವತಃ ಪರಿಶೀಲಿಸಿದ್ದನ್ನು ತೋರಿಸಲು ಮತ್ತು ವಿವರಿಸಲು ಒತ್ತಾಯಿಸಿದರು ಮತ್ತು ಅವರಿಗೆ ಪರೀಕ್ಷಾ ಸ್ಕ್ರಿಪ್ಟ್ ಅನ್ನು ಒತ್ತಾಯಿಸಿದರು. ಅವರು ಈ ಹಿಂದೆ ಈ ಡೆವಲಪರ್‌ನಿಂದ ಕಾರ್ಯನಿರ್ವಹಣೆಯೊಂದಿಗೆ ಸಮಸ್ಯೆಗಳನ್ನು ಹೊಂದಿದ್ದರು ಮತ್ತು ಮತ್ತೆ ತಮ್ಮ ಸಮಯವನ್ನು ವ್ಯರ್ಥ ಮಾಡಲು ಬಯಸಲಿಲ್ಲ. ಅಂದಹಾಗೆ, ಅವರು ಸರಿಯಾಗಿದ್ದರು - ವೈಶಿಷ್ಟ್ಯವು ನಿಜವಾಗಿಯೂ ಕೆಲಸ ಮಾಡಲಿಲ್ಲ, QA ಗೆ ಕಳುಹಿಸುವ ಮೊದಲು ಅವರು ಕೋಡ್ ಅನ್ನು ಪರಿಶೀಲಿಸಲಿಲ್ಲ.
ಪರಿಸ್ಥಿತಿಯನ್ನು ಪರಿಹರಿಸಲು, ಎಲ್ಲವೂ ನಿಜವಾಗಿಯೂ ಕೆಲಸ ಮಾಡಿದೆ ಎಂದು ನನಗೆ ತೋರಿಸಲು ನಾನು ಅವನನ್ನು ಕೇಳಿದೆ (ಅದು ಕೆಲಸ ಮಾಡಲಿಲ್ಲ, ಮತ್ತು ಅವನು ಅದನ್ನು ಸರಿಪಡಿಸಬೇಕಾಗಿತ್ತು), ನಾವು ತಂಡದೊಂದಿಗೆ ಮತ್ತು ಮುಗಿದಿದೆ (ಅವರು ಅದನ್ನು ಮಾಡಲಿಲ್ಲ) ಎಂಬ QA ವ್ಯಾಖ್ಯಾನದೊಂದಿಗೆ ಮಾತನಾಡಿದೆವು ಬರವಣಿಗೆ, ಏಕೆಂದರೆ ನಾವು ಪ್ರಕ್ರಿಯೆಯನ್ನು ಹೆಚ್ಚು ಅಧಿಕಾರಶಾಹಿ ಮಾಡಲು ಬಯಸುವುದಿಲ್ಲ ), ಅಲ್ಲದೆ, ನಾವು ಶೀಘ್ರದಲ್ಲೇ ಈ ತಜ್ಞರೊಂದಿಗೆ (ಸಾಮಾನ್ಯ ಪರಿಹಾರಕ್ಕಾಗಿ) ಬೇರ್ಪಟ್ಟಿದ್ದೇವೆ.
ಕೆಲಸದ ಹರಿವಿನ ದೃಷ್ಟಿಕೋನದಿಂದ, ಈ ಸಂದರ್ಭದಲ್ಲಿ ಸಂಭವನೀಯ ಸುಧಾರಣೆಗಳು ಮಾಡಿದ ವ್ಯಾಖ್ಯಾನದ ಉಪಸ್ಥಿತಿ, ಪ್ರತಿ ಘಟಕದ ವೈಶಿಷ್ಟ್ಯ ಮತ್ತು ಏಕೀಕರಣ ಪರೀಕ್ಷೆಗಳ ಬೆಂಬಲದ ಅವಶ್ಯಕತೆಗಳು ಮತ್ತು ಡೆವಲಪರ್ ನಡೆಸಿದ ಪರೀಕ್ಷೆಯ ವಿವರಣೆ. ಯೋಜನೆಗಳಲ್ಲಿ ಒಂದರಲ್ಲಿ, ನಾವು CI ಸಮಯದಲ್ಲಿ ಪರೀಕ್ಷೆಗಳ ಮೂಲಕ ಕೋಡ್ ವ್ಯಾಪ್ತಿಯ ಮಟ್ಟವನ್ನು ಅಳೆಯುತ್ತೇವೆ ಮತ್ತು ಪ್ಯಾಚ್ ಅನ್ನು ಸೇರಿಸಿದ ನಂತರ ಕವರೇಜ್ ಮಟ್ಟವು ಕುಸಿದರೆ, ಪರೀಕ್ಷೆಗಳನ್ನು ವಿಫಲವಾಗಿದೆ ಎಂದು ಗುರುತಿಸಲಾಗಿದೆ, ಅಂದರೆ. ಯಾವುದೇ ಹೊಸ ಕೋಡ್ಗೆ ಹೊಸ ಪರೀಕ್ಷೆಗಳು ಇದ್ದಲ್ಲಿ ಮಾತ್ರ ಸೇರಿಸಬಹುದು.
ಕೆಲಸದ ಪ್ರಕ್ರಿಯೆಯ ಸಂಘಟನೆಗೆ ನಿಕಟವಾಗಿ ಸಂಬಂಧಿಸಿದ ಸಂಘರ್ಷದ ಮತ್ತೊಂದು ವಿಶಿಷ್ಟ ಉದಾಹರಣೆ. ನಾವು ಉತ್ಪನ್ನ, ಉತ್ಪನ್ನ ಅಭಿವೃದ್ಧಿ ತಂಡ, ಬೆಂಬಲ ತಂಡ ಮತ್ತು ಗ್ರಾಹಕರನ್ನು ಹೊಂದಿದ್ದೇವೆ. ಗ್ರಾಹಕರು ಉತ್ಪನ್ನ ಮತ್ತು ಸಂಪರ್ಕಗಳ ಬೆಂಬಲದೊಂದಿಗೆ ಸಮಸ್ಯೆಗಳನ್ನು ಹೊಂದಿದ್ದಾರೆ. ಬೆಂಬಲವು ಸಮಸ್ಯೆಯನ್ನು ವಿಶ್ಲೇಷಿಸುತ್ತದೆ ಮತ್ತು ಸಮಸ್ಯೆಯು ಉತ್ಪನ್ನದಲ್ಲಿದೆ ಎಂದು ಅರ್ಥಮಾಡಿಕೊಳ್ಳುತ್ತದೆ ಮತ್ತು ಸಮಸ್ಯೆಯನ್ನು ಉತ್ಪನ್ನ ತಂಡಕ್ಕೆ ವರ್ಗಾಯಿಸುತ್ತದೆ. ಉತ್ಪನ್ನ ತಂಡವು ಬಿಡುವಿಲ್ಲದ ಸಮಯದಲ್ಲಿದೆ, ಬಿಡುಗಡೆಯು ಸಮೀಪಿಸುತ್ತಿದೆ, ಆದ್ದರಿಂದ ಗ್ರಾಹಕರಿಂದ ಸಮಸ್ಯೆಯಿರುವ ಟಿಕೆಟ್, ಅದನ್ನು ನಿಯೋಜಿಸಲಾದ ಡೆವಲಪರ್‌ನ ಇತರ ಟಿಕೆಟ್‌ಗಳಲ್ಲಿ ಕಳೆದುಹೋಗಿದೆ, ಗಮನವಿಲ್ಲದೆ ಹಲವಾರು ವಾರಗಳವರೆಗೆ ಸ್ಥಗಿತಗೊಳ್ಳುತ್ತದೆ. ಡೆವಲಪರ್ ಗ್ರಾಹಕರ ಸಮಸ್ಯೆಯ ಮೇಲೆ ಕೆಲಸ ಮಾಡುತ್ತಿದ್ದಾರೆ ಎಂದು ಬೆಂಬಲ ಭಾವಿಸುತ್ತದೆ. ಗ್ರಾಹಕರು ಕಾಯುತ್ತಿದ್ದಾರೆ ಮತ್ತು ಅವರ ಸಮಸ್ಯೆಯು ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತಿದೆ ಎಂದು ಭಾವಿಸುತ್ತಾರೆ. ವಾಸ್ತವದಲ್ಲಿ, ಇನ್ನೂ ಏನೂ ಆಗುತ್ತಿಲ್ಲ. ಕೆಲವು ವಾರಗಳ ನಂತರ, ಗ್ರಾಹಕರು ಅಂತಿಮವಾಗಿ ಪ್ರಗತಿಯಲ್ಲಿ ಆಸಕ್ತಿ ವಹಿಸಲು ನಿರ್ಧರಿಸುತ್ತಾರೆ ಮತ್ತು ವಿಷಯಗಳು ಹೇಗೆ ನಡೆಯುತ್ತಿವೆ ಎಂಬುದನ್ನು ಬೆಂಬಲವನ್ನು ಕೇಳುತ್ತಾರೆ. ಅಭಿವೃದ್ಧಿಗೆ ಬೆಂಬಲ ಕೇಳುತ್ತದೆ. ಡೆವಲಪರ್ ನಡುಗುತ್ತಾನೆ, ಟಿಕೆಟ್‌ಗಳ ಪಟ್ಟಿಯನ್ನು ನೋಡುತ್ತಾನೆ ಮತ್ತು ಅಲ್ಲಿನ ಗ್ರಾಹಕರಿಂದ ಟಿಕೆಟ್ ಅನ್ನು ಕಂಡುಕೊಳ್ಳುತ್ತಾನೆ. ಗ್ರಾಹಕರಿಂದ ಟಿಕೆಟ್ ಓದುವುದು, ಸಮಸ್ಯೆಯನ್ನು ಪರಿಹರಿಸಲು ಸಾಕಷ್ಟು ಮಾಹಿತಿ ಇಲ್ಲ ಎಂದು ಅವರು ಅರ್ಥಮಾಡಿಕೊಳ್ಳುತ್ತಾರೆ ಮತ್ತು ಅವರಿಗೆ ಹೆಚ್ಚಿನ ಲಾಗ್‌ಗಳು ಮತ್ತು ಡಂಪ್‌ಗಳು ಬೇಕಾಗುತ್ತವೆ. ಬೆಂಬಲವು ಗ್ರಾಹಕರಿಂದ ಹೆಚ್ಚುವರಿ ಮಾಹಿತಿಯನ್ನು ವಿನಂತಿಸುತ್ತದೆ. ಮತ್ತು ಈ ಸಮಯದಲ್ಲಿ ಯಾರೂ ತನ್ನ ಸಮಸ್ಯೆಯ ಮೇಲೆ ಕೆಲಸ ಮಾಡಿಲ್ಲ ಎಂದು ಗ್ರಾಹಕರು ಅರಿತುಕೊಳ್ಳುತ್ತಾರೆ. ಮತ್ತು ಗುಡುಗು ಹೊಡೆಯುತ್ತದೆ ...
ಈ ಪರಿಸ್ಥಿತಿಯಲ್ಲಿ, ಸಂಘರ್ಷಕ್ಕೆ ಪರಿಹಾರವು ಸಾಕಷ್ಟು ಸ್ಪಷ್ಟವಾಗಿದೆ ಮತ್ತು ರೇಖಾತ್ಮಕವಾಗಿರುತ್ತದೆ (ಉತ್ಪನ್ನವನ್ನು ಸರಿಪಡಿಸಿ, ದಸ್ತಾವೇಜನ್ನು ಮತ್ತು ಪರೀಕ್ಷೆಗಳನ್ನು ನವೀಕರಿಸಿ, ಗ್ರಾಹಕರನ್ನು ಸಮಾಧಾನಪಡಿಸಿ, ಹಾಟ್ಫಿಕ್ಸ್ ಅನ್ನು ಬಿಡುಗಡೆ ಮಾಡಿ, ಇತ್ಯಾದಿ.). ಕೆಲಸದ ಪ್ರಕ್ರಿಯೆಯನ್ನು ವಿಶ್ಲೇಷಿಸುವುದು ಮತ್ತು ಎರಡು ತಂಡಗಳ ನಡುವಿನ ಪರಸ್ಪರ ಕ್ರಿಯೆಯನ್ನು ಸಂಘಟಿಸಲು ಯಾರು ಜವಾಬ್ದಾರರು ಎಂಬುದನ್ನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳುವುದು ಮುಖ್ಯವಾಗಿದೆ ಮತ್ತು ಈ ಪರಿಸ್ಥಿತಿಯು ಮೊದಲ ಸ್ಥಾನದಲ್ಲಿ ಏಕೆ ಸಾಧ್ಯವಾಯಿತು. ಪ್ರಕ್ರಿಯೆಯಲ್ಲಿ ಏನನ್ನು ಸರಿಪಡಿಸಬೇಕು ಎಂಬುದು ಸ್ಪಷ್ಟವಾಗಿದೆ - ಗ್ರಾಹಕರಿಂದ ಜ್ಞಾಪನೆಗಳಿಲ್ಲದೆ, ಪೂರ್ವಭಾವಿಯಾಗಿ ಯಾರಾದರೂ ಒಟ್ಟಾರೆ ಚಿತ್ರವನ್ನು ಮೇಲ್ವಿಚಾರಣೆ ಮಾಡಬೇಕು. ಡೆವಲಪರ್‌ಗಳ ಇತರ ಟಿಕೆಟ್‌ಗಳ ನಡುವೆ ಗ್ರಾಹಕರ ಟಿಕೆಟ್‌ಗಳು ಎದ್ದು ಕಾಣಬೇಕು. ಅಭಿವೃದ್ಧಿ ತಂಡವು ಪ್ರಸ್ತುತ ತನ್ನ ಟಿಕೆಟ್‌ಗಳಲ್ಲಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತಿದೆಯೇ ಮತ್ತು ಇಲ್ಲದಿದ್ದರೆ, ಅದು ಯಾವಾಗ ಕೆಲಸ ಮಾಡಲು ಪ್ರಾರಂಭಿಸಬಹುದು ಮತ್ತು ಯಾವಾಗ ಫಲಿತಾಂಶಗಳನ್ನು ನಿರೀಕ್ಷಿಸಬಹುದು ಎಂಬುದನ್ನು ಬೆಂಬಲವು ನೋಡಬೇಕು. ಬೆಂಬಲ ಮತ್ತು ಅಭಿವೃದ್ಧಿಯು ನಿಯತಕಾಲಿಕವಾಗಿ ಟಿಕೆಟ್‌ಗಳ ಸ್ಥಿತಿಯನ್ನು ಸಂವಹಿಸಬೇಕು ಮತ್ತು ಚರ್ಚಿಸಬೇಕು, ಡೀಬಗ್ ಮಾಡಲು ಅಗತ್ಯವಾದ ಮಾಹಿತಿಯ ಸಂಗ್ರಹವನ್ನು ಸಾಧ್ಯವಾದಷ್ಟು ಸ್ವಯಂಚಾಲಿತಗೊಳಿಸಬೇಕು, ಇತ್ಯಾದಿ.
ಯುದ್ಧದಲ್ಲಿ ಶತ್ರು ಎರಡು ಘಟಕಗಳ ನಡುವಿನ ಜಂಕ್ಷನ್ ಅನ್ನು ಹೊಡೆಯಲು ಪ್ರಯತ್ನಿಸುವಂತೆಯೇ, ಕೆಲಸದಲ್ಲಿ ಅತ್ಯಂತ ಸೂಕ್ಷ್ಮವಾದ ಮತ್ತು ದುರ್ಬಲವಾದ ಬಿಂದುವು ಸಾಮಾನ್ಯವಾಗಿ ತಂಡಗಳ ನಡುವಿನ ಪರಸ್ಪರ ಕ್ರಿಯೆಯಾಗಿದೆ. ಬೆಂಬಲ ಮತ್ತು ಅಭಿವೃದ್ಧಿ ವ್ಯವಸ್ಥಾಪಕರು ಸಾಕಷ್ಟು ವಯಸ್ಸಾಗಿದ್ದರೆ, ಅವರು ಪ್ರಕ್ರಿಯೆಯನ್ನು ಸ್ವತಃ ಸರಿಪಡಿಸಲು ಸಾಧ್ಯವಾಗುತ್ತದೆ, ಇಲ್ಲದಿದ್ದರೆ, ಪರಿಸ್ಥಿತಿಯನ್ನು ಸರಿಪಡಿಸಲು ಒಬ್ಬ ವ್ಯವಸ್ಥಾಪಕರು ಮಧ್ಯಪ್ರವೇಶಿಸುವವರೆಗೆ ಪ್ರಕ್ರಿಯೆಯು ಘರ್ಷಣೆಗಳು ಮತ್ತು ಸಮಸ್ಯೆಗಳನ್ನು ಉಂಟುಮಾಡುತ್ತದೆ.
ವಿವಿಧ ಕಂಪನಿಗಳಲ್ಲಿ ನಾನು ಪದೇ ಪದೇ ನೋಡಿದ ಮತ್ತೊಂದು ವಿಶಿಷ್ಟ ಉದಾಹರಣೆಯೆಂದರೆ, ಉತ್ಪನ್ನವನ್ನು ಒಂದು ತಂಡದಿಂದ ಬರೆಯುವ ಪರಿಸ್ಥಿತಿ, ಅದಕ್ಕೆ ಸ್ವಯಂಚಾಲಿತ ಏಕೀಕರಣ ಪರೀಕ್ಷೆಗಳನ್ನು ಎರಡನೇ ತಂಡದಿಂದ ಬರೆಯಲಾಗುತ್ತದೆ ಮತ್ತು ಅದು ಕಾರ್ಯನಿರ್ವಹಿಸುವ ಮೂಲಸೌಕರ್ಯವು ಮೂರನೆಯದರೊಂದಿಗೆ ಇರುತ್ತದೆ. ತಂಡ. ಪರೀಕ್ಷೆಗಳನ್ನು ನಡೆಸುವಾಗ ತೊಂದರೆಗಳು ಸಾರ್ವಕಾಲಿಕ ಉದ್ಭವಿಸುತ್ತವೆ, ಮತ್ತು ಅವುಗಳಲ್ಲಿನ ಸಮಸ್ಯೆಗಳಿಗೆ ಕಾರಣ ಉತ್ಪನ್ನ ಮತ್ತು ಪರೀಕ್ಷೆಗಳು ಮತ್ತು ಮೂಲಸೌಕರ್ಯ ಎರಡೂ ಆಗಿರಬಹುದು. ಸಮಸ್ಯೆಗಳು, ಫೈಲ್ ದೋಷಗಳು, ಉತ್ಪನ್ನದ ಪಾರ್ಸ್ ಲಾಗ್‌ಗಳು, ಪರೀಕ್ಷೆಗಳು ಮತ್ತು ಮೂಲಸೌಕರ್ಯ ಇತ್ಯಾದಿಗಳ ಆರಂಭಿಕ ವಿಶ್ಲೇಷಣೆಯನ್ನು ಯಾರು ನಿರ್ವಹಿಸಬೇಕು ಎಂಬುದನ್ನು ಒಪ್ಪಿಕೊಳ್ಳುವುದು ಸಾಮಾನ್ಯವಾಗಿ ಸಮಸ್ಯಾತ್ಮಕವಾಗಿದೆ. ಇಲ್ಲಿ ಘರ್ಷಣೆಗಳು ಬಹಳ ಆಗಾಗ್ಗೆ, ಮತ್ತು, ಅದೇ ಸಮಯದಲ್ಲಿ, ಏಕರೂಪವಾಗಿರುತ್ತವೆ. ಹೆಚ್ಚಿನ ಭಾವನಾತ್ಮಕ ತೀವ್ರತೆಯ ಸಂದರ್ಭದಲ್ಲಿ, ಭಾಗವಹಿಸುವವರು ಸಾಮಾನ್ಯವಾಗಿ ಬಾಲಿಶ ಸ್ಥಾನಕ್ಕೆ ಬರುತ್ತಾರೆ ಮತ್ತು ಸರಣಿಯಲ್ಲಿ ಚರ್ಚೆಗಳು ಪ್ರಾರಂಭವಾಗುತ್ತವೆ: "ನಾನು ಇದನ್ನು ಏಕೆ ಟಿಂಕರ್ ಮಾಡಬೇಕು," "ಅವರು ಹೆಚ್ಚಾಗಿ ಒಡೆಯುತ್ತಾರೆ," ಇತ್ಯಾದಿ.
ವರ್ಕ್‌ಫ್ಲೋ ದೃಷ್ಟಿಕೋನದಿಂದ, ಸಮಸ್ಯೆಯನ್ನು ಪರಿಹರಿಸುವ ನಿರ್ದಿಷ್ಟ ಹಂತಗಳು ತಂಡಗಳ ಸಂಯೋಜನೆ, ಪರೀಕ್ಷೆಗಳ ಪ್ರಕಾರ ಮತ್ತು ಉತ್ಪನ್ನ ಇತ್ಯಾದಿಗಳನ್ನು ಅವಲಂಬಿಸಿರುತ್ತದೆ. ಪ್ರಾಜೆಕ್ಟ್‌ಗಳಲ್ಲಿ ಒಂದರಲ್ಲಿ, ನಾವು ಆವರ್ತಕ ಕರ್ತವ್ಯವನ್ನು ಪರಿಚಯಿಸಿದ್ದೇವೆ, ಇದರಲ್ಲಿ ತಂಡಗಳು ವಾರದಿಂದ ವಾರಕ್ಕೆ ಒಂದೊಂದಾಗಿ ಪರೀಕ್ಷೆಗಳನ್ನು ಮೇಲ್ವಿಚಾರಣೆ ಮಾಡುತ್ತವೆ. ಮತ್ತೊಂದರಲ್ಲಿ, ಆರಂಭಿಕ ವಿಶ್ಲೇಷಣೆಯನ್ನು ಯಾವಾಗಲೂ ಪರೀಕ್ಷಾ ಅಭಿವರ್ಧಕರು ಮಾಡುತ್ತಾರೆ, ಆದರೆ ವಿಶ್ಲೇಷಣೆಯು ತುಂಬಾ ಮೂಲಭೂತವಾಗಿದೆ ಮತ್ತು ಉತ್ಪನ್ನವು ಸಾಕಷ್ಟು ಸ್ಥಿರವಾಗಿತ್ತು, ಆದ್ದರಿಂದ ಇದು ಉತ್ತಮವಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ. ಪ್ರಕ್ರಿಯೆಯು ಪಾರದರ್ಶಕವಾಗಿದೆ ಎಂದು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳುವುದು ಪ್ರಮುಖವಾಗಿದೆ, ಎಲ್ಲಾ ಪಕ್ಷಗಳಿಗೆ ನಿರೀಕ್ಷೆಗಳು ಸ್ಪಷ್ಟವಾಗಿವೆ ಮತ್ತು ಪರಿಸ್ಥಿತಿಯು ಎಲ್ಲರಿಗೂ ನ್ಯಾಯೋಚಿತವಾಗಿದೆ.
ಸಂಸ್ಥೆಯಲ್ಲಿ ಸಂಘರ್ಷವು ಸಮಸ್ಯೆಯೇ? ನಿಮ್ಮ ತಂಡದಲ್ಲಿ ಆಗಾಗ್ಗೆ (ಅಥವಾ ನಿಯತಕಾಲಿಕವಾಗಿ) ಸಂಘರ್ಷಗಳು ಸಂಭವಿಸುವುದು ಕೆಟ್ಟ ಸಂಕೇತವೇ? ಸಾಮಾನ್ಯವಾಗಿ, ಇಲ್ಲ, ಏಕೆಂದರೆ ಬೆಳವಣಿಗೆ, ಅಭಿವೃದ್ಧಿ ಇದ್ದರೆ, ಕೆಲವು ರೀತಿಯ ಡೈನಾಮಿಕ್ಸ್ ಇದೆ, ನಂತರ ಹಿಂದೆಂದೂ ಪರಿಹರಿಸದ ಸಮಸ್ಯೆಗಳು ಉದ್ಭವಿಸುತ್ತವೆ ಮತ್ತು ಅವುಗಳನ್ನು ಪರಿಹರಿಸುವಾಗ ಘರ್ಷಣೆಗಳು ಉಂಟಾಗಬಹುದು. ಇದು ಕೆಲವು ಪ್ರದೇಶಗಳಿಗೆ ಗಮನ ಕೊಡಬೇಕಾದ ಸೂಚಕವಾಗಿದೆ, ಸುಧಾರಣೆಗೆ ಕ್ಷೇತ್ರಗಳಿವೆ. ಘರ್ಷಣೆಗಳು ಆಗಾಗ್ಗೆ ಉದ್ಭವಿಸಿದರೆ ಅದು ಕೆಟ್ಟದಾಗಿದೆ, ಪರಿಹರಿಸಲು ಕಷ್ಟವಾಗುತ್ತದೆ ಅಥವಾ ದೀರ್ಘಕಾಲ ತೆಗೆದುಕೊಳ್ಳುತ್ತದೆ. ಇದು ಹೆಚ್ಚಾಗಿ ಸಾಕಷ್ಟು ಸುವ್ಯವಸ್ಥಿತ ಕೆಲಸದ ಪ್ರಕ್ರಿಯೆಗಳು ಮತ್ತು ತಂಡದ ಸಾಕಷ್ಟು ಪ್ರಬುದ್ಧತೆಯ ಸಂಕೇತವಾಗಿದೆ.
ಮೂಲ: www.habr.com