Особенности внутренних проектов.
Коллеги, продолжаем тему внутренних проектов.
Вот что получилось у меня по особенностям внутренних проектов. Может быть дополните, расширите…
➕ Проще управлять объемом работ, т.к. нет жестких рамок объем-срок-бюджет.
〰️ С другой стороны сложнее рамки удержать, т.к. появляются «вечные хотелки».
➕ Легче управлять планом работ, т.к. (хоть это и печально) внутренние проекты делаются по остаточному принципу и все понимают, что сроки будут сдвигаться. Тут оговорка – не управлять, а выдерживать базовые планы.
➕ Коммуникации явно легче, т.к. работаем со всеми знакомыми лицами.
➕ Проще производить приемку работ, фиксировать отклонения, планировать доработки и исправление ошибок и недочетов системы.
➕ Отсутствуют формальные процедуры – управление рисками, работа с заинтересованными сторонами.
〰️ Зато сложнее управлять ресурсами, т.к. их постоянно выводят на внешние проекты.

По мне, так получается внутренние проекты делать легче.

#Рассуждения_о_проектах

Коллеги, добрый день.

🎲 А ведь мы вчера поиграли!!!! Помните, я говорила про бизнес-игру «Пресейл»…

Знаете, не плохо получилось ☺️
Совсем новый формат обучения. Не те самые скучные лекции, а динамичное общение.
Прокачали навыки
- уточнения требований,
- формирования ограничений проекта,
- немного проработали особенности жизненного цикла проекта
- и даже затронули soft-skills. То есть и про продажи, и про проект, как я и обещала.

Дима! Катя! Спасибо! (Это я нашим ведущим))))

✅ Плюс совсем иное ощущение при личном знакомстве, включенных камерах, живом диалоге…

✊ Участники нам дали ценные советы, что улучшить. Так что каждый следующий раз игра будет все динамичнее и продуктивнее.
Спасибо большое‼️

Присоединяйтесь в следующий раз, будет интересно и весело. Думаю и вам понравится.

#Обучение_РП

Почему у РП загрузка на больших проектах 100%

Ранее мы с Вами подняли тему загрузки разных ролей на проекте.
И даже была схемка… ☝️

Давайте сегодня поговорим про Руководителя проекта. Почему у него загрузка 100% и, самое главное, ну почти равномерная. Тут скорее надо поговорить про то, что загрузка именно почти ровная по всем этапам проекта - с небольшим падением на разработке. Так как объем участия РП может быть действительно и 100%, и 50%, и 70%.

Также как и ранее про аналитика – собрала по фазам проекта задачи РП.
Инициация
Тут масса всего, один из самых активных этапов работы РП.
• Знакомство в заказчиком
• Формирование плана-графика, устава, бюджета проекта
• А для них надо и риски продумать, и реестр заинтересованных сторон, и оргструкутру проекта
• Подготовка и проведение внешнего и внутреннего установочных совещаний
• А если есть субподряд, то все, что связано с планированием работ с субподрядыми организациями
• И начало работ по подготовке шаблонов документов, их согласование с заказчиком

Формирование требований к ИС
• Организация обследования – запросы доступов, запросы документации, согласование плана интервью
• Присутствие выборочно на некоторых интервью
• Контроль, что собранные требования соответствуют рамкам проекта
• Зачастую сложнейший вопрос организации среды разработки и тестирования новой системы – железо, доступы, ключи, доступы во внутренние контуры и т.п.
• Формальные работы по согласованию документов «Отчет об обследовании», описанных бизнес-процессов, альбомов отчетных и печатных форм

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

Разработка ИС
Тут тоже активная работа спецов. И лукавить не буду, считаю, что это этап, где РП отдыхает, работает фоном и готовится к следующим активностям.
Но задач тоже не мало, точнее их мало, но они очень фоновые и требуют включения с процесс:
• Организация предварительного/внутреннего тестирования работоспособности функционала ИС – подготовка предварительных показов функционала ИС ключевым пользователям
• Формальные процедуры согласования эксплуатационной документации
• Подготовка и проведение предварительных испытаний системы
• Опять же контроль рамок проекта и тут уже на испытаниях очень активная работ по их отстаиванию. Часто сложные переговоры по этим вопросам

Подготовка к эксплуатации
Активность растет. Здесь масса работ, т.к. почти все работы организационные.
• Перенос системы на продуктив
• Сложные работы организации переноса НСИ и исходных данных
• Подготовка и обучение конченых пользователей
• Контроль, что заказчик начал перестраиваться на работу в новой системе. Ведь иногда внедрение ИС затрагивает и изменение процессов. А это опять люди, недовольство, саботажи
• Подготовка этапа ОПЭ – и регламент, и сервис-дески, и трансформация команды
• Организация всем доступов

Эксплуатация ИС
Тут кажется – что РП делать?
А на самом деле один из самых активных и ответственных этапов.
Постоянные обращения пользователей и руководства. Проблемы с системой. Растущее недовольство, которое надо купировать.
Важнейшая задача – контроль обращений – не дать пользователям за месяц превратить систему в «лоскутное одеяло», плюс формирование запросов на изменение, если обращения явно не о функциональных рамках.
Загрузка тут конечно падает со временем, но в самом начале – очень активно.

Коллеги, добрый день.
🆘 Нашему коллеге требуется помощь.


Заказчик попросил в рамках проекта сделать РАБОТАЮЩИЙ реестр по изменениям в системе, который будет создан в рамках проекта и соответственно поддерживаться на протяжении всего последующего сопровождения. Хотят именно реестр, через актуализацию ПР не хотят этот процесс реализовывать. Может у кого-то есть удобный формат для использования?

Коллеги, добрый день.
🎄 С наступающим Новым годом 🎄

Под завершение года подготовили и опубликовали новые полезные материалы в ПрофКейс.
В 1С:ТКВ 2.0.:
• Сопроводительное письмо о передаче пакета выходной продукции по Фазе TKV-2-110 приведено в соответствие с ГОСТ 7.0.97-2016
• Шаблон Сопроводительного письма о передаче пакета выходной продукции по Фазе TKV-3-110 приведено в соответствие с ГОСТ 7.0.97-2016
• Содержательно обновлен Протокол предварительных испытаний TKV-2-073 и Протокол приемочных испытаний TKV-2-093
• Создан новый документ «Приказ о проведении приемочных испытаний системы TKV-2-118»

А в базе знаний «Методические материалы для РП и аналитиков» опубликованы новые документы, описывающие правила оформления эксплуатационной документации:
1. Руководство по оформлению эксплуатационной документации Р-ЭД-001
2. Образец руководства Пользователя
3. Образец ведомости эксплуатационной документации

Пользуйтесь, пожалуйста.

#Технологии_1С

Коллеги, добрый день.
🎄 С прошедшим Новым годом!!! 🎄

Подготовили для Вас новый долгожданный курс "1С:Аналитик".
Курс имеет гибридный формат - и видео-лекции, и онлайн-семинары, и домашние задания.
Дата начала курса 10.02.2025.

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

#Обучение_РП

Коллеги, добрый день.

Насколько актуально порассуждать о том, как работать с "минусовых" проектах?

Если актуально, предлагаю сформировать список наболевших вопросов по минусовым проектам.
✏️ Жду в комментариях ✏️

Давайте продолжим тему «минусовых» проектов.

Опрос, правда, прошло очень мало человек, но пропорции, думаю, получились жизненные.
Итого результат☝️
- довожу проект до конца, независимо от «минуса» 69%
- закрываю проект и фиксирую убытки 33%

☺️ Кстати, смешно считает телеграмм)))

Давайте обсудим причины и последствия первого пункта «Довожу проект до конца, независимо от «минуса».
Я напишу как вижу я, а вы дополняйте, корректируйте.

В моем понимании причин такого поведения две:
1. Деструктивная психологическая - «ну я же столько его продавал, как бросить», «проект всегда нужно доделывать, ведь нас так учили» и тп
2. Конструктивная хладнокровная. «Да, я изначально продал проект в минус, он у меня политический/маркетинговый/инвестиционный». Или «да, свалились в минус, но надо доделать, потому что …» и далее хладнокровная оценка ситуации, почему мы должны доделать. Вот коллеги ранее писали, например - не попасть в черный список поставщиков, или потом на вторичных продажах перекроюсь. Совершенно хладнокровная оценка текущей ситуации.

‼️ Коллеги, мне кажется, что в нашем бизнесе, при нашей профессии, надо уметь говорить «Нет», даже проекту. Да, это сложно, до этого надо дорасти, но надо ‼️

✅ Что я могу посоветовать, как с этим поработать:
- Посчитайте текущий минус 🥹
- Посчитайте тот минус, который еще будет 😭😭😭
- Подумайте, а если вы даже дотянете проект, заказчик-то будет доволен результатом. ☹️ 😖 🥶 🤬 🤕 💀 … Ведь зачастую «минус» признак не только плохой оценки, но и, простите, сложности в реализации. А значит, потенциально, несоответствия результата
- Оцените, а что будет с командой проекта. 🤯 (долго искала смайл, это самый отражающий, как показалось - вот такие у вас будут ресурсы в конце проекта). Люди же все чувствуют. Минусовой невыгодный проект эмоционально всегда сложный. И опять же… а бонусы то будут???
- Если вы руководитель отдела или компании оцените, не будет ли более эффективно использовать ресурсы «минусового» проекта в других активностях

Наверняка что-то забыла…
Но ответы даже на эти вопросы должны помочь вам научиться принимать решения в стиле «НЕТ».

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

P.S. Какой-то совсем не пятничный пост получился(

#Рассуждения_о_проектах

Коллеги, в комментариях обсуждаем, почему качество «сказать нет» такое дефицитное. Решила продублировать из комментариев прямо в канал. Спасибо Сергею 👏

Здравствуйте.
Пятница) Самое время продолжить разговор о «минусовых» проектах ☺️

Ранее мы немного обсудили – причины «почему мы беремся довести убыточный проект до конца». Поняли, что причины могут быть совершенно разные – самое главное – сознательные и бессознательные.

Теперь немного о формальной-организационной части выхода.

Мы решили выходить с «минусового» проекта, а вообще как выходить-то?
И тут надо для себя ответить на ряд вопросов:
1️⃣ какое мы принимаем решение - просто выходим и оставляем все результаты «за так»? Или будем доказывать частично-исполненную работу?
2️⃣ а вообще, позволит ли нам договор выйти из проекта до завершения?
3️⃣ а что у нас с формальными результатами, документами, как мы будем отстаивать то, что сделали на текущий момент? Если мы решили все же отстаивать.
4️⃣ будем ли мы пытаться сохранять 🪽лицо🪽? Или нам важнее выйти?

Ответы на эти вопросы, на мой взгляд, помогут выработать «стратегию выхода».

Да, коллеги, чтобы выйти с «минусового» проекта нужна стратегия.

К примеру. Знаю проект, где план выхода с проекта был рассчитан почти на 2 месяца бюрократических трудов руководителя проекта.
В расчет брались – формальные документы, которые надо подписать с заказчиком, до объявления о выходе с проекта; процедуры отправки документов; сроки доставки документов почтой; сроки подписания или получения мотивированного отказа, даже праздничные дни… Мы считали, чтобы документы приходили в определенные даты, которые были нам выгодны…
Но на всем был поставлен крест, маленьким печальным событием – отправкой пакета документом без описи 😮 🤬 Все!!! Точка, абзац, как говорят 🥶
Но все же из проекта мы потом вышли… Но это был уже другой план)

#Рассуждения_о_проектах