Что такое качество разработки и качество поддержки? Статья 2

Публикация № 1258168

Методология - Методология управления разработкой

Качество разработка SLA поддержка 1-я линия 2-я ошибки программирование проект управление проектом разработчик консультант технические

Это вторая из 8 статей про разработку в сфере 1С. В данной статье будут раскрыты следующие вопросы: 1. Ошибки в решениях в пользовательском режиме и их причины. 2. Технические ошибки при разработке решений в 1С. 3. Мы закрыли 100 заявок за 1 день. Есть ли польза от такой поддержки? Польза или вред от SLA.

Качество любой разработки можно оценить по 2 параметрам:

    • Нет ошибок со стороны пользовательского интерфейса.
    • Решение не содержит технических ошибок.

 

  1. Ошибки в решениях в пользовательском режиме и их причины.

 

Перечислим часто встречающиеся проблемы:

  1. Учтены не все сценарии работы. Очевидно, что это ошибка архитектора или аналитика, который выполнял обследование, описывал сценарии работы и ставил задачу разработчику.
  2. При наличии формул выдается неверный результат вычисления. Данная проблема возникает при некачественном тестировании со стороны разработчика и консультанта. Иногда разработчик не обладает достаточными компетенциями для проведения качественного тестирования. В данном случае контрольные примеры ему должен создать консультант или аналитик.
  3. При открытии пользовательской формы объекта метаданных (документа, справочника, отчета, обработки) вылетает ошибка. Это самая постыдная ошибка. Говорит она о том, что после последних изменений доработка не тестировалась. Это говорит о низком уровне ответственности со стороны разработчика и излишней его самоуверенности.
  4. Не удобный интерфейс. Не каждый разработчик способен спроектировать качественный интерфейс. Для этого предназначен этап Design review. Качественный интерфейс должен помочь пользователю решить следующие задачи:
    • Быстро ввести минимальный набор информации для работы механизма
    • Не допустить ошибок при вводе данных, заполнить все обязательные поля.
    • Быстро проанализировать уже введенные данные.
  5. Данные приходится вводить в двух разных объектах, или наоборот получать двумя отчетами. Такая проблема появляется, когда связанные задачи решают разные аналитики и разработчики. Если проектированием занимается архитектор – это показатель нехватки опыта в проектировании сложных механизмов.

 

  1. Технические ошибки в решениях, их причины и последствия для проекта.

 

Перечислим часто встречающиеся проблемы:

  1. Запросы написаны не оптимально. Данная ошибка встречается наиболее часто при проведении Code review. Данный этап проверки очень важен, т.к. напрямую влияет на производительность системы. Бывает, что сервер падает от неоптимального запроса. Проводит проверку архитектор проекта (системный), владеющий компетенциями по оптимизации запросов. На производительность максимальное влияние оказывают следующие ошибки:
    • Запросы в циклах. Иногда вызывается в цикле процедура либо функция, которая выполняет запрос.
    • Использование физической таблицы вместо виртуальной таблицы. Запрос к физической таблице выполняется в разы дольше, чем к виртуальной таблице. При этом выбирается больше ненужных данных.
    • Многократное обращение к одному и тому же источнику данных в рамках пакета запросов.
    • Неверное использование индексов при написании параметров виртуальных таблиц, связей между таблицами и условий запроса.
    • Отсутствие индексов при использовании больших временных таблиц, либо лишние индексы.
  2. Не используется программный интерфейс. Существующий в типовых конфигурациях программный интерфейс позволяет выполнять типичные для конфигурации действия без добавления новых процедур и функций. Программный интерфейс учитывает всегда большое количество сценариев и оптимизирован, насколько это возможно. Создание новый процедур и функций приводит к дублированию функционала, и не каждый разработчик способен написать лучше. Адаптация программного интерфейса под конкретную задачу занимает несколько часов. Написание «с нуля» может занять несколько недель.
  3. Типовые процедуры и функции выносятся в новые модули и там меняются. Часто встречаю ситуации, где разработчик скопировал типовую процедуру и меняет её в новом модуле. Так сказать, чтоб не обновлять потом это место. В данной ситуации забывают, что скопированная процедура имеет ссылки на процедуры и функции общих модулей. В типовых конфигурациях очень часто происходит смена местоположения процедур и функций и изменение количества параметров. Некоторые удаляют вовсе. Скопировав типовую процедуру, вы делаете данный участок кода не обновляемым. Никто не знает, что Вы её заимствовали. Следовательно, при обновлении на новый релиз её не обновят, и Ваш функционал перестанет работать! Такие ошибки выявляются на этапе Code review архитектором проекта.
  4. Неверное использование блокировок и привилегированного режима работы. Новые тенденции среди разработчиков:
    • При выполнении запроса к регистрам накопления включать блокировку. Возникает вопрос: ЗАЧЕМ? В реальности сценариев, при которых она нужна – единицы, а используют повсеместно! Нужно анализировать. Есть ли пользователи, которые могут изменить данные, которые ввел другой пользователь? Чаще всего зоны ответственности разграничены между пользователями и пересечение невозможно. Следовательно, и блокировка не нужна! Есть ещё ситуации, описывать все не буду. Важно использовать блокировку только там, где она влияет на результат запроса!
    • При записи или чтении данных используют привилегированный режим. Якобы некогда разбираться какие права у пользователя, проще записать или прочитать без учета прав. Такой подход  крайне негативно проявляется при использовании RLS. Допустимо это использовать на этапе тестирования функционала, но в релизной версии это недопустимо.
  5. Несоблюдение стандартов разработки. Об этом будет отдельная статья. Это одна из самых больших проблем на текущий момент. Из 10 разработчиков стандарты соблюдают в лучшем случае 2. Троих ещё можно убедить в необходимости их соблюдения. Примерно половина людей, называющих себя разработчиками категорически против стандартов. Чаще всего от  таких слышишь – оно же работает?! Это и выясним в отдельной статье.

 

  1. Как определить качество поддержки? Помогает ли в этом популярный SLA.

 

Чтобы оценить качество поддержки, необходимо разобраться, что это такое? Всем известно о наличии 3-х линий поддержки.

Первая линия поддержки решает следующие задачи:

    • Фиксация потребности в поддержке. Оформление заявки. Обсуждение проблемы с заказчиком. На этом данный этап уже должен закончиться! Не нужно сразу давать ответ по заданному вопросу. Необходимо ввести пример в пользовательском режиме, посмотреть актуальную пользовательскую инструкцию по данному вопросу.
    • Ответ на простые обращения пользователя, в правильности которых сотрудник первой линии уверен. Если в инструкции найден четкий ответ на заданный вопрос, его необходимо озвучить клиенту. При этом необходимо дать ссылки на инструкции.
    • Обеспечение второй линии поддержки дополнительной информацией по сложным вопросам, а также по требующим разработки задачам. Этот этап возникает, если решить вопрос не удалось, либо по заявке требуется доработка. Задача сотрудника первой линии поддержки составить:
  • Максимально подробное описание проблематики;
  • Указать сценарии, для которых актуально обращение;
  • Приложить скриншоты.

 

Чего первая линия поддержки делать НЕ должна:

    • Отвечать на вопросы «по памяти» и «с лёту». Это характеризует не уровень знаний, а уровень безответственности! Ответ на вопрос мог измениться. Например, в связи с изменением концепции и последующей доработкой системы.
    • Стараться закрыть обращения по более сложным вопросам. Для этого есть вторая линия! Задача их обеспечить максимальным количеством информации и сработать как команда. Не надо пытаться «заработать очки»! Вопросы, по которым первая линия может давать консультации, а по которым должна передавать на вторую линию должны быть регламентированы. Всё зависит от предметной области и используемой типовой конфигурации.
    • Не писать ТЗ для разработчиков. Этого делать ни в коем случае нельзя! Связано это с уровнем знаний и навыков первой линии. Обычно это сотрудники с маленьким опытом работы.
    • Не давать ответов по методологическим вопросам! Для этого на проекте есть методолог или архитектор.

Вторая линия поддержки решает следующие задачи:

    • Ответы на более сложные вопросы по описанию от первой линии. Сотрудник второй линии (при необходимости) выясняет недостающие детали у первой линии или у заказчика.
    • Составление ТЗ на разработку. Для этого может потребоваться анализ данных в рабочей базе и консультации с заказчиком. Методологические вопросы необходимо обсудить с методологом. Предлагаемое решение требуется согласовать с архитектором.
    • Актуализация инструкций и FAQ. Это существенно упрощает работу первой линии и повышает качество её работы.

 

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

 

Из всего описанного можем выделить критерии качества поддержки:

  1. Каждая линия поддержки дает грамотный проверенный ответ, старается решить задачу качественно.
  2. Если возникают сложности, необходимо описать всё, что необходимо и передать на следующую линию.
  3. Все линии поддержки соблюдают регламент, и каждая линия решает свой круг вопросов.
  4. Обращение закрывается только после решения вопроса, а не потому, что срок работы по заявке подходит к концу.

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

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

Лучшие комментарии
4. awk 714 30.06.20 17:38 Сейчас в теме
(3)
Учтены не все сценарии работы

Это не ошибка аналитика или архитектора. Это ошибка заказчика. Т.к. приемку проводил он, задачи согласовывал он и описывал задачи то же он (или его представитель). Здесь аналитик или архитектор лишь интерпретаторы.
При наличии формул выдается неверный результат вычисления. Данная проблема возникает при некачественном тестировании со стороны разработчика и консультанта.
Разработчик не может проводить тестирование. И консультант (в идеале) то же (где ж ты идеал?).
При открытии пользовательской формы объекта метаданных (документа, справочника, отчета, обработки) вылетает ошибка. Это самая постыдная ошибка. Говорит она о том, что после последних изменений доработка не тестировалась. Это говорит о низком уровне ответственности со стороны разработчика и излишней его самоуверенности.
Это наиболее частая ошибка при командной разработке. Говорит о неправильном процессе разработки.
Данные приходится вводить в двух разных объектах, или наоборот получать двумя отчетами. Такая проблема появляется, когда связанные задачи решают разные аналитики и разработчики. Если проектированием занимается архитектор – это показатель нехватки опыта в проектировании сложных механизмов.
Это не ошибка, а следствие не правильно выбранного продукта. Кода для магазина из одного человека берут, например, ERP.
Запросы написаны не оптимально
Не оптимально для чего? Как это можно выявить на этапе кодеревью, а не на этапе нагрузочного тестирования (где ты идеал в реальной жизни?)?
Запросы в циклах
Это не всегда зло.
Запрос к физической таблице выполняется в разы дольше, чем к виртуальной таблице
Это трэш. Виртуальная таблица, на то и виртуальная, что строится из реальной и нигде не хранится. Потому запрос к виртуальной таблице есть ни что иное как запрос или несколько запросов к реальной таблице или таблицам.

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

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

Многократное обращение к одному и тому же источнику данных в рамках пакета запросов.
Что такое источник данных в пакете запросов? Почему к нему надо обращаться однократно?

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

То есть кнопки "Проверка модулей" и "Расширенная проверка" - это что то таинственное, загадочное и не знакомое? Они решают 95% таких ситуаций, а остальные 5% можно решить написанием модульных тестов (где ты идеал в реальной жизни?).

При записи или чтении данных используют привилегированный режим. Якобы некогда разбираться какие права у пользователя, проще записать или прочитать без учета прав. Такой подход крайне негативно проявляется при использовании RLS.
И каким образом? RLS накладывает доп. фильтры на запросы. Если их отключить, что негативного произойдет? Я надеюсь вы не оптимизировали запросы посредством RLS, а разграничивали доступ?

Из всего описанного можем выделить критерии качества поддержки:

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

Как объективно определить: "грамотность", "старание", "зарытие при подходе времени"?

срок закрытия заявок и их количество, являются основной для расчета SLA

Нет. Это объективные измеримые показатели, а SLA - это контракт, между поставщиком и потребителем услуги. Каждый такой контракт индивидуален. Поэтому нельзя внеконтекста ответить на вопрос: "Помогает ли в этом популярный SLA?".

Вообще о чем статья я так и не понял. Об ошибках разработки или задачах поддержки?

Что такое качество - не раскрыто.
Почему не приведены определения? Например:

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

ГОСТ 15467-79
Качество — совокупность свойств и характеристик продукции или услуги, которые придают им способность удовлетворять обусловленные или предполагаемые потребности потребителя

ИСО 8402—86
Качество — степень соответствия совокупности присущих характеристик объекта требованиям

ГОСТ Р ИСО 9000-2015
for_sale; karpik666; biimmap; +3 Ответить
Остальные комментарии
Избранное Подписка Сортировка: Древо развёрнутое
Свернуть все
1. barelpro 1161 30.06.20 12:02 Сейчас в теме
Маловато про технические ошибки написано. Понятно что статья обзорная, на это можно сделать скидку.

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

Про быстродействие интерфейсов ничего не сказано, хотя визуальная скорость открытия форм - первое на что обращает внимание пользователь и ухудшает апдекс. Тут и тяжелые расчеты при открытии, и использование серверных процедур вместо клиентских или серверных без контекста, и неоптимальные запросы в динамическом списке. Мало кто используется фоновые задания и кеширование. В общем обширное поле для творчества.
2. awk 714 30.06.20 15:50 Сейчас в теме
Блин, ну как так? Такая хорошая первая часть и такое во второй части. Единственное место с которым согласен это пункт 3, до слов "Из всего описанного можем выделить критерии качества поддержки". Если автору интересно могу расписать...
3. barelpro 1161 30.06.20 16:29 Сейчас в теме
(2) Ну что уж тут жалеть, каждый делиться своим опытом, кто что успел пройти.
Мне интересно, распишите пожалуйста
4. awk 714 30.06.20 17:38 Сейчас в теме
(3)
Учтены не все сценарии работы

Это не ошибка аналитика или архитектора. Это ошибка заказчика. Т.к. приемку проводил он, задачи согласовывал он и описывал задачи то же он (или его представитель). Здесь аналитик или архитектор лишь интерпретаторы.
При наличии формул выдается неверный результат вычисления. Данная проблема возникает при некачественном тестировании со стороны разработчика и консультанта.
Разработчик не может проводить тестирование. И консультант (в идеале) то же (где ж ты идеал?).
При открытии пользовательской формы объекта метаданных (документа, справочника, отчета, обработки) вылетает ошибка. Это самая постыдная ошибка. Говорит она о том, что после последних изменений доработка не тестировалась. Это говорит о низком уровне ответственности со стороны разработчика и излишней его самоуверенности.
Это наиболее частая ошибка при командной разработке. Говорит о неправильном процессе разработки.
Данные приходится вводить в двух разных объектах, или наоборот получать двумя отчетами. Такая проблема появляется, когда связанные задачи решают разные аналитики и разработчики. Если проектированием занимается архитектор – это показатель нехватки опыта в проектировании сложных механизмов.
Это не ошибка, а следствие не правильно выбранного продукта. Кода для магазина из одного человека берут, например, ERP.
Запросы написаны не оптимально
Не оптимально для чего? Как это можно выявить на этапе кодеревью, а не на этапе нагрузочного тестирования (где ты идеал в реальной жизни?)?
Запросы в циклах
Это не всегда зло.
Запрос к физической таблице выполняется в разы дольше, чем к виртуальной таблице
Это трэш. Виртуальная таблица, на то и виртуальная, что строится из реальной и нигде не хранится. Потому запрос к виртуальной таблице есть ни что иное как запрос или несколько запросов к реальной таблице или таблицам.

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

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

Многократное обращение к одному и тому же источнику данных в рамках пакета запросов.
Что такое источник данных в пакете запросов? Почему к нему надо обращаться однократно?

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

То есть кнопки "Проверка модулей" и "Расширенная проверка" - это что то таинственное, загадочное и не знакомое? Они решают 95% таких ситуаций, а остальные 5% можно решить написанием модульных тестов (где ты идеал в реальной жизни?).

При записи или чтении данных используют привилегированный режим. Якобы некогда разбираться какие права у пользователя, проще записать или прочитать без учета прав. Такой подход крайне негативно проявляется при использовании RLS.
И каким образом? RLS накладывает доп. фильтры на запросы. Если их отключить, что негативного произойдет? Я надеюсь вы не оптимизировали запросы посредством RLS, а разграничивали доступ?

Из всего описанного можем выделить критерии качества поддержки:

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

Как объективно определить: "грамотность", "старание", "зарытие при подходе времени"?

срок закрытия заявок и их количество, являются основной для расчета SLA

Нет. Это объективные измеримые показатели, а SLA - это контракт, между поставщиком и потребителем услуги. Каждый такой контракт индивидуален. Поэтому нельзя внеконтекста ответить на вопрос: "Помогает ли в этом популярный SLA?".

Вообще о чем статья я так и не понял. Об ошибках разработки или задачах поддержки?

Что такое качество - не раскрыто.
Почему не приведены определения? Например:

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

ГОСТ 15467-79
Качество — совокупность свойств и характеристик продукции или услуги, которые придают им способность удовлетворять обусловленные или предполагаемые потребности потребителя

ИСО 8402—86
Качество — степень соответствия совокупности присущих характеристик объекта требованиям

ГОСТ Р ИСО 9000-2015
for_sale; karpik666; biimmap; +3 Ответить
5. for_sale 854 01.07.20 17:40 Сейчас в теме
Вторая часть марлезонского балета? Очередной графоман на форуме, только с потугами на техническую часть, хотя на деле понятия не имеет, как должен вестись проект. А всем несогласным ещё и ходит минусы лепит)
Оставьте свое сообщение

См. также

Про спагетти, или как исследовать бизнес-процессы организации Промо

Техническое задание Управление бизнес-процессами (BPM) Управление проектом Бесплатно (free)

Многие руководители предприятий не обладают полной картиной происходящего в собственных производственных подразделениях. Они знакомы с организационной структурой, направлениями деятельности, общими экономическими показателями. Если по результату получилась прибыль, то наступает уверенность успеха. Но есть ли на рынке предприятия, которые длительное время удерживаются в "слепом" режиме управления?

23.02.2017    27003    0    Gavrik    10    

Кто такой архитектор? Системный или функциональный? Статья 1

Конфигурирование 1С Проектирование Бесплатно (free)

В связи с повальным непониманием того, как устроен процесс разработки в сфере 1С и кто за что отвечает, будут написаны 8 статей. Это первая статья. Она очень актуальна, т.к. многие проектные команды не имеют архитектора, либо используют его не по назначению. В этой статье раскрываю роль архитектора и его значимость. Основываюсь на своём опыте (более 10 лет), также изучал статьи на эту тему от коллег и консультировался с руководителями крупных команд. В данной статье будут раскрыты следующие вопросы: 1. Кто такой архитектор? 2. Какие задачи выполняет архитектор? 3. Можно ли без него обойтись? 4. Чем отличается системный архитектор от функционального архитектора? 5. Кто главный: РП или архитектор? Кому подчиняется проектная команда?

30.06.2020    2181    0    biimmap    44    

Находим взаимопонимание с заказчиками с применением Enterprise Architect

Проектирование Управление взаимоотношениями с клиентами (СRM) Управление бизнес-процессами (BPM) Бесплатно (free)

Enterprise Architect – мощное средство моделирования бизнес-процессов и информационных систем. Сергей Наумов на мастер-классе конференции Infostart Event 2019 Inception показал, как моделировать бизнес-процессы и составлять понятные заказчику документы при внедрении 1С-систем с помощью Enterprise Architect. Материалы мастер-класса будут полезны как разработчикам на платформе 1С, так и аналитикам, участвующим во внедрении.

19.06.2020    1556    0    SergeyN    0    

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

Техническое задание Бесплатно (free)

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

28.05.2020    6669    0    sapervodichka    69    

Как оценивать задачи программисту 1С Промо

Техническое задание Россия Бесплатно (free)

Оценивать задачу всегда сложно. У меня не всегда получается оценивать задачи адекватно (во всяком случае, не всегда моё ощущение адекватности совпадает с ощущениями других участников процесса). Именно по причине того, что вопрос для меня актуальный, хочу поделиться своими размышлениями, субъективным опытом в этом вопросе. Речь пойдет только о технической оценке.

11.08.2016    32920    0    SamBadi    52    

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

Управление проектом Agile (XP, SCRUM, Канбан) Бесплатно (free)

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

18.05.2020    9599    0    MariaTemchina    33    

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

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

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

21.03.2020    2374    0    oleynik.dv    7    

RPA (роботизация) – "костыль" или автоматизация будущего? Идеи и практические примеры

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

Автоматизация действий пользователя упрощает интеграцию с внешними системами, сокращает рутинную работу, делает бизнес-процесс более контролируемым. О подходе Robotic Process Automation (RPA), случаях, когда его можно использовать, существующем рынке RPA-систем, на конференции Infostart Event 2019 Inception рассказал CTO компании WiseAdvice Олег Филиппов.

10.03.2020    3888    0    comol    1    

ГОСТ 34.602-89. ТЕХНИЧЕСКОЕ ЗАДАНИЕ НА СОЗДАНИЕ АВТОМАТИЗИРОВАННОЙ СИСТЕМЫ Промо

Техническое задание Россия Бесплатно (free)

Настоящий стандарт распространяется на автоматизированные системы (АС) для автоматизации различных видов деятельности (управление, проектирование, исследование и т. п.), включая их сочетания, и устанавливает состав, содержание, правила оформления документа «Техническое задание на создание (развитие или модернизацию) системы» (далее - ТЗ на АС). Дата введения с 01.01.1990г

29.06.2005    36335    0    support    11    

Технология разветвлённой разработки, использующая git, ci/cd

CI/CD Git (GitHub, GitLab, BitBucket) Методология управления разработкой EDT 1С:Франчайзи, автоматизация бизнеса Россия Бесплатно (free)

Адаптация и расширение требований к разветвлённой разработке с использованием git и ci/cd, основанное на стандартах 1С

24.02.2020    4997    0    check2    10    

1С СППР, как инструмент по внедрению, разработке и сопровождению информационных систем

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

Система проектирования прикладных решений (СППР) – инструмент от фирмы «1С», который позволяет проектировать конфигурации, вести по ним полную документацию в разрезе объектов системы, собирать требования на реализацию и выдавать на их основе детально описанные задачи программистам. Как правильно использовать СППР при работе с многосоставной командой, на конференции Infostart Event 2019 Inception рассказал генеральный директор компании «Иритум» Роман Кальмансон.

09.01.2020    5698    0    roman72    0    

1С: СППР и оценка сроков и стоимости проектов методом COCOMO II

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

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

06.01.2020    3342    0    roman72    9    

Направления работы программиста 1С Промо

Техническое задание Бесплатно (free)

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

08.11.2012    43213    0    adhocprog    58    

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

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

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

26.12.2019    7730    0    Mistress_A    28    

Vanessa Automation + СППР

Vanessa Automation СППР v8 Бесплатно (free)

Vanessa Automation. Использование автоматизированного тестирования в СППР.

07.11.2019    10876    0    SvVik    14    

Модернизация КА 2.4 под маркетинговую компанию. Часть 1

Управление взаимоотношениями с клиентами (СRM) Техническое задание v8 КА2 Россия УУ Бесплатно (free)

Выполнил для компании, которая занимается маркетингом и продвижением продуктов, проектирование и модификацию конфигурации КА 2.4 и справочника «Проекты». Теперь в конфигурации «Проекты» имеют особенную роль и на основании выполненной доработки руководство компании принимает решения по продолжению, закрытию или продвижению проекта/ов, поиск путей решения возникающих вопросов. При необходимости доработку можно реализовать под ERP конфигурацию. Архитектура решения выполнена «рядом» с основной конфигурацией. В настоящее время конфигурация поддерживается, модификация ведется в актуальной версии КА 2.4.10 на платформе 8.3.14.1630.

29.10.2019    5738    0    BraunAlex    1    

Есть 2 подхода к внедрению информационных систем. На примере 1С УПП 8 Промо

Управление проектом Техническое задание v8 УПП1 Россия Бесплатно (free)

С детальным ТЗ? Или без серьезного ТЗ? Какой лучше? И где успех более вероятен?

26.01.2012    55618    0        54    

Мастер-класс СППР

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

Сергей Наумов, в прошлом разработчик подсистемы бюджетирования в конфигурации «1С:ERP», на мастер-классе конференции INFOSTART EVENT 2018 EDUCATION поделился опытом управления проектами с помощью «1С:Системы проектирования прикладных решений» и показал, как использовать эту программу в работе над разными задачами: для сбора, классификации и хранения требований; для управления разработчиками и консультантами; в качестве системы документирования; в качестве баг-трекера на этапе опытно-промышленной эксплуатации.

30.08.2019    10513    0    SergeyN    6    

Impact mapping: чем он может быть вам полезен

Техническое задание Бесплатно (free)

Привет, коллеги! Сегодня хочу поговорить про один из инструментов Владельца продукта - Impact mapping (карта влияния). Чем он хорош и почему его стоит использовать.

26.07.2019    6136    0    slozhenikin_com    14    

[Заметки] Scrum за 5 минут

Agile (XP, SCRUM, Канбан) Бесплатно (free)

Первый опыт создания статьи в сообществе. Немного о Scrum и нашем знакомстве.

20.11.2018    8045    0    leobrn    11    

Как проектировать отчетность

Техническое задание Управление проектом Управленческие v8 УУ Бесплатно (free)

Эта статья написана по итогам мастер-класса для руководителей проектов и аналитиков, в рамках перехода на продуктовый подход к разработке. В ней мы постарались ответить на вопрос: "Как снизить риск потери доверия к данным информационной системы со стороны топ-менеджмента, грамотно выстроив процесс проектирования и разработки отчетности?"

16.10.2018    9101    0    weissfeuer    2    

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

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

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

03.10.2018    15777    0    roman72    19    

Управление отделом разработки с помощью "1С:СППР"

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

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

20.08.2018    15401    0    pau74    11    

На чьей стороне мячик? Алгоритм определения исполнителя задачи

Техническое задание Управление бизнес-процессами (BPM) Бесплатно (free)

Я считаю, что мало кому удалось избежать ситуации, когда его назначали исполнителем работы, мягко скажем, не его уровня. На мой взгляд, такое особенно часто встречается среди технических специалистов. Причем, в случае возражения, обычным аргументом противоположной стороны является: "Нам так раньше всегда делали!". Эта публикация является попыткой описать формализовано процесс определения исполнителя с точки зрения логики. Посвящается тем, кто, будучи невежественным в вопросе, смеет указывать, кому его решать. А также тем, кто это терпит.

14.08.2018    7236    0    itriot11    42    

Первый шаг к успешному проекту автоматизации

Техническое задание Управление бизнес-процессами (BPM) Управление проектом Россия Бесплатно (free)

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

30.03.2018    10120    0    Aprsoft    1    

Должностная инструкция специалиста по 1С

Техническое задание Бесплатно (free)

Описание функциональных обязанностей для трёх категорий специалистов 1С: Администратор платформы, Программист, Администратор конфигурации (Методист).

14.12.2017    25223    0    Vikki-di    20    

Внедрение МСФО: план-график выполнения проекта по автоматизации МСФО

Техническое задание Управление проектом МСФО (GAAP) МСФО (GAAP) БУ Бесплатно (free)

В данной статье будут детально рассмотрены задачи, которые предстоит выполнить в процессе запуска проекта автоматизированной подготовки отчетности МСФО

23.10.2017    9994    0    user743750    0    

Систематизация опыта подготовки технического задания

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

Решил «закинуть» на портал свою статью пяти-шестилетней давности. Статья писалась для внутреннего употребления в нашей компании – обобщил и систематизировал свой опыт. Думаю, кому-то она будет полезной. В процессе подготовки статьи немного отредактировал первоначальный вариант.

26.04.2017    23967    0    Soliton    33    

Концепция автоматизации многопрофильного Холдинга в системе АУБ на платформе 1С

Техническое задание Управление проектом Финансовый учет и бюджетирование (FRP) Управление холдингом (CPM) Учетная политика Бухгалтерский учет Управленческий учет (прочее) Финансовый учет и бюджетирование (FRP) Управление холдингом (CPM) Учетная политика v8 Россия УУ Бесплатно (free)

Это схема и обоснование концепции системы АУБ (Автоматизация Управления Бизнесом, авторская разработка) для автоматизации многопрофильного холдинга на платформе 1С. Система изначально проектировалась для многопрофильного холдинга, что определило особенность ее концепции - три уровня автоматизации. Система АУБ не является готовым решением, это определенная концепция (видение, подход) к автоматизации управленческого учета и расширяемый базис наработок реализованных в этой концепции. В конкретном проекте автоматизации, с учетом специфики управления предприятием, делается индивидуальная «функциональная сборка» с использованием готовых, существенно модифицируемых и заново разрабатываемых подсистем. Таким образом, концепция и расширяемый базис наработок системы АУБ, представляют своего рода конструктор, из которого компонуется решение в конкретном проекте, при этом заново разрабатывается лишь функционал, отражающий новую специфику. На практике концепция использовалась, например, в отраслевом решении для производства ЖБИ и добычи нерудных материалов.

02.03.2017    18286    0    aaw    3    

Как самим написать техническое задание

Техническое задание Россия Бесплатно (free)

Как показывает практика, под заветной аббревиатурой «ТЗ» понимаются совершенно разные по сути, содержанию, оформлению и детализации документы. 

21.02.2017    14241    0    user694964_olamikyw    6    

Проектное внедрение прав доступа в системах 1С

Техническое задание Управление бизнес-процессами (BPM) Управление проектом v8::Права 1cv8.cf Бесплатно (free)

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

17.01.2017    17343    0    Gavrik    4    

Наблюдения, которые указывают на решимость предприятия к изменениям

Техническое задание Управление бизнес-процессами (BPM) Управление проектом Бесплатно (free)

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

06.12.2016    18914    0    Gavrik    19    

Технические проблемы взрывного роста компании

Техническое задание Управление проектом Бесплатно (free)

Хочу рассказать об очень интересном проекте, с которым мы недавно столкнулись. В этом проекте необходимо было сделать огромный объем работы за очень короткий промежуток времени, поэтому мы его условно назвали «Марафон со спринтерской скоростью».

26.09.2016    14305    0    R.Tsarenko    27    

Дропшиппинг или "виртуальные" склады поставщиков в 1С

Техническое задание Оптовая торговля Розничная торговля Учет ТМЦ Оптовая торговля Розничная торговля Учет ТМЦ v8 УТ10 УУ Бесплатно (free)

Сейчас всё больше компаний работают по системе дропшиппинг (прямые поставки, когда поставщик отправляет товар непосредственно клиенту, а не продавцу) или продают товар со склада поставщика не закупая его себе на склад (под конкретные заказы покупателей). При этом за частую есть необходимость хранения остатков и цен поставщика, выгрузки их на сайты и другие информационные ресурсы, рассылки в своих прайс листах. В статье рассматриваются варианты отражения подобных операций в управленческих конфигурациях 1С без привязки к конкретной конфигурации. С некоторыми различиями данные схемы можно применить в Управлении торговлей 10 и 11, Рарус:Альфа-авто, Комплексной автоматизации, УПП и др. т.е. в целом в любой конфигурации с возможностью ведения управленческого учета и механизма заказов.

02.09.2016    28005    0    de0nis    17    

Как заставить разработки работать

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

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

30.03.2016    21064    0    liurn    26    

Предприятие требует проект автоматизации? Начните правильно!

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

На нулевом этапе мы не имеем никакого представления о порядке работ, бюджете и сроках достижения статуса «Работает как надо!». Единственное, чем мы можем обладать, — пониманием, что бизнес-процесс работает неэффективно. К сожалению, часто руководители этого не видят или не хотят видеть. Работу необходимо начинать с составления Технических требований проекта 1С автоматизации (оптимизации или бережливого производства).

23.12.2015    23672    0    Gavrik    5    

Большой проект: документация

Техническое задание Управление проектом Бесплатно (free)

Оставим за рамками нашей темы поиск потенциального клиента. Мы его нашли. Вот он - Большой клиент. Чего мы хотим? Хотим заработать. И чтобы этот Большой клиент был у нас не один. А к нам большинство таких клиентов пришли по рекомендации, а для рекомендаций положительных нужно, чтобы Большой клиент был очень доволен сотрудничеством с нами. Но и мы хотели бы быть довольны работой с ним. Вот о том, какими документами мы этого добиваемся, я и попытаюсь рассказать. *** Статья написана на основе доклада, прочитанного на Конференции IE 2013 Revolution (7-8 ноября 2013 года). Также она опубликована в журнале Инфостарта № 3

23.03.2015    20603    0    UR1    5    

Проектирование в 1С на практике. 1С:СППР.

СППР Бесплатно (free)

Статья по докладу на конференции Infostart Event (2013).

28.04.2014    53460    0    comol    47    

Автоматизация работы фрилансера

Техническое задание Управление взаимоотношениями с клиентами (СRM) Управление проектом Управление взаимоотношениями с клиентами (СRM) УУ Бесплатно (free)

Появилось желание рассказать о социальном интранете - Битрикс24. Я опишу опыт внедрения и использования данного продукта от лица фрилансера 1С.

25.09.2013    25291    0    randa    45    

Алгоритм работы с техническим заданием заказчика

Техническое задание Бесплатно (free)

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

24.09.2013    33101    0    Neti    21    

Пример ТЗ и ТП на небольшую доработку

Техническое задание v8 БП2.0 Россия Бесплатно (free)

Привожу пример технического задания и технического проекта на небольшую доработку к БП. Документы делались исходя из схемы: Обследование- ТЗ - ТП - Разработка.

14.12.2012    63085    0    SergAn    10