Нагрузка на базы данных растет с каждым днем. Как быстро масштабировать ресурсы, расширять базы данных и следить за их состоянием в UI, не вникая в подкапотные движения Kubernetes? Приводим кейсы.
Последние годы в управлении проектами активно распространилась идеология Agile. Многие работодатели указывают знание Agile как обязательное требование к кандидату. Появились целые школы, которые обучают Agile, выдают сертификаты и т.п. Я считаю, что эти люди( и работодатели, я уж не говорю про HR) просто не имеют опыта управления, а Agile - модное слово, наверно что-то продвинутое, современное. В общем я знаю, как образовалась Agile, с точки зрения программиста она достаточно привлекательна. Но распространять идеологию Agile на все проекты в ИТ - мягко выражаясь некорректно. Предлагаю вашему вниманию другую идеологию управления проектами и продажами.
Переход к удалённому режиму взаимодействия, с использованием видеоконференций, таких как Zoom, при всех открывающихся революционных возможностях, не обходится «бесплатно» для энергетического ресурса их участников. Встреча, проведённая онлайн, расходует больше энергии, нежели такая же встреча, в том же составе, но проведённая очно. Онлайн-общение в буквальном смысле «греет» расположенный в голове процессор.
Поначалу для меня это было только гипотезой, не дающей покоя. В какой-то момент я нашёл время чтобы разобраться в том, является ли такое наблюдение субъективным. Не является. Существует даже устойчивый термин: «Zoom Fatigue» (усталость от Зума).
Ты приходишь в новую компанию или проект и видишь большую команду — человек на 30–35 — и думаешь: «Сейчас поработаем, блээээт!» Такие большие, столько опыта и компетенций. Мы обязательно сделаем крутой продукт.
Проходит время, и ты понимаешь: что-то работает не так. Команда начинает расти ещё больше, а результата или положительной динамики как таковой нет. Ничего не оцифровано, только ФОТ — и он растёт (классика жанра).
И ты начинаешь это сравнивать с раковой опухолью: почему так получается и что с этим делать?
Личные наблюдения и немного историй из жизни.
— Шеф все пропало. Аудитория отваливается. Надо ее срочно догонять. — в компании началась планерка о проблеме удержания.
Невольным свидетелем таких встреч-переговоров я был не раз и не два.
Так и хочется крикнуть:
— Господа, оглянитесь! Мы же не ковбои на диком западе, чтоб по прериям на мустангах за разбежавшимися коровами гоняться!
Давайте лучше поступим, как в том анекдоте: медленно спустимся с горы и огуляем все стадо.
Добрый день, меня зовутВладимир Павлунин, я архитектор технологической платформы в ИТ‑команде «Северстали». В компаниях часто складывается такая ситуация, что каждая команда управляет проектом по‑своему: пишут код, строят системы исходя из своего опыта. В итоге — куча похожих решений, которые никак не связаны друг с другом. Происходит увеличении энтропии, сложно понять, что где сделано, еще сложнее это связать между собой. То, что можно было сделать один раз и потом переиспользовать в других проектах, делается каждый раз с нуля во всех проектах, и по‑разному.
Год назад наша компания столкнулась с проблемой, знакомой многим крупным организациям. Разные команды, работая над похожими сервисами, каждый раз решали одни и те же задачи: настраивали CI/CD, поднимали окружения, интегрировали мониторинг и управляли зависимостями. В результате мы получили дублирование усилий, фрагментированность подходов и значительное замедление стартовой фазы проектов.
Платформа, как и правила дорожного движения, нужна для создания единого стандарта, который обеспечивает порядок, безопасность и удобство взаимодействия всех участников. Без неё возникает хаос: каждый действует по своим правилам, что приводит к конфликтам, рискам и неэффективности. Например, когда на дорогах появились ГИБДД, водители стали соблюдать правила только в присутствии инспекторов, а при их отсутствии часто позволяли себе нарушения. С внедрением автоматизации, таких как камеры контроля скорости и светофоры с датчиками, соблюдение правил стало постоянным, так как система работает всегда и везде, а не только «при виде инспектора». Это показывает, что платформа упрощает взаимодействие, делает его предсказуемым и позволяет легко адаптироваться к новым условиям, сохраняя баланс между старыми и новыми участниками системы.
Когда речь заходит о налоге на добавленную стоимость (НДС), концепция кажется элементарной, но на деле процесс может быть весьма запутанным и сложным. И тут возникает тот самый "налог на дизайн".
Однажды в разгар рабочего дня я прикрыл глаза — и буквально за секунду провалился в сон. Просто отключился. Через минут 15 проснулся свежий, бодрый, и сразу пошел работать дальше. С тех пор я начал практиковать короткий сон. И это стало одним из трех моих секретов продуктивного дня.
В работе продакт-менеджера важную роль играет Product Discovery — процесс, в котором мы формируем понимание пользовательских потребностей, проверяем гипотезы и находим точки роста для продукта. Один из нестандартных способов углубить это понимание — выйти за пределы привычного рынка и погрузиться в другую среду.
В этом посте расскажем, как мы искали вдохновение и свежие идеи для 2ГИС в Китае. Мы съездили туда командой продактов и дизайнеров транспорта: изучили местные навигационные приложения, культуру и протестировали транспортные сценарии в их естественной среде обитания.
Вмире стартапов назревает сдвиг: классический подход Minimum Viable Product (MVP) больше не гарантирует успеха. Если раньше пользователи были готовы мириться с сырыми прототипами, которые «просто работали», то в 2025 году планка качества поднялась так высоко, что одной лишь функциональности уже недостаточно. Современные пользователи ожидают продуманный и приятный UX с первого касания — продукт должен не только работать, но и вызывать восторг. Здесь на сцену выходит концепция Minimum Lovable Product (MLP): стратегия запуска, ориентированная на создание любимого продукта с первого дня. Разберёмся, почему MVP теряет актуальность, чем отличается MLP и как компаниям адаптироваться, чтобы завоёвывать сердца пользователей в 2025 году.
Я собрал интерактивный тест из пары десятков парных текстов и предоставил аудитории угадывать где писал человек, а где нейросеть. Было ожидание, что завсегдатаи хабра и айтишники разнесут LLM в сухую. Ан нет, результат вышел отрезвляющим.
Последние 14 лет я работаю в крупных корпорациях. Так случилось, что за это время сменил много ролей, должностей и даже локаций. И на каждой позиции я в той или иной мере вовлекался, участвовал или полностью управлял проектами.
Казалось бы, логично будет рассказать о кейсах успешных запусков, побед и какие инструменты мне пригодились (об этом я, кстати, писал). Но правда заключается в том, что любой, даже самый успешный проект делал мне, как проджект-менеджеру, больно. Несмотря на весь опыт, инструментарий, сильные команды находились слабые места, в которые злобный проект бил точно, сильно и с максимально разрушительными последствиями.
В этой статье я напишу о 5 способах проекта треснуть тебе так, что будет очень сложно подняться, и попробую рассказать, как этой боли избежать. Всем тем, кто ни разу не ошибался и всегда исключительно успешен и превращает в золото все, до чего дотрагивается, — статья будет нерелевантна, так что не тратьте нервы и силы. Для остальных — смотрим, от чего бывает особенно больно.
Много о рисках проекта, стори-пойнты и почему они не работают, обзор ИСУП, пирамида Минто и FFF, приоритезация бэклога и всё интересное, что писали за последние 2 недели про управление проектами. Мы прочитали все публикации и выбрали для вас самые крутые и полезные. Читайте, сохраняйте и применяйте!
Привет! Я Андрей Дудин, мне 22 года, инженер-программист в iSpring, более 4 лет в разработке, из них почти 2 года в роли играющего тимлида.
Хочу поделиться с вами своей историей становления тимлидом.
Это не просто рассказа о переходе на новую роль. Я хочу поделиться опытом с теми, кто делает первые шаги к тому, чтобы стать тимлидом.
Расскажу об ошибках и какие выводы я из них сделал, поделюсь мыслями и тем, что вообще помогло мне так быстро добраться до роли тимлида.
Что делать, если ваш руководитель не может найти для вас 5 минут?
Привет, Хабр! Меня зовут Мария Архипова, я работаю в департаменте информационных технологий РСХБ-Интех и активно занимаюсь развитием soft skills в ИТ. Иногда ИТ-специалисты сталкиваются с трудностями в коммуникации как внутри своих команд, так и с другими отделами. Я начала исследовать различные подходы к улучшению коммуникаций на примере своей команды в РСХБ и в этой статье хочу поделиться опытом.
Это всё о том, сколько чудесного и неожиданного можно узнать о потенциальном работодателе из открытых данных, и что делать, чтобы не проработать месяц-два бесплатно и не обмануться с другими ожиданиями. Спойлер: увидеть можно многое — от потенциального банкротства компании до дела о мошенничестве.
Никто из работодателей не напишет на сайте или в описании вакансии: «Ну да, так-то у нас иногда кассовые разрывы бывают, но мы тут держимся». Вместо этого будет: «Мы — признанные лидеры там-то и сям-то, нам доверяют, мы меняем мир, мы — динамично развивающаяся компания с сильным корпоративным духом (да, такие описания и кислотой не вытравить) и прочие «выше нас только горы».
Самое замечательное может начаться, если найти 10-15 минут времени и всмотреться в эту бездну успеха.
Всем привет! Меня зовут Андрей, уже несколько лет я работаю тимлидом/техлидом в разных компаниях и различных проектах. В последнее время подход Domain Driven Design у всех на слуху. Хотя этот подход развивается уже много лет (с 2003), только сейчас на него обращают активное внимание и многие команды пробуют внедрять его у себя.
В этой статье я бы хотел рассказать об ошибках, возникших в процессе внедрения DDD в проектах с моим участием, и рассказать о подводных камнях, с которыми мы столкнулись при реализации, и о которых, к сожалению, мало говорят в книгах и руководствах. Возможно, это поможет вам правильно построить процесс внедрения и развития проектов с использованием подхода DDD.
На сегодня 99% коммуникации по подписанию договоров происходит письменно. Но несмотря на то, что перед написанием комментария в договор или сообщения потенциальному заказчику можно перепроверить вложенный в текст посыл, все равно периодически возникают письменные конфликты.
Даже в ситуации, когда, казалось бы, обе стороны заинтересованы в продолжении общения и заключении договора.
(иначе зачем они вообще общаются?)
❓ Знаете, что сильнее всего мешает в переговорах по договорам?
🤪 Эмоции.
📎 Мне кажется, периодически люди слишком активно воспринимают позицию другой стороны на свой счет. И ошибка тут может прятаться в том, что по большому счету мы можем вообще не знать, какова в принципе позиция с той стороны.
Бывает, что письменная коммуникация настолько не развита, что из сообщения другой стороны считывается всё, что угодно, но только не реальное положение вещей.
То есть нам что-то написали, а мы отреагировали не взрослой реальностью, а какими-то внутренними тревожными кнопками, которые "Здравствуйте, Варфоломей!" воспринимают, как начало конфликта.
📎 Другая ошибка, на мой взгляд, кроется в том, что если другая сторона переговоров перегибает палку в своих формулировках (а такое тоже бывает), мы достаточно быстро теряем из поля зрения цель переговоров и окунаемся в алгоритм «в интернете кто‑то не прав, сейчас я ему всё докажу!».
Чем я руководствуюсь при согласовании договоров?
Обзор без маркетинга, с фокусом на то, что реально нужно менеджеру: практика, широта тем, прикладные знания, релевантность, отсутствие воды и инфоцыганщины.
Как-то раз уже делался обзор по всем существующим на рынке курсам по управлению проектами, пришло время почихвостить рынок с новой, актуальной темой.
Всем привет! Это Александр Бондаренко, CPO в Garage Eight. Моя вторая часть статьи про развитие продукта при помощи улучшений и инноваций (часть 1 здесь). Она посвящена ТОП-13 худшим инновациям. На реальных примерах показываю, как качественные прорывы в продуктах разрушают репутацию компаний.