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

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

ჭრილის ქვემოთ მოცემულია ჩვენი გუნდის ლიდერის, ასევე RAS-ის პროდუქტების განვითარების დირექტორის იგორ მარნატის სტატიის მეორე ნაწილი, პროგრამისტების მოტივაციის თავისებურებების შესახებ. სტატიის პირველი ნაწილი შეგიძლიათ იხილოთ აქ - habr.com/ru/company/parallels/blog/452598

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

III - კუთვნილების და სიყვარულის მოთხოვნილება

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

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

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

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

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

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

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

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

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

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

IV. აღიარების საჭიროება

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

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

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

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

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

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

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

V. შემეცნებისა და თვითაქტუალიზაციის მოთხოვნილება.

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

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

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

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

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

მასლოუს პირამიდის მიღმა: შედეგების ხილვადობა, გემიფიკაცია და კონკურენცია, სისულელეების გარეშე

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

პირველი არის შედეგის ხილვადობა და სიახლოვე.

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

ეს მოტივაცია გარკვეულწილად ჰგავს იმას, რასაც მოთამაშეები განიცდიან კომპიუტერული თამაშების დასრულებისას: ისინი პერიოდულად იღებენ მედლებს, ქულებს, ბონუსებს თითოეული დონის დასრულებისას; ამას შეიძლება ეწოდოს "დოპამინის მოტივაცია".

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

მეორე წერტილი არის გეიფიკაცია და კონკურენცია.

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

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

და ბოლოს, მესამე პუნქტი - არა სისულელე.

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

წყარო: www.habr.com