Что такое качество разработки и качество поддержки? Статья 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 718 30.06.20 17:38 Сейчас в теме
(3)
Учтены не все сценарии работы

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ГОСТ Р ИСО 9000-2015
alest; for_sale; karpik666; biimmap; +4 Ответить
6. MamZhan 03.08.20 09:25 Сейчас в теме
Дайте пожалуйста ссылку на 1 часть.
Или лучше в статье указывать ссылки на части очень удобно.
Оставьте свое сообщение

См. также

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

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

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

23.02.2017    27566    Gavrik    10    

Стыд и Скрам: взгляд глазами собственника из IT-шников

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

Не все, кто употребляют понятия Agile и Scrum, понимают, что они означают. О том, насколько в реальном мире автоматизации бизнеса на платформе 1С применимы гибкие подходы к разработке ИТ-продуктов на конференции Infostart Event 2019 рассказал основатель и соучредитель группы компаний WiseAdvice Иван Тягунов.

18.09.2020    413    IvanAT1981    0    

Интеграция с Трелло. Готовый код

Обмен данными 1С Интеграция Agile (XP, SCRUM, Канбан) v8 Бесплатно (free)

Код основных действий, интеграция с API Трелло.

19.08.2020    1988    Yashazz    14    

Придет владелец продукта и решит все вопросы бизнеса!

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

Практически во всех крупных проектах есть отдельная роль – владелец продукта. Все чаще ее выполняют аналитик либо представители бизнеса, но насколько эффективно они работают, мало, кто задумывается. О том, что должен делать Product Owner, и какие ошибки чаще всего совершают такие специалисты, на конференции Infostart Event 2019 Inception рассказал управляющий партнер и Agile Coach компании Scrumtrek Иван Селеверстов.

24.07.2020    2195    iseleverstov    0    

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

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

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

11.08.2016    33792    SamBadi    54    

Видеозаписи открытых вебинаров Марии Темчиной

Методология управления разработкой Бесплатно (free)

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

21.07.2020    2366    MariaTemchina    1    

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

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

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

30.06.2020    5855    biimmap    47    

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

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

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

19.06.2020    2673    SergeyN    0    

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

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

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

29.06.2005    36731    support    11    

Закрытие проекта или фазы. Завершение курса по управлению проектами

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

Это заключительная часть курса по управлению проектами от Ивана Селиховкина. И прежде чем перейти к теме закрытия, давайте разберемся, что такое фаза проекта.

12.06.2020    2054    Selikhovkin    0    

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

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

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

28.05.2020    8282    sapervodichka    70    

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

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

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

18.05.2020    10598    MariaTemchina    33    

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

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

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

08.11.2012    43683    adhocprog    58    

"Выключай телевизор", или Три мифа современного проектного управления

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

В последние несколько лет у коучей доминируют убеждения о вреде иерархий, необходимости перейти на гибкие режимы управления, отказаться от операционного менеджмента. Насколько такое мнение неверно и даже опасно, рассказал на конференции INFOSTART EVENT 2019 Inception сооснователь СПБ PMI Иван Селиховкин.

10.04.2020    2463    Selikhovkin    5    

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

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

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

21.03.2020    2826    oleynik.dv    7    

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

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

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

10.03.2020    4584    comol    1    

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

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

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

26.01.2012    64304        54    

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

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

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

24.02.2020    5732    check2    10    

7-ой PMBoK - конец классического проектного управления? Часть 1-ая

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

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

23.01.2020    13731    MariaTemchina    8    

Что можно назвать проектом, а что нельзя, и каковы критерии успеха менеджера. Курс по управлению проектами, часть 1 Промо

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

Начало курса Ивана Селиховкина по проектному управлению. Разберемся: что такое проекты в классическом понимании, почему строительство египетских пирамид проектом считать нельзя, почему многие "продуктовые" компании могут обходиться без проектного управления, каковы критерии успеха для руководителя проекта.

30.07.2018    22538    Selikhovkin    40    

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

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

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

09.01.2020    6522    roman72    0    

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

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

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

06.01.2020    3800    roman72    9    

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

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

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

26.12.2019    8465    Mistress_A    28    

Vanessa Automation + СППР

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

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

07.11.2019    12279    SvVik    14    

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

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

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

29.10.2019    6042    BraunAlex    1    

Agile в проектах 1С: где-то между невозможно и неизбежно. Часть вторая

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

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

06.09.2019    6056    MariaTemchina    10    

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

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

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

30.08.2019    11832    SergeyN    7    

Agile в ИТ-проектах: где-то между невозможно и неизбежно

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

Приглашаем к дискуссии по мотивам прошедшего вебинара на тему "Agile и не Agile"

15.08.2019    6811    MariaTemchina    40    

Scrum: серебряной пули не существует

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

Гибкие методологии набирают популярность среди команд разработчиков. Но применять их в том варианте, который предлагается первоначально, не всегда удается. О своем опыте работы по Scrum в условиях, когда нет проектов, рассказал на конференции Infostart Event 2018 Education ведущий разработчик 1С одной из крупнейших торговых сетей Дмитрий Кирилкин.

12.08.2019    5299    dumsik    7    

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

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

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

26.07.2019    6499    slozhenikin_com    14    

Стыд и Скрам, часть вторая

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

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

14.03.2019    11472    MariaTemchina    47    

Стыд и скрам - Чему нас учит Scream Guide

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

Название "Scream Guide" можно вольно перевести на русский как “Вопль ужаса от того, как Scrum применяют на практике”

12.02.2019    9989    MariaTemchina    20    

Подходы к управлению проектами: границы применимости гибких методологий в проектах внедрения

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

В своем докладе Мария Темчина подробно рассказала про то, какие подходы к управлению проектами вообще бывают с точки зрения Project Management Institute, и какие из них применимы при руководстве проектами внедрения 1С.

21.01.2019    7609    MariaTemchina    0    

Черная книга Скрам

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

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

26.11.2018    8268    Selikhovkin    4    

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

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

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

20.11.2018    8548    leobrn    11    

Думать некогда, трясти надо - или что такое ретроспектива в Agile

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

12-ый принцип Agile-манифеста, как известно, гласит: "Каждый раз в конце заранее определенного интервала времени команда размышляет, как повысить результативность своей работы, и затем вносит коррективы в процессы." Попробуем разобраться, как это стоит, а как не стоит делать на практике. 

13.11.2018    10168    MariaTemchina    16    

Приоритизировали, приоритизировали, да не выприоритизировали...

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

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

30.10.2018    8412    MariaTemchina    47    

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

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

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

16.10.2018    9526    weissfeuer    2    

Построение высокоэффективной Agile-команды

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

Меня зовут Асхат Уразбаев, я из компании ScrumTrek. Наша компания помогает внедрять Agile, Scrum, Kanban – гибкие методологии и гибкие подходы. К миру 1С я совсем не принадлежу, но в прошлом я, тем не менее, программист – занимался разработкой на самых разных языках программирования. Помимо основной деятельности у меня было несколько технологических стартапов, в которые я был так или иначе вовлечен. И сегодня мы поговорим о том, как сделать так, чтобы команда была крутой и эффективной.

08.10.2018    7613    askhatu    15    

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

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

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

03.10.2018    16770    roman72    19    

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

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

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

20.08.2018    16354    pau74    11    

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

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

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

14.08.2018    7541    itriot11    42    

Канбан в условиях российской действительности

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

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

08.08.2018    23030    MariaTemchina    64    

Почему Agile превращается в Тяп-ляп. Кто виноват и что делать?

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

В моей практике довольно много историй, когда компании, решившие внедрять гибкие методологии, начинали за здравие (Agile), а кончали за упокой - Do & Fix (делаем, как бог на душу положит). Попробуем разобраться, почему так происходит.

27.07.2018    13042    MariaTemchina    20