Transcription
Вся правда о работе в IT-компаниях.
На курсах, а также во всяких онлайн-школах этого вам не расскажут. Дело в том, что многие не говорят правду о том, как всё во IT устроено на самом деле. Часто рассказывают теорию или идеальную ситуацию, при этом сами не работают каждый день в этом.
Поэтому сегодня я покажу рабочие процессы, как всё выглядит в джире на практике. Что за доски, что за таски, что с ними делать, когда выполнил задачу, как списывать время. В общем, всё то, что айтишники делают на работе ежедневно. И запомните, если у вас на собеседовании спросят: "А как у вас была организована работа в команде?" Моё видео точно вам пригодится, потому что я покажу всю правду про внутрянку в IT так, как оно выглядит на самом деле, со всеми минусами и плюсами.
Для начала необходимо разобраться, а что такое GR? GRA - это веб-инструмент для управления проектами и задачами. Это стандартный софт, который используют все или почти все IT-компании. Крайне важно иметь какие-то базовые навыки работы с ней. Ведь у специалиста с коммерческим опытом есть такие навыки. И для компании будет крайне странно, если вы потеряетесь и не сможете найти задачу, которую вам выдали.
Вот я открыл сейчас доску в Джири. Доска - это представление задач, сгруппированных по статусам или этапам работы. Тут же я могу увидеть членов своей команды и себя. Сейчас тут только я, но в реальности народа будет много. На доске есть задача создать форму обратной связи. Она сейчас находится в статусек. Бэклок - это список задач, которые ещё не в работе, но их можно брать в работу в будущем. Когда я решаю, что мне пора взять эту задачу, я беру её в работу, перетаскивая её в другой статус на реализации. Теперь любой член команды может увидеть, над чем я работаю прямо сейчас. Когда же я уже сделал задачу, я перетаскиваю её в статус "Готова к тестированию" и при этом списываю время, например, 8 часов. Изначально исполнителем задачи был я, но так как я разработчик, а не тестировщик, я должен сменить исполнительно задачи на ответственного тестировщика. После чего он уже на своей доске может увидеть, что можно брать эту задачу в работу. Иногда исполнитель автоматически меняется средствами джира и не приходится делать это вручную. Теперь, когда тестировщик будет готов взять задачу на тестирование, он передвигает её в статус в тестировании. Дальше уже два варианта. Если всё хорошо, то задача сдвигается в статус выполнена. Если нет, то задача возвращается назад тебе в бэклок с комментарием о тестировщика.
В принципе, я сейчас показал 99% того, как работают с джирой. обычные разработчики. Но как задачи попадают в бэклок? Кто занимается сбором требований, что такое методология, спринты? Это всё очень важно знать на уровне теории. То есть тебе не придётся наполнять бэклок и запускать спринты. Это делают другие люди. Но знать, как оно работает, надо.
Новички, кто не знаком с такими понятиями, как СМА, Adжаile, думают, что разработка выглядит следующим образом. Приходит бизнес в компанию и говорит, что ему надо. Далее составляется техническое задание. И потом по этому Тузе все работают и от него не отклоняются. И такая методология есть. Она старая, сейчас используется крайне редко и называется тел, водопад. Её общая идея в том, что каждый этап разработки идёт друг за другом последовательно, нет отклонения назад. То есть, если составили ТЗ, его согласовали, то это всё, изменить его нельзя. Разрабатываем чётко по ТЗ, не отклоняясь от него ни на шаг.
Кстати, по всему, что я сейчас рассказываю, я сделал шпаргалку. Эта шпаргалка будет в моём Telegram-канале. Сохрани у себя. Если вдруг что-то забудешь, сможешь быстро вспомнить.
В реальности, конечно, случаются моменты, когда логика по ТЗ может не соответствовать тому, что хочет бизнес. В этом случае обычно компании идут друг другу навстречу. Если там какая-то мелочь, то на договорничках меняют логику так, как хочет бизнес. Это классическая методология, но у неё есть минусы. Заказчик обычно слабо представляет, что ему надо. Он знает, что он хочет получить в конце, но каким образом до этого конца дойти, как обходить какие-то крайние случаи, он не знает. Он хочет прийти в компанию так, чтобы ему помогли с реализацией всего. Очень много нюансов всплывает в процессе, о которых бизнес даже понятия не имеет. Если вдруг бизнес знает, что ему надо, то на сбор требований, составления и согласования ТЗ уходят месяцы. В это время разработка не ведётся, а как известно, всем надо всё вчера. Работающее и без багов. Хочется этот процесс как-то ускорить.
Поэтому группа людей ещё в 2001 году решила придумать новый подход, который бы решил эти проблемы бизнеса. И назвали они его Agile это набор из четырёх ценностей и двенадцати принципов, которые я перечислять не буду, но ты их можешь посмотреть в шпаргалки в моём Телеграме. Но я расскажу об одном, и ты поймёшь общую суть. Работающее решение важнее документации. Это один из постулатов. Его суть заключается в том, что мы не составляем подробное ТЗ в начале, мы сразу разрабатываем продукт. Естественно, в процессе появляются проблемы. Вы что-то сделали, а бизнес хотел по-другому. Придётся переделывать, и это нормально. Это часть такого подхода. Будем вносить изменения в продукт столько раз, сколько потребуется. Но этот подход как раз решает все проблемы бизнеса. Проект начинает разрабатываться быстро, и большинство, в том числе и сам бизнес, слабо представляют, что будут в конце. Но разработка и аналитика не стоят на месте. Все что-то делают, шестерёнки крутятся. И вот такой подход к разработке прижился в нашем современном мире. И так работает большинство компаний.
А теперь про Скрам. Вот Скрам - это уже методология разработки, основанная на принципах Ажайл. Для простоты понимания, Agile - это интерфейс, а скрам - это реализация этого интерфейса. В скраме описаны конкретные способы взаимодействия внутри команды и заказчиком. То есть все спринты, дейлики, рефайменты, груминги, планинги, демо, ретроспективы. Это всё про скрам.
Когда клиент приходит за решением, у него есть свои бизнес-требования. Эти требования необходимо собрать с клиента. Но этим должен заниматься отдельный человек. Не разработчик же это будет делать. Этим занимается продукт-менеджер. Его задача - определить желание бизнеса, наметить цели проекта и его приоритеты. Он напрямую общается с бизнесом на языке бизнеса и выступает посредником между клиентом и командами разработки. Команд разработки может быть много. В том же банке есть отдельная команда, которая занимается кредитами, отдельная команда, которая занимается пенсиями, отдельная команда, которая занимается выпуском кредитных и дебетовых карт. И таких команд десятки, а то и сотни. И как один продукт-менеджер должен следить за каждой командой, каждой команде создавать задачи и переводить бизнес-запрос в какое-то ТЗ и требование. Очевидно, у него не хватит времени.
Поэтому придумали ещё одну роль. Прожект-менеджер, менеджер проекта. Его задача - собрать бизнес-трелебования с продукт-менеджера и перевести их в требования по разработке. Он отвечает за сроки, ресурсы проекта, бюджет проекта, может ставить задачи на разработку, может управлять аналитиками. То есть в отличие от продукт-менеджера, он фокусируется на управлении процессом. реализации проекта. Он же и занимается наполнением бэклога, но делает он это не один. В этот этап уже может подключаться и аналитик, потому что для составления задачи на разработку порой необходимо произвести аналитическую работу, которую делает аналитик, и описать её технически. Это уже сделает. Обычно один проject-менеджер привязан к одной команде.
Ещё есть такая позиция, как- это уже разработчик, который решил поуправлять командой. Часто он делает ревю кода, он же ведёт дейки, занимается наполнением бэклога, помогает с проблемами разработчиков, делает водные для новичков, ищет новых членов команды и проводит собеседование.
В идеальной ситуации оно происходит вот так. Но лично у меня никогда не было такой структуры, о которой я сейчас говорю. Вот история из моего личного жизненного опыта. У нас на проекте не было продукт-менеджера и прокт-менеджера. Был только аналитик и тимлит. Они вместе общались с клиентом, вместе собирали требования, анализировали их. Потом аналитика всё достала, и он уволился. В итоге всех заменил один Тимлит, и это устраивало всех, кроме Тимлида. А потом уволился Тимлит, и какое-то время команда существовала без него. Наверное, у тебя сразу возникает вопрос: а кто общался с заказчиком? Кто создавал задачи? Ответ тут никто и все сразу. Был полный бардак и анархия. Кто-то что-то делал, кто-то вообще ничего не делал. С заказчиком никто не общался, и всем было пофиг. Но не могло же руководство оставить это всё без внимания. Думаешь, нам быстренько нашли нового Тимледа и аналитика? Нам нашли только Тимледа, который опять же делал вообще всё. Запросы на Аналитика-то были. Руководство говорило, что да, мы ищем. В итоге никто никого не нашёл. А зачем? Есть же бедолага Тимлит, который делает всю работу за всех и всех всё устраивает. Вот она реальность. Зачем нанимать много позиций, если можно найти одного чувака, который будет делать вообще всё? Всё упирается в деньги.
Кто не знал, в скраме есть отдельная позиция скраммастер. Его задача - проводить все скрам-мероприятия по всем правилам. Условно, если кто-то на дейли слишком долго рассказывает о своей задаче, то он его перебьёт и скажет: "Стоп, стоп, стоп, не будем затягивать делик, у нас на него всего 5 минут. Обсудим это позже". Я не понимаю, откуда у него загрузка на все восемь рабочих часов. Ощущение такое, что он работает по часу в день. И по ходу компании думают также, потому что ни у меня, ни у моих знакомых никогда не было скраммастера. Хотя по всем канонам скрама он должен быть. Это бы снизило определённую нагрузку стимлида, но снова всё упирается в деньги. Именно по этой причине в книжке всё написано определённым образом, а приходишь в компанию и там всё вообще не так. Если у кого-то было так же или что-то похожее, или у вас в команде есть кроммастер, то напишите об этом в комментариях. Посмотрим, сколько вас.
Теперь у вас должно сложиться понимание того, как требования бизнеса попадает в бэклок и кто за что ответственен. Поэтому можно перейти уже к скраму, а в нём есть такое понятие, как спринт. Спринт - это промежуток времени, одна или 2 недели, чаще всего 2 недели, за которые команда должна полностью сделать определённый функционал. Такой спринтовый подход позволяет постоянно отгружать новые фичиваться ими перед менеджерами и бизнесом. Все видят, что вы что-то сделали, что вы поработали. И так как заказчик всё видит наглядно, он может внести корректировки, сказать: "Вот, ребят, я хотел не просто 2D карту на этой странице увидеть, а я хотел прямо планету, чтобы она тридэшная была и я мог её крутить как угодно и чтобы я ещё и 3D очки надел, и она вот прямо перед глазами у меня была. Ну и придётся переделывать всё в следующем спринте на 3D-планету, чтобы он был доволен. Ведь пожаile самая главная цель - это удовлетворение заказчика. Клиент всегда прав.
И вот начался новый спринт. Что происходит на этом этапе? Вы всей командой, обычно она по размеру небольшая, человек 5-10, созваниваетесь и начинаете этап планирования. Ммлит начинает показывать экран с бэклогом задач. На планировании вы распределяете задачи на текущий спринт. На этом этапе все задачи подготовлены, они проработаны аналитиком и описаны. У них есть оценка по времени, то есть их уже можно брать и начинать делать. По времени планирование длится около часа, хотя может и затянуться. Но хороший менеджмент понимает, как обычные работяги не любят сидеть на созвонах и всё это слушать. Так что стараются провести всё это как можно быстрее, но не в ущерб качеству. В конце планирования стартует новый спринт и закрывается старый.
На этом этапе Тимледу важно загрузить разработчика на полную, и он руководствуется доступными человека-часами. Спринт длится 2 недели. Одному человеку можно выдать задач на 80 человека часов, так как у нас 10 рабочих дней. Каждый по 8 часов, значит 80. Основная задача Тимледа здесь оптимально распределить задачи между командой. Например, если ты работал над сущностью книга, то логичнее всего именно тебе дать задачу, которая будет связана с этой сущностью книга. Но в реальной ситуации так не получается. Банально кто-то ушёл в отпуск, заболел или тимлить так решил. Поэтому ты можешь получить задачу, которая не особо связана с твоей частью кода. В реальной практике ты обычно не пишешь один свой микросервис, ты пишешь один свой микросервис, плюс ещё везде помаленьку. Вообще Agile - это про огромное количество командного взаимодействия, про общению между людьми. Так что, рассказывая про свой опыт работы, нельзя говорить, что я только одним микросервисом занимался, писал круды и всё. Больше ничего не знаю. Хотя бы пару предложений об общей логике, о том, что мог бы делать твой коллега, ты должен сказать.
Ну и самая нелюбимая и ненавистная часть большинства айтишников - это Дейлик. Дейлик - это то, с чего начинается твой день. Проходит он обычно с утра часов 10-11 каждый рабочий день. Цель Делика - рассказать о том, чем ты занимался вчера, чем ты будешь заниматься сегодня и есть ли у тебя блокеры. Блокер - это проблема, которая тебе не позволяет выполнить текущую задачу. Например, я сделал запрос на то, чтобы мне выдали VPN для доступа к стенду, а мне его не выдали. Обычно Dicт довольно уныло и рутинно. Все недавно проснулись, ещё не могут понять, где они находятся и зачем вообще сюда пришли, а их уже спрашивают, как дела.
Опишу, как выглядит типовой дейлик в реальности. Дейлик по плану начинается в 10:00 утра, а по факту в 10:02, так как кто-то опоздал, а Тимлит добрый и всех ждёт. Возможно, сам Тимлит опоздал. Потом он начинает шарить экран, на котором будет доска. На этой доске будет отображена вся команда. Кликнув на тебя, отображаются твои задачи и их статус выполнения. Далее задаётся вопрос: "Как твои дела? Расскажи о задачах". И ты начинаешь. Я делаю задачу номер 515. Сегодня планирую закончить и взять задачу 518. Блокеров нет. И так делает каждый член команды. Бэкэнндеры, фронтендеры, мобильные разработчики, тестировщики, аналитики. Сам тимлит. Каждый рассказывает, чем он занимался, чем будет заниматься и есть ли у него проблемы. Есть команды, где на дейликах все более подробнее рассказывают, более конкретно говорят, что они делали, с какими проблемами столкнулись. И твоя основная задача будет копировать их поведение на делике, то есть быть своим. В идеале продумать то, о чём ты будешь говорить на Делике заранее, так как на подобных вещах палиться тебе вообще нельзя. Если ты мидл, говори как мидл, а Мидл говорит так, как говорят остальные члены команды. Повторяй за ними.
В идеале Делик должен длиться минут 10, и за этим следит Тимлит. Но бывают команды, где Делики затягиваются. так как доходят до чувака, у которого проблемы, и он вместо того, чтобы решить проблему отдельно с кем-то отдельно созвониться, начинает их решать здесь. И подключаются другие люди, начинают ему помогать, и это всех бесит. Представь ситуацию, ты бэкэндер, а у чувака на фронте проблемы, и он начинает свои фронтвые проблемы решать, показывать дизайн и это на 20 минут. Поэтому у многих к дейликам негативные отношение, так как ты, в принципе, слабо понимаешь, что делают твои коллеги, особенно которые не в твоём стеке. Честно говоря, ты и не хочешь в это вникать. Во время Делика у тебя какой-то белый шум, и единственное, что ты слышишь - это концовку "Всем спасибо, всем хорошего дня".
Ну а если вдруг ты увлекаешься Java разработкой, ищешь себе ментора, хочешь выйти сразу на медла, на хорошую зарплату, хочешь, чтобы тебе составили конкурентное резюме и научили отвечать за опыт в этом резюме, то можешь обратиться ко мне. Я занимаюсь менторингом уже 2 с2 года. У меня большой упор идёт не только на натаскивание, на успешное прохождение собеседования, но и на учёбу. Мне важно, чтобы мой студент комфортно чувствовал себя на испытательном сроке. А если возникнут трудности, то я буду на связи и помогу. Основной платёж у меня происходит только после твоего успешного трудоустройства. Если трудоустроишься на зарплату меньше, чем указано в договоре, то ничего не платишь. Моя цель - помочь тебе стать не просто медлом на бумаге, но и медлом по факту.
Теперь о рефанменте. Он же груминг- это процесс, который обычно происходит раз в неделю, на котором присутствует вся команда. Задача этого процесса - обсудить задачи, приоритизировать их, уточнить и дать оценку в часах или сторипоинтах. По длительности - это час полтора. AMлиit начинает шарить экран, на котором открывает бэклоп, открывает какую-то задачу, рассказывает всем, что надо сделать, и происходят обсуждения. Подключаются ответственные люди, на которых, скорее всего, перепадёт эта задача. Они начинают задавать вопросы, всё уточнять, говорить, как сделать лучше. Вся остальная команда просто сидит с выключенными микрофонами. В большей части белый шум в ушах.
Когда обсуждение заканчивается, её начинают оценивать. Оценивать можно в часах. Это понятный всем подход, но оценивает задачу не один разработчик, а вся команда разработки. Ну, естественно, если ты фронтендер, а задача на эээкэнд, никто не будет с тебя просить оценку. Оценивать будет команда бэкэнда. Каждый по очереди называет время, за которое бы он сделал задачу. Далее, если есть расхождение, начинается обсуждение, почему ты оценил задачу на 20 часов, а Петя на 8 часов. Ну и как-то пытаются прийти к единому мнению, сколько часов неё поставить. В идеале все пишут время анонимно на какую-то карточку. Как все проставят время, эти карточки переворачиваются и берут среднюю оценку.
Бывает, что оценку задач делают в сторипоинтах, и лично мне такой формат нравится больше. Storypint - это такая сравнительная абстрактная характеристика для оценки задачи. Сторипоинты могут принимать значения по числам Фибонач, то есть 1 2 3 5 8 и так далее. И это не то же самое, что и часы. Например, есть задача добавить в какую-то сущность поля комментарий. Задача очень простая, это один сторит. Есть задача, где необходимо добавить поле, и для него есть множество проверок, которые значительно сложнее, чем просто добавить поле комментарии. Это два сторипоинта. Раз задача посложнее, но не сильно. Если задача, где необходимо добавить целую новую сущность - это три сторипоинта, так как это сложнее, чем задача на два сторипоинта. Ну, общая идея, наверное, прослеживается. Если задача сложнее, чем та задача, которая на два сторипоинта, но легче, чем та задача, которая на пять сторипоинтов, то это три сторипоинта. Если же задача от восьми сторипоинтов и выше, то, вероятнее всего, эту задачу необходимо разделять на несколько, так как возникает множество вопросов, которые необходимо ещё прорабатывать аналитику. Ну и вообще сторипоинты лучше, чем часы, потому что это абстракция, а любая абстракция не устанавливает точных границ. Два сторинта - это сколько? 4 часа, 1 день или полтора дня, непонятно. То есть разработчику проще оценивать задачу, так как выше шанс того, что он уложится в сроки, так как граница сроков размыта.
После того, как пройдёт парочка первых спринтов, ближе к третьему, четвёртому спринту, у менеджмента будет понимание того, сколько сторипоинтов может успеть сделать команда за спринт. Ну то есть команда делает 80 стори поинтов за спринт, значит, на планировании всем раскидаем задач на 80 сторипоинтов. Многие на Ютубе высказываются про сторипоинты в негативном ключе, но это скорее от непонимания, зачем оно надо. А по сути оценивать задачи легче, а понять, что ты не уложился в срок, тяжелее, так как нет чётких границ, в отличие от оценки в часах.
Теперь момент про баги. Что происходит, если задачи уже запланированы, они оценены в какое-то время и возник баг, заводится новый тикет, и чаще всего он фиксится в рамках текущего спринта. Но получается, к нашим уже расписанным часам добавляется новая задача, что влияет на сроки, и они сдвигаются. Поэтому какая-то фича переносится на новый спринт, либо вас будут просить поторопиться и быстрее-быстрее всё сделать, чтобы успеть к демо.
Демо - это тоже скрампроцесс, который происходит один раз за спринт, ближе к концу недели, обычно в предпоследний или последний день. Задача демо - продемонстрировать заказчику то, что команда сделала за текущий спринт, то есть успокоить заказчика и менеджмент, чтобы у них сложилось понимание, что работа ведётся. Вообще на демо должна участвовать вся команда, и вся команда разработки показывает функционал, который она сделала за спринт, но везде сильно по-разному. Если есть большой проект с множеством команд, то там демо может состоять из того, что сделали в спринтах вообще разные команды и в звонке сидит человек 50. Экран на демо обычно показывает тот, кто хорошо разбирается в системе. Это может быть тестировщик, продукт овнер или все остальные сидят и молчат, а кто-то вообще не приходит. Присутствие на демо больше по желанию. Но если ты недавно в компании, то ходи на все активности.
У меня бывали проекты, где не было заказчиков. Заказчиком выступала сама компания, надеясь на то, что потом проект удастся кому-нибудь продать. От компании заказчик как бы был, но его видело вообще очень мало людей, и он не сильно участвовал во всём. Поэтому мы демо проводили внутри команды сами. Просто начинали показывать экран и рассказывали, кто что сделал. Выходило довольно странно. В случае с фронтендерами ещё нормально, там всё наглядно, а вот на бэкэнде демо заключалась в том, что ты постманом просто дёргал ручки и в базе показывал, как у тебя сохранилась запись. Так что даже вот такое демовает. А вообще, часто бывает так, что демо не олицетворяет текущее состояние системы. Что-то может не работать или работать неправильно. Поэтому ответственный человек за демонстрацию экрана, знающий о всех косяках, их просто не показывает. То есть кликает и делает то, что работает. Ну и надеется на то, что заказчик не попросит сделать что-то ещё.
И последний процесс в стандартном скраме - это ретроспектива. Ещё её называют ретро. Задача ретро - выявить проблемы в текущем спринте и решить их все в следующем. На ретро находится вся команда. Идёт оно часа полтора-два. Оно может проходить в формате открытого диалога, где каждый член команды высказывает своё мнение о текущем спринте. Но лично у меня было иначе. Обычно использовался какой-нибудь сайт типа Миру, где создаются три колонки: что понравилось, что не понравилось и как исправить. В эти колонки есть возможность добавлять стикеры с текстом. Выделяется 10 минут, и вся команда молча в анонимном режиме пишет, что ей понравилось, и клеит стикеры. Далее Тимлит начинает их зачитывать, команда их обсуждает, и он группирует их по темам. Далее, по сгруппированным темам создаются задачи на исправление, либо не создаются задачи, а все остаются на уровне. Ребята, запомнили, да? Вот так делать нельзя. Всё, идём работать. Лично у меня бывало ретро не в конце каждого спринта раз в 3 месяца, потому что не всегда можно выделить какие-то проблемы за 2 недели, особенно если команда не сильно активная.
Ну и помимо Сраramм, вторая по популярности методология разработки - это canбан. В ней нет отдельных этапов рефаймента, планирования, демо, ретро и спринтов, но есть дейлики. Она гораздо проще для понимания. Тебе просто выдаётся задача, ты её выполняешь, как закончишь, выдаётся следующая и так в непрерывном режиме. Что касается оценки задач, то обычно спрашивают просто разраба, за сколько он сделает, и всё. Демо для заказчика не обязательно регулярная. Может быть тогда, когда захотят обе стороны, когда накопится достаточное количество фичей. Сами этапы на доске называются так же. Эта методология гораздо более лайтовая и проще Скрама. В ней отсутствует множество регулярных обязательных мероприятий.
На собеседовании ещё часто спрашивают: "Как происходит ревью кода? Делал ли ты ревью?" Правильный ответ тут сказать: "Да, делал, потому что это плюсик тебе". Рассказывай про то, что в компании было кроossвьew, построенное следующим образом. Обязательно твой merchрек requestст должен опрунуть TeamL плюс один член команды. Только после этого можно вливать код. Ну и ты участвовал в таком ревю. Так же, как и все члены команды. Здесь ещё могут спросить: "А как ты тогда проводил ревью?" Тут можно сказать, что просматривал весь код на соответствие кодстайлу, принятому в команде. Открывал задачу вжи, изучал, что необходимо сделать и соответствует ли решение требованиям. Иногда переключался на эту ветку и запускал в де, но это реже.
Надо понимать, что когда ты рассказываешь про процессы в команде на собеседовании, не надо бояться того, что ты расскажешь что-то отличное от того, что я сказал в видео. Делики у тебя могут быть не каждый день. В канбане может быть рефайнмент, в скраме может вообще не быть дема. Каждая компания имплементирует то, что написано в учебнике так, как она считает нужным. Поэтому не теряйся. Что-то не так ляпнул, стой на своём. Как говорится, ври до конца. Человек на той стороне не знает, как всё работало именно у тебя.
Кстати, любому веб-разработчику необходимо иметь базовые навыки работы с докером, даже фронтендеру. Поэтому я подсуетился и сделал по нему практический гайд без воды, который поможет сделать тебе первые шаги в этой технологии.
А с вами был Андрей Кулагин. Будьте гибкими людьми и ничего не бойтесь. เฮ [музыка]