Регламенты или KPI? ИТ-специалисты, и спецы по 1С не исключение, считают себя весьма творческими натурами. На самом деле, в этой области очень много неизвестных - обновилась платформа, например, и функция встроенного языка стала работать по-другому. И таких мелочей довольно много. Связаны они с тем, что бизнес заказчика меняется, внедряемый продукт меняется - и платформа и конфигурации. И в этом постоянно меняющемся мире имеют место быть человеческие ошибки. Как в этой ситуации регламентировать все? Я не видел ни одного регламента, который бы все соблюдали. В том числе - УК РФ

Что делать если вас склоняют принять заведомо странное решение? Например, подписаться под бюджет или план, в который ни вы, ни команда не верите? Из этого положения есть выход. Всегда можно принять сторону сильного и поддаться давлению. Так делают чаще всего незрелые руководители проектов. При этом, не подолжив себе документ. И страдают до скончания веков. Да, да. Не до конца проекта, а до скончания веков. Ибо длиться этот проект будет долго. Можно жестко отказаться. Но не все компании согласны мириться с такими РП и при такой позиции следует быть готовым к выходу из компании. Либо четко и конкретно подкладывать письма и документы - условия - на которых вы берете тот или иной проект

Сколько руководителей проектов должно быть в проекте - вопрос риторический. Классическая теория говорит о том, что только один руководитель проекта может быть в одном проекте. При этом есть хитрость - теория говорит также о том, что каждый, или почти каждый, участник проекта в том или ином виде занимается управлением проектом. То есть сама по себе методология управления существует в виде некоего блокчейна во всей команде, но вот итоговый ответственный за проект - один. Но всегда ли должно быть так? А если в команде 50 или даже 100 человек? Как один руководитель проекта может справиться с таким количеством?

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

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

Поэтому важно перед началом проекта определиться, кто мы - руководитель проекта по должности, или по роли. И уже от этого решения отталкиваться при конфигурировании команды проекта.

Когда делать проект как программу?
1. Когда проект занимает больше года
2. Когда проект должен поставлять результаты на протяжении всего времени выполнения
3. Когда проект выполняется несколькими командами профильных специалистов
4. Когда количество людей в команде стремится к бесконечности
5. Когда уровень бюрократии зашкаливает
6. Когда вы не уверены в своих силах и вам нужна поддержка

Всегда и везде важно определять круг заинтересованных лиц в проекте. Если кого-то пропустите - придется "ловить" требования при сдаче системы и отвечать на вопросы о том, почему вы, профессионалы, не подумали об этом заранее.
А действительно - почему?
Проблема заказчиков в том, что они не владеют технологиями. И внедрения, и знаниями о программах, которые они внедряют.
А проблема внедрецев в том, что они не владеют знаниями об организации.
Поэтому многие все-таки стремятся нанимать в штат. Тогда и заинтересанты целы, и знания все в коробочку сложены

Коммуникации в проекте. Как это?
Во всех умных книгах пишут, что 85% работы руководителя проекта - это коммуникации. Или даже больше. И дальше в этих книгах кропотливо объясняется, что под этим термином понимается набор артефактов. Например, план управления является средством коммуникации. Протокол является средством коммуникации. Отчет о статусе является средством коммуникации. Потому они они позволяют большому числу людей передать информацию без искажения.
Но есть аспект, о котором часто забывают. Эмпатия. Позитивное отношение между проектной командой и заказчиком и внутри проектной команды.
Если через дорогу друг от друга будут стоять две кофейни, где кофе будет немного сравним, но в одной все же хуже - вы пойдете в ту, где кофе лучше. Но если в первой будет бариста, с которым вы сможете душевно побеседовать и обсудить житейские вопросы, вы захотите ходить в ту кофейню где кофе может немного хуже, но атмосфера вам приятна. Да, это больше про продажи.
Но давайте будем честны - руководитель проекта продает проект. Спонсору. Функциональному заказчику. Команде. Пользователям. Да и мало ли еще кому...

Еще недавно никто не думал стандартами программ проектов в сфере 1С.
А вы уже подошли к этому этапу? Чем вам мог бы помочь такой подход?

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

Этика и эстетика.
Институт управления проектами PMI не сдержался и занял какую-то сторону в глобальной политической игре. Вот ссылка: https://www.pmi.org/about/solidarity-with-ukraine
Как вы считаете, насколько этично со стороны PMI так поступить и какова ответственность руководителей проектов за подобные политические выпады уже в индивидуальном порядке?

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

Всегда ли проекты уникальны?
С одной стороны, само определение проекта даёт однозначный ответ на этот вопрос. С другой, мы должны понимать, что уникальность а нашем мире - всегда понятие относительное. В целом, если рассматривать, скажем, учёт основных средств, вы можете совершенно достоверно утверждать, что в 99% проектов документ «Принятие к учета ОС» будет одинаковым. Да, это лишь одна операция из множества. Но если взглянуть сверху на множество проектов, то вдруг окажется, что с точки зрения офиса управления проектом вполне себе 80% работ повторяются из проекта в проект. И там страннее то, какое количество неудачных проектов в отрасли имеет место быть. Однако, поскольку руководитель проекта выполняет, как правило, 1-2 проекта в год, задача анализа проектов на системном уровне становится задачей именно проектного офиса. Требуйте от вашего офиса на входе в проект статистических выкладок, примеров документов, шаблонов и, конечно, развития методологии управления проектами. Занимайте проактивную позицию

Методологии нет, а регламентов много
Интересно бывает в проектных офисах. Начинаешь разбираться в процессах и понимаешь, что регламентов, инструкций и разного рода документов - вагон. Но не складывается в картинку.
И тут понимаешь, что документов много, а что делать - непонятно
Зачем нужна методология?
⚖️ обеспечить сравнимость проектов при анализе проектов
⚒ дать возможность РП быстро использовать результаты предыдущих проектов
⚙️ наладить взаимозаменяемость РП и членов проектных команд
💰 научиться делать полезные выводы из проектов
🕰 не терять время при входе в проект на разработку методики и синхронизации понятий внутри команды

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

Как проверить требования на полноту?
- Привязать все требования к процессам и проверить, что не осталось пустых процессов, не осталось процессов где одно или два требования, где требования охватывают все шаги процесса и отделы заказчика
- в среднем каждый крупный отдел (опрошенный эксперт) является источником 10 требований
- при чтении требований по порядку в рамках процесса создаётся полное впечатление от работы программы
- нет разрывов между ссылками друг на друга требований
- экспертный анализ функционального архитектора

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

Управление релизами
В каждом проекте в какой-то момент требуется перейти к управлению релизами. Раньше этому в сфере 1С внимания не уделялось. И правда - зачем вводить целую процедуру, если в программе работает только бухгалтерия? С появлением ERP и систем с режимом работы 24х7 этот процесс стал крайне актуален. А зрелости в этом смысле у партнёров больше не стало. В последнее время ситуация исправляется, но ещё есть куда расти.
- Планирование релизов
- Сборка релиза и контроль качества
- Установка релиза и внедрение
- Наполнение бэклога
- Аварийные релизы
Подробно в 1С:ТКС прописаны регламенты по работе с этими процессами

Управление интеграцией. Устав
Устав проекта. Опошленный, растиражированный, важнейший документ проекта.
От чего он отталкивается? Зачем он?
На самом деле этот документ относится к «религиозным». Поэтому спорить о нем можно бесконечно и яростно.
К сожалению, вендор - фирма «1С» - не балует нас с вами культурными изменениями в среде партнёров, что выражено в том, например, что Устав проекта также остаётся весьма спорным документом. Спорным, мы имеем в виду, в смысле поводом поспорить.
Должен ли устав умещаться на одну страницу? Должен ли он содержать в себе элементы плана управления проектом? Требуется ли синем фиксировать риски?
Сегодня каждый РП сам отвечает на эти вопросы.
Наше мнение таково:
- Устав должен помещаться на 1-2 страницы, иначе его не прочитают те, кому он предназначен
- Устав должен распределять ответственность, чтобы спонсор видел, кому он вверяет судьбу проекта
- Устав не должен объединяться с планом управления, так как тогда любое изменение процедуры управления приведёт к анализу целесообразности проекта
- Устав является концентрацией самого важного для спонсора в проекте, что должна видеть и команда
- Устав может изменяться в ходе проекта, но любое изменение устава является критичным для проекта и вызывает его существенную корректировку вплоть до закрытия

Бизнес-кейс
Сам по себе термин бизнес-кейс появился в PMBoK 6th как средство изменения центричности руководителя проекта. Теперь при анализе изменений во главе угла не классический треугольник «стоимость - сроки - содержание» и его расширенные версии, а именно бизнес-ценность.
Однако, в текущей версии 1С:ТКВ такой документ не нашёл отопление.
И во многих компаниях, с которыми мы сталкивались, такая сущность не внедрена.

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

Но и дальнейшее не менее важно:
1. Анализ требований на соответствие бизнес-целям
2. Анализ запросов на изменения
3. Анализ методологии
4. Контроль успешности проекта
5. Анализ рисков
6. Контроль содержания для максимизации выгод

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