კონფლიქტის მართვა გუნდში - დამაბალანსებელი აქტი თუ სასიცოცხლო აუცილებლობა?

ეპიგრაფი:
ერთხელ ზღარბი და პატარა დათვი ტყეში შეხვდნენ.
- გამარჯობა, ზღარბი!
- გამარჯობა, პატარა დათუნია!
ასე რომ, სიტყვა-სიტყვით, ხუმრობით ხუმრობით, ზღარბს სახეში მოხვდა პატარა დათვი...

ქვემოთ მოცემულია ჩვენი გუნდის ლიდერის, ასევე RAS-ის პროდუქტის განვითარების დირექტორის იგორ მარნატის დისკუსია სამუშაო კონფლიქტების სპეციფიკისა და მათი მართვის შესაძლო მეთოდების შესახებ.

კონფლიქტების უმეტესობა, რომელსაც ჩვენ ვხვდებით სამუშაოზე, ვითარდება ზემოთ მოცემულ ეპიგრაფში აღწერილი სცენარის მიხედვით. არის რამდენიმე მონაწილე, რომლებიც თავდაპირველად საკმაოდ კეთილგანწყობილნი არიან ერთმანეთის მიმართ, ცდილობენ რაღაც საკითხის გადაჭრას, მაგრამ საბოლოოდ პრობლემა გადაუჭრელი რჩება და რატომღაც დისკუსიის მონაწილეებს შორის ურთიერთობა გაფუჭებული აღმოჩნდება.

ცხოვრება მრავალფეროვანია და ვარიაციები ხდება ზემოთ აღწერილ სცენარში. ზოგჯერ მონაწილეებს შორის ურთიერთობა თავიდანვე არ არის ძალიან კარგი, ზოგჯერ კი არ არის საკითხი, რომელიც მოითხოვს პირდაპირ გადაწყვეტას (როგორც, მაგალითად, ეპიგრაფში), ზოგჯერ დისკუსიის შემდეგ ურთიერთობა იგივე რჩება, როგორც დაწყებამდე, მაგრამ საკითხი საბოლოოდ არ წყდება.

რა არის საერთო ყველა სიტუაციაში, რომელიც შეიძლება განისაზღვროს, როგორც სამუშაო კონფლიქტის სიტუაცია?



პირველ რიგში, არსებობს ორი ან მეტი მხარე. ამ მხარეებს შეუძლიათ დაიკავონ ორგანიზაციაში სხვადასხვა ადგილი, იყვნენ თანასწორუფლებიან ურთიერთობაში (კოლეგები გუნდში), ან იერარქიის სხვადასხვა დონეზე (უფროსი - დაქვემდებარებული), იყვნენ ინდივიდუალური (თანამშრომლები) ან ჯგუფური (კონფლიქტის შემთხვევაში, თანამშრომელი და გუნდი ან ორი გუნდი) და ა.შ. კონფლიქტის ალბათობაზე და მისი გადაჭრის სიმარტივეზე დიდ გავლენას ახდენს მონაწილეთა შორის ნდობის დონე. რაც უფრო კარგად იცნობენ მხარეები ერთმანეთს, რაც უფრო მაღალია ნდობის დონე, მით უფრო მაღალია შანსები, რომ მიაღწიონ შეთანხმებას. მაგალითად, განაწილებული გუნდის წევრები, რომლებსაც არასოდეს უკავშირდებოდნენ პირისპირ, უფრო ხშირად განიცდიან კონფლიქტს მარტივ სამუშაო საკითხთან დაკავშირებით, ვიდრე ადამიანები, რომლებსაც ჰქონიათ სულ მცირე რამდენიმე პირისპირ ურთიერთობა. ამიტომ, განაწილებულ გუნდებში მუშაობისას, ძალიან მნიშვნელოვანია, რომ გუნდის ყველა წევრი პერიოდულად შეხვდეს ერთმანეთს.

მეორეც, სამსახურში კონფლიქტურ სიტუაციაში მხარეები იმყოფებიან რაღაც საკითხის გადაჭრის სიტუაციაში, რომელიც მნიშვნელოვანია ერთ-ერთი მხარისთვის, ორივესთვის ან მთლიანად ორგანიზაციისთვის. ამავდროულად, სიტუაციის სპეციფიკიდან გამომდინარე, მხარეებს, როგორც წესი, აქვთ საკმარისი დრო და მისი გადაჭრის სხვადასხვა გზები (ფორმალური, არაფორმალური, შეხვედრები, წერილები, მენეჯმენტის გადაწყვეტილებები, გუნდის მიზნებისა და გეგმების არსებობა, იერარქიის ფაქტი და ა.შ.). ეს განსხვავდება ორგანიზაციაში სამუშაო (ან არასამუშაო) საკითხის გადაწყვეტისგან, მაგალითად, მნიშვნელოვანი კითხვის გადაწყვეტისგან: „ეჰ, შვილო, რომელი სფეროდან ხარ?!“ ქუჩაში, ან კონფლიქტი ეპიგრაფიდან. სამუშაო საკითხის მოგვარების შემთხვევაში მნიშვნელოვანია სამუშაო პროცესის ხარისხი და გუნდში საკითხების გადაჭრის კულტურა.

მესამე, კონფლიქტის განმსაზღვრელი ფაქტორი (ჩვენი განხილვის თვალსაზრისით) არის ის, რომ პროცესის მხარეები დამოუკიდებლად ვერ მიდიან იმ საკითხის გადაწყვეტამდე, რომელიც ყველა მხარეს შეეფერება. სიტუაცია მოითხოვს მესამე მხარის, გარე არბიტრის ჩარევას. ეს საკითხი შეიძლება საკამათო ჩანდეს, მაგრამ, არსებითად, თუ კონფლიქტური სიტუაცია წარმატებით მოგვარდა გარე არბიტრის ჩარევის გარეშე, საკითხი წარმატებით მოგვარდა და მხარეთა ურთიერთობა არ გაუარესდა, ეს ის ვითარებაა, რომლისკენაც უნდა ვისწრაფოდეთ. . ჩვენ, დიდი ალბათობით, არც კი გვეცოდინება ასეთი კონფლიქტის შესახებ, ან შემთხვევით გავიგებთ მისი მოგვარების შემდეგ. რაც უფრო მეტი საკითხის გადაჭრას შეძლებს გუნდი დამოუკიდებლად, მით უფრო ეფექტური იქნება ის.

კონფლიქტის კიდევ ერთი დამახასიათებელი თვისება, რომელზეც შეხება ღირს, არის გადაწყვეტილების მიღებისას ემოციური ინტენსივობის ხარისხი. კონფლიქტი სულაც არ ასოცირდება მაღალ ემოციურ დონესთან. მონაწილეებს არ უწევთ ყვირილი და ხელების ქნევა, რათა სიტუაცია, არსებითად, კონფლიქტი იყოს. საკითხი არ წყდება, არის გარკვეული ემოციური დაძაბულობა (შესაძლოა, გარეგნულად მკაფიოდ არ არის გამოხატული), რაც ნიშნავს, რომ კონფლიქტური სიტუაციის წინაშე ვდგავართ.

არის თუ არა საერთოდ საჭირო კონფლიქტურ სიტუაციებში ჩარევა, თუ ჯობია მივცეთ მათ გადაწყვეტას თავისი გზა და დაველოდოთ პრობლემის მოგვარებას? საჭიროა. კონფლიქტის სრულად გადაჭრა ყოველთვის თქვენს ძალაში ან კომპეტენციაში არ არის, მაგრამ ნებისმიერ სიტუაციაში, ნებისმიერი მასშტაბის კონფლიქტში შეგიძლიათ ზრდასრული პოზიცია დაიკავოთ, რითაც თქვენს გარშემო კიდევ რამდენიმე ადამიანს მიიყვანთ, შეამსუბუქოთ უარყოფითი შედეგები. კონფლიქტი და წვლილი შეიტანოს მის მოგვარებაში.

სანამ კონფლიქტური სიტუაციების რამდენიმე მაგალითს განვიხილავთ, მოდით შევხედოთ რამდენიმე მნიშვნელოვან პუნქტს, რომელიც საერთოა ყველა კონფლიქტისთვის.

კონფლიქტის მოგვარებისას მნიშვნელოვანია იყოთ ბრძოლაზე მაღლა და არა მის შიგნით (ამას ასევე უწოდებენ "მეტაპოზიციის დაკავებას"), ანუ არ იყოთ მოგვარების პროცესში ერთ-ერთი მხარის ნაწილი. წინააღმდეგ შემთხვევაში, გარე არბიტრის დახმარება, გადაწყვეტილება მხოლოდ გააძლიერებს ერთ-ერთი მხარის პოზიციას მეორე მხარის საზიანოდ. გადაწყვეტილების მიღებისას მნიშვნელოვანია, რომ ის მორალურად იყოს მიღებული ყველა მხარის მიერ, როგორც ამბობენ, "იყიდა". ისე, რომ, თუნდაც მხარეები არ აღფრთოვანებულიყვნენ მიღებული გადაწყვეტილებით, მაინც გულწრფელად დათანხმდნენ მის განხორციელებაზე. როგორც ამბობენ, რომ შეეძლოს უთანხმოება და ვალდებულება. წინააღმდეგ შემთხვევაში, კონფლიქტი უბრალოდ იცვლის თავის იერს, ადუღებული ცეცხლი დარჩება ტორფის ჭაობის ქვეშ და რაღაც მომენტში აუცილებლად აალდება.

მეორე პუნქტი, ნაწილობრივ პირველთან დაკავშირებული, არის ის, რომ თუ უკვე გადაწყვიტეთ მონაწილეობა მიიღოთ კონფლიქტის მოგვარებაში, მაქსიმალურად სერიოზულად მოეკიდეთ მას კომუნიკაციისა და კონტექსტის შესწავლის თვალსაზრისით. ესაუბრეთ თითოეულ მხარეს პირადად. ცალ-ცალკე, დამწყებთათვის. არ დაკმაყოფილდეთ ფოსტით. განაწილებული გუნდის შემთხვევაში მაინც ისაუბრეთ ვიდეო ბმულით. ნუ დაკმაყოფილდებით ცნობებითა და თვითმხილველების ცნობებით. გაიგეთ ამბავი, რა უნდა თითოეულ მხარეს, რატომ უნდათ, რას ელიან, ცდილობდნენ თუ არა ამ საკითხის გადაწყვეტას ადრე, რა მოხდება, თუ არ მოგვარდება, რა გადაწყვეტილებებს ხედავენ, როგორ წარმოუდგენიათ მათ პოზიციას. მეორე მხარე, რას ფიქრობენ, სწორად თუ არა და ა.შ. ჩატვირთეთ ყველა შესაძლო კონტექსტი თქვენს თავში, ღია გონებით, იმ პირობით, რომ ყველა მართალია. თქვენ არ ხართ კონფლიქტის შიგნით, თქვენ ხართ მის გარეთ, მეტაპოზიციაში. თუ კონტექსტი ხელმისაწვდომია მხოლოდ პოსტის თემაში, მაინც წაიკითხეთ იგი მთლიანად და მასთან დაკავშირებული თემები და დოკუმენტები. წაკითხვის შემდეგ მაინც ისაუბრეთ თქვენი ხმით. თქვენ თითქმის გარანტირებული გესმით რაიმე მნიშვნელოვანს, რომელიც ფოსტაში არ არის.

მესამე მნიშვნელოვანი წერტილი არის კომუნიკაციის ზოგადი მიდგომა. ეს ჩვეულებრივი რამ არის, არაფერი კოსმოსური, მაგრამ ძალიან მნიშვნელოვანია. ჩვენ არ ვცდილობთ დროის დაზოგვას, ჩვენ ვესაუბრებით ყველა მონაწილეს, არ ვაკრიტიკებთ ადამიანს, მაგრამ ვითვალისწინებთ მისი ქმედებების შედეგებს (არა „უხეში ხარ“, არამედ „შეიძლება ბიჭებს განაწყენონ ეს ნივთი“), ჩვენ ვაძლევთ საშუალებას, გადავარჩინოთ სახე, დისკუსიებს ვაწარმოებთ პირადად და არა ხაზის წინ.

კონფლიქტები, როგორც წესი, გამოწვეულია ორიდან ერთი მიზეზით. პირველი უკავშირდება იმას, არის თუ არა ადამიანი კონფლიქტის დროს ზრდასრულის პოზიციაზე თუ ბავშვის პოზიციაზე (დაწვრილებით ამის შესახებ ქვემოთ). ეს განპირობებულია მისი ემოციური სიმწიფით, ემოციების მართვის უნარით (რაც, სხვათა შორის, ყოველთვის არ არის დაკავშირებული მის ასაკთან). მეორე გავრცელებული მიზეზი არის სამუშაო პროცესის არასრულყოფილება, რომელიც ქმნის ნაცრისფერი ზონების სიტუაციებს, რომელშიც პასუხისმგებლობა ნაწილდება მონაწილეებს შორის, მხარეთა მოლოდინები არ არის გამჭვირვალე ერთმანეთის მიმართ და როლები ბუნდოვანია პროცესში.

შესაბამისად, კონფლიქტის მოგვარებისას (ისევე, როგორც ნებისმიერი სხვა საკითხის) მენეჯერს უნდა ჰქონდეს მხედველობაში სამი პერსპექტივა: მოკლევადიანი - საკითხის/კონფლიქტის აქ და ახლა გადაწყვეტა, საშუალოვადიანი - კიდევ ერთი კონფლიქტის წარმოშობის ალბათობის მინიმუმამდე შემცირება. ამავე მიზეზით და გრძელვადიანი - გუნდურ ადამიანში ზრდასრული კულტურის ჩამოყალიბება.

თითოეულ ჩვენგანს ჰყავს შინაგანი ბავშვი, დაახლოებით სამი ან ოთხი წლის. სამსახურში უმეტეს დროს სძინავს, მაგრამ ხანდახან იღვიძებს და კონტროლს იღებს. ბავშვს აქვს საკუთარი პრიორიტეტები. მისთვის მნიშვნელოვანია დაჟინებით მოითხოვოს, რომ ეს მისი ქვიშის ყუთია, დედას ის უფრო უყვარს, მისი მანქანა არის საუკეთესო (დიზაინი საუკეთესოა, ის საუკეთესოდ პროგრამირებს, ...). კონფლიქტურ სიტუაციაში ბავშვს შეუძლია დააჭიროს სათამაშოებს, დააჭიროს ფეხებს და გატეხოს სპატულა, მაგრამ მას არ შეუძლია მოზარდების საკითხების გადაჭრა (გადაწყვეტის არქიტექტურა, ავტომატური ტესტირების მიდგომები, გამოშვების თარიღები და ა.შ.), ის არ ფიქრობს სარგებელს. გუნდისთვის. კონფლიქტში მყოფი ბავშვის წახალისება, ნუგეშისცემა და დასაძინებლად გაგზავნა შესაძლებელია, თუ სთხოვთ მას დაურეკოს ზრდასრულს. კონფლიქტურ სიტუაციაში დისკუსიის დაწყებამდე დარწმუნდით, რომ ესაუბრებით ზრდასრულს და არა ბავშვს და თავად ხართ ზრდასრულის პოზიციაზე. თუ თქვენი პატიოსანი მიზანი ამ მომენტში სერიოზული საკითხის გადაჭრაა, თქვენ ზრდასრულის პოზიციაზე ხართ. თუ თქვენი მიზანია ფეხების დაჭერა და მხრის პირის გატეხვა, ეს ბავშვური პოზაა. გააგზავნეთ თქვენი შინაგანი ბავშვი საწოლში და დაურეკეთ ზრდასრულს, ან განაახლეთ დისკუსია. ადამიანი იღებს ემოციურ გადაწყვეტილებას, შემდეგ კი ეძებს მის რაციონალურ გამართლებას. ბავშვის მიერ ბავშვების პრიორიტეტებზე დაყრდნობით მიღებული გადაწყვეტილება არ იქნება ოპტიმალური.

კონფლიქტის დროს ქცევის გარდა, ბავშვის ან ზრდასრულის პოზიციას ასევე ახასიათებს პასუხისმგებლობის დონე, რომელიც ადამიანი მზად არის აიღოს საკუთარ თავზე. მისი ექსტრემალური გამოვლინებით პროგრამისტის ბავშვური პოზიცია, რომელსაც არაერთხელ შევხვედრივარ, ასე გამოიყურება: დავწერე კოდი, გავაგზავნე განსახილველად - ჩემი სამუშაო დასრულებულია. რეცენზენტებმა უნდა განიხილონ და დაამტკიცონ, QA-მ უნდა შეამოწმოს, თუ პრობლემებია, შემატყობინებენ. უცნაურია, მაგრამ საკმაოდ მოწიფული და გამოცდილი ადამიანებიც კი ზოგჯერ ასე იქცევიან. სკალის მეორე დასასრული არის ის, რომ ადამიანი თავს პასუხისმგებელად თვლის იმაში, რომ მისი კოდი მუშაობს, არის დაფარული ტესტებით, პირადად შემოწმდა მის მიერ, წარმატებით გაიარა განხილვა (საჭიროების შემთხვევაში არ არის პრობლემა რეცენზენტებთან პინგის, საკითხების განხილვისთვის. ხმით და ა.შ.) და აღკვეთილია, QA დახმარებას გაუწევს საჭიროების შემთხვევაში, იქნება აღწერილი ტესტის სცენარები და ა.შ. ჩვეულებრივ შემთხვევებში, პროგრამისტი ან იწყებს სკალის ზრდასრული ბოლოდან უფრო ახლოს, ან გადადის იქ გამოცდილების შეძენისას (იმ პირობით, რომ გუნდში სწორი კულტურაა დამუშავებული). უკიდურეს შემთხვევაში ის აგრძელებს მუშაობას, ჩვეულებრივ ბავშვურ პოზიციას იკავებს, შემდეგ მას და გუნდს პერიოდულად უჩნდება პრობლემები და კონფლიქტები.

გუნდში სწორი, მომწიფებული კულტურის ჩამოყალიბება მნიშვნელოვანი ამოცანაა ნებისმიერი მენეჯერისთვის. ამას დიდი დრო და ყოველდღიური ძალისხმევა სჭირდება, მაგრამ შედეგი ღირს. გუნდურ კულტურაზე გავლენის მოხდენის ორი გზა არსებობს - მაგალითის მიყვანა (რასაც აუცილებლად მიჰყვება; გუნდი ყოველთვის ლიდერს უყურებს) და სწორი ქცევის განხილვა და დაჯილდოება. აქაც არაფერია აბსტრაქტული ან ძალიან ფორმალური, უბრალოდ პრობლემების განხილვისას შენიშნეთ, რომ აქ შეიძლებოდა რაღაცის გაკეთება, ხაზგასმით აღნიშნეთ, რომ შენიშნეთ, როცა სწორად გადაწყდა, შექება, შენიშვნა გამოშვების განხილვისას და ა.შ.

განვიხილოთ რამდენიმე ტიპიური კონფლიქტური სიტუაცია, მარტივიდან რთულამდე:

კონფლიქტები, რომლებიც არ არის დაკავშირებული სამუშაო საკითხებთან

სამსახურში საკმაოდ ხშირად ხდება კონფლიქტები, რომლებიც არ არის დაკავშირებული სამუშაო საკითხებთან. მათი გაჩენა და გადაწყვეტის სიმარტივე, როგორც წესი, პირდაპირ კავშირშია მონაწილეთა ემოციური ინტელექტის დონესთან, მათ სიმწიფის დონესთან და არ უკავშირდება სამუშაო პროცესის სრულყოფილებას ან არასრულყოფილებას.

ტიპიური მაგალითები: ვიღაც საკმარისად ხშირად არ იყენებს სარეცხ მანქანას ან შხაპს, რაც სხვებს არ მოსწონთ, ვიღაც ჭუჭყიანდება, სხვებს კი ქარი ეცემა, თუ ფანჯარას ხსნის, ვიღაც ძალიან ხმაურიანია და სხვებს სამუშაოსთვის სიჩუმე სჭირდება და ასე შემდეგ. უმჯობესია, არ გადადოთ ამ ტიპის კონფლიქტების გადაწყვეტა და არ მივცეთ მათ თავიანთი გზა. ისინი თავისით არ გადაჭრიან და ყოველდღიურად მოგაშორებენ სამუშაოს და წამლავენ ატმოსფეროს გუნდში. საბედნიეროდ, მათი გადაჭრა, როგორც წესი, არ არის დიდი პრობლემა - უბრალოდ ისაუბრეთ მშვიდად (რა თქმა უნდა) კოლეგასთან, რომელიც უგულებელყოფს ჰიგიენას, უზრუნველყოთ კომფორტული ადგილები მათთვის, ვინც უპირატესობას ანიჭებს სიჩუმეს/სიგრილეს, იყიდეთ ხმის შთამნთქმელი ყურსასმენები ან დააინსტალირეთ ტიხრები. და ა.შ.

კიდევ ერთი მაგალითი, რომელსაც რამდენჯერმე შევხვდი ჩემი მუშაობის დროს, არის გუნდის წევრების ფსიქოლოგიური შეუთავსებლობა. რატომღაც ადამიანებს უბრალოდ არ შეუძლიათ ერთად მუშაობა; ყოველი ურთიერთქმედება მთავრდება სკანდალით. ზოგჯერ ეს გამოწვეულია იმით, რომ ადამიანებს აქვთ პოლარული შეხედულებები ზოგიერთ აქტუალურ საკითხზე (ჩვეულებრივ, პოლიტიკურზე) და არ იციან როგორ დატოვონ ისინი სამუშაოს მიღმა. მათი დარწმუნება, რომ მოითმინონ ერთმანეთი ან შეცვალონ ქცევა, საკმაოდ ფუჭი ამოცანაა. ერთადერთი გამონაკლისი, რაც მე შემხვედრია, არიან ღია აღქმის მქონე ახალგაზრდა კოლეგები, მათი ქცევა მაინც შეიძლება თანდათან შეიცვალოს პერიოდული საუბრების საშუალებით. როგორც წესი, საკითხი წარმატებით წყდება მათი სხვადასხვა გუნდებად დაყოფით, ან თუნდაც ძალიან იშვიათად სამუშაოზე გადახურვის შესაძლებლობის მიცემით.

ყველა ზემოთ ჩამოთვლილ სიტუაციაში, ღირს ყველა მონაწილესთან პირადად საუბარი, სიტუაციის განხილვა, კითხვა, ხედავენ თუ არა პრობლემას ამ შემთხვევაში, იკითხონ, რა არის მათი აზრით გადაწყვეტილებები და უზრუნველყოს მათი მონაწილეობა ამ საქმეში. გადაწყვეტილება.

სამუშაო პროცესის ოპტიმიზაციის თვალსაზრისით (შუავადიანი პერსპექტივა, რომელიც აღვნიშნე), აქ ბევრი რამის გაკეთება არ შეიძლება, ოპტიმიზაციის ერთადერთი საკითხია გუნდის ფორმირებისას თავსებადობის ფაქტორის გათვალისწინება და არა ხალხის დაყენება. წინასწარ ერთად ვინ იქნება კონფლიქტი.

გუნდური კულტურის თვალსაზრისით, ასეთი სიტუაციები გაცილებით იშვიათად წარმოიქმნება მომწიფებული კულტურის მქონე გუნდებში, სადაც ადამიანები პატივს სცემენ გუნდს და კოლეგებს და იციან როგორ მოაგვარონ საკითხები დამოუკიდებლად. გარდა ამისა, ასეთი კონფლიქტები ბევრად უფრო მარტივად (ხშირად ავტომატურად) წყდება გუნდებში, სადაც ნდობის მაღალი დონეა, ადამიანები დიდი ხნის განმავლობაში მუშაობდნენ ერთად და/ან ხშირად ურთიერთობენ სამუშაოს გარეთ.

სამუშაო საკითხებთან დაკავშირებული კონფლიქტები:

ასეთი კონფლიქტები, როგორც წესი, გამოწვეულია ორივე მიზეზით ერთდროულად, როგორც ემოციური (ის ფაქტი, რომ ერთ-ერთი მონაწილე არ არის ზრდასრულის პოზიციაზე) და თავად სამუშაო პროცესის არასრულყოფილება. შესაძლოა, კონფლიქტების ყველაზე გავრცელებული ტიპი, რომელიც მე შემხვედრია, არის კონფლიქტები კოდის მიმოხილვისას ან დეველოპერებს შორის არქიტექტურის დისკუსიების დროს.

აქ ორ ტიპურ შემთხვევას გამოვყოფ:

1) პირველ შემთხვევაში, დეველოპერს არ შეუძლია კოლეგისგან კოდის მიმოხილვა. პატჩი იგზავნება განსახილველად და არაფერი ხდება. ერთი შეხედვით, ორ მხარეს შორის აშკარა კონფლიქტი არ არის, მაგრამ თუ დაფიქრდებით, ეს საკმაოდ კონფლიქტია. სამუშაო საკითხი არ არის მოგვარებული, ერთ-ერთი მხარე (მიმოხილვას ელოდება) აშკარა დისკომფორტს განიცდის. ამ შემთხვევის უკიდურესი ქვეტიპი არის განვითარება საზოგადოებაში ან სხვადასხვა გუნდში, ხოლო მიმომხილველი შეიძლება არ იყოს დაინტერესებული ამ კონკრეტული კოდით, დატვირთვის ან სხვა გარემოებების გამო, შეიძლება საერთოდ არ მიაქციოს ყურადღება განხილვის მოთხოვნას და გარე არბიტრი (ორივე მხარისთვის საერთო მენეჯერი) ) შეიძლება საერთოდ არ არსებობდეს.

გადაწყვეტის მიდგომა, რომელიც ეხმარება ასეთ სიტუაციაში, ეხება ზუსტად გრძელვადიან პერსპექტივას, ზრდასრული ადამიანის კულტურას. პირველი, ჭკვიანი აქტივობა მუშაობს. არ უნდა ელოდოთ, რომ მიმოხილვაზე დაკიდებული კოდი თავად მიიპყრობს მიმომხილველის ყურადღებას. ჩვენ უნდა დავეხმაროთ მიმომხილველებს მისი შემჩნევაში. პინგანი რამდენიმე ადამიანი, დასვით შეკითხვა სინკაპზე, მონაწილეობა მიიღება დისკუსიებში. ცხადია, იმპორტი უფრო მეტად ზიანს აყენებს, ვიდრე დახმარებას, საჭიროა საღი აზრის გამოყენება. მეორეც, წინასწარი მომზადება კარგად მუშაობს. თუ გუნდს ესმის, რა ხდება და რატომ, რატომ არის საერთოდ საჭირო ეს კოდი, დიზაინი წინასწარ იყო განხილული და შეთანხმებული ყველასთან, ხალხი უფრო მეტად მიაქცევს ყურადღებას ასეთ კოდს და მიიღებს მას სამუშაოდ. მესამე, ავტორიტეტი მუშაობს. თუ გსურთ განხილვა, თავად გააკეთეთ ბევრი მიმოხილვა. გააკეთეთ მაღალი ხარისხის მიმოხილვები, რეალური შემოწმებებით, რეალური ტესტებით და სასარგებლო კომენტარებით. თუ თქვენი მეტსახელი კარგად არის ცნობილი გუნდში, უფრო დიდია შანსი, რომ თქვენი კოდი შეამჩნიოს.

სამუშაო პროცესის თვალსაზრისით, აქ შესაძლო გაუმჯობესება არის სწორი პრიორიტეტიზაცია, რომელიც მიზნად ისახავს დეველოპერს დაეხმაროს თავისი და გუნდის მიზნების მიღწევაში (სხვების გადახედვა, წერილების დაწერა საზოგადოებაში, თან ახლეთ კოდი არქიტექტურის აღწერილობით, დოკუმენტაციასთან, ტესტებთან, მონაწილეობა დისკუსიებში. საზოგადოება და ა.შ.), თავიდან აიცილოთ პატჩები რიგში დიდხანს დაკიდებას და ა.შ.

2) კოდის ან დიზაინის მიმოხილვის დროს კონფლიქტების მეორე გავრცელებული შემთხვევა არის განსხვავებული შეხედულებები ტექნიკურ საკითხებზე, კოდირების სტილზე და ინსტრუმენტების არჩევანზე. ამ შემთხვევაში დიდი მნიშვნელობა აქვს მონაწილეებს შორის ნდობის დონეს, ერთ გუნდს შორის და ერთად მუშაობის გამოცდილებას. ჩიხი დგება მაშინ, როდესაც ერთ-ერთი მონაწილე ბავშვურ პოზიციას იკავებს და არ ცდილობს გაიგოს ის, რისი გადმოცემაც სურს თანამოსაუბრეს. ხშირად, მეორე მხარის მიერ შემოთავაზებული მიდგომაც და თავდაპირველად შემოთავაზებულმა მიდგომამ შეიძლება წარმატებით იმუშაოს და პრინციპში არ აქვს მნიშვნელობა რომელი აირჩიოს.

ერთ დღეს, პროგრამისტმა ჩემი გუნდიდან (მოდით დავარქვათ მას ფაშა) მოამზადა პატჩი ცვლილებებით პაკეტის განლაგების სისტემაში, რომელიც შეიმუშავეს და მხარი დაუჭირეს მეზობელი განყოფილების კოლეგებს. ერთ-ერთ მათგანს (იგორს) ჰქონდა საკუთარი მტკიცე მოსაზრება იმის შესახებ, თუ როგორ უნდა იყოს კონფიგურირებული Linux სერვისები პაკეტების განლაგებისას. ეს მოსაზრება განსხვავდებოდა პატჩში შემოთავაზებული მიდგომისგან და ისინი ვერ შეთანხმდნენ. ჩვეულებისამებრ, ვადები იწურებოდა და საჭირო იყო რაიმე გადაწყვეტილების მიღება, აუცილებელი იყო ერთ-ერთი მათგანი სრულწლოვან თანამდებობაზე დაეკავებინა. ფაშამ აღიარა, რომ ორივე მიდგომას აქვს სიცოცხლის უფლება, მაგრამ მას სურდა, რომ მისი ვარიანტი გასულიყო, რადგან არც ერთ და არც მეორე ვარიანტს არ ჰქონდა რაიმე აშკარა ტექნიკური უპირატესობა.

ჩვენი დისკუსია ასე გამოიყურებოდა (ძალიან სქემატურად, რა თქმა უნდა, საუბარი გაგრძელდა ნახევარი საათის განმავლობაში):

- ფაშა, რამდენიმე დღეში ფუნქციის გაყინვა გვაქვს. მნიშვნელოვანია, რომ ყველაფერი გავაერთიანოთ და რაც შეიძლება მალე დავიწყოთ ტესტირება. როგორ გავიაროთ იგორი?
— მას სხვაგვარად სურს სერვისების დაყენება, იქ კომენტარები ჩამიკრა...
- და რა არის, დიდი ცვლილებები, ბევრი აურზაური?
- არა, ორიოდე საათია სამუშაო, მაგრამ საბოლოო ჯამში სხვაობა არაა, ორივენაირად იმუშავებს, რატომ არის ეს საჭირო? მე გავაკეთე რაღაც, რაც მუშაობს, მოდი მივიღოთ.
- მისმინე, რამდენი ხანია ამ ყველაფერზე მსჯელობ?
- დიახ, ჩვენ უკვე კვირანახევარია აღვნიშნავთ დროს.
- ჰმ... შეიძლება რამდენიმე საათში მოვაგვაროთ უკვე კვირანახევარი გასული საკითხი და არ გავაკეთოთ?
- კარგი, კი, მაგრამ არ მინდა იგორმა იფიქროს, რომ დავნებდი...
- მისმინე, რა არის შენთვის უფრო მნიშვნელოვანი, გათავისუფლება, შენს გადაწყვეტილებასთან ერთად, თუ იგორის მოკვლა? ჩვენ შეგვიძლია მისი დაბლოკვა, თუმცა, კარგი შანსია, რომ გაფრინდეს გამოშვებით.
- კარგი... რა თქმა უნდა, მაგარი იქნებოდა იგორის ცხვირის მოწმენდა, მაგრამ კარგი, გათავისუფლება უფრო მნიშვნელოვანია, გეთანხმები.
- მართლა ასე მნიშვნელოვანია შენთვის რას ფიქრობს იგორი? გულახდილად რომ ვთქვა, ის სულაც არ სწყალობს, უბრალოდ, ერთიანი მიდგომა სურს იმ საქმის სხვადასხვა ადგილას, რაზეც პასუხისმგებელია.
- კარგი, კარგი, მოდი ისე მოვიქცე, როგორც კომენტარებში მთხოვს და დავიწყებთ ტესტირებას.
- გმადლობთ, ფაშა! დარწმუნებული ვიყავი, რომ თქვენგანი უფრო მოწიფული იქნებოდით, თუმცა იგორეკი შენზე უფროსია :)

საკითხი მოგვარდა, გათავისუფლება დროულად გაათავისუფლეს, ფაშამ დიდი უკმაყოფილება არ იგრძნო, რადგან მან თავად შესთავაზა გამოსავალი და განახორციელა. იგორი ზოგადად კმაყოფილი იყო, რადგან... მისი აზრი გაითვალისწინეს და ისე მოიქცნენ, როგორც მან შესთავაზა.

არსებითად იგივე კონფლიქტის კიდევ ერთი ტიპია არჩევანი ტექნიკურ გადაწყვეტილებებს/ბიბლიოთეკებს/მიდგომებს შორის პროექტში, განსაკუთრებით განაწილებულ გუნდში. ერთ-ერთ პროექტში, რომელიც C/C++-ის გამოყენებით იყო პოზიციონირებული, აღმოჩნდა, რომ პროექტის ტექნიკური მენეჯმენტი კატეგორიულად ეწინააღმდეგებოდა STL-ს (სტანდარტული თარგების ბიბლიოთეკის) გამოყენებას. ეს არის სტანდარტული ენის ბიბლიოთეკა, რომელიც ამარტივებს განვითარებას და ჩვენი გუნდი ძალიან მიჩვეულია მას. აღმოჩნდა, რომ პროექტი ბევრად უფრო ახლოს არის C-სთან, ვიდრე C++-თან, რაც გუნდს დიდად არ შთააგონებდა, რადგან ხელმძღვანელობამ ყველაფერი სცადა და მართლაც მაგარი პლუს მოთამაშეები აიყვანა. ამავდროულად, გუნდის ამერიკული ნაწილი, ინჟინრებიც და მენეჯერებიც, დიდი ხნის განმავლობაში მუშაობდნენ კომპანიაში, მიჩვეული იყვნენ არსებულ მდგომარეობას და კმაყოფილი იყვნენ ყველაფრით. ნაკრების რუსული ნაწილი ცოტა ხნის წინ, რამდენიმე კვირაში (მათ შორის მეც) შეიკრიბა. გუნდის რუსულ ნაწილს კატეგორიულად არ სურდა დაეტოვებინა განვითარების ჩვეული მიდგომა.

გაუთავებელი წერილობითი დისკუსიები დაიწყო ორ კონტინენტს შორის, წერილები სამ-ოთხ ეკრანზე მიფრინავდნენ წინ და უკან, ჯგუფურ და პერსონალურ წერილებში, პროგრამისტებიდან პროგრამისტებამდე და მენეჯერებამდე. როგორც ჩვეულებრივ ხდება, ამ სიგრძის წერილებს არავინ კითხულობდა ავტორებისა და მათი მგზნებარე მხარდამჭერების გარდა. დაძაბულობისგან ჭექა-ქუხილი ჩეთები, მრავალეკრანიანი აზრების გადატანა სხვადასხვა მიმართულებით STL-ის ტექნიკურ უპირატესობებთან დაკავშირებით, რამდენად კარგად არის გამოცდილი, რამდენად უსაფრთხოა და ზოგადად, რამდენად მშვენიერია მასთან ცხოვრება და რამდენად საშინელია მის გარეშე. .

ეს ყველაფერი საკმაოდ დიდხანს გაგრძელდა, სანამ საბოლოოდ მივხვდი, რომ საკითხის ტექნიკურ ასპექტებზე ვსაუბრობდით, მაგრამ პრობლემა რეალურად ტექნიკური არ იყო. პრობლემა არ არის STL-ის დადებითი და უარყოფითი მხარეები ან მის გარეშე მუშაობის სირთულე. პრობლემა საკმაოდ ორგანიზაციულია. ჩვენ უბრალოდ უნდა გვესმოდეს, როგორ მუშაობდა კომპანია, რომელშიც ვმუშაობდით. აქამდე არცერთ ჩვენგანს არ გვქონია მსგავს კომპანიაში მუშაობის გამოცდილება. საქმე ის იყო, რომ კოდის შემუშავებისა და წარმოებაში გაშვების შემდეგ, მხარდაჭერას სხვა გუნდებიდან, სხვა ქვეყნებიდან სრულიად განსხვავებული ადამიანები ამუშავებდნენ. ამ უზარმაზარ საინჟინრო გუნდს რამდენიმე ათეული ათასი ინჟინერი (სულ) შეეძლო მხოლოდ ტექნიკური საშუალებების სრულიად ელემენტარული მინიმუმის, ასე ვთქვათ, მინიმალური მინიმორის გადახდა. ყველაფერი, რაც კომპანიაში დადგენილ საინჟინრო სტანდარტს სცილდება, მომავალში ვერ იქნება მხარდაჭერილი. გუნდის დონე განისაზღვრება მისი ყველაზე სუსტი წევრების დონით. მას შემდეგ რაც გავიგეთ რეალური მოტივაცია გუნდის ამერიკული ნაწილის ქმედებებით, ეს საკითხი ამოღებულ იქნა დღის წესრიგიდან და ჩვენ ერთად წარმატებით შევიმუშავეთ და გამოვაქვეყნეთ პროდუქტი კომპანიის მიერ მიღებული სტანდარტების გამოყენებით. წერილები და ჩეთები ამ შემთხვევაში კარგად არ მუშაობდა; საერთო მნიშვნელამდე მისვლას რამდენიმე მოგზაურობა და ბევრი პირადი კომუნიკაცია დასჭირდა.

სამუშაო პროცესის თვალსაზრისით, ამ კონკრეტულ შემთხვევაში, დაგვეხმარება გამოყენებული ინსტრუმენტების აღწერა, მათთვის მოთხოვნები, ახლის დამატებაზე შეზღუდვები და ასეთი შეზღუდვების დასაბუთება. ასეთი დოკუმენტები უხეშად შეესაბამება იმ დოკუმენტებს, რომლებიც აღწერილია აბზაცებში ხელახალი გამოყენების სტრატეგია და განვითარების გარემო, რომელიც შემუშავებულია პროგრამული უზრუნველყოფის განვითარების მენეჯერის სახელმძღვანელოში. NASA. მიუხედავად ასაკისა, იგი შესანიშნავად აღწერს ამ ტიპის პროგრამული უზრუნველყოფის განვითარების ყველა ძირითად საქმიანობას და დაგეგმვის ეტაპს. მსგავსი დოკუმენტების ქონა ძალიან აადვილებს განხილვას, თუ რა კომპონენტები და მიდგომები შეიძლება გამოყენებულ იქნას პროდუქტში და რატომ.

კულტურული თვალსაზრისით, ცხადია, უფრო მოწიფული პოზიციით, რომელშიც მხარეები ცდილობენ მოისმინონ და გაიგონ თავიანთი კოლეგების ქმედებების რეალური მოტივაცია და იმოქმედონ პროექტისა და გუნდის პრიორიტეტებზე და არა პიროვნულ ეგოზე დაყრდნობით. კონფლიქტი უფრო მარტივად და სწრაფად მოგვარდებოდა.

ტექნიკური გადაწყვეტის არჩევის სხვა კონფლიქტში, ასევე შესამჩნევი დრო დამჭირდა ერთ-ერთი მხარის მოტივაციის გასაგებად (ეს ძალიან უჩვეულო შემთხვევა იყო), მაგრამ მას შემდეგ რაც მოტივაცია ნათელი გახდა, გამოსავალი აშკარა იყო.

სიტუაცია ასეთია: ახალი დეველოპერი ჩნდება დაახლოებით 20 კაციან გუნდში, მოდით დავარქვათ მას სტასი. იმ დროს, ჩვენი სტანდარტული ინსტრუმენტი გუნდური კომუნიკაციისთვის იყო Skype. როგორც მოგვიანებით გაირკვა, სტასი იყო ღია სტანდარტებისა და ღია კოდის პროგრამული უზრუნველყოფის დიდი გულშემატკივარი და იყენებდა მხოლოდ ინსტრუმენტებსა და ოპერაციულ სისტემებს, რომელთა წყაროები იყო საჯაროდ და რომლებიც იყენებდნენ საჯაროდ აღწერილ პროტოკოლებს. Skype არ არის ერთ-ერთი ასეთი ინსტრუმენტი. ჩვენ დიდი დრო გავატარეთ ამ მიდგომის უპირატესობებისა და უარყოფითი მხარეების განხილვაზე, სკაიპის ანალოგების გაშვების მცდელობებზე სხვადასხვა ოპერაციულ სისტემაზე, სტასის მცდელობებზე დაერწმუნებინა გუნდი სხვა სტანდარტებზე გადასულიყო, პირადად მივწეროთ მას ფოსტით, პირადად დაურეკოთ მას ტელეფონი, იყიდე მისთვის მეორე კომპიუტერი სპეციალურად სკაიპისთვის და ა.შ. ბოლოს მივხვდი, რომ ეს პრობლემა, არსებითად, არ არის ტექნიკური ან ორგანიზაციული, არამედ იდეოლოგიური, თუნდაც, შეიძლება ითქვას, რელიგიური (სტასისთვის). მაშინაც კი, თუ ჩვენ საბოლოოდ დავაკავშირებთ Stas-სა და Skype-ს (რასაც რამდენიმე თვე დასჭირდა), პრობლემა კვლავ წარმოიქმნება ნებისმიერ მომდევნო ინსტრუმენტზე. მე არ მქონდა რეალური საშუალება სტასის მსოფლმხედველობის შესაცვლელად და არ იყო მიზეზი, შემეცვალა გუნდის მსოფლმხედველობა, რომელიც იდეალურად მუშაობდა ამ გარემოში. ადამიანი და კომპანია უბრალოდ ორთოგონალური იყო თავიანთი მსოფლმხედველობით. ასეთ სიტუაციებში კარგი გამოსავალი არის ორგანიზაციული. სტასი სხვა გუნდში გადავიყვანეთ, სადაც ის უფრო ორგანული იყო.

ამ კონფლიქტის მიზეზი, ჩემი აზრით, არის შეუსაბამობა კონკრეტული ადამიანის პიროვნულ კულტურას (რომელსაც აქვს ძლიერი აზრი, რომელიც მას კომპრომისზე არ აძლევს) და კომპანიის კულტურას შორის. ამ შემთხვევაში, რა თქმა უნდა, მენეჯერის შეცდომაა. თავდაპირველად არასწორი იყო მისი ამ ტიპის პროექტზე წაყვანა. საბოლოოდ სტასი გადავიდა ღია კოდის პროგრამული უზრუნველყოფის განვითარების პროექტში და იქ გამოირჩეოდა.

როგორც დეველოპერის ბავშვური დამოკიდებულებით, ასევე სამუშაო პროცესის ნაკლოვანებებით გამოწვეული კონფლიქტის კარგი მაგალითია სიტუაცია, რომელშიც, შესრულებულის განმარტების არარსებობის შემთხვევაში, დეველოპერს და QA გუნდს განსხვავებული მოლოდინი აქვთ მზაობასთან დაკავშირებით. ფუნქცია გადაცემულია QA-ზე. დეველოპერს სჯეროდა, რომ საკმარისი იყო კოდის დაწერა და ფუნქციის გადაგდება ღობეზე QA-ზე - ისინი დაალაგებდნენ მას იქ. სხვათა შორის, საკმაოდ მომწიფებული და გამოცდილი პროგრამისტი, მაგრამ ეს იყო მისი ხარისხის შიდა ბარიერი. QA არ დაეთანხმა ამას და მოითხოვა ეჩვენებინა და აღეწერათ ის, რაც მან თავად შეამოწმა და მოითხოვა მათთვის ტესტირების სკრიპტი. წარსულში მათ ჰქონდათ პრობლემები ამ დეველოპერის ფუნქციონალურობასთან დაკავშირებით და არ სურდათ დროის დაკარგვა. სხვათა შორის, ისინი მართლები იყვნენ - ფუნქცია ნამდვილად არ მუშაობდა, მან არ შეამოწმა კოდი QA-ში გაგზავნამდე.

სიტუაციის მოსაგვარებლად, მე ვთხოვე, მეჩვენებინა, რომ ყველაფერი ნამდვილად მუშაობდა (ეს არ მუშაობდა და მას უნდა გამოესწორებინა), ჩვენ ვესაუბრეთ გუნდს და შესრულებულის ხარისხის განსაზღვრას (მათ ეს ვერ შეძლეს წერა, რადგან არ გვინდოდა პროცესის ძალიან ბიუროკრატიული გამხდარიყო), ისე, მალევე დავშორდით ამ სპეციალისტს (ზოგად შვებას).

სამუშაო პროცესის თვალსაზრისით, ამ შემთხვევაში შესაძლო გაუმჯობესებაა შესრულებულის განმარტების არსებობა, მოთხოვნები თითოეული ერთეულის მახასიათებლისა და ინტეგრაციის ტესტების მხარდაჭერისთვის და დეველოპერის მიერ განხორციელებული ტესტირების აღწერა. ერთ-ერთ პროექტში ჩვენ გავზომეთ კოდის დაფარვის დონე ტესტებით CI-ის დროს და თუ დაფარვის დონე დაეცემა პატჩის დამატების შემდეგ, ტესტები მოინიშნა წარუმატებლად, ე.ი. ნებისმიერი ახალი კოდი შეიძლება დაემატოს მხოლოდ იმ შემთხვევაში, თუ მას ახალი ტესტები ექნება.

კონფლიქტის კიდევ ერთი ტიპიური მაგალითი, რომელიც მჭიდროდ არის დაკავშირებული სამუშაო პროცესის ორგანიზებასთან. ჩვენ გვყავს პროდუქტი, პროდუქტის განვითარების გუნდი, დამხმარე გუნდი და მომხმარებელი. მომხმარებელს აქვს პროდუქტთან დაკავშირებული პრობლემები და დაუკავშირდა მხარდაჭერას. მხარდაჭერა აანალიზებს პრობლემას და ესმის, რომ პრობლემა პროდუქტშია და პრობლემას გადასცემს პროდუქტის გუნდს. პროდუქტის გუნდი დატვირთული დროშია, გამოშვება ახლოვდება, ასე რომ, ბილეთი, რომელსაც აქვს პრობლემა მომხმარებლისგან, დაკარგული დეველოპერის სხვა ბილეთებს შორის, რომელსაც ის ენიჭება, რამდენიმე კვირის განმავლობაში დგას ყურადღების გარეშე. მხარდაჭერა ფიქრობს, რომ დეველოპერი მუშაობს მომხმარებლის პრობლემაზე. მომხმარებელი ელოდება და იმედოვნებს, რომ მათი პრობლემა დამუშავდება. რეალურად ჯერ არაფერი ხდება. რამდენიმე კვირის შემდეგ, მომხმარებელი საბოლოოდ გადაწყვეტს დაინტერესდეს პროგრესით და სთხოვს მხარდაჭერას, თუ როგორ მიდის საქმეები. მხარდაჭერა ითხოვს განვითარებას. დეველოპერი კანკალებს, ათვალიერებს ბილეთების სიას და პოულობს ბილეთს კლიენტისგან. მომხმარებლისგან ბილეთის წაკითხვისას, ის ხვდება, რომ არ არის საკმარისი ინფორმაცია პრობლემის გადასაჭრელად და მას სჭირდება მეტი მორები და ნაგავსაყრელები. მხარდაჭერა ითხოვს დამატებით ინფორმაციას მომხმარებლისგან. შემდეგ კი მომხმარებელი ხვდება, რომ მთელი ამ ხნის განმავლობაში მის პრობლემაზე არავინ მუშაობდა. და ჭექა-ქუხილი დატყდება...

ამ სიტუაციაში, თავად კონფლიქტის გადაწყვეტა საკმაოდ აშკარა და წრფივია (შეასწორეთ პროდუქტი, განაახლეთ დოკუმენტაცია და ტესტები, დაამშვიდეთ მომხმარებელი, გაათავისუფლეთ Hotfix და ა.შ.). მნიშვნელოვანია სამუშაო პროცესის გაანალიზება და იმის გაგება, თუ ვინ არის პასუხისმგებელი ორ გუნდს შორის ურთიერთქმედების ორგანიზებაზე და რატომ გახდა ეს სიტუაცია თავიდანვე შესაძლებელი. გასაგებია, რა უნდა გამოსწორდეს ამ პროცესში - ვინმემ უნდა აკონტროლოს საერთო სურათი მომხმარებლების შეხსენებების გარეშე, პროაქტიულად. ბილეთები მომხმარებლისგან უნდა გამოირჩეოდეს დეველოპერების სხვა ბილეთებს შორის. მხარდაჭერამ უნდა დაინახოს, მუშაობს თუ არა დეველოპერების ჯგუფი მის ბილეთებზე და თუ არა, როდის შეიძლება დაიწყოს მუშაობა და როდის შეიძლება იყოს მოსალოდნელი შედეგები. მხარდაჭერა და განვითარება პერიოდულად უნდა დაუკავშირდეს და განიხილოს ბილეთების სტატუსი, გამართვისთვის საჭირო ინფორმაციის შეგროვება მაქსიმალურად უნდა იყოს ავტომატიზირებული და ა.შ.

ისევე, როგორც ომში მტერი ცდილობს დაარტყას კვანძს ორ ერთეულს შორის, ასევე სამუშაოში ყველაზე დელიკატური და დაუცველი წერტილი ჩვეულებრივ გუნდებს შორის ურთიერთქმედებაა. თუ მხარდაჭერისა და განვითარების მენეჯერები საკმარისად ასაკოვანნი არიან, ისინი თავად შეძლებენ პროცესის გამოსწორებას, წინააღმდეგ შემთხვევაში, პროცესი გაგრძელდება კონფლიქტებისა და პრობლემების წარმოქმნამდე, სანამ მენეჯერი არ ჩაერევა, რომელიც შეძლებს სიტუაციის გამოსწორებას.

კიდევ ერთი ტიპიური მაგალითი, რომელიც არაერთხელ მინახავს სხვადასხვა კომპანიაში, არის სიტუაცია, როდესაც პროდუქტი იწერება ერთი გუნდის მიერ, მასზე ავტომატური ინტეგრაციის ტესტები იწერება მეორე გუნდის მიერ, ხოლო ინფრასტრუქტურას, რომელზედაც ეს ყველაფერი მუშაობს, თან ახლავს მესამე. გუნდი. ტესტების გაშვებისას პრობლემები მუდმივად ჩნდება და მათში პრობლემების მიზეზი შეიძლება იყოს როგორც პროდუქტი, ასევე ტესტები და ინფრასტრუქტურა. როგორც წესი, პრობლემურია შეთანხმება იმაზე, თუ ვინ უნდა შეასრულოს პრობლემების პირველადი ანალიზი, ფაილების შეცდომები, პროდუქტის ჟურნალის ანალიზი, ტესტები და ინფრასტრუქტურა და ა.შ. აქ კონფლიქტები ხშირია და, ამავდროულად, ერთგვაროვანი. მაღალი ემოციური ინტენსივობის შემთხვევაში, მონაწილეები ხშირად ხვდებიან ბავშვურ პოზიციაში და სერიალში იწყება დისკუსიები: „რატომ უნდა ვიყო ამით“, „უფრო ხშირად იშლება“ და ა.შ.

სამუშაო პროცესის თვალსაზრისით, პრობლემის გადასაჭრელად კონკრეტული ნაბიჯები დამოკიდებულია გუნდების შემადგენლობაზე, ტესტების ტიპზე და პროდუქტზე და ა.შ. ერთ-ერთ პროექტში ჩვენ შემოვიღეთ პერიოდული მოვალეობა, რომლის დროსაც გუნდები კვირიდან კვირაში აკვირდებოდნენ ტესტებს. მეორეში, პირველადი ანალიზი ყოველთვის კეთდებოდა ტესტის შემქმნელების მიერ, მაგრამ ანალიზი იყო ძალიან საბაზისო და პროდუქტი საკმაოდ სტაბილური, ამიტომ კარგად მუშაობდა. მთავარია უზრუნველყოს, რომ პროცესი იყოს გამჭვირვალე, რომ მოლოდინები იყოს ნათელი ყველა მხარისთვის და რომ სიტუაცია ყველასთვის სამართლიანი იყოს.

არის თუ არა კონფლიქტი ორგანიზაციაში პრობლემა? არის თუ არა ცუდი ნიშანი იმისა, რომ თქვენს გუნდში ხშირად (ან უბრალოდ პერიოდულად) ხდება კონფლიქტები? ზოგადად, არა, რადგან თუ არის ზრდა, განვითარება, არის რაღაც დინამიკა, მაშინ ჩნდება საკითხები, რომლებიც აქამდე არასოდეს მოგვარებულა და მათი მოგვარებისას შეიძლება წარმოიშვას კონფლიქტები. ეს იმის მაჩვენებელია, რომ ზოგიერთ სფეროს სჭირდება ყურადღება, რომ არის გაუმჯობესების სფეროები. ცუდია, თუ კონფლიქტები ძალიან ხშირად წარმოიქმნება, ძნელი მოსაგვარებელია ან დიდი დრო სჭირდება. ეს, სავარაუდოდ, არასაკმარისად გამარტივებული სამუშაო პროცესების და გუნდის არასაკმარისი სიმწიფის ნიშანია.

წყარო: www.habr.com