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

Публикация № 1825979 14.03.23

Анализ и управление - Управление проектом

Гибридные проектные технологии позволяют сочетать стандартизированные подходы управления проектами с гибким уточнением требований для проектных и технических решений. О том, как оптимизировать управление множеством разноплановых проектов в компании-интеграторе, на конференции Infostart Event 2021 Moscow Premiere рассказал руководитель отдела «Корпоративные финансы» WiseAdvice Сергей Наумов.

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

 

Объект исследования, на базе которого я внедрял эту гибридную проектную технологию – это мой отдел «Корпоративные финансы»:

  • его численность свыше 30 человек;

  • в данный момент мы выполняем 11 проектов;

  • общий объем портфеля проектов – свыше 700 миллионов.

В общем, объект исследования достойный.

Все, про что я буду рассказывать, внедрялось на базе компании WiseAdvice IT. Это – компания в группе WiseAdvice, которая занимается оказанием услуг клиентам.

У нас еще есть WiseAdvice Tech, которая работает над внутренней автоматизацией, но сейчас речь не про них, а про заказные проекты.

 

Проектные технологии: что это, и зачем их разрабатывать?

 

 

Вы все знаете, что есть два основных подхода к организации проектной технологии:

  • так называемые гибкие подходы;

  • и предиктивные подходы (их еще называют «водопадными»).

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

Рассмотрим элементы проектной технологии применительно к оказанию проектных услуг, к внедрению автоматизированных систем:

  • Во-первых, нам нужно понять, как спланировать проект и посчитать план.

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

    • программный продукт, выбранный для автоматизации;

    • пользователи, которые умеют пользоваться программным продуктом;

    • и инструкции, по которым пользователи используют программный продукт.

  • Конечно, нужно понимать, какие работы нужно выполнить внутри каждого этапа.

  • Каким будет результат каждой работы, и как определить требования к этому результату.

  • И, конечно, как это все задокументировать. Не все документы одинаково полезны. На некоторых проектах те или иные виды документов (например, техпроект) могут не применяться. А другие – наоборот, могут быть необходимыми и т.д.

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

Все это в совокупности и есть – проектная технология.

 

История разработки проектной технологии отдела

Сначала на этом слайде я написал много классных умных слов – оптимизация, повышение эффективности и т.д.

Потом все удалил и написал то, что действительно меня волновало, когда я начинал создавать свою проектную технологию. Меня волновали всего две простые вещи:

  • Как избежать ошибок при вступлении в проект.

  • И как избежать ошибок при его выполнении.

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

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

У меня очень большая личная боль – в день приходит два-три-четыре плана на согласование. Каждое ТЗ, которое мне приходит на вход, содержит по 150-500 страниц. Вдумываться в каждую работу я не могу. И каждый раз анализировать все материалы и сопоставлять план, разработанный руководителем проекта, с этими материалами – нереально.

Можно рассчитывать план для каждого клиента, выбирая уникальный состав работ. А можно брать стандартные планы.

Но мы для всех своих проектов не можем выбрать стандартные планы, потому что мой отдел занимается автоматизацией:

  • бюджетирования,

  • казначейства,

  • РСБУ,

  • управленческого учета,

  • МСФО.

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

А план-факт нужен в конце января, если это – месячный план-фактный анализ. Или в конце квартала, если это – квартальный план-фактный анализ.

Следовательно, нам удобнее пройти все этапы и подготовить систему для планирования, а потом спокойно пройти все этапы и подготовить систему для план-фактного анализа.

А в РСБУ наоборот – в РСБУ нужно сделать все, и желательно к 1 января. Можно, конечно, запускаться и в другие периоды – такие кейсы в нашей компании тоже есть, но, как правило, это стрессовые кейсы. Самое удобное – запуститься 1 января и спокойно сдать отчетность.

Т.е. не получается создать один шаблон плана проекта для каждого случая.

 

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

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

Какие это параметры?

  • Целостное проектирование (да/нет):

    • либо мы создаем техническое задание, модельный пример, технический проект на все очереди;

    • либо включаем этап проектирования внутрь очереди и очереди компонуем между собой.

  • Количество очередей разработки.

  • Количество очередей запуска.

  • Наличие методического проекта (да/нет).

Для примера, если мы говорим, что у нас:

  • количество очередей разработки – 1;

  • количество очередей ввода в действие – 1

Мы получаем простой «водопад».

Но может быть и интереснее ситуация:

  • если у нас количество очередей разработки – 3;

  • а количество очередей ввода в эксплуатацию – 2.

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

Эту идею я подсмотрел в «1С:Технологии корпоративного внедрения 2.0» (1С:ТКВ) и лучшее применил у себя.

 

Обзор разработанной технологии

 

Физически результат моей работы по внедрению проектной технологии представляет собой описанную проектную технологию на базе Confluence (пример на экране).

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

 

Так выглядит структура информационных систем нашего отдела:

  • Microsoft Project мы используем для расчета плана.

  • Confluence используем, чтобы вести документацию, все материалы по проекту, для управления требованиями и построения проектной аналитики.

  • В Jira мы ведем ближайший этап. Jira – классический трекер задач по проекту. Соответственно, все более детальные задачи, чем описаны в Project – они в Jira.

  • И недавно мы еще СППР интегрировали с Confluence, и для управления требованиями применяем СППР.

 

 

На слайде показан пример стандартного плана в MS Project.

У меня есть шаблон в MS Project, который использует руководитель проекта. Если проект разбивается по очередям, для него все равно используются элементы этого шаблона, но они компонуются уже в очереди.

Сам этап у нас описывается в Confluence – там хранится документация по этому этапу, все проектные документы, протокол совещаний и т.д.

А детальные задачи ведутся в Jira.

Верхний уровень задач Jira соответствует Project. Т.е., например, когда мы планируем план в Project, мы точно знаем, что нам нужно провести, например, 15 интервью. Но о том, что интервью нам нужно провести с Иваном Ивановичем и Марией Петровной, мы пишем в Jira.

 

Confluence

 

 

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

Мы не пишем документы в Word, а потом загружаем в Confluence. Мы делаем наоборот –пишем документы в Confluence и экспортируем их в Word.

Почему это удобно? В Confluence много всяких фишек, например:

  • можно делать отдельные страницы на те или иные разделы документов;

  • его удобно редактировать совместно;

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

 

 

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

 

 

Еще одно нестандартное применение Confluence – мы его применяем как систему проектной аналитики.

Слева на слайде показан пример статистики по требованиям – сколько требований по каким функциональным областям мы собрали.

А справа – реестр требований, на основании которого статистика строилась.

 

 

Confluence настолько удобен для построения таких аналитик, что я применил Confluence даже для подготовки к Инфостарту.

На экране вы видите отчет по подготовке докладчиков секции «Управление проектом».

 

 

Основные плагины, которые мы использовали – это:

  • «Свойства страницы»

  • «Отчет по свойствам»

  • «Фильтр таблиц»

  • «Сводная таблица»

Всего четыре плагина. Они очень простые.

Т.е. Confluence – это не просто корпоративная Wikipedia, где мы можем редактировать страницы и загружать информацию.

С помощью плагина «Свойства страницы» мы можем строить статистику. С его помощью мы можем описывать для страниц различные значения свойств, которые потом можно выводить в список.

А по списку уже потом можно строить различные аналитические отчеты с помощью сводных таблиц.

 

Единственное – мы не смогли сделать простыми плагинами построение матрицы трассировки требований.

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

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

Возможности открываются очень широкие, любые аналитические отчеты несложно делать.

 

Jira

 

 

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

Единственное, что отмечу – перед тем как использовать Jira, нужно обязательно договориться о типах задач.

У нас в компании Jira использовалась много лет. Там когда нажимаешь «Тип задачи» – вываливается список на два экрана. Сотрудники проектных отделов в этом путались, было непонятно, какой конкретно тип задачи указать:

  • я взял всего семь типов;

  • описал, на каком этапе проекта какой тип и как применяется;

  • и главное, отметил, кто может вводить задачу такого типа – тогда все стало прозрачно и очевидно.

 

 

Когда мы спланировали проект, но еще не понимаем всех детальных задач, мы в Jira используем плагин, который называется «Структура» – он позволяет делать дерево как в Project.

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

Кто-то может задать вопрос – почему бы сразу не составлять план проекта в Jira? Потому что Jira – это веб-интерфейс, и это дольше, чем в Project. В Project быстрее получается. А во-вторых, у Project более интересные инструменты для балансировки ресурсов, для проверки сбалансированности планов.

Но в Jira классно сделан план-факт. Поэтому мы используем два инструмента.

  • Сильные стороны Project мы используем для планирования.

  • Сильные стороны Jira используем для план-фактного анализа.

Плагин «Структура» может показаться сложным, но справа на слайде показано, как он настраивается. Мне тоже сначала показалось сложным, но я за пару часов справился и сделал всю структуру, которая мне нужна для работы.

 

Интеграция с СППР

 

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

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

Поэтому, чтобы работать с требованиями, мы прикрутили к Confluence СППР. Требования вводим в СППР, и они автоматически в Confluence экспортируются. И наоборот.

 

Интегрируется очень просто. Интеграцию я сделал в качестве хобби за выходные, чтобы проверить свою гипотезу, что 1С можно интегрировать с Confluence по API.

 

 

Если кому-то интересно – вот, пожалуйста, готовый кусок кода. Пробуйте, интегрируйте.

 

Параметрическая настройка технологии под особенности будущего проекта

 

 

Внутри проекта мы выделили минимальный значимый результат работ для клиента.

  • Модель AS IS – описание как есть.

  • Модель TO BE – схема функциональной структуры как должно быть.

  • Требования пользователей,

  • Модельный пример – описание того, как это может быть сделано в системе. С оговорками, что типовая сейчас нам это не позволяет, но мы ее доработаем.

  • Требование на функциональный разрыв.

  • Проектное решение – как будет выглядеть процесс после выполнения всех доработок.

  • Техническое решение – описание конкретной доработки – документа или интеграционного механизма.

В верхней части слайда приведено три разных схемы:

  • Первая – это классический «водопад».

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

  • Третий вариант – это когда мы работаем по очередям.

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

 

Таким образом, аналитики выполняют одну и ту же работу, но в зависимости от того, какую схему выполнения проекта выбрал руководитель, она может по-разному документироваться.

На слайде представлен пример того, какие модели мы строим на основании каких требований, и как они могут документироваться.

 

Ключевые результаты каждого из этапов

 

Немного расскажу про результаты каждого из этапов работ.

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

Модель AS IS по моему глубокому убеждению нужна подрядчику для ввода нового специалиста в курс дела, чтобы он понимал объект автоматизации, понимал, из каких предпосылок были выбраны те или иные проектные решения.

Чтобы построить хорошую модель AS IS, нужно правильно оформлять протоколы интервью.

Кто-то может подумать – что там протоколы писать? Мы поговорили и записали.

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

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

 

 

Здесь показан пример страницы требования.

На подчиненные страницы в Confluence мы пишем все требования, которые собрали. А с помощью плагина «Отчет по свойствам страницы» формируем протокол интервью – собираем в единый реестр все требования, которые в рамках этого протокола были собраны.

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

 

 

Модель TO BE – это схема функциональной структуры, которая описывает, какой процесс каким образом будет автоматизирован.

А что касается модели AS IS – при правильно оформленных протоколах вы просто их немного переформатируете и получаете модель AS IS. Не нужно делать двойную работу. Правильно оформляя протоколы, вы убиваете сразу двух зайцев.

 

Требования на разрывы, проектные и технические решения

 

Требования на разрывы – это второй уровень требований, который мы используем в своей работе.

В нашей технологии два уровня требований.

  • Первый – это пользовательский уровень требований, которые мы собираем в рамках протоколов.

  • И второй уровень требований – это требования на разрывы, которые выявляются по итогам моделирования и уточняют пользовательские требования. Либо может быть выявлен разрыв, который ранее в пользовательских требованиях не был, но при моделировании его увидели. Т.е. аналитик демонстрирует пользователю систему на данных пользователя (не на данных стандартной демобазы). Это позволяет проверить, что система работает так, как нужно пользователю. А там, где она работает так, как не нужно пользователю, регистрируется требование на разрыв.

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

Проектное решение – то, что готовится в рамках разработки технического задания. Т.е. техническое задание – это набор проектных решений.

  • Во-первых, это описания процессов TO BE – как будет выглядеть процесс.

  • Это описание шагов.

  • Требования к объектам автоматизированной системы, поддерживающих этот процесс.

 

 

Для моделирования процесса TO BE мы разработали очень интересное решение – мы взяли практически стандартный BPMN, но сделали небольшое добавление.

  • Красные объекты – это объекты новые.

  • Желтые объекты – это объекты с доработками.

  • Зеленые – это типовые.

Посмотрев на такую схему процесса, вы сразу можете понять, насколько процесс ложится или не ложится на типовое решение.

 

 

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

Понятно, что в техническое решение входит стандартный набор пунктов, уже привычный для отрасли – это

  • Прототипы интерфейсов

  • Перечни реквизитов и т.д.

 

 

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

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

 

ИТ-поддержка технологии управления проектом. Два бэклога

 

 

И самое интересное – это как выглядит процесс разработки.

Мы используем два бэклога.

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

А если робот будет весь зализанный, безопасный, плюшевый – родители захотят такого купить? Да, ведь он безопасный. А ребенку это будет интересно? Вроде не очень.

Это – классическая проблема, которая выявляется при создании автоматизированной системы.

То же самое – представим себе прайс-лист с перечнем цен. Если пользователю нужно забивать каждую строку в регистр сведений, пользователю это понравится? Вряд ли. Будет саботировать процесс.

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

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

Поэтому мы используем два бэклога:

  • Первый бэклог – это бэклог проектных решений, т.е. процессов.

  • Второй бэклог – это бэклог доработок.

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

Берем самое рисковое проектное решение и выбираем все технические решения, все доработки к этому бизнес-процессу, которые нужны, чтобы это проектное решение запустить.

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

В чем ценность Agile? Это постоянная обратная связь. Даже если процесс еще не закончен, мы показываем доработку, во втором спринте в этом примере мы выполнили все технические решения, необходимые для запуска первого процесса. И в конце второго спринта мы показываем доработки и показываем весь процесс в сборе.

 

Получилось, что первые этапы – это, фактически, формирование бэклога. Так называемый «нулевой спринт».

Сама разработка – классический итерационный процесс разработки по сформированным бэклогам.

 

А что касается ввода в действие, опытной и промышленной эксплуатации, там мы ничего нового не придумали. Там стандартный набор документов:

  • Программа методика испытаний;

  • Дополнение к документации и т.д.

Все самые инновационные изменения у нас как раз в части сбора требований, формирования бэклога и выполнения разработки.

 

Внедрение технологии

 

 

Пару слов о том, как я внедрял эту технологию.

Чтобы внедрить технологию управления проектом с помощью Confluence, я использовал Confluence.

  • В Confluence описана вся технология в виде вебинаров – получился курс по проектной технологии.

  • Когда сейчас ко мне выходит новый специалист, он в течение двух-трех дней смотрит курс, потом сдает экзамен с помощью Confluence – в нем есть плагин «Квизы».

  • И только после этого мы его допускаем до проекта.

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

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

 

 

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

 

Планы и достижения

 

 

Что касается ближайших планов:

  • Мы хотим более тесно интегрировать СППР с Confluence, потому что на каждом втором крупном корпоративном проекте заказчики хотят одновременно с Confluence использовать СППР. На данный момент у нас работает интеграция в части требований. Интеграция в части других объектов у нас сейчас в разработке.
    Предполагается, что в схеме интеграции:

    • проектное решение будет преобразовываться в функцию;

    • техническое решение – в техпроект. Но возможно, что-то поменяется. Об этом мы еще подумаем в ближайшее время.

  • Ввиду того, что в результате проекта мы оперируем минимальными значимыми результатами для заказчика (эти два бэклога – бэклог из проектных решений и бэклог из технических решений), логично дальше подумать об Agile-проектах. Для них как раз характерно использование таких PBI (Product Backlog Item) – небольших элементов бэклога, которые понятно, как реализовывать, понятно, как оценивать. В общем, дальше логично посмотреть в сторону Agile.

Теперь о достижениях, которые можно оценить:

  • Я стал намного меньше времени тратить на согласование планов, потому что пакеты работ в планах используются стандартные, а их состав описывается параметрами. Поэтому на проверку планов я стал тратить намного меньше времени без потери качества этой проверки.

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

 

 

 

Статья написана по итогам доклада (видео), прочитанного на конференции Infostart Event 2021 Moscow Premiere.

Больше статей можно прочитать здесь.

Приглашаем на мероприятия Инфостарта 2023 года:

  • 25-27 мая, Анализ & Управление в ИТ-проектах - первая практическая конференция для аналитиков и руководителей проектов, 30% докладов и 70% практических сессий.
  • 11-13 октября, Infostart Event 2023 - самое масштабное событие в сфере 1С-индустрии, 1000+ участников, 130+ докладов.

 

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

Комментарии
В избранное Подписаться на ответы Сортировка: Древо развёрнутое
Свернуть все
1. roman72 343 17.03.23 11:43 Сейчас в теме
Сослался на вашу статью в нашем чате Телеграм по СППР
https://t.me/SPPR1c/222

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

Общий посыл участников чата СППР - инструмент есть, методологии работы с ним нет.
В СППР 1С забыла прикрутить методологию корпоративных внедрений типа «1С:Технологии корпоративного внедрения 2.0» (1С:ТКВ).

А тут вы со статьей и методологией! )
2. SergeyN 1040 18.03.23 10:25 Сейчас в теме
(1) Роман, спасибо за приглашение. Сейчас очень сложно со свободным временем, поэтому к чату про СППР не присоединюсь. Присоединюсь когда буду свободнее. Но чтобы вам интереснее было ожидать меня - прикладываю скрин интерфейса СППР с доработками, т.е что нужно еще сделать в СППР чтобы работать по ТКВ 3.0
Прикрепленные файлы:
molodoi1sneg; roman72; vikad; +3 Ответить
Оставьте свое сообщение

См. также

Технология проекта внедрения 1С:ERP – как управлять большим проектом

Управление проектом Управление командой Платформа 1С v8.3 1С:ERP Управление предприятием 2 1С:Управление холдингом Бесплатно (free)

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

10.02.2023    2251    andironenko    2    

24

На что похож ваш продукт: на Аквариум или на Муравейник? 

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

Давайте поиграем в метафоры в лучших традициях экстремального программирования. А заодно проведем новогодний конкурс - на лучшую метафору для автоматизированного продукта

27.12.2022    1814    MariaTemchina    28    

23

ТРИЗ. Решение нерешаемых проблем в бизнесе

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

Советскую теорию решения изобретательских задач давно применяют крупнейшие мировые корпорации, причем не только в технологической области, но и в сфере бизнеса. На конференции Infostart Event 2021 Post-Apocalypse основатель бизнес-клуба ТРИЗ Алексей Благих рассказал, как с помощью ТРИЗ решать нерешаемые задачи, и почему метод проб и ошибок здесь не поможет.

09.11.2022    2190    user1576201    10    

16

Я - ЗУПер! Часть 1. Компетенции сотрудников.

Внедрение ИТ-системы Управление проектом Управление командой Управление ИТ-подразделением Платформа 1С v8.3 Конфигурации 1cv8 Бесплатно (free)

Цикл статей о том, почему акушер-сантехник широкого профиля - это ПЛОХО. Расскажу плюсы специализации на одной предметной области. Рассмотрим понятные аналогии из других областей. Проанализируем пару вакансий, естественно без указания компании.

09.09.2022    6614    biimmap    78    

59

Как донести здравый смысл до заказчика. Инструменты архитектора

Управление проектом Анализ и проектирование ИТ-систем Бесплатно (free)

Андрей Овсянкин на конференции Infostart Event 2021 Post-Apocalypse поделился инструментами, которые помогают ему обрабатывать большой поток задач и экономить недели на обсуждении проекта. Он рассказал, как искать ошибки в процессах, какие диаграммы полезны при общении с заказчиком и с помощью каких инструментов можно быстро рисовать наглядные картинки вместо долгих разговоров.

05.08.2022    9990    Evil Beaver    17    

100

Технология вялых проектов

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

Не все ж такие молодцы.

11.05.2022    4637    1c-intelligence    49    

41

Документальное оформление бизнес-процессов в проектах по автоматизации

Анализ и проектирование ИТ-систем Управление проектом Внедрение ИТ-системы Бесплатно (free)

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

02.02.2022    9208    denisgalimoff    3    

23

Анализ вариантов организации работ на проектах 1С

Управление проектом Платформа 1С v8.3 1С:ERP Управление предприятием 2 Бесплатно (free)

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

12.11.2021    2305    Soliton    14    

23

Новый PMBoK 7®: Неужели заговор его составителей против простых людей все-таки раскрыт?

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

Некоторое время назад один из моих читателей в своем письме предположил, что есть настоящий заговор у тех, кто пропагандирует изучение PMBoK®.

30.07.2021    9109    MariaTemchina    13    

23

Пришиваем хвост: нужен ли Эджайл в 1С или глупости это всё?..

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

Коллеги, приглашаем поучаствовать в опросе - Agile в проектах внедрения 1С: реально работает или это миф? Интересен практический опыт!..

12.03.2021    7658    MariaTemchina    86    

27

9 советов, как уговорить девушку. Точнее, как уговорить Заказчика работать по Agile, когда он этого не хочет

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

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

16.02.2021    4534    MariaTemchina    45    

33

Как бороться с соблазном объять необъятное, или Канбан-система в проектах 1С

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

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

12.02.2021    4907    MariaTemchina    17    

25

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

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

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

10.02.2021    6315    andironenko    17    

52

Есть ли способ повысить эффективность пищевого производства?

Управление проектом Платформа 1С v8.3 1С:ERP Управление предприятием 2 Пищевая промышленность Управленческий учет Бесплатно (free)

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

09.02.2021    3210    1СERP    4    

12

Статья Компетенции РП по версии PMI и здравому смыслу. Часть 2-ая

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

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

09.12.2020    3026    MariaTemchina    3    

30

Что почитать про Agile для чайников?

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

Продолжаю рубрику “Письма в редакцию”. Ко мне иногда обращаются с вопросом - вот, я, мол, совсем не представляю, что такое Agile…

03.12.2020    6291    MariaTemchina    9    

34

Компетенции руководителя проекта: по версии PMI и здравому смыслу. Часть 1-ая.

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

Об компетенции руководителя проекта сломано немало копий (хорошо, если не об самих руководителей).  В этой статье хочу оставить свои пять копеек, отталкиваясь от тех компетенций, которые институт PMI® - законодатель моды мирового проектного управления - озвучил в качестве требований к сертификации PMP® со 2-ого января 2021 года.

18.11.2020    7845    MariaTemchina    9    

26

Как создать коробочный программный продукт

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

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

05.10.2020    4458    primat    2    

25

Советы начинающим РП: Подводим итоги шляпной вечеринки 

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

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

15.09.2020    3449    MariaTemchina    5    

23

Как стать исполнителем в проекте от Инфостарта

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

Инфостарт в поисках специалистов, которые готовы взяться за реализацию интересных проектов. Как подать заявку и стать исполнителем, с кем согласна сотрудничать компания и на каких условиях, рассказал руководитель проектов корпоративного отдела Инфостарта Александр Блинов.

11.09.2020    4378    alexandr.blinov    17    

40

Давайте спасем древесных осьминогов или 12 советов для начинающих РП от опытных товарищей

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

Ниже я попыталась собрать житейские советы от опытных руководителей проектов 1С и выпускников курсов по управлению ИТ-проектами на Инфостарте с моими комментариями. 

04.09.2020    5242    MariaTemchina    30    

44

Интеграция с Трелло. Готовый код

Управление проектом Платформа 1С v8.3 Бесплатно (free)

Код основных действий, интеграция с API Трелло.

19.08.2020    6661    Yashazz    14    

55

Видеозаписи открытых вебинаров Марии Темчиной

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

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

21.07.2020    4274    MariaTemchina    1    

33

Управление в стиле Догвилль

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

Как и почему жизнь на работе становится всё хуже. Или всё лучше.

26.06.2020    5789    1c-intelligence    17    

56

Наиболее типичные ошибки при оценке работ в проектах 1С

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

Для кого эта статья? Если вы руководитель проектов (РП) с опытом «от трех проектов», то можете не читать: скорее всего, ничего нового вы не узнаете. А если вы хотите стать РП в проектах 1С или вы профессионал (разработчик, аналитик, консультант), к которому часто обращаются за оценкой, то вам будет полезно узнать о типичных ошибках при оценке. Если вам необходимо реализовать задачу, которую не имеет смысла делать по классической проектной технологии, но заказчик требует фиксированной оценки, и задача на 2-5 человеко-месяцев, - то вам будет полезно понять методы оценки работ. Если читатель часто пользуется услугами удаленных разработчиков/аналитиков, то вам, возможно, станет понятно, почему «человек все сделал, мы ему заплатили, сколько сказал, а он от нас ушел и больше работать не хочет». Типичные ошибки распределю по классам.

13.06.2020    3536    Koder_Line    9    

26

Как воспитать в себе РП? Часть 1

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

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

01.06.2020    9499    MariaTemchina    4    

23

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

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

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

25.05.2020    7319    sapervodichka    1    

56

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

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

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

18.05.2020    13796    MariaTemchina    34    

45

Автоматизация управления закупками: специфика проектов, методология работ или "как не наступить на грабли"

Управление проектом Платформа 1С v8.3 1С:ERP Управление предприятием 2 Управленческий учет Бесплатно (free)

В этой статье речь пойдет об автоматизации закупочной деятельности. Причем не о том, как настраивать рабочие места, документы и реквизиты в 1С:ERP. А о том, что на самом деле обычно нужно компании, когда она заявляет об «автоматизации процессов закупок». И о том, как правильно подойти к этой самой автоматизации, чтобы проект не стал «вечным долгостроем», а внутренние заказчики (руководство компании, руководители отделов и департаментов) получили действительно полезный результат. Подробнее тему автоматизации МТО можно изучить на курсе //infostart.ru/public/1201558/

06.04.2020    9194    1СERP    4    

28

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

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

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

23.03.2020    8374    MariaTemchina    26    

33

Визуализация фич Vanessa Automation в StoryMapper

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

Описан процесс визуального упорядочивания коллекции feature-файлов в виде карты пользовательских историй. Используется инструмент гибкого управления требованиями StoryMapper.

21.03.2020    5143    oleynik.dv    7    

23

Как завершать проекты в срок

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

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

10.03.2020    5930    VLikhobabin    6    

27

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

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

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

03.03.2020    11013    VLikhobabin    44    

67

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

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

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

23.01.2020    48420    MariaTemchina    12    

36

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

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

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

04.01.2020    7576    capitan    52    

24

BDDSM-практики, или 50 оттенков желтого

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

В статье описаны практические результаты применения методики BDDSM на отдельно взятом РЕАЛЬНОМ проекте поддержки.

26.12.2019    13392    Mistress_A    28    

80

Про одну Тётю

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

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

24.12.2019    7734    1c-intelligence    33    

27

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

Управление проектом Анализ и проектирование ИТ-систем Бесплатно (free)

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

14.10.2019    6676    chavalah    16    

27