Новости • События • Публикации

Новости ITSupportMe

post image

О компании

East or West, Home’s Best!

Это лето навсегда войдет в анналы истории. Ни литра моря, ни метра гор — только красоты рукотворных садов да грядок (шах и мат, ненавистники дачи), фотографии локальных жемчужин Гомельщины в сети, а для самых смелых исследователей — бескрайние (в пределах географически установленных границ, естественно) просторы Родины, благо исторических, экологических, культурных и прочих памятников у нас полно. Но все-таки мы не привыкли сидеть взаперти, верим в лучшее и уже вострим лыжи (ну, или складываем купальники в чемодан) в сторону новых приключений. Поговорили с отпетыми путешественниками из ITSupportMe о том, как им живется в сложившейся ситуации, куда они в первую очередь планируют поездку, когда Карфаген будет разрушен, и какое из посещенных ими мест запомнилось больше всего. Ян Жeкалов, BA: для настоящего путешественника преград не существует Я бы не сказал, что прям все границы закрыты, при желании можно много куда улететь, но это будет дорого, так как из Минска. Плюс кое-где придется побыть в изоляции, ну, и инстинкт самосохранения как-то пока не позволяет. К этой ситуации я в целом уже привык, но при первой же возможности возьму отпуск и уеду куда подальше. Как запасной вариант уже запланировал маршрут по РБ, возможно, и покатаюсь по стране. Из более удаленных во времени и пространстве планов — поеду в Англию и соседние британские государства, ведь я должен был поехать туда еще в мае! Сложно сказать, где мне понравилось больше всего: я был во многих интересных местах. Но для меня как для футбольного болельщика незабываемой была поездка на матч любимой команды в Милан. С точки зрения атмосферы очень крутое впечатление оставил Лиссабон и окрестности. А еще всем советую Братиславу, как минимум чтобы сравнить с тем, как ее показали в «Евротуре» и потому что все проезжают мимо (хотя она в часе езды от Вены), а зря. Юлия Кадильникова, команда Charlie: путешествовала по Беларуси до того, как это стало мейнстримом В условиях закрытых границ очень тоскливо — ощущение, что лишилась чего-то очень важного. За прошлый год я успела съездить в путешествия 7 раз и посетить 7 новых стран. Мне так это понравилось! И я думала: наконец-то я путешествую так, как всегда мечтала. И, естественно, надеялась и верила, что 2020 не будет уступать 2019 в количестве новых посещенных мест. Но коронавирус внёс свои коррективы… Поэтому сейчас от тоски спасают короткие поездки по Беларуси. Но так как все самые интересные места (замки, усадьбы, областные центры и нац. парки) моей родины я с друзьями посетила несколько лет назад, то сейчас мы просто ездим по районным центрам. После открытия границ у меня нет особых планов. Вообще в этом году мы с друзьями собирались в Португалию, но поездку придется отложить на следующий год. Ещё рассматривали Монголию, но тоже пока поставили эту идею на паузу. Сейчас есть в мыслях Азербайджан, но куда в итоге поедем — решим, как всегда, в последний момент. Сложно выделить какое-то одно особенно запомнившееся место из мной посещенных. В каждом путешествии есть что-то запоминающееся. Например, Израиль поразил меня тем, как из песка всего за несколько десятков лет выросла такая развитая страна. В Израиле, в Хайфе, находится одно из моих любимых мест — смотровая площадка в Бахайских садах. Оттуда открывается чудеснейший вид на город и на Средиземное море. Индия впечатлила меня своей отличностью от того, к чему мы привыкли. Там шумно, многолюдно, грязно, но в тоже время очень красиво. И там тоже нашлось одно место, куда я с удовольствием попала бы ещё раз: тихий, чистый и пустынный берег реки Ганг у подножия Гималаев в городе Ришикеш. Люксембург — маленькая, сказочная и беззаботная страна. Греция — захватывающие дух пейзажи. Особенно запомнился остров Закинф. Много красивых мест в Украине. Например, руины замка на горе в городе Хуст. Туда очень тяжело и долго подниматься пешком, но какие оттуда виды! Не могу не отметить Мурманск — суровая северная красота. А Териберка и берег Северного Ледовитого океана вообще не поддаются описанию. Нетронутая человеком природа Карелии, потрясающие закаты, тонущие в бесконечной глади озёр. И, конечно, европейские города со своей архитектурой и историей: Амстердам, Брюгге, Рига, Прага, Берлин, Варшава… А вообще путешествие — это не только архитектура и пейзажи, но и компания людей рядом с тобой. И любой город, любое место может навсегда остаться в памяти как что-то потрясающее. Вера Бабич, BA: в поисках драйва Сейчас мне живется с ощущением, что очень хочется на волю. Мне важна смена обстановки, чтобы перезагрузиться и восстановить ресурсы. Но со мной не работают такие способы, как съездить за город на пару дней или попутешествовать по Беларуси. Потому что в этом для меня нет драйва. Драйв есть тогда, когда у тебя третья пересадка до пункта назначения, за плечами две страны и впереди новый город, новый язык, другой менталитет. У меня были планы поехать в Сербию, Норвегию или куда-нибудь пожарче — Тайланд (посмотреть на пляж из одноименного фильма) или Филиппины (поплавать с акулами!). Сложно сказать, какое место было самое крутое. Мне очень нравится центр Вены, приятно гулять там часами. Была проездом через Швейцарию и сильно зацепили Альпы. А еще запомнился колорит Вьетнама. Иван Титуленко, отдел Java разработки: душа просит удаленку из Кипра Ну так наши границы не закрыты же? :) На самом деле мы за 9 лет не сильно напутешествовали: Вильнюс, Милан, Венеция, Цюрих, Люцерн и пару мест на Кипре (ну и понятно, Киев). Пока у нас удаленная работа, душа просит удаленку где-нибудь из Кипра :) Чтобы не на неделю, а на месяц там зависнуть. Сложно выделить что-то конкретное из того, что мы успели посетить. Разные места оставляют разные впечатления, у всех своя атмосфера. Но вот прямо чтобы похвастаться — дом Леонардо Да Винчи. Он был на время экспо открыт, и мы туда умудрились попасть не по билету на 15 минут, а просто ходи гуляй. Кстати, самый шик был в первый отпуск. Когда мы приехали в Милан, спустились в метро и… я не смог найти бумажку с адресом квартиры и номерами телефонов. Интернета нет, приложение данные не сохранило в офлайн, все печально. Это было одно из чудес отпуска — до сих пор я с трудом понимаю, как мы тогда добрались. Юлия Шмыговская, English instructor: воспоминания — это то, что с нами остается навсегда Первое время беспрецедентное положение вещей в голове просто не укладывалось, потому как мы все привыкли к более-менее свободному перемещению. Лично меня успокаивал тот факт, что срок действия Шенгенской визы закончился в начале марта и делать новую я не планировала. Мои намерения на 2020 год были связаны с отдыхом в пределах нашей страны. Отличных мест у нас, на самом деле, очень много. В эти выходные возлагаю большие надежды на поездку в Могилевскую область (Могилев — единственный областной центр, в котором я еще не была). Исследование новых для себя мест, несомненно, мое увлечение. И я готова вкладывать в него время, силы и финансы, потому что воспоминания — это то, что с нами остается навсегда. Любое из мест, где я побывала, интересно по-своему. Однако с приходом глобализации уникальность городов стирается, европейские столицы становятся все больше похожи друг на друга. Поэтому есть смысл посещать природные объекты, деревушки, заведения только для местных, чтобы ощутить весь колорит страны. Если выделять что-то одно, то самым любимым городом для меня пока остается разноплановая Барселона. От нее я не устану никогда, хочу возвращаться туда снова и снова. Кристина Леонова, PM: ещё столько классных мест, где я не была В условиях закрытых границ мне живется плохо :) Из-за пандемии отменилось несколько поездок, из-за чего очень грустно. Один концерт перенесли на год. Сейчас я не путешествую, соблюдаю самоизоляцию. Конечно, уже очень хочется куда-нибудь поехать, потому что мне надо часто менять обстановку, чтобы обнулиться. Куда поеду в первую очередь, когда дальние путешествия будут возможными? Пока сложно сказать. Ещё столько классных мест, где я не была, да и не люблю раскрывать свои планы :) Самые крутые места, которые я посещала — Исландия — там я была дважды, сначала летом, а потом поехала зимой смотреть на северное сияние; Доминикана — потрясающее Карибское море; США — по работе, но удалось немного попутешествовать и там; Китай — он вообще ни на что не похож, другая планета! А как ты сражаешься с закрытыми границами? :)

ITSupportMe

02 июля, 2020

post image

О компании

9 (не)идеальных product owner и как с ними работать. Из нашей практики.

9 (не)идеальных product owner и как с ними работать. Из нашей практики. При виде вас работники разбегаются в рассыпную, усиленно имитируя трудовую активность, недобросовестные подрядчики срывают все сроки и договоренности, кругом одни некомпетентности, и за всем циклом разработки нужен глаз да глаз?.. Да, ситуация не из легких. Хотя не исключено, что второй стороне конфликта также есть что сказать. Без малого 10-летний опыт в области разработки и внедрения IT-решений научил нас, что профессиональные отношения не бывают белыми или черными, к любому клиенту можно и нужно найти подход, а ориентированность на результат есть основа любых проектов. Тем не менее, с некоторыми заказчиками у нас была химия чуть ли не с первого звонка, и как правило, это было началом долгих и плодотворных отношений, породивших не один совместный проект. А с кем-то пришлось пробираться сквозь тернии к звездам, шаг за шагом синхронизируясь и налаживая эффективный диалог. Подводных камней в ходе IT разработки может быть хоть отбавляй. Но в сегодняшней статье мы бы хотели остановится на одном из самых важных участников процесса — владельце продукта. Кто он такой и как может повлиять на эффективность реализации бизнес-плана? Product Owner: введение Стоит открыть любой мануал гибкой разработки — и сразу перед тобой возникает образ его — всадника на белом коне — который есть глаза, уши и глас Заказчика. Он понимает общую идею проекта, отвечает за видение конечного продукта и его ценности для пользователя. Можно долго рассуждать, каким он должен быть, а каким нет, но здесь главное одно — от действий владельца продукта напрямую зависит… всё :) Рассмотрим ситуации, когда product owner так или иначе стопорил разработку и как мы решали те или иные вопросы. Портрет 1 Вот вам задача, действуйте! Он врывается в жизнь разработчиков с классным проектом и шикарным лонгридом, в котором с большего написано, что, как и когда должно функционировать. На первых парах этого вполне достаточно. Но проект набирает обороты, и шестеренки казалось бы отлично откалиброванного механизма начинают натыкаться на обстоятельства. Какие-то моменты требуют уточнения, о чем-то и вовсе забыли сказать (так как предсказать все аспекты разработки способна, пожалуй, только Ванга, но это не точно), где-то наш специалист увидел возможность оптимизировать функционал — да мало ли может быть причин. Выход: Налаженная коммуникация. Идеальный владелец продукта готов к обсуждению текущих вопросов с разработчиками хоть каждый день в особо «жаркие» периоды, а далее, как правило, хватает митингов один-два раза в неделю. Он способен слушать и слышать команду, уточняет, конкретизирует и приоритизирует свои действия, не боится отойти от намеченного плана, руководствуясь принципами эффективности. Повторим — идеальный владелец продукта. Портрет 2 Видите суслика? А он есть Ведь некоторые из нас могут позволить себе заниматься исключительно своей работой и делать это хорошо. А кто-то перегружен и по долгу службы постоянно отвлекается на сторонние вопросы — и с этим ничего не поделать. А делать приходится, ведь проблемы без координации с Заказчиком сами себя не решат.  На одном из наших проектов, например, product owner был настолько загружен, что мог не отвечать на наши мейлы не только днями, но иногда и целую неделю. В результате процесс серьезно тормозился: уже готовые фичи не утверждались, вопросы накапливались как снежный ком, и мы не могли взять новые задачи в разработку, чтобы хоть как-то скрасить мучительный момент ожидания. Нашему проектному менеджеру приходилось постоянно напоминать о себе, о команде, о своих вопросах: еще одним письмом либо прямым обращением в мессенджере, что также мало чем спасало ситуацию. В лучшем случае владелец продукта отвечал: «Да-да, сегодня вы получите свои ответы». Немного драмы добавляла и разница часовых поясов: поскольку команда Заказчика находилась в США, то и «сегодня» автоматически превращалось в «завтра». Конечно, у нас случались совещания, но к тому моменту список вопросов становился таким огромным, что обсудить все было просто невозможно. Выход 1 Рокировка. На самом деле проблема решилась довольно просто. Так как наш владелец продукта был задействован на многих проектах, было принято решение его немного разгрузить и отдать наш проект другому специалисту, у которого было больше возможностей уделять внимание нашей команде. Понятное дело, какое-то время наиболее специфические вопросы все равно решались с предыдущим product owner. Но очевидно одно — сразу после этой вынужденной рокировки проект очень круто пошел. 15 минут ежедневного митинга творят чудеса, что ни говори. Выход 2 Делегирование. Надо сказать, общая загруженность на проекте довольно распространенное явление. И в схожей ситуации другой владелец продукта, с которым мы сотрудничали, принял решение делегировать часть своих обязанностей подчиненному. И это тоже неплохой вариант, кроме одного но — отсутствие у заместителя соответствующих полномочий (а где-то опыта, ведь на то он и зам, чтобы где-то в чем-то учиться у своего руководства) для принятия критически важных решений. Тем не менее, такой ход помог существенно снизить напряжение команды в процессе разработки: большинство вопросов решалось довольно оперативно, фичи кларифайлились, баги фиксились — и караван шел. А что еще нужно для счастья?.. Портрет 3 Хронический опоздун Или вот похожая ситуация. Что если ваш product owner прекрасен спору нет: и общее видение проекта предоставляет, и всегда готов детализировать и приоритизировать задачи, и для диалога открыт, но… Давайте уже просыпаться и думать, что делать, если владелец продукта регулярно опаздывает на совещания, как, например, один из наших партнеров. Причин его бесконечных задержек было предостаточно и, надо признать, большая их часть была объективной. Так, нередкими были форс-мажорные обстоятельства, когда человек банально задерживался на каких-то предыдущих митингах, на которых тоже нужно было срочно дела делать. Что, тем не менее, не скрашивало нам ожидание. Выход: В целом ситуация не была критичной. Всегда можно было сдвинуть что-то в расписании. Ну, и составление программы встречи (meeting agenda) сильно облегчало наше взаимодействие. Плюс какие-то вопросы мы могли обсудить в течение 20 минут ожидания и предоставить уже итоговый вариант. Портрет 4 А вы точно работу работаете? А если проверить? Бывает так, что владельцу продукта сложно преодолеть свою природную недоверчивость, особенно если дело касается аусорсной компании, разработчики которой за тридевять земель неизвестно чем занимаются (а вдруг пасьянс раскладывают, а не трудятся над проектом). В таком случае может помочь только время, которое, как известно, не только лечит, но и дает возможность команде продемонстрировать свою компетенцию. Выход: Чтобы ускорить этот процесс, с одним заказчиком нам пришлось релизиться по чуть-чуть каждую неделю: и ему спокойнее, и нам несложно. В другом случае очень помогла командировка в головной офис клиента. Сперва product owner еще поработал немного в режиме учительницы младших классов: прохаживаясь мимо наших ребят, пытался заглянуть в мониторы и убедиться в том, что они заняты дело. Но пара дней непрерывного общения и совместного хардворка сделали свое дело — и к вопросам доверия мы больше не возвращались. Портрет 5 Я технически подкован и хочу за всем следить лично Ни для кого не секрет, что грамотный владелец продукта должен разбираться в технической составляющей проекта. В идеале даже приветствуется его предыдущий опыт в разработке. Тем не менее основополагающим принципом работы любой команды есть разделение обязанностей. Грубо говоря, кодер кодит, бизнес аналитик анализирует, проектный менеджер управляет, а product owner… владеет :) Вас не должно смущать, что какие-то технические аспекты вам не по зубам, это ведь попросту не ваша часть Марлезонского балета. Эта тема очень близка к предыдущей проблеме недоверия. Так, у одного нашего клиента было предвзятое убеждение, что айтишники, мягко говоря, не самые умные люди. И что в некоторых вопросах лучше всех справится он сам. В таких условиях команде довольно сложно показать свою компетенцию, ведь им по сути не позволяют самостоятельно делать то, в чем они действительно хороши. Владелец продукта постоянно требовал предоставить ему доступ ко всевозможным базам, он намеревался сам писать запросы, так как статистика либо отчеты, предоставляемые ему нашими ребятами, с его точки зрения, были некорректными. Выход: В той ситуации мы, конечно, предоставили владельцу продукта доступ. Но. Вскоре после этого последовала череда вопросов «А это что?», «А это как работает?», «А здесь куда нажимать?», потому что база была довольно сложно устроена, в таблицах было огромное количество значений и, понятное дело, работать с ней было затруднительно без определенного бэкграунда. В глобальном плане важно и делом, и словом донести до клиента, что айтишники — это не только код, но и глубокий анализ бизнес составляющей продукта, разработка стратегии его развития и гарант его успешного функционирования после непосредственного релиза. Ведь начало нового проекта сродни усыновлению — ты уже не можешь относится к идее заказчика как просто к работе. Для нас важно, чтобы она «выстрелила», было конкурентоспособной и максимально эффективной. Чтобы мы могли гордится тем, что сотворили. Портрет 6 А вот мне так нравится Иногда грань между объективными факторами, влияющими на развитие продукта, и субъективными предпочтениями заказчика размывается. Один product owner, с которым мы сотрудничали, был отличным специалистом — и хорошо описывал фичи, и давай четкие и подробные комментарии, и быстро реагировал на наши запросы. Но было одно но, которое серьезно мешало эффективности реализации задуманного плана: постепенно все фичи стали подстраиваться под вкусы и предпочтения конкретного человека, а не с учетом совместно выработанной и утвержденной стратегии реализации проекта. От него все чаще можно было услышать фразы типа «Вот мне здесь что-то неудобно», «А вот тут я бы хотел…», «А вот это мне как-то не нравится…» Выход: Конечно, ваш проект — это ваше дитя и всегда хочется, чтобы он был именно таким, каким вы его представляете. Однако стоит учитывать мнение и других участников «воспитательного процесса». Согласитесь, если вашему ребенку удобнее из пункта А в пункт Б добраться не на самокате, а на велосипеде, при этом шлем у него на голове будет не синего, а красного цвета, а еще, возможно, стоит включить в маршрут пару остановок для повышение его выносливости (а это не учитывая того, что он, возможно, вообще не хочет идти по отцовским следам, а мечтает о балетных подмостках)… В общем, без командной работы здесь никак. В случае с упомянутым выше владельцем продукта — через некоторое время Заказчик был вынужден делегировать эти полномочия более объективному кандидату. Портрет 7 Поди туда — не знаю куда, принеси то — не знаю что Бывает такая ситуация, что заказчик сам не может четко представить, как будет функционировать его система. В таких случаях на команду разработки возлагаются дополнительные чаяния — сформулировать четкую концепцию и стратегию ее реализации. Что совсем неплохо для компетентных специалистов. Но только в том случае, если клиент готов принять чужое видение проблемы. В нашей же практике бывали случаи, когда владелец продукта был целиком и полностью за стратегию развития, разделял наше стремление пилить классные фичи и создавать максимально востребованную платформу, но не всегда это желание сопровождалось предоставлением информации, как именно это будет происходить. Нам могли дать небольшой набросок: «чего бы я хотел». Но когда мы приходили за подробностями, ответом порой было «Я сам не знаю, что именно я хочу, но подумайте, придумайте». С этим не всегда было легко работать. Выход: В той конкретной ситуации нам очень повезло: наш техлид был довольно сильно погружен в бизнес-домен, что облегчало нашу задачу артикулировать и выполнять то, что хотел от нас product owner. Но и это не оградило нас от спорных моментов во время приемки того или иного этапа разработки. Ведь когда даже сам клиент не может четко объяснить, как и что он ждет в итоге, то сюрпризов не миновать. Как избежать такой ситуации? Предоставив четкие требования. Ну, и конечно, посредством регулярных митингов, обсуждая, объясняя, отвечая на вопросы. Портрет 8 Моя твоя не понимать Любая компания, работающая на аутсорс, рано или поздно нет-нет да и наступит на грабли культурных различий. И дело даже не в каких-то диаметрально противоположных менталитетах — подводные камни нередко скрываются за гладью казалось бы общего мировоззренческого бэкграунда. Например, извечный контраст: приветливый стиль американского дружелюбия и сдержанная славянская экспрессия — чем вам не повод для недопонимания. Так, ответив своему западному партнеру лаконичным (и таким профессионально нейтральным у нас) «Got it», минуя все small talks, знаки внимания и этикетные формулы, мы можем не только не подчеркнуть свою готовность к работе, но и даже обидеть собеседника. Выход: с клиентом всегда нужно разговаривать на его языке. Это касается не только слов, но и манеры общения. В этом есть огромное количество позитивных моментов, ведь близкое знакомство с другими культурами только обогащает нас духовно и делает открытыми миру. Портрет 9 Задира Этот случай, наверное, самый сложный. Ведь любая ситуация может быть благоприятно разрешена, когда обе стороны готовы вести диалог и идти на компромиссы во имя общего блага. Но что делать, когда проекту достался немного… конфликтный кормчий? Однажды нам довелось сотрудничать с весьма непростым product owner. Можно долго говорить о его плюсах и минусах как человека и специалиста, но главная отличительная особенность, которая существенно влияла на процесс разработки, — это его вспыльчивый характер и бескомпромиссность. Особенно его тяга к конфликтам усиливалась во время митингов в разговорах, как ни странно, с другими представителями Заказчика из-за чего рабочие конференции нередко превращались в целые холивары, где нам оставалось только доставать попкорн и запасаться терпением. Выход: конфликт то утихал, то разгорался с новой силой несколько месяцев, но затем наш «проблемный» владелец продукта продемонстрировал себя как настоящий профессионал. Он пошел на перемирие со своими коллегами, и они согласованно «выпилились» из наших митингов, назначив другого, более нейтрального product owner. После такого мудрого решения атмосфера в команде стала в целом намного спокойнее.   На этом наш сказ о непростом клиенте подходит к концу. Наверняка, у вас есть свои истории о том, как вы сталкивались с препятствиями и преодолевали их на пути к успешной командной работе. В чем мораль сей басни? Нет неразрешимых ситуаций. Мы сработаемся с вами даже там, где другие подают на развод, ссылаясь на «unmendable differences».

ITSupportMe

15 июня, 2020

post image

Разработка

Из варяг в греки, или зачем нам Котлин

Дисклеймер Данный материал ни в коем случае не претендует на серьезное исследование, а является коротким видением того, почему мы выбираем (или нет) Kotlin для своих проектов. Выводы представлены на основе двухлетнего опыта работы команды ITSupportMe с этим языком программирования. Из варяг в греки, или зачем нам Котлин Немного истории В 2011 году в океане информационных технологий стало на один остров больше. Российская компания JetBrains представила свою новую разработку – язык программирования Kotlin, по аналогии с Java названный в честь участка суши, на этот раз Финского залива. Через каких-то шесть лет этот довольно смелый и амбициозный проект достиг поразительных результатов. Так, на конференции Google I/O 2017 Kotlin стал одним из трех языков, по стандарту включенных в Android Studio 3.0 (первые два — Java и C++). Whyyyyyyyyyy? (что в переводе с английского означает «немного оптимистичной теории») В чем же секрет популярности детища JetBrains, и почему многие программисты обращаются именно к его инструментарию при решении тех или иных IT-задач. Причина номер раз: Java уже не та? Kotlin был придуман командой, которая создала большое количество продуктов на Java и хорошо ориентируется в новейших технологиях разработки. Для них, как и для многих других специалистов, не секрет, что сегодня Java развивается очень медленно. Новый функционал добавляется в нее с большим скрипом. В некотором роде это связано с тем, что «большая» Java, также известная как Java EE, накапливает колоссальный объем проектов, и их важно сохранить при обновлении системы. Такая ситуация, а также ряд других причин, породила потребность в новом, JVM-адаптированном языке программирования, с одной стороны, не нуждающемся в обратной совместимости, а с другой – свободно взаимодействующем с обширным диапазоном инструментов, плагинов и библиотек Java. Таким языком программирования и стал Kotlin. Причина номер два: это просто? Два главных достоинства Kotlin, с точки зрения многих его сторонников, это простота работы поверх JVM. JetBrains задумали свое детище как статический типизированный объектно-ориентированный язык индустриального уровня, который лаконичнее и типобезопаснее, чем Java, проще чем Scala, и при этом свободно компилируется для Java и JavaScript, что позволяет постепенно перейти со старой платформы на новую. Одним из примеров простоты и гибкости Kotlin является специфика его интеграции с системой Android, куда он встраивается посредством Gradle. В дальнейшем это позволяет внедрять новый функционал для Kotlin без переписывания Android-приложения целиком. Причина номер три: оно тебе надо? Kotlin представляет большой интерес для всех разработчиков, имеющим дело с Java-машиной или любыми языками со сборщиком мусора в целом. Упомянутая выше простота и адаптивность эксплуатации дает возможность почти любому Java-специалисту, готовому посвятить полчаса своего времени изучению туториала и спецификации языка, начать применять его в своей практике, а обратная совместимость решает проблему использования  Kotlin в уже действующем проекте. И еще N-цать технических причин Null-безопасность Система типов в Kotlin направлена на искоренение проблемы, в Java известной как NullPointerException (NPE). Она возникает при попытке отсылки к null значению. Kotlin избегает такой ситуации, выдавая ошибку компиляции. Конечно, это не идеальное решение (а какие идеальные?), и все равно остаются лазейки для «ошибки на миллион»: этому могут способствовать как внутренние (прямое указание throw NullPointerException() или использование оператора !!), так и внешние (например, ошибки самого Java-кода) причины. Гибкость и простота синтаксиса В Kotlin код выглядит менее громоздким и намного более читабельным, так как в нем простые подпрограммы, функции и структуры можно объявить одной строкой. При этом геттеры и сеттеры задаются за кулисами для полного взаимодействия с Java. Добавление же аннотации базы данных к классу позволяет генерировать различные шаблоны автоматически. Классы данных Разработчики Kotlin добавили специальные классы для хранения данных и генерирования различных шаблонов: equals(), hashCode(), toString(), геттеров и сеттеров и др. Функции-расширения Kotlin обеспечивает расширение функционального диапазона имеющихся классов без наследования, что достигается посредством функций-расширений. Чтобы объявить такую функцию, к ее имени нужно добавить префикс в виде расширяемого типа. Умные преобразования типов Компилятор Kotlin весьма удобен для приведения типов. Во многих случаях вам не нужно будет явно указывать операторы преобразования, так как эту работу за вас выполнит оператор is. Функциональное программирование Важно отметить, что Kotlin – это действенный инструмент функционального программирования, в вооружении которого широкий спектр полезных возможностей: функции высшего порядка, перегрузка операторов, лямбда-выражения и многое другое. Сравнение скорости Java и Kotlin При чистой сборке Java превосходит Kotlin на 15–20%. Однако чаще разработчики прибегают к частичной сборке, где благодаря активному демону Gradle и включенной инкрементальной компиляции Kotlin даже немного быстрее Java. Таким образом, языки приблизительно равны по скорости компиляции. А мы что? Как вспоминает наш специалист Иван Брель, опыт работы ITSupportMe с Kotlin начался с любопытства. Затем ребята убедились, что это работает — и понеслось. На самом деле в компании не так много проектов, написанных на этом языке, во многом из-за бытующего в среде разработчиков скептицизма по поводу всего нового. — Если стартует новый проект, то, мол, нужно использовать проверенные вещи, куда там Kotlin! Но как показывает время, в освоении он очень легок, а профитов больше, — замечает Иван. Наш собеседник подчеркивает, что зачастую ошибки в использовании Kotlin связаны с тем, что разработчики пишут на нем как будто это Java, только кода меньше. Однако постепенно приходит понимание общей концепции — и тогда становится ясно, что это совсем другое. Хорошая иллюстрация такой эволюции — внутренний проект компании ITSM Portal, где при детальном осмотре можно найти и «первый блин комом», и примеры хорошего кода: «на этом проекте мы попробовали все», — поясняет Иван. Разработчик добавляет, что его команда в своей работе использует как новые фичи и фреймворки, так и нативные вещи типа сертификатов от Sun — и ни с чем не было проблем: В целом Kotlin сильно облегчает жизнь: код краток, конструкции понятнее, многие вещи уже сделаны — и можно просто их использовать, плюс полная совместимость с Java. То есть все написанное ранее также будет работать, как и сторонний код на Java. Для Василия Писпанена текущий проект компании — первый опыт использования Kotlin с нуля с целью создания крупномасштабной и сложноархитектурной системы. — Проект — сущий ад с точки зрения архитектуры: больше десятка амазоновских сервисов, блокчейн, лицензирование кода, приличная нагрузка и отсутствие права на ошибку, так как через платформу будут гонять большие деньги, — то ли сетует, то ли восхищается наш собеседник. — Чтобы комфортно девелопить конкретно этот проект 16 гигов оперативки уже маловато. Интеграционные тесты поднимают два десятка докер-контейнеров — в такой момент уже мало что можно делать за компом. В таких условиях Kotlin видится нашему специалисту отличным решением: «в целом более функциональный стиль, крутые лямбды, компактный код и много мелких плюшек из коробки вроде extension functions или интерполяции строк». Есть и неудобные для разработчика моменты. Например, не поддерживаются repeatable annotations из Java. Многие стандартные для Java вещи задуманы как самостоятельные библиотеки (serialization, coroutines), и не всегда можно безболезненно обновить их вслед за версией самого языка. Конечно, можно использовать котлинские библиотеки из Java, но декомпилированный Kotlin класс выглядит не лучше обфусцированного кода. Некоторые синтаксические конструкции, вроде разных видов конструкторов, выглядят для Василия очень странно. — А ещё idea часто нещадно тупит в плане анализа кода и подсветки синтаксиса (JetBrains, алло, ну как так!), — эмоционально добавляет он. Имеет свое веское мнение о Kotlin и Алексей Метлицкий. Еще со времен тренингов в ITSupportMe, которые посещал молодой специалист, прежде чем прочно обосноваться в штате компании, стало ясно, что Kotlin очень приятный в использовании язык, и при старте новых проектов, если заказчик не настаивает на Java, есть смысл отдать предпочтение именно ему. На данный момент в эффективности детища Jetbrains Алексей убедился в рамках как минимум трех проектов. Как оказалось, на этом языке ему как программисту проще и комфортнее выражать свои намерения: — Создатели позаботились о том, чтобы максимально сократить количество букв в выражениях, которыми пользуются программисты, и добавили много «плюшек», позволяющих быстрее и читать, и писать код. Главным плюсом Kotlin для нашего собеседника является его полная совместимость с библиотеками Java. — А еще то, как язык работает «под капотом», мало чем отличается от Java. Это позволяет Java-разработчикам в очень краткие сроки добавить Kotlin в своё портфолио, — добавляет Алексей. — А тот факт, что язык гораздо моложе своего предшественника, означает, что можно начать его создание практически с чистого листа, не цепляясь за неудачные решения и ошибки, которые накопились в Java за  годы её существования. Кроме того, в JetBrains поработали над вопросами безопасности кода в плане его защищенности от ошибок. Еще одно очевидное достоинство Kotlin — это более простой в чтении и написании, современный, продвинутый, развивающийся (а значит и перспективный), свободный от проприетарных лицензий язык программирования. — Я считаю, что он мог бы стать нашим основным инструментом разработки, вот так, — уверенно подытоживает Алексей. Перечисление достоинств Kotlin можно продолжать еще долго. Равно как бесконечно обсуждать плюсы и минусы (конечно же, фундаментальные :)) использования этого языка при разработке. Однако на сегодняшний день команде ITSupportMe ясно одно: пора бы уже перестать скептически относиться к любому новому продукту. Ведь главное в разработке не то, на каком языке вы пишете. Гораздо важнее ваши трудозатраты на решение той или иной задачи. Программисты пишут код. И если на этом этапе удастся сэкономить время, то быстрее пройдет стадия тестирования и больше останется для разработки бизнес логики продукта. Как достичь такой цели — решать вам.

ITSupportMe

29 мая, 2020

post image

О компании

Come back to where you once belonged

Мы живем в удивительное время. Когда работать из дома — отличное решение, не здороваться за руку — признак хорошего тона, а обсуждение семейного рецепта антисептика — новый тренд кулинарного шоу. На этой тревожной волне особенно важно сохранять позитивный настрой и не терять свою связь с другими. А поэтому почему бы не поучаствовать в каком-то ностальгическом комьюнити флэш-мобе — подумали мы. И участвовали :) Итак… Спааать. Тебе хочется спааать…Твои глаза закрываются…Твои веки тяжелеют… Ты в далеком 2012 году. В нашем первом офисе. Наливаешь первый стакан офисной бутилированной воды. Сидишь за нашим первым столом. Наслаждаешься первым офисным видом из окна… О, а еще улыбаешься молодому и зеленому Евгению Шмыговскому, который воочию наблюдал (собственноручно сотворял) те времена. Буквально за год-два наши планы и достижения увели нас далеко от того места. Новые люди, новые проекты, 5000 commit — все это привело нас к новому home, sweet home, который расположился аж на трех этажах гомельского технопарка. К чему мы это все? А помнишь свой первый год в ITSupportMe? Вот эти ребята точно помнят. 2017 г. Первый год в ITSM для Ивана Николайцева (слева) и очередной для Виктора Штанзе. Молодой Олег Супер Курницов? 2016, 2017 гг.  Кажется, у нас завелся офисный Бенджамин Баттон. Анастасия Сурта. А она у нас вампир, потому что ей что 2016, что 2020 — все нипочем) Праздники, корпоративы вместе с Юлией Кадильниковой, 2017. Вечный подросток Денис Кораблев Шаповалов, 2016. Дважды счастливый человек Сабина Животок, лето 2017.  Анна Мушкетова в октябре 2018. Видимо, титул «Горячая штучка» дается раз и навсегда :) Просто веселые Егор Титуленко и Юлия Шмыговская, 2016. Ладно, признаемся, это не первый их год. Юля с нами аж с 2014. Безграничные же таланты Егора поступили в распоряжении ITSupportMe в марте 2015. Такие дела. Это был #itsm_begins …на счет три ты проснёшься и начнёшь репостить и лайкать. Три :) Хороших выходных всем!

ITSupportMe

08 мая, 2020

post image

О компании

Музыка нас связала…

Мы давно знаем, что не IT единым живет наш большой и дружный коллектив. Спорт, игры — настольные и компьютерные — книжный клуб, вязание и макраме — да мало ли интересов было, есть и будет! И сегодня мы поговорим о прекрасном — о том, как сотрудники ITSupportMe прекрасно управляются с музыкальными инструментами. И хоть половина из наших сегодняшних героев скромно отмахивается, мол, давно не играли, забыли совсем, в далеком детстве оставили свои увлечения, но все-таки из песни слов не выкинуть. Как и не выкинуть +100500 часов, усилий, нервов и нечеловеческого упорства, положенных на алтарь достижения своей цели. Ведь без этого вот всего не было и нас самих. В общем, читаем, умиляемся, удивляемся, а заодно пытаемся разгадать наш любимый ребус — «Угадай коллегу». 1 Научился играть на пианино… сам Кажется, этот парень знает все о саморазвитии. Ведь консерваторий (впрочем как и музыкальных школ) он не заканчивал, а играть на паре инструментов все-таки умеет! Первый раз наш коллега заинтересовался музыкой в 9 классе. Тогда ему нравилась одна девушка, которая как-то взяла да и сыграла для всех на пианино. «Вот бы тоже научиться играть, тогда-то она точно не устоит!» — от этой мысли сердце у юноши застучало быстрей. Как ни странно, банальными мечтаниями история не закончилась, и уже через несколько месяцев силовых тренировок орудие дев нежнейших и возвышенных мужей сдалось под напором чрезвычайно мотивированного влюбленного. Пик активности музыканта-самоучки пришелся на старшие классы (даже на выпускном выступил). И хоть сердце красавицы оказалось тем еще крепким орешком, те времена наш коллега вспоминает с неподдельной теплотой, периодически смахивая пыль с домашнего синтезатора. А еще в его жизни нашлось место гитаре. После 11 класса он просто взял этот инструмент у друга — так и учится до сих пор (свою гитару, правда, уже успел приобрести) :) 2 Сквозь тернии к звездам Семь лет она занималась в музыкальной школе (класс фортепиано), а потом еще 2 года — в Доме детского творчества (класс эстрадного пения). Кажется, секрет музыкального открытия ITSM_Summer_Party’2019 успешно раскрыт! Чем нашей коллеге запомнился путь к музыкальному совершенству? В первую очередь, своей тернистостью: «Я страдала, потому что учитель меня постоянно била по рукам и говорила, что я бездарность)) Помню бесконечные скучные арии, которые мы слушали, я старалась их понять, но у меня это плохо получалось, я зевала и смотрела в окно». Но в последний год забрезжил лучик надежды: «…учитель сменился, и вдруг мне открылась вся музыкальная грамота, все предыдущие 6 лет вдруг стали понятны — и мне все стало нравиться)». С тех пор прошло немало времени, и к музыкальным практикам наша коллега возвращается только в компании очень близких людей, которым доверяет и перед которыми готова раскрыться: «видимо, остались старые рефлексы, что если что, то опять можно получить по рукам или спине))))))» А еще не за горами коварнейший план по захвату музыкальным бэндом ITSM целого мира. Но об этом вы наверняка еще услышите. Пока скажем одно — без следующего героя эта история явно не обойдется. 3 «Широко известный в узких кругах» Собрал группу еще в школе, потому что нужно было срочно выступить на выпускном. Выступили, понравилось, решили продолжить, достигли статуса своеобразного local band, «широко известного в узких кругах». Выступали на одной сцене с Rasta, Gods Tower, Dragonflame и другими белорусскими коллективами. В последнее время, правда, все как-то подзатихло, но репетиций наш герой не бросает и даже записал недавно альбом для сайд-проекта. Начинающим же или мечтающим начать заниматься музыкой, настоятельно рекомендует: «бросайте это дело и учите джаваскрипт лучше». Видимо, уже на старте устраняет конкурентов :) 4 И жнец, и жрец, и на гитаре игрец На самом деле все началось с классического образования — окончив музыкальную школу по классу фортепиано, наш коллега с головой ушел в гитарный джаз. Выступал с одними из лучших музыкантов города, создал группу Non Grata в мединституте (а вы думали, почему жрец?)), по вечерам после учебы  играл в «Пятом колесе» (было такое атмосферное место), вел гитарный кружок в 24 школе, пел с гомельским эстрадным оркестром Василевского… И тут мы вынуждены остановиться, потому что получится настоящий эпический лонгрид :) 5 Каждая девочка мечтает играть на фортепиано… и ударных Эта гремучая инструментальная смесь научила ее, с одной стороны, доводить любое, даже самое раздражающее дело, до логического завершения, а с другой — концентрации и умению делать «разные вещи двумя руками и двумя ногами))))))». А еще она обзавелась кучей интересных знакомств и запоминающихся историй, так что нашей коллеге явно будет что рассказать своим (и даже нашим) внукам. Одно выступление в закрытом байкерском клубе чего стоит! 6 Музыка открыла ей мир «В 17 лет я окончила музыкальную школу по классу фортепьяно. Большинство родителей отправляют детей в музыкалку в более раннем возрасте, в моем же случае это было только мое решение, и все окружающие меня активно отговаривали от 7 лет обучения, но я уверила всех, что не отступлюсь и не брошу занятия, как мои сестры спустя несколько лет. Сейчас я ни капли не жалею. Было сложно, как и у многих, были кризисы в обучении: 3 года и 5 лет, но каждый раз я вспоминала момент, когда пообещала себе не сдаваться. Благодаря своим занятиям я познакомилась с замечательными людьми, которые хотели, чтобы «ребенок, который умеет играть на пианино» посещал их каждое лето в Германии. Как оказалось, глава семьи — композитор из Америки, который, помимо музыки, преподавал английский язык и вел радиопередачи. Такое общение, определенно, послужило сильнейшим толчком в моем развитии и становлении. Когда меня спрашивают, есть ли смысл заниматься музыкой, то я категорична в своем ответе. Безусловно. Я никогда не была талантливым музыкантом, и давалось мне все только усердным трудом, однако, я чувствовала, что мой кругозор был шире, общее развитие и отношение к прекрасному отличалось от такового со стороны моих сверстников. Сейчас игра помогает мне, главным образом, поднять настроение, переключиться от дел насущных, разрядиться».   Кажется, ITSupportMe давно пора организовать фестивальчик на досуге — так много талантливых и мегаинтересных музыкантов трудится в стенах нашей компании! А сколько поскромничало и пожелало остаться неназванными! Пожалуй, добавим эту идею в копилку нашей будущей реалки, которая, мы верим, не за горами! А завершит наш музыкальный этюд еще одна фотография давно минувших дней — 15 мая, 2017 г., Минута музыки и вдохновения. ITSupportMe, Гомельский технопарк. (1 — Антон Дрик, 2 — Алеся Смирнова, 3 — Анатолий Акуленко, 4 — Юрий Ермаков, 5 — Вера Бабич, 6 — Юлия Шмыговская)

ITSupportMe

24 апреля, 2020

post image

Системное администрирование

10 мифов и легенд о DevOps

Зародившись в относительно недалеком 2009-м, движение DevOps сегодня творит небывалые вещи. Пока любой мало-мальски серьезный проект жаждет себе в штат такого специалиста, далеко не каждый вовлеченный в разработку специалист полностью осознает, что на самом деле скрывается за столь звучной формулировкой. Мы собрали топ-10 самых распространенных утверждений / заблуждений о DevOps и попытались разобраться, что из них ложь, а что намек-добрым-молодцам-урок). Правда, у нас бы ничего не получилось без наших IT-mythbusters — Сергея Пономаренко (тимлид IT-отдела), Николая Трофимовича, Станислава Соломенина и Олега Курницова. DevOps — не профессия, а, в первую очередь, культура создания продукта — YEP Зачастую в объявлении о поиске нового специалиста скупо указывается «нужен DevOps», что нередко вгоняет этого самого специалиста в когнитивный ступор: так чего же или кого же все-таки не хватает работодателю? Действительно, кто-то считает DevOps методологией для автоматизации и увеличения числа релизов, кто-то — для уменьшения ошибок, а кто-то, авторитетно подняв палец вверх, скажет, что DevOps — это, прежде всего, человек, и без него жизнь у программеров, сисадминов и QA-шников не та. Здесь наши консультанты единодушны: DevOps-инженер один в поле не воин, и просто включив Бэт-сигнал на крыше Готэма, проблем не разгрести. Например, мнение Сергея Пономаренко таково: «Я согласен с основным высказыванием, DevOps — это, прежде всего, культура. Культура взаимоотношений между частями одной команды, разными командами и целыми компаниями. Основная ее идея — это общение, тесное сотрудничество людей, выполняющих разные роли, и за счет этого упрощение, ускорение разработки и доставки более качественного и своевременного продукта клиенту. Сейчас многие компании, менеджеры думают: «Вот наймем девопса, он нам все автоматизирует — и будет всем счастье». Да, DevOps-инженер может упростить и улучшить какие-то процессы, но без внедрения DevOps-процессов на всех стадиях работы над проектом какого-то грандиозного эффекта это не даст». Олег Курницов добавляет: «Да, DevOps — это не человек однозначно. DevOps — это набор практик, которые позволяют разрушить границы между Ops и Dev. DevOps — это про совместную работу на общее благо». В реальной жизни человек-DevOps — это чаще всего такой продвинутый админ — 50/50 Кто на самом деле может стать DevOps-инженером? Могут ли в эту сферу перейти, скажем, разработчики? В целом Олег Курницов согласен с утверждением, что DevOps — это такой эволюционировавший админ, который стал вникать в процессы разработки. Про переметнувшихся разрабов он также слышал, но лично не встречал. Сергей Пономаренко же старается быть более либеральным, давая надежду даже нетехнарям: «Я думаю, практически любой может стать DevOps-инженером. Да, я встречал бывших программистов, тестировщиков, ставших DevOps. Я думаю, только людям с гуманитарным образованием и соответствующей профессией будет тяжелее перейти в инженеры, но это тоже реально». Решил поддержать всех мечтающих о DevOps-стезе, но «идеологически» далеких от этого направления, и Николай Трофимович, замечая, что на его памяти «в DevOps приходят из любой сферы: админ, разработчик, тестировщик, таксист, доктор, продавец, филолог и т.д.» DevOps-инженер — это больше про опыт, нежели про знание конкретного софта — 50/50 Можно ли вообще стать DevOps инженером с нуля? А есть ли шанс остановиться на определенном этапе и сказать: теперь я достиг потолка? Тут мнения наших экспертов разошлись. Сергей Пономаренко, например, уверен, что все возможно: «…долго и упорно обучаясь, можно стать кем угодно с нуля, если нравится выбранный путь». Станислав Соломенин, наоборот, настроен скептически: «…нет, практически невозможно, без бэкграунда системного администратора или программиста. С учетом специфики профессии, придется по ходу дела усваивать знания из каждой области, так или иначе связанной с разработкой». В общем, думайте сами, решайте сами, а пока вот вам приятный бонус — совет для начинающих — от Николая Трофимовича, как все-таки стартануть в данном направлении: «прочитать кучу непонятных поначалу и по большей части ненужных потом, статей на форумах; затем можно поискать свое место в команде — вроде как и инфраструктуру не админишь, но и код писать разработчики не подпускают (правда, не очень то и хотелось…). Желательно иметь тот багаж знаний, который нужен на текущем проекте: будет фигово, если админил одноранговую сетку на Windows XP, и вдруг приходится прикручивать сбор логов из Java-приложения в ELK-кластер, развернутый на Linux… в облаке… с iptables на борту…» …Воодушевляет? Тогда добавим сверху единогласное мнение наших специалистов, что покой девопсу только снится, как, впрочем, и всей IT сфере. Сергей Пономаренко: «Нет, потолка просто нет, в современном мире просто невозможно угнаться за новыми технологиями, облаками и изменениями в них. Постоянное обучение становится основной составляющей не важно какой профессии: программиста, тестировщика или DevOps-инженера. Это как гонка, только стоит остановиться на минуту, день — и все, тебя обогнали более молодые и гибкие, и ты уже плетешься в хвосте, пытаясь впитать тонны новой информации». DevOps — это своего рода полевые архитекторы — NOPE Многим ребятам вообще не понравилось это сравнение. Кто-то посчитал его некорректным. Олег Курницов поясняет: «Я не согласен. Скорее это человек, который расскажет разработчикам, как будет себя вести то или иное окружение в работе и откроет глаза на не всегда очевидные для них вещи». DevOps — это заговор сисадминов, чтобы заставить разработчиков делать чужую работу — NOPE Первое правило бойцовского клуба — никогда не говорить о бойцовском клубе. То есть наши заговорщики собеседники не видят ничего крамольного в действиях DevOps относительно других участников проекта. Наоборот, участие девопса приветствуется на любом уровне менеджмента проекта — утверждают они. Олег Курницов: «Это холивар :) Но нет, в некоторых компаниях на стартах проекта нет выделенного человека, который будет отвечать за инфраструктуру, и поэтому разработчикам приходится вникать во все тонкости, и для них «манна небесная», когда DevOps заходит на проект :)» Сергей Пономаренко сам факт заговора не отрицает, но при этом с улыбкой добавляет: «Ну нет, я бы сказал, что это заговор сисадминов, чтоб заставить делать свою работу и не перекладывать какие-то косяки на другие отделы, а работать сообща над их решением =)» То, о чем в приличном обществе нельзя говорить, но так хочется знать — зарплата. Зарплата, поговаривают, огромная — 50/50 Согласно Stack Overflow, самые высокие зарплаты среди ИТ-специалистов США приходятся именно на DevOps-разработчиков. Они же лидируют по уровню дохода в Индии, Германии и Великобритании. А как же у нас (стране, регионе)? Сергей Пономаренко: «Да, ситуация с зарплатами в DevOps-среде «интересная», уже даже мемы и комиксы появляются на эту тему. Сисадмин, просто написав «DevOps» у себя в резюме, моментально привлекает внимание рекрутеров и просит на 50–100% больше =). В нашей стране DevOps (к сожалению, хехе) еще не догнали программистов (или, как сейчас модно говорить, Software Engineer) по зарплатам, но стремительно приближаются к этому. С одной стороны, это обусловлено тем, что от инженера требуется очень много учиться и буквально поглощать знания, с другой стороны — хайповостью и модой на данную профессию». Олег Курницов: «Если ты заходишь с нуля, без опыта работы на проектах, то можно просить среднюю по стране. В Беларуси с этим в целом хорошо, но вилка довольно широкая. Про регион сложно судить, но я думаю, объективно меньше Минска в два раза». Устоявшегося перечня требований к DevOps-инженерам нет, а значит, они должны знать все — NOPE Выдыхаем, все не так страшно. Хоть Сергей Пономаренко и кивает головом, мол, «True-true», Олег Курницов категорически отметает такой абсолютистский подход: «Не знаю ни одного человека, который будет знать все. Да и нереально это. Как правило, специалист знает одно или два облака, систему оркестрации, систему менеджмента, какой-то язык для скриптов и пару всяких штук в обвесе. Реально очень много всяких инструментов есть и вариантов их комбинации». У DevOps-инженера свой неповторимый набор софт скиллз — 50/50 Про стрессоустойчивость говорить не будем, это и так понятно, но чем еще должен обладать успешный специалист в этой отрасти?  И опять единства нет в наших рядах. Николай Трофимович, например, считает, что этот момент функционально не так уж и важен, мол, никому нет дела до личностных качеств, когда по большей части «нужна обезьянка контейнеры двигать либо умные штуки в облаке прикручивать. Как и везде (не привязываясь к делению на Dev или Ops) — надо будет че-то почитать, потом че-то написать». Коллеги Николая, немного подумав, все-таки выводят формулу идеального DevOps-инженера, подчеркивая, что ничего необычного в этом наборе нет. Для Сергея Пономаренко он должен быть коммуникабельным — «в этой сфере и интроверт разговорчивым станет», уметь работать в многозадачном режиме — «вот у нас у некоторых ребят уже по 4 монитора, все задачи не влазят на два. А мы все ищем, где же у них еще два глаза спрятаны =)». Станислав Соломенин убежден, что «самое главное качество в профессии — быть командным игроком. Так же важно не забывать, что DevOps — это не должность или человек. Это набор практик которых придерживается вся команда (а лучше вся компания). Надо уметь слушать и договариваться». Подводит итог вышесказанному Олег Курницов: «Вообще весь процесс Agile и DevOps как его части — это про софт скиллз. Ибо главное — это слушать, слышать и говорить :)». Таких не берут в стартапы — NOPE Мол, задача стартапа — выпустить максимально быстро минимально жизнеспособный продукт, чтобы проверить новую идею. То есть в большинстве случаев стартапы могут обойтись без DevOps. Ребята с такой расстановкой приоритетов категорически не согласны. Так, например, Сергей Пономаренко отмечает: «Ну, стартапы — это отдельная большая тема, они все очень разные, на то они и стартапы. В каких-то стартапах могут быть большие полноценные команды со строгими процессами и распределенными ролями. В других — два программиста и дизайнер, где каждый и швец, и жнец, и девопс, и тестировщик. Кроме того, многое зависит от зрелости стартапа: на старте они могут работать маленькой командой, а после, получив понимание востребованности продукта, набрать большую команду». Олег Курницов также обращает внимание, что немаловажную роль в этом вопросе играет финансовый аспект: «Стартап умеет считать деньги. И если нет человека, который продумывает архитектуру среды, чтобы она масштабировалась, была отказоустойчивой и вообще легко адаптировалась, то  рано или поздно придет «Технический долг» и заставит переделывать всё с нуля». Программер переиграет девопса в программировании, сисадмин — в администрировании, а тестировщик — на своем тестировочном поле (но это не точно) — 50/50 …Ценность же DevOps-man-a в другом… В чем? С этим утверждением собеседники согласны отчасти. Сергей Пономаренко замечает, что «DevOps — это связующее звено между программистами и тестировщиками, часто между разными командами и иногда даже между конечными пользователями и разработчиками». Олег Курницов приводит в пример собственный опыт: «Ну, тест планы и тест кейсы я точно писать не буду. А вот интеграционное/нагрузочное тестирование точно за нами». Ценность же DevOps-а ему видится в его умении поговорить, прийти ко всем заинтересованным сторонам и согласовать правила игры. Помочь с решением проблем и сделать их жизнь легче/лучше».

ITSupportMe

03 апреля, 2020

Начните жить жизнью ITSupportMe

Подпишитесь на нашу E-mail-рассылку, чтобы быть в курсе всех интересных событий и новостей нашей компании!