Tim Lister - kitabların həmmüəllifi
- “İnsan amili. Uğurlu Layihələr və Komandalar” (orijinal kitab “Peopleware” adlanır)
- "Ayılarla Vals: Proqram Layihələrində Riskin İdarə Edilməsi"
- “Adrenalinlə çılğın və naxışlarla zombiləşdirilmiş. Layihə komandalarının davranış nümunələri"
Bu kitabların hamısı öz sahəsində klassikdir və həmkarları ilə birlikdə yazılmışdır . Rusiyada onun həmkarları ən məşhurdur - и , o da bir çox məşhur əsərlər yazmışdır.
Tim proqram təminatının hazırlanması sahəsində 40 illik təcrübəyə malikdir; 1975-ci ildə (bu habrapostu yazanların heç biri bu il anadan olmayıb), Tim artıq Yourdon Inc-in icraçı vitse-prezidenti idi. İndi vaxtını məsləhətləşməyə, öyrətməyə və yazmağa sərf edir, vaxtaşırı ona baş çəkir dünya üzrə konfranslar.
Xüsusilə Habr üçün Tim Lister ilə müsahibə etdik. O, DevOops 2019 konfransını açacaq və kitablar və sair haqqında çoxlu suallarımız var. Müsahibəni konfransın proqram komitəsindən Mixail Drujinin və Oleq Çiruxin aparır.
Michael: İndi gördüyünüz iş haqqında bir neçə söz deyə bilərsinizmi?
Tim: Mən Atlantik Sistemlər Gildiyasının rəhbəriyəm. Gildiyada altı nəfərik, özümüzə direktor deyirik. Üçü ABŞ-da, üçü Avropada - buna görə Gildiya Atlantik adlanır. Biz o qədər uzun illərdir ki, bir yerdəyik ki, onları saymaq olmur. Hamımızın öz ixtisaslarımız var. Mən son on il və ya daha çox müştərilərlə işləyirəm. Layihələrimə təkcə idarəetmə deyil, həm də tələblərin qoyulması, layihənin planlaşdırılması və qiymətləndirmə daxildir. Görünür, pis başlayan layihələr adətən pis başa çatır. Buna görə də, bütün fəaliyyətlərin həqiqətən yaxşı düşünülmüş və əlaqələndirilmiş olduğundan, yaradıcıların fikirlərinin birləşdirildiyindən əmin olmağa dəyər. Nə etdiyinizi və niyə etdiyinizi düşünməyə dəyər. Layihəni başa çatdırmaq üçün hansı strategiyalardan istifadə etmək lazımdır.
Mən uzun illərdir ki, müştərilərə müxtəlif yollarla məsləhət verirəm. Maraqlı nümunə diz və omba əməliyyatları üçün robotlar istehsal edən şirkətdir. Cərrah tamamilə müstəqil fəaliyyət göstərmir, ancaq robotdan istifadə edir. Açıq desək, burada təhlükəsizlik vacibdir. Ancaq problemlərin həllinə diqqət yetirən insanlarla tələbləri müzakirə etməyə çalışdığınız zaman... Qəribə səslənəcək, amma ABŞ-da Bu robotlar kimi məhsulların lisenziyasını verən (Federal Dərman İdarəsi). Bir şey satmadan və canlı insanlarda istifadə etməzdən əvvəl lisenziya almalısınız. Şərtlərdən biri tələblərinizi, testlərin nə olduğunu, onları necə sınaqdan keçirdiyinizi, test nəticələrinin nə olduğunu göstərməkdir. Tələbləri dəyişdirsəniz, bu nəhəng sınaq prosesindən təkrar-təkrar keçməli olacaqsınız. Müştərilərimiz öz tələblərinə tətbiqlərin vizual dizaynını daxil etməyi bacardılar. Tələblərin bir hissəsi olaraq birbaşa ekran görüntüləri var idi. Onları çıxarıb izah etməliyik ki, əksər hallarda bütün bu proqramlar dizlər və ombalar, kamera ilə bağlı bütün bunlar və s. haqqında heç nə bilmir. Biz tələb sənədlərini yenidən yazmalıyıq ki, bəzi vacib əsas şərtlər dəyişmədikcə, onlar heç vaxt dəyişməsin. Vizual dizayn tələblərə uyğun deyilsə, məhsulun yenilənməsi daha sürətli olacaq. Bizim işimiz dizdə, ombada, kürəkdə əməliyyatlarla məşğul olan elementləri tapmaq, onları ayrı-ayrı sənədlərə çıxarmaq və bunun əsas tələblər olacağını söyləməkdir. Diz əməliyyatları ilə bağlı təcrid olunmuş bir qrup tələb edək. Bu, bizə daha sabit tələblər toplusunu qurmağa imkan verəcək. Xüsusi robotlar haqqında deyil, bütün məhsul xətti haqqında danışacağıq.
Çox iş görüldü, amma yenə də əvvəllər həftələr və aylarla təkrar sınaqlar keçirdikləri yerlərə gəldilər, çünki onların kağız üzərində təsvir olunan tələbləri sistemlərin qurulduğu real tələblərlə üst-üstə düşmürdü. FDA onlara hər dəfə deyirdi: tələbləriniz dəyişib, indi hər şeyi sıfırdan yoxlamaq lazımdır. Bütün məhsulun tam yenidən yoxlanılması müəssisəni öldürürdü.
Beləliklə, özünüzü maraqlı bir şeyin başlanğıcında tapanda belə gözəl vəzifələr var və ilk hərəkətlər oyunun sonrakı qaydalarını təyin edir. Bu erkən fəaliyyətin həm idarəetmə, həm də texniki baxımdan yaxşı işləməyə başladığına əmin olsanız, böyük bir layihə ilə başa çatmaq şansınız var. Amma bu hissə relsdən çıxıbsa və hardasa səhv gedibsə, əsas razılaşmaları tapa bilmirsinizsə... yox, bu, sizin layihənizin mütləq uğursuz olacağı anlamına gəlmir. Amma siz artıq deyə bilməyəcəksiniz: “Biz əla iş gördük, hər şeyi həqiqətən səmərəli etdik”. Müştərilərlə ünsiyyət qurarkən etdiyim şeylər bunlardır.
Michael: Yəni, siz layihələrə start verirsiniz, bir növ start götürürsünüz və relslərin düzgün istiqamətdə getdiyini yoxlayırsınız?
Tim: Tapmacanın bütün hissələrini necə bir araya gətirmək barədə də fikirlərimiz var: bizə hansı bacarıqlara ehtiyacımız var, onlar tam olaraq nə vaxt lazımdır, komandanın özəyi necə görünür və digər bu kimi əsas şeylər. Tam ştatlı işçilərə ehtiyacımız varmı və ya kimisə part-time işə götürə bilərik? Planlaşdırma, idarəetmə. Suallar: Bu xüsusi layihə üçün ən vacib olan nədir? Buna necə nail olmaq olar? Bu məhsul və ya layihə haqqında nə bilirik, hansı risklər var və bilinməyənlər haradadır, bütün bunlarla necə məşğul olacağıq? Təbii ki, bu anda kimsə “Bəs çeviklik?” deyə qışqırmağa başlayır. Yaxşı, hamınız çeviksiniz, amma nə olacaq? Layihə tam olaraq necə görünür, onu layihəyə uyğun şəkildə necə çıxarmaq fikrindəsiniz? Sadəcə deyə bilməzsiniz ki, “bizim yanaşmamız hər şeyə uzanır, biz Scrum komandasıyıq!” Bu cəfəngiyyat və cəfəngiyyatdır. Bundan sonra hara gedəcəksən, niyə işləməlidir, məqam haradadır? Müştərilərimə bütün bu suallar üzərində düşünməyi öyrədirəm.
19 il çevik
Michael: Agile-də insanlar tez-tez heç nəyi əvvəlcədən müəyyənləşdirməməyə, mümkün qədər gec qərar verməyə çalışırlar və deyirlər: biz çox böyükük, ümumi memarlıq haqqında düşünməyəcəyəm. Mən bir çox başqa şeylər haqqında düşünməyəcəyəm; bunun əvəzinə, müştəriyə hazırda işləyən bir şey çatdıracağam.
Tim: Məncə çevik metodologiyalardan başlayaraq 2001-ci ildə sənayenin gözlərini açdı. Ancaq digər tərəfdən, heç bir şey mükəmməl deyil. Mən iterativ inkişafın tərəfdarıyam. Əksər layihələrdə iterasiya çox məna kəsb edir. Ancaq düşünməli olduğunuz sual budur: məhsul çıxarıldıqdan və istifadə edildikdən sonra nə qədər davam edir? Bu, başqa bir şeylə əvəz edilməzdən əvvəl altı ay davam edəcək bir məhsuldurmu? Yoxsa bu, uzun illər işləyəcək bir məhsuldur? Əlbəttə, ad çəkməyəcəm, amma... Nyu Yorkda və onun maliyyə icmasında ən fundamental sistemlər çox köhnədir. Bu heyrətamizdir. Onlara baxıb fikirləşirsən ki, kaş keçmişə, 1994-cü ilə qayıdıb tərtibatçılara deyirsən: “Mən gələcəkdən, 2019-cu ildən gəlmişəm. Sadəcə bu sistemi ehtiyacınız olan müddətə inkişaf etdirin. Onu genişləndirilə bilən hala gətirin, memarlıq haqqında düşünün. Daha sonra iyirmi beş ildən çox müddətə təkmilləşdiriləcəkdir. Əgər inkişafı bir az da gecikdirsəniz, heç kim hiss etməyəcək!” Uzun müddət ərzində hər şeyi təxmin edərkən, bunun cəmi nə qədər başa gələcəyini nəzərə almalısınız. Bəzən yaxşı dizayn edilmiş memarlıq həqiqətən buna dəyər, bəzən isə yox. Ətrafa baxıb özümüzə sual verməliyik: belə bir qərar üçün düzgün vəziyyətdəyikmi?
Beləliklə, "Biz çevik tərəfdarıq, müştəri özü bizə nə almaq istədiyini söyləyəcək" kimi bir fikir çox sadəlövhdür. Müştərilər nə istədiklərini belə bilmirlər və daha çox nə əldə edə biləcəklərini bilmirlər. Bəziləri arqument kimi tarixi nümunələr gətirməyə başlayacaqlar, mən bunu artıq görmüşəm. Ancaq texniki cəhətdən inkişaf etmiş insanlar adətən bunu demirlər. Deyirlər: “2019-cu ildir, bunlar bizim imkanlarımızdır və biz bunlara baxışımızı tamamilə dəyişə bilərik!” Mövcud həlləri təqlid etmək, onları bir az daha gözəl və daha daranmış etmək əvəzinə, bəzən çölə çıxıb deməlisən: “Gəlin burada etməyə çalışdığımız işi tamamilə yenidən kəşf edək!”
Və mən düşünmürəm ki, müştərilərin çoxu problemi belə düşünə bilməz. Onlar yalnız onlarda olanları görürlər, hamısı budur. Bundan sonra onlar “bunu bir az daha sadələşdirək” və ya adətən nə deyirlərsə, kimi xahişlərlə gəlirlər. Amma biz ofisiant və ya ofisiant deyilik, ona görə də nə qədər axmaq olsa da, sifariş götürüb mətbəxdə bişirə bilərik. Biz onların bələdçiləriyik. Onların gözlərini açıb deməliyik: hey, burada bizim yeni imkanlarımız var! Biznesinizin bu hissəsinin həyata keçirilməsini həqiqətən dəyişə biləcəyimizi başa düşürsünüzmü? Agile ilə bağlı problemlərdən biri odur ki, o, imkanın nə olduğunu, problemin nə olduğunu, hətta nə etməli olduğumuzu, mövcud texnologiyaların bu xüsusi vəziyyətə ən uyğun olduğunu başa düşməyi aradan qaldırır.
Ola bilsin ki, mən burada həddindən artıq şübhə ilə yanaşıram: çevik cəmiyyətdə çox gözəl şeylər baş verir. Amma mənim bir problemim var ki, insanlar hansısa layihəni müəyyənləşdirmək əvəzinə, əl-qol atmağa başlayırlar. Mən burada soruşardım - biz nə edirik, bunu necə edəcəyik? Və nədənsə sehrli şəkildə həmişə müştərinin hamıdan yaxşı bilməli olduğu ortaya çıxır. Ancaq müştəri yalnız kiminsə artıq tikdiyi şeylərdən seçim etdikdə ən yaxşısını bilir. Əgər mən maşın almaq istəsəm və ailə büdcəmin ölçüsünü bilirəmsə, o zaman tez həyat tərzimə uyğun avtomobil seçərəm. Burada mən hər şeyi hamıdan yaxşı bilirəm! Amma nəzərə alın ki, maşınları artıq kimsə düzəldib. Yeni avtomobil icad etmək haqqında heç bir fikrim yoxdur, ekspert deyiləm. Biz xüsusi və ya xüsusi məhsullar yaratdıqda, müştərinin səsi nəzərə alınmalıdır, lakin bu, artıq yeganə səs deyil.
Oleq: Siz Çevik Manifestdən bəhs etdiniz. Məsələnin müasir anlayışını nəzərə alaraq birtəhər yeniləmək və ya yenidən nəzərdən keçirmək lazımdırmı?
Tim: Mən ona toxunmazdım. Hesab edirəm ki, bu, böyük tarixi sənəddir. Demək istədiyim odur ki, odur. 19 yaşı tamam olur, qocalıb, amma vaxtında inqilab edib. Yaxşı etdiyi şey o idi ki, reaksiya verdi və insanlar onun haqqında pıçıldamağa başladılar. Siz, çox güman ki, 2001-ci ildə hələ sənayedə işləmirdiniz, amma sonra hamı proseslərə uyğun işləyirdi. Proqram Mühəndisliyi İnstitutu, proqram təminatının tamlıq modelinin (CMMI) beş səviyyəsi. Bilmirəm, antik dövrün bu cür əfsanələri sizə nəsə deyir, amma sonra bu, bir irəliləyiş oldu. İnsanlar əvvəlcə inanırdılar ki, proseslər düzgün qurulsa, o zaman problemlər öz-özünə aradan qalxacaq. Və sonra Manifest gəlir və deyir: "Xeyr, yox, yox - biz proseslərə deyil, insanlara əsaslanacağıq." Biz proqram təminatının inkişafı ustalarıyıq. Biz başa düşürük ki, ideal proses ilğımdır, bu baş vermir. Layihələrdə həddən artıq idiosinkraziya var, bütün layihələr üçün vahid mükəmməl proses ideyası heç bir məna kəsb etmir. Problemlər çox mürəkkəbdir ki, hər şeyin yalnız bir həlli var (salam, nirvana).
Gələcəyə baxmağı düşünmürəm, amma deyim ki, insanlar indi layihələr haqqında daha çox düşünməyə başlayıblar. Düşünürəm ki, Çevik Manifest sıçrayıb deməyi çox yaxşı bacarır: “Hey! Sən gəmidəsən və bu gəmini özün idarə edirsən. Qərar verməli olacaqsınız - bütün vəziyyətlər üçün universal resept təklif etməyəcəyik. Siz gəminin heyətisiniz və kifayət qədər yaxşısınızsa, məqsədinizə çatmaq üçün bir yol tapa bilərsiniz. Səndən əvvəl də başqa gəmilər olub, səndən sonra da başqa gəmilər olacaq, amma yenə də, müəyyən mənada, sənin səyahətin unikaldır”. Belə bir şey! Bu bir düşüncə tərzidir. Mənim üçün günəşin altında yeni bir şey yoxdur, insanlar əvvəllər üzüblər və yenə də üzəcəklər, amma sizin üçün bu, əsas səyahətinizdir və sizə dəqiq nə olacağını söyləməyəcəyəm. Bir komandada koordinasiyalı iş bacarıqlarına sahib olmalısınız və əgər bunlar həqiqətən varsa, hər şey düzələcək və istədiyiniz yerə çatacaqsınız.
Peopleware: 30 il sonra
Oleq: Peopleware Manifest kimi bir inqilab idimi?
Tim: Peopleware... Tom və mən bu kitabı yazdıq, amma bunun belə olacağını düşünməmişdik. Nədənsə bir çox insanın fikirləri ilə rezonans doğurdu. Bu, deyən ilk kitab idi: proqram təminatının inkişafı çox insan intensiv fəaliyyətdir. Texniki təbiətimizə baxmayaraq, biz həm də böyük, hətta nəhəng, çox mürəkkəb bir şey quran insanların birliyiyik. Heç kim təkbaşına belə şeylər yarada bilməz, elə deyilmi? Beləliklə, "komanda" ideyası çox vacib oldu. Həm də təkcə idarəetmə nöqteyi-nəzərindən deyil, həm də bir çox naməlumlarla həqiqətən mürəkkəb dərin problemləri həll etmək üçün bir araya gələn texniki insanlar üçün. Şəxsən mənim üçün bu, karyeram boyu böyük bir zəka sınağı olmuşdur. Və burada deyə bilməlisiniz: bəli, bu problem mənim təkbaşına həll edə biləcəyimdən daha çoxdur, lakin biz birlikdə fəxr edə biləcəyimiz zərif bir həll tapa bilərik. Və məncə, ən çox rezonans doğuran bu fikir oldu. Zamanın bir hissəsini təkbaşına, bir hissəsini qrupun bir hissəsi kimi işlədiyimiz və çox vaxt qərarın qrup tərəfindən qəbul edilməsi fikri. Qrup problemlərinin həlli tez bir zamanda kompleks layihələrin vacib xüsusiyyətinə çevrildi.
Tim çoxlu sayda çıxışlar etməsinə baxmayaraq, onlardan çox az hissəsi YouTube-da yerləşdirilib. 2007-ci ildən “İnsanların Qaytarılması” hesabatına baxa bilərsiniz. Keyfiyyət, əlbəttə ki, arzuolunan çox şey buraxır.
Michael: Kitabın nəşrindən sonra keçən 30 ildə nəsə dəyişdimi?
Tim: Buna bir çox fərqli bucaqlardan baxa bilərsiniz. Sosioloji desək... bir vaxtlar, daha sadə vaxtlarda komandanızla eyni kabinetdə oturmusunuz. Hər gün yaxın ola, birlikdə qəhvə içə və işi müzakirə edə bilərsiniz. Həqiqətən dəyişən odur ki, komandalar indi coğrafi olaraq, müxtəlif ölkələrdə və saat qurşağında paylana bilər, lakin yenə də eyni problem üzərində işləyirlər və bu, tamamilə yeni bir mürəkkəblik qatını əlavə edir. Bu köhnə məktəb kimi səslənə bilər, amma hamınızın bir yerdə olduğunuz, birlikdə işlədiyiniz və bir həmkarınızın yanına gedib deyə biləcəyiniz üz-üzə ünsiyyət kimi bir şey yoxdur ki, görün mən nə kəşf etdim, bunu necə bəyənirsiniz? Üz-üzə söhbətlər qeyri-rəsmi ünsiyyətə keçidin sürətli yolunu təmin edir və məncə çevik həvəskarlar da bunu bəyənməlidir. Mən də narahatam, çünki reallıqda dünya çox kiçik olub və indi hər şey paylanmış komandalarla əhatə olunub və hər şey çox mürəkkəbdir.
Hamımız DevOps-da yaşayırıq
Michael: Hətta konfransın proqram komitəsi baxımından bizim Kaliforniyada, Nyu-Yorkda, Avropada, Rusiyada adamlarımız var... Sinqapurda hələ heç kim yoxdur. Coğrafiyadakı fərq olduqca böyükdür və insanlar daha da yayılmağa başlayır. Əgər inkişafdan danışırıqsa, bizə devops və komandalar arasında maneələrin aradan qaldırılması haqqında ətraflı məlumat verə bilərsinizmi? Belə bir anlayış var ki, hamı öz bunkerində oturur, indi də bunkerlər dağılır, bu bənzətməyə necə baxırsınız?
Tim: Mənə elə gəlir ki, son texnoloji nailiyyətlər fonunda devops böyük əhəmiyyət kəsb edir. Əvvəllər tərtibatçılar və idarəçilərdən ibarət komandalarınız var idi, onlar işlədilər, işlədilər, işlədilər və bir anda adminlərə yaxınlaşıb istehsal üçün yaymaq üçün bir şey ortaya çıxdı. Və burada bunker haqqında söhbət başladı, çünki adminlər bir növ müttəfiqdirlər, heç olmasa düşmən deyillər, amma siz onlarla yalnız hər şey istehsala getməyə hazır olanda danışdınız. Onlara bir şeylə getdin və dedin: bax bizim nə proqramımız var, amma bu proqramı yaymaq olar? İndi bütün çatdırılma konsepsiyası yaxşılığa doğru dəyişdi. Demək istədiyim o fikir var idi ki, siz dəyişiklikləri tez bir zamanda həyata keçirə bilərsiniz. Məhsulları tez yeniləyə bilərik. Laptopumda Firefox görünəndə həmişə gülümsəyirəm və deyir ki, hey, biz Firefox-u arxa planda yeniləmişik və bir dəqiqəniz olan kimi bura klikləyin və biz sizə ən son buraxılışı təqdim edəcəyik. Və mən dedim: "Oh, balam!" Mən yatarkən, onlar mənim kompüterimdə mənə yeni buraxılışı çatdırmaq üzərində işləyirdilər. Bu gözəldir, inanılmazdır.
Ancaq burada çətinlik var: proqram təminatının yenilənməsi ilə bu xüsusiyyətiniz var, lakin insanları inteqrasiya etmək daha çətindir. DevOops-un əsas çıxışında səsləndirmək istədiyim odur ki, indi bizdə həmişə olduğundan daha çox oyunçu var. Yalnız bir komandada iştirak edən hər kəsi düşünsəniz... Siz bunu bir komanda kimi düşündünüz və bu, sadəcə proqramçılardan ibarət komandadan daha çox şeydir. Bunlar testçilər, layihə menecerləri və bir çox başqa insanlardır. Və hər kəsin dünyaya öz baxışı var. Məhsul menecerləri layihə menecerlərindən tamamilə fərqlidir. Adminlərin öz vəzifələri var. Baş verənlərdən xəbərdar olmağa və dəli olmamağa davam etmək üçün bütün iştirakçıları əlaqələndirmək olduqca çətin bir problemə çevrilir. Qrupun tapşırıqlarını və hamıya aid olan tapşırıqları ayırmaq lazımdır. Bu, çox çətin bir işdir. Digər tərəfdən, düşünürəm ki, hər şey illər əvvəl olduğundan daha yaxşıdır. Bu, insanların böyüdüyü və düzgün davranmağı öyrəndiyi yoldur. İnteqrasiya edəndə başa düşürsən ki, heç bir yeraltı inkişaf olmamalıdır, belə ki, proqram təminatı ən son anda qutuda bir jack-in-the-the-box kimi sürünməsin: məsələn, burada nə etdik! İdeya budur ki, siz inteqrasiya və inkişaf edə biləcəksiniz və sonda səliqəli və təkrarlanan bir şəkildə yayılacaqsınız. Bütün bunlar mənim üçün çox şey deməkdir. Bu, sistemin istifadəçiləri və müştəriniz üçün daha çox dəyər yaratmağa imkan verir.
Michael: Devops-un bütün ideyası mənalı inkişafı mümkün qədər tez çatdırmaqdır. Görürəm ki, dünya getdikcə sürətlənməyə başlayıb. Bu cür sürətlənmələrə necə uyğunlaşmaq olar? On il əvvəl bu yox idi!
Tim: Əlbəttə ki, hər kəs daha çox funksionallıq istəyir. Hərəkət etməyə ehtiyac yoxdur, sadəcə daha çox yığın. Bəzən hətta faydalı bir şey gətirmək üçün növbəti artımlı yeniləmə üçün yavaşlamalı olursunuz - və bu, tamamilə normaldır.
Qaçmaq, qaçmaq, qaçmaq fikri ən yaxşısı deyil. Çətin ki, kimsə həyatını belə yaşamaq istəsin. İstərdim ki, çatdırılmaların ritmi layihənin öz ritmini təyin etsin. Əgər siz sadəcə olaraq kiçik, nisbətən mənasız şeylər axını yaratsanız, bunların heç bir mənası yoxdur. Ağılsızca hər şeyi mümkün qədər tez buraxmağa çalışmaq əvəzinə, aparıcı tərtibatçılar və məhsul və layihə menecerləri ilə müzakirə etməyə dəyər strategiyadır. Bunun hətta mənası varmı?
Nümunələr və antipatternlər
Oleq: Siz adətən nümunələr və antipatternlər haqqında danışırsınız və bu, layihələrin həyatı və ölümü arasındakı fərqdir. İndi isə devops həyatımıza daxil olur. Layihəni yerindəcə öldürə biləcək öz naxışlarından və anti-naxışlarından hər hansı biri varmı?
Tim: Nümunələr və anti-naxışlar hər zaman olur. Danışacaq bir şey. Yaxşı, "parlaq şeylər" dediyimiz bir şey var. İnsanlar həqiqətən, həqiqətən, yeni texnologiyanı sevirlər. Onlar sadəcə olaraq sərin və qəşəng görünən hər şeyin parıltısına heyran qalırlar və suallar verməyi dayandırırlar: hətta lazımdırmı? Nəyə nail olacağıq? Bu şey etibarlıdırmı, bunun bir mənası varmı? Mən tez-tez insanları, belə demək mümkünsə, texnologiyanın ən qabaqcıl nöqtəsində görürəm. Dünyada baş verənlər onları hipnoz edir. Ancaq onların hansı faydalı işlərlə məşğul olduğuna daha yaxından nəzər salsanız, çox vaxt faydalı heç nə yoxdur!
Biz sadəcə olaraq yoldaşlarımızla müzakirə edirdik ki, bu il yubiley ilidir, insanların Aya enişindən əlli il keçir. Bu, 1969-cu ildə idi. İnsanların oraya getməsinə kömək edən texnologiya hətta 1969-cu il texnologiyası deyil, daha çox 1960 və ya 62-dir, çünki NASA yalnız etibarlılığın yaxşı sübutu olanlardan istifadə etmək istəyirdi. Beləliklə, ona baxıb başa düşürsən - bəli və onlar doğru idi! İndi, yox, yox, ancaq texnologiya ilə bağlı problemlərə girirsiniz, çünki hər şey çox güclü şəkildə itələnir, bütün çatlardan satılır. İnsanlar hər yerdən qışqırırlar: "Bax, bu nə şeydir, bu, dünyanın ən yeni, ən gözəl şeyidir, tamamilə hamıya uyğundur!" Bəli, belədir... adətən bütün bunlar sadəcə bir aldatmacaya çevrilir və sonra hamısını atmaq lazımdır. Bəlkə də hamısı ona görədir ki, mən artıq qocayam və insanlar tükənib ən yaxşı texnologiyaları yaratmağın yeganə, ən düzgün yolunu tapdıqlarını söyləyəndə belə şeylərə böyük şübhə ilə baxıram. Bu anda içimdə bir səs oyanır: “Nə qarmaqarışıqlıqdır!”
Michael: Həqiqətən, biz növbəti gümüş güllə haqqında nə qədər tez-tez eşitmişik?
Tim: Məhz və bu, hər şeyin adi gedişatıdır! Məsələn... deyəsən, bu, artıq bütün dünyada zarafat halına gəlib, amma burada insanlar tez-tez blokçeyn texnologiyasından danışırlar. Və onlar müəyyən vəziyyətlərdə həqiqətən məna kəsb edirlər! Həqiqətən hadisələrin, sistemin işlədiyinə və heç kimin bizi aldatmadığına dair etibarlı sübuta ehtiyacınız olduqda, təhlükəsizlik problemləriniz və bütün bu şeylər bir-birinə qarışdıqda - blockchain məna kəsb edir. Bəs onlar Blockchain-in indi dünyanı süpürərək yolundakı hər şeyi süpürəcəyini söyləyəndə? Daha çox xəyal edin! Bu çox bahalı və mürəkkəb texnologiyadır. Texniki cəhətdən mürəkkəb və vaxt aparan. O cümlədən sırf alqoritmik olaraq, hər dəfə riyaziyyatı ən kiçik dəyişikliklərlə yenidən hesablamaq lazımdır... və bu əla fikirdir - ancaq müəyyən hallar üçün. Bütün həyatım və karyeram bununla bağlı olub: çox konkret vəziyyətlərdə maraqlı fikirlər. Vəziyyətinizin nə olduğunu dəqiq başa düşmək çox vacibdir.
Michael: Bəli, əsas “həyatın, kainatın və hər şeyin sualı”: bu texnologiya və ya yanaşma sizin vəziyyətinizə uyğundur, ya yox?
Tim: Bu sual artıq texnologiya qrupu ilə müzakirə oluna bilər. Bəlkə də hansısa məsləhətçi də gətirsin. Layihəyə nəzər salın və anlayın - indi əvvəlkindən daha yaxşı, düzgün və faydalı bir şey edəcəyikmi? Bəlkə uyğun olacaq, bəlkə də uyğun olmayacaq. Amma ən əsası odur ki, sadəcə kiminsə ağzını açıb: “Bizim blokçeynə çox ehtiyacımız var! Mən indicə təyyarədə onun haqqında jurnalda oxudum!” Ciddi? Heç gülməli deyil.
Mifik "devops mühəndisi"
Oleq: İndi hamı devops tətbiq edir. Kimsə internetdə devops haqqında oxuyur və sabah işə qəbul saytında başqa bir vakansiya görünür. "devops mühəndis". Burada diqqətinizi çəkmək istərdim: sizcə, “devops engineer” termininin yaşamaq hüququ varmı? Devopsun bir mədəniyyət olduğuna dair bir fikir var və burada bir şey əlavə edilmir.
Tim: Belə-belə. Qoy dərhal bu terminin izahını versinlər. Unikal etmək üçün bir şey. Belə bir vakansiyanın arxasında bacarıqların unikal birləşməsinin olduğunu sübut etməyənə qədər, onu almayacağam! Demək istəyirəm ki, yaxşı, bizim vəzifəmiz var, “devops engineer”, maraqlı bir başlıq, bəli, bundan sonra nə olacaq? Vəzifə adları ümumiyyətlə çox maraqlı bir şeydir. Deyək ki, “inkişafçı” – hər halda bu nədir? Fərqli təşkilatlar tamamilə fərqli şeylər deməkdir. Bəzi şirkətlərdə yüksək keyfiyyətli proqramçılar digər şirkətlərdə xüsusi peşəkar testerlər tərəfindən yazılmış testlərdən daha mənalı olan testlər yazır. Bəs onlar indi proqramçılardır, yoxsa sınaqçılar?
Bəli, iş adlarımız var, amma kifayət qədər uzun suallar versəniz, nəticədə məlum olur ki, biz hamımız problem həll edənik. Biz həll axtarışındayıq və bəzilərinin bəzi texniki bacarıqları, bəzilərinin isə fərqli bacarıqları var. Əgər siz DevOps-un nüfuz etdiyi bir mühitdə yaşayırsınızsa, siz inkişaf və idarəetmənin inteqrasiyası ilə məşğul olursunuz və bu fəaliyyətin kifayət qədər vacib məqsədi var. Amma soruşsalar ki, sən konkret olaraq nə işlə məşğulsan və nəyə cavabdehsən, belə çıxır ki, insanlar bütün bunları qədim zamanlardan edirlər. "Mən arxitekturaya cavabdehəm", "Mən verilənlər bazası üçün cavabdehəm" və s., nə olursa olsun, görürsən - bütün bunlar "devops" dan əvvəl idi.
Kimsə mənə işinin adını deyəndə, çox da qulaq asmıram. Ona əslində nəyə görə cavabdeh olduğunu söyləməsinə icazə vermək daha yaxşıdır, bu, məsələni daha yaxşı başa düşməyə imkan verəcəkdir. Ən sevdiyim nümunə bir insanın "layihə meneceri" olduğunu iddia etməsidir. Nə? Bunun heç bir mənası yoxdur, mən hələ nə etdiyini bilmirəm. Layihə meneceri bir tərtibatçı, dörd nəfərlik bir komandanın lideri, kod yazan, iş görən, komanda lideri halına gələn, insanların öz aralarında lider kimi tanıdığı bir şəxs ola bilər. Həm də bir layihə meneceri bir layihədə altı yüz nəfəri idarə edən, digər menecerləri idarə edən, cədvəllərin tərtib edilməsinə və büdcələrin planlaşdırılmasına cavabdeh olan menecer ola bilər, hamısı budur. Bunlar tamamilə fərqli iki dünyadır! Amma onların vəzifə adı eyni səslənir.
Bunu bir az fərqli şəkildə çevirək. Həqiqətən nəyi yaxşı bilirsiniz, çoxlu təcrübəniz var, istedadınız varmı? Tapşırığın öhdəsindən gələ biləcəyinizi düşündüyünüz üçün nəyə görə məsuliyyət götürəcəksiniz? Və burada kimsə dərhal inkar etməyə başlayacaq: yox, yox, yox, ümumiyyətlə layihə resursları ilə məşğul olmaq istəyim yoxdur, bu mənim işim deyil, mən texniki adamam və praktikliyi və istifadəçi interfeyslərini başa düşürəm, mən yox. ümumiyyətlə insan ordularını idarə etmək istəyirəm, icazə verin daha yaxşı işə gedim.
Yeri gəlmişkən, mən bacarıqların bu cür ayrılmasının yaxşı işlədiyi bir yanaşmanın böyük tərəfdarıyam. Texniklərin karyeralarını istədikləri qədər inkişaf etdirə biləcəkləri yer. Bununla belə, mən hələ də texniki işçilərin şikayət etdiyi təşkilatları görürəm: mən layihənin idarə edilməsinə getməli olacam, çünki bu şirkətdə yeganə yol budur. Bəzən bu, dəhşətli nəticələrə gətirib çıxarır. Ən yaxşı texniki mütəxəssislər heç də yaxşı menecer deyillər və ən yaxşı menecerlər texnologiyanın öhdəsindən gələ bilməzlər. Gəlin bu barədə səmimi olaq.
İndi buna böyük tələbat görürəm. Əgər siz texnoloqsunuzsa, şirkətiniz sizə kömək edə bilər, lakin bundan asılı olmayaraq, siz həqiqətən öz karyera yolunuzu tapmalısınız, çünki texnologiya daim dəyişir və siz onunla birlikdə özünüzü yenidən kəşf etməlisiniz! Cəmi iyirmi il ərzində texnologiyalar ən azı beş dəfə dəyişə bilər. Texnologiya qəribə bir şeydir...
"Hər şey üzrə ekspertlər"
Michael: İnsanlar texnologiya dəyişikliyinin bu qədər sürətinin öhdəsindən necə gələ bilər? Onların mürəkkəbliyi artır, sayı artır, insanlar arasında ünsiyyətin ümumi həcmi də artır və məlum olur ki, siz “hər şeydə mütəxəssis” ola bilməzsiniz.
Tim: Doğru! Əgər texnologiya sahəsində işləyirsinizsə, bəli, mütləq konkret bir şey seçməli və onu dərinləşdirməlisiniz. Təşkilatınızın faydalı hesab etdiyi bəzi texnologiya (və bəlkə də əslində faydalı olacaq). Əgər artıq bununla maraqlanmırsınızsa - bunu deyəcəyimə heç vaxt inanmazdım - yaxşı, bəlkə də texnologiyanın daha maraqlı və ya öyrənmək üçün daha əlverişli olduğu başqa bir təşkilata keçməlisiniz.
Amma ümumiyyətlə, bəli, haqlısınız. Texnologiyalar bir anda bütün istiqamətlərdə böyüyür, heç kim “mən mövcud olan bütün texnologiyalar üzrə ekspert texnoloqam” deyə bilməz. Digər tərəfdən, texnoloji bilikləri sözün əsl mənasında mənimsəyən və buna dəli olan süngər insanlar var. Mən bir neçə belə insan görmüşəm, onlar sözün əsl mənasında nəfəs alır və bunu yaşayırlar, onlarla danışmaq faydalı və maraqlıdır. Onlar nəinki təşkilat daxilində baş verənləri öyrənirlər, ümumiyyətlə, bu barədə danışırlar, həm də həqiqətən sərin texnoloqlardır, çox şüurlu və məqsədyönlüdürlər. Əsas işlərinin nə olmasından asılı olmayaraq, sadəcə olaraq dalğanın zirvəsində qalmağa çalışırlar, çünki onların həvəsi Texnologiyanın hərəkəti, texnologiyanın təbliğidir. Birdən belə bir insanla qarşılaşsanız, onunla nahara getməli və naharda müxtəlif sərin şeyləri müzakirə etməlisiniz. Düşünürəm ki, istənilən təşkilatda ən azı bir-iki belə adam lazımdır.
Risklər və qeyri-müəyyənlik
Michael: Əməkdar mühəndislər, bəli. Vaxtımız olanda risklərin idarə edilməsinə toxunaq. Bu müsahibəyə tibbi proqram təminatının müzakirəsi ilə başladıq, burada səhvlər dəhşətli nəticələrə səbəb ola bilər. Sonra bir səhvin dəyəri milyonlarla dollar və bəlkə də bir neçə insan həyatı olan Ay Proqramı haqqında danışdıq. Amma indi sənayedə əks hərəkət görürəm, insanlar risklər haqqında düşünmürlər, onları proqnozlaşdırmağa çalışmırlar, hətta müşahidə etmirlər.
Oleq: Sürətlə hərəkət edin və əşyaları qırın!
Michael: Bəli, bir şeydən ölənə qədər sürətli hərəkət edin, hər şeyi qırın, daha çox şey. Sizin nöqteyi-nəzərincə, orta inkişaf etdirici indi risklərin idarə edilməsini öyrənməyə necə yanaşmalıdır?
Tim: Gəlin burada iki şey arasında bir xətt çəkək: risklər və qeyri-müəyyənlik. Bunlar fərqli şeylərdir. Qeyri-müəyyənlik, qəti cavaba gəlmək üçün hər hansı bir zamanda kifayət qədər məlumatınız olmadıqda baş verir. Məsələn, layihənin ən erkən mərhələsində kimsə sizdən “işi nə vaxt bitirəcəksiniz” deyə soruşsa, kifayət qədər dürüst insansınızsa, “heç bir fikrim yoxdur” deyəcəksiniz. Siz sadəcə bilmirsiniz və bu, yaxşıdır. Siz hələ problemləri öyrənməmisiniz və komanda ilə tanış deyilsiniz, onların bacarıqlarını bilmirsiniz və s. Bu qeyri-müəyyənlikdir.
Potensial problemləri artıq müəyyən etmək mümkün olduqda risklər yaranır. Bu cür şey ola bilər, onun ehtimalı sıfırdan böyükdür, amma yüz faizdən azdır, aralarında bir yerdə. Buna görə gecikmələrdən və lazımsız işlərdən tutmuş layihə üçün ölümcül nəticəyə qədər hər şey ola bilər. Nəticə, siz deyəndə - uşaqlar, gəlin çətirlərimizi qatlayaq və çimərliyi tərk edək, bunu heç vaxt bitirməyəcəyik, hər şey bitdi, dövr. Bu şeyin işləyəcəyini fərz etdik, amma heç işləmir, dayanmağın vaxtı gəldi. Bu vəziyyətlərdir.
Çox vaxt problemlər artıq ortaya çıxdıqda, problem hazırda baş verəndə həll etmək daha asandır. Ancaq qarşınızda problem olanda siz risklərin idarə edilməsi ilə məşğul olmursunuz - problemin həlli, böhranın idarə edilməsi ilə məşğul olursunuz. Əgər siz aparıcı tərtibatçı və ya menecersinizsə, gecikmələrə, vaxt itkisinə, lazımsız xərclərə və ya bütün layihənin dağılmasına səbəb ola biləcək nə baş verə biləcəyi ilə maraqlanmalısınız? Bizi dayandırıb yenidən başlamağa nə vadar edəcək? Bütün bunlar işlədikdə, biz onlarla nə edəcəyik? Əksər vəziyyətlər üçün etibarlı olan sadə bir cavab var: risklərdən qaçmayın, onların üzərində işləyin. Riskli bir vəziyyəti necə həll edə biləcəyinizi görün, onu heçə endirə bilərsiniz, problemdən başqa bir şeyə çevirə bilərsiniz. Demək əvəzinə: yaxşı, problemləri ortaya çıxan kimi həll edəcəyik.
Qarşılaşdığınız hər şeydə qeyri-müəyyənlik və risk ön planda olmalıdır. Siz layihə planını götürə, müəyyən kritik risklərə əvvəlcədən baxa və deyə bilərsiniz: biz bununla indi məşğul olmalıyıq, çünki bunlardan hər hansı biri səhv olarsa, başqa heç nə əhəmiyyət kəsb etməyəcək. Axşam yeməyi bişirə biləcəyiniz bəlli deyilsə, masanın üstündəki süfrənin gözəlliyindən narahat olmamalısınız. Əvvəlcə ləzzətli bir şam yeməyi hazırlamaq üçün bütün riskləri müəyyən etməli, onlarla məşğul olmalı və yalnız bundan sonra real təhlükə yaratmayan bütün digər şeylər barədə düşünməlisiniz.
Yenə də layihənizi unikal edən nədir? Gəlin görək layihəmizi relsdən kənarlaşdıran nə ola bilər. Bunun baş vermə ehtimalını minimuma endirmək üçün nə edə bilərik? Adətən siz onları 100% zərərsizləşdirə və təmiz vicdanla bəyan edə bilməzsiniz: “Belədir, bu artıq problem deyil, risk həll olundu!” Mənə görə bu, böyüklərin davranışının əlamətidir. Uşağın böyükdən fərqi budur - uşaqlar elə bilirlər ki, ölümsüzdürlər, heç bir şey yolunda getməz, hər şey yaxşı olacaq! Eyni zamanda, böyüklər üç yaşlı uşaqların oyun meydançasına necə tullandığını, hərəkətləri gözləri ilə izlədiklərini və özlərinə "ooh-ooh, ooh-ooh" dediklərini izləyirlər. Mən yaxınlıqda dayanıb uşaq yıxılanda tutmağa hazırlaşıram.
Digər tərəfdən, bu işi bu qədər bəyənməyimin səbəbi riskli olmasıdır. Biz işlər görürük və bunlar risklidir. Onlar bir yetkin yanaşma tələb edir. Təkcə həvəs sizin problemlərinizi həll etməyəcək!
Yetkinlərin mühəndis düşüncəsi
Michael: Uşaqlarla nümunə yaxşıdır. Əgər mən adi mühəndisəmsə, deməli uşaq olmaqdan məmnunam. Ancaq daha çox yetkin düşüncəyə doğru necə hərəkət edirsiniz?
Tim: İstər yeni başlayan, istərsə də qurulmuş tərtibatçı ilə eyni dərəcədə yaxşı işləyən ideyalardan biri kontekst anlayışıdır. Nə edirik, nəyə nail olacağıq. Bu layihədə həqiqətən vacib olan nədir? Bu layihədə kim olduğunuzun fərqi yoxdur, istər təcrübəçi, istərsə də baş memar, hər kəsin kontekstə ehtiyacı var. Hər kəsi öz işindən daha geniş miqyasda düşünməyə vadar etməliyik. "Mən əsərimi düzəldirəm və nə qədər ki əsərim işləyirsə, xoşbəxtəm." Yox və yenə yox. İnsanlara işlədikləri konteksti xatırlatmağa həmişə dəyər (kobudluq etmədən!). Hamımız birlikdə nəyə nail olmağa çalışırıq. Layihənizdə hər şey qaydasında olduğu müddətcə uşaq ola biləcəyiniz ideyalar - lütfən, bunu etməyin. Əgər finiş xəttini ümumiyyətlə keçsək, onu yalnız birlikdə keçəcəyik. Sən tək deyilsən, biz hamımız bir yerdəyik. Layihədəki bütün insanlar, istər yaşlı, istərsə də gənc, layihə üçün nəyin vacib olduğunu, şirkətin niyə hamımızın nail olmağa çalışdığı şeyə pul yatırdığını danışmağa başlasalar... onların çoxu özlərini daha yaxşı hiss edəcəklər, çünki onlar onların işinin başqalarının işi ilə necə əlaqəli olduğunu görəcəklər. Bir tərəfdən şəxsən məsuliyyət daşıdığım əsəri başa düşürəm. Ancaq işi başa çatdırmaq üçün bütün digər insanlara da ehtiyacımız var. Və həqiqətən işin bitdiyini düşünürsənsə, layihədə həmişə görüləsi işlərimiz var!
Oleq: Nisbətən desək, Kanbana uyğun işləsəniz, bəzi testlərin darboğazına düşdüyünüz zaman orada etdiyiniz işdən (məsələn, proqramlaşdırmadan) çıxa və test edənlərə kömək edə bilərsiniz.
Tim: Tam olaraq. Düşünürəm ki, ən yaxşı texnoloqlar, onlara yaxından baxsanız, onlar bir növ öz menecerləridir. Bunu necə formalaşdırmaq olar...
Oleq: Həyatınız idarə etdiyiniz layihənizdir.
Tim: Tam olaraq! Demək istədiyim odur ki, siz məsuliyyəti öz üzərinizə götürürsünüz, məsələni başa düşürsünüz və qərarlarınızın onların işinə təsir edə biləcəyini, bu kimi şeyləri görəndə insanlarla təmasda olursunuz. Söhbət yalnız masanızda oturmaq, işinizi görmək və hətta ətrafınızda baş verənləri dərk etməməkdən getmir. yox yox yox. Yeri gəlmişkən, Agile-nin ən yaxşı cəhətlərindən biri onların qısa sprintlər təklif etməsidir, çünki bu yolla bütün iştirakçıların vəziyyəti aydın şəkildə müşahidə olunur, onlar hamısını birlikdə görə bilirlər. Hər gün bir-birimizdən danışırıq.
Risklərin idarə edilməsinə necə girmək olar
Oleq: Bu sahədə hər hansı formal bilik strukturu varmı? Məsələn, mən Java proqramçısıyam və təhsillə real layihə meneceri olmadan risklərin idarə edilməsini başa düşmək istəyirəm. Yəqin ki, əvvəlcə McConnell-in “Bir proqram layihəsinin dəyəri nə qədərdir” əsərini oxuyacağam, sonra nə olacaq? İlk addımlar hansılardır?
Tim: Birincisi, layihədəki insanlarla ünsiyyətə başlamaqdır. Bu, həmkarları ilə ünsiyyət mədəniyyətinin dərhal təkmilləşdirilməsini təmin edir. Hər şeyi gizlətmək əvəzinə, standart olaraq açmaqla başlamalıyıq. De ki: bunlar məni narahat edən şeylərdir, məni gecələr oyadanlar bunlardır, bu gün gecə oyandım və belə oldum: Allahım, bu haqda fikirləşməliyəm! Başqaları da eyni şeyi görürmü? Qrup olaraq bu potensial problemlərə cavab verməliyikmi? Bu mövzularda müzakirəyə dəstək olmağı bacarmalısınız. Bizim işlədiyimiz əvvəlcədən hazırlanmış formula yoxdur. Hamburger hazırlamaq deyil, hər şey insanlardır. “Çizburqer etdim, çizburger sat” bizim işimiz deyil və buna görə də bu işi çox sevirəm. Menecerlərin əvvəllər etdiyi hər şeyin indi komandanın mülkiyyətinə çevrilməsi xoşuma gəlir.
Oleq: Kitablarda və müsahibələrdə insanların qrafikdəki rəqəmlərdən daha çox xoşbəxtliyə əhəmiyyət verməsindən danışmısınız. Digər tərəfdən, komandaya dediyiniz zaman: biz devops-a keçirik və indi proqramçı daim əlaqə saxlamalıdır, bu, onun rahatlıq zonasından çox uzaqda ola bilər. Və bu anda, deyək ki, dərin bədbəxt ola bilər. Bu vəziyyətdə nə etməli?
Tim: Mən dəqiq nə edəcəyimi bilmirəm. Əgər tərtibatçı çox təcrid olunubsa, onlar ilk növbədə işin niyə görüldüyünü görmürlər, sadəcə olaraq işin öz hissəsinə baxırlar və mənim “kontekst” adlandırdığım şeyə daxil olmalıdırlar. O, hər şeyin bir-birinə necə bağlı olduğunu başa düşməlidir. Və təbii ki, mən rəsmi təqdimatlar və ya buna bənzər bir şeyi nəzərdə tutmuram. Mən ondan danışıram ki, siz həmkarlarınızla işin təkcə məsuliyyət daşıdığınız hissəsi haqqında deyil, bütövlükdə iş haqqında ünsiyyət qurmalısınız. Burada ideyaları müzakirə etməyə, işinizi bir-birinə yaxşı uyğunlaşdırmaq üçün ümumi razılaşmalara və ümumi problemi birlikdə həll etməyə başlaya bilərsiniz.
Onlara uyğunlaşmaqda kömək etmək üçün onlar tez-tez texnoloqları təlimə göndərmək istəyirlər və onlar təlimləri müzakirə edirlər. Bir dostum təlimin itlər üçün olduğunu söyləməyi xoşlayır. İnsanlar üçün təlim var. Tərtibatçı kimi öyrənməklə bağlı ən yaxşı şeylərdən biri həmyaşıdlarınızla ünsiyyət qurmaqdır. Əgər kimsə bir şeydə həqiqətən yaxşıdırsa, onun işini izləməli və ya işi və ya başqa bir şey haqqında danışmalısınız. Bəzi ənənəvi Kent Beck daim ekstremal proqramlaşdırma haqqında danışırdı. Bu gülməli, çünki XP çox sadə bir fikirdir, lakin çoxlu problemlərə səbəb olur. Bəziləri üçün XP etmək dostların qarşısında çılpaq soyunmağa məcbur olmaq kimidir. Nə etdiyimi görəcəklər! Onlar mənim həmkarlarımdır, nəinki görəcəklər, həm də başa düşəcəklər! Dəhşətli! Bəzi insanlar ciddi əsəbləşməyə başlayır. Ancaq bunun öyrənməyin son yolu olduğunu başa düşəndə hər şey dəyişir. İnsanlarla yaxından işləyirsiniz və bəzi insanlar mövzunu sizdən daha yaxşı başa düşürlər.
Michael: Ancaq bütün bunlar sizi rahatlıq zonanızdan çıxmağa məcbur edir. Mühəndis olaraq rahatlıq zonanızdan çıxmalı və ünsiyyət qurmalısınız. Problemi həll edən biri olaraq, özünüzü daim zəif vəziyyətə salmalı və nəyin səhv ola biləcəyini düşünməlisiniz. Bu tip iş mahiyyət etibarı ilə narahatlıq yaratmaq üçün nəzərdə tutulmuşdur. Özünüzü şüurlu olaraq stresli vəziyyətlərə salırsınız. Adətən insanlar onlardan qaçır, insanlar xoşbəxt uşaq olmağı sevirlər.
Tim: Nə etmək olar, çıxıb açıq deyə bilərsiniz: “Hər şey qaydasındadır, öhdəsindən gələ bilərəm! Özümü narahat hiss edən tək mən deyiləm. Gəlin bir komanda olaraq müxtəlif xoşagəlməz şeyləri müzakirə edək!” Bunlar bizim ümumi problemlərimizdir, biz onlarla məşğul olmalıyıq, bilirsinizmi? Düşünürəm ki, idiosinkratik dahi tərtibatçılar mamontlara bənzəyirlər, onlar yoxa çıxıblar. Və onların əhəmiyyəti çox məhduddur. Ünsiyyət qura bilmirsinizsə, yaxşı iştirak edə bilməzsiniz. Ona görə də sadəcə danış. Dürüst və açıq olun. Çox təəssüf edirəm ki, bu, kimsə üçün xoşagəlməzdir. Təsəvvür edirsiniz, illər əvvəl ABŞ-da əsas qorxunun ölüm olmadığı bir araşdırma var idi, amma təxmin edə bilərsinizmi? Xalq qarşısında çıxış etmək qorxusu! Bu o deməkdir ki, haradasa yüksək səslə kompliment deməkdənsə ölməyi üstün tutan insanlar var. Düşünürəm ki, gördüyünüz işdən asılı olaraq bəzi əsas bacarıqlara sahib olmağınız kifayətdir. Danışıq bacarıqları, yazı bacarıqları - ancaq işinizdə həqiqətən lazım olan qədər. Əgər siz analitik işləyirsinizsə, amma oxuya, yaza və danışa bilmirsinizsə, o zaman təəssüf ki, mənim layihələrimdə heç bir işiniz olmayacaq!
Rabitə qiyməti
Oleq: Belə gedən işçiləri işə götürmək müxtəlif səbəblərdən baha başa gəlmirmi? Axı onlar işləmək əvəzinə daim söhbət edirlər!
Tim: Mən komandanın özəyini nəzərdə tuturdum, nəinki hamını. Əgər verilənlər bazalarını tənzimləməkdə həqiqətən əla olan, verilənlər bazalarını tənzimləməyi sevən və ömrünün qalan hissəsi üçün verilənlər bazalarınızı tənzimləməyə davam edəcək kimsə varsa və bu, sərin, davam edin. Amma mən layihənin özündə yaşamaq istəyən insanlardan danışıram. Layihəni inkişaf etdirməyə yönəlmiş komandanın əsası. Bu insanlar həqiqətən bir-biri ilə daim ünsiyyətdə olmalıdırlar. Xüsusilə də layihənin əvvəlində riskləri, qlobal məqsədlərə nail olmaq yollarını və sairələri müzakirə edərkən.
Michael: Bu, ixtisasından, bacarıqlarından və iş üsullarından asılı olmayaraq layihədə iştirak edən hər kəsə aiddir. Hamınız layihənin uğuru ilə maraqlanırsınız.
Tim: Bəli, siz layihəyə kifayət qədər qərq olduğunuzu, vəzifənizin layihənin gerçəkləşməsinə kömək etmək olduğunu hiss edirsiniz. İstər proqramçı, istər analitik, istər interfeys dizayneri, istərsə də hər kəs. Hər səhər işə gəlməyimin səbəbi və etdiyimiz budur. Bacarıqlarından asılı olmayaraq bütün bu insanlara cavabdehik. Bu, böyüklər arasında söhbət edən insanlar qrupudur.
Oleq: Əslində, danışan işçilər haqqında danışarkən, insanların, xüsusən də menecerlərin devoplara keçməsi xahiş olunan bu tamamilə yeni dünya görüşünə etirazlarını simulyasiya etməyə çalışdım. Və siz, məsləhətçilər olaraq, bu etirazları bir tərtibatçı olaraq məndən daha yaxşı bilməlisiniz! Menecerləri ən çox nə narahat edir?
Tim: Menecerlər? Hm. Çox vaxt menecerlər problemlərdən təzyiq altında olurlar, təcili olaraq bir şey buraxmaq və çatdırmaq və s. Bir şeyi davamlı olaraq necə müzakirə edib mübahisə etdiyimizi izləyirlər və bunu belə görürlər: söhbətlər, söhbətlər, söhbətlər... Daha nə söhbətlər? İşə qayıt! Çünki danışmaq onlara iş kimi gəlmir. Siz kod yazmırsınız, proqram təminatını sınaqdan keçirmirsiniz, deyəsən heç nə etmirsiniz - niyə sizi bir şey etməyə göndərmirsiniz? Axı, çatdırılma artıq bir aydır!
Michael: Get bir kod yaz!
Tim: Mənə elə gəlir ki, onları iş yox, tərəqqinin görünməməsi narahat edir. Uğura yaxınlaşdığımız kimi görünmək üçün onlar bizi klaviaturada düymələrə basdığımızı görməlidirlər. Bütün gün səhərdən axşama qədər. Bu bir nömrəli problemdir.
Oleq: Misha, sən nəsə fikirləşirsən.
Michael: Bağışlayın, fikrə daldım və bir flashback aldım. Bütün bunlar mənə dünən baş verən maraqlı mitinqi xatırlatdı... Dünən çoxlu mitinqlər oldu... Və hamısı çox tanış səslənir!
Maaşsız həyat
Tim: Yeri gəlmişkən, ünsiyyət üçün “mitinqlər” təşkil etmək heç də lazım deyil. Demək istədiyim odur ki, tərtibatçılar arasında ən faydalı müzakirələr yalnız bir-biri ilə danışdıqları zaman baş verir. Səhər bir fincan kofe ilə içəri girirsən və orada beş nəfər toplanıb, texniki bir şeyi şiddətlə müzakirə edir. Mənim üçün bu layihənin meneceriyəmsə, yaxşı olar ki, sadəcə gülümsəyim və işimlə bağlı harasa gedim, qoy bunu müzakirə etsinlər. Onlar artıq mümkün qədər cəlb olunublar. Bu yaxşı əlamətdir.
Oleq: Yeri gəlmişkən, kitabınızda nəyin yaxşı, nəyin pis olduğu barədə bir dəstə qeyd var. Onlardan hər hansı birini özünüz istifadə edirsiniz? Nisbətən desək, indi sizin çox qeyri-adi şəkildə qurulmuş bir şirkətiniz var...
Tim: Qeyri-adi, lakin bu cihaz bizə mükəmməl uyğun gəlir. Biz bir-birimizi çoxdan tanıyırıq. Biz bir-birimizə güvənirik, tərəfdaş olana qədər bir-birimizə çox güvənirdik. Və məsələn, bizdə ümumiyyətlə maaş yoxdur. Biz sadəcə işləyirik və məsələn, müştərilərimdən pul qazanmışamsa, o zaman bütün pullar mənə gedib. Bundan sonra təşkilata üzvlük haqqı ödəyirik və bu, şirkətin özünü saxlamağa kifayət edir. Üstəlik, hamımız fərqli şeylərdə ixtisaslaşırıq. Məsələn, mən mühasiblərlə işləyirəm, vergi bəyannamələrini doldururam, şirkət üçün hər cür inzibati işlər görürəm və bunun üçün mənə heç kim pul vermir. James və Tom veb saytımızda işləyirlər və heç kim onlara pul ödəmir. Haqqınızı ödədiyiniz müddətcə heç kim sizə nə etməli olduğunuzu söyləməyi düşünməyəcək. Məsələn, Tom indi əvvəlkindən daha az işləyir. İndi onun başqa maraqları var; o, Gildiya üçün deyil, bəzi işləri görür. Amma nə qədər ki, haqqını ödəyir, heç kim onun yanına gəlib “Hey, Tom, işə get!” deməyəcək. Aranızda pul olmayanda həmkarlarla məşğul olmaq çox asandır. İndi isə bizim münasibətimiz müxtəlif ixtisaslara münasibətdə əsas ideyalardan biridir. Bu işləyir və çox yaxşı işləyir.
ən yaxşı məsləhət
Michael: “Ən yaxşı məsləhətə” qayıdaraq, müştərilərinizə təkrar-təkrar dediyiniz bir şey varmı? 80/20 haqqında bir fikir var və bəzi məsləhətlər yəqin ki, daha tez-tez təkrarlanır.
Tim: Bir dəfə düşünürdüm ki, sən “Ayılarla vals” kimi bir kitab yazsan, bu, tarixin gedişatını dəyişəcək və insanlar dayanacaq, amma... Bax, şirkətlər tez-tez elə göstərirlər ki, onlarla hər şey qaydasındadır. Pis bir şey baş verən kimi onlar üçün şok və sürpriz olur. “Bax, biz sistemi sınaqdan keçirdik və o, heç bir sistem testindən keçmir və bu, daha üç aylıq plansız işdir, bu necə baş verə bilər? Kim bilirdi? Nə səhv ola bilər? Ciddi, sən buna inanırsan?
Mən izah etməyə çalışıram ki, mövcud vəziyyətə görə çox da qəzəblənməməlisən. Biz bunu müzakirə etməliyik, nəyin səhv ola biləcəyini və gələcəkdə belə şeylərin baş verməsinin qarşısını necə alacağımızı başa düşməliyik. Əgər problem yaranarsa, onunla necə mübarizə aparacağıq, onu necə tutacağıq?
Mənə görə bütün bunlar qorxulu görünür. İnsanlar mürəkkəb, cansıxıcı problemlərlə məşğul olurlar və elə iddia etməyə davam edirlər ki, əgər barmaqlarını keçib ən yaxşısına ümid etsələr, əslində “ən yaxşı” baş verəcək. Xeyr, bu belə işləmir.
Risklərin idarə edilməsi ilə məşğul olun!
Michael: Sizcə, risklərin idarə edilməsi ilə neçə təşkilat məşğul olur?
Tim: Məni qəzəbləndirən odur ki, insanlar sadəcə olaraq riskləri yazıb ortaya çıxan siyahıya baxıb işə gedirlər. Əslində, onlar üçün riskləri müəyyən etmək riskin idarə edilməsidir. Amma mənə bu sual vermək üçün səbəb kimi səslənir: yaxşı, siyahı var, dəqiq nəyi dəyişəcəksiniz? Bu riskləri nəzərə alaraq standart hərəkət ardıcıllığınızı dəyişdirməlisiniz. Əgər işin ən çətin hissəsi varsa, onun öhdəsindən gəlmək lazımdır və yalnız bundan sonra daha sadə bir işə keçməlisiniz. İlk sprintlərdə mürəkkəb problemləri həll etməyə başlayın. Bu, artıq risklərin idarə olunması kimi görünür. Amma adətən insanlar risklərin siyahısını tərtib etdikdən sonra nəyi dəyişdiklərini deyə bilmirlər.
Michael: Yenə də bu şirkətlərdən neçəsi risklərin idarə edilməsində iştirak edir, beş faiz?
Tim: Təəssüf ki, bunu deməyə nifrət edirəm, amma bu çox əhəmiyyətsiz bir hissədir. Ancaq beşdən çox, çünki həqiqətən böyük layihələr var və heç olmasa bir şey etməsələr, mövcud ola bilməzlər. Deyək ki, ən azı 25% olsa, çox təəccüblənəcəyəm. Kiçik layihələr adətən belə suallara belə cavab verir: əgər problem bizə təsir edirsə, o zaman biz onu həll edəcəyik. Sonra müvəffəqiyyətlə problemə girirlər və problemin idarə edilməsi və böhranın idarə edilməsi ilə məşğul olurlar. Problemi həll etməyə çalışdığınız zaman və problem həll edilmədikdə, böhran idarəçiliyinə xoş gəlmisiniz.
Bəli, tez-tez eşidirəm ki, “problemlər yarandıqca həll edəcəyik”. Şübhəsiz ki, edəcəyik? Həqiqətən qərar verəcəyik?
Oleq: Siz bunu sadəlövhlüklə edə bilərsiniz və sadəcə olaraq layihə nizamnaməsinə mühüm invariantları yaza bilərsiniz və əgər invariantlar pozularsa, sadəcə olaraq layihəni yenidən başladın. Çox pis çıxır.
Michael: Bəli, mənim başıma gəldi ki, risklər işə salındıqda, layihə sadəcə olaraq yenidən təyin olundu. Əla, bingo, problem həll olundu, daha narahat olmayın!
Tim: Gəlin sıfırlama düyməsini sıxaq! Xeyr, bu belə işləmir.
DevOops 2019-da əsas söz
Michael: Gəldik bu müsahibənin son sualına. Növbəti DevOops-a əsas sözlə gəlirsiniz, deyəcəklərinizlə bağlı məxfilik pərdəsini qaldıra bilərsinizmi?
Tim: Hazırda onlardan altısı iş mədəniyyəti, təşkilatların danışılmamış qaydaları haqqında kitab yazır. Mədəniyyət təşkilatın əsas dəyərləri ilə müəyyən edilir. Adətən insanlar bunu hiss etmirlər, amma uzun illər konsaltinqdə işlədiyimiz üçün biz bunu hiss etməyə öyrəşmişik. Bir şirkətə girirsiniz və sözün əsl mənasında bir neçə dəqiqə ərzində nə baş verdiyini hiss etməyə başlayırsınız. Biz buna "ləzzət" deyirik. Bəzən bu qoxu həqiqətən yaxşıdır, bəzən də, yaxşı, oops. Fərqli təşkilatlar üçün hər şey çox fərqlidir.
Michael: Mən də illərdir konsaltinq sahəsində çalışıram və nə danışdığınızı yaxşı başa düşürəm.
Tim: Əslində, əsas çıxışda danışmağa dəyər olan şeylərdən biri odur ki, hər şey şirkət tərəfindən müəyyən edilmir. Siz və komandanız bir icma olaraq öz komanda mədəniyyətinə sahibsiniz. Bu, bütün şirkət və ya ayrı bir şöbə, ayrı bir komanda ola bilər. Amma sən deməmişdən əvvəl, inandığımız budur, vacib olan budur... Konkret hərəkətlərin arxasındakı dəyərlər və inanclar başa düşülməmiş bir mədəniyyəti dəyişdirə bilməzsiniz. Davranışı müşahidə etmək asandır, amma inancları axtarmaq çətindir. DevOps, işlərin getdikcə daha da mürəkkəbləşdiyinin sadəcə gözəl nümunəsidir. Qarşılıqlı əlaqələr daha da mürəkkəbləşir, onlar daha təmiz və ya heç də aydınlaşmır, ona görə də nəyə inandığınız və ətrafınızdakı hər kəsin nəyə susur olduğu barədə düşünməlisiniz.
Tez nəticələr əldə etmək istəyirsinizsə, sizə yaxşı bir mövzu var: heç kimin “bilmirəm” demədiyi şirkətləri görmüsünüzmü? Elə yerlər var ki, insan nəyisə bilmədiyini etiraf edənə qədər işgəncə verirsən. Hər kəs hər şeyi bilir, hər kəs inanılmaz bir eruditdir. İstənilən şəxsə yaxınlaşırsınız və o, suala dərhal cavab verməlidir. “Bilmirəm” demək əvəzinə. Yaşasın, bir dəstə erudit işə götürdülər! Bəzi mədəniyyətlərdə “bilmirəm” demək ümumiyyətlə çox təhlükəlidir, bunu zəiflik əlaməti kimi qəbul etmək olar. Elə təşkilatlar da var ki, orada əksinə, hamı “bilmirəm” deyə bilər. Orada bu, tamamilə qanunidir və kimsə suala cavab olaraq zibilləməyə başlayırsa, cavab vermək tamamilə normaldır: "Sən nə danışdığını bilmirsən, elə deyilmi?" və hamısını zarafata çevirin.
İdeal olaraq, daim xoşbəxt ola biləcəyiniz bir işə sahib olmaq istərdiniz. Bu asan olmayacaq, hər gün günəşli və xoş keçmir, bəzən çox çalışmaq lazımdır, amma hesablaşmağa başlayanda belə çıxacaq: vay, bura həqiqətən gözəl yerdir, burada işləmək özümü yaxşı hiss edir, həm emosional, həm də intellektual. Və elə şirkətlər var ki, orada məsləhətçi kimi gedirsən və dərhal başa düşürsən ki, üç ay dözə bilməyəcəksən və dəhşət içində qaçacaqsan. Hesabatda bu haqda danışmaq istəyirəm.
Tim Lister çıxış edəcək 2019-29 oktyabr 30-cu il tarixlərində Sankt-Peterburqda keçiriləcək DevOops 2019 konfransına. Biletləri əldə edə bilərsiniz . Sizi DevOops-da gözləyirik!
Mənbə: www.habr.com