Тим Листер - кітаптардың бірлескен авторы
- «Адам факторы. Табысты жобалар мен командалар» (түпнұсқа кітап «Peopleware» деп аталады)
- «Аюлармен вальс: бағдарламалық жасақтама жобаларындағы тәуекелді басқару»
- «Адреналинге толы және өрнектермен зомбиленген. Жоба командаларының мінез-құлық үлгілері»
Бұл кітаптардың барлығы өз саласындағы классиктер және әріптестерімен бірге жазылған . Ресейде оның әріптестері ең танымал - и , ол да көптеген атақты шығармалар жазды.
Тимнің бағдарламалық жасақтаманы әзірлеуде 40 жылдық тәжірибесі бар; 1975 жылы (осы хабрапостты жазғандардың ешқайсысы осы жылы дүниеге келген жоқ), Тим қазірдің өзінде Yourdon Inc атқарушы вице-президенті болды. Ол енді уақытын кеңес беруге, оқытуға және жазуға арнайды, анда-санда барып тұрады дүние жүзіндегі конференциялар.
Біз Хабр үшін Тим Листермен сұхбат жасадық. Ол DevOops 2019 конференциясын ашады және бізде кітаптар туралы және т.б. сұрақтар көп. Сұхбатты конференцияның бағдарламалық комитетінен Михаил Дружинин мен Олег Чирухин жүргізеді.
Майкл: Қазір не істеп жатқаныңыз туралы бірнеше сөз айта аласыз ба?
Тим: Мен Атлантикалық жүйелер гильдиясының басшысымын. Гильдияда алты адамбыз, өзімізді директор дейміз. Үшеуі АҚШ-та және үшеуі Еуропада - сондықтан гильдия Атлантикалық деп аталады. Екеуміздің бірге болғанымыз сонша, оларды санау мүмкін емес. Әрқайсымыздың өз мамандығымыз бар. Мен соңғы онжылдықта немесе одан да көп клиенттермен жұмыс істеймін. Менің жобаларым тек басқаруды ғана емес, сонымен қатар талаптарды орнатуды, жобаны жоспарлауды және бағалауды қамтиды. Нашар басталған жобалар әдетте нашар аяқталатын сияқты. Сондықтан барлық іс-шаралар шынымен жақсы ойластырылған және үйлестірілген, жасаушылардың идеялары біріктірілгеніне көз жеткізген жөн. Не істеп жатқаныңызды және не үшін істеп жатқаныңызды ойлаған жөн. Жобаны аяқтау үшін қандай стратегияларды қолдану керек.
Мен көптеген жылдар бойы клиенттерге әртүрлі тәсілдермен кеңес бердім. Қызықты мысал - тізе және жамбас хирургиясы үшін роботтар жасайтын компания. Хирург толығымен дербес операция жасамайды, роботты пайдаланады. Бұл жерде, шынын айтқанда, қауіпсіздік маңызды. Бірақ сіз проблемаларды шешуге бағытталған адамдармен талаптарды талқылауға тырысқанда... Бұл біртүрлі естіледі, бірақ АҚШ-та бар. (Федералдық дәрі-дәрмек басқармасы) осы роботтар сияқты өнімдерге лицензия береді. Кез келген нәрсені сатып, оны тірі адамдарға қолданбас бұрын лицензия алу керек. Шарттардың бірі - талаптарыңызды, қандай сынақтар бар, оларды қалай тексердіңіз, тест нәтижелері қандай екенін көрсету. Егер сіз талаптарды өзгертсеңіз, онда сіз осы үлкен сынақ процесін қайта-қайта өтуіңіз керек. Біздің клиенттер өз талаптарында қосымшалардың визуалды дизайнын қоса алды. Олар талаптардың бір бөлігі ретінде тікелей скриншоттарға ие болды. Біз оларды шығарып, осы бағдарламалардың көпшілігі тізе мен жамбас туралы ештеңе білмейтінін түсіндіруіміз керек, мұның бәрі камерамен және т.б. Кейбір шын мәнінде маңызды негізгі шарттар өзгермейінше, талаптар құжаттарын олар ешқашан өзгермейтіндей етіп қайта жазуымыз керек. Көрнекі дизайн талаптарға сай болмаса, өнімді жаңарту әлдеқайда жылдам болады. Біздің жұмысымыз - тізе, жамбас, арқадағы операцияларға қатысты элементтерді тауып, оларды бөлек құжаттарға шығарып, бұл негізгі талаптар болатынын айту. Тізе операциялары туралы оқшауланған талаптар тобын жасайық. Бұл бізге неғұрлым тұрақты талаптар кешенін құруға мүмкіндік береді. Біз нақты роботтар туралы емес, бүкіл өнім желісі туралы сөйлесетін боламыз.
Көптеген жұмыс жасалды, бірақ олар бұрынғысынша мағынасыз немесе қажетсіз апталар мен айлар қайталанатын сынақтарды өткізген жерлерге жетті, өйткені олардың қағазда сипатталған талаптары жүйелер салынған нақты талаптарға сәйкес келмеді. FDA оларға әр уақытта айтты: сіздің талаптарыңыз өзгерді, енді бәрін нөлден бастап тексеру керек. Бүкіл өнімді толық қайта тексеру кәсіпорынды өлтірді.
Сонымен, сіз өзіңізді қызықты нәрсенің басында тапсаңыз, осындай тамаша тапсырмалар бар және ең алғашқы әрекеттер ойынның одан әрі ережелерін белгілейді. Егер сіз бұл ерте әрекеттің басқарушылық және техникалық тұрғыдан жақсы жұмыс істей бастайтынына көз жеткізсеңіз, сізде керемет жобаға қол жеткізуге мүмкіндік бар. Бірақ егер бұл бөлік рельстен шығып, бір жерде дұрыс емес болса, іргелі келісімдерді таба алмасаңыз... жоқ, бұл сіздің жобаңыз міндетті түрде сәтсіздікке ұшырайды деген сөз емес. Бірақ сіз енді: «Біз керемет жасадық, біз барлығын шынымен де тиімді жасадық» деп айта алмайсыз. Клиенттермен қарым-қатынас жасағанда мен мұны істеймін.
Майкл: Яғни, сіз жобаларды іске қосасыз, қандай да бір бастама жасайсыз және рельстердің дұрыс бағытта келе жатқанын тексересіз бе?
Тим: Бізде басқатырғыштың барлық бөліктерін қалай біріктіру керектігі туралы идеялар бар: бізге қандай дағдылар қажет, олар нақты қашан қажет, команданың өзегі қалай көрінеді және басқа да осындай негізгі нәрселер. Бізге толық уақытты жұмысшылар керек пе немесе біреуді толық емес жұмыс күнімен жалдай аламыз ба? Жоспарлау, басқару. Сұрақтар: Бұл нақты жоба үшін ең маңыздысы не? Бұған қалай қол жеткізуге болады? Біз бұл өнім немесе жоба туралы не білеміз, қандай қауіптер бар және белгісіздер қайда жатыр, біз мұның бәрімен қалай күресеміз? Әрине, дәл осы сәтте біреу «Агиль ше?!» деп айқайлай бастайды. Жарайды, бәріңіз икемдісіздер, бірақ ше? Жоба нақты қалай көрінеді, оны жобаға сай етіп қалай шығармақсыз? Сіз жай ғана «біздің көзқарасымыз кез келген нәрсеге созылады, біз Scrum командасымыз!» деп айта алмайсыз. Бұл бос сөз және бос сөз. Әрі қарай қайда бармақшысыз, ол неге жұмыс істеуі керек, мәні қайда? Мен өз клиенттерімді осы сұрақтардың барлығын ойлауға үйретемін.
19 жыл епті
Майкл: Agile-де адамдар жиі ештеңені алдын ала анықтамауға тырысады, бірақ мүмкіндігінше кешігіп шешім қабылдауға тырысады: біз тым үлкенміз, мен жалпы архитектура туралы ойламаймын. Мен басқа нәрселер туралы ойламаймын; оның орнына дәл қазір тұтынушыға жұмыс істейтін нәрсені жеткіземін.
Тим: Менің ойымша, Agile әдістемелері, бастап 2001 жылы саланың көзін ашты. Бірақ екінші жағынан, ештеңе мінсіз емес. Мен итеративті дамуға дайынмын. Көптеген жобаларда итерация көп мағына береді. Бірақ сіз ойлануыңыз керек сұрақ: өнім шыққаннан кейін және пайдаланылғаннан кейін ол қанша уақытқа жетеді? Бұл басқа нәрсемен ауыстырылғанға дейін алты айға созылатын өнім ме? Әлде бұл көп жылдар бойы жұмыс істейтін өнім ме? Әрине, мен атауларды атамай-ақ қояйын, бірақ... Нью-Йоркте және оның қаржы қоғамдастығында ең іргелі жүйелер өте ескі. Бұл таңқаларлық. Сіз оларға қарап, 1994 жылға оралып, әзірлеушілерге: «Мен болашақтан, 2019 жылдан келдім. Бұл жүйені қажет болғанша дамытыңыз. Оны кеңейтуге мүмкіндік беріңіз, сәулет туралы ойланыңыз. Содан кейін ол жиырма бес жылдан астам уақыт бойы жетілдіріледі. Егер сіз дамуды сәл кешіктірсеңіз, үлкен схемада ешкім байқамайды!» Ұзақ мерзімді перспективада заттарды бағалағанда, оның жалпы құны қанша болатынын ескеру қажет. Кейде жақсы жобаланған сәулет шынымен де оған тұрарлық, ал кейде олай емес. Біз айналамызға қарап, өзімізге сұрақ қоюымыз керек: біз мұндай шешім қабылдау үшін дұрыс жағдайдамыз ба?
Сондықтан «Біз ептілікке ұмтыламыз, тапсырыс берушінің өзі не алғысы келетінін айтады» деген идея өте аңғал. Клиенттер тіпті не қалайтынын білмейді, тіпті одан да көп, олар не ала алатынын білмейді. Кейбіреулер дәлел ретінде тарихи мысалдарды келтіре бастайды, мен мұны бұрыннан көрдім. Бірақ техникалық жағынан дамыған адамдар мұны әдетте айтпайды. Олар: «Бұл 2019 жыл, бұл бізде бар мүмкіндіктер және біз бұл нәрселерге көзқарасымызды толығымен өзгерте аламыз!» Қолданыстағы шешімдерге еліктеудің орнына, оларды сәл әдемірек және тарақтырақ етудің орнына, кейде сіз сыртқа шығып: «Бұл жерде не істеуге тырысып жатқанымызды толығымен қайта ойлап көрейік!» деу керек.
Менің ойымша, тұтынушылардың көпшілігі мәселе туралы осылай ойлай алмайды. Олар өздерінде бар нәрсені ғана көреді, бар болғаны. Одан кейін олар «бұны сәл жеңілдетейік» немесе әдетте не айтатын сияқты сұраулармен келеді. Бірақ біз даяшы немесе даяшы емеспіз, сондықтан қанша ақымақ болса да тапсырыс алып, ас үйде пісіріп аламыз. Біз олардың жетекшіміз. Біз олардың көздерін ашып: ей, бізде жаңа мүмкіндіктер бар! Сіздің бизнесіңіздің осы бөлігінің жасалу жолын шынымен өзгерте алатынымызды түсінесіз бе? Agile-дің проблемаларының бірі - бұл мүмкіндік деген не, мәселе не, тіпті не істеуіміз керек, қандай қолжетімді технологиялар осы нақты жағдайға ең қолайлы екендігі туралы хабардарлықты жояды.
Мүмкін, мен бұл жерде тым күмәнмен қарайтын шығармын: Agile қауымдастығында көптеген тамаша нәрселер болып жатыр. Бірақ менде бір мәселе бар, ол жобаны анықтаудың орнына, қол ұшын соза бастайды. Мен бұл жерде сұрар едім - біз не істеп жатырмыз, оны қалай жасаймыз? Және әйтеуір бір сиқырлы түрде әрқашан клиент басқалардан жақсы білуі керек. Бірақ клиент біреу салған нәрселердің ішінен таңдаған кезде ғана жақсы біледі. Егер мен көлік алғым келсе және өзімнің отбасылық бюджетімнің көлемін білсем, онда мен өмір салтыма сай көлікті тез таңдаймын. Бұл жерде мен бәрін бәрінен де жақсы білемін! Бірақ көліктерді біреу жасап қойғанын ескеріңіз. Мен жаңа көлік ойлап табуды білмеймін, мен маман емеспін. Арнайы немесе арнайы өнімдерді жасаған кезде тұтынушының дауысын ескеру керек, бірақ бұл енді жалғыз дауыс емес.
Олег: Сіз Agile манифесті туралы айттыңыз. Мәселенің қазіргі заманғы түсінігін ескере отырып, оны қандай да бір түрде жаңарту немесе қайта қарау керек пе?
Тим: Мен оған тиіспес едім. Бұл үлкен тарихи құжат деп ойлаймын. Айтайын дегенім, ол қандай болса. Жасы 19-ға толды, жасы ұлғайғанымен, өз заманында төңкеріс жасады. Оның жақсы істегені - реакция тудырып, адамдар ол туралы сыбырлай бастады. Сіз, ең алдымен, 2001 жылы бұл салада әлі жұмыс істемеген шығарсыз, бірақ содан кейін бәрі процестерге сәйкес жұмыс істеді. Software Engineering Institute, бағдарламалық қамтамасыз етудің толықтығы моделінің бес деңгейі (CMMI). Мұндай терең ежелгі аңыздар сізге бірдеңе айтар ма, білмеймін, бірақ кейін бұл серпіліс болды. Бастапқыда адамдар егер процестер дұрыс орнатылса, проблемалар өздігінен жойылады деп сенді. Содан кейін Манифест шығады және былай дейді: «Жоқ, жоқ, жоқ – біз процестерге емес, адамдарға негізделеміз». Біз бағдарламалық жасақтаманы әзірлеудің шеберіміз. Біз идеалды процестің закым екенін түсінеміз, ол болмайды. Жобаларда тым көп ерекшелік бар, барлық жобалар үшін бір тамаша процесс идеясы ешқандай мағынасы жоқ. Мәселелер бәріне бір ғана шешім бар деп айту үшін тым күрделі (сәлем, нирвана).
Мен болашаққа қараймын деп ойламаймын, бірақ мен қазір адамдар жобалар туралы көбірек ойлана бастады деп айтамын. Менің ойымша, Agile манифесті секіріп, «Эй! Сіз кемедесіз және бұл кемені өзіңіз басқарасыз. Сізге шешім қабылдауға тура келеді - біз барлық жағдайларға әмбебап рецепт ұсынбаймыз. Сіз кеменің экипажысыз, егер сіз жеткілікті жақсы болсаңыз, мақсатқа жол таба аласыз. Сізден бұрын басқа кемелер болды, сізден кейін де басқа кемелер болады, бірақ бәрібір, белгілі бір мағынада, сіздің саяхатыңыз ерекше». Осындай нәрсе! Бұл ойлау тәсілі. Мен үшін күн астында жаңалық жоқ, адамдар бұрын жүзіп келген және қайтадан жүзетін болады, бірақ сіз үшін бұл сіздің басты саяхатыңыз, мен сізге нақты не болатынын айтпаймын. Сізде топта үйлестірілген жұмыс дағдылары болуы керек, егер сізде олар шынымен болса, бәрі орындалады және сіз қалаған жерге жетесіз.
Peopleware: 30 жылдан кейін
Олег: Peopleware Манифест сияқты революция болды ма?
Тим: Адамдарға арналған құралдар... Том екеуміз бұл кітапты жазғанбыз, бірақ бұлай болады деп ойламадық. Әйтеуір көптің ойынан шықты. Бұл бірінші кітап: бағдарламалық жасақтаманы әзірлеу - бұл адам үшін өте қарқынды әрекет. Техникалық табиғатымызға қарамастан, біз сондай-ақ үлкен, тіпті үлкен, өте күрделі нәрсені жасайтын адамдар қауымдастығымыз. Мұндай нәрселерді ешкім жалғыз жасай алмайды, солай ма? Сондықтан «команда» идеясы өте маңызды болды. Менеджмент тұрғысынан ғана емес, сонымен қатар белгісіздер тобымен шын мәнінде күрделі терең мәселелерді шешу үшін жиналған техникалық адамдар үшін. Жеке мен үшін бұл менің мансабымдағы интеллекттің үлкен сынағы болды. Бұл жерде сіз айта алуыңыз керек: иә, бұл мәселе мен өз бетімше шеше алатынымнан да көп, бірақ біз бірге мақтануға болатын талғампаз шешім таба аламыз. Ең көп резонанс тудырған осы идея болды деп ойлаймын. Уақыттың бір бөлігін өз бетімізше, бір бөлігін топтың бір бөлігі ретінде жұмыс істейміз және көбінесе шешімді топ қабылдайды деген ой. Топтық мәселелерді шешу тез арада күрделі жобалардың маңызды ерекшелігіне айналды.
Тим көптеген баяндамалар жасағанына қарамастан, олардың өте азы YouTube сайтында жарияланған. Сіз 2007 жылғы «Адамдық құралдардың қайтарылуы» есебін көре аласыз. Сапасы, әрине, көп нәрсені қалауға қалдырады.
Майкл: Кітап шыққаннан кейінгі 30 жылда бірдеңе өзгерді ме?
Тим: Бұған әртүрлі қырынан қарауға болады. Социологиялық тұрғыдан алғанда... бір кездері, қарапайым уақытта сіз және сіздің командаңыз бір кабинетте отырдыңыз. Сіз күнде жақын болып, бірге кофе ішіп, жұмысты талқылай аласыз. Шын мәнінде өзгерген нәрсе, командаларды географиялық тұрғыдан, әртүрлі елдер мен уақыт белдеулеріне бөлуге болады, бірақ олар әлі де бірдей мәселемен жұмыс істейді және бұл күрделіліктің жаңа қабатын қосады. Бұл ескі мектеп сияқты көрінуі мүмкін, бірақ бәріңіз бірге, бірге жұмыс істеп, әріптесіңізге жақындап, «қараңызшы, мен не аштым, сізге бұл қалай ұнады?» деп айта алатын бетпе-бет сөйлесу сияқты ештеңе жоқ. Бетпе-бет сөйлесу бейресми қарым-қатынасқа өтудің жылдам жолын қамтамасыз етеді және менің ойымша, бұл епті энтузиастарға да ұнауы керек. Мен де алаңдаймын, өйткені шын мәнінде әлем өте кішкентай болып шықты, қазір оның барлығы бөлінген командалармен жабылған және бәрі өте күрделі.
Біз бәріміз DevOps жүйесінде өмір сүреміз
Майкл: Тіпті конференцияның бағдарламалық комитетінің көзқарасы бойынша бізде Калифорнияда, Нью-Йоркте, Еуропада, Ресейде адамдар бар ... Сингапурда әлі ешкім жоқ. Географиялық айырмашылық өте үлкен және адамдар одан да көп тарай бастады. Егер даму туралы айтатын болсақ, devops және командалар арасындағы кедергілерді жою туралы көбірек айтып бере аласыз ба? Әркім өз бункерлерінде отырады, енді бункерлер құлап жатыр деген түсінік бар, бұл ұқсастыққа қалай қарайсыз?
Тим: Менің ойымша, соңғы технологиялық серпілістерді ескере отырып, devops өте маңызды болып табылады. Бұрын сізде әзірлеушілер мен әкімшілер топтары болды, олар жұмыс істеді, жұмыс істеді, жұмыс істеді және бір сәтте сіз әкімшілерге келіп, оны өндіріске шығаруға болатын нәрсе пайда болды. Міне, бункер туралы әңгіме басталды, өйткені админдер біртүрлі одақтастар, жау емес, кем дегенде, сіз олармен өндіріске баруға дайын болғанда ғана сөйлестіңіз. Сіз оларға бірдеңемен барып: Қараңызшы, бізде қандай қосымша бар, бірақ сіз бұл қолданбаны шығара аласыз ба? Ал қазір жеткізудің барлық тұжырымдамасы жақсы жаққа өзгерді. Менің айтайын дегенім, өзгерістерді тез итермелеуге болатын идея болды. Біз өнімдерді жылдам жаңарта аламыз. Ноутбугімдегі Firefox пайда болған кезде мен әрқашан күлемін: «Эй, біз Firefox-ты фондық режимде жаңарттық және сізге бір минут болған кезде осы жерді бассаңыз, біз сізге соңғы шығарылымды береміз. Мен: «Иә, балақай!» Мен ұйықтап жатқанда, олар менің компьютерімде жаңа шығарылымды жеткізумен айналысты. Бұл керемет, керемет.
Бірақ мұнда қиындық бар: бағдарламалық жасақтаманы жаңарту арқылы сізде бұл мүмкіндік бар, бірақ адамдарды біріктіру әлдеқайда қиын. Мен DevOops негізгі баяндамасында айтқым келетіні, қазір бізде бұрынғыдан да көп ойыншылар бар. Егер сіз тек бір командаға қатысатын барлық адамдар туралы ойласаңыз .... Сіз оны команда ретінде ойладыңыз және бұл жай ғана бағдарламашылар командасынан әлдеқайда көп. Бұл тестерлер, жоба менеджерлері және басқа да адамдар. Және әркімнің дүниеге деген өз көзқарасы бар. Өнім менеджерлері жоба менеджерлерінен мүлдем өзгеше. Админдердің өз міндеттері бар. Не болып жатқанын біліп, есінен танып қалмау үшін барлық қатысушыларды үйлестіру өте қиын мәселеге айналады. Топтың тапсырмалары мен барлығына қатысты тапсырмаларды бөліп алу керек. Бұл өте қиын тапсырма. Екінші жағынан, менің ойымша, бәрі көп жылдар бұрынғыға қарағанда әлдеқайда жақсы. Дәл осы жолда адамдар өсіп, өзін дұрыс ұстауға үйренеді. Сіз интеграцияны жүзеге асырған кезде, бағдарламалық жасақтама соңғы сәтте қораптағы ұяшық сияқты шығып кетпеуі үшін жер асты дамуының болмауы керек екенін түсінесіз: біз мұнда не істегенімізді қараңыз! Идея - сіз интеграция мен дамуды жасай аласыз, соңында сіз ұқыпты және итеративті түрде шығасыз. Мұның бәрі мен үшін көп нәрсені білдіреді. Бұл жүйені пайдаланушылар үшін және сіздің клиентіңіз үшін көбірек мән жасауға мүмкіндік береді.
Майкл: Девоптың бүкіл идеясы маңызды оқиғаларды мүмкіндігінше ертерек жеткізу болып табылады. Байқаймын, әлем барған сайын жылдамдай бастады. Мұндай жеделдетулерге қалай бейімделуге болады? Он жыл бұрын бұл жоқ еді!
Тим: Әрине, бәрі көбірек функционалдылықты қалайды. Қозғалудың қажеті жоқ, тек көбірек үйіп тастаңыз. Кейде пайдалы нәрсе әкелу үшін келесі қосымша жаңарту үшін баяулатуға тура келеді - бұл қалыпты жағдай.
Жүгіру, жүгіру, жүгіру керек деген идея ең жақсы емес. Кез келген адам өз өмірін осылай өткізгісі келетіні екіталай. Мен жеткізу ырғағы жобаның өзіндік ырғағын орнатқанын қалаймын. Егер сіз жай ғана шағын, салыстырмалы түрде мағынасыз нәрселер ағынын шығарсаңыз, мұның бәрі мағынасыз болады. Мүмкіндігінше ертерек босатуға тырысудың орнына, жетекші әзірлеушілермен, өнім және жоба менеджерлерімен талқылау керек нәрсе - бұл стратегия. Бұл тіпті мағынасы бар ма?
Үлгілер және антипаттерндер
Олег: Сіз әдетте үлгілер мен антипаттерндер туралы айтасыз және бұл жобалардың өмірі мен өлімінің арасындағы айырмашылық. Ал енді, девопс біздің өмірімізге еніп кетті. Оның жобаны орнында өлтіруі мүмкін өзіндік үлгілері мен анти-үлгілері бар ма?
Тим: Үлгілер мен анти-үлгілер үнемі орын алады. Әңгімелейтін нәрсе. Жарайды, біз «жылтыр заттар» деп атайтын нәрсе бар. Адамдар жаңа технологияны шынымен жақсы көреді. Олар жай ғана салқын және стильді көрінетін барлық нәрселердің жарқырағанымен таң қалдырады және олар сұрақ қоюды тоқтатады: бұл қажет пе? Біз неге қол жеткіземіз? Бұл нәрсе сенімді ме, оның мағынасы бар ма? Мен, былайша айтқанда, технологияның алдыңғы қатарында жүрген адамдарды жиі көремін. Олар әлемде болып жатқан оқиғаларға гипнозға ұшырайды. Бірақ егер сіз олардың қандай пайдалы істермен айналысатынын мұқият қарасаңыз, көбінесе пайдалы ештеңе жоқ!
Жаңа ғана жолдастарымызбен биылғы жыл мерейтойлы жыл, адамдардың Айға қонғанына елу жыл екенін талқыладық. Бұл 1969 жылы болды. Адамдарға ол жерге жетуге көмектескен технология тіпті 1969 технологиясы емес, 1960 немесе 62, өйткені NASA сенімділіктің жақсы дәлелі бар нәрсені ғана пайдаланғысы келді. Міне, сіз оған қарап, түсінесіз - иә, және олар шындық болды! Енді, жоқ, жоқ, бірақ сіз технологиямен проблемаларға тап боласыз, өйткені бәрі тым қатты итеріліп, барлық жарықтардан сатылды. Адамдар әр жерден айқайлап жатыр: «Міне, бұл не деген нәрсе, бұл әлемдегі ең жаңа нәрсе, ең әдемі нәрсе, барлығына жарамды!» Міне, солай... әдетте мұның бәрі алдамшы болып шығады, содан кейін бәрін тастау керек. Бәлкім, мұның бәрі мен қазірдің өзінде қарт адам болғандықтан, адамдар таусылып, ең жақсы технологияларды жасаудың жалғыз, ең дұрыс жолын таптым деген кезде мұндай нәрселерге үлкен сенімсіздікпен қарайтындықтан шығар. Осы кезде ішімде: «Не деген сұмдық!» деген дауыс оянады.
Майкл: Шынында да, біз келесі күміс оқ туралы қаншалықты жиі естідік?
Тим: Дәл солай, бұл әдеттегі жағдай! Мысалы... бұл дүние жүзінде әзілге айналған сияқты, бірақ мұнда адамдар блокчейн технологиясы туралы жиі айтады. Және олар белгілі бір жағдайларда мағынасы бар! Оқиғалардың, жүйенің жұмыс істейтінін және бізді ешкім алдамағаны туралы сенімді дәлелдер қажет болғанда, сізде қауіпсіздік мәселелері және осының бәрі араласқан кезде - блокчейн мағынасы бар. Бірақ олар Blockchain енді бүкіл әлемді сыпырып, жолындағының бәрін жояды деп айтқанда? Көбірек арманда! Бұл өте қымбат және күрделі технология. Техникалық күрделі және көп уақытты қажет етеді. Соның ішінде таза алгоритмдік түрде, математиканы аздаған өзгерістермен қайта есептеу қажет болған сайын... және бұл тамаша идея - бірақ белгілі бір жағдайлар үшін ғана. Менің бүкіл өмірім мен мансабым осыған байланысты болды: өте нақты жағдайларда қызықты идеялар. Сіздің жағдайыңыздың нақты қандай екенін түсіну өте маңызды.
Майкл: Иә, басты «өмірдің, ғаламның және бәрінің сұрағы»: бұл технология немесе тәсіл сіздің жағдайыңызға сай ма, жоқ па?
Тим: Бұл сұрақты технологиялық топпен талқылауға болады. Мүмкін, тіпті кейбір кеңесшіні де әкелуі мүмкін. Жобаны қарап шығыңыз және түсініңіз - енді біз бұрынғыдан жақсырақ, дұрыс және пайдалы нәрсе жасаймыз ба? Мүмкін жарасады, мүмкін жарамайды. Бірақ ең бастысы, әдепкі бойынша мұндай шешімді қабылдамаңыз, себебі біреу: «Бізге блокчейн өте қажет! Мен ол туралы жаңа ғана ұшақта журналдан оқыдым!» Шынайы ма? Бұл тіпті күлкілі емес.
Мифтік «девопс инженері»
Олег: Қазір барлығы devops енгізуде. Біреу интернетте devops туралы оқиды, ал ертең рекрутинг сайтында басқа бос орын пайда болады. «девопс инженері». Осы жерде мен сіздердің назарларыңызды аударғым келеді: қалай ойлайсыз, бұл «devops engineer» терминінің өмір сүруге құқығы бар ма? Девопс - бұл мәдениет және мұнда бірдеңе қосылмайды деген пікір бар.
Тим: Солай де. Олар дереу осы терминге түсініктеме берсін. Оны бірегей ететін нәрсе. Олар мұндай бос орынның артында қандай да бір ерекше дағдылар жиынтығы бар екенін дәлелдемейінше, мен оны сатып алмаймын! Менің айтайын дегенім, бізде «девоп инженер» деген лауазым бар, иә, әрі қарай не істеу керек? Лауазымдық атаулар, әдетте, өте қызықты нәрсе. «Әзірлеуші» делік - бұл не? Әртүрлі ұйымдар мүлдем басқа нәрселерді білдіреді. Кейбір компанияларда жоғары сапалы бағдарламашылар басқа компаниялардағы арнайы кәсіби тестерлер жазған тесттерден гөрі мағыналырақ тесттер жазады. Енді олар бағдарламашылар ма, әлде тестерлер ме?
Иә, бізде жұмыс атаулары бар, бірақ егер сіз жеткілікті ұзақ сұрақтар қоятын болсаңыз, біз бәріміз проблеманы шешуші екенбіз. Біз шешім іздеушілерміз, ал кейбіреулерінің техникалық дағдылары бар, ал кейбіреулерінің басқалары бар. Егер сіз DevOps енген ортада тұрсаңыз, сіз әзірлеу мен басқаруды біріктірумен айналысасыз және бұл әрекеттің айтарлықтай маңызды мақсаты бар. Бірақ сізден нақты немен айналысасыз және не үшін жауаптысыз деп сұраса, бұл адамдардың барлығын ежелден істеп келе жатқаны белгілі болады. «Мен сәулет үшін жауаптымын», «Мен дерекқорға жауаптымын» және т.б., сіз көріп тұрсыз - мұның бәрі «девоптардан» бұрын болған.
Біреу маған лауазымын айтса, мен көп тыңдамаймын. Оған шын мәнінде не үшін жауапты екенін айтып берген дұрыс, бұл бізге мәселені жақсырақ түсінуге мүмкіндік береді. Менің ең жақсы көретін мысалым: адам өзін «жоба менеджері» деп мәлімдеген кезде. Не? Бұл ештеңені білдірмейді, мен сенің не істейтініңді әлі білмеймін. Жоба менеджері әзірлеуші, төрт адамнан тұратын топтың жетекшісі, код жазатын, жұмыс жасайтын, топ жетекшісіне айналған, адамдар арасында көшбасшы ретінде танитын болуы мүмкін. Сондай-ақ, жоба менеджері жобада алты жүз адамды басқаратын, басқа менеджерлерді басқаратын, кестелерді құруға және бюджеттерді жоспарлауға жауап беретін менеджер болуы мүмкін. Бұл екі мүлдем басқа әлем! Бірақ олардың лауазымы бірдей естіледі.
Мұны сәл басқаша бұрайық. Сіз шынымен немен айналысасыз, тәжірибеңіз көп, сізде талант бар ма? Тапсырманы орындай аламын деп ойлай отырып, сіз не үшін жауапкершілікті аласыз? Бұл жерде біреу бірден бас тарта бастайды: жоқ, жоқ, жоқ, жоба ресурстарымен мүлдем айналысқым келмейді, бұл менің ісім емес, мен техникалық жігітпін және ыңғайлылық пен пайдаланушы интерфейстерін түсінемін, мен түсінбеймін. Мен адамдар армиясын басқарғым келеді, маған жұмысқа баруға рұқсат етіңіз.
Айтпақшы, мен дағдыларды бөлу жақсы жұмыс істейтін тәсілдің үлкен жақтаушысымын. Техниктер өз мансабын қалағанша өсіретін жерде. Дегенмен, мен әлі де техникалық мамандар шағымданатын ұйымдарды көремін: мен жобаны басқаруға баруым керек, өйткені бұл компаниядағы жалғыз жол. Кейде бұл қорқынышты нәтижелерге әкеледі. Ең жақсы техниктер жақсы менеджерлер емес, ал ең жақсы менеджерлер технологияны басқара алмайды. Бұл туралы шыншыл болайық.
Қазір осыған сұраныс көп екенін көріп тұрмын. Егер сіз техникалық маман болсаңыз, сіздің компанияңыз сізге көмектесе алады, бірақ оған қарамастан, сізге өзіңіздің мансап жолыңызды табу керек, өйткені технология үнемі өзгеріп отырады және сіз онымен бірге өзіңізді қайта ойлап табуыңыз керек! Жиырма жылдың ішінде технологиялар кем дегенде бес рет өзгеруі мүмкін. Технология біртүрлі нәрсе...
«Бәрі бойынша сарапшылар»
Майкл: Адамдар технологияның мұндай жылдамдығына қалай төтеп бере алады? Олардың күрделілігі өсуде, олардың саны өсуде, адамдар арасындағы қарым-қатынастың жалпы көлемі де өсуде және сіз «барлық нәрсенің сарапшысы» бола алмайтыныңыз белгілі болды.
Тим: Дұрыс! Егер сіз технологияда жұмыс жасасаңыз, иә, сізге нақты нәрсені таңдап, оған тереңірек үңілу керек. Ұйымыңыз пайдалы деп санайтын кейбір технологиялар (және шын мәнінде пайдалы болуы мүмкін). Ал егер сізді бұдан былай қызықтырмайтын болсаңыз - мен бұлай айтамын деп ешқашан сенбес едім - жақсы, мүмкін сіз технология қызықтырақ немесе оқуға ыңғайлы басқа ұйымға ауысуыңыз керек шығар.
Бірақ жалпы алғанда, иә, сіз дұрыссыз. Технологиялар бірден барлық бағытта дамып келеді, ешкім «мен барлық технологиялардың сарапшысымын» деп айта алмайды. Екінші жағынан, технологиялық білімді сөзбе-сөз бойына сіңіріп, оған ақылсыз адамдар бар. Мен мұндай адамдарды көрдім, олар сөзбе-сөз тыныс алады және өмір сүреді, олармен сөйлесу пайдалы және қызықты. Олар ұйым ішінде не болып жатқанын зерттеп қана қоймайды, сонымен бірге олар бұл туралы айтады, олар сонымен қатар өте керемет технологтар, олар өте саналы және мақсатты. Олар негізгі жұмысы қандай болса да, толқынның шыңында қалуға тырысады, өйткені олардың құмарлығы – Технологияның қозғалысы, технологияны алға жылжыту. Егер сіз кенеттен осындай адамды кездестірсеңіз, онымен түскі асқа баруыңыз керек және түскі ас үстінде әртүрлі салқын нәрселерді талқылауыңыз керек. Менің ойымша, кез келген ұйымға мұндай адамдар кем дегенде бір-екі керек.
Тәуекелдер және белгісіздік
Майкл: Құрметті инженерлер, иә. Уақыт болғанша тәуекелдерді басқаруға тоқталайық. Біз бұл сұхбатты қателер ауыр зардаптарға әкелуі мүмкін медициналық бағдарламалық қамтамасыз етуді талқылаудан бастадық. Содан кейін біз Ай бағдарламасы туралы айттық, онда қатенің құны миллиондаған долларды құрайды, мүмкін бірнеше адам өмірі. Бірақ қазір мен салада керісінше қозғалысты көріп отырмын, адамдар тәуекелдер туралы ойламайды, оларды болжауға тырыспайды, тіпті оларды байқамайды.
Олег: Жылдам қозғалып, заттарды сындырыңыз!
Майкл: Иә, бірдеңеден өлгенше, тез қозғалыңыз, заттарды сындырыңыз, одан да көп нәрсені. Сіздің көзқарасыңыз бойынша, орташа әзірлеуші қазір тәуекелдерді басқаруды үйренуге қалай қарау керек?
Тим: Осы жерде екі нәрсенің арасын сызып көрейік: тәуекелдер мен белгісіздік. Бұл әртүрлі нәрселер. Белгісіздік белгілі бір уақытта нақты жауап алу үшін жеткілікті деректер болмаған кезде пайда болады. Мысалы, жобаның ең ерте кезеңінде біреу сізден «жұмысты қашан аяқтайсыз» деп сұраса, егер сіз шыншыл адам болсаңыз, «менде ештеңе жоқ» деп жауап бересіз. Сіз жай ғана білмейсіз, бұл жақсы. Сіз әлі есептерді зерттеген жоқсыз және командамен таныс емессіз, олардың дағдыларын білмейсіз және т.б. Бұл белгісіздік.
Тәуекелдер ықтимал проблемаларды анықтау мүмкін болған кезде пайда болады. Мұндай нәрсе болуы мүмкін, оның ықтималдығы нөлден жоғары, бірақ жүз пайыздан аз, бір жерде. Осыған байланысты кез келген нәрсе болуы мүмкін, кешігулер мен қажетсіз жұмыстардан бастап, тіпті жоба үшін өлімге әкелетін нәтижеге дейін. Нәтижесі, балалар, қолшатырларымызды бүктеп, жағадан шығайық, оны ешқашан бітірмейміз, бәрі бітті, кезең. Біз бұл нәрсе жұмыс істейді деп болжадық, бірақ ол мүлдем жұмыс істемейді, тоқтайтын уақыт келді. Бұл жағдайлар.
Көбінесе проблемалар пайда болған кезде, мәселе дәл қазір болып жатқанда оңай шешіледі. Бірақ мәселе сіздің алдыңызда тұрғанда, сіз тәуекелдерді басқарумен айналыспайсыз - сіз проблеманы шешумен, дағдарысты басқарумен айналысасыз. Егер сіз жетекші әзірлеуші немесе менеджер болсаңыз, кідірістерге, уақытты жоғалтуға, қажетсіз шығындарға немесе бүкіл жобаның құлдырауына әкелетін не болуы мүмкін деп ойлайсыз ба? Бізді тоқтатып, қайта бастауға не мәжбүр етеді? Осының бәрі жұмыс істегенде, біз олармен не істейміз? Көптеген жағдайларға жарамды қарапайым жауап бар: тәуекелдерден қашпаңыз, олармен жұмыс істеңіз. Тәуекелді жағдайды қалай шешуге, оны жоққа дейін азайтуға, оны мәселеден басқа нәрсеге айналдыруға болатынын қараңыз. «Жарайды, біз проблемаларды олар туындаған кезде шешеміз» деп айтудың орнына.
Белгісіздік пен тәуекел сіз шешетін барлық нәрсенің басында болуы керек. Сіз жобаның жоспарын қабылдап, белгілі бір сыни тәуекелдерді алдын ала қарап, мынаны айта аласыз: біз мұнымен қазір айналысуымыз керек, өйткені егер мұның кез келгені дұрыс болмаса, басқа ештеңе маңызды емес. Кешкі ас әзірлеуге болатын-болмағаныңыз белгісіз болса, үстелдегі дастарханның әдемілігі туралы алаңдамауыңыз керек. Алдымен дәмді кешкі асты дайындаудың барлық тәуекелдерін анықтау керек, олармен күресу керек, содан кейін ғана нақты қауіп төндірмейтін барлық басқа нәрселер туралы ойланыңыз.
Тағы да айта кетейін, сіздің жобаңызды бірегей ететін не? Біздің жобамызды рельстен шығаруға не себеп болатынын көрейік. Бұл жағдайдың ықтималдығын азайту үшін не істей аламыз? Әдетте сіз оларды 100% бейтараптандыруға және таза ар-ұжданмен: «Міне, бұл енді проблема емес, тәуекел шешілді!» деп мәлімдей алмайсыз. Мен үшін бұл ересектердің мінез-құлқының белгісі. Бала мен ересек адамның айырмашылығы осында – балалар өздерін өлмейтін, ешнәрседен қателеспейді, бәрі жақсы болады деп ойлайды! Сонымен бірге ересектер үш жасар балалардың ойын алаңында қалай секіргенін бақылап, қимылдарды көздерімен қадағалап, өздеріне: «ooh-ooh, ooh-ooh» дейді. Мен жақын жерде тұрып, бала құлап қалғанда ұстауға дайындаламын.
Екінші жағынан, маған бұл бизнесті соншалықты ұнататын себебім, ол тәуекелді. Біз нәрселерді жасаймыз және бұл нәрселер қауіпті. Олар ересектердің көзқарасын талап етеді. Жалғыз ынта-жігер проблемаларыңызды шешпейді!
Ересектердің инженерлік ойлауы
Майкл: Балалармен үлгі жақсы. Егер мен қарапайым инженер болсам, бала болғаныма ризамын. Бірақ ересектерге көбірек ойлауға қалай көшуге болады?
Тим: Жаңадан бастаушымен де, қалыптасқан әзірлеушімен де бірдей жақсы жұмыс істейтін идеялардың бірі - контекст тұжырымдамасы. Біз не істеп жатырмыз, неге қол жеткіземіз. Бұл жобада шынымен не маңызды? Бұл жобада кім екеніңіз маңызды емес, сіз интерн немесе бас сәулетші болсаңыз да, барлығына контекст қажет. Біз әркім өз жұмысынан гөрі кеңірек ойлауға мәжбүрлеуіміз керек. «Мен өз туындымды жасаймын және менің шығармам жұмыс істеп тұрғанда, мен бақыттымын». Жоқ және қайтадан жоқ. Адамдарға олар жұмыс істейтін контекстті еске түсіру әрқашан тұрарлық (дөрекі емес!). Барлығымыз бірге қол жеткізуге тырысамыз. Сіздің жобаңызда бәрі жақсы болғанша бала бола алатыныңыз туралы идеялар - өтінемін, олай етпеңіз. Мәре сызығын мүлде кесетін болсақ, оны тек бірге өтеміз. Сіз жалғыз емессіз, біз бәріміз біргеміз. Егер жобадағы барлық адамдар, жасы да, кәрі де, жоба үшін нақты не маңызды екенін, компания неге біз бәріміз қол жеткізуге тырысып жатқан нәрсеге ақша салып жатқаны туралы айта бастаса... олардың көпшілігі өздерін әлдеқайда жақсы сезінеді, өйткені олар олардың жұмысы басқалардың жұмысымен қалай сәйкес келетінін көреді. Бір жағынан, мен жеке жауап беретін шығарманы түсінемін. Бірақ жұмысты аяқтау үшін бізге басқа адамдар да керек. Ал егер сіз шынымен аяқтадым деп ойласаңыз, жобада бізде әрқашан жұмыс бар!
Олег: Салыстырмалы түрде айтатын болсақ, егер сіз Канбанға сәйкес жұмыс жасасаңыз, кейбір тестілеудің тығырыққа тірелген кезде, сіз сол жерде істеп жатқан ісіңізді (мысалы, бағдарламалау) тастап, тестерлерге көмектесе аласыз.
Тим: Дәл. Менің ойымша, ең жақсы техниктер, егер сіз оларға мұқият қарасаңыз, олар өздерінің менеджерлері сияқты. Мен мұны қалай тұжырымдай аламын ...
Олег: Сіздің өміріңіз - сіз басқаратын жобаңыз.
Тим: Дәл! Айтайын дегенім, сіз жауапкершілікті өз мойныңызға аласыз, мәселені түсінесіз және сіздің шешімдеріңіз олардың жұмысына әсер етуі мүмкін екенін көргенде адамдармен байланысқа түсесіз. Бұл жай ғана үстеліңізде отыру, өз жұмысыңызды орындау, тіпті айналаңызда не болып жатқанын түсінбеу туралы емес. Жоқ Жоқ жоқ. Айтпақшы, Agile-дің жақсы жақтарының бірі - олар қысқа спринттерді ұсынды, өйткені осылайша барлық қатысушылардың жағдайы анық байқалады, олар барлығын бірге көре алады. Біз күнде бір-біріміз туралы сөйлесеміз.
Тәуекелдерді басқаруға қалай түсуге болады
Олег: Бұл салада білімнің ресми құрылымы бар ма? Мысалы, мен Java әзірлеушісімін және білім бойынша нақты жоба менеджері болмай-ақ тәуекелдерді басқаруды түсінгім келеді. Мен алдымен МакКоннеллдің «Бағдарламалық жасақтама жобасының құны қанша» дегенді оқитын шығармын, содан кейін не? Алғашқы қадамдар қандай?
Тим: Біріншісі - жобадағы адамдармен қарым-қатынасты бастау. Бұл әріптестермен қарым-қатынас мәдениетінің бірден жақсаруын қамтамасыз етеді. Біз бәрін жасырудан емес, әдепкі бойынша ашудан бастауымыз керек. Айтыңызшы: осылар мені мазалайды, түнде ұйықтатпайтын нәрселер осылар, мен бүгін түнде оянып, былай болдым: Құдай-ау, осыны ойлауым керек! Басқалар бірдей нәрсені көре ме? Топ ретінде осы ықтимал мәселелерге жауап беруіміз керек пе? Сіз осы тақырыптар бойынша пікірталасқа қолдау көрсете білуіңіз керек. Біз жұмыс істейтін алдын ала дайындалған формула жоқ. Бұл гамбургер жасау туралы емес, бәрі адамдарға қатысты. «Чизбургер жасадым, чизбургер сатамын» - бұл біздің шаруамыз емес, сондықтан мен бұл жұмысты жақсы көремін. Менеджерлер жасағанның бәрі қазір команданың меншігіне айналғаны ұнайды.
Олег: Сіз кітаптарда және сұхбаттарда адамдардың диаграммадағы сандардан гөрі бақыт туралы көбірек ойлайтыны туралы айттыңыз. Екінші жағынан, сіз командаға айтқан кезде: біз devops-қа көшеміз, енді бағдарламашы үнемі байланыста болуы керек, бұл оның жайлылық аймағынан алыс болуы мүмкін. Осы сәтте ол, айталық, қатты бақытсыз болуы мүмкін. Бұл жағдайда не істеу керек?
Тим: Мен нақты не істеу керектігін білмеймін. Егер әзірлеуші тым оқшауланған болса, олар бірінші кезекте жұмыстың неліктен орындалып жатқанын түсінбейді, олар тек жұмыстың өз бөлігіне қарайды және олар мен «контекст» деп атайтын нәрсеге енуі керек. Ол бәрі бір-бірімен қалай байланысты екенін анықтауы керек. Және, әрине, мен ресми презентацияларды немесе сол сияқты нәрсені білдірмеймін. Мен әріптестермен жұмыстың сіз жауапты бөлігі туралы ғана емес, жалпы жұмыс туралы сөйлесуіңіз керек екендігі туралы айтып отырмын. Бұл жерде сіз идеяларды, жұмысыңызды бір-бірімен жақсы үйлестіру үшін ортақ келісімдерді және ортақ мәселені қалай бірге шешуге болатынын талқылауды бастай аласыз.
Оларға бейімделуге көмектесу үшін олар көбінесе техникалық мамандарды тренингке жібергісі келеді және олар оқытуды талқылайды. Менің бір досым жаттығу иттерге арналған деп айтқанды ұнатады. Адамдарға арналған тренингтер бар. Әзірлеуші ретінде үйренудің ең жақсы нәрселерінің бірі - құрдастарыңызбен қарым-қатынас жасау. Егер біреу бірдеңеде шынымен жақсы болса, сіз оның жұмысын бақылаңыз немесе олармен жұмысы туралы немесе бір нәрсе туралы сөйлесіңіз. Кейбір кәдімгі Кент Бек үнемі экстремалды бағдарламалау туралы айтты. Бұл күлкілі, өйткені XP өте қарапайым идея, бірақ ол көптеген мәселелерді тудырады. Кейбіреулер үшін XP жасау достардың алдында жалаңаштануға мәжбүрлеу сияқты. Олар менің не істеп жатқанымды көреді! Олар менің әріптестерім, олар көріп қана қоймай, түсінеді! Қорқынышты! Кейбір адамдар қатты қобалжи бастайды. Бірақ бұл оқудың соңғы жолы екенін түсінгенде, бәрі өзгереді. Сіз адамдармен тығыз жұмыс жасайсыз, ал кейбір адамдар тақырыпты сізден әлдеқайда жақсы түсінеді.
Майкл: Бірақ мұның бәрі сізді жайлылық аймағынан шығуға мәжбүр етеді. Инженер ретінде сіз өзіңіздің жайлылық аймағыңыздан шығып, қарым-қатынас жасауыңыз керек. Мәселені шешуші ретінде сіз үнемі өзіңізді әлсіз жағдайға қойып, ненің дұрыс емес болуы мүмкін екенін ойлауыңыз керек. Жұмыстың бұл түрі табиғи түрде ыңғайсыздық туғызу үшін жасалған. Сіз өзіңізді стресстік жағдайларға саналы түрде түсіресіз. Әдетте адамдар олардан қашады, адамдар бақытты бала болғанды ұнатады.
Тим: Не істеуге болады, сіз шығып, ашық айта аласыз: «Бәрі жақсы, менің қолымнан келеді! Өзімді жайсыз сезінетін жалғыз мен емеспін. Әртүрлі ыңғайсыз нәрселерді бірге, топ болып талқылайық!» Бұл біздің ортақ проблемаларымыз, біз олармен күресуіміз керек, білесіз бе? Менің ойымша, идиосинкратикалық гений әзірлеушілер мамонттарға ұқсайды, олар жоғалып кетті. Ал олардың маңызы өте шектеулі. Егер сіз сөйлесе алмасаңыз, сіз жақсы қатыса алмайсыз. Сондықтан жай ғана сөйле. Адал және ашық болыңыз. Бұл біреу үшін жағымсыз болғаны үшін қатты өкінемін. Сіз елестете аласыз ба, көптеген жылдар бұрын Америка Құрама Штаттарындағы басты қорқыныш өлім емес, зерттеу болды, бірақ нені болжаңыз? Көпшілік алдында сөйлеуден қорқу! Бұл бір жерде дауыстап мақтаудан гөрі өлгенді ұнататын адамдар бар дегенді білдіреді. Менің ойымша, сізде не істеп жатқаныңызға байланысты кейбір негізгі дағдылардың болуы жеткілікті. Сөйлеу дағдылары, жазу дағдылары - бірақ сіздің жұмысыңызда шынымен қажет болғанша ғана. Егер сіз аналитик болып жұмыс істесеңіз, бірақ оқи алмасаңыз, жаза алмасаңыз немесе сөйлей алмасаңыз, өкінішке орай, менің жобаларымда сізде ештеңе болмайды!
Байланыс бағасы
Олег: Мұндай жұмыстан кеткен қызметкерлерді жұмысқа алу әртүрлі себептермен қымбатырақ емес пе? Өйткені, олар жұмыс істеудің орнына үнемі сөйлеседі!
Тим: Мен барлығын емес, команданың өзегін айттым. Егер сізде дерекқорларды баптауды жақсы көретін, дерекқорларды баптауды ұнататын және сіздің деректер қорыңызды баптауды өмірінің соңына дейін жалғастыратын адам болса, бәрі жақсы, оны жалғастырыңыз. Бірақ мен жобаның өзінде өмір сүргісі келетін адамдар туралы айтып отырмын. Жобаны әзірлеуге бағытталған команданың өзегі. Бұл адамдар шынымен де бір-бірімен үнемі байланыста болуы керек. Және әсіресе жобаның басында тәуекелдерді, жаһандық мақсаттарға жету жолдарын және т.б.
Майкл: Бұл мамандыққа, дағдыларға немесе жұмыс тәсілдеріне қарамастан жобаға қатысатын әрбір адамға қатысты. Барлықтарыңызды жобаның табысты болуы қызықтырады.
Тим: Иә, сіз жобаға жеткілікті түрде еніп кеткеніңізді, сіздің міндетіңіз жобаны жүзеге асыруға көмектесу екенін сезінесіз. Сіз бағдарламашы, аналитик, интерфейс дизайнері, кез келген адам болсаңыз да. Күнде таңертең жұмысқа келетін себебім және біз осылай істейміз. Біз бұл адамдардың барлығына, олардың біліктілігіне қарамастан жауаптымыз. Бұл ересектермен сөйлесетін адамдар тобы.
Олег: Шындығында, әңгімешіл қызметкерлер туралы айта отырып, мен адамдардың, әсіресе, devops-қа ауысуды сұрайтын менеджерлердің әлемге деген жаңа көзқарасына қарсылық білдіруге тырыстым. Ал сіз кеңесшілер ретінде бұл қарсылықтарды әзірлеуші ретінде маған қарағанда жақсырақ білуіңіз керек! Менеджерлерді не алаңдатады, бөлісіңіз бе?
Тим: Менеджерлер? Хм. Көбінесе менеджерлер проблемаларға байланысты қысымға ұшырайды, тез арада бір нәрсені босату және жеткізу және т.б. Олар біздің бір нәрсені қалай үнемі талқылап, дауласып жатқанымызды бақылап отырады және олар оны былай көреді: әңгіме, әңгіме, әңгіме... Тағы қандай әңгіме? Жұмысқа оралыңыз! Өйткені олар үшін сөйлесу жұмыс сияқты емес. Сіз код жазбайсыз, бағдарламалық жасақтаманы сынамайсыз, ештеңе істемейтін сияқтысыз - неге сізді бірдеңе жасауға жібермеске? Өйткені, жеткізу бір айдан кейін!
Майкл: Біраз код жазыңыз!
Тим: Меніңше, оларды жұмыс емес, ілгерілеудің көрінбейтіндігі алаңдатады. Табысқа жақындап келе жатқандай көріну үшін олар пернетақтадағы түймелерді басқанымызды көруі керек. Таңертеңнен кешке дейін күні бойы. Бұл бірінші мәселе.
Олег: Миша, сен бірдеңе ойлап отырсың.
Майкл: Кешіріңіз, мен ойға кетіп қалдым және есте қалдым. Осының бәрі кеше болған бір қызық митингті есіме түсірді... Кеше митингілер тым көп болды... Және бәрі өте таныс естіледі!
Жалақысыз өмір
Тим: Айтпақшы, байланыс үшін «митингтерді» ұйымдастырудың қажеті жоқ. Айтайын дегенім, әзірлеушілер арасындағы ең пайдалы пікірталас олар бір-бірімен сөйлескенде болады. Сіз таңертең бір шыны кофемен кіресіз, бес адам жиналып, техникалық нәрсені қызу талқылап жатыр. Мен үшін, егер мен осы жобаның менеджері болсам, жай ғана күлімсіреп, өз ісім туралы бір жерге барғаным дұрыс, олар оны талқыласын. Олар қазірдің өзінде мүмкіндігінше тартылған. Бұл жақсы белгі.
Олег: Айтпақшы, сіздің кітабыңызда ненің жақсы, ненің жаман екендігі туралы көптеген жазбалар бар. Сіз олардың кез келгенін өзіңіз пайдаланасыз ба? Салыстырмалы түрде айтатын болсақ, қазір сізде компания бар және ол әдеттен тыс түрде құрылымдалған ...
Тим: Ортақ емес, бірақ бұл құрылғы бізге өте қолайлы. Біз бір-бірімізді бұрыннан танимыз. Біз бір-бірімізге сенеміз, серіктес болмас бұрын бір-бірімізге қатты сенетінбіз. Ал, мысалы, бізде жалақы мүлдем жоқ. Біз жай ғана жұмыс істейміз, мысалы, мен өз клиенттерімнен ақша тапсам, онда барлық ақша маған кетті. Одан кейін ұйымға мүшелік жарна төлейміз, бұл компанияның өзін қамтамасыз етуге жетеді. Сонымен қатар, біз бәріміз әртүрлі нәрселерге маманданамыз. Мысалы, мен бухгалтерлермен жұмыс істеймін, салық декларациясын толтырамын, компанияның әр түрлі әкімшілік істерін жасаймын, ол үшін маған ешкім ақша төлемейді. Джеймс пен Том біздің веб-сайтта жұмыс істейді және оларға ешкім ақша төлемейді. Сіз жарнаңызды төлесеңіз, сізге не істеу керек екенін ешкім айтуды ойламайды. Мысалы, Том қазір бұрынғыдан әлдеқайда аз жұмыс істейді. Енді оның басқа мүдделері бар; ол Гильдия үшін емес, кейбір нәрселерді жасайды. Бірақ ол жарнасын төлегенше, оған ешкім келіп: «Әй, Том, жұмысқа кет!» Демейді. Араларыңызда ақша болмаған кезде әріптестермен қарым-қатынас жасау өте оңай. Ал енді біздің қарым-қатынасымыз әртүрлі мамандықтарға қатысты іргелі идеялардың бірі болып табылады. Бұл жұмыс істейді және ол өте жақсы жұмыс істейді.
Ең жақсы кеңес
Майкл: «Ең жақсы кеңеске» оралу, сіз өзіңіздің клиенттеріңізге қайта-қайта айтатын нәрсе бар ма? 80/20 туралы идея бар, кейбір кеңестер жиі қайталанатын шығар.
Тим: Мен бір кездері «Аюлармен вальс» сияқты кітап жазсаңыз, тарихтың бағыты өзгеріп, адамдар тоқтап қалады деп ойладым, бірақ... Қараңызшы, компаниялар көбіне оларда бәрі жақсы деп кейіп танытады. Жаман нәрсе бола салысымен олар үшін таң қалдырады. «Міне, біз жүйені сынадық, ол жүйелік сынақтардан өтпеді, бұл тағы үш айлық жоспардан тыс жұмыс, бұл қалай болуы мүмкін? Кім білген? Не қате болуы мүмкін? Шынымды айтсам, бұған сенесіз бе?
Мен қазіргі жағдайға қатты ашуланбау керектігін түсіндіруге тырысамын. Біз бұл туралы сөйлесіп, ненің дұрыс емес болуы мүмкін екенін және болашақта мұндай жағдайлардың алдын алудың жолын түсінуіміз керек. Егер мәселе туындаса, онымен қалай күресеміз, оны қалай ұстаймыз?
Маған мұның бәрі қорқынышты болып көрінеді. Адамдар күрделі, тітіркендіретін мәселелермен айналысады және егер олар саусақтарын айқастырып, жақсылыққа үміттенсе, «жақсы» іс жүзінде болады деп сынауды жалғастырады. Жоқ, олай жұмыс істемейді.
Тәуекелдерді басқаруды үйреніңіз!
Майкл: Сіздің ойыңызша, тәуекелдерді басқарумен қанша ұйым айналысады?
Тим: Менің ашуымды келтіретіні, адамдар тәуекелдерді жазып алып, алынған тізімге қарап, жұмысқа кіріседі. Шын мәнінде, олар үшін тәуекелдерді анықтау тәуекелді басқару болып табылады. Бірақ маған бұл сұрақ қоюға себеп болып көрінеді: жарайды, тізім бар, сіз нақты нені өзгертесіз? Осы тәуекелдерді ескере отырып, стандартты әрекеттер тізбегін өзгерту керек. Егер жұмыстың ең қиын бөлігі болса, оны шешу керек, содан кейін ғана қарапайым нәрсеге көшу керек. Алғашқы спринттерде күрделі есептерді шешуге кірісіңіз. Бұл қазірдің өзінде тәуекелдерді басқару сияқты көрінеді. Бірақ әдетте адамдар тәуекелдер тізімін жасағаннан кейін не өзгергенін айта алмайды.
Майкл: Дегенмен, осы компаниялардың қаншасы тәуекелдерді басқарумен айналысады, бес пайызы?
Тим: Өкінішке орай, мен мұны айтуды жек көремін, бірақ бұл өте маңызды емес бөлік. Бірақ бестен көп, өйткені шын мәнінде үлкен жобалар бар және олар кем дегенде бірдеңе жасамаса, олар өмір сүре алмайды. Ең болмағанда 25 пайыз болса, қатты таң қаламын дейміз. Шағын жобалар әдетте мұндай сұрақтарға жауап береді: егер мәселе бізге әсер етсе, біз оны шешеміз. Содан кейін олар проблемаға сәтті кірісіп, проблемаларды басқару және дағдарысты басқарумен айналысады. Мәселені шешуге тырысқанда және мәселе шешілмесе, дағдарысты басқаруға қош келдіңіз.
Иә, мен «мәселелер туындаған кезде шешеміз» дегенді жиі естимін. Әрине жасаймыз ба? Біз шынымен шешеміз бе?
Олег: Сіз мұны аңғал түрде жасай аласыз және жоба жарғысына маңызды инварианттарды жай жаза аласыз, ал инварианттар бұзылса, жобаны қайта бастаңыз. Бұл өте қызық болып шығады.
Майкл: Иә, тәуекелдер туындаған кезде жоба жай ғана қайта анықталатын болды. Жақсы, бинго, мәселе шешілді, енді уайымдамаңыз!
Тим: Қалпына келтіру түймесін басайық! Жоқ, олай жұмыс істемейді.
DevOops 2019 негізгі баяндамасы
Майкл: Біз бұл сұхбаттың соңғы сұрағына келдік. Сіз келесі DevOops бағдарламасына негізгі баяндамамен келе жатырсыз, сіз не айтқыңыз келетіні туралы құпия шымылдықты көтере аласыз ба?
Тим: Дәл қазір олардың алтауы еңбек мәдениеті, ұйымдардың айтылмаған ережелері туралы кітап жазып жатыр. Мәдениет ұйымның негізгі құндылықтарымен анықталады. Әдетте адамдар мұны байқамайды, бірақ көп жылдар бойы кеңес беруде жұмыс істегендіктен, біз оны байқап қалғанбыз. Сіз компанияға кіресіз және бірнеше минут ішінде сіз не болып жатқанын сезіне бастайсыз. Біз мұны «дәм» деп атаймыз. Кейде бұл хош иіс шынымен жақсы, ал кейде бұл, жақсы, ой-пікір. Әр түрлі ұйымдар үшін бәрі әртүрлі.
Майкл: Мен де көптеген жылдар бойы кеңес беру саласында жұмыс істеп келемін және сіз айтып отырғаныңызды жақсы түсінемін.
Тим: Шындығында, негізгі баяндамада айта кететін нәрселердің бірі - барлығын компания анықтамайды. Сізде және сіздің командаңызда қауымдастық ретінде өз командалық мәдениетіңіз бар. Бұл бүкіл компания немесе бөлек бөлім, бөлек команда болуы мүмкін. Бірақ сіз айтпас бұрын, біз сенеміз, міне, маңызды нәрсе... Белгілі бір әрекеттердің артында тұрған құндылықтар мен сенімдер түсінілмейінше, сіз мәдениетті өзгерте алмайсыз. Мінез-құлықты байқау оңай, бірақ сенімдерді іздеу қиын. DevOps - бұл заттардың барған сайын күрделене түсуінің тамаша мысалы. Өзара әрекеттесулер тек күрделене түсуде, олар таза немесе мүлде анық бола бермейді, сондықтан сіз не сенетініңіз және айналаңыздағылардың бәрі не туралы үндемейтіні туралы ойлануыңыз керек.
Егер сіз жылдам нәтижеге қол жеткізгіңіз келсе, бұл сізге жақсы тақырып: сіз ешкім «білмеймін» демейтін компанияларды көрдіңіз бе? Адам бірдеңе білмейтінін мойындамайынша, оны азаптайтын жерлер бар. Барлығы бәрін біледі, бәрі керемет эрудит. Сіз кез келген адамға жақындайсыз және ол сұраққа бірден жауап беруі керек. «Білмеймін» деудің орнына. Ура, олар бір топ эрудитті жалдады! Кейбір мәдениеттерде «білмеймін» деп айту өте қауіпті, оны әлсіздік белгісі ретінде қабылдауға болады. Керісінше, барлығы «білмеймін» деп айта алатын ұйымдар да бар. Мұнда бұл толығымен заңды және егер біреу сұраққа жауап ретінде қоқыс айта бастаса, бұл қалыпты жағдай: «Сіз не туралы айтып жатқаныңызды білмейсіз бе?» және мұның бәрін әзілге айналдырыңыз.
Ең дұрысы, сіз үнемі бақытты бола алатын жұмысыңыз болғанын қалайсыз. Бұл оңай болмайды, әр күн шуақты және жағымды емес, кейде көп жұмыс істеу керек, бірақ түгендеуді бастағанда, ол шығады: уау, бұл шынымен керемет жер, мен мұнда жұмыс істегенімді жақсы сезінемін, эмоционалды және интеллектуалды. Сондай-ақ кеңесші ретінде баратын компаниялар бар және сіз үш ай бойы шыдай алмай, қорқынышпен қашып кететініңізді бірден түсінесіз. Бұл туралы баяндамада айтқым келеді.
Тим Листер негізгі баяндамамен келеді 2019 жылдың 29-30 қазанында Санкт-Петербургте өтетін DevOops 2019 конференциясына. Билеттерді сатып алуға болады . Біз сізді DevOops-та күтеміз!
Ақпарат көзі: www.habr.com