Открой новые возможности с компанией ITSupportMe

Присоединяйтесь к нам:

О нас

Компания ITSupportMe — это сплоченная, креативная команда специалистов в сфере разработки, тестирования и поддержки программного обеспечения, а также анализа, модернизации и интеграции бизнес-решений.

Благодаря высокому профессионализму и целеустремленности команды, компания быстро развивается, расширяя штат сотрудников, клиентскую и партнерскую базы.

Более 2 800 000 пациентов обслуживаются при помощи нашего программного обеспечения. Накопленные знания и опыт позволяют ITSupportMe создавать технологии, которые повышают качество медицинского обслуживания и улучшают жизнь пациентов. Наша особая гордость — это инновационный портативный глюкометр, который был разработан в нашей исследовательской лаборатории.

8

лет успешных
проектов

100+

штат
сотрудников

8

количество
отделов

29

средний возраст
сотрудников

64%

сотрудников ежегодно проходят
различные тренинги и курсы

167

компаний по всему миру
используют наше ПО

Основные направления деятельности нашей компании:

Разработка и поддержка CRM системы для страховых компаний и автоматизации продаж медицинских препаратов.

Разработка и поддержка систем, предназначенных для автоматизации работы call-центров, обслуживания пациентов, почтовых сервисов, оптовых продаж, складского хозяйства, учета рабочего времени.

Веб-дизайн, проектирование интерфейсов, UX-аналитика, дизайн мобильных приложений, графический дизайн, моушн-дизайн, брендинг, инфографика.

Мы работаем со следующими технологиями:

PHP
Java
MySQL
Symfony
JavaScript
jQuery
ReactJS
Angular
AJAX
HTML5
CSS3
LESS
SASS
Twig
Bootstrap
Hibernate
Spring Framework
PHPUnit
DynamoDB
Neo4j
LAMP
Amazon Web
                                Services
CI
Android
Kotlin
Laravel
NodeJS
VueJs

Отдел
Java-разработки

«Когда у тебя в руках молоток, все проблемы выглядят как гвозди. Рабочий инструмент нашего отдела — Java, который открывает практически безграничные перспективы для разработчика в решении любых, даже самых нетривиальных задач»

Василий

Рук. отдела Java-разработки

Отдел
PHP-разработки

«Мы — команда профессиональных PHP-разработчиков с опытом создания IT-проектов любого типа: от простых веб-сайтов до CRM-решений и больших маркетплейсов. С нами ваши затраты на разработку сокращаются, а инвестиции окупаются быстрее»

Евгений

Рук. отдела PHP-разработки

Отдел
тестирования

«Обеспечить пользователей качественным продуктом — главная задача специалистов отдела тестирования, с которой они отлично справляются. Отдел принимает участие в оптимизации процессов разработки ПО и взаимодействия между командами, что непосредственно влияет на улучшение качества продукта»

Александра

Рук. отдела тестирования

Отдел
бизнес анализа

«От работы бизнес-аналитиков напрямую зависит доверие заказчика к компании. Перед ними стоит непростая задача — выявить проблемы бизнеса и найти максимально эффективное решение»

Никита

Рук. отдела бизнес анализа

Отдел
дизайна

«Талант и креативность наших дизайнеров проявляются буквально во всем. Они умеют сочетать требования заказчиков с простыми и стильными дизайнерскими решениями. Главная задача нашего отдела — сделать заказчика счастливым, а дизайн удобным для пользователей»

Технический
отдел

«Главные задачи отдела — создание окружений для разработчиков и поддержка пользователей. Благодаря нашим техническим специалистам обеспечивается бесперебойная работа программных и аппаратных средств компании»

Сергей

Рук. технического отдела

Ценности:

Сотрудники

Основополагающей ценностью ITSupportMe являются наши сотрудники. Тщательно отбирая и профессионально обучая специалистов, мы даем им возможность продвигаться по карьерной лестнице, вносить свежие идеи и получать удовольствие от работы.

Заказчики

Мы видим смысл нашей работы в том, чтобы бизнес клиента работал максимально эффективно.

Качество

Мы задаём высокие стандарты качества продукта, чтобы быть уверенными в том, что он соответствует требованиям и пожеланиям заказчиков.

Принципы:

Профессионалы своего дела

Наши требования к самим себе постоянно растут. Для того, чтобы добиваться успеха в сфере информационных технологий, мы идём в ногу со временем, постоянно учимся новому и внимательно следим за направлениями развития IT-сферы.

Планируем цель — находим решения

Наша главная цель — качественный и удобный для работы продукт. Для достижения этой цели мы тесно взаимодействуем в команде, применяя гибкую методологию разработки.

Отдых — залог эффективности

Компания делает все для того, чтобы у работника была возможность расслабиться и вернуться к работе с новыми силами. В офисе есть уютная комната отдыха, а кухни оснащены всем необходимым для того, чтобы вкусно обедать. Для посещения доступны фитнес-центр и СПА-комплекс, бассейн.

Последние новости

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