ಅಭಿವೃದ್ಧಿ ತಂಡದಲ್ಲಿ "ಯೂನಿವರ್ಸಲ್": ಪ್ರಯೋಜನ ಅಥವಾ ಹಾನಿ?

ಅಭಿವೃದ್ಧಿ ತಂಡದಲ್ಲಿ "ಯೂನಿವರ್ಸಲ್": ಪ್ರಯೋಜನ ಅಥವಾ ಹಾನಿ?

ಎಲ್ಲರಿಗು ನಮಸ್ಖರ! ನನ್ನ ಹೆಸರು ಲ್ಯುಡ್ಮಿಲಾ ಮಕರೋವಾ, ನಾನು UBRD ನಲ್ಲಿ ಡೆವಲಪ್ಮೆಂಟ್ ಮ್ಯಾನೇಜರ್ ಆಗಿದ್ದೇನೆ ಮತ್ತು ನನ್ನ ತಂಡದ ಮೂರನೇ ಒಂದು ಭಾಗವು "ಜನರಲಿಸ್ಟ್ಗಳು".

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

ಅವನು ಯಾರು, ನಮ್ಮ ನಿರೀಕ್ಷೆಗಳ ಮುಂದಾಳು?

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

ತಂಡದ ಪರಸ್ಪರ ಕ್ರಿಯೆ ಮತ್ತು ಅದರ ಕೆಲಸದ ಫಲಿತಾಂಶವು ಭಾಗವಹಿಸುವವರ ವೃತ್ತಿಪರ ಮತ್ತು ವೈಯಕ್ತಿಕ ಗುಣಗಳನ್ನು ಅವಲಂಬಿಸಿರುತ್ತದೆ.

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

ಐಟಿ ಉದ್ಯಮದಲ್ಲಿ ಎಲ್ಲಾ ರೀತಿಯ ವ್ಯಕ್ತಿತ್ವ ಪ್ರಕಾರಗಳ ಬಗ್ಗೆ ಅನೇಕ ಲೇಖನಗಳಿವೆ. ನನ್ನ ಅನುಭವದ ಆಧಾರದ ಮೇಲೆ, ನಾನು ಐಟಿ ಸಾಮಾನ್ಯವಾದಿಗಳನ್ನು ನಾಲ್ಕು ವರ್ಗಗಳಾಗಿ ವಿಂಗಡಿಸುತ್ತೇನೆ:

1. "ಯೂನಿವರ್ಸಲ್ - ಆಲ್ಮೈಟಿ"

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

ಅವರು ಯಾವುದರಲ್ಲಿ ಪ್ರಬಲರಾಗಿದ್ದಾರೆ:

  • ಸಂಕೀರ್ಣ ಸಮಸ್ಯೆಗಳನ್ನು ಪರಿಹರಿಸಲು ಸಾಧ್ಯವಾಗುತ್ತದೆ;
  • ಸಮಸ್ಯೆಗೆ ಆಳವಾಗಿ ಧುಮುಕುವುದು, "ಡಿಗ್" ಮತ್ತು ಫಲಿತಾಂಶಗಳನ್ನು ಸಾಧಿಸುವುದು;
  • ಜಿಜ್ಞಾಸೆಯ ಮನಸ್ಸನ್ನು ಹೊಂದಿರುತ್ತಾರೆ.

ಆದರೆ:

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

2. "ಯೂನಿವರ್ಸಲ್ - ನಾನು ಅದನ್ನು ಲೆಕ್ಕಾಚಾರ ಮಾಡುತ್ತೇನೆ ಮತ್ತು ಅದನ್ನು ಮಾಡುತ್ತೇನೆ"

ಅಂತಹ ಜನರಿಗೆ ಕೇವಲ ಕೈಪಿಡಿ ಮತ್ತು ಸ್ವಲ್ಪ ಸಮಯ ಬೇಕಾಗುತ್ತದೆ - ಮತ್ತು ಅವರು ಸಮಸ್ಯೆಯನ್ನು ಪರಿಹರಿಸುತ್ತಾರೆ. ಅವರು ಸಾಮಾನ್ಯವಾಗಿ DevOps ನಲ್ಲಿ ಬಲವಾದ ಹಿನ್ನೆಲೆಯನ್ನು ಹೊಂದಿರುತ್ತಾರೆ. ಅಂತಹ ಸಾಮಾನ್ಯವಾದಿಗಳು ವಿನ್ಯಾಸದೊಂದಿಗೆ ತಮ್ಮನ್ನು ತಾವು ಚಿಂತಿಸುವುದಿಲ್ಲ ಮತ್ತು ಅವರ ಅನುಭವದ ಆಧಾರದ ಮೇಲೆ ಅಭಿವೃದ್ಧಿ ವಿಧಾನವನ್ನು ಬಳಸಲು ಬಯಸುತ್ತಾರೆ. ಕಾರ್ಯವನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸಲು ಆಯ್ಕೆಮಾಡಿದ ಆಯ್ಕೆಯ ಬಗ್ಗೆ ಅವರು ತಾಂತ್ರಿಕ ನಾಯಕರೊಂದಿಗೆ ಸುಲಭವಾಗಿ ಚರ್ಚೆ ನಡೆಸಬಹುದು.

ಅವರು ಯಾವುದರಲ್ಲಿ ಪ್ರಬಲರಾಗಿದ್ದಾರೆ:

  • ಸ್ವತಂತ್ರ;
  • ಒತ್ತಡ-ನಿರೋಧಕ;
  • ಅನೇಕ ಸಮಸ್ಯೆಗಳಲ್ಲಿ ಸಮರ್ಥ;
  • ಪ್ರಬುದ್ಧ - ಅವರೊಂದಿಗೆ ಮಾತನಾಡಲು ಯಾವಾಗಲೂ ಏನಾದರೂ ಇರುತ್ತದೆ.

ಆದರೆ:

  • ಆಗಾಗ್ಗೆ ಕಟ್ಟುಪಾಡುಗಳನ್ನು ಉಲ್ಲಂಘಿಸುತ್ತದೆ;
  • ಎಲ್ಲವನ್ನೂ ಸಂಕೀರ್ಣಗೊಳಿಸಲು ಒಲವು: ಭಾಗಗಳ ಮೂಲಕ ಸಂಯೋಜಿಸುವ ಮೂಲಕ ಗುಣಾಕಾರ ಕೋಷ್ಟಕವನ್ನು ಪರಿಹರಿಸಿ;
  • ಕೆಲಸದ ಗುಣಮಟ್ಟ ಕಡಿಮೆಯಾಗಿದೆ, ಎಲ್ಲವೂ 2-3 ಬಾರಿ ಕೆಲಸ ಮಾಡುತ್ತದೆ;
  • ಅವರು ನಿರಂತರವಾಗಿ ಗಡುವನ್ನು ಬದಲಾಯಿಸುತ್ತಾರೆ, ಏಕೆಂದರೆ ವಾಸ್ತವದಲ್ಲಿ ಎಲ್ಲವೂ ಅಷ್ಟು ಸುಲಭವಲ್ಲ.

3. "ಯೂನಿವರ್ಸಲ್ - ಸರಿ, ನಾನು ಅದನ್ನು ಮಾಡುತ್ತೇನೆ, ಏಕೆಂದರೆ ಬೇರೆ ಯಾರೂ ಇಲ್ಲ"

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

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

ಅವರು ಯಾವುದರಲ್ಲಿ ಪ್ರಬಲರಾಗಿದ್ದಾರೆ:

  • ಜವಾಬ್ದಾರಿಯುತ;
  • ಫಲಿತಾಂಶ-ಆಧಾರಿತ;
  • ಶಾಂತ;
  • ಸಂಪೂರ್ಣವಾಗಿ ನಿಯಂತ್ರಿಸಲಾಗಿದೆ.

ಆದರೆ:

  • ಕಡಿಮೆ ಮಟ್ಟದ ಸಾಮರ್ಥ್ಯಗಳಿಂದಾಗಿ ಸರಾಸರಿ ಫಲಿತಾಂಶಗಳನ್ನು ತೋರಿಸಿ;
  • ಸಂಕೀರ್ಣ ಮತ್ತು ಅಮೂರ್ತ ಸಮಸ್ಯೆಗಳನ್ನು ಪರಿಹರಿಸಲು ಸಾಧ್ಯವಿಲ್ಲ.

4. "ಒಬ್ಬ ಆಲ್ ರೌಂಡರ್ ಅವನ ಕುಶಲತೆಯ ಮಾಸ್ಟರ್"

ಡೆವಲಪರ್ ಆಗಿ ಗಂಭೀರ ಹಿನ್ನೆಲೆ ಹೊಂದಿರುವ ವ್ಯಕ್ತಿಯು ಸಿಸ್ಟಮ್ ಚಿಂತನೆಯನ್ನು ಹೊಂದಿರುತ್ತಾನೆ. ಪೆಡಾಂಟಿಕ್, ತನ್ನನ್ನು ಮತ್ತು ಅವನ ತಂಡವನ್ನು ಒತ್ತಾಯಿಸುತ್ತಾನೆ. ಗಡಿಗಳನ್ನು ವ್ಯಾಖ್ಯಾನಿಸದಿದ್ದರೆ ಅವನನ್ನು ಒಳಗೊಂಡ ಯಾವುದೇ ಕಾರ್ಯವು ಅನಿರ್ದಿಷ್ಟವಾಗಿ ಬೆಳೆಯಬಹುದು.

ಅವರು ವಾಸ್ತುಶಿಲ್ಪದೊಂದಿಗೆ ಚೆನ್ನಾಗಿ ಪರಿಚಿತರಾಗಿದ್ದಾರೆ, ತಾಂತ್ರಿಕ ಅನುಷ್ಠಾನದ ವಿಧಾನವನ್ನು ಆಯ್ಕೆ ಮಾಡುತ್ತಾರೆ, ಪ್ರಸ್ತುತ ವಾಸ್ತುಶಿಲ್ಪದ ಮೇಲೆ ಆಯ್ಕೆಮಾಡಿದ ಪರಿಹಾರದ ಪ್ರಭಾವವನ್ನು ಎಚ್ಚರಿಕೆಯಿಂದ ವಿಶ್ಲೇಷಿಸುತ್ತಾರೆ. ಸಾಧಾರಣ, ಮಹತ್ವಾಕಾಂಕ್ಷೆಯಲ್ಲ.

ಅವರು ಯಾವುದರಲ್ಲಿ ಪ್ರಬಲರಾಗಿದ್ದಾರೆ:

  • ಕೆಲಸದ ಉತ್ತಮ ಗುಣಮಟ್ಟವನ್ನು ತೋರಿಸಿ;
  • ಯಾವುದೇ ಸಮಸ್ಯೆಯನ್ನು ಪರಿಹರಿಸುವ ಸಾಮರ್ಥ್ಯ;
  • ಅತ್ಯಂತ ಪರಿಣಾಮಕಾರಿ.

ಆದರೆ:

  • ಇತರರ ಅಭಿಪ್ರಾಯಗಳ ಅಸಹಿಷ್ಣುತೆ;
  • ಗರಿಷ್ಠವಾದಿಗಳು. ಅವರು ಎಲ್ಲವನ್ನೂ ಸರಿಯಾಗಿ ಮಾಡಲು ಪ್ರಯತ್ನಿಸುತ್ತಾರೆ, ಮತ್ತು ಇದು ಅಭಿವೃದ್ಧಿ ಸಮಯವನ್ನು ಹೆಚ್ಚಿಸುತ್ತದೆ.

ನಾವು ಆಚರಣೆಯಲ್ಲಿ ಏನು ಹೊಂದಿದ್ದೇವೆ?

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

ಸಾಮರ್ಥ್ಯಗಳನ್ನು ಸಂಯೋಜಿಸುವ/ವಿಲೀನಗೊಳಿಸುವ/ಒಗ್ಗೂಡಿಸುವ ಅತ್ಯಂತ ಸಾಮಾನ್ಯ ಆಯ್ಕೆಯೆಂದರೆ ಡೆವಲಪರ್-ವಿಶ್ಲೇಷಕ. ಪರೀಕ್ಷಾ ವಿಶ್ಲೇಷಕ ಮತ್ತು "ಒಂದರಲ್ಲಿ ಮೂರು" ಸಹ ತುಂಬಾ ಸಾಮಾನ್ಯವಾಗಿದೆ.

ನನ್ನ ತಂಡವನ್ನು ಉದಾಹರಣೆಯಾಗಿ ಬಳಸಿಕೊಂಡು, ನನ್ನ ಸಹವರ್ತಿ ಸಾಮಾನ್ಯರ ಸಾಧಕ-ಬಾಧಕಗಳನ್ನು ನಾನು ನಿಮಗೆ ತೋರಿಸುತ್ತೇನೆ. ನನ್ನ ತಂಡದಲ್ಲಿ ಅವರಲ್ಲಿ ಮೂರನೇ ಒಂದು ಭಾಗವಿದೆ, ಮತ್ತು ನಾನು ಅವರನ್ನು ತುಂಬಾ ಪ್ರೀತಿಸುತ್ತೇನೆ.

ಅಸ್ತಿತ್ವದಲ್ಲಿರುವ ಉತ್ಪನ್ನಕ್ಕೆ ಹೊಸ ಸುಂಕಗಳನ್ನು ಪರಿಚಯಿಸಲು PO ತುರ್ತು ಕಾರ್ಯವನ್ನು ಸ್ವೀಕರಿಸಿದೆ. ನನ್ನ ತಂಡವು 4 ವಿಶ್ಲೇಷಕರನ್ನು ಹೊಂದಿದೆ. ಆ ಸಮಯದಲ್ಲಿ, ಒಬ್ಬರು ರಜೆಯಲ್ಲಿದ್ದರು, ಇನ್ನೊಬ್ಬರು ಅನಾರೋಗ್ಯದಿಂದ ಬಳಲುತ್ತಿದ್ದರು ಮತ್ತು ಉಳಿದವರು ಕಾರ್ಯತಂತ್ರದ ಕಾರ್ಯಗಳ ಅನುಷ್ಠಾನದಲ್ಲಿ ತೊಡಗಿದ್ದರು. ನಾನು ಅವರನ್ನು ಹೊರತೆಗೆದರೆ, ಅದು ಅನಿವಾರ್ಯವಾಗಿ ಅನುಷ್ಠಾನದ ಗಡುವನ್ನು ಅಡ್ಡಿಪಡಿಸುತ್ತದೆ. ಒಂದೇ ಒಂದು ಮಾರ್ಗವಿದೆ: “ರಹಸ್ಯ ಆಯುಧ” ವನ್ನು ಬಳಸಲು - ಅಗತ್ಯವಿರುವ ವಿಷಯದ ಪ್ರದೇಶವನ್ನು ಕರಗತ ಮಾಡಿಕೊಂಡ ಬಹುಮುಖ ಡೆವಲಪರ್-ವಿಶ್ಲೇಷಕ. ಅವನನ್ನು ಅನಾಟೊಲಿ ಎಂದು ಕರೆಯೋಣ.

ಅವರ ವ್ಯಕ್ತಿತ್ವದ ಪ್ರಕಾರ "ಸಾರ್ವತ್ರಿಕ - ನಾನು ಅದನ್ನು ಲೆಕ್ಕಾಚಾರ ಮಾಡುತ್ತೇನೆ ಮತ್ತು ಅದನ್ನು ಮಾಡುತ್ತೇನೆ". ಸಹಜವಾಗಿ, ಅವರು "ತನ್ನ ಕಾರ್ಯಗಳ ಸಂಪೂರ್ಣ ಬ್ಯಾಕ್ಲಾಗ್ ಅನ್ನು ಹೊಂದಿದ್ದಾರೆ" ಎಂದು ವಿವರಿಸಲು ಅವರು ದೀರ್ಘಕಾಲದವರೆಗೆ ಪ್ರಯತ್ನಿಸಿದರು, ಆದರೆ ನನ್ನ ಬಲವಾದ ಇಚ್ಛಾಶಕ್ತಿಯ ನಿರ್ಧಾರದಿಂದ ಅವರು ತುರ್ತು ಸಮಸ್ಯೆಯನ್ನು ಪರಿಹರಿಸಲು ಕಳುಹಿಸಲ್ಪಟ್ಟರು. ಮತ್ತು ಅನಾಟೊಲಿ ಅದನ್ನು ಮಾಡಿದರು! ಅವರು ವೇದಿಕೆಯನ್ನು ನಿರ್ವಹಿಸಿದರು ಮತ್ತು ಸಮಯಕ್ಕೆ ಅನುಷ್ಠಾನವನ್ನು ಪೂರ್ಣಗೊಳಿಸಿದರು ಮತ್ತು ಗ್ರಾಹಕರು ತೃಪ್ತರಾದರು.

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

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

ಮತ್ತೊಂದು ಪರಿಸ್ಥಿತಿ ಇತ್ತು. ಈಗ ನಾವು ಕೇವಲ ಒಬ್ಬ ಪರೀಕ್ಷಕನನ್ನು ಹೊಂದಿದ್ದೇವೆ, ಆದ್ದರಿಂದ ಕೆಲವು ಕಾರ್ಯಗಳನ್ನು ಸಾಮಾನ್ಯವಾದಿಗಳು ಸೇರಿದಂತೆ ವಿಶ್ಲೇಷಕರು ಪರೀಕ್ಷಿಸಬೇಕು. ಆದ್ದರಿಂದ, ನಾನು ಷರತ್ತುಬದ್ಧ ಫೆಡರ್‌ಗೆ ಒಂದು ಕೆಲಸವನ್ನು ನೀಡಿದ್ದೇನೆ - "ಸಾರ್ವತ್ರಿಕ - ಸರಿ, ನಾನು ಅದನ್ನು ಮಾಡುತ್ತೇನೆ, ಏಕೆಂದರೆ ಬೇರೆ ಯಾರೂ ಇಲ್ಲ".
ಫೆಡರ್ "ಒಂದರಲ್ಲಿ ಮೂರು", ಆದರೆ ಈ ಕಾರ್ಯಕ್ಕಾಗಿ ಡೆವಲಪರ್ ಅನ್ನು ಈಗಾಗಲೇ ನಿಯೋಜಿಸಲಾಗಿದೆ. ಇದರರ್ಥ ಫೆಡಿಯಾ ಒಬ್ಬ ವಿಶ್ಲೇಷಕ ಮತ್ತು ಪರೀಕ್ಷಕನನ್ನು ಮಾತ್ರ ಸಂಯೋಜಿಸಬೇಕಾಗಿತ್ತು.

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

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

ನಾವು ಸಮಸ್ಯೆಗಳನ್ನು ಹೇಗೆ ಎದುರಿಸುತ್ತೇವೆ?

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

1. ತೊಂದರೆಗಳನ್ನು ಉಂಟುಮಾಡುವ ಪ್ರತಿಯೊಂದು ಕಾರ್ಯಕ್ಕಾಗಿ, ಏಕೀಕೃತ ಫಾರ್ಮ್ ಅನ್ನು ಭರ್ತಿ ಮಾಡಲು ನಾನು ನಿಮ್ಮನ್ನು ಕೇಳುತ್ತೇನೆ: ದೋಷ ನಕ್ಷೆ, ಇದು "ಡ್ರಾಡೌನ್" ಸಂಭವಿಸಿದ ಹಂತವನ್ನು ಗುರುತಿಸಲು ನಿಮಗೆ ಅನುಮತಿಸುತ್ತದೆ:

ಅಭಿವೃದ್ಧಿ ತಂಡದಲ್ಲಿ "ಯೂನಿವರ್ಸಲ್": ಪ್ರಯೋಜನ ಅಥವಾ ಹಾನಿ?

2. ಅಡಚಣೆಗಳನ್ನು ಗುರುತಿಸಿದ ನಂತರ, ಸಮಸ್ಯೆಯ ಮೇಲೆ ಪ್ರಭಾವ ಬೀರಿದ ಪ್ರತಿ ಉದ್ಯೋಗಿಯೊಂದಿಗೆ ಬುದ್ದಿಮತ್ತೆಯ ಅಧಿವೇಶನವನ್ನು ನಡೆಸಲಾಗುತ್ತದೆ: "ಏನು ಬದಲಾಯಿಸಬೇಕು?" (ನಾವು ಸಿಂಹಾವಲೋಕನದಲ್ಲಿ ವಿಶೇಷ ಪ್ರಕರಣಗಳನ್ನು ಪರಿಗಣಿಸುವುದಿಲ್ಲ), ಇದರ ಪರಿಣಾಮವಾಗಿ ನಿರ್ದಿಷ್ಟ ಕ್ರಿಯೆಗಳು (ಪ್ರತಿ ವ್ಯಕ್ತಿತ್ವ ಪ್ರಕಾರಕ್ಕೆ) ಗಡುವುಗಳೊಂದಿಗೆ ಜನಿಸುತ್ತವೆ.

3. ನಾವು ತಂಡದೊಳಗೆ ಸಂವಹನಕ್ಕಾಗಿ ನಿಯಮಗಳನ್ನು ಪರಿಚಯಿಸಿದ್ದೇವೆ. ಉದಾಹರಣೆಗೆ, ಯೋಜನಾ ನಿರ್ವಹಣಾ ವ್ಯವಸ್ಥೆಯಲ್ಲಿ ಕಾರ್ಯದ ಪ್ರಗತಿಯ ಕುರಿತು ಎಲ್ಲಾ ಮಾಹಿತಿಯನ್ನು ಅಗತ್ಯವಾಗಿ ದಾಖಲಿಸಲು ನಾವು ಒಪ್ಪಿಕೊಂಡಿದ್ದೇವೆ. ಅಭಿವೃದ್ಧಿ ಪ್ರಕ್ರಿಯೆಯಲ್ಲಿ ಕಲಾಕೃತಿಗಳನ್ನು ಬದಲಾಯಿಸಿದಾಗ/ಗುರುತಿಸಿದಾಗ, ಇದು ಜ್ಞಾನದ ನೆಲೆಯಲ್ಲಿ ಮತ್ತು ತಾಂತ್ರಿಕ ವಿಶೇಷಣಗಳ ಅಂತಿಮ ಆವೃತ್ತಿಯಲ್ಲಿ ಪ್ರತಿಫಲಿಸಬೇಕು.

4. ಪ್ರತಿ ಹಂತದಲ್ಲೂ ನಿಯಂತ್ರಣವನ್ನು ಕೈಗೊಳ್ಳಲು ಪ್ರಾರಂಭಿಸಿತು (ಹಿಂದೆ ಸಮಸ್ಯಾತ್ಮಕ ಹಂತಗಳಿಗೆ ವಿಶೇಷ ಗಮನವನ್ನು ನೀಡಲಾಗುತ್ತದೆ) ಮತ್ತು ಮುಂದಿನ ಕಾರ್ಯದ ಫಲಿತಾಂಶಗಳ ಆಧಾರದ ಮೇಲೆ ಸ್ವಯಂಚಾಲಿತವಾಗಿ.

5. ಮುಂದಿನ ಕಾರ್ಯದ ಫಲಿತಾಂಶವು ಬದಲಾಗದಿದ್ದರೆ, ಅವನು ಕಳಪೆಯಾಗಿ ನಿಭಾಯಿಸುವ ಪಾತ್ರದಲ್ಲಿ ನಾನು ಸಾಮಾನ್ಯವಾದಿಯನ್ನು ಪ್ರಶ್ನಿಸುವುದಿಲ್ಲ. ಈ ಪಾತ್ರದಲ್ಲಿ ಅವರ ಸಾಮರ್ಥ್ಯ ಮತ್ತು ಸಾಮರ್ಥ್ಯಗಳನ್ನು ಅಭಿವೃದ್ಧಿಪಡಿಸುವ ಬಯಕೆಯನ್ನು ನಿರ್ಣಯಿಸಲು ನಾನು ಪ್ರಯತ್ನಿಸುತ್ತೇನೆ. ನನಗೆ ಪ್ರತಿಕ್ರಿಯೆ ಸಿಗದಿದ್ದರೆ, ಅವರಿಗೆ ಹತ್ತಿರವಾದ ಪಾತ್ರದಲ್ಲಿ ಬಿಡುತ್ತೇನೆ.

ಕೊನೆಗೆ ಏನಾಯಿತು?

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

ಅಭಿವೃದ್ಧಿ ತಂಡದಲ್ಲಿ "ಯೂನಿವರ್ಸಲ್": ಪ್ರಯೋಜನ ಅಥವಾ ಹಾನಿ?

ಸಂಶೋಧನೆಗಳು

ಸಾಮಾನ್ಯ ನೌಕರರು ತಮ್ಮ ಬಾಧಕಗಳನ್ನು ಹೊಂದಿದ್ದಾರೆ.

ಪ್ಲಸಸ್:

  • ನೀವು ಯಾವುದೇ ಸಮಯದಲ್ಲಿ ಕುಗ್ಗುವ ಕೆಲಸವನ್ನು ಮುಚ್ಚಬಹುದು ಅಥವಾ ಕಡಿಮೆ ಸಮಯದಲ್ಲಿ ತುರ್ತು ದೋಷವನ್ನು ಪರಿಹರಿಸಬಹುದು;
  • ಸಮಸ್ಯೆಯನ್ನು ಪರಿಹರಿಸಲು ಒಂದು ಸಂಯೋಜಿತ ವಿಧಾನ: ಪ್ರದರ್ಶಕನು ಅದನ್ನು ಎಲ್ಲಾ ಪಾತ್ರಗಳ ದೃಷ್ಟಿಕೋನದಿಂದ ನೋಡುತ್ತಾನೆ;
  • ಸಾಮಾನ್ಯವಾದಿಗಳು ಬಹುತೇಕ ಎಲ್ಲವನ್ನೂ ಸಮಾನವಾಗಿ ಮಾಡಬಹುದು.

ಅನನುಕೂಲಗಳು:

  • BUS ಅಂಶ ಹೆಚ್ಚಾಗುತ್ತದೆ;
  • ಪಾತ್ರಕ್ಕೆ ಅಂತರ್ಗತವಾಗಿರುವ ಪ್ರಮುಖ ಸಾಮರ್ಥ್ಯಗಳು ನಾಶವಾಗುತ್ತವೆ. ಈ ಕಾರಣದಿಂದಾಗಿ, ಕೆಲಸದ ಗುಣಮಟ್ಟ ಕಡಿಮೆಯಾಗುತ್ತದೆ;
  • ಗಡುವುಗಳಲ್ಲಿ ಬದಲಾವಣೆಯ ಸಾಧ್ಯತೆಯು ಹೆಚ್ಚಾಗುತ್ತದೆ, ಏಕೆಂದರೆ ಪ್ರತಿ ಹಂತದಲ್ಲಿ ಯಾವುದೇ ನಿಯಂತ್ರಣವಿಲ್ಲ. "ನಕ್ಷತ್ರ" ಬೆಳೆಯುವ ಅಪಾಯಗಳು ಸಹ ಇವೆ: ಉದ್ಯೋಗಿಯು ತಾನು ಪರ ಎಂದು ಚೆನ್ನಾಗಿ ತಿಳಿದಿರುವ ವಿಶ್ವಾಸವಿದೆ;
  • ವೃತ್ತಿಪರ ಭಸ್ಮವಾಗಿಸುವಿಕೆಯ ಅಪಾಯವು ಹೆಚ್ಚಾಗುತ್ತದೆ;
  • ಯೋಜನೆಯ ಬಗ್ಗೆ ಬಹಳಷ್ಟು ಪ್ರಮುಖ ಮಾಹಿತಿಯು ನೌಕರನ "ತಲೆಯಲ್ಲಿ" ಮಾತ್ರ ಉಳಿಯಬಹುದು.

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

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

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

ಪ್ರತಿಯೊಬ್ಬರೂ "ತಮ್ಮ ಕರಕುಶಲತೆಯ ಸಾರ್ವತ್ರಿಕ ಮಾಸ್ಟರ್ಸ್" ನ ಸ್ವಯಂ-ಸಂಘಟನೆಯ ತಂಡವನ್ನು ನಾನು ಬಯಸುತ್ತೇನೆ!

ಮೂಲ: www.habr.com

ಕಾಮೆಂಟ್ ಅನ್ನು ಸೇರಿಸಿ