Управление разработкой *

RPA 2025: Как программные роботы меняют бизнес уже сегодня

ITFB Group и Primo RPA приглашают на вебинар, посвященный роботизации бизнес-процессов в 2025 году.

Когда: 10 июня, 11:00

Формат: онлайн

➡️ Зарегистрироваться

Технологии RPA стремительно меняются, и мы разберём, как максимально эффективно использовать их сегодня.

Обсудим:

• Как изменилось отношение к Роботизации за последние годы и почему компании продолжают внедрять RPA.

• Как программные роботы помогают ИТ-отделам справляться с растущим потоком задач, а бизнесу — быстро получать измеримые результаты.

• Российские кейсы: реальный опыт внедрения, ошибки и успехи.

Спикеры:

• Илья Кочетов, директор по технологическому развитию платформы Primo RPA.

• Николай Чекин, директор по развитию отношений с партнёрами ITFB Group.

Для кого вебинар:

• ИТ-директора и руководители цифровой трансформации.

• CEO, коммерческие и исполнительные директора.

• Директора по продажам, клиентскому сервису и маркетингу.

• ИТ-эксперты и интеграторы.

Узнайте, как RPA помогает бизнесу уже сегодня, и какие возможности откроются завтра. Регистрируйтесь сейчас!

➡️ Зарегистрироваться

Карьера и жизнь техлида: новый выпуск подкаста «Работник месяца»

Гостем нового выпуска популярного подкаста «Работник месяца» стал Юрий Молодюков, техлид Mailion — корпоративной почтовой системы от компании МойОфис. 

Что обсудили:
— рабочий день техлида,
— горизонтальное vs вертикальное развитие: что выбрать,
— сложности руководства командой,
— опыт работы в Германии и возвращения,
— почему Юрий выбрал МойОфис, и как у нас устроена инженерная культура,
— как развиваться самому и развивать продукт.

Хотите стать техлидом или просто узнать, что значит вести команду? В этом выпуске — кейсы и честные истории про задачи и людей.

Слушать выпуск
Смотреть видео-версию 

Декоратор, Фасад и их основные преимущества

В новом эпизоде отрытого курса «Паттерны и практики написания кода» вместе с бэкенд-инженером Авито Юрой Афанасьевым продолжаем тему Структурных Паттернов. Разберём два новых подхода — Декоратор и Фасад, поговорим про UML-диаграммы паттернов и их реализацию в коде, а также рассмотрим основные преимущества подходов.

Смотреть VK
Смотреть YouTube

Подписывайтесь на канал AvitoTech в Telegram, там мы рассказываем больше о профессиональном опыте наших инженеров, проектах и работе в Авито, а также анонсируем митапы и статьи.

🔥 Agile умирает - и его убийца уже здесь. Имя ему - искусственный интеллект!
Заметили ли вы что многие Agile визионеры активно перетекают в сторону AI-консалтинга?

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

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

Может, Agile - это как Nokia в мире проектного менеджмента? Собственно у Nokia был замечательный Agile

Теперь думаю: это трагедия или естественный отбор? Agile ещё жив или уже пора хоронить?

Data-класс вашей ошибки: как относиться к ошибкам как программист

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

Чтобы убрать эмоции из анализа ошибки и подойти к ней с «трезвой» головой, можно разложить ее как код. Вот, например, какой data-класс можно выделить у ошибки:

class Error {
  // что нужно было сделать
  var task
  // что пошло не так
  var errorDetails
  //какие возможные последствия уже есть или последуют и кто может пострадать
  var effect
  //причины ошибки
  var reasons
  //плюшки от решения сложившейся ситуации
  var benefits
  //выводы
  var experience
 //список улучшений, которые можно сделать, чтобы минимизировать повторение ошибки
  var actionItems
 }

А теперь — реализация.

Пример: Вы неверно оценили сроки выполнения целого скоупа задач, входящих в MVP для приложения Сообщения — ошиблись на целых два релиза. Никто не пострадал, но ситуация по многим аспектам неприятная.

Как бы выглядела реализация интерфейса для данного случая:

class BadEstimationForMVPMessaging {
  
  var task = эстимация MVP для приложения Сообщения. Необходимо оценить все задачи, распределить по спринтам и релизам, учесть загрузку команды и выдать предполагаемую дату релиза
  
  var errorDetails = ошибка в эстимации на два релиза (два месяца разработки команды из трех человек)
  
  var  effects = listOf(
  - релиз переносился два раза
  - демотивация команды
  - вопросы с продуктовой стороны
  )
  
  var reasons = listOf(
  - часть задач были сильно недооценены
  - не учтены зависимости, которые, конечно, вылезли только в конце
  - не заложен запас по времени
  )
  
  var  benefits = listOf(
  - хороший пример, который можно разобрать
  - прокачан навык работы с ожиданиями
  - ощутили дух стартапа с командой, решая внезапные блокеры перед релизом, и радовались запуску приложения
  )

  var experience = listOf( 
  - детальнее искать зависимости на этапе подготовки к эстимации
  - закладывать запас по времени в 2-3 релиза
  - на задачи с неизвестными апишками и стеком увеличивать коэффициент Пи*
  )
  
  var actionItems = listOf(
  - составить чек-лист для подготовки к запуску новых приложений, на который можно ориентироваться всем командам
  - обсудить с командой процесс выявления зависимостей
  )
 
}

Смотреть на ошибки так гораздо эффективнее. Вы выносите из них уроки, а не просто посыпаете голову пеплом. Попробуйте!

А больше лайфхаков по построению здоровой культуры ошибок в жизни и на работе читайте в подробной статье от Марии Киселевой, тимлида команды разработки мобильных приложений для KvadraOS в YADRO → 

Задачи Структурных Паттернов: Адаптер и Компоновщик — в чём суть?

В пятой серии открытого курса «Паттерны и практики написания кода» мы начинаем новую объёмную тему — изучение Структурных Паттернов. Она состоит из семи подходов. В эпизоде вместе с бэкенд-инженером Юрой Афанасьевым погрузимся в особенности работы Адаптера и Компоновщика.

Смотреть VK
Смотреть YouTube

Подписывайтесь на канал AvitoTech в Telegram, там мы рассказываем больше о профессиональном опыте наших инженеров, проектах и работе в Авито, а также анонсируем митапы и статьи.

Порождающие паттерны Prototype и Singleton: а минусы будут?

В новой серии открытого курса «Паттерны и практики написания кода» мы завершим изучение порождающих паттернов знакомством с двумя шаблонами — паттерном Прототип и паттерном Синглтон. Вместе с бэкенд-инженером Юрой Афанасьевым разберемся, почему паттерн Prototype — простой в реализации — используется редко, а паттерн Singleton — самый критикуемый.

Смотреть VK
Смотреть YouTube

Подписывайтесь на канал AvitoTech в Telegram, там мы рассказываем больше о профессиональном опыте наших инженеров, проектах и работе в Авито, а также анонсируем митапы и статьи.

Как принимать решения, даже если не хочется?

В новом выпуске подкаста «Свободный слот» обсуждаем сложные решения тимлида — те, что бьют не по метрикам, а по нервам. Чтобы разобрать эту непростую тему, ведущие Саша Прокшина и Паша Федотов встретились с Олегом Федоткиным, CTO в «Циан». Как принимать решения, когда нет правильного ответа? Уволить или дать шанс? Сохранить команду или пойти на реорганизацию? Согласиться на даунгрейд ради себя или тянуть дальше? Выделите свободный слот в своем расписании, чтобы вместе с ребятами найти ответы на все вопросы.

Смотреть VK
Смотреть YouTube

Подписывайтесь на канал AvitoTech в Telegram, там мы рассказываем больше о профессиональном опыте наших инженеров, проектах и работе в Авито, а также анонсируем митапы и статьи.

Опять попробовали React Native и снова решили, что не хотим его внедрять у себя 🧐

Олег и Денис, наши фронтенд-разработчики, рассказали, почему отказались от этого фреймворка, несмотря на то что потратили на погружение в него немало времени. Это был хороший эксперимент, который дал нам много полезных инсайтов. ✍️

Перед нашей командой стояла задача: написать код один раз, собрать под три платформы и встроить в существующие нативные и веб-приложения. Решили поэкспериментировать с React Native: до этого мы «щупали» фреймворк в 2018-м, но делали новое приложение, опыта разработки SDK у нас не было. Отправились гуглить и узнавать, как это сделать. Начали с разработки под Android, потом подключили в веб, и уже финально — iOS, в котором практически всё заработало по дефолту.

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

Вот что мы поняли при разработке:

● Обязательно нужна единая дизайн-система под все три платформы под React Native и библиотека компонентов. А ещё — команда из фронтенд и мобильных разработчиков под iOS и Android: одни будут поддерживать часть React Native, которая относится к нативной платформе, другие — писать бизнес-логику и UI.

● React Native может подойти для проектов, которые начинаешь с нуля и нужно охватить мобильные платформы и веб сразу.

Результаты нашего эксперимента

Хоть и ушло на работу с React Native несколько кварталов, мы решили не внедрять его. Было ли нам обидно? Нет, потому что благодаря эксперименту мы:

✔ Закрепили опыт, что фронтенд-разработчики могут писать на React Native.

✔ Поняли, как всё работает изнутри, какие у фреймворка плюсы и минусы.

Будет ли применимо для нас в будущем — время покажет. Возможно, для новых продуктов это рабочая схема, сейчас — экономически неоправданно.

Куда смотреть и как интерпретировать увиденное

В малом и микро бизнесе встречаются два вида контроля. Они в каком-то смысле противоположны друг другу по цели и методам осуществления.

В первом случае предприниматель чувствует облегчение, что кто-то занимается отделом продаж и старается не вдаваться в подробности. Во втором контроль — это способ справиться с тревожностью. Спросил, и вроде отлегло.

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

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

Управленческое воздействие сильно зависит от того как интерпретировать данные. А те, в свою очередь, зависят от того куда мы смотрели.

Костя Дубровин. Канал, книга.

Как стать детективом в Авито?

Модерация объявлений, коммуникация внутри сервиса, меры безопасности — рассказываем о SafeCom в новом выпуске «AviTalk». На этот раз экспертизой делится Антон Тупиков, технический лидер дирекции SafeСom Авито. Вместе с ведущей Стасей Кошман говорим о найме в SafeCom, интересных кейсах из работы сервиса и способах стать детективом внутри Авито. Антон также поделится историей собственной карьеры: от первых проектов до перехода в Авито.

Чтобы ничего не пропустить, включайте видео и делитесь мнением в комментариях.

Смотреть VK
Смотреть YouTube

Подписывайтесь на канал AvitoTech в Telegram, там мы рассказываем больше о профессиональном опыте наших инженеров, проектах и работе в Авито, а также анонсируем митапы и статьи.

В репозитории Tencent Cloud SDK for Go на GitHub содержится более 200 000 тегов Git. Это так много, что попытка взаимодействия с тегами в этом репозитории может фактически привести к сбоям в работе GitHub (504 Gateway Time-out. The server didn't respond in time).

BI-проекты: 5 причин, почему они выходят за рамки бюджета (и как этого избежать)

Если вы хоть раз участвовали во внедрении BI-системы — знаете, как легко проект может уйти не туда:
– бюджет трещит по швам,
– сроки съедены интеграцией и доработками,
– пользователи по-прежнему делают аналитику в Excel.

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

Плюс: даём самодиагностический чек-лист и PDF-гайд, где перечислены все организационные, финансовые и технические риски BI-проектов.

Заходите почитать! Статья здесь → Скрытая стоимость BI: что не учитывают 8 из 10 компаний при внедрении аналитических систем.

Открытый проект редактора Neovim имеет уже более 100 ИИ-плагинов сейчас. Их список привёл разработчик решение Colin Kennedy. Некоторые из плагинов в списке находятся в разработке или могут быть не полностью ориентированы на редактор Neovim.

В прошлом году усиленно начал пользоваться AI (LLM) тулами и словил жуткую волну грусти-печали после 5-6 месяцев использования. Для меня самым сложным стало не то, что код в целом может писать LLM, а осознание того, то в общем-то это и не так важно. Гораздо важнее появился абстрактный вопрос зачем его вообще писать если завтра всё может поменяться настолько быстро что глазом не моргнешь.

Погрустив и поболев буквально и походив по книжным магазинам наткнулся на интересную книгу - The Art of Excellent Products: Enchanting Customers with Premium Brand Experiences by Riccardo Illy. И эта книга попала настолько, что понял как разрешить (на текущий момент), моральную дилемму с AI кодом, когда ты сам не пишешь код, а его пишет AI - через этические принципы.

На мой взгляд этические принципы дают три возможности:

1. Ограничения или фокус - зафиксировав принципы, можно фокусироваться только на том, что действительно важно и отбрасывать / deprioritize то, что не согласуется с этими принципами.

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

3. Доверие - имея ограничения в виде выбранных этических принципов, ценности продукта / компании могут стать более устойчивыми к кризисам - что в итоге может дать больше доверия продукту для конечного пользователя. В теории:)

Поэтому с начала года я начал думать над принципами / ценностями / values и пытаться понять, какие подходят - и почему.

Для себя выделил три группы (пока что):
- Приложения, игры и персональные принципы.

Например для приложений пока пришел к такому списку:

• Удобство

• Простота

• Безопасность

• Долговечность

• Полезность

Для игр (так как это хобби, немного другие принципы):

• Полезность

• Творчество

• Развлечение

• Вызов

На текущий момент (май), 5 месяц тестирования - и могу честно сказать что стало гораздо проще фокусироваться на проблеме и решении чем раньше. Уверен что с развитием AI многое ещё изменится - но как будто это может стать мостиком для работы с ним с морально - этической стороны (особенно когда нужно торговаться / выбирать между быстрее - качественнее).

Ещё завел телеграм канал - https://t.me/devethics, в который стал собирать ценности / принципы которые внезапно стал открывать у других людей и компаний (продуктовых, электронных) и т.д.. Пока назвал этика разработчика:)

Надеюсь что пост чем нибудь вдохновит и окажется полезным :-)

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

Спасибо за ваше время и хорошего дня!

Антон

p.s.: надеюсь теги проставил правильно:)

Объявлено решении включить в состав выпуска GNOME 49 видеопроигрыватель Showtime, который станет поставляться под именем GNOME Video Player и будет задействован по умолчанию вместо видеопроигрывателя Totem (GNOME Videos).

Для желающих протестировать Showtime не дожидаясь осеннего релиза GNOME 49 подготовлен пакет в формате flatpak. Программа отличается минималистичным интерфейсом, отображаемым поверх содержимого и скрываемым во время просмотра. Поддерживаются типовые элементы управления, полноэкранный режим, изменение скорости воспроизведения, показ субтитров и создание скриншотов.

ГОСТ Р 56939-2024 – Разработка безопасного программного обеспечения (РБПО)

20 декабря 2024 года введён ГОСТ Р 56939-2024 взамен ГОСТ Р 56939—2016. Хотя уже прошло около полугода, не все про это знают, осознают это или как-то подстраиваются под произошедшие изменения :) А изменения есть, так как новый ГОСТ ориентирован на построение и контроль процессов, обеспечивающих цикл безопасной разработки в компании.

Несколько информационных моментов.

1. Цикл публикаций в моём канале "Бестиарий программирования" на тему РБПО

Я начинаю большой цикл публикаций в Telegram, посвящённый РБПО и ГОСТ Р 56939-2024. Приглашаю подписываться всех, кто хочет постепенно знакомиться с этой темой и разбираться в ней.

2. Вебинары РБПО-направленности

Мы уже провели совместно с другими компаниями два вебинара, связанных с ГОСТ Р 56939-2024:

1. Интеграция статического анализа и DevSecOps: PVS-Studio и AppSec.Hub в действии.

2. Внедрение процессов безопасной разработки. Интеграция PVS-Studio и SGRC SECURITM.

Приглашаем принять участие в следующем совместном с "ИНСЕК" вебинаре "Регулярный статический анализ по ГОСТу" (21 мая 12:00 по Москве), где они презентуют InSeq RBPO.

Приглашаем и другие компании к технологическому и/или информационному сотрудничеству. Напишите нам в поддержку или моему ассистенту.

3. Сертификация ФСТЭК

В последнее время нас спрашивают, подходит ли PVS-Studio для сертификации, и есть ли у нас сертификат ФСТЭК?

Для PVS-Studio нет сертификата ФСТЭК, так как он не нужен (для статических анализаторов процедура сертификации является добровольной).

PVS-Studio может использоваться как инструментальное средство статического анализа кода при построении процессов РБПО по ГОСТ Р 56939-2024.

PVS-Studio успешно применяется испытательными лабораториями, аккредитованными в системах сертификации средств защиты информации ФСТЭК России в рамках работ по сертификационным испытаниям программных продуктов, так как соответствует необходимым критериям (для заказчиков и сертификационных лабораторий мы подготовили информационное письмо):

• PVS-Studio включён в Реестр российского ПО (запись № 9837 от 18.03.2021);

• PVS-Studio удовлетворяет функциональным требованиям к инструментам статического анализа кода, описанным в Методическом документе "Методика выявления уязвимостей и недекларированных возможностей в программном обеспечении" (издание второе, доработанное, утверждён ФСТЭК России 25 декабря 2020 г.);

• продукт разрабатывается с учётом требований, предъявляемых к статическим анализаторам в ГОСТ Р 71207–2024.

Подробнее: Сертификация ФСТЭК. Если у вас есть вопросы, напишите нам в поддержку или позвоните по телефону +7(903)844-02-22.

Работа каждого руководителя начинается с PDCA (Plan–Do–Check–Act)⁠⁠

Работала в одном из моих самых первых стартапов командиром админов девочка-админ из Питера. Говорят, в Питере даже у хулиганов два высших образования — вот и она была чёткая, как питерский пацан и резкая, как клинок в питерской подворотне! Её отец (тоже питерский админ) учил так, — пока чёткий план не составишь, руки на клавиатуру не кладёшь!

Хорошее правило, да и вообще стандартный управленческий цикл состоит из 4х элементов: планирование, работа, контроль и развитие. Никакую компоненту выкинуть не получится. Если оставить только планирование и развитие без контроля за результатом, — получается ерунда. Именно так всё тогда и случилось.

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

Беда была в том, что планировать она умела, а вот выполнять получалось не очень. Точнее как... Так получилось, что исполнителем был как раз её отец, но он не исполнял. А она не могла его проконтролировать должным образом. В результате из всего управленческого цикла было только планирование.

Зато бабло на развитие команда админов просила регулярно, — чтобы влить, например, в оборудование. Я однажды отказал в финансировании на обновление серверов — решение оказалось ошибочным: сервис перешёл в режим ReadOnly на несколько суток, пока срочно не докупили новых серверов. Без прозрачности и системного контроля принятие каких бы то ни было решений превращается в рулетку (русскую) — и почти всегда стреляют в бизнес. Этот случай я до сих пор использую как пример рисков при отсутствии контроля в управленческом цикле.

Руководителю лучше заранее решить, за что браться самому, а что делегировать для обеспечения полноты управленческой цепочки. Ну или надеется на "авось", а потом расхлебывать. В нашем случае девочка планировала, её отец брался за работу и развитие. Но цепочка была неполной как раз из-за отсутствия контроля — никто по-настоящему не отвечал за результат. Вот и получили то, что получили.

Какой вывод можно сделать? Любая перекошенная конфигурация PDCA почти всегда чинится — главное, вовремя откалибровать баланс между вовлечённостью руководителя и делегированием. А вот если без балансировки просто потерять какой-то элемент из цепочки, то последствия неизбежны.

Есть 1000 и 1 способ организовать продуктовую команду, и каждый со своими преимуществами и недостатками. Как тут выбрать и не ошибиться? (*ﾉωﾉ)

Наш CPO Саша Бондаренко собрал и описал более 12 моделей команд. У каждой указал, какому типу компаний она подойдет, а также дал инструкцию по подбору «той самой». Получился большой материал, который мы разбили на несколько частей. 

> 6 моделей продуктовых команд с разбором преимуществ и недостатков каждой.
> И еще 6 моделей на примере Spotify и других крупных игроков.
> Как формируют продуктовые команды Apple, Amazon, Google и другие лидеры рынка.
> Гайд по выбору лучшей модели для своей команды и обзор ошибок, мешающих развитию компании.

Самое время прочитать или закинуть себе в сохраненки на будущее!

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

С конца 2022 года многие IT-компании во всём миру уволили примерно 635 тысяч сотрудников.

Эксперты винят в этой ситуации спад выручки, закрытие проектов, а также автоматизацию и внедрение нейросетей, которые снимают ощутимую часть работы. Специалисты говорят, что такие события будут прогрессировать по мере совершенствования ИИ. Под угрозой оказались даже сеньоры с 15-летним опытом и специалисты Microsoft, Google, Tesla, eBay и PayPal.