• Настоящий металл: как сплавить команды в горниле совместной разработки

      У нас было 2 проектных менеджера, 72 эксперта от производства, 33 высококлассных спеца из двух IT-команд, несколько десятков систем управления производством по всей стране, а еще, разработчики КРОК и Группы НЛМК прежде не работали вместе.

      Звучит как организационный ад, и это недалеко от истины. Но мы справились и теперь хотим поделиться опытом работы в объединенной команде Группы НЛМК и КРОК в масштабном проекте по развитию информационных сервисов службы продаж.

      Читать далее
      • +25
      • 3,1k
      • 1
    • Из тестировщиков в агенты изменений департамента: путь в 10 лет и два выгорания

        image

        Хабр, привет! Меня зовут Ася, я ведущий инженер-тестировщик (QA Lead) в КРОК.

        Недавно я отметила десятилетний юбилей в компании и в тестировании одновременно — да, за столько лет мне не надоело ни там, ни там. Хотя насчет тестирования было по-разному — успела даже дважды выгореть (один раз из-за декрета), стать контрол-фриком и влюбиться в профессию заново.

        Про профессию тестировщика часто слышу, что это самый легкий и быстрый порог входа в ИТ — а там и на разработчика переучиться можно. Я же наоборот — училась на разработчика и даже успела им немного поработать, но душа к этому не лежала, потому что искать баги намного веселее. За всю мою карьеру я участвовала в совершенно разнообразных проектах: документооборот, файлообменники, статистические наблюдения, обработка обращений пассажиров в ЦППК, учет оборудования. А потом поняла, что этот опыт можно масштабировать на свою жизнь и даже на работу целого департамента. Так я стала агентом изменений департамента разработки программного обеспечения (ДРПО).

        В этой статье хочу рассказать про свой путь и постараться ответить на вопрос, который мучает многих тестировщиков — а есть ли жизнь на Марсе задор и челленджи после многих лет в тестировании?
        Читать дальше →
        • +36
        • 9,3k
        • 3
      • MLOps — Cook book, chapter 1

        • Tutorial


        Всем привет! Я CV-разработчик в КРОК. Уже 3 года мы реализуем проекты в области CV. За это время чего мы только не делали, например: мониторили водителей, чтобы во время движения они не пили, не курили, по телефону не разговаривали, смотрели на дорогу, а не сны или в облака; фиксировали любителей ездить по выделенным полосам и занимать несколько мест на парковке; следили за тем, чтобы работники носили каски, перчатки и т.п.; идентифицировали сотрудника, который хочет пройти на объект; подсчитывали всё, что только можно.


        Я все это к чему?


        В процессе реализации проектов мы набили шишки, много шишек, с частью проблем вы или знакомы, или познакомитесь в будущем.


        Моделируем ситуацию


        Представим, что мы устроились в молодую компанию “N”, деятельность которой связана с ML. Работаем мы над ML (DL, CV) проектом, потом по каким-либо причинам переключаемся на другую работу, в общем делаем перерыв, и возвращаемся к своей или чужой нейроночке.


        1. Наступает момент истины, нужно как-то вспомнить на чем ты остановился, какие гиперпараметры пробовал и, самое главное, к каким результатам они привели.
        Читать дальше →
        • +24
        • 5,3k
        • 4
      • Используем Xtend для прикладной кодогенерации: сеанс чёрной магии с разоблачением

        Привет Хабр! Меня зовут Когунь Андрей. В КРОК я руковожу группой разработчиков Java (у нас большая распределённая по всей стране команда). Ещё я провожу встречи московского сообщества Java разработчиков JUG.MSK. Делаю это исключительно в корыстных целях: фотографируюсь там со всеми докладчиками, и однажды открою галерею с самыми интересными людьми в мире Java-разработки. Также помогаю делать конференции для разработчиков: JPoint, Joker и DevOops — в качестве члена программного комитета. Ну и для души, так сказать, преподаю Java-технологии студентам.


        В КРОК мы с коллегами в основном занимаемся заказной разработкой. Одно из наших направлений — так называемые учётные системы. Их надо делать по возможности быстро. Они типовые, различия обычно наблюдаются только в доменной модели. Поэтому мы постоянно боремся за то, чтобы писать меньше бойлерплейт-кода, будь то тривиальные геттеры-сеттеры, конструкторы и т.п. или CRUD-репозитории и контроллеры. Мы для этого активно пользуем кодогенерацию.


        Про неё сейчас и расскажу: покажу как взять кодогенерацию под контроль, чтобы она стала реально полезным инструментом разработчика. Попутно расскажу про технологию Xtend и покажу практические приёмы как с ней можно работать. Покажу как создавать собственные активные аннотации, писать и отлаживать код процессора аннотаций.


        Читать дальше →
        • +39
        • 3,9k
        • 6
      • Какие ошибки делают руководители на удалёнке

          Привет, Хабр! Я не разработчик, а менеджер. Меня некоторое время учили управлять людьми, а потом я погрузилась в мрачный мир разработки, где всё идёт не так, как говорят в университете. Сейчас я руковожу практикой управления жизненным циклом программного обеспечения и хочу рассказать несколько, возможно, важных для тимлидов и ПМ'ов вещей, которые касаются перехода на удалёнку. Потому что в наших командах люди было уже начинали так косячить. А потом покажу и расскажу про наш стек автоматизации для удалёнки, и о том, как мы аппрувим релизы из чатов на телефоне одной кнопкой, а не поднимая VPN в защищённый периметр, и это ускорило согласования, и это помогает согласовывать день в день.

          Первый совет — хватит доставать своих людей!



          Я знаю, звучит очень глупо, но многие руководители, не видя людей рядом, начинают как-то компенсировать своё желание убедиться, что они работают. Происходят вот такие чаты:


          Дятел-менеджмент в чистом виде

          Если стоит задача повысить эффективность команды сейчас и в перспективе — оставьте людей в покое. И установите 15-минутные дейли по утрам. Я уже успела увидеть и общепроектные синхры раз в четыре часа, и дейли по два часа, и впадающих во фрустрацию менеджеров, привыкших договариваться сидя лицом к лицу с кем-то.
          Читать дальше →
        • Хакатон на 200 человек — что нужно для организации



            Знаете, почему проекты в крупных компаниях делаются по полгода? Потому что один из самых медленных процессов — это общение с заказчиком для выявления деталей его потребностей. Простое уточнение ТЗ (на гвозди или на клей надо крепить) может занимать до трёх месяцев. Я сейчас, конечно, несколько утрирую, но реальность в том, что почти никогда нельзя просто взять написать или позвонить и получить прямой ответ. Надо дождаться всех из отпусков и собрать совещание.

            Вторая особенность сферы — чтобы началась автоматизация чего-то, нужно, чтобы заказчик знал, что это в принципе можно автоматизировать. И понимал, дёшево или нет. С учётом скорости развития технологий (особенно нейросетевых детекторов) некоторые вещи выходят за рамки представления опытных промышленников, а некоторые резко дешевеют и становятся доступными. Но задача писать их с нуля не ставится.

            Это понимали мы и понимало руководство СИБУРа, нашего мощного промышленного партнёра, который помогал с проведением и организацией хакатона. Надо было устранять зазор между тем, что уже сделано и тем, что можно и нужно сделать по автоматизации. Для этого мы решили собрать на одной площадке сразу четыре стороны:

            1. Крупнейшие промышленные компании страны.
            2. Вендоров технологий с меняющихся рынков.
            3. Молодых разработчиков.
            4. ИТ-инженеров с опытом работ в сфере или в конкретных нужных технологиях.

            Смысл в том, что крупные компании приходят со своими задачами, а разработчики на подобных хакатонах пытаются показать концепт их решения. Если всё хорошо — получают контракт, на базе которого можно основывать компанию. Заказчики же тратят два-три дня своего времени на ответы на вопросы, зато получают очень хорошую картину технологий и сразу множество прототипов решений.

            Вот отчёт по задачам и их решению. Но сам пост будет про то, как мы организовывали мероприятие — возможно, это пригодится вам для своих хакатонов.
            Читать дальше →
          • Разбор решения задач реальной промышленности (спасение поросят и другие)

              Свиноматка кормит поросят до 26-го дня. За это время она может на них прилечь, что приведёт к тому, что поросят станет чуть меньше, чем было в самом начале. Чтобы этого избежать, используются вот такие станки, как на фото, которые исключают её повороты и хождение по загону. У одной свиноматки — от 10 до 15 поросят. На первой неделе поросята ещё не понимают, что эта туша опасна, и могут не уйти из опасной области, когда она ложится. Когда это происходит, поросёнок громко визжит примерно в половине случаев. Часть поросят можно спасти, если вовремя поднять свинью. Задача — детектировать такие случаи и вызывать сотрудника.


              Как видите, этот вариант решения распознаёт поросят на видео и считает их.

              Ещё были задачи оптимизации вентиляции в шахте (сэкономить на электричестве, но не убить при этом шахтёров); моделирование растекания жидкости; матмодель расплава; определение каски и очков на сотруднике перед входом в опасную зону и поиск брака на шоколадных батончиках.

              Когда представитель MARS сказал, что принесёт обучающую выборку, мы не думали, что это будет четыре коробки шоколадок Twix Minis.
              Читать дальше →
            • Как мы летали на дронах по мусорным полигонам и искали утечки метана


                Карта полёта, отмечены точки с концентрацией метана свыше 3 000 ppm*m. И это много!

                Представьте себе, что у вас есть мусорный полигон, который время от времени дымит и воняет. Связано это с тем, что при гниении органики образуются различные газы. При этом образуется не только метан, но и совсем ядовитые газы, поэтому полигоны ТБО иногда нужно обследовать.

                Обычно это делается пешим обходом с носимым детектором метана, но на практике это очень сложно, долго и вообще не особо нужно владельцам мусорного полигона.

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

                Услуга автоматизированного замера уровня метана с помощью дронов очень востребована в Европе.

                Мы, с нашими партнёрами из компании Пергам, провели совместную работу в этом направлении и получили интересный результат.
                Читать дальше →
              • Байки переговорщика



                  Привет!

                  Начинал я с разработчика, сейчас руковожу департаментом разработки программного обеспечения и часто участвую в переговорах по разным проектам. По большей части речь о деталях реализации, то есть это не продажи, а обсуждение проектов с заказчиком. Но всё равно на них весело. Например, недавно наш человек чувствовал себя довольно неуютно, когда одному из резидентов Сколково объяснил, что блокчейн в проекте не нужен. Смотрели на него косо, и ощущение было, что он их убеждает в том, что вместо новомодного электричества всё можно решить на паровой или лошадиной тяге.

                  С другой стороны, частые переговоры означают много поездок. Иногда везёт. Вот в Дубае выходные пятница и суббота, а воскресенье — рабочий. При этом рейсы на воскресенье дорогие, и куда выгоднее лететь в пятницу. Встреча по поводу наших разработок по машинному зрению для дронов была на воскресенье, и когда наш переговорщик прилетел, заказчик извинился и сказал, что не получается, и нужно перенести ещё на пару дней. Так у него получились незапланированные выходные. Ну а дальше он закономерно вышел на пляж и уснул. После чего всем говорил, что сгорел на работе. Но интересно не это: дело в том, что ещё один наш коллега как раз застрял посреди тундры. Это примерно два часа вертолётом от Нового Уренгоя, и, кроме вертолёта, там транспорта нет. У него была метель — и, как следствие, нелётная погода. Он прибыл, обследовал талевые канаты и не смог вылететь. К началу истории уже сидел там два дня. Синоптики обещали открыть площадку только ещё через три дня. Из развлечений у него там была еда в столовой на месторождении, настольный теннис с вахтовиками и SMS на телефоне. Вот они друг другу и жаловались, кто и где застрял.
                  Читать дальше →
                • Database as Сode. Копаем глубже


                    В IT-проектах код пишут все. Инженеры с помощью нескольких строк управляют Kubernetes кластерами, разгоняют облака Terraform'ом и ворочают тонны конфигураций на Ansible, Chef и Puppet. QA пишут понятные бизнесу тестовые сценарии на Spock и Cucumber. Аналитики свободно, часто лучше разработчиков, разговаривают на SQL. Проектная документация в форматах Markdown, AsciiDoc или LaTEX "компилируются" в нужный формат на билд-сервере. Ну а сами разработчики, эти укротители кода, владеют сразу россыпью языков на каждый жизненный случай — клиентский, серверный, скриптовый, функциональный и пр.


                    Код уже давно перестал быть загадочной тарабарщиной и теперь в том или ином виде доступен и понятен многим, даже премьер-министрам. И весь этот код участвует в стандартном жизненном цикле — находится под управлением VCS, подвергается code review, автоматизированному тестированию, CI, CD. Используются общие инструменты и подходы, метрики производительности и качества. А все вместе это носит гордое название — "Everything as code".


                    Однако мир БД традиционно стоит особняком вдалеке от этой феерии прогресса и технологий. Процесс разработки и сопровождения БД не меняется годами и продолжает вселять ужас и страх в разработчиков, администраторов и пользователей по всему миру. Но возможно ли представить БД в виде обычного кода? Приблизиться к основному процессу разработки, использовать общие инструменты и подходы? Об этом под катом.

                    Database as Code? Что за дичь?
                  • Oracle Certified Associate и Oracle Certified Professional. Общее впечатление и нюансы подготовки

                      Привет, Хабр!

                      Меня зовут Маша, я работаю в КРОК. Сегодня я хочу рассказать вам о получении сертификатов Oracle Certified Associate и Oracle Certified Professional.



                      Вообще, в спорах о полезности профессиональной сертификации (да и ее необходимости в принципе) среди разработчиков довольно часто ломаются копья. Некоторые уверены, что для найма на приличную работу сертификат крайне желателен. Другие говорят, что “бумажки” не играют особой роли, даже диплом о высшем образовании может не потребоваться, оценивать будут исключительно навыки.

                      Бывают случаи (вероятно, если процесс собеседования не очень отлажен), когда HR может отсеять человека без сертификата, хотя такой человек на самом деле более чем справился бы с работой. Или, наоборот, среагировать на наличие сертификата, устроить техническое собеседование с разработчиком, который, правда, быстро поймет, что кандидат вообще зашел случайно, и начнет подозревать, что кроме сдачи сертификата он ничего не изучал и не использовал в работе.

                      Как бы то ни было, есть люди, которым сертификаты нужны. Как для портфолио, так и для себя лично. Под катом я поделюсь впечатлениями от сертификации Oracle по Java: Oracle Certified Associate (1Z0-808) и Oracle Certified Professional (1Z0-809). В мировой практике наличие этих сертификатов является подтверждением определенного уровня квалификации java-разработчика, поэтому многие эту процедуру проходят.
                      Читать дальше →
                    • Разработка изнутри: люди, утки и много работы

                        Привет, Хабр!

                        Разработка в интеграторе обычно довольно сильно отличается от работы в стартапе или студии разработки программного обеспечения. Из плюсов – куда более глобальные задачи, над решением некоторых из них работают сотни специалистов одновременно, так что заскучать не получится. А еще — возможность оперативно прокачать собственные навыки и вырасти внутри команды.

                        Из минусов – такая работа не всегда видна конечному пользователю, ну и из-за некоторых NDA размером с тостер не обо всем можно рассказывать.


                        Когда хотел рассказать про занятный проект, но там опять NDA

                        Меня зовут Иван, я технический менеджер (Java) в КРОКе. И сегодня я постараюсь немного приоткрыть завесу тайны и рассказать о том, как у нас в целом работается разработчикам, которых около 350 человек, а также о текущих вакансиях (Java, PHP и фронтенд). Подробности – под катом.
                        Читать дальше →
                      • Devops в кровавом энтерпрайзе


                          Вот к такому можно стремиться

                          У нас больше 350 своих разработчиков ПО и тестировщиков по всей стране, плюс мы часто взаимодействуем с инженерами и разработчиками заказчиков. Чтобы перейти на практическое использование devops, нам нужно было обеспечить не только внедрение методологии, но и приучить любимых российских заказчиков к некоторой базовой культуре. Просто пара диалогов для понимания:
                          — Почему у нас всё упало?
                          — Потому что вы откатали это на стенде, всё протестировали, а потом развернули на проде. Вот у вас настройка, которая не попала в инструкции, и жила только в голове старого админа.

                          Или:
                          — Почему не запускается по всей стране?
                          — Потому что у вас несколько десятков разных региональных инсталляций, каждая делалась руками, и на каждой разные конфиги. И ещё в паре случаев инженер ошибся.
                          — Поправите до завтра? Очень нужно! Только доступ удалённо мы вам не дадим.
                          — ..! Конечно, у нас есть команда высокооплачиваемых спецов, обожающих ездить на Дальний Восток. Нет проблем.
                          Читать дальше →
                        • Эксплуатация зданий: что будет, если один раз подойти с умом

                            Карточка оборудования на модели здания — к ней прикреплены работы, затраты по единице железа, все документы (договоры, гарантия и пр.), инструкции и регламенты.

                            Вот строят торговый центр. Сразу, когда строят, рассчитывают, что, например, то же кондиционирование будет требовать столько-то энергии, столько-то работы по обслуживанию. А потом выясняется, что где-то они проёмы так заложили, что оборудование внутрь уже не занести. И вместо одной мощной единицы появляется две, зато которые можно занести внутрь. Или вот надо было сделать определённую конструкцию для специального оборудования. Иностранный подрядчик сказал:
                            — Привезли не ту конструкцию, мы её уже смонтировали, но ваше оборудование не подходит. Либо простой, либо так принимайте и покупайте другое.

                            И все расчёты дальше идут лесом. Звучит дико, но так почти на каждом объекте.

                            Вот тут пригождаются информационные модели, а точнее — приложения для управления эксплуатацией, которые работают в связке с моделями зданий. Хотя бы для того, чтобы тот же торговый центр мог элементарно посчитать, что и сколько стоит в эксплуатации. Конечно, обходится не без воплей — сразу становится видно, кто, где и сколько эээ…нецелевым образом расходует.

                            Естественно, BIM-приложения дают много и в том случае, если здание уже построено и надо эксплуатировать рациональнее. Да, бывает, что модели нет (а иногда даже и простой 2D-документации), но все эти проблемы решаемы. Мы же в будущем, чёрт побери, тут всё продумано!
                            Читать дальше →
                            • +32
                            • 17,2k
                            • 7
                          • Интеграция — байки



                              Тебе хана, если ты не влез в бизнес-процесс заказчика, а копаешься только в ИТ-процессе.

                              Это общее правило почти не знает исключений. Потому что ИТ-структура часто не владеет данными и не знает, зачем они дальше нужны. А когда речь про интеграцию (без которой не обходится ни одно внедрение цифрового инструмента, будь то модный чат-бот или олдскульный CRM) — это нужно очень точно и детально понимать.

                              Я видел много разных историй: и то, как один малюсенький сервис для работы с факсами после внедрения начал вести себя как вирус и бороться с почтовым сервером и другими сервисами компании (кстати, победил), и то, как сегмент «малый и средний бизнес» не включал в себя средний бизнес (к искреннему удивлению ИТ-отдела), и как люди просто не знали, в чём смысл обрабатываемых данных и зачем они нужны — это часто касается финансов.

                              Поэтому давайте расскажу пару баек про то, что случается, когда нужно просто взять и соединить несколько ИТ-систем. Делов-то!
                              Читать дальше →
                            • Что может чат-бот

                                Сначала мы выделили основные офисные процессы. Про чат-бота мы даже не говорили. Вот, например, заказ командировок. Сейчас я должна написать сотруднику службы деловых поездок в почту: «Я собираюсь в командировку в Сургут 5-го числа на три дня», а он: «Такой-то самолет и такая-то гостиница — всё подходит?», а я: «Да, давай». Дальше он пойдет согласовывать с руководством, забронирует сам билеты, спустя какое-то пришлёт мне подтверждение, что все Ок. Всё то же самое может делать бот.

                                Или если нужна справка для визы, то бот постучит в шину, шина постучит в кадровую подсистему и заберёт PDF, дальше отправит его на принтер отдела кадров и напишет письмо, что туда нужна печать. Затем уведомит меня, что можно подойти через пару часов. Если нужно оформить пропуск на гостя или забронировать переговорку для встречи, то достаточно поручить боту эту задачу, и он её выполнит.



                                Теперь давайте покажу пример чуть посложнее.

                                Читать дальше →