Этапы проектов 1С
Данные > Статьи и инструкции > Практика
Подход в компании 1С (от Aрипoвa Никиты, @АriN1С):
📝 Любая задача состоит из:
- Проговаривание задачи: Убеждаемся, что одинаково понимаем проблему, которую хотим решить
- Согласование требований: Договариваемся, какими новыми качествами будет обладать программа после реализации проекта
- Обсуждение идеи: Смотрим, как такие задачи решали другие, обдумываем, как примерно решать эту задачу
- Выработка проектных решений: Выбираем конкретный подход для решения задачи
- Проработка интерфейса: Придумываем, как будет выглядеть наше решение, чтобы оно было удобным и понятным
- Обсуждение архитектурных решений: Прорабатываем, как это все будет работать с точки зрения метаданных и существующих решений
- Согласование готового решения: Проверяем, что получилось то, что мы задумывали и ничего не упустили
- Проведение код-ревью: Смотрим, понятный и хороший ли код
- Тестирование: Проверяем, что не осталось ошибок и непродуманного поведения
- Выпуск в релизе: Выпускаем наше решение в правильном релизе
🌀 Движемся слева направо, но иногда можем и откатиться назад, если столкнулись с проблемами, чтобы их обойти новым путем
1️⃣ Проговаривание задачи - это 5-10 минутный созвон тимлида, разработчика и ответственного за продукт. Цель: объединить понимание задачи и наметить план решения. Например, «Развитие отчетов руководителю» после проговаривания может трансформироваться в «Добавить быстрые настройки (оформление, округление, варианты) в общую форму отчетов руководителя». Причем этот этап полезен даже если задача сформулирована понятно - «Указывать основание финансирование в документе Расход материалов». На встрече можно подсказать куда посмотреть и к кому обратиться за помощью, чтобы сделать быстрее.
❓ Какие вопросы задать?
Чтобы встреча прошла продуктивно во первых стараемся жестко держать тайминг, а во-вторых не превращаем созвон в проектное совещание. Поэтому основные вопросы могут быть такие:
- Какую проблему решаем? («Руководители тратят 2 часа на настройку отчетов»)
- Что должно получится в конце? («Быстрые настройки для оформления отчета»)
- Для каких объектов или документов? («Давай начнем с Продаж и Задолженности по контрагентам»)
- Какие ограничения? («Стандартные отчеты не трогаем»)
- Есть ли какие-то идеи? («Хвалят как сделано в УНФ»)
Таким образом, разработчик на следующий этап «Согласование требований» уже приходит с пониманием что делать и куда копать. А значит может сформулировать четкие требования к программе и донести их до заинтересованных лиц.
💣 Что будет, если пропустить этап?
Представим, что разработчику выдали задачу «Улучшение проведения документов» и проговаривания не было.
Обычно следующие действия такие:
- Самостоятельно исследуем контекст - что сейчас не так с документами?
- Ищем конкретику - в каких документах и что улучшать?
- Выясняем, кто может подсказать - может быть кто-то решал подобную задачу?
Добавим еще деталей. В описании задачи еще есть «Перевести торговые документы на новый режим проведения».
Появляются новые вопросы:
- Что это за новый режим проведения?
- Кто его сделал и как с ним работать?
- Делаем для всех торговых документах (даже для комиссии?) или только для частотных?
Хорошо, если разработчик знает к кому обратиться с этими вопросами.А если нет?
📌 Лучше потратить 10 минут на старте, чем 10 часов на переделки. Проговаривание задачи - это «рытье канала с двух сторон»:
👉 Разработчик задает свои вопросы
👉 Тимлид и ответственный за продукт добавляют деталей
💡 Итог: все на одной волне, а требования согласовываются в разы быстрее.
2️⃣ Согласование требований - это первый самостоятельный этап работы программиста над задачей. У нас нет аналитиков, поэтому все, начиная от требований и заканчивая замерами производительности готового решения, выполняет непосредственно разработчик. Почему это важно? Без четких требований легко уйти в бесконечные правки или пропустить ключевые детали.
🎯 Цель этапа:
Разработать и согласовать требования, по которым задача будет считаться выполненной. Требования — это ответ на вопрос: «Как мы поймем, что всё работает как надо?»
Пример для проекта «Быстрые настройки в отчетах руководителю»:
- Руководитель меняет округление не более чем за 4 клика (сейчас 6 кликов)
- Контекст отчета не теряется при изменениях
- Настройки сохраняются индивидуально для пользователя
То есть это рамки, которые мы сами себе ставим, чтобы ничего не забыть и не делать лишнего. А вот как конкретно это будет реализовано решаем позже. То есть будет ли это подменю, реквизиты на форме или напрыгивающее окно — решается на следующих этапах.
❌ Частая ошибка
Неправильно подгонять требования под свое решение. Нужно уметь максимально отдалиться от конкретной идеи и постараться описать то, что на наш взгляд поможет решению.
Не нужно в требованиях указывать конкретные проектные решения:
- Настройки указываются как отдельный реквизит на форме
- При закрытии отчета вариант округления сохраняются в пользовательских настройках
- Быстрые настройки открываются в модальном окне
Совет: Если сложно отвязаться от своей идеи, придумайте 2-3 альтернативных решения (даже абсурдных). Это поможет выделить суть требований.
📖 Пользовательская история
Для подготовки требований отлично помогает ключевая пользовательская история. Обычно именно из нее и рождаются хорошие требования. Про User Story есть много отличных материалов, поэтому я просто приведу пример для нашей задачи:
Я как руководитель
- ХОЧУ увидеть цифры в отчете в тысячах рублей
- ЧТОБЫ быстрее принимать решение, не производя округление в голове
Такие истории помогают понять, что нужно пользователю, а не как это сделать. Без использования ключевых пользовательских истории сложно на согласовании описать какую проблему мы собираемся решать. Поэтому использовать их — обязательно.
🚀 Согласование
С историей и требованиями разработчик идет на согласование с командой и ответственным за продукт. Это тот этап, когда из описания проблемы рождаются четкие критерии задачи. На проговаривании проекта мы можем увидеть лишь вершину айсберга, но не корень проблемы. Как раз требования позволяют нам оградить все место флажками.
🎯 Зачем это нужно?
Цель согласования — обсудить с тимлидом и ответственным за продукт, что:
- Требования закрывают реальную боль пользователей
- Задачу нужно решать именно сейчас
🔧 Как проходит процесс?
1. Подготовка
- Выбираем 20-минутный слот в расписании.
- Приглашаем тимлида и ответственного за продукт
- Приглашаем коллег по нужным направлениям (например, если проект про НДС или УСН — подключаем налоговых специалистов)
2. Демо (10 минут)
- Показываем анализ проблемы, требования и пользовательскую историю
- Пример: «Руководителю сложно настроить отчет → нужно дать возможность делать это контекстно»
3. Обсуждение (10 минут)
- Уточняем границы проекта: что включаем, а что оставляем «за скобками»
- Обсуждаем серые зоны: что еще не учли, кому может быть хуже?
- Ищем компромиссы: возможно сделать инструкцию, а не делать проект
4. Итог
- Фиксируем решение. Отправная точка для дальнейшей работы над проектом.
Варианты результата:
✅ Делаем! Требования согласованы — переходим к идее
❌ Не делаем. Отлично! Сэкономили время, если задача не критична или решается без разработки
🔄 Ни к чему не пришли. Нужно уточнить данные и вернуться с новыми аргументами
❗️Важные моменты:
- Открытость процесса. К обсуждению могут присоединится все заинтересованные коллеги (узнают об этом из рассылки). Поэтому важно четко обрисовывать и доносить проблему, которую хотим решить. Коллеги со своей стороны задают уточняющие вопросы, чтобы понять, что хотим реализовать.
- Фокус на главном. Бывает так, что мы специально какую-то часть задачи не делаем. Или наоборот делаем только какую-то одну, даже небольшую часть задачи. А все остальное оставляем на потом. Здесь важно выделить самое критичное и важное, а также защиить свою задачу от неконтролируемого роста
- Жесткий тайминг. На весь процесс - 20 минут. Почему?
- Долго рассказываешь - не хватит времени на обсуждение
- Слишком коротко - не раскрыта суть и нечего обсуждать
- Уважаем время коллег. Ты тратишь не только свое время, но и время коллег. Очень грустно приходить на согласования на которых ни к чему не пришли.
📌 Что дальше?
- Если требования согласованы, то начинаем готовить идею - как планируем решать задачу, как решают эту задачу в аналогичных решениях, какие в целом есть варианты.
- Если требования не согласованы, то исправляем замечания и снова выходим на согласование.
3️⃣4️⃣5️⃣6️⃣7️⃣8️⃣9️⃣🔟 - Ждём... Никита еще не выпустил)
Типовой подход бизнеса (устаревшее):
📝 Внедрение проектов по 1С обычно включает в себя несколько ключевых этапов, которые могут варьироваться в зависимости от специфики проекта и требований заказчика. Вот основные типовые этапы, которые часто встречаются в проектах 1С:
- Анализ и диагностика: Изучение текущих бизнес-процессов и требований заказчика. Анализ существующих информационных систем и их интеграции. Определение целей и задач проекта.
- Проектирование: Разработка технического задания (ТЗ), в котором описываются требования к системе. Проектирование архитектуры системы, включая базы данных и интерфейсы. Определение функциональных и нефункциональных требований.
- Разработка и настройка: Настройка и адаптация стандартных решений 1С под требования заказчика. Разработка дополнительных модулей и функциональности, если это необходимо. Интеграция с другими системами, если это предусмотрено проектом.
- Тестирование:Проведение функционального и нагрузочного тестирования системы. Исправление ошибок и доработка системы на основе результатов тестирования. Подготовка к переходу в промышленную эксплуатацию.
- Обучение пользователей: Проведение обучающих курсов и тренингов для пользователей и администраторов системы. Создание документации и инструкций по использованию системы.
- Внедрение и переход в промышленную эксплуатацию: Перенос данных из старой системы в новую, если это необходимо. Запуск системы в промышленную эксплуатацию. Поддержка пользователей в начальный период эксплуатации.
- Поддержка и сопровождение: Обеспечение технической поддержки и обновление системы. Мониторинг производительности и исправление возникающих проблем. Планирование и реализация дальнейших доработок и улучшений.
0
комментарии
____________________
Перепечатка текста и фотографий разрешена при наличии прямой ссылки на источник