• Байки переговорщика



      Привет!

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

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


        Одна из главных задач ИТ сейчас в производственном секторе — уменьшить количество аварий.

        Что сейчас меняется на производствах?


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

        Всё идёт к тому, что через десять лет все сотрудники производств будут «под колпаком». Сейчас уже есть пилоты, но до массового распространения технологий ещё пара лет. Будет интерфейс руководителя производства, подозрительно напоминающий компьютерную игру. Там положение каждого сотрудника, свойства и состояния каждого станка, очередь задач, самочувствие каждого, тип исполняемых операций. Смысл в том, чтобы оцифровать всё и контролировать правильность исполнения процессов. И ещё вспомогательный AI будет оптимизировать задачи сотрудников — уже есть примеры, где работа распределяется по оптимальной загрузке станков и навыкам рабочих, правильно кластеризуется и выстраивается в оптимальной последовательности.
        Читать дальше →
      • Примеры дичи из заказов «приходите спасать» (разбор десятка инцидентов с примерами)

          Иногда бывает так:

          — Приезжайте, у нас упало. Если сейчас не поднять — покажут по телевизору.

          И мы едем. Ночью. На другой край страны.


          Ситуация, когда не повезло: на графике показан резкий рост нагрузки на СУБД. Очень часто это первое, на что смотрят администраторы системы и это первый признак того, что наступила жопа

          Но чаще речь идёт про какие-то типовые вещи. Например, заказчик столкнулся с низкой производительностью системы документооборота. По понедельникам и вторникам система падала, они перезагружали сервер, и потом всё поднималось. Захлёбывалась база данных. Хотели докупить оборудования (что долго и дорого), позвали нас просчитать смету. Мы им посчитали смету и заодно предложили разобраться, что же именно тормозит. За три-четыре часа локализовали источник проблемы. Выяснили, что это медленные запросы в базу данных и неоптимальные схемы индексирования. Создали недостающие индексы, поковырялись с оптимизатором запросов в Оракле, некоторые проблемы потребовали изменения кода — поменяли условия поиска (без изменения функциональности), заменили часть запросов на использование предрассчитанных представлений. Если бы у них был нормальный человек по БД — могли бы сделать то же и сами. Но вместо нормального человека был аудит базы данных раз в полгода крутыми ораклистами — они выдавали общие рекомендации по настройкам и железу.
          Читать дальше →
        • Devops в кровавом энтерпрайзе


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

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

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


              Типовое рабочее место: два монитора, дорожный ноутбук, лампа, интернет

              У нас очень много работы в разработке, и далеко не вся она требует присутствия в Москве, и далеко не всех разработчиков можно легко найти в столице. Поэтому принцип довольно простой: находим разработчиков в городе, где им приятно жить, снимаем там хороший и удобно расположенный офис и просто присылаем задачи. Связь по сети, еда в ближайшем ресторане по абонементу. И все счастливы. Мы — тем, что получаем «головы», которых нет в Москве, по ценам города (разница с Москвой вполне окупает аренду офиса), а разработчики могут работать у себя и путешествовать по стране.


              Тестировщик в Иркутске

              «Телепорты» сделаны так: можно поехать в любой другой такой же центр разработки на 4 недели на пробу поработать там. С сохранением зарплаты, и ещё гостиница и питание — за счёт компании. Если «порт приписки» Москва, то, перемещаясь в другой офис, надо ещё обязательно прочитать семинар.

              Проекты, над которыми работают распределённо по стране, — от автоматизации АЭС до разного прикладного софта «Ленты», Мосгорсуда, Росстата и так далее.

              Всего у нас сейчас 7 таких центров — от маленького офиса на 5 человек в бизнес-центре до большой региональной команды из 30 разработчиков и тестировщиков. Но, конечно, исторически пока больше всего разработчиков и тестировщиков в Москве — около 250 человек (это один из самых больших отделов в КРОК). Однако скоро процент работающих в других городах грозит приблизиться к половине. География довольно обширная: Москва (включая отдельный небольшой офис в Троицке), Петербург, Нижний Новгород, Самара, Иркутск, Пермь, Краснодар.
              Читать дальше →