В команде Apple вайбкодят приложения — разработчики случайно оставили файлы Claude .md в обновлении Apple Support. После того, как этот инцидент стал публичным в соцсетях, то в Apple выпустили новую версию обновления 5.13.1 без следов вайбкодинга.
1024K+
Управление проектами *
Как заставить всё работать
373,54
Рейтинг
AIRD: когда страх потерять работу токсичнее самой потери
Допустим, вас ещё не уволили. Ваш стек актуален, в Jira тикеты закрываются, митинги проходят без неловкого молчания. Но ночью вы лежите и думаете: «А вдруг следующий спринт — последний?»
Поздравляю. Возможно, у вас AIRD.
Что за аббревиатура
В начале 2026 года в Cureus Journal of Medical Science вышла работа исследователей Стефани Макнамары и Джозефа Торнтона из Университета Флориды. Они ввели термин AI Replacement Dysfunction (AIRD) — клинический конструкт для описания психологического дистресса у людей, которые боятся быть вытеснены ИИ.
Ключевой парадокс звучит как баг в продакшне: симптомы появляются до реального увольнения и без предшествующих психических расстройств. Страх сам по себе становится дисфункцией.
Симптоматика, которую вы уже видели в команде
Тревожность и бессонница — фоновый шум о профессиональном будущем, который не глушится ни кофе, ни дедлайнами
Распад профессиональной идентичности — «кто я, если мой скилл можно промптом заменить?»
Паранойя внутри команды — нежелание делиться знаниями, скрытая конкуренция там, где раньше был code review
Снижение самооценки — человек начинает сомневаться в своих архитектурных решениях не потому что они плохи, а потому что чувствует себя устаревшим
Риск злоупотреблений — хроническое напряжение ищет выход
Клинический психолог Харви Либерман (Нью-Йорк) формулирует это так: «Самое частое, что я слышу — страх стать устаревшим. Люди сомневаются в своих решениях, выборах, перспективах». И это не нытьё — это симптом.
Цифры, которые неудобно игнорировать
По данным Американской психологической ассоциации (июль 2025), 38% работников беспокоятся, что ИИ сделает их обязанности устаревшими. В том же году более 54 000 сотрудников были уволены именно из-за внедрения автоматизации.
Исследователи из Индии зафиксировали схожую картину в IT: потеря «когерентности идентичности» и «ориентации на будущее» — даже у тех, кто сохранил работу. Страх меняет поведение раньше, чем меняется реальность.
Почему это системная проблема, а не личная слабость
Торнтон называет происходящее «невидимой катастрофой». Корпоративные медиа, LinkedIn и деловые издания ежедневно транслируют сигнал тревоги — и мозг, обученный на выживание, реагирует на него как на реальную угрозу, даже если угроза пока статистическая.
Это не слабость конкретного разработчика или менеджера. Это системный ответ на системный стрессор.
Что предлагают исследователи
Авторы работы предлагают не только диагностику, но и терапевтические подходы:
Мотивационное интервьюирование — работа с внутренней амбивалентностью и сопротивлением переменам
Нарративная терапия — переосмысление профессиональной истории: не «я Java-разработчик», а «я человек, умеющий решать такие-то задачи»
Реструктуризация идентичности — строить «Я» вокруг навыков и ценностей, а не должности в оргчарте
Адаптационные практики — снижение когнитивной нагрузки от неопределённости
Клиницистам рекомендуют выходить за рамки кабинета и формировать ответы на уровне организаций — менять среду, а не только лечить симптомы.
Почему это должно волновать тех, кто управляет командами
AIRD снижает продуктивность, разрушает психологическую безопасность в командах и повышает текучку задолго до того, как ИИ реально займёт хоть одну позицию. Компании, игнорирующие психологическую сторону автоматизации, платят дважды: сначала за внедрение технологий, потом за потерю людей, которые не выдержали неопределённости.
Невидимый технический долг бывает не только в коде.
AI-дирижёр: почему оркестратор ценнее промптера
Два года назад на конференциях гордо представлялись: «Я промпт-инженер». Звучало свежо и дорого. Сегодня это примерно как писать в резюме «уверенный пользователь Google». Навык нужный — но не дифференцирующий.
Дело не в том, что промпты устарели. Изменилась единица работы с ИИ.
Что реально произошло
Раньше типичный сценарий: открыл ChatGPT → ввёл запрос → получил текст → поправил руками → пошёл дальше. Один инструмент, одна итерация, один человек в петле управления.
Сегодня производственные пайплайны выглядят иначе:
Агент-планировщик разбивает цель на подзадачи и строит граф выполнения
Специализированные агенты выполняют каждую задачу параллельно или последовательно
RAG-слой подтягивает релевантный контекст из векторного хранилища
Валидатор проверяет выход на соответствие контракту
Оркестратор управляет всем этим — как дирижёр, а не как музыкант
В чём принципиальная разница
Промпт-инженер владеет языком — умеет правильно формулировать задачу для одной модели. Оркестратор владеет архитектурой — проектирует систему, в которой несколько моделей и инструментов работают как единый организм.
Разница хорошо видна на вопросах, которые задаёт каждый. Промпт-инженер спрашивает: «Как лучше сформулировать запрос? Какой tone of voice выбрать? Как получить нужный формат?» Оркестратор спрашивает иначе: «На какие подзадачи разбить цель? Какому агенту что делегировать? Что происходит, если один из них возвращает ошибку?»
Первый оптимизирует ввод. Второй проектирует систему.
Что нужно уметь оркестратору
Это не про знание математики нейросетей и даже не обязательно про Python. Это про системное мышление плюс несколько прикладных навыков.
1. Декомпозиция задач. Умение разбить сложную цель на атомарные подзадачи, которые можно делегировать независимым агентам без потери контекста.
2. Управление состоянием. Что хранить в памяти между вызовами, что передавать явно в контексте, а что безопасно забыть — это напрямую влияет на стоимость и надёжность системы.
3. Fallback-логика. Если агент вернул невалидный ответ или timeout — что дальше? Перезапуск, альтернативный путь, эскалация человеку? Системы без продуманного error handling ломаются в продакшене предсказуемо.
4. Выбор инструментов под задачу. Когда нужен LLM, когда — поисковый агент, а когда задачу дешевле и надёжнее решить классическим алгоритмом без ИИ вообще. Молоток-LLM не нужен для каждого гвоздя.
5. Оценка качества выхода. Не «красиво ли написано», а «решена ли задача, воспроизводим ли результат, насколько система деградирует при изменении входных данных».
Почему это важно именно сейчас
Microsoft в опросе 31 000 сотрудников из 31 страны обозначил роль «промпт-инженера» как одну из наименее перспективных для роста на горизонте 12–18 месяцев. Проектирование мультиагентных систем при этом называется ключевым навыком следующих двух-трёх лет.
Компании уже сейчас ищут не тех, кто «умеет работать с ИИ», а тех, кто умеет строить системы на базе ИИ. Это разные запросы — и разный рынок труда.
Порог входа ниже, чем кажется
Не нужно знать математику нейронных сетей. Достаточно освоить несколько паттернов: оркестратор ставит задачу → субагент её выполняет с помощью инструмента → результат идёт на валидатор → валидатор либо принимает выход, либо запускает повтор или эскалацию.
Понять, как работает memory и state в агентных системах, и попрактиковаться на реальных задачах — n8n, LangGraph или AutoGen дают это с минимальным порогом входа.
Промпт-инженерия дала нам грамотность в работе с ИИ. Оркестрация даёт проектирование. Переход между ними — это не про новый инструмент. Это про новый тип мышления.
Лог в реальном времени: берём госзаказ и закрываем его агентной разработкой
На днях Оскар Хартманн довольно жёстко высказался за вайбкодинг. Тем временем на Пикабу из 45 программистов в профессиональном сообществе вайбкодят только 9. В госсекторе — единицы.
Пока остальные спорят, костыли это или нет — я берусь за реальный тендер и публикую всё как есть.
Подписывайтесь — первый пост как только войду в торги на понижение.
Вчера проводила эксперимент с 5 нейронками об отключении мобильного интернета и об ограничении вообще интернета в стране Х. Были задействованы DeepSeek, Yandex, Kimi, Gemini и GPT. То есть, разные нейронки, обученные на разных культурных корпусах, США, Китай, Россия. Язык русский.
Так вот, все 5 нейронок согласились что интернет можно отключать только в кратковременных случаях, если есть угроза жизни. Ограничивать также можно, но если это пропорционально соответствует угрозе, что пока не доказано. Самый сок!
Во всех опросах Алиса/Яндекс рассказывала как это плохо ограничивать интернет в целях безопасности, но ставила 8/10 «ЗА». Все остальные ставили 2-3/10.
Вы понимаете парадокс? Алиса говорит, что ограничения ужасны для безопасности, образования, медиа, науки, права, экономики, медицины (особенно она отметила что нельзя ограничивать доступ к глобальной медицине), но голосовала ЗА!
Подумайте, какой приоритет встроен в итоговую оценку.А теперь главное: ИИ встраивается сейчас везде, в бизнес, в банки, в госуправление, в места, где принимаются критические решения.
Что посоветует Алиса, если она подробно описывает медленную деградацию системы, но в итоговой оценке всё равно поддерживает ограничения? Какие критические решения могут приниматься с таким "технологическим суверенитетом”?
Премия за гибридность: почему самый ценный сотрудник не технарь и не гуманитарий
Долгое время разделение было почти кастовым: одни пишут код и строят модели, другие ведут переговоры и рассказывают истории. Каждый лагерь немного презирал другой. Это было удобно, понятно и — как выясняется — безнадёжно устарело.
Генеративный ИИ сломал эту систему не потому, что «заберёт работу». Он сломал её потому, что изменил саму единицу ценности специалиста.
Что говорят данные
PwC и MIT проанализировали требования к позициям, связанным с Gen AI, и получили неудобный результат. Роли с ИИ требуют на 36,7% больше когнитивных навыков, чем аналогичные позиции без него. Но одновременно устойчиво растёт спрос на социальные компетенции: эмпатию, лидерство, суждение в условиях неопределённости.
Логика железная: машина забирает рутину, обработку данных, генерацию контента. Человеку остаётся то, с чем LLM справляется плохо — интерпретация, этика, контекст и доверие. А доверие, к слову, до сих пор не токенизируется.
π-shaped как новый стандарт найма
McKinsey и Google уже несколько лет оперируют концепцией π-shaped специалиста: два вертикальных столба глубокой экспертизы плюс горизонтальная гибкость между ними.
В контексте AI это выглядит так:
Столб 1 — техническая AI-грамотность: понимание архитектуры языковых моделей, промпт-инжиниринг, работа с API и осознание ограничений систем
Столб 2 — человеческий интеллект: эмоциональный, социальный, этический
Перекладина — способность переключаться между этими режимами в рамках одной задачи
Продакт, который понимает разницу между RAG и fine-tuning и при этом умеет провести глубинное интервью с пользователем — это уже не «редкий зверь», это просто новый минимальный стандарт для сильных команд.
Как это развивать — без воды
AI-грамотность — не обязательно писать код, но необходимо понимать, как работают языковые модели, где они галлюцинируют и как правильно декомпозировать задачу для промпта
Практика суждения — берите кросс-функциональные проекты, где нет единственно правильного ответа. Именно там тренируется то, что модель сымитировать не может
Осознанная коммуникация — это не «навык презентаций». Это умение слышать, адаптировать месседж под аудиторию и строить доверие. Прокачивается через фасилитацию и наставничество, а не через курсы ораторского мастерства
Рефлексия — те, кто регулярно разбирает собственные решения и открыт к критике, накапливают опыт, который не дистиллируется в веса модели
Почему это не очередной buzzword
Автоматизация не уничтожает рабочие места — она реструктурирует их. Исчезают позиции, где человек выполнял функцию дешёвого процессора. Появляются роли, где нужен человек с AI-усиленным интеллектом — и именно они получат премию за гибридность в зарплате, карьере и реальном влиянии на результат.
Вопрос уже не «технарь вы или гуманитарий». Вопрос в том, как быстро вы готовы перестать считать это противоречием.
23 апреля 2026 года в Гвианском космическом центре на бывшем стартовом комплексе российской ракеты-носителя «Союз-СТ» была взорвана мобильная башня обслуживания. До этого на самой пусковой установке был разрезан легендарный «тюльпан» — четыре ферменные опоры, на которых висела ракета перед стартом, и кабель-мачты.
РБПО по ГОСТ Р 56939—2024: вебинар №07 из 30 – Моделирование угроз и разработка описания поверхности атаки
Компания ООО "ПВС" совместно с учебным центром "Маском" провела цикл вебинаров, посвящённых разработке безопасного программного обеспечения (РБПО). Совместно с приглашёнными экспертами различных компаний мы рассмотрели 25 процессов, приведённых в ГОСТ Р 56939—2024.
Предлагаем сегодня вашему вниманию вебинар цикла, посвящённый процессу, описанному в разделе 5.7. – "Моделирование угроз и разработка описания поверхности атаки". На YouTube. Слайды.
Цели седьмого процесса по ГОСТ Р 56939—2024:
5.7.1.1 Создание условий для снижения количества недостатков, связанных с особенностями реализации архитектуры ПО и логики его функционирования, выработка мер по нейтрализации угроз безопасности, связанных с особенностями реализации архитектуры ПО.
5.7.1.2 Уточнение модели угроз и описания поверхности атаки по результатам разработки кода и его изменений.
Общее количество вебинаров — 30: каждому из 25 процессов ГОСТа посвящено по одному вебинару и 5 записано дополнительно на смежные темы. Запись всех вебинаров и подборка дополнительной информации доступна по ссылке: ГОСТ56939.РФ.
РБПО по ГОСТ Р 56939—2024: вебинар №06 из 30 – Разработка, уточнение и анализ архитектуры программного обеспечения
Прошёлся сегодня по использованию вайб-кодинга без соответствующих мер контроля результата – Ревью вайб-кода с гнильцой, который притворяется оптимизированным С++ кодом. А теперь продолжим тему, как создавать качественные, надёжные и безопасные приложения. Это всё, кстати, актуально и для веб-кодинга, но, к сожалению, пока мало кто это осознаёт :(
Компания ООО "ПВС" совместно с учебным центром "Маском" провела цикл вебинаров, посвящённых разработке безопасного программного обеспечения (РБПО). Совместно с приглашёнными экспертами различных компаний мы рассмотрели 25 процессов, приведённых в ГОСТ Р 56939—2024.
Предлагаем сегодня вашему вниманию вебинар цикла, посвящённый процессу, описанному в разделе 5.6. – "Разработка, уточнение и анализ архитектуры программного обеспечения". Слайды.
Цели шестого процесса по ГОСТ Р 56939—2024:
5.6.1.1 Создание условий для снижения количества возможных недостатков при разработке архитектуры ПО.
5.6.1.2 Уточнение архитектуры ПО в процессе разработки кода.
Общее количество вебинаров — 30: каждому из 25 процессов ГОСТа посвящено по одному вебинару и 5 записано дополнительно на смежные темы. Запись всех вебинаров и подборка дополнительной информации доступна по ссылке: ГОСТ56939.РФ.
Из сильного специалиста — в руководителя: 11 открытых уроков про управление, архитектуру и карьерный рост
Управленческие и околоуправленческие роли в IT давно перестали быть только про «руководить людьми». Сегодня это и делегирование, и продуктовые границы, и работа с рисками, и архитектура изменений, и умение принимать решения в условиях дефицита.
Ниже — подборка ближайших бесплатных открытых уроков для тех, кто хочет разобраться в этих задачах предметно.
① Управление командой
➡ 22 апреля, 20:00 — «Делегирование без боли: как перестать быть „главным исполнителем“ и не скатиться в микроменеджмент»
Для тех, кто уже руководит или только переходит в управление и хочет перестроить свою роль без потери контроля.
➡ 28 апреля, 20:00 — «Коучинговые инструменты для мотивации и повышения продуктивности команды»
Если хочется не просто ставить задачи, а реально влиять на вовлеченность и результат команды.
➡ 30 апреля, 20:00 — «Как управлять тимлидами?»
Урок для тех, кто уже управляет не только исполнителями, но и руководителями внутри команды.
② Карьерный рост в управление
➡ 29 апреля, 20:00 — «Разрешите себе карьеру технического директора»
Полезно тем, кто уже вырос из роли сильного технического специалиста и думает о следующем карьерном шаге.
➡ 30 апреля, 19:00 — «МОК‑интервью на позицию Руководитель Проектов»
Практический формат для тех, кто готовится к переходу в управление проектами или хочет проверить себя на интервью.
➡ 12 мая, 18:00 — «Какие метрики использует технический директор?»
Для тех, кто хочет понять, как на уровне CTO смотреть на эффективность команды, процессов и продукта.
③ Продукт, проекты и аналитика
➡ 29 апреля, 20:00 — «Продакт‑менеджер, маркетолог и PMM — в чём разница»
Хороший урок для тех, кто работает на стыке продукта, маркетинга и стратегии и хочет лучше понимать зоны ответственности.
➡ 7 мая, 20:00 — «Как бизнес‑аналитик управляет рисками при разработке IT‑продукта?»
Полезно тем, кто хочет глубже разобраться, как аналитика влияет на устойчивость и качество продуктовой разработки.
➡ 12 мая, 19:00 — «Управление ресурсами в условиях жестокого дефицита»
Актуально для тех, кто работает в условиях перегруженных команд, ограниченного бюджета и постоянных компромиссов.
④ Архитектура и изменения
➡ 30 апреля, 19:00 — «От стратегии к портфелю изменений: как архитектор связывает цели бизнеса, инициативы и архитектурные решения»
Для тех, кому важно понимать архитектуру не только как набор схем, а как инструмент управления изменениями.
➡ 14 мая, 19:00 — «Архитектор как модератор изменений: как проводить архитектурные решения через стейкхоледеров»
Для тех, кто хочет лучше понимать, как продвигать решения в сложной организационной среде, а не только проектировать их.
﹋﹋﹋﹋﹋﹋﹋﹋﹋﹋﹋﹋﹋﹋﹋﹋﹋﹋﹋﹋﹋﹋﹋﹋﹋﹋﹋﹋﹋﹋﹋﹋﹋﹋﹋﹋﹋﹋﹋﹋﹋﹋﹋﹋
Открытые уроки — хороший способ присмотреться к теме. А если хотите пойти дальше, можно посмотреть весь каталог программ по управлению в IT и выбрать подходящее направление под свои задачи.
Клиент + Продакт + Сервис = любовь QBR
Иногда кажется, что продукт, сервис и клиент живут каждый в своей реальности. Клиентский сервис отвечает на входящие запросы, продукт приходит к клиенту, когда нужно что‑то проверить, а сам клиент не всегда понимает, влияет ли он вообще на развитие продукта.
Даша, менеджер продукта в команде Скорозвон, рассказала, как они выстроили регулярное взаимодействие с клиентами и почему в таких встречах одновременно нужны продукт и клиентский сервис.
1️⃣ Что такое Quarterly Business Review (QBR)
Это встречи с клиентом, как правило, раз в квартал для оценки результатов, обсуждения достигнутых целей и планирования. На встречи приходят: клиент, персональный менеджер, руководитель сервиса и менеджер продукта.
Формат больше похож на разговор, где клиенту уделяют внимание на уровне команды, а не одного менеджера.
2️⃣ Зачем вообще появился этот формат
Он вырос из конкретных проблем.
Клиентский сервис чаще реагировал, чем инициировал диалог — клиент приходил сам, когда уже есть проблема.
Продукт общался с клиентами точечно — под конкретные задачи, без системности.
Клиенту не хватало понимания, влияет ли он вообще на продукт.
Нужен был формат, где все стороны встречаются регулярно и говорят не только о проблемах.
3️⃣ Почему не сработали Excel-таблицы
До QBR мы пробовали собирать запросы клиентов через Excel-таблицы: менеджеры фиксировали идеи, передавали продукту, но дальше все разваливалось.
Не хватало контекста + появлялись вопросы = мотивация заполнять таблицы падала.
4️⃣ Что изменилось, когда позвали клиента в диалог
Когда клиент стал частью обсуждения, появилась возможность сразу уточнять, обсуждать и принимать решения.
5️⃣ Как устроена встреча
Есть базовая структура:
разбираем текущие вопросы и контекст по клиенту;
обсуждаем, что происходит в бизнесе клиента;
синхронизируемся по метрикам эффективности;
собираем обратную связь и сложности в работе;
рассказываем про обновления и планы продукта;
фиксируем договоренности.
6️⃣ Что важно в ролях
Менеджер клиента — ведет встречу и держит контекст.
Руководитель сервиса — подключается к сложным вопросам.
Менеджер продукта — отвечает за продуктовую экспертизу.
Без полного состава встреча сильно теряет в качестве.
7️⃣ Что может пойти не так
Встреча превращается в список «хотелок»
Тут нужно вернуть разговор к структуре: сначала бизнес и контекст, потом — пожелания.
Клиенту некомфортно отвечать на вопросы про бизнес
Стоит заранее объяснить, зачем это нужно — чтобы лучше настроить продукт под задачи бизнеса.
Клиент приходит с негативом
Это нормально. Лучше обсудить проблему открыто, чем получить ее в отложенном виде.
К следующей встрече нет изменений
Возможности и планы продукта проговариваем заранее: какие задачи в приоритете, что планируется, а что нет. Если планы изменились, обязательно объясняем причины.
8️⃣ QBR работает, если
Клиентский сервис и продукт готовятся к встрече вместе.
Разговор идет про бизнес клиента, а не только про продукт.
Подключены участники со стороны клиента на разных уровнях.
Договоренности фиксируются и превращаются в конкретные действия.
Аутстаф IT-специалистов: подборка статей для разработчиков и команд
Аутстаф — распространенная модель работы для IT-подразделений, особенно когда нужно быстро масштабировать команду разработки без долгого найма. Кто-то выбирает её ради гибкости и разнообразия проектов, а кто-то — чтобы закрыть нехватку специалистов здесь и сейчас. Для разработчиков при этом аутстаф — это регулярная адаптация к новым условиям, размытые зоны ответственности и разные ожидания на проектах.
Аутстаф для Doubletapp — ежедневная практика с 2020 года. Мы работали с командами разного масштаба: от стартапов до международных корпораций.
В каждом проекте различаются ожидания, процессы и уровень зрелости, поэтому ключевая задача — не просто подключить разработчика, а встроить его в контекст. Мы берём на себя роль связующего звена: выравниваем ожидания, помогаем согласовать процессы и находим решения, которые работают и для заказчика, и для команды.
Аутстаф — это не «волшебная таблетка» для бизнеса, а инструмент, который требует системного подхода и выстроенных процессов.
Мы собрали подборку материалов, которые помогут разобраться:
— когда стоит нанимать аутстаф-разработчиков
— как выстроить с ними работу
— и с какими проблемами можно столкнуться на практике.
Руководитель бизнес-юнита аутстаф Анна Антонова разбирает, как устроен аутстаф изнутри: как компании усиливают команды разработчиков, какие процессы за этим стоят и почему аутстаф — это не просто «подключить человека», а выстроить рабочую систему.
Аутстаф в бигтехах: работал сам, готовлю других
Руководитель бэкенд-отдела Данил Миронов – о своем пути от аутстаф-разработчика в зарубежной корпорации до руководителя отдела в Doubletapp. В статье много прикладных советов о том, как быстро вливаться в международные команды, договариваться с заказчиками, если они ставят нереальные сроки, как прокачать грейд и зарплату всего за несколько месяцев.
Чем отличается работа на аутстафе в корпорации и стартапе
Хаос в процессах в первом случае и проблемы с доступами во втором – проинтервьюировали разработчиков и честно рассказываем о всех сложностях, с которыми им приходится сталкиваться в работе.
Как подготовить IT-специалистов, работающих в аутстаф-формате
Про распределение ресурсов, обучение и взаимодействие с тимлидами на стороне клиента.
Аутстаф-разработчики не ровня инхаус-сотрудникам?
Разбираемся, как сделать так, чтобы аутстаф-специалисты могли ощутимо усилить команду заказчика и привнести в нее все плюсы аутстаф-формата.
Для чего он клиентам – понятно. А какая выгода для программистов на аутстафе? Собрали ответы разработчиков Doubletapp.
Проблемы аутстаф-разработчиков
Боли и ограничения, с которыми сталкиваются аутстаф-разработчики на проектах: от проблем с доступами до размытых зон ответственности и сложной коммуникации с заказчиком.
Зачем нанимать аутстаф-специалистов?
Топ-5 причин, по которым компании выбирают аутстаф-разработчиков вместо классического найма — от ускорения time-to-hire до гибкого масштабирования команды.
Аутстаф как отдельный юнит IT-компании
Руководитель направления объясняет преимущества юнит-экономики и рассказывает, как с ее помощью нам удается иметь постоянную коммерческую загрузку для разработчиков.
В блоге Doubletapp на этой неделе выйдет статья о том, как быстро и бесшовно онбордить аутстаф-разработчика в проект. Мы собрали практические рекомендации, которые помогают:
— разработчикам быстрее адаптироваться и не терять мотивацию
— бизнесу сокращать время онбординга и снижать риски при подключении специалистов.
Подпишись, чтобы не пропустить!
Если вы планируете нанять аутстаф-разработчиков или усилить текущую команду, напишите нам — разберём задачу, подберём специалистов под стек и сроки и предложим формат подключения под ваш процесс.
Доделаю на выходных. Встану пораньше. Дам фидбек попозже — и другие истории, в которые мы верим
Мы все себе врём. Иногда — чтобы не расстраиваться, иногда — чтобы казаться лучше, иногда — просто по привычке. Но почему это происходит и можно ли с этим что-то сделать?
В новом выпуске «Свободного слота» Александра Прокшина и Саша Афёнов разбирают самые популярные типы самообмана — те, что узнал каждый, кто хоть раз открывал рабочий ноутбук в воскресенье вечером.
Что обсудили
Взяли результаты опроса, который проводили заранее, и прошлись по главным хитам: «доделаю на выходных», «справлюсь сам — зачем спрашивать», «дам обратную связь чуть попозже» и «ну это же исключение». Разобрались, куда приводит желание всегда быть классным для команды, и почему объяснять очевидное — иногда лучшее решение.
Слушайте и смотрите новый выпуск на площадках:
📺 YouTube
🔵 ВК Видео
📌 RuTube
🎧 Яндекс Музыка
Ⓜ️ Mave
Ещё больше новостей — в нашем телеграм-канале
«Свободный слот» — терапевтичный контент для тимлидов и тех, кто хочет ими стать
Ближайшие события
РБПО по ГОСТ Р 56939—2024: вебинар №04 из 30 – Управление конфигурацией программного обеспечения
Компания ООО "ПВС" совместно с учебным центром "Маском" провела цикл вебинаров, посвящённых разработке безопасного программного обеспечения (РБПО). Совместно с приглашёнными экспертами различных компаний мы рассмотрели 25 процессов, приведённых в ГОСТ Р 56939—2024.
Предлагаем сегодня вашему вниманию вебинар цикла, посвящённый процессу, описанному в разделе 5.4. – "Управление конфигурацией программного обеспечения". Слайды.
Цели четвёртого процесса по ГОСТ Р 56939—2024:
5.4.1.1 Осуществление уникальной идентификации ПО, документации на ПО, других элементов, подлежащих отслеживанию в рамках управления конфигурацией ПО (элементов конфигурации).
5.4.1.2 Контроль реализации изменений ПО, документации на ПО, других элементов, подлежащих отслеживанию в рамках управления конфигурацией ПО (элементов конфигурации).
Общее количество вебинаров — 30: каждому из 25 процессов ГОСТа посвящено по одному вебинару и 5 записано дополнительно на смежные темы. Запись всех вебинаров и подборка дополнительной информации доступна по ссылке: ГОСТ56939.РФ.
P.S. При разработке регламента идентификации ПО (версий ПО, модулей ПО) можно оттолкнуться от ГОСТ 19.103—77 "Единая система программной документации. Обозначение программ и программных документов".
РБПО по ГОСТ Р 56939—2024: вебинар №03 из 30 – Формирование и предъявление требований безопасности к программному обеспечению
Компания ООО "ПВС" совместно с учебным центром "Маском" провела цикл вебинаров, посвящённых разработке безопасного программного обеспечения (РБПО). Совместно с приглашёнными экспертами различных компаний мы рассмотрели 25 процессов, приведённых в ГОСТ Р 56939—2024.
Предлагаем сегодня вашему вниманию вебинар цикла, посвящённый процессу, описанному в разделе 5.3. – "Формирование и предъявление требований безопасности к программному обеспечению". Слайды.
Цели третьего процесса по ГОСТ Р 56939—2024 (п. 5.3.1.1):
Обеспечение безопасности ПО посредством предъявления к нему требований и управления требованиями в процессе изменения (разработки) ПО.
Общее количество вебинаров — 30: каждому из 25 процессов ГОСТа посвящено по одному вебинару и 5 записано дополнительно на смежные темы. Запись всех вебинаров и подборка дополнительной информации доступна по ссылке: ГОСТ56939.РФ.
Представлен сервис DeathByClawd, который показывает, заменит ли ИИ конкретный продукт или сервис уже сейчас. Достаточно ввести название — получаете «Death Score» от 0 до 100. Чем выше балл, тем легче нейросеть сделает то же самое.
РБПО по ГОСТ Р 56939—2024: вебинар №02 из 30 – Обучение сотрудников
Компания ООО "ПВС" совместно с учебным центром "Маском" провела цикл вебинаров, посвящённых разработке безопасного программного обеспечения (РБПО). Совместно с приглашёнными экспертами различных компаний мы рассмотрели 25 процессов, приведённых в ГОСТ Р 56939—2024.
Предлагаем вашему вниманию сегодня вебинар цикла, посвящённый процессу, описанному в разделе 5.2. – "Обучение сотрудников". Слайды.
Общее количество вебинаров — 30: каждому из 25 процессов ГОСТа посвящено по одному вебинару и 5 записано дополнительно на смежные темы. Я буду публиковать по два вебинара в неделю, чтобы было время знакомиться с ними.
Запись всех вебинаров и подборка дополнительной информации доступна по ссылке: ГОСТ56939.РФ.
Поскольку рассматриваем процесс обучения, хочется напомнить, что учебный центр "Маском" предлагает ряд курсов по тематике РБПО:
М БРПО-Спец. Специалист по процессам разработки безопасного программного обеспечения. 200 часов / 20 дней.
М БРПО-01. Внедрение процессов разработки безопасного программного обеспечения в организации (для руководителей и ответственных). 40 часов/4 дня.
М БРПО-02. Внедрение процессов разработки безопасного программного обеспечения для специалистов по информационной безопасности. 50 часов/5 дней.
М БРПО-03. Сертификационные испытания с учётом требований по разработке безопасного программного обеспечения для экспертов органов по сертификации (испытательных лабораторий) различных систем сертификации средств защиты информации. 140 часов/14 дней.
М БРПО-04. Формирование практических навыков по разработке безопасного программного обеспечения для разработчиков и программистов. 140 часов/14 дней.
М БРПО-05. Методология подготовки предприятия к сертификации процессов безопасной разработки программного обеспечения средств защиты информации в соответствии с требованиями ФСТЭК России. 30 часов/3 дня.
Вы узнаете много полезной информации из вебинаров, которые я здесь публикую. Однако есть смысл подумать и о прохождении обучающих курсов.
Вебинары – это теория. На курсах вы получите практические навыки, знакомясь с продуктами лидеров рынка РФ по РБПО.
УЦ "Маском" имеет лицензию на учебную деятельность и право давать официальный документ о повышении квалификации и прохождении профессиональной переподготовки.
Официальный документ об обучении требуется для экспертов органов/лабораторий в системах сертификации ФСТЭК России и Минобороны России.
Программа М БРПО-Спец "Специалист по процессам разработки безопасного ПО" (200 часов/20 дней) официально согласована с ФСТЭК России.
Человеческий фактор. Не все сотрудники достаточно мотивированы самостоятельно глубоко изучить тему РБПО. Курсы станут поводом выделить на это время.
P.S. В конце не могу не упомянуть про курс "ПВС СТАТ" – Статический анализ программного обеспечения в соответствии с требованиями ГОСТ Р 71207–2024 с применением PVS-Studio. 30 часов/3 дня.
Пятничный пост. Рубрика - узнай себя и что было дальше?
— Привет. В этом спринте наш главный приоритет — это обработка больших данных из файла, который загружает пользователь. Тебе предстоит сделать пошаговую форму и предварительную проверку перед отправкой, — уверенным голосом сказал Виталий — руководитель проекта.
— Бизнес очень хочет эту фичу и ждёт, — добавил он, повышая уровень ответственности и важности задачи.
— Но… перед этим есть маленькая задачка: нужно в форме группового добавления товаров в корзину показать ошибки, которые возвращает сервер.
Подключились ребята с бэка.
— Раньше у нас этого не было, мы просто падали. Сейчас для каждого отдельного запроса может быть своя ошибка. Мы обсудили это с Виталием и Викой на прошлой неделе и быстро всё сделали, — декларировали они, явно удовлетворённые результатом своей работы.
— Да… там простой процесс: пользователь нажимает кнопку, и для каждого поля уходит свой запрос. Нужно просто показать ошибки, — подтвердила Вика — аналитик.
Вдруг я ощутил, что все смотрят на меня, и даже бизнес, которого не было в комнате.
Тестировщик Николай молчал и, кажется, тянулся за попкорном.
— Я не при делах, меня на совещании не было, — читалось в его глазах.
— Не уверен… что это можно сделать быстро. Там много старого кода и логики, запросы работают параллельно, мы вообще не обрабатываем ошибки в этой форме. Просто закрываем модалку. Нужно подумать… — сделал я слабую попытку возразить.
— Ну, так… форма же уже работает. Это простое отображение ошибок. Бизнес хочет, чтобы в конце недели это было на проде. Ок…? — закончил вопросом-утверждением Виталий.
— Ок… — зачем-то ответил я. «Б…!!! Зачем я это сказал?!» — тут же промелькнуло у меня в голове, и две половинки моего тела чуть ниже спины нервно сжались в предвкушении нюансов…
Кого узнали и что было дальше?
РБПО по ГОСТ Р 56939—2024: вебинар №01 из 30 – Планирование процессов РБПО
Компания ООО "ПВС" совместно с учебным центром "Маском" провела цикл вебинаров, посвящённых разработке безопасного программного обеспечения (РБПО). Совместно с приглашёнными экспертами различных компаний мы рассмотрели 25 процессов, приведённых в ГОСТ Р 56939—2024.
Предлагаем вашему вниманию сегодня первый вебинар цикла, посвящённый первому процессу, описанному в разделе 5.1. – "Планирование процессов разработки безопасного программного обеспечения". Слайды.
Общее количество вебинаров — 30: каждому из 25 процессов ГОСТа посвящено по одному вебинару и 5 записано дополнительно на смежные темы. Я буду публиковать по два вебинара в неделю, чтобы было время знакомиться с ними.
Запись всех вебинаров и подборка дополнительной информации доступна по ссылке: ГОСТ56939.РФ.
Пришло время раскаяться
Микроменеджмент, ложь, манипуляции, лицемерие — звучит как верная дорожка в ад. Но что, если это просто будни почти любого тимлида? И что, если некоторые из этих «грехов» не так страшны, как кажутся?
В новом выпуске «Свободного слота» Паша Федотов и Александра Прокшина позвали сразу двух гостей: Артёма Коночкина, руководителя юнита Mall and sales, и Константина Лёгкого, заместителя коммерческого директора Битрикс24. Вместе разобрали все грехи тимлида — и честно примерили каждый на себя.
Что обсудили
Прошлись по всем грехам и честно примерили каждый на себя. Выяснили, когда микроменеджмент — это не слабость, а рабочий инструмент. Разобрались, чем похвала отличается от настоящей обратной связи. Поспорили про манипуляции, лицемерие и ложь — и нашли границы, в которых они допустимы. А в финале научились грехи комбинировать: в реальной жизни они редко приходят поодиночке.
Что будет дальше
Это второй выпуск сезона, в котором «Свободный слот» говорит о том, о чём тимлиды обычно молчат. Впереди — негативный фидбек, ошибки руководителей, AI и деградация компетенций. Неудобные темы, честные разговоры.
Слушайте и смотрите новый выпуск на площадках:
📺 YouTube
🔵 ВК Видео
💻 RuTube
Ещё больше экспертизы собрали для вас на сайте: смотрите наши лонгриды, новости, плейлисты видео. А узнать, как стать частью команды AvitoTech, можно вот здесь.