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

2023-03-30 11:47:14 Что такое продажа проектов и с чем ее едят

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

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

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

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

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

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

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

2023-03-27 14:56:41 План управления проектами - вот он, на полке лежит
Примерно такую фразу слышишь каждый раз, когда задаешь вопрос руководителю проекта. А во многих случаях делаются удивленные глаза и руководитель проекта задает вопрос: "А что это?"
На самом деле все руководители проектов строят так или иначе план управления проектом (ПУП). Кто-то делает это неформально, кто-то более формально, кто-то включает положения ПУП в Устав проекта. Почему так происходит?
1. Не все знакомы с теорией PMI о том, что план управления проектом - отдельный документ. Этот факт таков потому, что ПУП является "живым" документом, то есть он может меняться в ходе выполнения работ. Вы можете передоговариваться о каналах коммуникации, способах управления рисками, добавлять или убирать контрольные события - от этого не изменяются ключевые параметры проекта.
2. Многие живут в парадигме неформального заключения ПУП - на словах. Это бывает полезно, когда вы делаете небольшой проект, а процесс разработки ПУП занимает больше 40 часов руководителя проекта с учетом цикла выработки решений, согласований и прочих особенностей документооборота всех участвующих в проекте сторон. Тогда руководитель проекта должен осознавать, что источник плана управления проектом для него - юридический договор. Именно там содержатся процедуры и положения проекта, которые пожелали включить туда на этапе составления
3. В проектах часто приходится видеть, как положения ПУП включают в Устав проекта. Методологически это не совсем верно, но в каком -то смысле это частный случай п.2 - настоящим Уставом проекта для вас становится юридический договор, а то, что называется в проекте Уставом является по сути ПУПом. Полезно ли это? Конечно, полезно, если вы руководствуетесь положениями ПУП и они не противоречат договору

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

Если вы и ваша команда издали документ, пожалуйста, следите за тем, чтобы он применялся по назначению и актуализировался своевременно. Открыть/Комментировать

2023-03-11 06:16:55 Героизм руководителя проекта
В мире 1С руководитель проекта часто пытается выполнять сам несколько ролей или волею случая становится многостаночником.
Эта порочная практика имеет много Корней, и самый главный из этих Корней - в мире 1С руководителями проектов становятся вчерашние внедренцы. При этом они и раньше зачастую сочетали в себе и консультантов, и разработчиков, и методологов - и всех тех, кто нужен был в проектах, но бюджета на них не было.
С другой стороны, у руководителя проекта часто «чешутся руки» показать команде как и что делать правильно.
Избегайте этого.
Используйте аутотренинг: Рефлексируйте каждый вечер, отвечая себе на вопрос «Где я сегодня пытался что-то сделать?» и «Как мне научить команду делать так, как я хочу?»
Пробуйте разные подходы на следующий день: если позволяет время, рецензируйте и возвращайте на доработку, проводите индивидуальные беседы и семинары, моделируйте встречи. Делайте все так, как будто вы не знаете, что нужно делать Открыть/Комментировать

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

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

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

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

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

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

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

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

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