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

1. Методики управления развитием ИС на базе 1С
Олег Демиденко

2. В момент внедрения системы и добавления функционала
• Делают не то
• Делают одно, другое ломают
• Работы выполненные разными специалистами оказываются во
взаимном противоречии
Причины проблемы: плохие коммуникации
• Каждый понял по своему что ему надо делать. Заказчик ждёт одно,
программист может очень хорошо сделать но не то, что нужно
• Бизнес-заказчики и программисты не знают над чем работают их
коллеги.
• В худшем случае, два бизнес-заказчика одновременно попросят
сделать одинаковые / противоположные функции у двух разных
программистов.
В чем проблема? Зачем какие-то методики?

3. В чем проблема? Зачем какие-то методики?

4. При развитии системы
• Забывается что и зачем было сделано. Появляется священный страх
делать изменения (а вдруг что-нибудь сломается)
• Стоимость добавления нового функционала растёт, т.к. внедрить его
учтя все взаимосвязи становится всё сложнее
Причины проблемы:
• Отсутствие документации проектных решений
• Плохая архитектура – сложно разобраться в клубке разных
программных функций непонятно как и зачем связанных между собой
В чем проблема? Зачем какие-то методики?

5. При смене системы
• Никто не помнит зачем старая система так работала. Поэтому
выбирают один из двух путей: делают новую систему как копию
старой, сохраняя груз проблем. Или делают новую систему с нуля, с
огромными повторными затратами на бизнес-анализ.
Причины проблемы:
• Отсутствие документации проектных решений
В чем проблема? Зачем какие-то методики?

6. • Некачественная передача информации между людьми, или вообще
отсутствие коммуникации.
• Важная информация хранится в головах. Постепенно происходит
забывание или отток голов, хранивших эту информацию.
• Некоторые проектные решения иногда неоптимально влияют на ИС,
делаются наспех, в виде заплаток. Копится груз проблем.
• Бывает что и в тепличных условиях технари дают плохой результат
Итого:
• 2,5 проблемы имеют организационную причину.
• 1,5 проблемы имеют техническую причину (недостаток тех.квалификации)
В чем корень проблемы

7. • Нужно чтобы Заказчик и Исполнитель смогли точно понять друг друга,
чтобы Исполнитель сделал то, что нужно Заказчику
• Разработчики должны общаться между собой, чтобы не ломать работу
друг друга
• Архитектор системы должен вовремя и понятно сообщить о критическом
числе заплаток и необходимости провести рефакторинг, приводящий
систему в божеский вид
Методики решения:
• Обсуждение требований в виде максимально исключающим
взаимонепонимание: простой язык, наглядные примеры
• Разработчики должны регулярно общаться, на стадии проектирования
своих доработок, чтобы не оказалось что что-то было сделано зря
• Учет «Технического долга» накопленного при проектировании системы
Задача – наладить коммуникации

8. Пойдем от обратного:
• Оплачивайте программистам только то время, когда они сидят и пишут
код, а не чешут языком. Программистов вообще не просили разбираться в
бизнесе, который они автоматизируют. Как им сказали, так пусть и делают.
• Пишите ТЗ в технических терминах со всеми нюансами. Не тратьте время
на переписывание ТЗ ради такого абстрактного понятия как
«удобочитаемость». Тогда пользователь его подпишет не читая.
• Не используйте графические картинки и схемы
• Предполагайте что всё, что вы не стали обсуждать, вы с заказчиком
понимаете одинаково. Ведь мы же все разумные люди, и скорее всего
предполагаем примерно одно и то же.
• Не показывайте заказчику промежуточный прототип, всё равно не поймет.
Только время зря потратим.
Как однозначно понять друг друга?

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

10. • Необходимо чтобы программисты согласовывали друг с другом проекты
на предмет выявления нестыковок
• Необходимо чтобы программисты обменивались информацией о работе
друг друга, чтобы итоговый результат было более унифицированным в
подходах и за счет этого, более эффективным в использовании.
Не продуктивные варианты:
• Схема «звезда» не работает. Один человек не способен
проконтролировать полную стыковку всех блоков уже в команде от 5
человек. Особенно если он играющий тренер и одновременно сам
отвечает за самый сложный блок работ.
• При почасовой оплате работы программистов, и их необходимости
доказать полезность каждого часа своей работы – общение между собой
доказать труднее всего. Проблемы из-за отсутствия согласованности
станут видны намного позже. Это скрытый «технический долг».
Как согласовать работу разработчиков

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

12. Организация совместной разработки в фирме 1С
с использованием
«Системы проектирования прикладных решений»

13. • Описание всего в IDEF 0.
Бывает полезно при согласовании и объяснении верхнеуровневой
архитектуры, на уровне руководства. Внутри отделов разработки
используется редко
Что вообще умеет СППР

14. • Средство контроля кто что и зачем будет делать
• «Память» проекта – кто что и зачем сделал
• Контроль формальных правил выполнения проекта: контрольные точки и
контрольные вопросы
«Технический проект»

15. • Способ формализации подхода к выполнению задач
«Технический проект»

16. • Контроль выполненных изменений
«Технический проект»

17. • Средство подготовки встроенной справки и документации к релизам
• История изменений в разрезе объектов метаданных
• Реестр требований, с указанием источников, ответственных и
приоритетов; возможностью группировки по тематикам
• Баг-трекер
• Система постановки задач друг другу
• Интеграция с документооборотом
• Поддержка работы с несколькими хранилищами/ветками разработки
Что еще есть в СППР

18. СППР – не самоцель. И, возможно, не самый удобный инструмент.
Преимущества СППР:
• Однообразно по всей компании
• На платформе 1С, можно дорабатывать под свои нужды
• Есть положительный опыт из фирмы 1С по разработке сложных систем
• У нас есть тоже положительный опыт
• Это технология, которую активно рекламирует сама фирма «1С» на всех
своих бизнес-форумах, посвященных ERP.
• Технологию СППР фирма 1С обязывает использовать на VIP-проектах,
которые проходят под её надзором
Почему именно СППР?

19. Спасибо за внимание