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

Мы любим говорить: «Нужно делать CustDev». Или: «Нужно считать Юнит-экономику». Или: «Нарисуем CJM — и станет ясно».

Проблема в том, что эти артефакты часто делаются изолированно: JTBD не связывается с User Story, Юнит-экономика существует в вакууме, Use Cases живут отдельно от гипотез, а гипотезы накапливаются и становится непонятно, почему они появились именно в таком порядке.

В результате — знания есть, но целостной картины видения продукта нет.

Когда ключевой вендор ушёл с рынка, а готовые решения перестали справляться, у нас было два пути: искать костыли или написать свою систему. Мы выбрали второе — и за 2 года создали ACRM, которая не просто заменяет SAS, но и даёт новые возможности. Рассказываю, как мы проектировали систему с нуля, на какие грабли наступили и почему теперь не зависим от вендоров.

Меня зовут Иван Курбатов, и я руковожу направлением систем взаимодействия с клиентами в компании «Столото». Наша команда отвечает за разработку и поддержку CRM-систем, которые помогают нам общаться с миллионами клиентов через СМС, email-рассылки и push-уведомления.

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

Хотите узнать, как строится CRM-система с нуля, как она работает в масштабе миллиона клиентов и почему иногда лучше писать своё, чем адаптировать чужое — добро пожаловать под кат!

Привет! На связи разработчик Максим и инженер по качеству Евгения из Т-Банка. Как-то мы задумались о переходе на TBD, чтобы избежать develop-ветки со всеми вытекающими. 

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

В этой статье мы поделимся опытом перехода на TBD: планом внедрения и вопросами, с которыми мы столкнулись.

Cтатья пригодится инженерам уровня middle и ниже и тимлидам. Для senior-инженеров статья не будет откровением, но надеемся, что станет местом для обсуждения нюансов внедрения или возможностью посмотреть на процесс с точки зрения QA. 

Погнали!

Появление новых требований в разгар проекта — настоящая головная боль для любого проектного менеджера. Они возникают внезапно, как метеорит в SimCity, и угрожают разрушить сроки, бюджет и нервы команды. Неважно, кто виноват — аналитик, недоглядевший нюансы, или заказчик, который понял, что надо было делать по-другому Важно, что эти «межпланетные тела» могут разрушить всё, если не знать, как с ними справляться. В этой статье мы разберём, как с помощью системы класса service desk превратить хаос изменений в управляемый процесс, сохранить при этом контроль над проектом и доверие заказчика.

Как попытки быть ближе к пользователю иногда отдаляют от цели

В одномстартапе мы решили сделать по уму — активно собирать и учитывать обратную связь.
Видим комментарий: «Сделайте поиск попроще» — переделываем.
Пишут: «Темная тема нужна обязательно!» — добавл яем.
...

Привет! Меня зовут Сергей Киселев, я Head of Development Platform в MWS Cloud Platform. В 2023 году я пришёл собирать команду Development Platform (DevP) для разработчиков нового облака. Эта статья написана по следам моего доклада «Как с нуля построить Development Platform в отдельно взятой компании» на DevOops 2024. Далее расскажу о том, почему мы заботимся об общем коде, растим культуру разработки и почему только разработчик может сделать инфраструктуру для другого разработчика.

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

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

Почему это важно? Незаметные на первый взгляд проблемы могут привести к задержкам, ухудшению качества и финансовым потерям. Мы систематизируем свой опыт, анализируем прошлые ошибки и заранее готовимся к возможным сложностям — чтобы релизы проходили гладко и без сюрпризов. Хотите узнать, как мы это делаем? Тогда поехали!

Всем привет! Меня зовут Макаров Иван, я руководитель программы Tech for Tech проектов в Magnit Tech. Последние 1,5 года мы реализуем масштабный технологический проект по выносу наиболее критичных информационных систем из единой платформы-монолита на выделенную инфраструктуру. Проект интересен своим масштабом и сложностью, и сегодня я расскажу, как мы справились с высоким уровнем неопределенности, скрытыми зависимостями, требованиями бизнеса и другими трудностями.

Сразу предупрежу: будет практика и честные выводы. И я был бы безгранично рад, если бы перед стартом проекта нашел и прочитал подобную статью.

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

Мы в редакции журнала «Конверт» (экс блог Unisender) собрали подборку подкастов, которые помогут прокачать управленческие навыки и подскажут, как перестать «чинить баги» в рабочих процессах и начать строить сильную команду.

Число проектов внедрения и непрерывного развития корпоративных информационных систем достаточно велико, и текущая геополитическая обстановка не является помехой. Наоборот, специальная операция в братской Украине требует более пристального и досконального прорабатывания вопроса импортозамещения программного обеспечения, в особенности классов ERP1–3. В этом нет ничего удивительного, ведь применение автоматизированных программных продуктов позволяет предприятиям обрабатывать большие массивы данных, формировать необходимую для принятия управленческих решений аналитику, а также заменять ручной труд над рутинными операциями на автоматизированную обработку.

Внедрения ERP‑систем практически всегда рассматриваются как высокорискованные проекты. Основная причина здесь в больших временных и человеческих затратах: обычно проект имплементации длится около 1-го года, трудозатраты внедрения только на стороне подрядчика рассчитываются от 1000 человеко‑дней. Грамотное и своевременное планирование и исполнение задач в подобных условиях является залогом успеха. Имплементация ERP‑систем преимущественно ведется по каскадной однопроходной модели внедрения [1], где часто используются принципы Agile [2]. Руководство же проектом обычно базируется на PMBoK [3]. Однако и этого бывает недостаточно, так в литературных источниках описывают типовые причины провала проектов имплементации корпоративных систем [4].

Любопытна одна из указанных причин провала внедрения: отсутствие должной поддержки проекта со стороны руководства заказчика. Несмотря на кажущуюся противоречивость и банальность, это действительно так. Лишь мизерный процент ERP‑проектов не запускается по прочим причинам, ведь когда руководство заинтересовано в результатах, любые сложности будут решены и для них будет найден обходной путь решения. В рамках данной статьи мы проведем оценку качества как самого процесса внедрения, так и уже внедренной ERP‑системы, что поможет выявить наиболее важные моменты реализации проекта.

Привет! Меня зовут Герман Лышков, я руковожу проектами в диджитал-продакшене Далее. Если вам когда-то приходилось оценивать разработку сферического коня в вакууме, это статья для вас. Я расскажу, как это сделать и дам пару советов из личного опыта. 

Я лид команды – и хочу идти дальше вверх! Точнее, не уверен, что хочу, но в айтишке надо ведь расти и развиваться, значит, следующая позиция для меня — менеджмент на уровень выше. Или нет?

Как пробиться на новый уровень, если компания нанимает на руководящие позиции извне? На чём фокусироваться? Как перестать скучать по разработке? А может, к ней надо вернуться?

Знакомы такие рассуждения? Тогда эта статья для вас:)

Меня зовут Максим Шульга, я руководитель департамента разработки Документы Онлайн в МойОфис. Наша команда работает с современными стеками: высоконагруженные бэкенды на Java и Python, фронтенд на React и TypeScript и другие.

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

Привет, Хабр! Я Павел Шестаков, Product Owner BI в MWS. За последние годы цифровой трансформации в нашей компании многие команды прошли путь от хаоса и пересылаемых друг другу «экселек» до удобных выстроенных процессов. И инструменты BI (Business Intelligence) сыграли в этом не последнюю роль.

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

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

Меня зовут Денис Макрушин, и вместе с Андреем Кулешовым @akuleshov7и Алексеем Тройниковым @atroynikov в этом году мы сделали POC платформы для безопасной разработки в рамках команды SourceCraft. Сегодня поговорим о функциональности поиска секретов. Наша appsec‑платформа состоит из двух групп инструментов: анализаторы, которые требуют точной настройки, и слой управления, который отвечает за обработку результатов и интеграцию с инфраструктурой.

В этом материале пройдём стадию discovery для анализатора секретов: посмотрим на актуальные инструменты поиска секретов, их ограничения и определим направления для повышения трёх ключевых параметров Secret Sсanning: точность, полнота и скорость.

Что общего у атомной станции, ледокола и промышленной IoT‑системы? Все они — часть критической информационной инфраструктуры (КИИ), где сбой может обернуться серьёзными последствиями.

О том, что из себя представляет КИИ, почему она так важна, чему учат будущих специалистов и как устроена работа на практике, рассказывает эксперт из Росатома — руководитель Дирекции «Цифровая Арктика» АО «Гринатом» и ведущий инженер‑исследователь научного центра «Сириус».

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

На сегодняшний день существует множество методологий разработки ПО: SDLC, Agile, Scrum и подобные. Но ни одна из них в чистом виде не подходит к процессу разработки физических устройств, предназначенных для массового производства.

Самые значимые различия (как, впрочем, и сходства) в подходах и методологиях мы рассмотрим через погружение в цикл разработки продуктов потребительской электроники. Разберём, какие именно задачи лежат на инженерах аппаратной разработки, какими знаниями необходимо обладать и почему цена ошибки так велика. А в качестве примера возьмём знакомое и понятное всем устройство: умную колонку с AI‑ассистентом.

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

Привет, Хабр! На связи Артём Камыш, руководитель платформенной команды VK Cloud. Сегодня расскажу о том, как мы сделали систему, которая помогла:

• уменьшить количество инцидентов;
• сократить время их устранения;
• ускорить постинцидентный анализ;
• стандартизировать процессы разработки для 120+ проектов.

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

- А давайте добавим ещё фильтр…
- Хорошо бы выгрузку в Excel
- Вот бы ещё график и пуши — красиво же будет!

Проект набирает скорость. Только вот в каком направлении?

Согласно своду по управлению знаниями PMBoK существует 4-е ключевые плана, характеризующие любой проект, в том числе внедрение ERP-систем: график проекта, ресурсный план, план затрат и закупок. В литературе обычно описывают только построение плана-графика проекта с использованием методов критического пути и цепи, однако взаимосвязь с ресурсным планом и прочими планами обычно опускают. В работе [1] сделана попытка одновременного построения первых трех планов в виду их корреляции, способ базируется на бенчмаркинге этапов проекта и оценщике разработок. Однако вопрос оптимизации построенного ресурсного плана обсуждается лишь вскользь.

В данной работе мы выполним анализ примеров построения ресурсного плана в проектах внедрения ERP-систем, что позволит планировать человеческие ресурсы более точно и обеспечит более эффективное и качественное имплементирование программной системы. Для начала более подробно разберемся, как взаимосвязаны между собой три плана: проекта, ресурсный и затрат. Обычно план проекта ведется в разрезе задач, далее на него налагается ресурсный план, показывающий, какое число человеческих ресурсов требуется для выполнения активностей. Зная число и квалификацию ресурсов, а также их ставки, возможно рассчитать план по затратам. Таким образом все три плана связаны между собой и изменение одного из них непременно приводит к обновлению других. Наконец, построив ресурсный план, мы фактически формируем планы проекта и затрат.

Создание проектного плана может вестись согласно двум классическим способам, описанным в своде знаний PMBoK [2]: критический путь и критическая цепь. Метод критического пути предполагает декомпозицию всех проектных задач, выстраивание их логической последовательности и взаимосвязей, выставление предполагаемых продолжительностей и расчет одноименного пути. Способ не оперирует человеческими ресурсами, поэтому не всегда понятно на основе каких правил рассчитываются продолжительности задач, ведь они зависят от числа ресурсов. Следующий способ, метод критического пути, расширяет предыдущий, вводя три вида «буферов» (ресурсные, поддерживающие и проектные), для сглаживания неопределенностей и возможных задержек. Здесь сроки задач и наличие буферов устанавливаются согласно доступности человеческих ресурсов, после чего строится все тот же критический путь. Применение обоих методов на практике видится крайне трудозатратным в особенности при часто изменяющихся вводных. Поэтому в качестве базиса построения ресурсного плана воспользуемся методом, основанном на бенчмаркинге фаз ERP-проекта [3].