Проектная разработка на платформе 1С: Предприятие 8

  • Создание системы с нуля под требования клиента
  • Реализация разработок на основе типовых конфигураций
  • Сложные интеграции

Высокий класс разработки, скорость и качество выполняемых работ подтверждают не только наши крупные конечные клиенты, но и постоянное сотрудничество с крупнейшими системными интеграторами: Рексофтом, Техносервом, и другими ИТ-компаниями. Мы сотрудничали и сотрудничаем с компаниями Информатика и Сервис, Мегаплан, ОКТелл и другими. Такие клиенты являются самыми требовательными ведь они знают, как должны идти ИТ-проекты.

Кому и для чего нужна разработка на 1С?

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

Разработка на 1С необходима, если

  • 1

    НУЖНЫ СЛОЖНЫЕ И НЕСТАНДАРТНЫЕ ИНТЕГРАЦИИ

    Между типовыми 1С решениями легко наладить обмен с помощью универсальных механизмов. А как быть, если необходимо интегрировать 1С с IBMWebSphere, SAP, MSProjectServer или Почтой России? Без хардкорной разработки, подключения к API, написания шлюзов — не обойтись.
  • 2

    НУЖНО АВТОМАТИЗИРОВАТЬ ОТДЕЛЬНЫЙ ПРОЦЕСС, ИЛИ АСПЕКТ ЖИЗНЕДЕЯТЕЛЬНОСТИ КОМПАНИИ

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

    БИЗНЕС КЛИЕНТА – ОЧЕНЬ СПЕЦИФИЧЕСКИЙ

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

Как осуществляется разработка?

Все проекты ведутся единым «проектным офисом» — в каждом проекте участвуют методологи, архитектор, разработчики, внедренцы, все специалисты различного профиля, которые в этом проекте могут понадобиться. Работу по проекту координирует РП (руководитель проекта), а все проекты в целом — РПО (руководитель проектного офиса). Мы знаем кто, когда, чем занят, когда освобождается, и когда мы можем или не можем взять проект определенного типа.
Чуть ниже — таблица, которая примерно дает понять, в каких случаях какая методика применима. Есть несколько условий, которые мы соблюдаем в любом случае.

Ведение проекта

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

Технологии

Продуманная архитектура, максимальное использование типового функционала
Внутреннее тестирование
Обновляемость (решения должны быть настолько обновляемыми, насколько это возможно)
Высокий уровень разработки (оптимальный быстрый и чистый код)

Взаимодействие

Команда проекта должна говорить на человеческом языке
Необходимо руководить не только собой, но и заказчиком
Заказчика необходимо вовлекать в проект с начала и до конца
Есть общее понимание требуемого результата (концепции, задач решаемых ИС), но сформулировать его детально — невозможно
Требования могут меняться в ходе проекта, и это нормально (проект должен это учитывать)
Бюджет на проект в целом — не выделен. Нужно распределять оплаты по периодам, и постоянно видеть результат каждой оплаты.
Заказчик не может гарантировать скорость реакции со своей стороны в ходе всего проекта. Возможны задержки, вызванные текущими делами: выставками, командировками ЛПР, и так далее
Заказчику нужно видеть хоть какие-то результаты как можно быстрее и чаще

Выбор подхода

ВЫБИРАЕМ AGILE

ВЫБИРАЕМ WATERFALL

Мы собрали несколько важных критериев — конечно, их больше. Но это то, на что мы всегда обращаем внимание, перед тем как предложить заказчику подход к разработке.
Цели проекта полностью известны. Можно написать единое большое ТЗ — на весь проект.
Зафиксированные требования не меняются, или меняются незначительно.
Необходимо сразу понять бюджет, согласовать его на всех уровнях компании, утвердить и придерживаться
Со стороны заказчика выделен РП, который занимается проектом как основной работой. Он постоянно доступен, решает проектные задачи, обеспечивает быструю реакцию, и на время проекта никуда не уезжает.
У проекта есть контрольные точки и этапы. Этого достаточно.

Ценообразование

1
Пресейл, предварительный анализ требований
Бесплатно, в ходе выполнения этих работ мы можем дать оценку бюджета в диапазоне от — до и стоимость этапа 2.
4
Внедрение, обучение, интеграция
Стоимость точно определена на этапе 2 (если применяется методология «водопад»). Составляет 10−20% от бюджета проекта.
Стоимость работ рассчитывается исходя из ставки специалиста 3 000 р/час. При этом согласованный бюджет (по задаче, этапу, реализации требования), фиксируется и не меняется, если от клиента не поступают новые требования. Мы не перекладываем на заказчика ответственность за наш перерасход часов/денег.
3
Разработка ПО, тестирование
(по этапам, или итерациями). Стоимость точно определена на этапе 2 (если применяется методология «водопад»).
2
Обследование, написание документации
(ФТ, ТЗ, концепция ИТ системы, устав проекта, план, перечень задач — в зависимости от объема проекта и выбранной методологии). Стоимость точно определена на этапе 1, и составляет 20−30% от бюджета проекта.

Реализованные проекты

Оставьте Ваши контакты.
Мы свяжемся с Вами в кратчайшие сроки.

Остались вопросы?