په ټیم کې د شخړې مدیریت - یو توازن عمل یا حیاتي اړتیا؟

خطاط:
یو وخت په ځنګل کې هیج هاګ او کوچنی ږیره سره ولیدل.
- سلام، هیجړا!
- سلام، کوچنی ږیره!
نو، کلمه په کلمه، ټوکه په ټوکه، هیج هاګ د کوچني ریښتو لخوا په مخ ووهل شو ...

لاندې زموږ د ټیم مشر ، او همدارنګه د RAS محصول پراختیا رییس ایګور مارنات ، د کاري شخړو ځانګړتیاو او د دوی اداره کولو احتمالي میتودونو په اړه بحث دی.

ډیری شخړې چې موږ په کار کې ورسره مخ کیږو د یوې سناریو له مخې رامینځته کیږي لکه څنګه چې په پورتنۍ خط کې بیان شوي. څو تنه ګډونوال په لومړي سر کې د یو بل په وړاندې ښه چلند کوي، هڅه کوي چې ځینې مسایل حل کړي، مګر په پای کې ستونزه ناحل پاتې کیږي او د ځینو لاملونو له امله د بحث د برخه والو ترمنځ اړیکې خرابیږي.

ژوند متنوع دی، او په پورته بیان شوي سناریو کې بدلونونه واقع کیږي. کله کله د ګډونوالو تر منځ اړیکي په پیل کې ډېر ښه نه وي، کله کله داسې مسله هم نه وي چې مستقیم حل ته اړتیا ولري (لکه د بېلګې په توګه په ایپیګراف کې)، کله ناکله له بحث وروسته اړیکې هماغه ډول پاتې کېږي لکه مخکې چې پیل شوې وې، خو مسله په نهایت کې نه حل کیږي.

په ټولو حالتونو کې څه عام دي چې د کاري شخړې د وضعیت په توګه تعریف کیدی شي؟



لومړی، دوه یا ډیر اړخونه شتون لري. دا ګوندونه کولی شي په سازمان کې مختلف ځایونه ونیسي، د مساواتو په اړیکه کې وي (په ټیم کې همکاران)، یا د درجه بندي په مختلفو کچو کې (باس - ماتحت) وي، انفرادي (کارمند) یا ډله وي (د شخړې په صورت کې. کارمند او یو ټیم یا دوه ټیمونه) او داسې نور. د شخړو احتمال او د هغې د حل اسانه کول د ګډون کونکو ترمنځ د باور په کچه خورا اغیزمن دي. څومره چې خواوې یو بل ښه پیژني، هومره د باور کچه لوړه وي، هومره د دې چانس لوړ وي چې دوی به یوې موافقې ته ورسیږي. د مثال په توګه، د ویشل شوي ټیم غړي چې هیڅکله یې مخامخ خبرې نه دي کړي د هغو خلکو په پرتله چې لږ تر لږه یو څو مخامخ متقابل عملونه لري د یوې ساده کاري مسلې په اړه د شخړې تجربه کوي. له همدې امله، کله چې په ویشل شوي ټیمونو کې کار کول، دا خورا مهمه ده چې ډاډ ترلاسه شي چې د ټیم ټول غړي وخت په وخت له یو بل سره په شخصی توګه ملاقات کوي.

دوهم، په کار کې د شخړو په حالت کې، اړخونه د ځینو مسلو د حل کولو په حالت کې دي چې د یو اړخ لپاره، د دواړو لپاره، یا د ټول سازمان لپاره مهم دي. په ورته وخت کې، د وضعیت د ځانګړتیاوو له امله، اړخونه معمولا د هغې د حل کولو لپاره کافي وخت او مختلفې لارې لري (رسمي، غیر رسمي، غونډې، مکتوبونه، د مدیریت پریکړې، د ټیم د اهدافو او پلانونو شتون، د سلسلې حقیقت، او داسې نور). دا په یوه اداره کې د کار (یا غیر کار) مسلې د حل کولو وضعیت څخه توپیر لري، د بیلګې په توګه، د یوې مهمې پوښتنې حل کول: "ای، ماشوم، تاسو د کومې سیمې څخه یاست؟!" په سړک کې، یا د ایپیګراف څخه شخړه. د کاري مسلې د حل کولو په صورت کې، د کاري پروسې کیفیت او په ټیم کې د مسلو د حل کولو کلتور مهم دی.

دریم، د شخړې ټاکونکی عامل (زموږ د بحث له نظره) دا حقیقت دی چې د پروسې اړخونه نشي کولی په خپلواکه توګه د دې مسلې حل ته ورسیږي چې د ټولو اړخونو سره مناسب وي. وضعیت د دریمې ډلې مداخلې ته اړتیا لري، یو بهرنی منځګړیتوب. ښایي دا ټکی جنجالي ښکاري، خو په اصل کې که د جګړې وضعیت د یوه بهرني منځګړي له مداخلې پرته په بریالیتوب سره حل شوی وای، مسله په بریالیتوب سره حل شوې وای او د اړخونو اړیکې خرابې نه شي، دا هغه حالت دی چې موږ یې باید هڅه وکړو. . موږ به ډیری احتمال حتی د داسې یوې شخړې په اړه هم نه پوهیږو، یا موږ به د حل کیدو وروسته په اتفاق سره ومومئ. څومره چې یو ټیم کولی شي په خپله حل کړي، هغومره به اغیزمن وي.

د شخړې بله ځانګړنه چې د پام وړ ده د پریکړې پرمهال د احساساتي شدت کچه ​​​​ده. شخړه اړینه نه ده چې د لوړې احساساتي کچې سره تړاو ولري. ګډونوال اړ نه دي چې چیغې وکړي او خپلې وسلې وغورځوي ترڅو وضعیت په حقیقت کې یوه شخړه وي. مسله نه حل کیږي، یو ځانګړی احساساتي فشار شتون لري (شاید دا په ښکاره توګه په ښکاره توګه نه وي څرګند شوی)، پدې معنی چې موږ د شخړې له وضعیت سره مخ یو.

ایا دا اړینه ده چې د شخړې په شرایطو کې مداخله وشي، یا دا غوره ده چې د دوی د حل لاره غوره کړي او د ستونزې د حل لپاره انتظار وکړي؟ ته اړتیا لري. دا تل ستاسو په واک یا وړتیا کې نه وي چې شخړه په بشپړ ډول حل کړئ ، مګر په هر حالت کې ، په هره پیمانه شخړه کې ، تاسو کولی شئ یو بالغ دریځ ونیسئ ، په دې توګه ستاسو شاوخوا څو نور خلک راوباسي او د منفي پایلو مخه ونیسي. شخړه او د هغې په حل کې مرسته کوي.

مخکې له دې چې د شخړو یو څو مثالونو ته وګورو، راځئ چې د ټولو شخړو لپاره یو څو مهم ټکي وګورو.

کله چې د شخړې حل کول، دا مهمه ده چې د جګړې څخه پورته وي، نه د هغې دننه (دا د "میټا موقف اخیستل" په نوم هم یادیږي)، دا د حل په بهیر کې د یو اړخ برخه نه وي. که نه نو، د بهرنۍ منځګړیتوب سره د پریکړې سره مرسته کول به یوازې د یو اړخ موقف پیاوړی کړي چې بل اړخ ته زیان ورسوي. کله چې پریکړه وکړئ، دا مهمه ده چې دا د ټولو اړخونو لخوا په اخلاقي توګه ومنل شي، لکه څنګه چې دوی وايي، "پیرودل شوي." په دې توګه، که څه هم ګوندونه د پریکړې څخه خوښ نه وو، دوی لږ تر لږه په صادقانه توګه د هغې پلي کولو موافقه وکړه. لکه څنګه چې دوی وايي، د اختلاف او ژمنتیا وړ وي. که نه نو، شخړه به په ساده ډول خپل بڼه بدله کړي، اور به د پیټ بوګ لاندې پاتې شي او په ځینو وختونو کې به په ناڅاپي ډول بیا راڅرګند شي.

دوهم ټکی، چې تر یوې اندازې پورې له لومړي سره تړاو لري، دا دی چې که تاسو دمخه د شخړې په حل کې د برخه اخیستو پریکړه کړې وي، د ارتباطاتو او د شرایطو د مطالعې له نظره د امکان تر حده جدي ونیسئ. په شخصي توګه د هر ګوند سره خبرې وکړئ. د هر یو سره جلا، د پیل لپاره. د بریښنالیک لپاره بسنه مه کوئ. د ویشل شوي ټیم په حالت کې، لږترلږه د ویډیو لینک له لارې خبرې وکړئ. د اوریدلو او عیني شاهدانو په راپورونو راضي مه اوسئ. په کیسه پوه شئ، چې هر اړخ څه غواړي، ولې یې غواړي، څه تمه لري، ایا مخکې یې د دې مسلې د هوارولو هڅه کړې، که حل نه شي، څه به کېږي، د حل لارې یې څه وي، د دریځ په اړه څه تصور کوي؟ بل اړخ، دوی څه فکر کوي، سم یا غلط، او نور. ټول احتمالي شرایط په خپل سر کې بار کړئ، په خلاص ذهن سره، داسې انګیرل چې هرڅوک سم دي. تاسو د شخړې دننه نه یاست، تاسو د هغې بهر یاست، په میټاپوزیشن کې. که شرایط یوازې د پوسټ په موضوع کې شتون ولري، لږترلږه په بشپړ ډول یې ولولئ او د هغې اړوند تارونه او اسناد. د لوستلو وروسته، بیا هم په خپل غږ سره خبرې وکړئ. تاسو تقریبا تضمین یاست چې یو څه مهم واورئ چې په بریښنالیک کې ندي.

دریم مهم ټکی د اړیکو عمومي چلند دی. دا عادي شیان دي، هیڅ کائناتي ندي، مګر دا خورا مهم دي. موږ د وخت د سپما کولو هڅه نه کوو، موږ د ټولو ګډون کوونکو سره خبرې کوو، موږ په شخص نیوکه نه کوو، مګر موږ د هغه د کړنو پایلې په پام کې نیسو (نه "تاسو بې رحمه یاست"، مګر "شاید هلکان ناراضه وي. دا شی")، موږ د مخ د ژغورلو فرصت ورکوو، موږ په شخصي توګه بحث کوو، نه د کرښې په وړاندې.

شخړې معمولا د دوو دلیلونو څخه یو له امله رامنځته کیږي. لومړی په دې پورې اړه لري چې آیا د شخړې په وخت کې یو کس د بالغ یا د ماشوم په موقف کې دی (په دې اړه نور لاندې لاندې). دا د هغه د احساساتي بلوغ له امله دی، د هغه د احساساتو اداره کولو وړتیا (کوم چې، په لاره کې، تل د هغه عمر پورې تړاو نلري). دوهم عام لامل د کاري پروسې نیمګړتیا ده، کوم چې د خړ ساحو حالت رامینځته کوي چې د ګډون کوونکو تر منځ مسؤلیتونه ویشل کیږي، د اړخونو تمه یو بل ته شفافه نه وي، او په پروسه کې رولونه تیاره کیږي.

په دې اساس، د شخړې په حل کولو کې (همدارنګه د کومې بلې مسلې)، مدیر باید درې نظرونه په پام کې ونیسي: لنډ مهاله - د دې لپاره چې ستونزه/شخړه دلته او اوس حل کړي، منځمهاله - د بلې شخړې د رامنځته کیدو احتمال کم کړي. د ورته دلیل لپاره، او اوږدې مودې - د ټیم شخص کې د بالغ کلتور وده کول.

موږ هر یو یو داخلي ماشوم لرو، شاوخوا درې یا څلور کلن. هغه ډیری وخت په کار کې ویده کیږي، مګر کله ناکله ویښیږي او کنټرول اخلي. ماشوم خپل لومړیتوبونه لري. د هغه لپاره دا مهمه ده چې ټینګار وکړي چې دا د هغه سینڈ باکس دی، مور یې له هغه سره ډیره مینه لري، ماشین یې غوره دی (ډیزاین غوره دی، هغه غوره پروګرام کوي، ...). د شخړو په حالت کې، یو ماشوم کولی شي لوبی فشار کړي، پښې یې ودروي او خپل سپتولا مات کړي، مګر هغه نشي کولی د لویانو مسلې حل کړي (د حل جوړښت، د اتوماتیک ازموینې طریقې، د خوشې کولو نیټه، او نور)، هغه د ګټو په اړه فکر نه کوي. د ټیم لپاره. یو ماشوم چې په شخړه کې وي وهڅول شي، تسلی ورکول شي او بستر ته لیږل کیدی شي له هغه څخه وغوښتل شي چې خپل بالغ ته بلنه ورکړي. مخکې له دې چې د شخړې په حالت کې خبرې اترې پیل کړئ، ډاډ ترلاسه کړئ چې تاسو د یو بالغ سره خبرې کوئ، نه ماشوم، او دا چې تاسو پخپله د بالغ حالت کې یاست. که په اوس وخت کې ستاسو صادقانه هدف د یوې جدي مسلې حل کول وي، تاسو د بالغ حالت کې یاست. که ستاسو هدف دا وي چې ستاسو پښې ودروئ او ستاسو اوږه تیغ مات کړئ ، دا یو ماشوم دریځ دی. خپل داخلي ماشوم بستر ته ولېږئ او یو بالغ ته زنګ ووهئ، یا د خبرو اترو مهالویش وکړئ. یو شخص احساساتي پریکړه کوي، او بیا د هغې لپاره منطقي توجیه ګوري. د ماشومانو د لومړیتوبونو پر بنسټ د ماشوم لخوا پریکړه به غوره نه وي.

د شخړو په وخت کې د چلند سربیره، د ماشوم یا بالغ موقف هم د مسؤلیت د کچې له مخې مشخص کیږي چې یو څوک چمتو دی چې ځان په غاړه واخلي. د دې په سختو څرګندونو کې، د پروګرامر ماشوم موقف، کوم چې ما یو ځل لیدلی دی، داسې ښکاري: ما کوډ لیکلی، د بیاکتنې لپاره یې لیږلی - زما کار پای ته رسیدلی. بیاکتونکي باید دا بیاکتنه وکړي او تصویب یې کړي، QA باید دا وګوري، که کومه ستونزه وي، دوی به ما خبر کړي. په عجیبه توګه، حتی کافي بالغ او تجربه لرونکي خلک کله ناکله دا ډول چلند کوي. د پیمان بله برخه دا ده چې یو شخص خپل ځان د دې لپاره مسؤل ګڼي چې ډاډ ترلاسه کړي چې د هغه کوډ کار کوي، د ازموینې پوښښ لري، د هغه لخوا په شخصي توګه چک شوی، په بریالیتوب سره بیاکتنه تیره شوې (که اړتیا وي، د بیاکتونکو په پینګ کولو کې کومه ستونزه نشته، د مسلو په اړه بحث کول. د غږ له لارې، او داسې نور) او فشار راوړل شوی، QA به مرسته چمتو کړي که اړتیا وي، د ازموینې سناریوګانې به بیان شي، او داسې نور. په نورمال حالتونو کې، پروګرامر یا هم د پیمانې بالغ پای ته نږدې پیل کوي، یا هلته حرکت کوي کله چې هغه تجربه ترلاسه کوي (په دې شرط چې سم کلتور په ټیم کې کرل شوی وي). په سختو قضیو کې، هغه کار ته دوام ورکوي، معمولا د ماشوم موقف اخلي، بیا هغه او ټیم په وخت سره ستونزې او شخړې لري.

په ټیم کې د سم، بالغ کلتور وده د هر مدیر لپاره یو مهم کار دی. دا ډیر وخت او ورځنۍ هڅې ته اړتیا لري، مګر پایله یې ارزښت لري. د ټیم کلتور اغیزمن کولو لپاره دوه لارې شتون لري - د مثال په توګه رهبري کول (کوم چې به یقینا تعقیب شي؛ ټیم تل مشر ته ګوري) او د سم چلند په اړه بحث او انعام ورکول. دلته هیڅ غیر رسمي یا خورا رسمي شتون نلري ، یوازې کله چې د ستونزو په اړه بحث وکړئ ، پام وکړئ چې دلته یو څه ترسره کیدی شي ، ټینګار وکړئ چې تاسو پام کړی کله چې سم پریکړه شوې وه ، ستاینه ، د خوشې بیاکتنې پرمهال یادونه ، او داسې نور.

راځئ چې د جګړې ډیری عادي حالتونه په پام کې ونیسو، له ساده څخه پیچلي ته:

شخړې د کاري مسلو سره تړاو نلري

ډیری وختونه په کار کې شخړې شتون لري چې د کاري مسلو سره تړاو نلري. د دوی واقع کیدل او د حل کولو اسانتیا معمولا مستقیم د برخه اخیستونکو احساساتي هوښیارتیا ، د دوی د بلوغت کچې پورې اړه لري ، او د کار پروسې بشپړتیا یا نیمګړتیا پورې تړاو نلري.

عادي مثالونه: یو څوک ډیری وختونه د مینځلو ماشین یا شاور نه کاروي، کوم چې نور یې نه خوښوي، یو څوک ډک وي، په داسې حال کې چې نور د کړکۍ پرانستلو په وخت کې باد راځي، یو څوک ډیر شور لري، او نور د کار کولو لپاره چوپتیا ته اړتیا لري، او داسې نور. دا به غوره وي چې د دې ډول شخړو په حل کې ځنډ ونه کړي او اجازه ورنکړي چې دوی خپله لاره غوره کړي. دوی به پخپله حل نه کړي او هره ورځ به تاسو له کار څخه لرې کړي او په ټیم کې به فضا مسموم کړي. په خوشبختۍ سره، د دوی حل کول معمولا لویه ستونزه نده - یوازې په آرامۍ سره خبرې وکړئ (یو په بل کې، البته) د هغه همکار سره چې حفظ الصحې ته پام نه کوي، د هغو خلکو لپاره آرامۍ څوکۍ چمتو کړئ چې چوپتیا / یخني ته ترجیح ورکوي، د غږ جذبونکي هیډفونونه واخلي یا پارشنونه نصب کړي. , etc.

بله بیلګه چې زه د خپل کار په جریان کې څو ځله ورسره مخ شوم د ټیم غړو رواني بې ثباتي ده. د ځینو دلیلونو لپاره، خلک په ساده ډول نشي کولی یوځای کار وکړي؛ هر متقابل عمل په اسکندل پای ته رسیږي. ځینې ​​​​وختونه دا د دې حقیقت له امله وي چې خلک په ځینو مهمو مسلو (معمولا سیاسي) کې قطبي نظرونه لري او نه پوهیږي چې څنګه دوی د کار څخه بهر پریږدي. دوی قانع کول چې یو بل زغمي یا د دوی چلند بدل کړي یو بې ځایه کار دی. یوازینی استثنا چې زه ورسره مخ شوی یم هغه ځوان همکاران دي چې د خلاص احساس سره دي؛ د دوی چلند لاهم د دورې خبرو اترو له لارې په تدریجي ډول بدلیدلی شي. معمولا مسله په بریالیتوب سره په مختلفو ټیمونو کې په جلا کولو سره حل کیږي، یا لږترلږه د کار کولو فرصت په ندرت سره حل کیږي.

په پورتنیو ټولو حالاتو کې دا ارزښت لري چې له ټولو ګډونوالو سره په شخصي توګه خبرې وکړي، د وضعیت په اړه بحث وکړي، پوښتنه وکړي چې ایا دوی په دې قضیه کې کومه ستونزه ویني، پوښتنه کوي چې د دوی په نظر، د حل لارې څه دي، او په دې برخه کې د دوی د ګډون ډاډ ترلاسه کول. پریکړه

د کاري پروسې د اصلاح کولو له نظره (د منځنۍ مودې لید چې ما ورته اشاره وکړه) دلته ډیر څه نه شي ترسره کیدی؛ د اصلاح کولو یوازینۍ ټکی د ټیم جوړولو په وخت کې د مطابقت فکتور په پام کې نیول دي نه د خلکو ځای په ځای کول. یوځای مخکې له مخکې به څوک شخړه وکړي.

د ټیم کلتور له نظره، دا ډول حالتونه ډیر لږ وخت په ټیمونو کې د بالغ کلتور سره رامینځته کیږي، چیرې چې خلک ټیم او همکارانو ته درناوی کوي او پوهیږي چې څنګه په خپلواکه توګه مسلې حل کړي. برسېره پردې، دا ډول شخړې په اسانۍ سره حل کیږي (اکثرا په اتوماتيک ډول) په ټیمونو کې چیرې چې د باور لوړه کچه شتون لري، خلکو د اوږدې مودې لپاره یوځای کار کړی او / یا د کار څخه بهر په مکرر ډول اړیکه نیسي.

د کاري مسلو اړوند شخړې:

دا ډول شخړې معمولا په یو وخت کې د دواړو دلیلونو له امله رامینځته کیږي، دواړه احساساتي (حقیقت چې د ګډون کوونکو څخه یو د بالغ په موقف کې نه وي) او پخپله د کار پروسې نیمګړتیا. شاید د شخړو ترټولو عام ډول چې ما ورسره مخ شوی د کوډ بیاکتنې یا د پراختیا کونکو ترمینځ د جوړښت بحثونو پرمهال شخړې دي.

زه به دلته دوه عادي قضیې په ګوته کړم:

1) په لومړي حالت کې، پراختیا کونکی نشي کولی د همکار څخه د کوډ بیاکتنه ترلاسه کړي. پیچ د بیاکتنې لپاره لیږل کیږي، او هیڅ شی نه کیږي. په لومړي نظر کې، د دواړو خواوو ترمنځ کومه ښکاره شخړه شتون نلري، مګر که تاسو ورته فکر وکړئ، دا ډیره شخړه ده. د کار مسله نه حل کیږي، یو اړخ (بیا کتنې ته انتظار کول) ښکاره ناخوښي تجربه کوي. د دې قضیې خورا فرعي ډول په ټولنه کې یا په مختلفو ټیمونو کې پرمختګ دی، پداسې حال کې چې بیاکتونکی ممکن د دې ځانګړي کوډ سره دلچسپي ونلري، د بار کولو یا نورو شرایطو له امله، ممکن د بیاکتنې غوښتنې ته هیڅ پام ونه کړي، او بهرنی ثالث (یو مدیر چې د دواړو خواوو لپاره عام دی)) ممکن شتون ونلري.

د حل لاره چې په داسې حالت کې مرسته کوي دقیقا د اوږدې مودې لید، د بالغ کلتور پورې اړه لري. لومړی، سمارټ فعالیت کار کوي. تاسو باید تمه ونه کړئ چې په بیاکتنه کې ځړول کوډ به پخپله د بیاکتونکي پام ځانته راجلب کړي. موږ اړتیا لرو د بیاکتونکو سره مرسته وکړو چې هغه ته پام وکړي. پینګاني یو څو کسان، د سنکیپ په اړه پوښتنه وکړئ، په بحثونو کې برخه واخلئ. په ښکاره ډول، د مرستې په پرتله د زیان رسولو احتمال ډیر دی، تاسو اړتیا لرئ چې د عقل څخه کار واخلئ. دوهم، مخکې چمتووالی ښه کار کوي. که ټیم پوه شي چې څه پیښیږي او ولې، ولې دا کوډ ته اړتیا لیدل کیږي، ډیزاین د هرچا سره دمخه بحث او موافقه شوې وي، خلک ډیر احتمال لري چې دا ډول کوډ ته پام وکړي او د کار لپاره یې ومني. دریم، واک کار کوي. که تاسو غواړئ بیاکتنه وکړئ، پخپله ډیری بیاکتنې وکړئ. د لوړ کیفیت بیاکتنې وکړئ، د اصلي چکونو، ریښتینې ازموینو، او ګټورو نظرونو سره. که ستاسو مستعار نوم په ټیم کې ښه پیژندل شوی وي ، نو ډیر چانس شتون لري چې ستاسو کوډ به په پام کې ونیول شي.

د کاري جریان له نظره، دلته احتمالي پرمختګونه سم لومړیتوبونه دي چې هدف یې د پراختیا کونکي سره د هغه او ټیم اهدافو په ترلاسه کولو کې مرسته کول دي (نورو بیاکتنه وکړئ، ټولنې ته لیکونه ولیکئ، د کوډ سره د جوړښت توضیحات، اسناد، ازموینې، په بحثونو کې برخه واخلئ. ټولنه، او داسې نور)، د پیچونو مخه نیسي چې په کتار کې د ډیر وخت لپاره ځړول کیږي، او داسې نور.

2) د کوډ یا ډیزاین بیاکتنې پرمهال د شخړو دوهم عام قضیه د تخنیکي مسلو، کوډ کولو سټایل، او د وسیلو انتخاب په اړه مختلف نظرونه دي. په دې قضیه کې خورا مهم د ګډون کوونکو ترمنځ د باور کچه، په ورته ټیم پورې اړه لري، او د یوځای کار کولو تجربه ده. یو مړ پای هغه وخت رامینځته کیږي کله چې یو برخه اخیستونکي د ماشومتوب دریځ غوره کړي او هڅه نه کوي چې هغه څه واوري چې مرکه کوونکی یې ورته رسول غواړي. ډیری وختونه، دواړه د بل لوري لخوا وړاندیز شوي چلند او په پیل کې وړاندیز شوي چلند ممکن په بریالیتوب سره کار وکړي او دا په اصولو کې مهمه نده چې کوم یو غوره کړي.

یوه ورځ، زما د ټیم یو پروګرامر (راځئ چې هغه ته پاشا ووایو) د بسته بندۍ سیسټم کې د بدلونونو سره یو پیچ چمتو کړ، کوم چې د ګاونډیو څانګې د همکارانو لخوا رامینځته شوی او ملاتړ شوی. یو له دوی څخه (ایګور) د دې په اړه خپل قوي نظر درلود چې د لینوکس خدمات باید څنګه تنظیم شي کله چې د کڅوړو ځای په ځای کول. دا نظر په پیچ کې وړاندیز شوي طریقې سره توپیر درلود، او دوی موافق نه و. د معمول په څیر، وخت پای ته رسیدلی و، او دا اړینه وه چې یو ډول پریکړې ته ورسیږو؛ دا اړینه وه چې یو له دوی څخه یو بالغ موقف واخلي. پاشا پوهیده چې دواړه طریقې د ژوند حق لري، مګر هغه غوښتل چې د هغه اختیار تیر شي نه یو او نه هم دویم اختیار کومه ښکاره تخنیکي ګټې درلودې.

زموږ بحث یو څه داسې ښکاریده (په خورا منظم ډول، البته، خبرې نیم ساعت دوام درلود):

- پاشا، موږ په څو ورځو کې یو فیچر منجمد لرو. دا مهمه ده چې موږ هرڅه یوځای ترلاسه کړو او ژر تر ژره ازموینه پیل کړو. څنګه کولای شو چی د ایګور له لارې ترلاسه کړو؟
- هغه غواړي خدمات په بل ډول تنظیم کړي ، هغه زما لپاره دلته تبصرې ودرولې ...
- او هلته څه دي، لوی بدلونونه، ډیر ګډوډي؟
- نه، یو څو ساعته کار دی، خو په پای کې هیڅ توپیر نشته، دا به په هره طریقه کار وکړي، دا ولې اړین دی؟ ما یو څه جوړ کړل چې کار کوي، اجازه راکړئ چې ومنئ.
- واورئ، له څومره وخته دې دا خبرې کولې؟
- هو، موږ اوس د یوې نیمې اونۍ لپاره وخت په نښه کوو.
- اما ... ایا موږ کولی شو یوه مسله په څو ساعتونو کې حل کړو چې دمخه یې یوه نیمه اونۍ وخت نیولی وي او نه یې کوي؟
- ښه، هو، مګر زه نه غواړم ایګور فکر وکړي چې زه په دې کې غلی شوی یم ...
- واورئ، تاسو ته نور څه مهم دي چې خوشې کول، دننه ستاسو د پریکړې سره، یا د ایګور وژلو لپاره؟ موږ کولی شو دا بند کړو، په هرصورت، د خوشې کولو سره د الوتنې لپاره یو ښه چانس شتون لري.
- ښه ... دا به ښه وي، البته، د ایګور پوزه پاکول، مګر ښه، خوشې کول خورا مهم دي، زه موافق یم.
- ایا دا واقعیا ستاسو لپاره مهم دی چې ایګور څه فکر کوي؟ د ریښتیني کیدو لپاره ، هغه هیڅ زیان نه ورکوي ، هغه یوازې د شیانو په بیلابیلو ځایونو کې یو متحد چلند غواړي د کوم لپاره چې هغه مسؤل دی.
- ښه، سمه ده، اجازه راکړئ لکه څنګه چې هغه په ​​​​نظرونو کې پوښتنه کوي او راځئ چې ازموینه پیل کړو.
- مننه، پاشا! زه ډاډه وم چې ستاسو دواړو څخه به تاسو ډیر بالغ یاست، که څه هم ایګوریک ستاسو څخه لوی دی :)

مسله هواره شوه، په خپل وخت خوشې شو، پاشا د ډېر خپګان احساس ونه کړ، ځکه هغه پخپله د حل وړاندیز وکړ او هغه یې پلي کړ. ایګور عموما خوښ و، ځکه چې ... د هغه نظر په پام کې ونیول شو او دوی هغه څه وکړل لکه څنګه چې هغه وړاندیز وکړ.

په اصل کې د ورته شخړو بل ډول په پروژه کې د تخنیکي حلونو/کتابتونونو/طریقو ترمنځ انتخاب دی، په ځانګړې توګه په ویشل شوي ټیم کې. په یوه پروژه کې، چې د C/C++ کارولو په توګه موقعیت درلود، دا معلومه شوه چې د پروژې تخنیکي مدیریت په کلکه د STL (معیاري ټیمپلیټ کتابتون) کارولو سره مخالف و. دا یو معیاري ژبی کتابتون دی چې پراختیا ساده کوي، او زموږ ټیم د دې سره ډیر عادت شوی. دا معلومه شوه چې پروژه د C++ په پرتله C ته خورا نږدې ده، کوم چې ټیم ډیر هڅولی نه و، ځکه چې مدیریت خپله غوره هڅه وکړه او واقعیا ښه پلس لوبغاړي استخدام کړل. په ورته وخت کې، د ټیم امریکایي برخه، انجنیران او مدیران دواړه د اوږدې مودې لپاره په شرکت کې کار کاوه، د اوسني حالت سره عادت شوي، او له هرڅه څخه خوښ وو. د ټیم روسی برخه په دې وروستیو کې په څو اونیو کې (زما په شمول) سره یوځای شوه. د ټیم د روسیې برخه په کلکه نه غوښتل چې د پرمختګ لپاره د معمول چلند پریږدي.

د دواړو براعظمونو تر منځ نه ختمیدونکي لیکل شوي بحثونه پیل شول، په دریو یا څلورو سکرینونو کې لیکونه شا او خوا روان شول، په ډله ایزو لیکونو او شخصي لیکونو کې، د پروګرام کونکو څخه پروګرامرانو او مدیرانو ته. لکه څنګه چې معمولا قضیه وي، د دې اوږدوالی لیکونه د لیکوالانو او د دوی د ملاتړو څخه پرته بل چا نه لوستل. چیټونه د تشنج سره رامینځته شوي ، د STL تخنیکي ګټو په اړه په بیلابیلو لارښوونو کې د څو سکرین افکارو تیریدل ، دا څومره ښه ازمول شوی ، څومره خوندي دی ، او په عموم کې د دې سره ژوند څومره په زړه پوری دی ، او پرته له دې څومره ویرونکی دی. .

دا ټول ډیر وخت دوام وکړ، تر هغه چې زه په پای کې پوه شوم چې موږ د مسلې په تخنیکي اړخونو بحث کوو، مګر ستونزه په حقیقت کې تخنیکي نه وه. ستونزه د STL ګټې یا زیانونه یا پرته د کار کولو ستونزې ندي. ستونزه نه بلکه سازماني ده. موږ یوازې اړتیا لرو پوه شو چې هغه شرکت چې موږ یې کار کاوه څنګه کار کوي. زموږ څخه هیچا دمخه په داسې شرکت کې د کار کولو تجربه نه درلوده. خبره دا وه چې وروسته له دې چې کوډ رامینځته شو او تولید ته خپور شو ، ملاتړ د نورو هیوادونو څخه د نورو ټیمونو څخه په بشپړ ډول مختلف خلکو لخوا اداره شو. د لسګونو زرو انجینرانو دا لوی انجینري ټیم (په مجموع کې) یوازې د بشپړ لومړني لږترلږه تخنیکي وسیلو توان لري ، نو د خبرو کولو لپاره ، لږترلږه لږترلږه. هر هغه څه چې په شرکت کې په فزیکي توګه رامینځته شوي د انجینري معیار څخه هاخوا په راتلونکي کې ملاتړ نشي کیدی. د ټیم کچه د هغه د ضعیف غړو په کچه ټاکل کیږي. وروسته له دې چې موږ پوه شو ریښتینی هڅونه د ټیم د امریکایی برخې کړنې، دا مسله له اجنډا څخه لرې شوې، او په ګډه موږ په بریالیتوب سره د شرکت لخوا منل شوي معیارونو په کارولو سره محصول تولید او خپور کړ. په دې قضیه کې لیکونه او چیټونه ښه کار نه کوي؛ دا څو سفرونه او ډیری شخصي اړیکې نیولې ترڅو یو عام ډینومیټ ته راشي.

د کاري فلو له نظره، پدې ځانګړې قضیه کې، دا به د کارول شویو وسیلو توضیحات، د دوی اړتیاوې، د نویو اضافه کولو محدودیتونه، او د ورته محدودیتونو توجیه کولو کې مرسته وکړي. دا ډول اسناد تقریبا د هغو پراګرافونو سره مطابقت لري چې د "سافټویر پراختیا لپاره د مدیر لارښود کتاب" د بیا کارولو ستراتیژی او پراختیا چاپیریال په پراګرافونو کې بیان شوي، ناسا. د خپل عمر سره سره، دا د دې ډول سافټویر پراختیا ټول اصلي فعالیتونه او پالن جوړونې مرحلې په بشپړه توګه بیانوي. د دې په څیر اسناد درلودل دا خورا اسانه کوي چې بحث وکړي چې کوم برخې او طریقې په محصول کې کارول کیدی شي، او ولې.

له کلتوري پلوه، په ښکاره ډول، په یو ډیر بالغ دریځ سره، چې ګوندونه هڅه کوي د خپلو همکارانو د کړنو اصلي انګیزه واوري او پوه شي او د پروژې او ټیم د لومړیتوبونو پراساس عمل وکړي، نه د شخصي انا. ، شخړه به په اسانۍ او چټکه حل شي.

د تخنیکي حل د انتخاب په اړه په یوه بله شخړه کې، دا هم ما د پام وړ وخت واخیست چې د یوې خوا د هڅونې په اړه پوه شو (دا خورا غیر معمولي قضیه وه)، مګر وروسته له دې چې انګیزه روښانه شوه، حل څرګند شو.

وضعیت دا دی: یو نوی پراختیا کونکی د شاوخوا 20 کسانو په ډله کې څرګندیږي ، راځئ چې هغه ته سټاس ووایو. په هغه وخت کې، د ټیم په توګه د اړیکو لپاره زموږ معیاري وسیله سکایپ وه. لکه څنګه چې وروسته معلومه شوه، سټاس د خلاص معیارونو او خلاصې سرچینې سافټویر لوی پرستار و، او یوازې هغه وسیلې او عملیاتي سیسټمونه یې کارول چې سرچینې یې په عامه توګه شتون درلود او په عامه توګه تشریح شوي پروتوکولونه یې کارول. سکایپ یو له دې وسیلو څخه ندي. موږ د دې تګلارې د ګټو او زیانونو په اړه ډیر وخت تیر کړ، په مختلف عملیاتي سیسټمونو کې د سکایپ انلاګونو پیل کولو هڅې، د سټاس هڅې چې ټیم قانع کړي چې نورو معیارونو ته لاړ شي، هغه ته په شخصي توګه د بریښنالیک له لارې ولیکئ، هغه ته په شخصي توګه تلیفون وکړئ. تلیفون، هغه ته بل کمپیوټر په ځانګړي ډول د سکایپ لپاره وپیرئ. په نهایت کې، زه پوهیدم چې دا ستونزه، په اصل کې، تخنیکي یا سازماني نه ده، دا بلکه ایډیالوژیکي ده، حتی، یو څوک به ووایي، مذهبي (د سټاس لپاره). حتی که موږ بالاخره سټاس او سکایپ سره وصل کړو (کوم چې څو میاشتې وخت نیولی) ، ستونزه به بیا په راتلونکي وسیله کې راپورته شي. ما د سټاس نړۍ لید بدلولو لپاره زما په اختیار کې هیڅ ریښتیني وسیله نه درلوده ، او هیڅ دلیل شتون نلري چې د یوې ټیم نړۍ لید بدلولو هڅه وکړم چې پدې چاپیریال کې په بشپړ ډول کار کوي. شخص او شرکت په ساده ډول د دوی د نړۍ لید کې اورتوګونل وو. په داسې شرایطو کې، یو ښه حل سازماني دی. موږ Stas بل ټیم ​​ته لیږدول، چیرته چې هغه ډیر عضوي و.

د دې شخړې لامل، زما په اند، د یو ځانګړي کس د شخصي کلتور (څوک چې قوي نظر لري چې هغه ته اجازه نه ورکوي چې جوړجاړی وکړي) او د شرکت کلتور ترمنځ توپیر دی. په دې حالت کې، البته، دا د مدیر تېروتنه ده. دا په پیل کې غلطه وه چې هغه د دې ډول پروژې په غاړه واخلي. سټاس په پای کې د خلاصې سرچینې سافټویر پراختیا پروژې ته لاړ او هلته یې غوره کړه.

د جوړونکي د ماشوم چلند او د کاري پروسې نیمګړتیاو له امله رامینځته شوي شخړې یوه ښه بیلګه یو داسې حالت دی چې د ترسره شوي تعریف په نشتوالي کې ، پراختیا کونکی او د QA ټیم د چمتووالي په اړه مختلف تمې لري. خصوصیت QA ته لیږدول شوی. پرمختگپالونکي باور درلود چې دا کافي و چې کوډ ولیکئ او خصوصیت یې QA ته وغورځوئ - دوی به یې هلته تنظیم کړي. یو کافي بالغ او تجربه لرونکی برنامه ، په هرصورت ، مګر دا د کیفیت لپاره د هغه داخلي حد و. QA له دې سره موافق نه و او غوښتنه یې وکړه چې دوی ته هغه څه وښیې او تشریح کړي چې هغه پخپله چک کړي، او د دوی لپاره یې د ازموینې سکریپټ غوښتنه وکړه. دوی په تیرو وختونو کې د دې پراختیا کونکي فعالیت سره ستونزې درلودې او نه یې غوښتل خپل وخت بیا ضایع کړي. په لاره کې، دوی سم وو - فیچر واقعیا کار نه دی کړی، هغه QA ته د لیږلو دمخه کوډ ندی چک کړی.

د وضعیت د حل لپاره، ما له هغه څخه وغوښتل چې ما ته وښيي چې هرڅه واقعیا کار کوي (دا کار نه دی کړی، او هغه باید سم کړي)، موږ د ټیم سره خبرې وکړې او د QA تعریف سره (دوی دا کار نه دی کړی) لیکنه، ځکه چې موږ نه غوښتل دا پروسه ډیره بیوروکراسي جوړه کړو )، ښه، موږ ډیر ژر د دې متخصص (عمومي راحت) سره جلا شو.

د کاري فلو له نظره ، پدې قضیه کې ممکنه پرمختګونه د ترسره شوي تعریف شتون ، د هر واحد ځانګړتیا او ادغام ازموینې ملاتړ لپاره اړتیاوې ، او د پراختیا کونکي لخوا ترسره شوي ازموینې توضیحات دي. په یوه پروژه کې ، موږ د CI په جریان کې د ازموینو لخوا د کوډ پوښښ کچه اندازه کړه او که چیرې د پوښ اضافه کولو وروسته د پوښښ کچه راټیټه شي ، ازموینې د ناکامې په توګه په نښه شوي ، د بیلګې په توګه. کوم نوی کوډ یوازې هغه وخت اضافه کیدی شي که چیرې د دې لپاره نوي ازموینې شتون ولري.

د شخړو بله بیلګه د کار پروسې تنظیم سره نږدې تړاو لري. موږ یو محصول لرو، د محصول پراختیا ټیم، د ملاتړ ټیم، او یو پیرودونکی. پیرودونکي د محصول سره ستونزې لري او د ملاتړ سره تماس لري. ملاتړ ستونزه تحلیلوي او پوهیږي چې ستونزه په محصول کې ده او ستونزه د محصول ټیم ​​ته لیږدوي. د محصول ټیم ​​په بوخت وخت کې دی ، خوشې کیدو ته نږدې کیږي ، نو د پیرودونکي لخوا د ستونزې سره ټیکټ ، د پراختیا کونکي د نورو ټیکټونو په مینځ کې ورک شوی چې ورته ټاکل شوی ، د څو اونیو لپاره پرته له پاملرنې ځړیږي. ملاتړ فکر کوي چې پراختیا کونکي د پیرودونکي ستونزې باندې کار کوي. پیرودونکي انتظار کوي او هیله لري چې د دوی ستونزه حل شي. په واقعیت کې، تر اوسه هیڅ شی نه کیږي. د څو اونیو وروسته، پیرودونکي په پای کې پریکړه کوي چې په پرمختګ کې دلچسپي واخلي او د مالتړ څخه پوښتنه وکړي چې شیان څنګه پرمخ ځي. ملاتړ د پرمختګ غوښتنه کوي. پرمخ وړونکی ټکان کوي، د ټکټونو لیست ګوري او هلته د پیرودونکي څخه ټیکټ پیدا کوي. د پیرودونکي څخه د ټکټ لوستل، هغه پوهیږي چې د ستونزې حل کولو لپاره کافي معلومات شتون نلري، او هغه نور لاګونو او ډمپونو ته اړتیا لري. ملاتړ د پیرودونکي څخه اضافي معلوماتو غوښتنه کوي. او بیا پیرودونکی پوهیږي چې هیڅوک په دې ټول وخت کې د هغه ستونزې ته کار نه کوي. او تندر به ودریږي ...

پدې حالت کې ، پخپله د شخړې حل خورا څرګند او خطي دی (محصول تنظیم کړئ ، اسناد او ازموینې تازه کړئ ، پیرودونکي راضي کړئ ، هاټ فکس خوشې کړئ ، او داسې نور). دا مهمه ده چې د کار بهیر تحلیل او پوه شي چې څوک د دواړو ټیمونو ترمنځ د تعامل د تنظیم کولو مسولیت لري، او ولې دا وضعیت په لومړي ځای کې ممکن شو. دا روښانه ده چې په پروسه کې څه شی باید تنظیم شي - یو څوک باید په فعاله توګه د پیرودونکو له یادونې پرته ټول عکس وڅاري. د پیرودونکي ټکټونه باید د پراختیا کونکو څخه د نورو ټیکټونو په مینځ کې ودریږي. ملاتړ باید وګوري چې ایا پراختیایی ټیم اوس مهال په خپلو ټکټونو کار کوي، او که نه، کله چې دا کار پیل کولی شي، او کله چې پایلې تمه کیدی شي. ملاتړ او پراختیا باید وخت په وخت د ټکټونو وضعیت په اړه اړیکه ونیسي او بحث وکړي، د ډیبګ کولو لپاره اړین معلوماتو راټولول باید د امکان تر حده اتومات شي، او داسې نور.

لکه څنګه چې په جګړه کې دښمن هڅه کوي چې د دوو واحدونو تر منځ جنکشن په نښه کړي، نو په کار کې ترټولو نازک او زیان منونکی ټکی معمولا د ټیمونو ترمنځ تعامل دی. که د ملاتړ او پراختیا مدیران کافي زوړ وي، دوی به وکولی شي پخپله پروسه سمه کړي، که نه، پروسه به تر هغه وخته پورې شخړې او ستونزې رامینځته کړي چې یو مدیر مداخله وکړي چې وضعیت سم کړي.

یو بل عام مثال چې ما په مکرر ډول په مختلفو شرکتونو کې لیدلی دی یو داسې حالت دی چې په کې یو محصول د یوې ډلې لخوا لیکل کیږي، د دې لپاره د اتوماتیک ادغام ازموینې د دویمې ډلې لخوا لیکل کیږي، او زیربنا چې دا ټول پرمخ وړل کیږي د دریم سره یوځای کیږي. ټیم ستونزې کله چې د ازموینې چلولو هر وخت رامینځته کیږي ، او په دوی کې د ستونزو لامل دواړه محصول او ازموینې او زیربنا کیدی شي. دا معمولا ستونزمن وي چې موافقه وکړي چې څوک باید د ستونزو لومړني تحلیل ترسره کړي، د فایل بګونه، د محصول پارس لاګونه، ازموینې او زیربنا، او نور. دلته شخړې خورا مکرر دي، او په ورته وخت کې یونیفورم. د لوړ احساساتي شدت په حالت کې، ګډونوال اکثرا په ماشومتوب کې راځي او په لړۍ کې بحثونه پیل کیږي: "ولې زه باید له دې سره ټکر وکړم،" "دوی ډیر ځله مات شي،" او داسې نور.

د کاري فلو له لید څخه، د یوې مسلې د حل لپاره ځانګړي ګامونه د ټیمونو جوړښت، د ازموینو ډول او محصول، او داسې نور پورې اړه لري. په یوه پروژه کې، موږ دوره ای وظیفه معرفي کړه، په کوم کې چې ټیمونه په اونۍ کې په یوه وخت کې د ازموینې څارنه کوي. په بل کې، لومړنی تحلیل تل د ازموینې پراختیا کونکو لخوا ترسره کیده، مګر تحلیل خورا بنسټیز و او محصول خورا باثباته و، نو دا ښه کار وکړ. کلیدي دا ده چې ډاډ ترلاسه شي چې پروسه شفافه ده، تمه د ټولو خواوو لپاره روښانه ده، او دا چې وضعیت د هرچا لپاره عادلانه احساس کوي.

ایا شخړه حتی په یوه اداره کې ستونزه ده؟ ایا دا یوه بده نښه ده چې شخړې اکثرا (یا یوازې په وخت سره) ستاسو په ټیم کې پیښیږي؟ په عموم کې، نه، ځکه چې که چیرې وده، پرمختګ، یو ډول متحرکات شتون ولري، نو بیا داسې مسلې رامینځته کیږي چې مخکې هیڅکله نه دي حل شوي، او کله چې حل شي، شخړې رامنځ ته کیدی شي. دا یو شاخص دی چې ځینې برخې پاملرنې ته اړتیا لري، چې د پرمختګ لپاره ساحې شتون لري. دا بد دی که شخړې ډیری وختونه رامینځته شي ، حل کول یې ستونزمن وي یا ډیر وخت ونیسي. دا ډیری احتمال د ناکافي منظم کاري پروسې او د ټیم د ناکافي بلوغ نښه ده.

سرچینه: www.habr.com