# БИБЛИОТЕКА Статистика Требования в проектах Redmine Управление Стейкхолдеры Информация Саморазвитие Логика, интеллект Социальные связи Экономика и общество ТЕСТИРОВАНИЕ Книги и ссылки QA и QC Этапы тестирования Тест план Тестовые случаи Баг-репорт Метрики Уровни тестирования Виды тестирования Шаблоны документов XPATH Безопасность Нагрузочное Android Автоматизация Selenium WebDriver Генератор ИНН и т.п. РАЗРАБОТКА Ресурсы Цикл разработки ПО Continuous Integration OOP - базис Frontend HTTP/REST основы Apache web-server Регулярные выражения git Javascript Perl Python Ruby Rust Полезности в Windows LINUX Ресурсы права, юзеры и группы crontab IP tables SSH консоль (терминал) tips & tricks useful apps БАЗЫ ДАННЫХ SQL MongoDB
Эта страница:
- Чтиво - Тезисы - Типичные проблемы - Процессный подход с точки зрения кибернетики - PERT/GERT
Этот раздел:
БИБЛИОТЕКА Управление Стейкхолдеры Информация Саморазвитие Логика, интеллект Социальные связи Экономика и общество
Разделы:
# MONGO DB SQL РАЗРАБОТКА БИБЛИОТЕКА LINUX ТЕСТИРОВАНИЕ
Управление
Выражаю некоторое опасение, что вмешательство невежд в процессы, которых они не понимают даже примерно, очень вряд ли может привести к каким-то положительным результатам.
Чтиво
Тезисы

Тезисы:

  • управлять процессами, а не людьми - наладить процесс проще, чем уследить за всеми
  • уметь говорить "нет"
  • уважать членов команды и их потребности
  • анализировать инциденты и предпринимать меры для неповторения их в будущем
  • планирование. Стратегическое на год, разбитое на оперативное и тактическое на квартал/месяц/недели
  • критикуя - предлагай, предлагая - делай, делая - отвечай
  • не можешь достичь цели — смени подход
  • уважение добывается успешным решением сложных задач
  • никогда не обсуждаем личность и поведение, обсуждаем только объекты:
    • проекты
    • цели
    • деятельность
    • навыки
    • результаты
    • смыслы
    • ценности

Кто руководит? Кто капитан?

  • Тот, кто задаёт вопросы.
  • Тот, кто умеет слушать и слышать
  • Тот, кто следит за временем
  • Тот, кто обеспечивает коммуникацию - разговор по делу - между всеми участниками
  • Тот, кто следит за постоянным движением содержания

Матрица срочности и важности дел:
матрица срочности и важности дел

Типичные проблемы

Проблемы:

  • замедление роста, невидимый "потолок"
  • эмоциональное выгорание управленцев
  • снижение вовлечённости
  • низкая ответственность
  • "хаки" регламентов и KPI
  • активизация внутренних/внешних конкурентов
  • стратегические инициативы буксуют на уровне менеджеров

Причины:

  • все нужные навыки известны, но не применяются
  • знания и экспертиза приобретаются, и растрачиваются
  • отлично тушим пожары -- но нет профилактики
  • тонем в текучке - "Мы очень-очень-очень заняты!!"
  • "не хотим думать, хотим чтобы нас натренировали"

Корневая причина:

- Всем такая ситуация нравится.
Т.е. система достигает некоего баланса, а перемены начинают восприниматься участниками резко "в штыки".
Процессный подход с точки зрения кибернетики
Процесс можно представить в виде "следящей" кибернетической системы управления, которая основана на модели представления системы как управляющего Субъекта Управления и Объекта Управления: ( скачать схему в XML )

Процесс (лат. processus - продвижение) -- управляемая система действий, которая использует ресурсы для преобразования входящего в выходящее.
Входящее и выходящее в процессе могут быть материальными или нематериальными.
Выходящее из процесса (его результат) в общем виде называют продуктом процесса.

В системе менеджмента процессы условно подразделяют на:

  • управляющие
  • производственные
  • обеспечивающие
Такая классификация также соответствует классификации счетов Плана счетов бухгалтерского учета, что упрощает, при необходимости, учёт затрат по процессам.

В общем виде процесс представляет собой систему входящих в него подпроцессов, получаемых при декомпозиции этого процесса.
Операция - процесс, декомпозиция которого невозможна либо нецелесообразна.

В общем виде ресурсы бывают:

  • ВРЕМЯ
  • материальные
  • финансовые
  • кадровые/трудовые
  • юридические
  • административные
  • информационные
  • методические

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

Задаются:

  • параметры входных потоков (значения и направление)
  • требуемая функция преобразования (определение целей и задач процесса)

Управление процессом должно быть направлено на уменьшение вариабельности (изменение параметров отдельных единиц продукции процесса) или, по крайней мере, поддержанию вариабельности продукции в допустимых границах.

Система менеджмента при управлении процессами основана на цикле Деминга Plan-Do-Check-Act:

  1. ПЛАНИРОВАНИЕ. Реализуется Субъектом Управления (Измеритель Рассогласования + Управляющий Регулятор).
    Производится установка стандартов, т.е. конкретных, поддающихся измерению целей, имеющих временные границы. Для управления необходимы стандарты в форме показателей результативности объекта управления для всех его ключевых областей, которые определяются при планировании. Требуемый уровень показателей процесса часто задают в виде ключевых показателей эффективности (KPI).
    Определяется масштаб допустимых отклонений. В соответствии с принципом исключения, только существенные отклонения от заданных стандартов должны вызывать срабатывание системы контроля, иначе она станет неэкономичной и неустойчивой.
  2. ОСУЩЕСТВЛЕНИЕ. Реализуется Объектом Управления.
    Вместе с управляющим действием на Объект Управления поступает вектор возмущений внешней среды, поэтому векторы параметров выходных потоков отклоняются от заданных значений. Действие внешних и внутренних факторов системы менеджмента являются причиной вариабельности процесса и его продукции.
  3. ПРОВЕРКА. Реализуется Обратной Связью и Измерителем Рассогласования.
    Обратная связь в реальных системах менеджмента имеет следующие особенности:
    - Она не является "чисто" обратной, так как орган управления может принимать дополнительные решения в процессе реализации ранее принятых и реализуемых управляющих действий ("прямая связь") до получения информации с общего контура Обратной связи;
    - Она должна быть пороговой, отсекающей незначительные несоответствия.
    Отсутствие порогов в Обратной Связи экономически не целесообразно, так как стоимость системы сбора и анализа информации может превысить стоимость производства и/или затруднить управление системой.
    В системе менеджмента функции Измерителя Рассогласования и Обратной Связи выполняет мониторинг. Мониторинг это процесс постоянного контроля, надзора, наблюдения или иного определения показателей процесса в целях выявления их критических изменений от требуемого или ожидаемого уровня.
    Измерение результатов является обычно довольно трудным (особенно если продукция - услуги) и дорогостоящим.
  4. КОРРЕКТИРОВКА. Реализуется Субъектом Управления (Измеритель Рассогласования + Управляющий Регулятор).
    Измеритель Рассогласования - сравнивает параметры ВХодных и ВЫХодных потоков от цепи Обратной Связи и передаёт значение рассогласования системы на Управляющий Регулятор (орган управления).
    • Сравнивая измеренные результаты с заданными стандартами, на основе анализа можно определить, какие действия необходимо предпринимать. Такими действиями могут быть изменение некоторых внутренних переменных системы, изменение стандартов или невмешательство в работу системы.
    • В зависимости от значения рассогласования и информации от вектора управляющих воздействий на процесс Управляющий Регулятор вырабатывает соответствующее управляющее действие для уменьшения рассогласования (коррекция и корректирующие действия) или для получения новых значений выхода и передает его на Объект Управления.
    • Вместе с этим Управляющий Регулятор проводит анализ и оценку рисков в системе и по ее результатам разрабатывает проактивные мероприятия, направленные на предотвращение потенциально возможных негативных действий выявленных опасных факторов.

Контроль

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

Процесс контроля обычно разбивают на следующие фазы:

  • Предварительный контроль. На стадии ПЛАНИРОВАНИЕ.
    Направлен на проверку адекватности выбранной модели, адекватности планирования и обеспеченности процесса всеми видами ресурсов.
  • Текущий контроль. На стадии ОСУЩЕСТВЛЕНИЕ.
    Обычно производится в виде контроля работы подчинённого его непосредственным начальником.
  • Окончательный/Заключительный контроль. На стадии ПРОВЕРКА.
    Осуществляется после того, как работа закончена или истекло отведенное для неё время.

В качестве основы был использован ресурс Процессный подход с точки зрения кибернетики. Олег Кольцов, 17.03.2015 в 12:18.
PERT/GERT

Program (Project) Evaluation and Review Technique (сокращённо PERT):

Если озадачиться оценкой затрат времени на тестирование, то стоило бы посмотреть в сторону PERT/GERT, critical path method (CPM).
Буржуи начали это всё разрабатывать и использовать ещё во Вторую Мировую, а затем для проектов NASA. Строгая логическая и математическая база, без всякого словоблудия.

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

Для нашего конкретного случая (оценка времени на тестирование доработки, части проекта, целого проекта и чёрта в ступе), обязательными и необходимым условиями являются:

  1. определиться, тестируем по функционалу или-таки по компонентам системы
  2. (самое сложное в наших условиях) обеспечивать как можно более ранней и полной информации по проекту/доработкам.
    Привет аналитика + базы знаний (JRIA Confluence?) + максимально оперативное взаимодействие между ключевыми подразделениями/личностями.
  3. собрать статистику по времени тестирования текущего функционала/компонента. Привет плагин Kanoah для JIRA?
  4. собрать статистику по частоте появления багов в том или ином функционале/компоненте.
    Привет ишьи в JIRA и плагин Kanoah к ней?
  5. научиться быстро прикидывать ориентировочное время на тестирование (и время на фикс!) нового функционала/компонента.
    Привет аналитика + обратная связь от разработчиков в деле фиксирования затрат рабочего времени на тот или иной функционал/компонент.
"Внезапно", это всё непросто и требует времени.

Как это всё дело видится.

На входе составляется матрица задач и прикидывается время. Графически получаем нечто навроде этого: Что имеем на входе.png

Потом путём пропуска всего этого через определённые формулы (возможно, понадобится разработать или украсть готовый программный комплекс, но там несложные в принципе формулы, изложенные например тут)
ПОЛУЧАЕМ на выходе:

  • вероятности не- и успеха тестирования сборки/спринта/проекта
  • (что самое главное) - конкретные величины временных рамок по каждому вероятному исходу
Выглядеть это будет примерно так: Результат. Что имеем на выходе.

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

По факту на выходе получем примерные сроки/затраты, которые так любит Бизнес.
Понятно, что осознание пи*деца текущей ситуации и инициатива к внедрению должна исходить сверху, иначе всё бесполезно и браться не стоит.

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

Записки, 2017 год