#УправлениеПроектами #Теория #Качество

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

Давайте для начала определим, что такое качество проекта или продукта - в общем случае это соответствие заранее установленным параметрам или требованиям,
🌟для ИТ систем часто применятся такие показатели, как быстродействие, время отклика, объем баз данных и т.д.
🌟Для производственных систем у вас может мониториться % бракованных изделий, соблюдение Гости т.д.
🌟Также под качеством проекта может подразумеваться и качество выстроенных процессов внутри проекта/ организации для своевременного выявления дефектов/ проблем.

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

Общая схема управления качеством выглядит так:
1️⃣На этапе инициации Заказчик определяет требования к продукту, РП собирает все стандарты и политики, которым также должен соответствовать продукт
2️⃣На этапе планирования
◦ Команда уточняет эти требования и определяет, что нужно сделать в проекте
◦ РП разрабатывает план управления качеством (кто, что и когда делает, какие процедуры проверки качества будем использовать, с какой периодичностью) и синхронизирует его с остальными планами (сроки, деньги, др)
3️⃣ На этапе реализации
◦ команда проводит контроль качества разработок в соотв. с планом (например, тестирует программный код перед сдачей Заказчику на предмет соответствия требованиям) - чек-лист тестирования ИТ-системы забери тут
◦ отдел качества контролирует соблюдение плана по качеству (например, проектный офис проверяет наличие протоколов внутреннего тестирования, подписанного тестировщиками)
4️⃣ На этапе мониторинга Заказчик проверяет продукт на предмет соответствия заявленным требованиям (тестирует решение) и в случае успеха - принимает работы

🌟ТОП 5 советов:
1. В каждом проекте вы управляете качеством, когда что-то проверяете. перед тем, как что-то проверять, напиши, КАК проверять
2. Лучше предотвращать, чем устранять
3. Не надо делать лучше, если вас об этом не просили - это передайте проектной команде
4. постоянно ищите способы, как повысить эффективность процессов управления проектом/ разработки кода/ проведения совещаний
5. за качество отвечает каждый участник проекта

🆘А теперь Давайте сразу к ключевому и основному, что вам нужно запомнить и на этом мы пожалуй на сегодня закончим, чтобы не мучать и меня и вас 😂

Как вы знаете, в проекта есть треугольник ограничений - стоимость, расписание, содержание. Представьте, что это ваши вершины треугольника (рисунок будет ниже). В проектном управлении есть одна простая аксиома: при изменении любой вершины (к примеру, увеличение содержания или при снижении стоимости) обязательно изменяются и другие вершины, а какая-то из свершил невозможна к изменению (к примеру, проект нужно реализовать к 01.01.22), поэтому вы как Руководитель проекта всегда должны находить компромисс и наиболее важные параметры для проекта.
Что выберет Заказчик: реализацию дополнительного функционала и увеличение сроков проекта на 2 неделю + 500 тыс. руб. или завершит проект в срок, но не выполнит дополнительное требование?

✅ так вот - основной вывод сегодняшней темы в том, что какие бы вы параметры проекта не меняли, вы никогда не должны СНИЖАТЬ утвержденное качество вашего продукта и стараться удержать его наиболее «круглым»!

Все эти вопросы мы подробно разбираем на курсе Основы управления проектами, узнать , когда будет следующий поток или приобрести записи, можно тут

Следующая область управления проектами
Управление коммуникациями

Привет, 102 подписчика!))) 🎉

За сегодняшнюю ночь нас стало немного больше, чем 1️⃣0️⃣0️⃣)

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

В чате закрепила 3 поста: о себе, о навигации по хэштегами и о теме блога на январь - области знаний проектного управления.

🌟Проектный менеджер VS менеджер продукта?

#интересныеМероприятия #проекты #продукты

Кто все эти люди и какая в них разница? Судя по опросам примерно 20% не понимают разницы. И это нормально и вполне объяснимо - во многих компаниях эти функции перемешены, либо используются не по назначению.

🗣Я объясню просто на примере
Давайте представим, Вы - менеджер продукта, например в он-лайн школе, вам поставлена задача сделать ПРОДУКТ - сайт для взаимодействия преподавателей и учеников, да еще так, чтобы он он-лайн школе прибыль приносил и имел внешний, удобный, классный интерфейс.

И вот вы хватаетесь за голову и начинаете думать, что же такого можно на этом сайте сделать, изучаете потребности будущих пользователей, выбираете платформу, считаете экономические эффекты и в итоге решаете для запуска привлечь Менеджера проекта (неважно: внутреннего, внешнего) для реализации ПРОЕКТА по созданию сайта.

📆 У менеджера проекта задача понятная и ограниченная определенной целью и во времени: к 1 июня запустить сайт с заявленным функционалом.

И вот 1️⃣ июня вы получаете готовый сайт , но дальше вам, как менеджеру продукта, предстоит поддержка и развитие ПРОДУКТА: внимательно следить за работой сайта, реагировать на внешние и внутренние изменения с целью обновления сайта; контролировать, чтобы заявленные эффекты действительно были достигнуты и, что самое главное, но редко используемое - вовремя принять решение о выводе вашего сайта из эксплуатации или замене его на более крутую версию.

А дальше все по спирали и этому может даже не быть ни конца ни края (ну вот такая доля у менеджера продукта). На этом нашему примеру конец, а кто слушал…т.е. Читал + 500 к карме 🙏

#управлениеПроектами #теория #коммуникации
💜Это Моя самая любимая область управления проектами и, если вы хотите стать хорошим руководителем проекта, полюбите её тоже.

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

Задумайтесь над следующей ситуацией : вы встречаете в коридоре руководителя смежного подразделения, который интересуется, когда вы планируете запускать в продуктив вашу систему. Вы называете дату, а он просит вас направить все документы по проекту

Что бы вы подумали?
⁃ какого художника?
⁃ кто это вообще?
⁃ У меня его вообще в проекте нет
⁃ Блин, придётся тратить время и потом отвечать на вопросы по документам

Бывало у вас такое? Наверняка да! Первое, о чем вы должны подумать : почему он интересуется проектом и соответственно почему он вовремя не получил необходимую - скорее всего вы не идентифициррвали его как заинтересованных сторону, не учли его требования, как следствие, придется проводить доп работы. Оно вам надо?

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

Самый главный документ здесь - план коммуникаций, который обычно состоит из описания того
🌟какие совещания/встречи /звонки /статусы/ информационные сессии/ публикации вам нужно провести
🌟в каком формате (очно, заочно)/ какая периодичность
🌟кто ответственный
🌟с кем (кто должен быть на совещании или кто должен быть получателем информации )
🌟какая цель каждой коммуникации

А вот еще топ 5 лайфхаков для составления и исполнения классного плана коммуникаций:

1️⃣ Представьте все коммуникации как квадрат: они проходят внутри и снаружи проектной команды, а также в горизонтальном и вертикальном направлении. А теперь постарайтесь описать каждый из этих потоков.
Например, вертикаль вверх: в офис управления проектов РП будет 1 раз в неделю подавать отчет о статусе проекта в установленной форме (word). Горизонталь: команда обменивается статусом задач и открытыми вопросами на ежедневных стендапах и т.д.

2️⃣ коммуникации в проектах не всегда письменные и формальные. Постоять в курилке/ отметить ДР участника команды/ похвалить за крутую работу - это тоже коммуникация. Краткая шпаргалка о подходящих типах коммуникаций будет внизу в виде картинки

3️⃣ используйте правило 5С: любая коммуникация должна быть грамотной, емкой, с указанием цели, с логичным изложением мысли, и под контролем. Вам кажется эта рекомендация слишком очевидной? 😎А вы понаблюдайте за ближайшими своими или чужими коммуникациями и сделайте выводы - соблюдаются ли эти условия или нет.

4️⃣ Вспомним математику: если в проекте у вас 3 участника команды, то у вас 3 канала коммуникации. А если 4? Количество каналов рассчитывается по формуле n*(n-1)/2, т.е. При 4 участниках у вас Уже 6 каналов. А если 10 участников команды? - чтобы коммуникации оставались эффективными, Выделите 2 мини-руководителя групп (к примеру, ведущий программист и ведущий аналитик) и все коммуникации проводите с ними, а они в свою очередь - со своими 2-3 участниками.

5️⃣last but not least не стесняйтесь подтверждать получение информации - это касается и простых писем из серии: подтвердите, пожалуйста, получение письма. Я, к примеру, очень люблю писать письма с фразой kind remind и далее напоминание о том, что я ожидаю получить. Если речь про устную коммуникацию (особенно на удаленке) просите собеседника повторить как он понял вопрос/ поручение или попросите зафиксировать в виде мимо/ протокола

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

Все эти детали, шаблоны и примеры рабочих документов мы разбираем на семинаре «Инструменты проектного управления» (доступна запись)

#посмотреть #видео #управлениеРасписанием

Ежегодно пересматриваю это неимоверно милое видео про сетевое планирование и управление расписанием из Советского союза.

Столько прошло времени, а видео до сих пор актуально
Обязательно посмотрите, как будет время

Enjoy!
https://www.youtube.com/watch?v=xDp6xKOVJYE&t=977s

Еще больше информации про управление расписанием в проектах

#кейсыИзЖизни #проДоговоры

Включать ли Акт выполненных работ в результирующие документы по договору?

Давайте сразу на примере из жизни: у вас проходит опытно-промышленная эксплуатация системы (ОПЭ) и в договоре в качестве результата указан Акт выполненных работ. И вот Подрядчик запустил систему в ОПЭ и через 2 дня приходит к вам с актом выполненных работ на подписание? Можете ли вы его подписать? - очевидно нет, но, с другой стороны, юридически у вас нет необходимости сдавать другие документы.

И 2️⃣ вариант развития событий: в результатах этапа написано:
🌟Протокол проведения ОПЭ в течение 3-х месяцев
🌟Протокол устраненных замечаний по итогам ОПЭ

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

ИТОГО: Акт выполненных работ - это бухгалтерский документ, который вы в любом случае обязаны подготовить при закрытии этапов работ, а вот конкретные результирующие документы дают вам сразу четкое понимание, что нужно сделать, а также позволяют избежать потенциальных разборок и споров в суде

☝🏻Кстати, имейте ввиду, что достаточно часто Поставщики предлагают договоры, по условиям которых, предоставление акта выполненных работ обязывает вас в течение какого-то срока⏰ (к примеру, 5 дней) его подписать или направить официальный отказ, а если вы вдруг этого не сделали, работы считаются принятыми. Поэтому обязательно внимательно читайте договор и согласовывайте его с юристами.

Подробности разбираем на семинаре «Тендеры и договоры» (доступны записи)

🚘Арендовать или покупать в проектах и в жизни?
#кейсыИзЖизни #бюджетПроекта

Пост как всегда навеян прошедшим обучением на курсе Финансовый менеджмент))
Новым студентам - привет)))

Сегодня немного поговорим о классификации статей затрат на CAPEX и ОРЕХ, которая всегда используется в организациях и при управлении проектами. Знать и понимать эти термины нужно для того, чтобы уметь ответить себе на вопросы

• Арендовать место в облачном хранилище или купить собственные сервера?
• Нанимать работников в штат или привлекать со стороны?
• Арендовать автомобиль или приобрести в собственность?

Объясню на простом примере из жизни:

🚘 Вы хотите водить машину и думаете, ЧТО именно выбрать: каршеринг или купить новенький порш (ну а что… сразу замахнемся на него).

Если у вас сейчас нет достаточной суммы денег 💰(хотя бы для первого взноса по кредиту) вам выгоднее использовать каршеринг (недорого, быстро, можно взять любую машину и вполне вашей цели удовлетворяет) - это будут ваши текущие (ОРЕХовые) затраты. Вы начинаете ездить, ежедневно тратите деньги на каршеринг, пару раз съездили за город и уже понимаете, что денег то уходит не мало, а скоро годовая премия, да еще и скидки на машины прошлого года и вы решаете купить пусть не Порше, но хотя бы хёндай. И вот вы выезжаете из салона на новеньком авто и теперь понимаете, что у вас уже появилась своя собственность, которую вы почти в любой момент и по предсказуемой цене можете продать - это ваш актив или CAPEXовые расходы. Это серьезная покупка, которой вы будете пользоваться больше года (если все-таки не решитесь на порш). Однако у вас появляются новые расходы - текущий ремонт, заправка, покупка ковриков, масла, обывателей, вонючек и т.д. И это опять ваши текущие расходы, т.е. OPEX

☝🏻К чему я все это: с точки зрения краткосрочного планирования всегда выгоднее иметь OPEXовые затраты (дешевле взять машину в аренду на несколько часов), но с т.з. стратегического мышления - выгоднее наращивать свои «активы», т.е. CAPEXовые затраты (когда у вас есть в собственности автомобиль вы понимаете, что у вас есть определенная «денежная подушка».

Чем больше у вас OРEХовых затрат, тем больше расходов приходится нести ежемесячно, плюс возникают непредвиденные/ нерегулируемым проблемы (нет поблизости нужной машины из-за высокого спроса, в карантин каршеринг закрылся и т.д.).
Однако и СAPEXоывые затраты также имеют свои минусы: машину надо заправлять, ремонтировать, и между прочим платить налог.

📌Вывод (вспомним о нашем выборе: каршеринг или покупка): решение принимать конечно вам, важно учесть не только затраты в моменте (покупка автомобиля), но и все сопутствующие затраты во время использования, и еще и не забыть про обесценение машины при продаже. А вот опыт, конечно, полученный после обладания автомобилем, вряд ли измеришь в денежном эквиваленте 😂

📒Ну и немного теории с практическими применениями в проектах:
• Капитальные затраты, или CAPEX (сокращ. от англ. capital expenditure), представляют собой затраты на приобретение активов (срок эксплуатации более 1 года - машина), а также на их модификацию (достройку, дооборудование, реконструкцию - замена Хендай на порш) и модернизацию. Пример из проектов: закупка ПО, оборудования, лицензий, привлечение внешнего консалтинга.

• Операционные затраты, или OPEX (сокращ. от англ. operational expenditure), представляют собой затраты компании, которые возникают в процессе ее текущей деятельности. Примерами операционных затрат являются: зарплата персонала, аренда помещений, представительские расходы, командировочные, затраты на обучение или обследование бизнес-процессов.

А какую модель предпочитаете вы - покупка или аренда квартиры/ машины/ оборудования? Делитесь в комментах к посту)

💣#управлениеПроектами #теория #управлениеКомандой

Всем привет!
Сегодня 6-я область знаний проектного управления - Управление командой. Напомню, что перечень областей знаний есть в закрепленных сообщениях 👆🏻

Ооооох, к этой теме я долго не могла подступиться. Почему? Потому что помимо теоретической фигни (её тут кстати достаточно мало) тема управления командой - это огромный океан теорий, практик и личных навыков, но давайте все-таки попробуем начать.

Когда вообще начинается процесс управления ресурсами?
есть несколько сценариев :

Сценарий 1️⃣
при инициации проекта. Давайте для примера сегодня будем внедрять CRM систему. Итак заказчик назначает вас РП и даёт для первичной проработки проекта, к примеру, функционального специалиста- руководителя отдела продаж и аналитика и вот у вас уже появилась маленькая команда

Сценарий 2️⃣
вас назначают Руководителем проекта и поручают определить, кто вам нужен в проекте и вы садитесь планировать проект:

🗂определяете содержание - здесь вы пишите, что хотите, к примеру, интеграцию вашей CRM системы с бухгалтерской системой для автоматического выставления актов выполненных работ. Сразу же «прикидываете» требования к исполнителю: необходим программист из соседнего отдела, который обслуживает 1С:Бухгалтерию (внешнего подрядчика не рассматриваем- он не сможет получить доступ к нашей системе). Вторая задача - это настроить систему оплат, для этого нужен будет программист, который занимается CRM (у нас в компании никто эту систему не знает - будем брать подрядчика), а для оплат нужна интеграция с нашим сайтом (это тоже будет делать подрядчик, но без нашего разработчика сайта тут не обойтись). Ну и конечно нужно выбрать ключевых пользователей, которые поставят требования к CRM системе, протестируют ее и потом будут визионерами внедрения - запланируем пока 2 человека)))

⏰Определяете расписание - выделяете приоритетные работы и «прикидываете», когда и на какой объем работы вам необходимы будут заявленные выше ресурсы. К примеру, выставление актов потребуется только к концу квартала, да их можно и руками сделать - с этим можно повременить, а вот оплаты пойдут сразу и нужно сделать интеграцию с CRM как можно скорее - поэтому подрядчика начнем искать сразу и заранее договоримся о привлечении разработчика сайта. Результатом этого шага является предварительное расписание использования ресурсов - кто и в какой момент вам нужен.

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

Дальше начинается полноценный процесс управления ресурсами, который состоит из следующих действий:
1️⃣ Еще раз составляете перечень всех необходимых ресурсов с учетом графика работ и требований. У нас с вами получилось 2 программиста, ключевые пользователи и подрядчики. Пока без фамилий - только роли
2️⃣ Готовим матрицу ответственности - кто и что должен делать. Можно в виде матрицы RACI
3️⃣Опционально, но желательно - делаете устав команды - это принципы взаимодействия, к примеру, какие основные ценности, как мы будем принимать решения, форматы проведения совещаний - не стесняйтесь, пишите все, что хочется - так вы заранее закладываете фундамент вашего взаимодействия
4️⃣ Вот тут самое интересное - вам необходимо идти договариваться с владельцами ресурсов о выделении самых лучших специалистов для вашего проекта! Ваша задача получить конкретные фамилии под конкретные роли. Включайте все свое обаяние, прихватывайте с собой дар убеждения и вперед. Можете сначала составить письма с запросом о выделении требуемых вам фио с указанием функционала и времени участия, а если будут вопросы у менеджеров ресурсов - топайте ножками.

ПРОДОЛЖЕНИЕ->>>>>>>

🏷Я прихожу в магазин покупать вещи, а не скидки

Всем привет!
Думаете, Странный заголовок в чатике про управление проектами?? А вот и нет. Руководители проектов постоянно сталкиваются с необходимостью продажи себя или проекта, поэтому сегодня хотела бы поделиться с вами своими мыслями на этот счет.

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

Я очень люблю приводить пример с покупкой вещей👠. Как прожжённый шопоголик я фанат походить по торговым центрам. В период распродаж и скидок - это конечно то еще занятие. Не успеваешь ты зайти в магазин, как тебе из самого дальнего угла кричат о том, что у нас скидки -50/ -30%. А я как бы не за скидками пришла, а туфли из новой коллекции купить (ну, к примеру).

Также и в проектах - прежде, чем предлагать Заказчику варианты снижения стоимости проекта, сформируйте ценностное предложение, которое будет соответствовать ожиданиям Заказчика и вашему понимаю о стоимости этой работы. А вот уже в запасе имейте несколько козырей на случай, если Заказчик попросит рассказать о вариантах оптимизации затрат. Кстати, вот парочка советов, как сократить затраты и при этом остаться «при заработке»
🌟сокращение содержания
🌟перенос рисков на сторону Заказчика

Все остальные варианты (типа: сокращения стоимости оборудования, привлечения более дешевого специалиста или сокращения бюджета проекта в 4 раза 😂) не пишу, т.к. предполагаю, что в первоначальном бюджете вы уже выбрали самый оптимальный способ выполнения работ для достижения заявленного качества и примерно понимаете ожидания Заказчика.

А что вы думаете на этот счет? С какими кейсами встречались?

#обзор #добропожаловать

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

В закрепленке есть вся необходимая информация обо мне (меня зовут Ольга) и о назначении этого чата)) Здесь мы общаемся и делимся нашими находками в сфере проектного управления, продуктивности и не только) К чату привязан канал https://t.iss.one/proProject1 - это для тех, кто не хочет общаться, а только получать полезные сообщения;)

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

#СоветДня или #СоветВыходногоДня - простые, но емкие советы из жизни РП
#ИнтересныеМероприятия - обзор ближайших мероприятий, или конспекты прошедших лекций, конференций, семинаров
#Design - вдруг кому интересна тема дизайна
#Платформа #ИТсистемы - немного об ИТ
#сертификация #PMBoK #PMP #управлениеПроектами #теория - говорит само за себя
#продуктивность #приложения - все про планирование, продуктивности, обзоры мобильных приложений
#смешно - ну не все же о серьезном
#Обучение #ПолезныеВидео - обзор проводимых обучений

#ВопросОтвет
Всем привет!
За последний месяц ко мне обратилось около 10 человек относительно возможности трудоустройства в сферу проектного управления или перехода с др специальностей, потому решила сделать серию постов «вопрос/ответ» по самым распространенным вопросам :

PS за идею поста большое спасибо @Pashtet64
Итак, поехали🚀, постараюсь отвечать кратко и емко - если какую-то тему нужно будет раскрыть поподробнее - пишите

1️⃣можно ли устроиться на должность Руководителя проектов совсем без опыта

🗣Ответ: Нет, увы нет - всем сейчас нужен опыт, причем в релевантной сфере. Если вы занимались проектами по открытию офисов продаж, вряд ли это подойдет для реализации ИТ-проектов.
⁉️Что делать: попробуйте устроиться на администратора/ координатора проекта - здесь требования ниже и как раз ваш опыт в другой сфере будет хорош.
☢️Исключения: новые компании, которые массово пылесосят рынок и без разбора берут РП-шников, но вероятность такого успеха крайне мала

2️⃣ Нужно ли мне сертифицированное обучение
🗣Сильно зависит от вашего текущего уровня и опыта работы.
🌟Если вы совсем новичок, то для начала вам необходимо понять основы проектного управления - для этого сертификация не нужна (вы скорее всего ее просто не сдадите), достаточно мини-курсов, которые вам «вправят мозги» в нужном направлении. Желательно найти в этой сфере опытного ментора, который «проведет» вас по всем основам, желательно из той сферы, куда хотите попасть.
🌟А вот если вы уже имеете проектный опыт и, к примеру, ваша компания подается на серьезный тендер в проект, здесь уже могут потребовать специальную сертификацию и если у вас ее не будет, то на определённым этапе вы будете проигрывать в деньгах отдельным специалистам.
⁉️ Опять же сертификация «выглядит хорошо», когда вы приходите устраиваться на работу опытным РП, и при прочих равных сертификация может стать решающим фактором

3️⃣ Имеют ли роль при приёме на работу проектные кейсы, которые дают гиганты обучения?
🗣Без реально опыта - нет, но и тут есть нюансы - зацените разницу:
🌟вы имеете опыт реальной инициации проекта, т.е. Можете рассказать о том, как общались с Заказчиком, какие презентации рисовали, как набирали группу (это ваш реальный опыт), вот тут вы можете применить кейс из учебного курса и рассказать, что еще вам приходилось рассчитывать бюджет проект методом оценки по аналогам и вы это делали вот так….
🌟Но еси у вас нет вообще никакого опыта, все учебные кейсы будут выглядеть очень куце и опытный рекрутер обязательно копнет в такую конкретику, на которую у вас не будет ответа: к примеру: как проходила защиты бюджета с вашим Заказчиком, какие вопросы вам задавали, какие аргументы вы приводите и так в каждой области.

Дабы сильно не затягивать, на сегодня на этом остановимся, но у меня в запасе еще пяток вопросов. Если у вас тоже есть или появились вопросы, которые стоит вот так осветить - напишите, пожалуйста в комментариях + напишите, пожалуйста, если в вашей практике были/ есть отличные кейсы👇🏻

Доброе утро!
#вопросОтвет #Итсистемы
По запросу @ziablova_e

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

1️⃣Кадровый документооборот

https://job-63.ru/news/253/

2️⃣Бухгалтерский учёт

https://moluch.ru/conf/econ/archive/131/6697/

3️⃣Документооборот

https://crmindex.ru/sed

https://www.tadviser.ru/index.php/Статья:Самые_популярные_СЭД/ECM-системы

Добавляйте в комментариях 👇

⚠️ #управлениеПроектами #теория #управлениеРисками⚠️

На повестке - 7 область "Управление рисками" в проектах - это, кстати, единственная область знаний, которая должна обсуждаться абсолютно на каждой проектной встрече, на каждом совещании, а основная работа Руководителя проекта на самом деле заключается в постоянном поиске и анализе новых рисков. Также к работе над рисками ОБЯЗАТЕЛЬНО должны быть привлечены все заинтересованные стороны проекта.

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

1️⃣ Риски имеют положительные ✅ и отрицательные 🆘последствия, поэтому стоит выделять угрозы и возможности.
💡 практически любой риск можно переформулировать в возможность. Например, уход крутого ведущего разработчика даст вам возможность привлечь более квалифицированного сотрудника со свежим взглядом, а если совсем повезет - еще и за мЕньшие деньги

2️⃣ два основных параметра риска - это вероятность возникновения и последствие от риска. Наша задача в работе с рисками - снижать вероятность угроз, и снижать негативное влияние/ последствие. если говорить о возможностях - делаем все наоборот.

3️⃣риск - это не всегда событие, можно фиксировать и неопределенности. Пример: несвойственные для данного сезона погодные условия или возможные изменения законодательства
💡как работать с такими рисками - постепенно заполнять пробелы и постоянно переоценивать последствие риска. к примеру, мониторить изменения законодательства, участвовать в формировании экспертной позиции, получить драфт законопроекта и тд

4️⃣Не все риски можно предотвратить, но можно научиться быстро ⚡️и гибко реагировать на наступление риска
💡что делать? заложить денежные 💰 или временные ⏰ резервы (к примеру + 100 тыс. на прием на работу более дорогого программиста), предусмотреть план Б (начать обучать ведущего программиста, организовать программу наставничества).

5️⃣ не все риски НУЖНО предотвращать или работать с ними. определите, на какие риски можно "забить" (к примеру эту те риски, где ваши затраты на снижение вероятности гораздо выше стоимости последствия)
💡 что делать? - учитывать риск аппетит (уровень риска, который компания готова принять), проводить качественный анализ риска с помощью тепловых карт 🔴🟡🟢 . Зеленые риски просто фиксируем и периодически следим, чтобы они не попали в красную зону

6️⃣ Можно отслеживать в динамике 📈 различные числовые индикаторы для предотвращения наступления рискового события для проекта (к примеру, отношение фактических трудозатрат к плановым - для этого берем плановые затраты из плана-графика и ежедневно делаем выгрузку трудозатрат к примеру из jira, сравниваем два показателя и при отклонении разбираемся, что идет не так)

7️⃣Отслеживать программные и портфельные риски 💼 на уровне организации, которые могут влиять на ваш проект.
Пример: у вас в компании инициирован новый очень приоритетный проект... время напрячься - скоро к вам придут за вашими лучшими ресурсами 😂😂

8️⃣Наш любимый #Agile в принципе один большой риск, поэтому весь цикл управления рисками 🔄 проводим для каждого инкремента и еще тщательнее ходим и ищем новые риски

9️⃣ количественная оценка рисков - не обязательный этап. Обычно ее проводят в сложных строительных, космических или автомобильных проектах для расчета тех событий, которые могут привести к большим финансовым потерям. Пример из книги "Ли Якокка. «Карьера менеджера»: увеличение капота автомобиля на 5% (по желанию Генри Форад 2) могло стоить компании около 100 млн $. И как всегда не забываем про целесообразность такой сложной оценки - см п5

🔟 этот пункт надо было поставить первым.

Научитесь грамотно формулировать риск - он должен стать для команды 🌟 путеводной звездой", а не набором непонятных символов.
К примеру,
❌убиваем все риски типа: риск превышения бюджета проекта, риск задержки сроков и пишем по формуле: причина - риск- эффект.
✅Например, в связи с некорректным планированием и как следствие переработками ведущего программиста, он может уволиться, что приведет к потенциальным ошибкам в программном коде или к задержке выпуска релиза на 1,5 недели.
Чувствуете разницу? в этом случае вам сразу понятно, что нужно делать, чтобы предотвратить это безобразие.

Более подробно эта тема разбирается на 4-х часовом практикуме по управлению рисками, там же все шаблоны и примеры описания 6 самых распространенных рисков в проектах

🌟Что такое soft скилы и для чего они нужны руководителю проекта и не только ему

#Кейсизжизни

Работала я как-то в одной ИТ-шной команде, которая занималась внедрением системы по учету заработной платы. А система эта всегда заинтегрирована с системой ведения бухгалтерского учёта (в зарплате делаем кадровые документы, считаем зарплату и начисления), а вот уже все проводки передаём в «бухгалтерию» - этой программой занималась другая ИТ Команда. При этом у нас был один Руководитель.

И вот как-то раз сидим мы на совещании, где мой аналитик в проекте рассказывает о концепции построения управленческого учета (тезисы предварительно обсуждались с руководителем, но он не смог присоединиться ко встрече). Кстати, если интересно, зачем в компании делают компании учёт - черканите в комментах. Смежная Команда в жесткой форме отклоняет все предложения под предлогом непроработанности концепции и как следствие нереализуемости в Бухгалтерии. Аналитик закипает на глазах и я решаю прекратить дискуссию.

Как вы считаете, что делать в такой ситуации? Выберите ответ в опросе ниже, а через день разберём доступные варианты и мой выбор.

Опрос и Ответ на кейс