Problem: ən yaxşı proqramçı komandanın darboğazına çevrilir

Senior mühəndis altı nəfərlik komandanın tech lead-i təyin olunur. İlk ayda əvvəlki üsullarla işləyir: ən çətin tapşırıqları götürür, bütün Pull Request-lərə özü baxır, çatdakı hər suala özü cavab verir. Komanda işləyir, amma yavaş. İki həmkar təsdiq gözləyir, ödəniş modulunu başqa heç kim başa düşmür, lead-in öz tapşırıqları isə hər sprintdə gecikir. Mühəndisdə problem yoxdur. İş dəyişib, vərdişlər dəyişməyib.

Əsas dəyişiklik belədir: fərdi icraçı kimi sizi nə qurduğunuza görə qiymətləndirirlər, tech lead kimi isə komandanın nə qurduğuna və sizsiz də qurmağa davam edə bilməsinə görə. Çıxışınız artıq qərarlar, aydınlıq və başqalarının inkişafıdır. Kod işin hissəsi olaraq qalır, amma əsas rıçaq deyil.

İlk həftələr: dəyişməzdən əvvəl dinləyin

Yeni proses elan etmək istəyinə qarşı durun. İlk həftələri faktları toplamağa ayırın.

  • Hər mühəndislə ayrıca görüş keçirin. Onları nə ləngidir, nə ilə fəxr edirlər, hansı hissəyə toxunmaq istəmirlər, nəyi öyrənmək istəyirlər.
  • Son aylardakı insidentlərə, geri qaytarmalara (rollback) və uzun çəkən Pull Request-lərə baxın. Real ağrı nöqtələri oradadır.
  • Sistemi çəkin. Diaqram yoxdursa, özünüz context və container görünüşü cızın (C4 model bələdçisinə baxın) və komandadan düzəliş istəyin. Ən qiymətli hissə düzəlişlərdir.
  • Komandanızdan asılı olanlarla tanış olun: product, dəstək, əməliyyat, digər komandalar. Onlardan nə gözlədiklərini və nəyin onları təəccübləndirdiyini soruşun.

Öyrəndiklərinizi qısa sənəddə yazın: sistem, problemlər, açıq suallar. Paylaşın. Bu bir səhifə istənilən yeni qaydadan çox etibar qazandırır.

Texniki istiqaməti diktə etmədən müəyyən etmək

Tech lead istiqamətə sahibdir, hər qərara yox. Faydalı bölgü:

  • Siz qərar verirsiniz: seçim bütün sistemə aiddirsə, geri qaytarılması çətindirsə və ya komanda ilişibsə.
  • Komanda qərar verir: razılaşdırılmış çərçivədə lokal seçimləri.
  • Rəy alıb sonra siz qərar verirsiniz: hansı kateqoriyaya aid olduğu aydın deyilsə.

Hansı qərarı verirsinizsə, onu görünən edin. Yalnız görüşdə qalan qərar bir neçə sprintdən sonra unudulur və hər yeni gələn onu yenidən müzakirə edir. Kodun yanında saxlanan qısa Architecture Decision Record-lar yazın (ADR yazmaq məqaləsinə baxın). Yaxşı qeyd konteksti, baxılan variantları, qərarı və nəticələri, o cümlədən qəbul etdiyiniz mənfi tərəfi göstərir.

ADR-007: Hələlik order və payment bir deployable-da qalır
Status: accepted
Context: altı nəfərlik komanda, bir database, ortaq release.
Options: (a) indi servislərə bölmək, (b) modular monolit,
(c) mövcud vəziyyət.
Decision: (b), ayrı package-lər, package-lər arası cədvələ
birbaşa giriş yoxdur.
Consequences: əməliyyat sadədir; modul sərhədlərini review-da
yoxlamalıyıq; komanda sayı artanda yenidən baxılacaq.

Bu cür sərhəd suallarına mikroservis sərhədləri məqaləsində baxılır.

İşləyən tapşırıq bölgüsü

Delegasiya ya "bunu həll et" kimi atmaqla, ya da "hər saat yoxlayacağam" kimi nəzarətlə pozulur. Addımları yox, nəticəni tapşırın və dörd şeyi razılaşdırın: məqsəd, məhdudiyyətlər, işin bitdiyini necə biləcəyiniz və problemlər barədə nə vaxt eşitmək istədiyiniz.

İnsanlara rahatlıq zonasından bir az yuxarı tapşırıqlar verin. Risklilərini işi geri götürmək əvəzinə reviewer ilə cütləşdirin. Geri götürmək bu gün sürətlidir, amma sonrakı hər gün baha başa gəlir: komanda çətin işin sizə axdığını öyrənir.

Özünüzü yoxlamaq üçün sual: iki həftə əlçatmaz olsanız, hansı sahələr dayanar? Hər cavab növbəti rüb üçün delegasiya və ya bilik paylaşma tapşırığıdır.

Review mədəniyyəti və nə qədər kod yazmaq

Code review keyfiyyət və ortaq bilik üçün ən ucuz rıçaqdır. Onu yayın: reviewer-ləri növbələşdirin, Pull Request-ləri kiçik saxlayın, bloklayıcı problemlərlə üslub seçimlərinin qarışmaması üçün şərh növləri razılaşdırın. Təfərrüatlar code review mədəniyyəti məqaləsindədir. Öz review-larınız istədiyiniz tonun nümunəsi olmalıdır.

Kod yazmağa gəlincə: koda yaxın qalın, amma kritik yoldan kənarda. Yaxşı lead tapşırıqları: spike-lar, prototiplər, alətlər, test infrastrukturu, cütlük işi (pairing). Pis lead tapşırığı hamının gözlədiyi feature-dir, çünki hər yarımçıqlıq komandanı bloklayır. Təqviminizi dürüst planlayın: bir çox lead-lər üçün həftədə bir neçə dəfə yarım günlük fokus bloku realdır, qalanını görüşlər doldurur.

Maraqlı tərəflərlə ünsiyyət

Maraqlı tərəflər (stakeholder) texniki təfərrüat istəmir. Onlar nələrin gəldiyini, nəyin risk altında olduğunu və sizdən nə lazım olduğunu bilmək istəyir. Qısa müntəzəm yeniləmə yaxşı işləyir:

  1. Əvvəlki yeniləmədən bəri nə çatdırılıb.
  2. Növbəti nədir, yalançı tarix əvəzinə əminlik səviyyəsi (yüksək, orta, aşağı) ilə.
  3. Risklər və sizə lazım olan qərar və ya kömək.

"Yox" deyəndə alternativ təklif edin: mövcud vaxtla nə etmək olar və ya yeni sorğuya yer açmaq üçün nə çıxarılmalıdır. Pis xəbəri tez və təklif olunan yolla çatdırın. Gözlənilməz hallar gecikmədən qat-qat çox etibara zərər verir.

Yeni rolun ən böyük təhlükəsi görünməz olmaqdır: ya hər şeyə qarışan mikromenecer, ya da görüşlərdə itən lider. Hər həftənin sonunda özünüzdən soruşun: komandanın hansı maneəsini bu həftə aradan qaldırdım və kimin işi mənim sayəmdə asanlaşdı? Cavab yoxdursa, təqviminizi yenidən qurun. Bu sual sizi həm koddan, həm də boş görüşlərdən qoruyur və fokusu komandanın axınına qaytarır.

Tez-tez edilən səhvlər

  • Hazırkı yolun niyə mövcud olduğunu anlamamış çoxlu şeyi eyni anda dəyişmək.
  • Eyni zamanda həm ən yaxşı developer, həm əsas reviewer qalmaq.
  • Qərarları səssiz verib sonra nəzərə alınmadığına təəccüblənmək.
  • Performans barədə çətin söhbətlərdən qaçıb onları böhrana çevirmək.
  • Texniki borcu əxlaqi məsələ kimi görmək, prioritetləşdirilmiş və izah olunmuş kompromis əvəzinə.
  • Komandanın müstəqilliyi əvəzinə özünüzün lazım olmağınız üçün optimallaşdırmaq.

Kompromislər

Daha çox tapşırıq bölmək sizinkindən fərqli həlləri qəbul etmək deməkdir. Razılaşdırılmış nəticəni təmin edirsə, qəbul edin; etirazları düzgünlük, təhlükəsizlik və geri qaytarıla bilmə üçün saxlayın. Qərarları yazmaq vaxt aparır, ona görə ADR-ləri dəyişdirilməsi baha olan seçimlərə saxlayın. Praktik işdə qalmaq etibarınızı qoruyur, amma liderlik işini sıxışdıra bilər, balansı hər rüb yenidən tənzimləyin.

30-60-90 çərçivəsi

Rəqəmlər ritmdir, vəd deyil.

  • İlk 30: fərdi görüşlər, insident analizi, sistem diaqramı, stakeholder tanışlığı, tapıntılar sənədinin paylaşılması.
  • Növbəti 30: komandanın razılaşdığı iki-üç yaxşılaşdırma seçin, ADR-lərə başlayın, reviewer-ləri növbələşdirin, bir mühüm sahəni başqasına verin.
  • Son 30: nəyin dəyişdiyini komanda ilə nəzərdən keçirin, rüblük məqsədlər qoyun, stakeholder yeniləmə formatını razılaşdırın, inkişaf söhbətlərini planlaşdırın.

Yoxlama siyahısı

  • Hər mühəndislə sizin fərdi görüşünüz olub.
  • Aktual sistem diaqramı var və komanda onu düzəldib.
  • Əhəmiyyətli qərarlar nəticələri ilə yazılıb.
  • Ən azı bir sahə sizdən başqasına keçib.
  • Review-lar komanda üzrə bölünüb, şərh növləri razılaşdırılıb.
  • Stakeholder-lər müntəzəm qısa yeniləmə alır.

Növbəti addımlar