პროგრამისტების გუნდის მართვა: როგორ და როგორ მოვახდინოთ მათი სათანადო მოტივაცია? ნაწილი პირველი

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

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

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

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

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

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

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

I: ფიზიოლოგიური, ბიოლოგიური საჭიროებები:

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

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

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

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

II. უსაფრთხოების, კომფორტის, საცხოვრებელი პირობების თანმიმდევრულობის საჭიროება:

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

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

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

კომფორტის ფიზიკური კომპონენტი ყველაზე ძირითადი და მარტივია, ახლა დანარჩენზე ვისაუბროთ.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

გაგრძელება იქნება ...

წყარო: www.habr.com