1С Управление проектами (канал)

Как же хочется оформить пост картинками, но... Если сделать картинку, то Телеграмм ограничивает количество символов подписи к картинке. Приходится хоть где-то хоть как-то вставлять смайлики

Еще одна тема про относительность: Достигнут ли результат проекта. Наверно, возникнет вопрос, почему эта тема про относительность. Объясню, почему я ее таковой считаю, возможно вы со мной согласитесь. Опять обратимся к составляющим, тут их тоже три: 1. Сам факт понимания ожидаемого результата. 2. Полнота понимания ожидаемого результата. 3. Оценка достижения ожидаемого результата. Чтобы понять достигнут ли результат, надо четко понимать сам ожидаемый результат. И вот тут все очень неоднозначно и есть сложности. Где и кем определен результат? Результат может быть описан в договоре, тендерной или проектной документации. Но мы уверены, что это тот результат, который действительно ожидается. Ведь зачастую такие разделы как цели и задачи, а соответственно и ожидаемые результаты просто копируются из более-менее подходящих источников. Что же поделать с такой ситуацией? К сожалению, почти ничего. Тендерная документация не подлежит корректировке исполнителем. Вписать в проектные документы цели и ожидаемые результаты, отличающиеся от договорных, тоже некорректно, т.к. приемка работ и все официальные процедуры все равно будут опираться на юридически-значимые документы. Остается смириться, внимательно читать, что прописано в документах, и на входе в проект хотя бы обсуждать, чего мы должны достигнуть по факту. Это мой взгляд. А как вы работаете с официальными ожиданиями результатов? Полнота понимания ожидаемого результата. Тут хотела бы сказать о двух вещах: • В полной ли мере описан в документах ожидаемый результат, ничего ли не забыли, ничего ли не преувеличили при «копировании». См. п 1. • Не все ожидаемые результаты обычно фиксируются в бумагах. Важно не забывать, что проекты это взаимодействие с людьми, ведь именно люди принимают все решения. И даже если на бумаге есть перечень формальных результатов, нельзя забывать про то, что ожидают персоналии. Этот момент важен, так как зачастую, принятие решения о достижений целей проекта происходит не по ожидаемым результата, зафиксированным в юридически-значимой документации, а как раз на основании удовлетворенности персоналий, что их хотелки выполнены. Но будьте внимательны. Многие допускают фатальные ошибки, не соблюдая баланс достижения официальных результатов и персональных. В результате, или слишком формальный подход к реализации проекта и отказ от приемки работ по причине «Вы сделали не то, что мы хотели». Или наоборот, все персоналии удовлетворены, а вот формально система-то не та и при приемке работ мы получаем вопрос «Получается вы сделали не то, что в договоре. Как же мы подпишем вам акты?» Оценка достижения ожидаемого результата. Тут надо задаться вопросом, а вообще измерим ли результат, описанный в документах, или мы видим обтекаемые фразы типа «улучшение качества обслуживания клиентов». Сразу должен возникнуть вопрос, каким образом должно быть улучшено качество обслуживания? И тут тоже весьма частая ошибка: мы забываем или соглашаемся на результаты, которые не на 100% зависят от нас, как исполнителей. А имеют значительную долю работ и ответственности самого заказчика. Например, провести реструктуризацию отдела продаж, оптимизировать процедуры, изменить регламенты и пр. Или другой результат: «Создание рабочего места менеджера». А каким должно быть это рабочее место, какие функции оно должно позволять реализовывать? Зачастую это нигде не описано и мы вынуждены это обсуждать уже в ходе проекта и работать с ожиданиями персоналий. При этом даже не фиксируя эти ожидания. И в результате, см. п.2 «Многие допускают фатальные ошибки, не соблюдая баланс достижения официальных результатов и персональных». Как же работать с этими относительностями? К сожалению, опять «единой таблетки» нет. Очень многое в этом вопросе зависит от коммуникативных навыков РП, умении лавировать, расставлять приоритеты и принимать решения, которые нужны именно этому проекту именно в этот момент. P.S. Пост получился с каким-то оттенком безысходности😰. Видимо осень уже внесла свои краски.

🤯Сложность проекта 🤯 Наверно самая простая тема в череде возможных тем об относительности на проекте. На мой взгляд, важно изначально, до обсуждения самой темы, определить на какие составляющие надо ее разложить. Определить, что в принципе образует «Сложность проекта». Предлагаю остановиться на 3 составляющих: 1. Сама компания, выполняющая проекты, уровень ее развития. 2. Параметры, которые определяют сложность проекта. 3. Значения параметров, определяющих сложность проекта. Поговорим про каждый. Уровень развития компании. Я выделяю этот параметр отдельно, т.к. каждый франчайзи должен понять и корректно про себя понимать уровень развития проектной деятельности, уровень развития управленческих навыков, профессиональный уровень своих сотрудников и пр. Это понимание должно максимально четко определить, как бы это обидно не звучало, место компании на рынке. Т.к. именно от истинного понимания «места» зависит адекватность принятия всех решений о развитии компании, выстраивании системы управления, в том числе управления проектами. А верные решения ведут в верной цели – росту. Это понимание является и важной составляющей для формирования достаточно прикладной вещи – системы оценки сложности проекта. Т.к. для небольших начинающих компании даже небольшой проект может быть сложным. А для крупных китов проектного бизнеса этот же проект будет весьма прост. Поэтому важно определить начальную точку верно – на каком уровне развития находится компания. Параметры. Тут перечислю те, которые часто использовала и я, и мои коллеги. Вас же попрошу расширить этот список своими примерами. • Бюджет • Длительность • Базовый программный продукт и/или количество базовых продуктов для создания системы • Численность проектной команды (включая основных представителей подрядчика) • Наличие третьих организаций в проекте. Например, Субподряд, генподряд • Инновационность проекта для Исполнителя • Территориальные рамки проекта, количество удаленных подразделений • Организационные рамки проекта, количество юрлиц • Количество пользователей • Методологический объем проекта (Изменений бизнес-процессов и формирование методико-регламентной документации для Заказчика) • Объем работ по интеграции с системами заказчика и миграции данных • Влияние на корпоративную инфраструктуру Заказчика – количество новых для Заказчика систем • Взаимосвязь и зависимость от других проектов • Критичность для бизнеса, уровень контроля проекта со стороны Заказчика • Стабильность окружения – наличие стратегии развития компании, происходящие орг.изменения в структуре Заказчика • Изменения в ИТ-процессах поддержки на стороне Заказчика Значения параметров. Эта составляющая полностью зависит от первой составляющей – «понимании» своей компании. Важно верно определить границы и значения каждого параметра, чтобы система учета проектной деятельности работала корректно. И тут сложность именно в индивидуальности. Нельзя, к сожалению, дать единую для всех таблицу и предложить ею пользоваться, тут каждый должен подумать и принять решение для своей компании.

Давно не выходила на связь (у меня закончилась одна из фаз самого важного в жизни проекта и началась другая🐣)))). Но если посмотреть по датам, вроде бы и не очень давно. Перерыв всего лишь с 7 июля. Вот она – относительность. И ведь эта относительность везде: в жизни, в работе, в отношениях, в ощущениях. И конечно же в проектах. Хочу сделать ряд постов про различные относительности в проектах. Например, сложный проект или нет, эффективен ли результат проекта для заказчика или нет, достигнут ли результат или нет. Накидайте еще примеров относительности в проектах, чтобы можно было подумать, обдумать, проработать и пообщаться.

Коллеги, обратите внимание даты курсов слегка изменились. Курс по ТКВ будет проходить по вторникам, начиная с 13.09, и до 18.10

Добрый день) Коллеги, хочу с вами посоветоваться. Вопрос вот какой. Если бы вам предложили лекцию по PMBOK, примерно на 3 часа, какие темы, вопросы, дискуссии были бы вам интересны. Вопрос возник потому, что если рассказывать содержание PMBOK, то это точно намного больше 3 часов. А рассказать, что есть такой свод знаний, это точно меньше 3 часов. И хочется найти интересные вопросы и темы, чтобы время было потрачено эффективно. Посоветуйте, о чем рассказать, что показать, что обсудить по PMBOK. Заранее очень благодарна)

Коллеги, добрый день. Объявлены даты очередных курсов: • Управление проектами на основе 1С:ТКВ: 08.09.2022 - 13.10.2022 • Как построить проектное управление в фирме-франчайзи: 03.11.2022 - 08.12.2022 Записывайтесь https://uc1.1c.ru/courses/upravlenie-proektami/

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

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

Татьяна, ваш вопрос связан с терминологией. Я в своей практике сталкивалась аж с 3 видами ТЗ: 1. ТЗ на конкурс. Документ, который клиент прикрепляет к конкурсной документации, чтобы участники могли сделать свои предложения. Этот документ готовит сам заказчик. 2. ТЗ приложение к договору. Часто повторяет ТЗ на конкурс. Но если исполнитель выбирался не в рамках конкурсной процедуры, а просто выбором подрядчика, то это самостоятельный документ. Этот документ готовит сам заказчик. 3. ТЗ на создание системы. То самое ТЗ, где описывается детально, как будет реализована система, какие есть требования, какие условия создания. Иногда в ТЗ на создание системы приводятся даже описания смоделированных в системе бизнес-процессов, и корректировок кода программы. А вот этот документ готовит исполнитель. К сожалению, в нашей сфере нет единых терминов и жестких ограничений по их использованию. Поэтому входом для фазы 1 служит именно ТЗ приложение к договору, которое определяет, что должно быть сделано в ходе проекта.

«Формализация сведений, необходимых исполнителю и заказчику для предварительной оценки объема работ, рисков, продолжительности и стоимости проекта». Отчет об экспресс-обследовании включает как раз сведения, на основании которых рассчитываются сроки и стоимость проекта. В шаблоне документа указано: «Отчет об экспресс-обследовании позволяет зафиксировать единое понимание Заказчика и потенциального Исполнителя о целях, задачах и рамках проекта». Т.е. по сути это предметные результаты обследования, ответы на вопросы, которые зафиксированы в п 0.11 ТСВ «Основными направлениями, требующими уточнения, могут быть …». А вот после обследования и написания отчета об экспресс-обследовании, составляется КП, где и указываются сроки и стоимости. И тут помним! Технологии дают рекомендации по максимально полным проектным циклам. А вот пользователи уже вправе выбирать, нужна ли им та или иная работа, или они ее исключают из проекта, конечно, анализируя возможные риски.

Теперь о том, бывают или нет ситуации с уточнением и без него. Да, бывает и так и так. На наличие работ по уточнению влияет в основном 3 параметра: 1. Готов ли клиент тратить на нас – внедренцев время, чтобы дать ответы на наши уточняющие вопросы. 2. Какие риски мы – внедренцы видим, если не будет производить уточнение требований. Ведь бывают случаи, когда без уточнений риски таковы, что и в проект не стоит идти. А бывает и наоборот – все понятно, т.к. мы уже не первый проект делаем у данного клиента. Ну это к примеру. Ну или как написала Татьяна, есть очень подробное, исчерпывающее ТЗ. Хотя такое большая редкость. 3. Готовы ли мы инвестировать в продажу проекта данному клиенту, т.к. любые работы по уточнению требований и составлению нового КП – это наши затраты. Вот на пересечении ответов на эти 3 вопроса и возникает решение – делаем уточняющее КП или нет, и ограничиваемся лишь первичным. Данное решение может быть принято как на совещании по презентации первичного КП, так и после него в рамках пакета работ 0.8 «Повторная квалификация запроса заказчика». Соответственно, решение о выполнении п. 0.9 - 0.13 ТСВ принимается исходя из решения – делаем или нет уточняющее КП.

Добрый день, коллеги и Татьяна. Приношу свои извинения за долгую паузу в публикации постов и ответах на Ваши вопросы. Сегодня хотела бы ответить на вопросы Татьяны, которые она задала по новой технологии 1С:ТСВ 3.0. Вопроса было 3 и публикаций, тоже сделаю 3. Вопрос №1 (см. картинку). Тут сразу обращу внимание, что все технологии 1С – это общие своды знаний. Они дают рекомендации по максимально полным проектным циклам. А вот пользователи уже вправе выбирать, нужна ли им та или иная работа, или они ее исключают из проекта, конечно, анализируя возможные риски. Исходя из этого утверждения. Действительно на фазе 0 «Продажа проекта», предусмотрено 2 типа взаимодействия с клиентом – первичные переговоры и КП, и уточняющие переговоры и уточненное КП. При этом мы понимаем, что уточнение может происходить даже не в один заход, а иметь несколько циклов.

Но есть момент печальный в PMBOK7 - забыла написать сразу. Теперь в книгу вошла мораль и принципы, а все инструменты перенесены на интерактивную платформу и стали недоступны к покупке (поправьте меня если не права). И это перекос, но уже в другую сторону. Поэтому я бы рекомендовала изучать и PMBOK7 - принципы и домены, и 6 - где есть области знаний, фазы, инструменты.

Добрый день. Вчера обещала ответить на вопрос Егора Кабанова «Интересует практическое применение PMBOK 7 к проектам внедрения 1С в наших реалиях и менталитете». Итак, мое мнение – всегда считала, что PMBOK применим. Теперь прямо по пунктам. 1. Область деятельности. Применение PMBOK не зависит от области деятельности компании – внедрение 1С, стройка, позаказное производство. Это связано с тем, что PMBOK описывает общие правила организации работы людей. Он не содержит никакой специфики, ни по какой отрасли. В PMBOK даны общие рекомендации по организации проектных работ. Это библиотека полезных рекомендаций. В любой отрасли проект имеет фазы инициации, планирования, исполнения, контроля и завершения. В любой отрасли есть и команда, и расписание проекта, и заинтересованные стороны и т.д. Поэтому общие рекомендации применимы, конечно, везде. 2. Объем бюрократии. PMBOK не настаивает на том, что должны применяться все предложенные в нем подходы, практики, инструменты. Еще раз, PMBOK – библиотека. Каждая компания вправе выбрать для себя те эффективные на текущий момент времени инструменты, которые ей необходимы. А далее можно развиваться, и скорее будет развитие, или долго использовать то, что определили для себя как важное ранее. 3. Менталитет. Тут тоже ничего такого… Проект есть проект, и по проекту должны быть планы, должна быть отчетность, должна быть ясность. И независимо от менталитета (многие же не любят контроль), если вы осознаете, что проекты должны приносить выгоду, вам придется планировать, собирать отчетность и ясными глазами смотреть на проект. И тут не до менталитета и нелюбви к контролю. Есть правила. А вот внедрять их можно жестко или аккуратно и незаметно. Тут выбирать вам. А человек, независимо от менталитета, привыкает ко всему))) 4. Если к реалиям отнести еще и нежелание формализовывать какие-то вещи, экономить на этом время и бюджет, то тут опять же решать вам. См. п.3. И если вы готовы увеличить риски связанные с отсутствием планов, отечности, контроля, то это ваш выбор. И PMBOK тут ни при чем, его задача показать вам, что является правильным и полезным. 5. Личность РП. Его ценности и мораль. Вот наконец в PMBOK 7 они появились. Я всегда говорила, что управление проектами – это на 50% психология. Теперь в PMBOK описаны принципы управления проектами (ценности и мораль РП) и домены исполнения проекта (наставление как все организовать, на что обращать внимание). Этого очень не хватало в предыдущих изданиях – они были какие-то очень инструментальные. А теперь – полный набор))) Ну и конечно, с точки зрения применимости, управленцы они и есть управленцы, ценности и мораль работы с людьми одинакова во всех отраслях. А менталитет – так ведь «хорошее слово и кошке приятно». Поэтому учитесь работать с людьми. И тут тоже полная применимость. Итого: PMBOK полностью применим. Я работала в компаниях, где применялись все без исключения процедуры, работала там где применялись только выборочные элементы. Ну а те компании, где не применялось ничего, их уже и нет в области проектов. Более того, поверьте, вы скорее всего неосознанно применяете многое, что описано в PMBOK. И тут стоит вопрос – прочитать, систематизировать свои знания и даже обрадоваться, что вы сами до многих моментов дошли. И как приятно в книге увидеть возможные пути развития, согласитесь))) Готова ответить на ваши вопросы и подискутировать - пишите.

И еще хотела вас спросить: может быть вам что-то рассказать про PMBOK 7? Может есть какие-то конкретные вопросы? Но сразу оговорюсь, конечно рассказать смогу через призму собственного восприятия) Задавайте вопросы в комментариях)

Когда я слушала анонсы, эти 12 принципов казались какими-то общими, формальными, «холодными формулировками». Понятными, но отстраненными от жизненных реалий. И только при прочтении я поняла! Наконец-то, в таком важном документе появились «заповеди», «правила поведения», «идеи», которым должны следовать РП. Наконец-то, вместо «холодных» и «строгих» инструментов, подходов и процессов мы получили моральный кодекс руководителя проекта. Раньше я всегда говорила (тут не в коей мере не хочу задеть чувства верующих, сама верую, поэтому возьму слова в кавычки): PMBOK – «библия» РП. Но как я ошибалась!!! Это была не библия, а свод законов, правил. А вот сейчас – ДА!!! Стандарт управления проектом содержит каноны управления проектами. Это мораль и наставление – каким должен быть РП, как он должен относиться к проекту и команде, и вообще, что такое проект, ведь это не просто набор задач, а целый мир, со своими правилами, внутренними и внешними взаимосвязями, и людьми. Коллеги, очень рекомендую почитать, правда книгу надо или покупать, или «доставать». Но поверьте, она того стоит. Если раньше я говорила «Не бойтесь читать это большое издание на 800 листов. Вы там найдете много понятного, т.к. уже работаете в проектах. А книга поможет вам структурировать имеющийся опыт и знания». То сейчас я говорю «Найдите и прочитайте PMBOK 7. Книга читается не как учебник по физике или математике, а как художественная литература с моральной составляющей». И повторюсь, в Стандарте по управлению проектом вы найдете не «формулы работы на проекте», а «мораль и наставление», которые, надеюсь, придутся вам по душе. Они кому-то помогут убедиться и утвердиться в своем профессионализме, а кому-то взглянуться на проект другими глазами, увидеть новый вектор своего личного роста и развития как руководителя проекта – быть не просто заранее определенной шахматной фигурой с заданными правилами движения по полю, а создателем тех самых фигур, правил и даже, отчасти, идеи самой игры.

Стандарт управления проектом. Возможно Вам мой пост покажется каким-то напыщенным и высокопарным по смыслу. Но все же… Сейчас читаю новую версию PMBOK, седьмую. Читаю внимательно и кропотливо. Не торопясь, вчитываясь и пропуская через себя. Закончила изучение одной из частей - «Стандарт управления проектом». И спешу с Вами поделиться своими ощущениями. Стандарт включает в себя 2 основные части: Система поставки ценности и Принципы управления проектом И тут у меня немного личное. ощущение. До момента самостоятельного изучения PMBOK 7, я прослушала много разных выступлений, анализов, анонсов. Все в один голос говорят «Это прорыв», «Это новое видение и подход к реализации проектов». Основные изменения, которые анонсируются: 1. «Цель проектов по новому стандарту не в производстве результатов, а в поставке ценности». Соглашусь это очень важное изменение. Именно оно ведет к пересмотру многих аспектов управления. 2. Формулировка 12 принципов управления проектом. И вот к ним у меня сложилось особое отношение.