Данная презентация была представлена в ходе вебинара "Методики управления развитием ИС на базе 1С. СППР как возможный инструмент поддержки данных методик". Ведущий - Олег Демиденко, руководитель отдела внедрения, руководитель проектов компания "Кодерлайн".
2. В момент внедрения системы и добавления функционала
• Делают не то
• Делают одно, другое ломают
• Работы выполненные разными специалистами оказываются во
взаимном противоречии
Причины проблемы: плохие коммуникации
• Каждый понял по своему что ему надо делать. Заказчик ждёт одно,
программист может очень хорошо сделать но не то, что нужно
• Бизнес-заказчики и программисты не знают над чем работают их
коллеги.
• В худшем случае, два бизнес-заказчика одновременно попросят
сделать одинаковые / противоположные функции у двух разных
программистов.
В чем проблема? Зачем какие-то методики?
4. При развитии системы
• Забывается что и зачем было сделано. Появляется священный страх
делать изменения (а вдруг что-нибудь сломается)
• Стоимость добавления нового функционала растёт, т.к. внедрить его
учтя все взаимосвязи становится всё сложнее
Причины проблемы:
• Отсутствие документации проектных решений
• Плохая архитектура – сложно разобраться в клубке разных
программных функций непонятно как и зачем связанных между собой
В чем проблема? Зачем какие-то методики?
5. При смене системы
• Никто не помнит зачем старая система так работала. Поэтому
выбирают один из двух путей: делают новую систему как копию
старой, сохраняя груз проблем. Или делают новую систему с нуля, с
огромными повторными затратами на бизнес-анализ.
Причины проблемы:
• Отсутствие документации проектных решений
В чем проблема? Зачем какие-то методики?
6. • Некачественная передача информации между людьми, или вообще
отсутствие коммуникации.
• Важная информация хранится в головах. Постепенно происходит
забывание или отток голов, хранивших эту информацию.
• Некоторые проектные решения иногда неоптимально влияют на ИС,
делаются наспех, в виде заплаток. Копится груз проблем.
Итого:
• 2,5 проблемы имеют организационную причину.
• 0,5 проблемы имеют техническую причину (недостаток тех.квалификации)
В чем корень проблемы
7. • Нужно чтобы Заказчик и Исполнитель смогли точно понять друг друга,
чтобы Исполнитель сделал то, что нужно Заказчику
• Разработчики должны общаться между собой, чтобы не ломать работу
друг друга
• Архитектор системы должен вовремя и понятно сообщить о критическом
числе заплаток и необходимости провести рефакторинг, приводящий
систему в божеский вид
Методики решения:
• Обсуждение требований в виде максимально исключающим
взаимонепонимание: простой язык, наглядные примеры
• Разработчики должны регулярно общаться, на стадии проектирования
своих доработок, чтобы не оказалось что что-то было сделано зря
• Учет «Технического долга» накопленного при проектировании системы
Задача – наладить коммуникации
8. Пойдем от обратного:
• Оплачивайте программистам только то время, когда они сидят и пишут
код, а не чешут языком. Программистов вообще не просили разбираться в
бизнесе, который они автоматизируют. Как им сказали, так пусть и делают.
• Пишите ТЗ в технических терминах со всеми нюансами. Не тратьте время
на переписывание ТЗ ради такого абстрактного понятия как
«удобочитаемость». Тогда пользователь его подпишет не читая.
• Не используйте графические картинки и схемы
• Предполагайте что всё, что вы не стали обсуждать, вы с заказчиком
понимаете одинаково. Ведь мы же все разумные люди, и скорее всего
предполагаем примерно одно и то же.
• Не показывайте заказчику промежуточный прототип, всё равно не поймет.
Только время зря потратим.
Как однозначно понять друг друга?
9. • Разработчик и заказчик должны провести достаточное время в
обсуждении сути задачи и выработки эффективного подхода к её
решению. Они должны придти к однозначному общему пониманию задачи
• Договоренности должны быть задокументированы простым и достаточно
исчерпывающим способом. Сценарии использования, схемы бизнес-
процессов, графические схемы.
• До реализации полного функционала должен быть разработан
интерфейсный прототип. Данный прототип должен быть обязательно
согласован с заказчиком, чтобы убедиться что разработка ведётся в
верном направлении.
Как однозначно понять друг друга?
10. • Необходимо чтобы программисты согласовывали друг с другом свои
задачи на предмет выявления нестыковок
• Необходимо чтобы программисты обменивались информацией о работе
друг друга, чтобы итоговый результат было более унифицированным в
подходах и за счет этого, более эффективным в использовании.
Не продуктивные варианты:
• Схема «звезда» не работает. Один человек не способен
проконтролировать полную стыковку всех блоков даже в небольшой
команде.
• При почасовой оплате работы программистов, и необходимости доказать
полезность каждого часа своей работы – общение между собой доказать
труднее всего.
Как согласовать работу разработчиков
12. • Функциональное моделированцие (IDEF 0)
• Функционал планирования, контроля и документирования технических
проектов
• Баг-трекинг
• Учет требований
• Система подготовки встроенной справки
• Система проектирования прав доступа
Что вообще умеет СППР
13. Бывает полезно при согласовании и объяснении верхнеуровневой
архитектуры, на уровне руководства. Внутри отделов разработки
используется редко
Функциональное моделирование
14. • Средство контроля кто что и зачем будет делать
• «Память» проекта – кто что и зачем сделал
• Контроль формальных правил выполнения проекта: контрольные точки и
контрольные вопросы
«Технический проект»
17. • Средство подготовки встроенной справки и документации к релизам
• История изменений в разрезе объектов метаданных
• Реестр требований, с указанием источников, ответственных и
приоритетов; возможностью группировки по тематикам
• Баг-трекер
• Система постановки задач друг другу
• Интеграция с документооборотом
• Поддержка работы с несколькими хранилищами/ветками разработки
Что еще есть в СППР
18. СППР – не самоцель. И, возможно, не самый удобный инструмент.
Преимущества СППР:
• Однообразно по всей компании
• На платформе 1С, можно дорабатывать под свои нужды
• Есть положительный опыт из фирмы 1С по разработке сложных систем
• У нас есть тоже положительный опыт
• Это технология, которую активно рекламирует сама фирма «1С» на всех
своих бизнес-форумах, посвященных ERP.
• Технологию СППР фирма 1С обязывает использовать на VIP-проектах,
которые проходят под её надзором
Почему именно СППР?
Пример:.Делают не то – Технониколь, Детальный дизайн
Делают одно, другое ломают – тот же Технониколь – оч.запутанная архитектура, пробелы в требованиях
Взаимное противоречие доработок – проект РТИТС. Заказы глав.буха и фин.дира 2 разработчика делали так, что эти доработки были несовместимы.
через полгода на интенсивном проекте часть сделанных проектных решений уже может быть забыта
Примеры:
Проект ЭЦ – забыли зачем включили какую-то ФО. Но точно помним что долго это обсуждали перед тем как так сделать.
В Технониколь – перестали поддерживать техническую документацию, и с самого начала она была неполной. В итоге – что имелось в виду под частью кода понятно только при его долгом анализе.
Технониколь – стоимость добавления функционала росла, т.к. было ясно что часть решений неоптимальна и по-хорошему, её надо пересмотреть.
через полгода на интенсивном проекте часть сделанных проектных решений уже может быть забыта
Бывает что и в тепличных условиях технари дают плохой результат
Понятно что могут быть еще чисто технические проблем, возникающие из-за масштабов системы и технологии.
Мы обсуждаем проблемы которые не имеют однозначного оправдания в виде недостатков технологии.
Бизнес-цели не стал выснять Костя Шок в Технониколе.
Моничев из 1С любит говорить «Длинные письма начальство только расстраивают»
Был опыт когда позже выяснилось что типовой функционал решал задачу. Но заказчик сформулировал задачу на доработку и её выполнили строго по ТЗ.
Был опыт когда позже выяснилось что типовой функционал решал задачу. Но заказчик сформулировал задачу на доработку и её выполнили строго по ТЗ.
Схема «звезда» не работает. Один человек не способен проконтролировать полную стыковку всех блоков уже в команде от 5 человек. Особенно если он играющий тренер и одновременно сам отвечает за самый сложный блок работ.
При почасовой оплате работы программистов, и их необходимости доказать полезность каждого часа своей работы – общение между собой доказать труднее всего. Проблемы из-за отсутствия согласованности станут видны намного позже. Это скрытый «технический долг».
через полгода на интенсивном проекте часть сделанных проектных решений уже может быть забыта
через полгода на интенсивном проекте часть сделанных проектных решений уже может быть забыта
через полгода на интенсивном проекте часть сделанных проектных решений уже может быть забыта
через полгода на интенсивном проекте часть сделанных проектных решений уже может быть забыта
через полгода на интенсивном проекте часть сделанных проектных решений уже может быть забыта