Управление проектами *

Кажется, что чтобы наладить коммуникации в команде особых усилий не требуется. Многие руководители проектов думают: «люди и так договорятся» и поэтому часто фокусируются исключительно на «жестких» аспектах (сроки, бюджет, процессы). Однако именно коммуникации являются тем «клеем», который скрепляет все остальные процессы проекта и напрямую влияет на его успех или провал. И недооценивать их — ошибка.

Привет, Хабр! Я Марина Евстафьева, HRBP в КОРУСе, со мной Анастасия Криулина, фасилитатор и ведущая командных сессий. Сегодня мы поговорим о важном аспекте управления командами, который часто упускают из вида — коммуникациях. О том, какими они должны быть, как их выстроить и что важно учитывать. Чтобы не загружать вас теорией, мы решили продемонстрировать все на реальных историях, свидетелями которых были сами.

Привет, Хабр! Меня зовут Маша, я бренд-аналитик, провожу разные исследования, а в перерывах пишу на Хабр. Коллеги из команды спецпроектов попросили меня протестировать на моих реальных задачах MWS Tables и сравнить со своими привычными сервисами. Я проверила его для проведения опросов, обработки данных и отслеживания задач на канбан-доске — и готова поделиться впечатлениями.

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

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

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

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

Время выполнения потоковых задач в разработке часто колеблется: один день задача занимает 2 часа, в другой — 6. Из-за этого сложно предсказать, уложится ли команда в срок. Control chart помогает отслеживать разброс времени, находить аномалии и корректировать процесс до того, как отклонения станут проблемой. 

В статье разберем, как это работает, и покажем, как можно читать график, чтобы определить SLA при работе с заказчиком.

Идея написать статью пришла ко мне, когда я читала книгу «Цветы для Элджернона». Кто не знаком с произведением, советую его прочитать: это глубокий и пронзительный психологический роман, в котором мужчина с нарушениями интеллектуального развития по имени Чарли стал гением благодаря научному эксперименту. И хотя цель была высокой и благородной, а результат — достойным, герой  доставил достаточно хлопот ученым на своем пике развития интеллекта. Что-то все-таки пошло не так, и постепенно Чарли потерял все знания, которые ему открылись. В какой-то момент чтения я подумала: а ведь похожим образом ведут себя требования. Они сначала простые, понятные. Потом бац! Они начинают умнеть, эволюционировать, требуют больше ресурсов и в конечном счете создают хаос и порой даже рушат текущие процессы.

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

Сегодня в блоге ЛАНИТ на Хабр я хочу поделиться десятью шагами из своего опыта, которые помогали моей команде справляться с ситуациями, когда требования росли быстрее, чем их успевали зафиксировать.

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

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

Эта статья является дополненной адаптацией статьи профессора Леонардо Карвало. Сначала описывается структура ОБЛАСТЕЙ (выделены разным цветом), затем перечисляются блоки (пронумерованы). В каждом блоке есть: описание в чем его задумка и примеры вопросов, советы, пример заполнения.

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

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

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

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

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

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

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

Обрыв каналов связи, багованный релиз, мискоммуникация… Серия загадочных событий, авантюрный детектив из цикла «Следствие вели…» — нет, не с Леонидом Каневским, и даже не Колобки, а команда разбора инцидентов, или просто Post. 

Хей-хей! Я Юля, и я специалист по сопровождению инцидентов в команде Post департамента SRE (Site Reliability Engineering). Когда я рассказываю своим друзьям, чем я занимаюсь на работе, мне часто говорят, что я работаю в детективном агентстве. 

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

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

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

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

Привет, с вами Вячеслав Егоров, основатель и CEO MediaTen. Сотрудничая с крупными клиентами, я понял, что у них есть запросы на полный комплекс услуг от одного подрядчика. И помимо разработки, в него входят аудиты и написание подробной технической информации, в том числе техзаданий.

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

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

Для начала представлюсь — меня зовут Роман, я аналитик и проджект разработки информационных систем, в основном с веб‑интерфейсом. Занимаюсь этим делом давно, и понятно что сдавать проекты различной крупности приходилось неоднократно. Но рассказать хочется об одной недавней разработке, когда на этапе сдачи выплыло особенно много незапланированных изначально вещей, что сделало ее (сдачу) особенно длинной и болезненной. Надеюсь, что пытливый читатель возьмет этот опыт на вооружение и хотя бы продумает пути завершения проекта заранее.

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

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

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

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

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

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

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

Потому что до этого работала по 14 часов в день. Без перерывов и с редкими выходными.

Раскрываю тему «рисков» разработки ПО в сравнении с.. киноиндустрией. Чтобы дорогие читатели наконец одумались, устыдились и более никогда не заморачивались этой воображаемой проблемой.