ტიმ ლისტერი - წიგნების თანაავტორი

• „ადამიანური ფაქტორი. წარმატებული პროექტები და გუნდები" (ორიგინალური წიგნი ჰქვია "Peopleware")
• "ვალსი დათვებთან ერთად: რისკის მართვა პროგრამულ პროექტებში"
• „ადრენალინით გაჟღენთილი და შაბლონებით ზომბირებული. პროექტის გუნდების ქცევის ნიმუშები"

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

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

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

მაიკლ: შეგიძლიათ ორიოდე სიტყვით თქვათ იმაზე, რასაც ახლა აკეთებთ?

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

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

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

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

მაიკლ: ანუ იწყებთ პროექტებს, ახორციელებთ რაიმე სახის დარტყმას და ამოწმებთ, რომ რელსები სწორი მიმართულებით მიდის?

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

19 წელი მოქნილი

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

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

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

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

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

ოლეგი: თქვენ ახსენეთ Agile Manifesto. საჭიროა თუ არა მისი როგორმე განახლება ან გადახედვა საკითხის თანამედროვე გაგების გათვალისწინებით?

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

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

Peopleware: 30 წლის შემდეგ

ოლეგი: იყო თუ არა Peopleware რევოლუცია, ისევე როგორც მანიფესტი?

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

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

მაიკლ: შეიცვალა თუ არა რამე წიგნის გამოქვეყნებიდან ბოლო 30 წლის განმავლობაში?

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

ჩვენ ყველანი ვცხოვრობთ DevOps-ში

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

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

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

მაიკლ: devops-ის მთელი იდეა არის მნიშვნელოვანი მოვლენების რაც შეიძლება ადრე მიწოდება. ვხედავ, რომ სამყარო უფრო და უფრო აჩქარებს. როგორ მოერგოს ასეთ აჩქარებებს? ათი წლის წინ ეს არ არსებობდა!

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

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

შაბლონები და ანტინიმუშები

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

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

ჩვენ მხოლოდ ამხანაგებთან ერთად ვმსჯელობდით, რომ ეს წელი საიუბილეო წელია, ორმოცდაათი წელი მას შემდეგ, რაც ხალხი მთვარეზე დაეშვა. ეს იყო 1969 წელს. ტექნოლოგია, რომელიც დაეხმარა ადამიანებს იქ მოხვედრაში, არის 1969 წლის ტექნოლოგია, არამედ 1960 ან 62, რადგან NASA-ს სურდა გამოეყენებინა მხოლოდ ის, რაც სანდოობის კარგი მტკიცებულება ჰქონდა. ასე რომ, თქვენ უყურებთ და მიხვდებით - დიახ, და ისინი მართალი იყვნენ! ახლა, არა, არა, მაგრამ თქვენ შეგექმნებათ პრობლემები ტექნოლოგიასთან მხოლოდ იმიტომ, რომ ყველაფერი ძალიან ძლიერად არის დაწნული, გაყიდული ყველა ბზარიდან. ხალხი ყველგან ყვირის: "აჰა, რა არის, ეს არის უახლესი რამ, ყველაზე ლამაზი რამ მსოფლიოში, აბსოლუტურად ყველასთვის შესაფერისი!" ესე იგი... როგორც წესი, ეს ყველაფერი მხოლოდ მატყუარა აღმოჩნდება და მერე ეს ყველაფერი უნდა გადააგდოთ. ალბათ იმიტომ, რომ მე უკვე მოხუცი ვარ და ასეთ რაღაცეებს ​​დიდი სკეპტიციზმით ვუყურებ, როცა ადამიანები გარბიან და ამბობენ, რომ მათ იპოვეს ერთადერთი, ყველაზე სწორი გზა საუკეთესო ტექნოლოგიების შესაქმნელად. ამ დროს ჩემს შიგნით იღვიძებს ხმა, რომელიც ამბობს: "რა არეულობაა!"

მაიკლ: მართლაც, რამდენად ხშირად გვსმენია შემდეგი ვერცხლის ტყვიის შესახებ?

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

მაიკლ: დიახ, მთავარი „სიცოცხლის, სამყაროს და ყველაფრის საკითხი“: არის თუ არა ეს ტექნოლოგია ან მიდგომა თქვენი სიტუაციისთვის შესაფერისი?

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

მითიური "დევოპს ინჟინერი"

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

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

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

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

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

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

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

"ექსპერტები ყველაფერს"

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

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

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

რისკები და გაურკვევლობა

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

ოლეგი: იმოძრავეთ სწრაფად და დაარღვიე ნივთები!

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

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

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

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

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

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

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

ზრდასრულთა საინჟინრო აზროვნება

მაიკლ: ბავშვებთან მაგალითი კარგია. თუ ჩვეულებრივი ინჟინერი ვარ, მაშინ ბედნიერი ვარ, რომ ბავშვი ვარ. მაგრამ როგორ მიდიხარ უფრო ზრდასრულთა აზროვნებამდე?

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

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

ტიმ: ზუსტად. ვფიქრობ, საუკეთესო ტექნიკოსები, თუ მათ ყურადღებით დააკვირდებით, ისინი ერთგვარი საკუთარი მენეჯერები არიან. როგორ ჩამოვაყალიბო ეს...

ოლეგი: თქვენი ცხოვრება არის თქვენი პროექტი, რომელსაც თქვენ მართავთ.

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

როგორ მოხვდეთ რისკების მართვაში

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

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

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

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

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

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

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

კომუნიკაციის ფასი

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

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

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

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

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

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

მაიკლ: წადი დაწერე კოდი!

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

ოლეგი: მიშა, რაღაცაზე ფიქრობ.

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

ცხოვრება ხელფასების გარეშე

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

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

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

საუკეთესო რჩევა

მაიკლ: „საუკეთესო რჩევებს“ რომ დავუბრუნდეთ, არის თუ არა რაიმე, რასაც უთხარით თქვენს კლიენტებს არაერთხელ? არსებობს იდეა 80/20-ზე და ზოგიერთი რჩევა ალბათ უფრო ხშირად მეორდება.

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

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

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

ივარჯიშე რისკების მართვაში!

მაიკლ: თქვენი აზრით, რამდენი ორგანიზაციაა ჩართული რისკების მართვაში?

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

მაიკლ: და მაინც, ამ კომპანიებიდან რამდენია ჩართული რისკის მენეჯმენტში, ხუთი პროცენტი?

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

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

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

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

ტიმ: მოდით დავაჭიროთ გადატვირთვის ღილაკს! არა, ასე არ მუშაობს.

მთავარი ნოტა DevOops 2019-ზე

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

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

მაიკლ: მეც წლებია ვმუშაობ კონსულტაციებში და კარგად მესმის რაზეა საუბარი.

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

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

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

ტიმ ლისტერი ჩამოვა მთავარი ნოტით "პერსონაჟები, საზოგადოება და კულტურა: კეთილდღეობის მნიშვნელოვანი ფაქტორები"DevOops 2019 კონფერენციაზე, რომელიც ჩატარდება 29 წლის 30-2019 ოქტომბერს ქ. შეგიძლიათ შეიძინოთ ბილეთები ოფიციალურ ვებგვერდზე. გელოდებით DevOops-ში!

წყარო: www.habr.com