Пару раз на предыдущих местах работы я попадал на проект, где не было документации. Все знания о проекте были у разных коллег, а некоторые части систем вообще были «чёрными ящиками».

Что делать, когда попал в проект без документации? Ответ простой — уходить!

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

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

- неизвестный проект с неизвестными рисками;

- непонятный руководитель (при первом знакомстве он душка, но какой будет в реале?);

- непонятные коллеги;

- непонятный заказчик.

Причем, как правило, проект, который вам отдают, уже несется на всех парах: команда пашет, заказчик чего-то хочет, у нового руководителя какие-то ожидания. И хорошо, если все так просто. А часто случается, что проект уже летит в бездну, бюджет израсходован, заказчик всех ненавидит, а руководство ждет от вас сдачи на следующей неделе (да, такие случаи тоже бывали 😊).

Это очередная статья о том, чего не рассказывают на курсах РП: о тех самых софт-скиллах, которые потребуются Руководителю проектов с самого первого дня работы. Если вам интересны такие истории, читайте другие мои статьи на Хабре и подписывайтесь на мой ТГ канал "Морковка спереди, морковка сзади".

Выглядит так, что РП, выходящий на новую работу, как пассажир, который пытается запрыгнуть в поезд на ходу, чтобы потом добраться до головы состава и начать им управлять. И чем быстрее летит поезд – тем сложнее в него запрыгнуть. Ну и на все про все у вас примерно 2 недели. 4 от силы, если место ванильное, и поезд еще не разогнался.

Как не свернуть шею и не попасть под колеса на этом славном пути – по пунктам ниже

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

Опуская множество НО, в целом, философия Agile (а никак иначе язык сказать не поворачивается) показала довольно неплохие результаты с точки зрения организации команд в других, околоайтишных направлениях.

И возник вопрос, возможно ли этот подход положить на понятный, последовательный и очевидный проект в области Охраны труда. Казалось бы, зачем? А затем, что помимо понятной и очевидной части есть совершенно непредсказуемая и многогранная - работа с Заказчиком, пользователями и экспертами.

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

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

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

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

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

Привет, Хабр!

Меня зовут Кристина Спирина, я руководитель проектов в IT.

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

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

Иметь свой VPS для VPN довольно выгодно. Нет ограничений по количеству клиентов, можно обеспечить VPN подключением всех своих родных, друзей и знакомых. При этом можно за это платить 160-300 рублей в месяц. И если общедоступные VPN вовсю банятся по DNS и IP, то личные VPN пока что избегают этой участи.

Минусы есть, это администрирование сервера и отсутствие разнообразия географии.

Для VPN нужен зарубежный сервер, а с зарубежными сервисами в России уже больше года есть проблемы с оплатой. Но есть российские компании, которые предоставляют зарубежные сервера и при этом им можно платить с помощью российской карточки.
Я зарегистрировался в дюжине провайдеров, до покупки VPS дошёл у пяти. А после тестов остались только трое.

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

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

Срок выполнения задачи  – 2 месяца, что добавило остроты проекту перед Новым годом…