И снова здравствуйте! Меня зовут Светлана, я руковожу отделом методологии и развития системы управления проектной деятельностью в ГК «Цифра». Ранее я уже писала на Хабр про успешное бюджетирование проектов. Сегодня хочется поговорить о таком аспекте проектного управления, как планирование его доходности и маржинальности. Cтатья будет интересна прежде всего руководителям проектов разработки и внедрения ПО, а также ответственным за бюджетирование таких проектов.

В статье рассматриваются следующие проблемы:

 • Замкнутый круг низкой рентабельности

• Анализ «Затраты-объем-прибыль»

• Сколько стоит простой сотрудника

• Как НЕЛЬЗЯ считать загрузку

• Токсичность скидок

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

 Зачем? Да потому что высокая маржинальность проектов обеспечивает жизнеспособность и дальнейшее развитие продуктов и компании в целом.

Группа компаний «Цифра» презентовала свою дизайн-систему Prizm, имеющую открытый исходный код. Это первая российская дизайн-система для индустриальных цифровых решений.

Мои коллеги уже написали не одну статью для Хабра о наших роботах-самосвалах. Я хочу продолжить эту серию материалов, но мой рассказ будет не о лидарах, радарах и прочем железе, а о людях, задача которых – приглядывать за роботами в карьере, чтобы они случайно не нарушили производственный процесс или чего доброго – законы Азимова.

Всем привет! Меня зовут Андрей Федотов, я бэкенд-разработчик в одной из команд платформы интернета вещей ZIIoT Oil&Gas. В этой статье я рассказываю, что нужно знать и как работать с HttpClient в .NET, чтобы не получить трудноподдерживаемый и сложный код и не нарваться на глобальный рефакторинг.

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

Меня зовут Николай Усов, я работаю в отделе тестирования «Цифровой индустриальной платформы». В нашей команде в качестве системы управления тестированием программных продуктов используется Test IT. Система в целом нам нравится, претензий к функционалу почти совсем нет. Однако инструментарий Test IT не всегда позволяет настроить работу тестировщиков так, как удобно. Например, тот, кто с ней работал, знает, что при большом количестве тестов может быть затруднительным поддержание соответствия между автоматизированными и ручными тест-кейсами, если их слишком много. Плюс могут потребоваться иные методы расчета успешности автотестов или более простой интерфейс для удаленного просмотра статистики по прогонам. В этой статье я расскажу, как с помощью telegram-бота, работающего в связке с Test IT, мы сделали жизнь тестировщиков немного приятнее.

Всем привет! Меня зовут Ксения Непомнящая, я — технический писатель в команде Zyfra Mass & Energy Balance (Z-MEB) компании «Цифровая индустриальная платформа». Z-MEB — это продукт для предприятий добычи и переработки нефти, газа и руды, участвующий в программе импортозамещения. Сегодня предлагаю вам взглянуть на пользовательскую документацию как на путеводитель по продукту и рассмотреть ее роль в увеличении ценности продукта.

Понятный интерфейс как город с понятной планировкой и развитой инфраструктурой

Представим себе город с понятной планировкой и развитой инфраструктурой и рассмотрим два варианта взаимодействия с ним.

Всем привет! Меня зовут Елена Галата, в ГК "Цифра" я руковожу направлением разработки программного обеспечения. Хочу сегодня немного поговорить об информационной безопасности и о том, как она выглядит со стороны тех, кто имеет отношение к созданию ПО. Не только программистов, но и специалистов QA, аналитиков, продуктовиков и других. В этой статье я и хочу обсудить три важных вопроса: почему нам так важна безопасность, как она выглядит со стороны разработки, и куда двигаться дальше.

Меня зовут Юлия Седова, и я представляю команду технических писателей ГК «Цифра». В рамках масштабной работы по повышению качества документации мы столкнулись с проблемой отсутствия культуры предварительного планирования трудозатрат технического писателя. В этой статье я хочу поделиться нашим решением проблемы.

Всем привет! Тут уважаемые коллеги уже много раз писали о различных инструментах и технологиях платформы ZIIoT для работы с промышленными данными и создания приложений. Но как-то руки пока не доходили до одного из самых важных ее компонентов — единой объектной модели (ЕОМ). В этой статье я исправлю это недоразумение и расскажу, как реализована концепция ЕОМ у нас и как работает наш инструмент для графического конфигурирования моделей — Zyfra Graphic Object Designer. Меня, кстати, зовут Александр Пучков, я ведущий владелец продуктов в компании «Цифровая индустриальная платформа», которая занимается развитием отдельной модификации ZIIoT для нефтегазовой и нефтехимической отраслей – ZIIoT Oil&Gas – и приложений на ее основе.

Случается, что нам, техническим специалистам, нужно принять решение в пользу того или иного кандидата для найма в команду. Обычно мы делаем упор на технические знания и навыки и не слишком обременяем себя размышлениями о том, подходит ли подходящий нам по техническим компетенциям кандидат под уже сложившуюся модель взаимоотношений внутри коллектива и может/хочет ли он справляться с ролью, которую ему в этом коллективе предстоит играть. В этой статье, которую я назвал по мотивам известного альбома Pink Floyd, я хочу рассказать, как на собственном опыте убедился, что обременить себя этими размышлениями при найме специалистов не только полезно, но и необходимо. Можете считать это работой над ошибками.

Дисклеймер. Эта статья создана техническим специалистом, чтобы помочь таким же техническим специалистам выработать свой подход к найму персонала, а не HRом для HRов. Если что-то тут кажется очевидным для  HR-профи или написано недостаточно научно, то ну и ладно.

Всем привет! Меня зовут Сергей Лысов, я занимаюсь тестированием производительности платформы интернета вещей ZIIoT Oil&Gas. Если вы о ней еще не слышали, то велком сюда. А в этой статье я расскажу о том, как мы ускоряли и упрощали ее тестирование через автоматизацию контроля тестов и сборки  отчетов, а также внедрение изолированных тестов. Точнее — с чего мы этот путь начали и куда примерно движемся.

Переносимость процессоров и паттерны

Вот и обещанная третья часть саги о том, что в NiFi можно делать и как это делать правильно, без претензий на истину в последней инстанции, конечно. Сегодня расскажу о переносимости процессоров и дам несколько паттернов для самых популярных задач на платформе ZIIoT. Если вдруг вам интересно почитать про оптимизацию схем и производительности в NiFi — велком в первую часть. Если мечтаете узнать больше о мониторинге, то вторая часть — must read. Только потом сюда не забудьте вернуться.

Всем привет! Меня зовут Алексей Бакукин, я старший бизнес-аналитик в дивизионе «Цифровой завод» ГК «Цифра». Из названия понятно, что мы занимаемся проектами цифровизации заводов. Чаще всего эти проекты преследуют две цели:

1. Рост прибыли предприятия за счет уменьшения затрат или увеличения выхода продукции.

2. Упрощение процесса, автоматизация типовых действий (отчет, расчет, дашборд и так далее).

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

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

Мониторинг 

Продолжаем разговор о том, что в NiFi делать можно и нужно, а что можно, но лучше не стоит. Если вы пропустили первую часть разговора, то вам сюда. Там про улучшение читаемости схем и повышение производительности (ну почти). Здесь же пойдет речь о том, как проводить мониторинг бизнес-части схемы, чтобы всем было хорошо (ну или чтобы не было плохо), ну и немного о переносимости процессоров. Поехали!

Есть мнение, что хуже всего — не вести мониторинг бизнес-части схемы совсем, используя популярный подход «и так сойдет!». Но если подумать, есть одна вещь хуже отсутствия мониторинга — неправильный мониторинг.

Улучшаем читаемость схем и повышаем производительность

Всем нам (ну хорошо, большинству!) приходится иметь дело с Apache NiFi в качестве ETL-инструмента. У нас он используется для управления потоками данных в платформе ZIIoT (кому интересно, что это за зверь, можно почитать здесь). Apache NiFi — инструмент хороший, местами удобный, позволяет быстро решать задачи, в том числе и достаточно высокой сложности, не формируя для этого отдельную группу разработчиков. Однако, как правило, по ходу проекта условия этих задач меняются несколько раз, и нередко их решением на разных этапах занимаются разные люди в режиме аврала. И вот в результате мы видим НЕЧТО

Привет, Хабр! Меня зовут Илья, я — разработчик систем восприятия окружения в компании Zyfra Robotics. Проще говоря, я учу самосвалы и буровые станки «видеть» окружающий их мир. Наши роботы бурят скважины на просторах Перу, а самосвалы без водителей трудятся на карьерах Хакасии. Чтобы они могли делать это быстро и, главное, безопасно, мы наделяем машины «глазами» и учим ими пользоваться. Для этого мы применяем камеры, радары и, конечно, лидары. В этом посте я хочу рассказать, что это вообще такое и с какими проблемами мы сталкиваемся.

Всем привет! Недавно у нас в Группе компаний «Цифра» прошла очень крутая ежегодная внутренняя техническая конференция TechTalks. Мы настолько ей гордимся, что решили поделиться внутренней кухней с вами и рассказать про ивент через призму того, как мы его делаем.

У нас очень много команд разработки в Москве, Кемерове, Смоленске, Санкт-Петербурге, Иванове и нам важно, чтобы коллеги чувствовали, что работают в единой команде, перенимали опыт друг друга, учились друг у друга, поэтому мы придумали TechTalks. Это неформальная корпоративная ИТ-конференция. Все мероприятие мы делаем своими силами, так как понимаем, что лучше нас самих такой ивент никто не сделает.

Известно множество практик борьбы с выбросами во входных данных – применяются  как статистические методы, так и ML/DL-подходы. Каждый специалист по анализу данных использует их в процессе предобработки данных. Однако часто при этом отсеиваются исключительно ценные замеры, которые на самом деле выбросами не являются, а представляют собой редко встречающиеся состояния измеряемого объекта или процесса.

 "А стоит ли возиться с этими "редкими" состояниями?", – спросит нас любознательный читатель. "Да", – уверенно ответим мы и далее приведем один простой и показательный пример, а сразу за ним расскажем, как извлечь пользу из этих редких состояний. Конкретнее – мы предложим подход для генерации дополнительных измерений в задачах восстановления регрессии временного ряда.

Под "мы" здесь и далее имеются в виду я – Семён Косяченко – и мои коллеги Александр Подвойский и Александр Калиниченко. Вместе мы разрабатываем решения на основе ML для нефтегазовой отрасли в компании "Цифровая индустриальная платформа" (совместное предприятие ГК "Цифра" и "Газпром нефть").

Многие читатели «Хабра» имели опыт построения «умного дома» и, скорее всего, использовали для этого беспроводные устройства. Кто захочет портить квартиру/дом, особенно после ремонта, ворохом проводов? Но вот на заводе для решения подобных задач беспроводных датчиков вы вряд ли увидите. Мы в отделе аппаратной разработки компании «Цифра» решили это исправить и сделали беспроводное устройство для сбора промышленных данных. Зачем оно нам понадобилось и как мы его разрабатывали, расскажу под катом.

Привет, Хабр! Меня зовут Светлана Захарова, и это мой первый пост. Я работаю в команде внедрения ВИСТ, ГК «Цифра», а именно обеспечиваю жизненный цикл бюджетирования проектов нашей компании. Хочу поделиться своим опытом и сконцентрировать внимание заинтересованных читателей на некоторых деталях этого процесса. В этой статье речь пойдет о начальных этапах управления проектом – его бюджете, и, возможно, тема будет не столько интересна сообществу разработчиков, сколько руководителям проектов внедрения, которые, как ни удивительно, слишком часто проявляют некоторое легкомыслие при планировании. В дальнейших статьях я постараюсь рассмотреть более технические вопросы, связанные с интеграцией наших систем в единую систему управления проектами внедрения.