1С СППР, как инструмент по внедрению, разработке и сопровождению информационных систем

Публикация № 1177144

Методология - Управление проектом

Система проектирования прикладных решений (СППР) – инструмент от фирмы «1С», который позволяет проектировать конфигурации, вести по ним полную документацию в разрезе объектов системы, собирать требования на реализацию и выдавать на их основе детально описанные задачи программистам. Как правильно использовать СППР при работе с многосоставной командой, на конференции Infostart Event 2019 Inception рассказал генеральный директор компании «Иритум» Роман Кальмансон.

Тема доклада – система проектирования прикладных решений от 1С. Ей недавно исполнилось 6 лет. Эта система предназначена для ведения очень больших, сложных, длительных проектов большим числом людей и очень сложным составом команды.

 

Ключевая функция СППР

 

 

Главная цель СППР – собрать требования с заказчика и конвертировать их в задачи программистам. Требования заказчика могут быть очень неформализованные. В результате работы с требованием вы задаете задачу программисту, но сами программисты и разработчики в СППР не работают. 

Встает вопрос – как в большой команде собрать требования и конвертировать их в задачи? Собственно, СППР и решает эту проблему. Она построена на технологии структурного анализа и проектирования SADT – это значит, что после проведения структурного анализа и проектирования, делается попытка в объекте связать людей и машины.

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

Допустим, на одном крупном проекте с нами работали методологи, которые знали SAP, а мы собирались внедрять 1С. И методологи говорили: «Мы ваш 1С не знаем, у нас основной бэкграунд – бухгалтера и аудиторы». Их задачей было собрать проводки, которые нужно передать в SAP. Там огромная компания, огромное количество филиалов – методологи собрали три тысячи строк проводок в файле Excel. Потом к этой работе подключились методологи МСФО, и стало уже 10 тысяч строк проводок. Что делать разработчику в итоге с этими проводками? Как выкручиваться? Методологи сделали свою работу за полгода и ушли. А разработчики 1С остаются непонятно, с чем.

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

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

 

Работа в СППР и сферы ответственности

 

 

Посмотрите – обычная структура большой команды. 

  • Руководитель проекта – управляет проектом по теории управления проектами. 

  • Дальше работают методологи и аналитики. Обычно, они первые общаются с клиентом, получают огромные кипы документов по корпоративной учетной политике. Начинают во что-то это превращать.

  • ИТ-консультанты (проектировщики и консультанты) обрабатывают собранные требования – обычно ИТ-консультанты это подчиненные архитектора проекта.

  • Архитектор проекта определяет структуру проектного решения.

  • И разработчики это проектное решение реализуют. 

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

 

Бизнес-процесс работы в СППР

 

 

Рассмотрим общий бизнес-процесс работы в СППР. 

Руководитель проекта стартует бизнес-процесс, создает проект, шаги проекта. Все стандартно. И в конце принимает работу ото всей команды. 

В рамках проекта формируются требования, с которыми работают аналитики, методологи, консультанты, и в итоге все это попадает к архитектору проекта. 

Что делает архитектор проекта? Он – главный в рамках СППР. Он, как раз, и задает общий язык.

Для разработчиков используется словарь общего языка, который называется «Объекты метаданных». Это – объекты конфигурации. Они их понимают, они их знают. Это – без вопросов. 

Но методологи и аналитики не знают, что такое объекты метаданных. Для них используется второй словарь общего языка, который называется «Объекты методологии». Что входит в это понятие, рассмотрим чуть позже.

Я вернусь к исходному слайду.

 

 

Видите, аналитики собрали требования, которые надо детализировать до объектов методологии. Соответственно, объекты методологии должны конвертироваться в объекты конфигурации (в элементы справочника «Объекты метаданных»). И задача архитектора на проекте – написать этот общий язык и предоставить его людям. 

Справочник «Объекты метаданных» собирается практически автоматом из любой конфигурации 1С. Это объекты вашей конфигурации и их реквизиты. Но вы также можете заполнять этот справочник с нуля, если вы делаете проект с нуля (может быть, даже не на 1С). 

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

 

Задача архитектора на проекте с СППР

 

 

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

Дальше архитектор и разработчики начинают работать с функциями системы (здесь, собственно, и происходит привязка к объектам метаданных). Опять же, здесь на картинке показаны функции самой конфигурации СППР – как будто бы мы делаем проект по внедрению СППР. 

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

Тогда получается сквозное видение:

  • от требования, которое привязано к объекту данных;

  • объект данных ссылается на объекты метаданных;

  • а объекты метаданных указываются в каждом задании программисту. 

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

 

Интеграция СППР в ИТ-среду организации

 

 

Как внедрить СППР в вашу компанию?

  • Обычно у интеграторов и крупных внедренцев уже есть система управления проектами. Из нее делается выгрузка данных по проектам и шагам проектов. И они могут загружаться в СППР.

  • Также у интегратора обычно есть система типа Jira, где ведется разработка задач программистами. 

  • СППР очень удачно между ними ложится. Из СППР в Jira выгружаются задачи программистам. Там идет жесткая связка со всеми требованиями, ссылками на все объекты конфигурации и на переписку в том числе. Программист может видеть все, что мы обсуждали в рамках задачи СППР – ему не нужно ничего ни у кого спрашивать. Он не должен ничего спрашивать. Вы можете настроить такую интеграцию.

Если у вас нет СУП, нет Jira, то СППР с этими блоками прекрасно справится:

  • В СППР есть СУП – нельзя сказать, что идеальный и очень мощный, но управлять проектами там можно.

  • В другом блоке СППР можно проектировать и ставить задачи.

  • Также в СППР есть блок для ведения разработки программистами – там есть измерители трудозатрат.

Отдельный вопрос: «СППР только для работы с 1С?» Нет. Если вы можете взять выгрузить из SAP структуру объектов метаданных и их реквизитов, то вы можете работать и в SAP-овскими проектами, если они у вас есть. Вы можете хоть руками завести объекты данных. Нет проблем построить привычную среду.

 

Объекты методологии

 

 

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

На слайде собраны объекты методологии из конкретного примера. 

Если вы посмотрите, здесь вам все знакомо. Например, одной из групп справочника «Объекты данных» будет «Бизнес-модель» – в ней будут храниться описанные бизнес-процессы. 

В группе «Аналитики данных» находится объект методологии «План счетов». Это означает, что проект был по учетной системе. Если бы вы делали проект по системе CRM, то там не нужен план счетов. Что там нужно, а что не нужно, определяет архитектор в зависимости от того, какой проект делается.

Еще я вам рекомендую обратить внимание на группу «Выходные данные проекта», которая является оглавлением проектного документа. Одна из конкретных жалоб, что в СППР никак не помогает делать проектные документы. В ходе проекта очень часто происходит перетасовка – сначала решили делать так, потом – иначе. Меняются связки – эти объекты создаем, эти не создаем. Проектные документы нужно перезаполнять снова. И люди хотели бы, чтобы СППР выдавала уже готовые проектные документы. Если вы работаете по госконтракту, там обычно ГОСТы. Может быть, проектные документы заложены в договоре. И этот момент мы рассмотрим чуть позже.

 

Описание модели проектирования в СППР

 

 

Теперь смотрите – общая схема модели проектирования в СППР.

Привычная каскадная водопадная модель:

  • Проектирование начинается с обследования – методологи собирают требования, которые сначала заказчик дает размытые. 

  • Требования нужно детализировать. Надо разбираться – какая функция связана с требованием, какие объекты. Насколько детализировать, когда остановиться? Это определяет, как раз, архитектор, когда задает вам список объектов данных (объектов методологии). Каждое требование должно быть детализировано до плана счетов (если требование касается плана счетов), или до какого-то первичного документа (если он решает эту задачу). Пока такой прямой привязки нет, работы не сдали. Эта формализация работ очень важна. Вы можете заворачивать и аналитиков, и методологов, пока они не обработали все требования, не привязали их к объектам данных.

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

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

  • Вы берете объектную модель метаданных (допустим, ERP), понимаете, достаточно ли у вас функциональности для решения задач клиента, или нет. Если нет – архитектор дорабатывает объекты метаданных. Они также связываются с требованиями для сквозного отслеживания.

  • В результате, разрабатываем задачи – конечный итог работы СППР. 

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

  • В результате вы должны пройти контроль качества проектирования непрограммного кода – в СППР есть функция «Контроль качества проектирования». 

  • И на выходе у вас будут проектные решения.

 

Схема модели проектирования

 

 

Здесь на этом слайде в очень простой форме приведена схема модели проектирования. 

Вы ищете в системе все входы и определяете, во что это в результате выльется. 

А вот этот конвертер «Бизнес-процессы» (то, что вы делаете на проекте), конвертирует вход в выход для клиента. 

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

В этом блоке СППР эту информацию и записывает.

 

 

Допустим, вы построили работу в СППР – все работают, формализовано передают по цепочке свои участки работы. 

Обратите внимание, здесь красным выделена зона возможной работы Agile и Scrum. Когда она начинается? Когда вы архитектору и разработчикам передаете все полностью собранные данные. Им не нужно никуда обращаться, никуда бегать, все собрано в системе, включая перечень объектов, описание, методологические документы, документы заказчика – все под рукой. Вот тогда может начаться нормальный Scrum и Agile. Вы уже разрабатываете функции своей системы.

 

Модель оценки времени и затрат по COCOMO II

 

 

А теперь интересный момент, который связан с вопросом – как же выдавать проектные документы? 

Желательно этот момент автоматизировать, потому что там толстенные тома, которые никто не читает. В больших проектах, особенно, если вы делаете документацию по ГОСТам, назначение этих документов в том, что они определяют, кто будет «сидеть», и с кого будут брать деньги. Особенно, если вы работаете с госконторами. 

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

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

Что можно сделать? Я вам уже говорил про структуру проектных документов. Она очень помогает оценивать по методике COCOMO. Что такое COCOMO? Это когда в 60-х годах один американец собрал статистику по количеству строк программного кода в своих проектах (всего у него был 161 проект), и получил статистическое знание, сколько примерно строк программного кода займет следующий проект.

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

 

 

Метод COCOMO общеизвестен, но он предназначен для разработчиков – он считает строки программного кода. А команда-то у вас гораздо больше – там методологи, аналитики, какой у них программный код? У них нет программного кода. Но, тем не менее, у них есть формализованный результат работы. Они выдают кипы документов – это их «псевдокод». Их базис – структура проектных документов (оглавление, тексты, рисунки, таблицы), количество строк в них. И затраты их времени вы тоже можете оценивать формализовано по модифицированному COCOMO. У программистов – строки программного кода, а у этих – строки проектных документов.

Очень существенный момент – как бы СППР вам в этом помогло?

Вы, наверное, поняли механизм работы COCOMO – получили число строк кода, конвертируете в затраты времени и рассчитываете стоимость проекта. Здесь – то же самое, только в базисе строки проектных документов.

 

 

А делается это вот так. 

На слайде показано оглавление одного из проектных документов. Вы это оглавление заносите в качестве элементов иерархии справочника «Объекты данных». Выделяете в этом справочнике группу «Выходные проектные документы». Внутри нее – подгруппы под каждый вид документов, далее еще подгруппы под каждый отдельный документ, а внутри уже этих подгрупп как элементы справочника строки оглавления проектного документа.

Если будет принято решение включать в базис COCOMO текстовое содержание, таблицы, графические объекты выходных проектных документов, то тогда строки оглавления проектного документа также следует делать группами справочника «Объекты данных», а внутри них размещать имена таблиц, графических объектов и абзацев текста. 

Текст самого проектного документа можно набирать по абзацам как текстовое поле элемента справочника «Объекты данных»

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

Именно так вам может помочь методика COCOMO. Иначе получается, что проектные документы надо писать параллельно – или в Excel или в Word. Это очень трудоемко. Здесь же вы можете попытаться сделать выгрузку. Кто может – сделает сразу хороший готовый формат, кто-то отдаст дизайнеру, чтобы все красиво оформить. Но там уже не надо писать текст, все в уже СППР набрано, структурировано, описано – вы это уже сделали в ходе проекта.

 

Контроль качества проектирования в СППР

 

 

И вот очень важный элемент, который есть в СППР, – вы можете проверить качество проектирования системы. Не программного кода, а проектирования. В СППР нет программного кода, там вообще не работают разработчики. 

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

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

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

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

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

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

 

Вопросы

 

  • Здесь речь идет о проектах, а насколько применима СППР в рамках постоянной разработки внутри конкретной компании? Не проектные, а оперативные задачи. Насколько возможно применение этой системы для документирования и контроля оперативных задач?

  • Можно, пожалуйста. Вы можете использовать СППР для управления сопровождением системы. Там есть блок сбора ошибок – собираются тикеты и ведется фиксация исправлений. Но чтобы работать с разработкой в целом, вам нужно описывать справочник функций системы. А представьте, как вы опишите функции системы ERP? Это очень трудоемко. 

  • Насколько, по-вашему, реально вести полностью разработку в СППР?

  • А сколько у вас людей на это есть? Если вам не выделяют людей, в этом нет смысла.

  • Людей мало.

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

  • Тогда вопрос – какую другую систему можно применять для контроля разработки? Не глобально, для ведения проектов, а именно для контроля разработки с точки зрения 1С, с точки зрения решения задач на уровне конфигурации.

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

 

  • На одном из слайдов вы сказали, что можно применять Scrum и Agile. А где здесь участвует владелец продукта, который должен ставить задачи в бэклог и как это применимо с использованием СППР?

  • Вообще-то задача – это результат Agile в СППР. Agile начинается, когда методологи и бизнес-аналитики собрали данные. У них есть определенный набор объектов, набор требований, и из этого делаются задачи. Но прежде чем делать задачи, надо понять, покрывает ли ваша система по функциям собранные процессы и требования или нет? Здесь Agile в таком смысле – это не Agile по разработке. Получается, что здесь задачи сформированы, и они должны передаваться в другую систему, где вы как-то отслеживаете Agile для программистов. Вообще для задач в СППР аналитики достаточно – вы можете проставить для них какие-то обозначения через доп. реквизиты, доп. сведения, чтобы организовать ход задачи внутри СППР. Пожалуйста.

  • Получается, что здесь владелец продукта будет взаимодействовать с методологами и ставить задачи в СППР? 

  • Если вы работаете в СППР, вы должны взаимодействовать со всей линейкой команды – от методологов, до проектировщиков и разработчиков. Если неполное взаимодействие – зачем СППР? Вы с ним будете мучиться, как многие мучаются. Скорее, вы будете там отслеживать те требования, которые были сформированы методологом, и их ранжировать. Не он сам, потому что необходимо связывать объекты данных с объектами системы, которые методолог, скорее всего, не знает.

 

  • Вы показывали три этапа – система управления проектами, 1С:СППР и Jira. Насколько возможно интегрировать в качестве первого и третьего этапа систему 1С:Документооборот? Просто мы сейчас ведем весь учет наших проектов и задач в системе 1С:Документооборот. Очень удобно, мы ее немного под себя доработали. Я знаю, что СППР интегрируется с 1С:документооборотом. Насколько это будет типовое решение? Не придется ли какие-то доработки делать? Насколько объем доработок будет большим?

  • У вас в Документообороте собираются требования?

  • Сейчас в Документообороте ведутся все проекты. Требования мы там не ведем. Как раз для того, чтобы собирать требования, я и хотел использовать СППР.

  • Но вы сказали, что вместо Jira используете Документооборот, что там вы хотите ставить задачи программистам. Я даже не пытался СППР интегрировать с Документооборотом, но то, что вы описываете, звучит, как уже хвостик процесса – вы уже собрали задачи. СППР нужен для того, чтобы к задачам были привязаны объекты метаданных, объекты данных, требования, процессы и шаги проектов. Получается, что вам этот кусок не нужен. Зачем тогда вам гнать в СППР задачи? Вы и в документообороте можете ошибки регистрировать. Создайте документ «Регистрация ошибки» и используйте его.

  • Но система документооборота не предназначена для регистрации ошибок.

  • Система документооборота не предназначена и для сбора задач. Я думаю, что интеграция с документооборотом слишком усложнит эту систему. По логике, источником из Документооборота будет требование. Но если вы фиксируете в Документообороте ошибки, значит, вы занимаетесь сопровождением системы, вам нужно реакцию программиста – исправление ошибки. Получается, у вас уже есть в Документообороте регистрация ошибок, а из СППР вы хотите получить реакцию программиста на поставленную задачу. По описанию это выглядит трудоемко. Если бы вы сделали это целиком на стороне документооборота, было бы проще. СППР для вас будет тяжелым.

 

  • От какого числа человек в команде есть смысл внедрять СППР?

  • Я думаю, это несколько десятков человек – порядка 20-30 человек и более в команде. Важнее не количество, а структура команды, чтобы там была вся цепочка – методологи, аналитики, архитектор, проектировщик, консультанты. И только в конце разработчики. Для сборной солянки из 6-ти человек может быть и выгодно. Но команде, состоящей только из разработчиков, СППР не нужен.

 

****************

Данная статья написана по итогам доклада (видео), прочитанного на конференции INFOSTART EVENT 2019. Больше статей можно прочитать здесь.

В 2020 году приглашаем всех принять участие в 7 региональных митапах, а также юбилейной INFOSTART EVENT 2020 в Москве.

Выбрать мероприятие

Специальные предложения

Оставьте свое сообщение

См. также

Управление ИТ-проектами, базовый курс, 3 поток. Онлайн-курс с 15 мая по 1 июля 2019 Промо

Управление проектом Бесплатно (free)

Отличительная черта курса - органичное сочетание трех вещей: - Теория проектного управления (PMI®+Agile Alliance+Российские ГОСТ+Методологии от 1С)  - Опыт внедрения продуктов 1С (опыт франчайзи и успешных компаний + тренды Infostart Event и Agile Days) - Разбор реальных проблем и рекомендации экспертов по проектам слушателей Мы будем фиксироваться на тех инструментах, которые реально оказываются полезными в практике  руководителей проектов внедрения. 

04.04.2019    12327    67    Infostart    18    

Есть ли жизнь после внедрения, или упрощаем работу в сопровождении

Управление проектом Бесплатно (free)

Из-за отсутствия грамотных правил разработки на этапе внедрения сильно усложняется работа по поддержке и развитию типовых доработанных конфигураций. О некоторых правилах и подходах в разработке, которые помогут специалистам сопровождать внедренное решение, на конференции Infostart Event 2019 Inception рассказал разработчик компании «Инвестиционная группа Абсолют» Алексей Степаненко.

08.06.2020    3568    0    stepan96    11    

Добрый великан

Управление проектом Бесплатно (free)

Руководители проектов определяют наше настоящее, каким оно будет?! Ответ прост - таким, каким и сам РП.

25.05.2020    4370    0    sapervodichka    1    

Почему Scrum не работает в проектах 1С

Управление проектом Agile (XP, SCRUM, Канбан) Бесплатно (free)

Более точная формулировка заголовка, пожалуй будет такой -  Почему Scrum в чистом виде плохо работает в проектах внедрения продуктов 1С.

18.05.2020    9621    0    MariaTemchina    33    

Кто здесь? Или как проводить онлайн-совещания

Управление проектом Управление командой Бесплатно (free)

На самом деле, переход рабочей жизни в онлайн обладает некоторым количеством плюсов. В частности хочется верить, что формальный контроль “отслеживаем кто сколько часов проработал, проверка, что сотрудники на месте и все чем-то заняты” заменится фактической отчетностью “по результатам”.

23.03.2020    4753    0    MariaTemchina    24    

4 причины, почему проекты никогда не завершаются в срок

Управление проектом Бесплатно (free)

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

03.03.2020    5503    0    VLikhobabin    44    

7-ой PMBoK - конец классического проектного управления? Часть 1-ая

Управление проектом Бесплатно (free)

В новой версии PMBoK традиционные рекомендации по управлению проектами перевернуты с ног на голову. В этой статье расскажу свою точку зрения, в чем, на мой взгляд, основные изменения, и как это может сказаться на проектах внедрения…   

23.01.2020    10453    0    MariaTemchina    8    

Ошибки управленцев: как топ-менеджеров убивает перфекционизм Промо

Управление проектом Бесплатно (free)

В преддверии онлайн-конференции «Гнев и слезы руководителя» мы решили заранее познакомить нашу аудиторию со спикерами, причем сделать это через видео-истории. Начнем с видео-приглашения от Миланы Джиджоевой и ее виденья диджитализации рекрутинга в России.

24.01.2019    9380    0    user809424    11    

Про одну Тётю

Управление проектом Бесплатно (free)

Суровое челябинское распределение ресурсов

24.12.2019    6212    0    1c-intelligence    32    

20 мыслей об ИТ-проектах. Мысль №3. "О правильных требованиях к системе"

Управление проектом Бесплатно (free)

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

14.10.2019    5563    0    chavalah    16    

Незакрытый проект на 1000 часов

Управление проектом Россия Бесплатно (free)

История о незакрытом проекте, о бессонных ночах, о попытках его выгрести, о бесплатной работе, о вселенской боли.

19.09.2019    11574    0    ogroup    163    

Проблемы внедрения 1С:ERP на крупном предприятии Промо

Управление проектом Бесплатно (free)

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

29.06.2017    33305    0    1СERP    79    

Стратегия выживания в корпоративных войнах

Управление проектом Бесплатно (free)

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

16.09.2019    8931    0    GSoft    15    

Мастер-класс СППР

Управление проектом СППР Бесплатно (free)

Сергей Наумов, в прошлом разработчик подсистемы бюджетирования в конфигурации «1С:ERP», на мастер-классе конференции INFOSTART EVENT 2018 EDUCATION поделился опытом управления проектами с помощью «1С:Системы проектирования прикладных решений» и показал, как использовать эту программу в работе над разными задачами: для сбора, классификации и хранения требований; для управления разработчиками и консультантами; в качестве системы документирования; в качестве баг-трекера на этапе опытно-промышленной эксплуатации.

30.08.2019    10552    0    SergeyN    6    

Эволюция пользовательской документации 1С в производственной компании

Пользователю системы Управление проектом Бесплатно (free)

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

20.08.2019    8003    0    KoldunOne    7    

История одного неуспешного проекта Промо

Управление проектом Бесплатно (free)

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

09.06.2017    30245    0    1СERP    175    

Быстрый старт: минимальный набор автоматизации типовых процессов

Управление проектом 1С:Франчайзи, автоматизация бизнеса Бесплатно (free)

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

16.08.2019    7713    0    Hissin    18    

Внедрение решений: как выполнять все обязательства в срок в условиях ограниченных ресурсов

Управление проектом Бесплатно (free)

Многие менеджеры вынуждены работать в условиях многоклиентской среды с ограниченными ресурсами. И вовремя сдавать проекты в таких условиях сложно. Как добиться того, чтобы поставки делались без нарушений сроков, рассказал гостям и участникам конференции Infostart Event 2018 управляющий партнер BIPULSE.RU Алексей Васильев.

24.06.2019    6223    0    sbase    9    

Цифровая трансформация. Будущее учетных систем

Управление проектом Россия Бесплатно (free)

О цифровой трансформации слышали все, но немногие в этом разбираются. Что она собой представляет, какие несет изменения, на что надо обратить внимание айтишникам и 1С-никам, рассказал на конференции руководитель департамента автоматизации строительных организаций компании «Первый БИТ» Иван Аверьянов.

19.06.2019    9508    0    FB_10160810658600104    62    

Такие разные франчайзи. Часть вторая: Особенности реализации крупных проектов, Глава 1. О людях Промо

Управление проектом Бесплатно (free)

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

18.04.2017    31068    0    1СERP    189    

Риск - благородное дело!.. Часть первая

Управление проектом Бесплатно (free)

Несколько рекомендаций по управлению рисками в ИТ-проектах.

18.06.2019    7046    0    MariaTemchina    8    

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

Управление проектом Бесплатно (free)

В своей публикации “Устав писать Устав” я много рассуждала о том, как полезно умение договариваться на берегу. Как известно, у каждого человека в голове своя картина мира. В целом, многие конфликты в ходе проектов происходят как раз из-за конфликта ожиданий, и из-за нечетких договоренностей, кто чем должен заниматься.  

31.05.2019    8193    0    MariaTemchina    23    

Как мы со Стасом завод за 2 месяца автоматизировали

Управление проектом Бесплатно (free)

Мой опыт быстрого внедрения.

14.05.2019    10648    0    1c-intelligence    121    

Такие разные франчайзи, или как мы делаем большие проекты на 1С. Часть первая: ты помнишь, как всё начиналось Промо

Управление проектом Бесплатно (free)

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

10.04.2017    30939    0    1СERP    107    

Устав писать Устав

Управление проектом Бесплатно (free)

Ответы на вопросы про то, нужен ли Устав для проектов автоматизации, и если нужен, то зачем?

06.05.2019    7063    0    MariaTemchina    8    

Как сжать время?

Управление проектом Личная эффективность 1С:Франчайзи, автоматизация бизнеса Бесплатно (free)

Как, и зачем измерять задачи в чем-то, помимо часов.

04.05.2019    8559    0    1c-intelligence    39    

Путь джедая в управлении проектами 1С: умение быть, а не казаться

Управление проектом Бесплатно (free)

Чем руководитель проекта “на бумаге” отличается от “настоящего” руководителя проекта, умеющего направлять команду и выдавать ценный результат?

15.04.2019    10966    0    MariaTemchina    15    

Мотивация персонала в фирмах франчайзи: а она работает? Промо

Управление проектом Бесплатно (free)

Думаем, что практически любого работающего человека интересует вопрос мотивации. Этой проблемой в одинаковой степени озабочены работники и работодатели: как мотивировать людей, сколько платить, как платить, какая часть оплаты должна быть фиксированной, а какая зависеть от результата работы, как это всё повлияет на результаты работы, стоит ли быть строгим и дотошным руководителем или нужно активно делегировать полномочия подчиненным. ВЦ "Раздолье" провело небольшое исследование на тему мотивации и вот его результат. Автор статьи Андрей Мироненко.

03.04.2017    41609    0    1СERP    231    

20 мыслей об ИТ-проектах. Мысль №2. "С какой стороны подойти к новому проекту?"

Управление проектом Бесплатно (free)

Продолжаем серию статей из цикла “20 мыслей об ИТ-проектах”. Сегодня мы поговорим о том, с какой стороны подойти к новому проекту. Такой вопрос возникал у каждого, кому приходилось выступать в роли руководителя проектов, особенно первый раз. Да и для опытных РП некоторые проекты вызывают аналогичный вопрос.

13.02.2019    7896    0    chavalah    22    

Стыд и скрам - Чему нас учит Scream Guide

Управление проектом Бесплатно (free)

Название "Scream Guide" можно вольно перевести на русский как “Вопль ужаса от того, как Scrum применяют на практике”

12.02.2019    9404    0    MariaTemchina    20    

Бизнес, не горюй

Управление проектом Бесплатно (free)

Про цели автоматизации.

04.02.2019    9593    0    1c-intelligence    64    

Про спагетти, или как исследовать бизнес-процессы организации Промо

Техническое задание Управление бизнес-процессами (BPM) Управление проектом Бесплатно (free)

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

23.02.2017    27019    0    Gavrik    10    

Лучший домик для поросенка, или Что нужно знать руководителю проекта внедрения

Управление проектом Бесплатно (free)

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

31.01.2019    7942    0    MariaTemchina    0    

Что немцу хорошо, то русскому... Как минимум, небезынтересно. Продолжаем тему Канбан

Управление проектом Бесплатно (free)

Пользуясь несовпадением рождественских каникул в России и Германии, решила познакомиться с тем, как организована работа разработчиков в одном немецком банке. Сразу оговорюсь: еще давно, со времен совместных яхтенных плаваний с немцами, я противник четких стереотипов из серии "все русские всегда...." или "все немцы обязательно..." (пропущенные места предлагаю читателям заполнить самим в меру своей испорченности).

14.01.2019    9733    0    MariaTemchina    13    

20 мыслей об ИТ-проектах. Мысль №1. "О незаменимых людях"

Управление проектом Бесплатно (free)

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

10.01.2019    12195    0    chavalah    123    

10 способов злоупотребления сотрудниками своим служебным положением и методы борьбы с ними с помощью учетной системы Промо

Управление проектом Бесплатно (free)

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

17.06.2016    39502    0    raiml    37    

Практические вопросы внедрения и развития автоматизации склада Промо

Управление проектом Бесплатно (free)

Мне, как одинэснику, не приходилось заниматься какими-то узкими задачами «от сих до сих». Вся моя профессиональная деятельность, как одинэсника, была всегда связана с очень широким кругом вопросов. Наверное, потому, что я работал, в основном, в малых компаниях, где приходилось работать над всем спектром вопросов.

26.12.2014    43963    0    CheBurator    64    

Практика пуска склада продуктов питания Промо

Бухгалтерский учет Управление проектом Оптовая торговля, дистрибуция, логистика 1С:Франчайзи, автоматизация бизнеса Бесплатно (free)

Описывается опыт пуска склада (охлажденная и замороженная продукция) с точки зрения IT. Со временем из складского подразделения была создана компания, которая оказывает логистические услуги (3PL-оператор) сторонним Клиентам.

1 стартмани

14.09.2015    35811    0    axxell    15