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

Одним из гостей подкаста Doubletapp «Что-то на программистском» стал бывший топ-менеджер Яндекса и нынешний IT-предприниматель Григорий Бакунов (aka Bobuk). В разговоре с ведущим, CEO Doubletapp Сергеем Анчутиным( (ТГ-канал: t.me/serega_ceo), он рассказал, почему против работы фултайм и аутсорса, чем IT-компании вредят российскому образованию, куда по карьерной лестнице могут продвинуться разработчики и почему чаще всего им это не интересно.

Вы все еще разрабатываете и тестируете в общем окружении, пересылаете в мессенджерах файлы конфигов для запуска приложения на рабочей машине, провели половину спринта в ожидании ресурсов для новой: бд, очереди, etc.? Знайте - вы не одиноки. Но бывает по-другому.

Если вы еще здесь, полагаю, что все же хочется “по-другому”. На самом деле это вовсе не значит, что сейчас плохо. Просто жизнь такая.

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

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

Лет пять назад я обнаружил для себя Чистую архитектуру Дяди Боба и на некоторое время успокоился, пока поток новых источников постепенно не начал менять мое отношение и к этой книге. Но, если вы решили для себя, что Чистая архитектура — это ваш окончательный выбор, то я точно не буду вас отговаривать, потому что, на мой взгляд, это однозначно лучше, чем, наверное, 90% того, что вам встретится на рынке.

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

Раньше мы в 3 частях [1, 2, 3] пробежались по основным идеям архитектуры систем. Поэтому, если вы ищете информацию по System Design, микросервисам и топологии команд, то вам туда. Эта же статья про архитектуру внутри кодовой базы: она посвящена концепциям программирования, влияющим на структуру приложения, поэтому описывает не только архитектурные подходы, но и иные идеи, оставляющие на дизайне свой отпечаток.

Введение: почему AI-трансформация — это не мода, а конкурентное преимущество

В последние годы бизнес всё чаще сталкивается с вызовом: искусственный интеллект перестал быть “технологией будущего” — теперь это рабочий инструмент для роста, автоматизации и удержания позиций на рынке.
Однако во многих компаниях AI внедряется точечно и хаотично: разные команды пилят своих агентов, чат-ботов и интеграции, зачастую не зная о работе друг друга.
Результат — раздутые бюджеты, дублирование решений, высокий технический долг и замедление инноваций.

Почему так происходит, к чему это приводит и как навести порядок?
В этой статье — практический опыт и структурированный подход: как системно трансформировать компанию под AI, сделать бизнес AI-friendly и экономить ресурсы.

Или как культура страха убивает продукт

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

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

Изменения в управлении часто ассоциируются с громкими заявлениями, трансформациями, реструктуризациями и, конечно, внутренним сопротивлением. У нас всё случилось иначе.

За последние несколько лет мы практически полностью перешли от принципов менеджмента 2.0 к менеджменту 3.0. Но интереснее всего то, что сотрудники этого почти не заметили — просто потому, что всё происходило естественно. Делюсь своими наблюдениями, как и почему это получилось.

Мы любим говорить: «Нужно делать 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 и как добились того, что сейчас он обслуживает тысячи пользователей и покоряет внешний рынок. Это будет история про энтузиазм, стартап внутри корпорации, импортозамещение и, конечно же, работу с пользователями. Поехали!