როგორ პოულობს staff-ინჟინერი მოსაგვარებელ პრობლემებს

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

შეითვისე პრობლემები და არა მოთხოვნები

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

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

მიეცი პრობლემებს დაგროვების საშუალება

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

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

ფუნქციის მოთხოვნებიდან გაფართოებებამდე

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

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

რატომ არის ეს მნიშვნელოვანი

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