Микросервисная архитектура — это концепция, которая существует уже довольно давно, но до сих пор многие не до конца понимают, в чем ее суть, какие плюсы и минусы она имеет по сравнению с монолитной архитектурой. На мой взгляд это нужно понимать, даже нетехническим специалистам. Как-то даже на одном из собеседований на "продуктовую" позицию в крупную международную компанию, рекрутер попросила меня объяснить разницу между ними и перечислить преимущества и недостатки каждого подхода.
Этот статья вряд ли откроет что-то новое для опытных специалистов, хотя они, возможно, найдут его полезным как пример для объяснения новичкам. Однако нетехническим специалистам это может помочь — на простом бытовом примере я покажу, как работают оба подхода и чем один лучше другого.

Меня пригласили как эксперта по внедрению гибких подходов управления в одну IT-компанию, занимающуюся разработкой решений в сфере B2B. Основная задача заключалась в том, чтобы настроить процессы управления проектами, сделать их предсказуемыми и управляемыми. До начала сотрудничества компания сталкивалась с множеством проблем: сроки регулярно срывались, клиенты были недовольны, проекты могли «висеть» в работе до 8 месяцев без завершения, а команда испытывала серьезные перегрузки из‑за параллельной работы над несколькими задачами.

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

Ещё до ухода Microsoft менеджеры проектов часто переключались между двумя системами — Project использовали для планирования задач и, например, Jira для их исполнения. В этом случае они вручную или с помощью дополнительных плагинов синхронизировали данные, а также отдельно узнавали статусы у исполнителей в третьем решении или мессенджере.

При этом Project оставался самой популярной системой для ведения проектов в крупных компаниях. Мы с командой понимали, что рано или поздно Microsoft отключит российских пользователей, поэтому заранее стали готовиться к росту запросов на «полный аналог» и перепридумали своё проектное управление. 

Меня зовут Максим Тимонов, я дизайн-директор в «Первой Форме». В этой статье я покажу, какие возможности мы добавили, чтобы заменить MS Project и объединить всю проектную работу в одной системе. 

На шкале стресса Рея и Холмса увольнение занимает восьмое место среди 43 наиболее стрессовых событий жизненного пути. Это тревожное событие как для сотрудника, так и для руководителя: мир IT тесен, и нужно понимать, что в какой-то момент вы можете встретиться снова, чтобы вместе работать. Так как поступить правильно и где всё-таки поставить запятую в «Уволить нельзя оставить»?

Привет! Нас зовут Катя Черных и Маша Вострикова, мы бизнес-аналитики в Х5 Tech. Мы любим инструмент User Story Map (карта пользовательских историй или USM), проводим по нему воркшопы в X5 и хотим поделиться своим опытом.

В статье рассказываем, как на этапе Discovery (начальный этап проработки задачи, на котором выявляются основные требования и анализируются поставленные бизнес-цели) прорабатывать большие инициативы, используя USM. 

Фокус делаем на практическом использовании карты и на что обращать внимание при построении USM. Мы собрали возможные сложности, разобрали конкретные кейсы и описали варианты взаимодействия с заинтересованными лицами. 

Привет, Хабр! Я Женя, CPO в корпоративном мессенджере Compass. Собрались мы как-то в баре с 5 продактами, поделились друг с другом рабочими историями, и теперь у меня есть 5 антикейсов, которыми я, с разрешения ребят, поделюсь здесь.

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

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

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

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

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

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

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

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

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

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

Эта статья – часть цикла статей о том, чего не рассказывают на курсах РП, и что в жизни понадобится вам с первого же дня работы: о так называемых софтскиллах РП. Кому это интересно, читайте статьи здесь и заходите в мой ТГ канал «Морковка спереди, морковка сзади».

Правила – это скучно.

Я давно заметил, что, когда набираю новых менеджеров и рассказываю им про регламенты и правила разработки в компании, они очень внимательно слушают, усиленно кивают и вообще – само внимание. А спустя пару недель или месяц, внезапно выясняется, что они не даже не кликнули по ссылке, которую я отправлял в письме. И читают регламенты исключительно из-под палки. Хотя, казалось бы, что там: 5 листов, 30 минут осознанного времени, не более. Почему так?

Я работаю тимлидом уже несколько лет и с уверенностью могу сказать, что это направление развития мне очень нравится. А помню, я чуть не запорол свою карьеру тимлида в самом начале, на переходном этапе разработчик - тимлид. Я тогда работал разработчиком в большой компании и, в общем, работа мне нравилась. У нашей команды был номинальный тимлид - хороший, душевный человек, которому очень нравилось ковыряться в своих железках, а в жизни команды его участие ограничивалось только вопросами на дейлике “как дела?”. В общем, проблемы в команде копились, и никто ими не занимался, и меня это беспокоило. В итоге мне предложили попробовать себя тимлидом. Я эту историю рассказываю к тому, что я начинал свой путь с огромном воодушевлением, но уже через 3-4 месяца я почти выгорел и хотел вернуться в разработку или вообще уволиться. Поразмыслив тогда, я решил, что не могу так бесславно уйти и должен попытаться разобраться в ситуации и найти другое решение. Я сформулировал 4 основные причины такого быстрого выгорания, которое случилось со мной на этом переходном этапе. Мне удалось найти решение этих возникших трудностей и продолжить работу.

Итак, четыре проблемы начинающего тимлида.

«Играющий тренер» – термин, пришедший в IT из мира спорта. Он подразумевает, что руководитель одновременно занимается как управленческими задачами (планирование, контроль), так и решает вполне рядовые (пишет код, настраивает сервера и т.д.). Считается, что совмещать эти роли нельзя, но в жизни, как и в палитре, есть куча оттенков между «можно» и «нельзя». Под катом будет мой жизненный опыт в роли этого самого играющего тренера, я расскажу о плюсах и минусах, а также попробую подвести некий итог своего опыта в этой роли.

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

Описание задачи

Иногда в жизни бывает так – вам вручают белую каску менеджера вместо привычной оранжевой или синей каски исполнителя и говорят: «Теперь ты — руководитель проекта. На тебя вся надежда». Что делать, если при этом вы не изучали, например, PMBoK (Project Management Body of Knowledge, свод знаний по управлению проектами)? Вы могли в них участвовать, но отвечали за функционал и делали работу руками. Как пересесть в другое кресло и вжиться в иную роль, по возможности гася в себе синдром самозванца?

В ЛАНИТ мы выполнили тысячи различных проектов – внутренних, внешних, с различными видами контрактов и оплат, сервисных и строительных, связанных с привлечением десятков субподрядчиков. Персонально я когда-то тоже получил белую каску – управлял внедрением ERP-систем, руководил отделом консалтинга, вел международные и локальные проекты. Так что сегодня дам несколько, надеюсь, полезных советов.

Когда вы вступаете в должность в качестве руководителя или старшего менеджера проекта, одной из первых и самых важных задач является понимание текущих процессов управления проектами. Этот процесс, часто называемый аудитом, позволяет определить точку «As Is…» — текущее состояние дел в компании. Без четкого понимания текущей ситуации невозможно разработать эффективный план действий и начать внедрение улучшений. Меня зовут Саша Максимова, я уже 10 лет занимаюсь развитием команд и управлением проектами, сейчас работаю в Kokoc group на должности Руководителя отдела управления проектами и надеюсь, эта статья поможет многим избежать моих ошибок.

Статей про эмоциональное выгорание много, и часть из них очень даже хорошие. Они фокусируются на работе с людьми: как и что говорить, какие ставить задачи, где вести общение, и вот это всё. Я хочу разобрать более узкую тему: специфичное выгорание тестировщиков. И решения буду предлагать не про людей, а про процессы. Как строить такие процессы разработки, чтобы минимизировать эмоциональное выгорание в команде? Какие баги (в коде и в процессе) надо фиксить? На какие штуки обращать внимание? Рассказывать буду с трёх позиций: что с каждой проблемой может сделать биг‑босс (РМ или собственник бизнеса), тест‑менеджер и сам выгоревший тестировщик. Букв в статье получилось много, сорян ))) Зато вроде полезные? Поехали!

Привет, Хабр! На связи QA-специалисты SimbirSoft Алена и Светлана. В компании мы тестируем проекты 1С в составе выделенной команды или на усилении команды заказчика. 

Сегодня платформа 8.3 компании 1С — популярный и востребованный продукт на рынке учетных систем СНГ, несмотря на различные мнения коллег по разработке. Комьюнити 1С расширяется, и материалов для изучения становится всё больше. Но наши коллеги часто ломают голову над тем, как подступиться к тестированию 1С:Предприятие и автоматизировать процесс.

1С это целая экосистема, которая имеет свои особенности и специфичные термины. Поэтому сегодня разберем виды, порядок, инструменты и особенности тестирования 1С, автоматизацию и подход к подготовке документации на примере одного из проектов. Если вы QA, AQA или SDET, и вам предстоит тестировать платформу 1С — эта статья для вас.