Хабр, привет! Я Саша, Product Manager в Ozon. Хочу сегодня поговорить с вами об исследовании зависимостей между подсистемами проекта, в частности, и повышении прозрачности процессов в разработке в общем.

Обычное дело: в команду приходит заказчик, приносит суперзадачу — киллер-фичу, которая по приблизительным оценкам будет приносить не меньше N денег в секунду. Очень важная и нужная штука. Потом проходит 3 месяца, а фича так и не появляется на проде. Более того, команда к ней так и не приступала. 

Почему? 

– вместо суперзадачи команда занимается какой-то ерундой — проблемы с приоритизацией;

– команда не поняла, что фича принесёт реальные деньги и насколько это важно — сложности с коммуникацией с заказчиком;

– недостаточно описаны требования, команда отфильтровала задачу как «не готовую к взятию в работу» — продакт не доработал;

– задача потерялась в недрах бэклога — продакт проглядел.

Все эти варианты говорят нам о наличии рассинхрона команд, ожиданий и реальности, рассинхрона подсистем относительно общего процесса, вследствие этого команда(ы) делает «не то» «не так» или не делает вовсе.

Давайте разбираться — расскажу вам об инструменте, который поможет выявлять приводящие к подобным ситуациям серые зоны, нестыковки, зависимости между подсистемами проекта; поможет всё это дело визуализировать и анализировать. Инструмент я назвала картой зависимостей.

Вероятно, вы слышали о планировщике Go раньше, но насколько хорошо мы знает о том как он работает? Как он связывает горутины с потоками?

Разберем по очереди операции, которые выполняет планировщик.

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

Привет, Хабр! Я Федор Щудло, team lead и fullstack-разработчик. Всего я в разработке 15 лет, из них 11 в роли team lead.

Три года назад я сменил работу и занялся проектом, состояние которого можно описать кратко: ему 25 лет.

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

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

Как результат, разработка шла с большими накладными расходами (все делали долго), и с высокими рисками (выкатили и разломали прод). А команда при этом работала на износ.

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

За многие годы моей карьеры я столкнулся с множеством вызовов и уникальных ситуаций, которые позволили мне глубоко погрузиться в мир гибкого управления проектами. Думаю, статья будет полезна РМ’ам всех уровней.

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

Гибкость в управлении проектами – это способность адаптироваться к меняющимся условиям и требованиям без потери эффективности. Использование правильных инструментов и техник может значительно улучшить адаптивность команд и проектов.

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

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

Я поделюсь своими впечатлениями от участия в этом формате, рассмотрю проблемные моменты и предложу, что с ними можно сделать.

Ory Kratos - современный cloud native сервер идентификации с поддержкой PassKeys, MFA, FIDO2, TOTP, WebAuthn, с возможностью управления профилями, схемами пользователей, входом через внешние сервисы, регистрацией, восстановлением аккаунта, с поддержкой passwordless входа. Написан на Go, headless, API-first.

Целью этой статьи не является сравнение с другими популярными сервисами идентификации, которые дальше будут упомянуты, но будет рассмотрен основной функционал и мой опыт использования в пет-проектах.

Недавно меня спросили, какие фреймворки обратной связи я знаю. Я растерялся и сходу вспомнил только бутерброд, а также то, что хвалить нужно публично, а ругать — приватно. Это заинтриговало меня: какие же существуют практики для правильной обратной связи?

Давайте рассмотрим гипотетическую ситуацию: коллега принёс в офис кота, и тот поцарапал ваш ноутбук. Как правильно дать обратную связь, используя разные фреймворки?

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

Вместе с HR BP компании TAGES Маргаритой Рачкулик разбираемся, как двигаться по карьерной лестнице быстро и уверенно, правильно отслеживать и оценивать свой рост, а также выбирать верные шаги для достижения карьерных целей.

На рынке не так много книг, которые помогают начинающим тимлидам, которые еще вчера писали код и строили архитектуру, понять, как нужно приступать к работе с людьми и строить свое развитие по ветке управления. Это, естественно, две популярные книги: "Мама, я тимлид!  Практические советы по руководству IT-командой" Перескоковой Марины и "Как пасти котов. Наставление для программистов, руководящих другими программистами" Дж. Ханк Рейнвотера.

И вот на свет вышка книга: "Become an Effective Software Engineering Manager: How to Be the Leader Your Development Team Needs", которую Издательство Питер @ph_piter перевело как: "Карьера Software Engineering Manager. Эффективное управление командой разработчиков ПО". Не нужно пугаться позиции "Software Engineering Manager" - это именно что тимлид в понимании рынка РФ. И эта книга по своей сути является такой же отправной точкой в карьере начинающего тимлида, как и две предыдущие, но немного иначе!

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

В статье поделюсь своим мнением о том, как это делать и какие инструменты использовать.

Всем привет!

Сегодня хочу поделиться с вами личной историей преодоления и теми инструментами, рекомендациями и выводами по планированию, которые я нашла на своём непростом пути управления временем и командой, личными ресурсами и эффективностью.

Я приведу импровизированный кодекс, который поможет вам выбраться из ямы микроменеджмента и захлёстывающего с головой потока задач, или, если вам повезло, то понять как в него не попасть. Так что если вы управленец/менеджер/тимлид, то вам должно пригодиться. Но сразу скажу, некоторые рекомендации могут быть специфичными, чисто агентскими.

Хочу поделиться этой инфой потому, что знаю, что где-то на свете сейчас сидит, обняв коленки, менеджер/тимлид, который просто очень хочет на ручки и чтоб его обняли, а не вот это всё 😢

Коллега - я с тобой ✊ Держись, ты разберёшься и станешь сильнее и опытнее, чем был.

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

На написание статьи меня подтолкнула собственная боль, пронесенная через года, размышления о роли Google и GPT в работе программиста и старый анекдот про инженера и объем резинового мяча.

В большинстве учетных систем, типа нашего СБИС, рано или поздно возникает проблема быстрого отображения реестра, в который по просьбам бизнес‑пользователей накручено несколько комбинируемых фильтров с очень редкой выборкой, ну никак не ложащихся в вашу красивую структуру базы данных и индексов базовой таблицы реестра — что‑нибудь типа "список продаж покупателям, чей день рождения выпадает на 29 февраля".

Универсального способа сделать «хорошо» тут нет, но я расскажу про модель запроса, которая позволит вам дать пользователю быстрый отклик, но при этом весьма эффективно с точки зрения PostgreSQL.

Всем привет. Меня зовут Нина Пакшина, я разработчик “Лента Онлайн” и часть операционной команды в сервисе доставки продуктов.

В данной статье на примере языка Go я расскажу о том, как мы внедряли Kafka в связке с Schema Registry и Protobuf в качестве формата сообщений.

Я расскажу о том, какие появятся преимущества от использования данных технологий, а также пройдусь по подводным камням, с которыми можно столкнуться при разработке.

Веб 2.0 — отличная штука. Сайты на самообслуживании. Пользователи наполняют их сами («постят контент», как сейчас выражаются). Сами напостили, сами посмеялись. А владелец сайта только платит за хостинг и стрижет купоны на рекламе. Удобно же.

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

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

Что же делать? Конечно, призвать на помощью железную машину — пусть она сама ищет баяны.