Анализ историй пользователей с использованием Google Таблиц

Перевод статьи User Story Insights Using Google Sheets by Tom Martin , Senior Product Manager https://www.metaltoad.com/blog/user-story-insights-using-google-sheets

Для кого: Владельцы продуктов / менеджеры проектов

Что: Использование Google Таблиц в качестве инструмента для сбора показателей пользовательских историй

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

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

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

Копирование шаблона листа

Чтобы использовать и создавать таблицы Google, вам необходимо иметь учетную запись Google и иметь возможность войти в систему и получить доступ к своему Google Диску .

Сделать копию в Google ТаблицахДля удобства здесь доступен образец шаблона, который включает функции и концепции, обсуждаемые в этом посте:

Google Таблицы Истории пользователей [ШАБЛОН]

Перейдите в раздел «Файл» и нажмите «Сделать копию». Это создаст копию шаблона на вашем личном Google Диске, которую вы затем сможете редактировать и манипулировать любым способом, необходимым для соответствия вашим конкретным потребностям.

Лист(ы)

Шаблон включает три листа. Первый лист — это список функций и пользовательских историй, которые будут знакомы тем, кто имеет опыт в упражнениях и артефактах пользовательских историй. На втором листе используется сводная таблица, чтобы быстро понять, какое значение придается определенным функциям. Последний лист принимает различные значения, найденные в столбцах пользовательской истории, для отображения некоторого анализа высокого уровня в форме диаграмм.

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

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

Вот столбцы, которые я собираю в этом шаблоне:

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

Пользовательская история: истории — это фундаментальное средство общения, планирования и переговоров между командой схватки, владельцами бизнеса и владельцем продукта. Каждая история должна следовать принципу «ИНВЕСТИРОВАТЬ» (истории должны быть: независимыми, подлежащими обсуждению, ценными, оцениваемыми, имеющими соответствующий размер, проверяемыми). Один из стандартных форматов — это: «Как {{персона}} я хотел бы {{выполнить действие}}, так что {{причина почему}}». То, как вы строите свои истории, менее критично, чем обеспечение того, чтобы вы отвечали на три вопроса: кто, что и почему.

Приоритет: относительная мера того, когда компания хотела бы, чтобы история была выпущена, по сравнению с другими историями. Это всегда должны предоставлять владельцы бизнеса или заинтересованные стороны. В шаблоне мы допускаем значения 1–4, где 1 — высокий приоритет, а 4 — низкий. Если оставить в стороне дебаты о «упорядоченном» против «приоритезованного», факт остается фактом: за пределами вашей scrum-команды владельцы бизнеса, как правило, обладают определенными функциями, которым из-за сложного политического или внешнего конкурентного давления может потребоваться расставить приоритеты перед другими функциями, которые принесут больше значение пользователя. Конечно, стоит отметить, что во многих проектах грань между приоритетом и значением может быть настолько тонкой, что этот столбец становится избыточным и ненужным.

Ценность: относительная мера того, насколько история обогатит пользовательский опыт при взаимодействии с продуктом. Для простоты мы также допускаем только 4 варианта от 1 до 4, где 1 — высокое значение, а 4 — низкое значение. Способ определения стоимости может отличаться. По возможности старайтесь использовать измеримые показатели или, по крайней мере, учитывайте точку зрения множества заинтересованных сторон.

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

Оценка: относительный объем работы, необходимой для завершения рассказа, по сравнению с другими историями. Это строго принадлежит команде доставки и только группе доставки. На этом этапе проекта вы хотели бы сохранить приблизительные оценки. Помните, что ваша команда по доставке будет продолжать уточнять оценку каждой истории по мере того, как она приближается к включению в активный бэклог спринта. На этом этапе производства я бы рекомендовал использовать метод калибровки «размер футболки» (XSm, Sm, Md, Lg, XLg, XXLg). По мере того, как истории приближаются к бэклогу спринта, команда может захотеть переоценить, используя значения последовательности Фибоначчи в командном программном обеспечении для отслеживания проектов (Jira, VSO и т. Д.), Чтобы повысить точность относительного размера истории.

Релиз: этот столбец предназначен для помощи в уточнении дорожной карты продукта. Этот столбец не следует заполнять для истории до тех пор, пока не будут оценены упомянутые выше столбцы.

Здесь происходит волшебство

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

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

Другие необязательные столбцы: если вы думаете об Agile, будьте гибкими в выборе столбцов, которые, по вашему мнению, добавят ценности вашему процессу. В Google Таблицах вы можете добавить столько столбцов, сколько захотите, в свою копию шаблона и легко скрыть целые столбцы, если они не имеют отношения к конкретному проекту. Возможно, вы захотите отследить, кто запросил историю, какие-либо зависимости или даже какие-то цели приемочного тестирования высокого уровня. В некоторых случаях имеет смысл отслеживать столбец приоритетов для каждой заинтересованной стороны, чтобы пролить свет на противоречивые отзывы владельцев бизнеса. Возможно, вы можете отказаться от «Риска» в пользу отслеживания «Выполнимость».

Вы ограничены только вашей собственной способностью адаптировать шаблон к вашим потребностям в контексте вашего проекта или продукта.

Цветовое кодирование с условным форматированием

Никогда не недооценивайте силу «чистоты». Используя условное форматирование Google Таблиц, мы можем визуально отображать значения, представленные в некоторых из наших столбцов, позволяя читателю сканировать страницу в поисках ценных историй. Или, наоборот, он может визуально выделить те истории, в которых риск плюс затраты перевешивают ценность для бизнеса, которую они создадут.

В шаблоне вы можете увидеть, где каждый столбец использует свой собственный базовый цвет, а затем использует различные оттенки этого цвета для обозначения интенсивности. Например, чем выше значение, тем темнее фон в столбце «Значение» для истории.

Вы можете настроить условное форматирование, выбрав столбец или ячейки и перейдя в меню «Формат» к «Условное форматирование…»

Использование элементов списка проверки данных

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

Чтобы настроить правила проверки, выберите диапазон ячеек и в меню «Данные» перейдите к «Проверка…».

Заставляем лист работать на вас

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

Матрица стоимости / риска

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

=if(AND(OR(D2=»1 High»,D2=»2 Med»),OR(E2=»1 High»,E2=»2 Med»)),»Strategic»,if(AND(OR(D2=»1 High»,D2=»2 Med»),OR(E2=»3 Med»,E2=»4 Low»)),»Leveraged»,if(AND(OR(D2=»3 Med»,D2=»4 Low»),OR(E2=»1 High»,E2=»2 Med»)),»Focused»,if(AND(OR(D2=»3 Med»,D2=»4 Low»),OR(E2=»3 Med»,E2=»4 Low»)),»Routine»,»»))))

//В качестве альтернативы вы можете выполнить поиск в таблице вместо этого сложного вложения условных выражений

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

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

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

Возможно, стоит пересмотреть некоторые решения, чтобы сбалансировать план выпуска и повысить вероятность успешного выпуска.

Расширенные столбцы

Это «секретный соус» этого листа. В шаблоне, если вы посмотрите полностью вправо от заголовка столбца, вы заметите стрелочные индикаторы, обозначающие скрытые столбцы. Если вы развернете эти столбцы, вы найдете несколько столбцов с расчетными данными, в которых используются формулы для преобразования данных из видимых столбцов для использования в наших сводных таблицах и диаграммах анализа.

В шаблоне вы можете видеть, что первые три скрытых поля представляют собой просто целочисленные представления значений, выбранных в столбцах «Приоритет», «Значение» и «Риск». Хотя метки High, Med, Low делают видимые столбцы более удобными для человека, они не подходят для агрегирования и анализа. Создав эту целочисленную копию данных, мы теперь можем легко использовать эту информацию в наших графиках, сводя к минимуму путаницу для любых заинтересованных сторон, просматривающих основные столбцы таблицы.

=IF(C2=»1 High»,1,IF(C2=»2 Med»,2,IF(C2=»3 Med»,3,IF(C2=»4 Low»,4,»»))))

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

=IF(C2=»1 High»,4,IF(C2=»2 Med»,3,IF(C2=»3 Med»,2,IF(C2=»4 Low»,1,»»))))

Помимо этого, то, какие скрытые вычисляемые / агрегированные столбцы вам понадобятся, зависит от вас и от контекста вашей ситуации.

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

Создание представлений фильтров для выпусков

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

Использование сводных таблиц

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

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

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

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

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

Графики аналитики

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

Как и в случае со сводными таблицами, к некоторым из них нужно относиться с недоверием. Я использую приведенные ниже графики для проверки интуиции, «похоже ли, что этот проект будет сбалансирован». Цель здесь не в том, чтобы окончательно регистрировать научную аналитику, а в том, чтобы создать визуально очищаемый интерфейс, который мог бы помочь в обнаружении потенциальных ранних предупреждающих сигналов.

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

Круговые диаграммы

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

Столбчатые диаграммы

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

Диаграммы с областями и линейные диаграммы

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

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

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

Сила обмена

Прозрачность — основа гибких методологий. Общение вокруг пользовательских историй можно дополнительно упростить, поделившись своими таблицами и документами Google с вашим клиентом и заинтересованными сторонами, предоставив им различные степени доступа. Обычно мы разрешаем нашим клиентам оставлять комментарии в любых артефактах Google. Мы Позвольте заинтересованным сторонам оставлять комментарииждем и с энтузиазмом приветствуем комментарии клиентов в наших рабочих документах. Дождаться обратной связи до последней минуты или делать «Большое Разоблачение» — это азартная игра. Вы можете накрыть их носки своей презентацией. Но опять же, если вы этого не сделаете, ставки высоки. Позвольте вашим клиентам войти и побудить их комментировать незавершенные документы между вашими scrum-мероприятиями и встречами.

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

В Google Таблицах вы можете открыть лист своим клиентам, нажав кнопку «Поделиться» в правом верхнем углу. В модальном окне вы сможете добавить столько адресов электронной почты, сколько необходимо, и предоставить им доступ для редактирования, комментирования или только просмотра. Чтобы добавить несколько групп пользователей с разным доступом, просто добавьте одну группу с одним уровнем доступа, затем вернитесь и добавьте другую группу с другим уровнем доступа.

Чем больше людей вы привлечете к Google Sheet, тем меньше людей вы будете передавать устаревшие экспортированные листы Excel. По возможности держите людей в источнике истины; экспорт не должен быть вашим основным средством обмена.

Иногда вам может потребоваться разрешить заинтересованным сторонам войти в документ и попросить их предоставить или редактировать данные только на некоторых листах или в определенных столбцах. Чтобы учесть это, вы можете использовать Защищенные листы и Защищенные диапазоны. Чтобы защитить весь лист, щелкните правой кнопкой мыши вкладку листа и перейдите в Защищенные листы. Чтобы установить разрешения для определенных столбцов листа, выберите столбцы, щелкнув, удерживая Ctrl + щелчок или Shift + щелкнув нужные столбцы, а затем щелкните правой кнопкой мыши, чтобы перейти к кнопке Защищенные диапазоны в контекстном меню. Это расширит область администрирования Protected Sheets and Ranges в правую часть страницы. В каждом определяемом вами диапазоне вы можете установить высокую степень детализации в отношении того, кто может и не может редактировать содержимое в пределах.

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

Продолжая

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

Некоторые дополнительные способы применения некоторых из вышеперечисленных методов:

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

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

Скрытые столбцы будут выглядеть так:
=IF(H2=»1 High»,4,IF(H2=»2 Med»,3,IF(H2=»3 Med»,2,IF(H2=»4 Low»,1,»»))))

А усредненный столбец будет иметь формулу, подобную этой:
=IF(NOT(ISBLANK(A2)), IF(AVERAGEIF(AK2:AQ2, «>0»)>3.5, «1 High», IF(AVERAGEIF(AK2:AQ2, «>0″)>2.5,»2 Med», IF(AVERAGEIF(AK2:AQ2, «>0″)>1.5,»3 Med»,»4 Low»))), «»)

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

Следующие шаги

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

Оригинал — Истории пользователей [ШАБЛОН]

Перевод — Истории пользователей [ШАБЛОН]

Общие принципы построения сетевого графика

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

— предшествующие работы и предварительные условия, при выполнении которых может быть начата проектируемая работа;

— другие работы, которые можно выполнять параллельно с данной работой;

— работы, которые могут быть выполнены только после полного завершения рассматриваемой работы.

Форма графика должна быть простой без лишних пересечений. Большинство работ следует изображать горизонтальными линиями с направлением стрелок слева направо (рис.5.4., а).

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

Рис.5.4. Основные правила построения сетевого графика

При выполнении параллельных дифференцированно зависимых работ должны вводиться зависимости по каждой работе (рис.5.4.в).

Если до начала работы необходимо выполнить работы А и Б, а для начала работы В — только работу А, то вводятся зависимость и дополнительное событие (рис.5.4, г).

В сетевом графике не должно быть «тупиков» (кроме завершающего события), «хвостов» (кроме исходного события) и «циклов» (замкнутых контуров) (рис.5.4, д).

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

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

При укрупнении сетевых графиков (рис.5.5) приняты следующие правила:

Рис.5.5. Укрупнение сетевых графиков:

а — до укрупнения; б — после укрупнения

— группа работ изображается как одна работа, если в этой группе имеется одно начальное и одно конечное события;

— укрупнять в одну работу следует только такие работы, которые закреплены за одним исполнителем (бригадой, участком и т.д.);

— в укрупненную сеть нельзя вводить новые события, которых не было до укрупнения;

— коды событий в укрупненном графике сохраняются такими же, как и в детальном.

Внутриплощадочные строительные работы увязываются с внешними работами (поставки материалов, оборудования и т.п.) (рис.5.6).

Рис.5.6. Варианты символов внешних поставок и работ:

а, б — поставка основного технологического оборудования и строительных конструкций; в, г — то же, электротехнического и сантехнического оборудования; д — монтаж (демонтаж) крана

Внешние работы выделяют графически, при необходимости вводят дополнительные события.

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

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

Этапы построения сетевого графика показаны на рис.5.7.

Рис.5.7. Последовательность построения сетевого графика:

а — первоначальный вариант; б — промежуточный вариант; в — окончательный вариант

При построении СГ степень детализации работ зависит от сложности объектов, количества ресурсов, объемов работ и периода строительства. 

При составлении первичных СГ учитывают следующие рекомендации:

— технология работ должна быть выражена с исчерпывающей полнотой;

— каждая стрелка должна соответствовать отдельной работе, выполняемой бригадой в определенных пространственных границах;

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

Необходимо, чтобы продолжительность работ не превышала продолжительности двух интервалов представления оперативной информации.

Например, если информация предоставляется каждые сутки, работы следует выполнять не более двух дней, при недельном планировании — 14 дней, при месячном — 60 дней.

Принципы построения сетевого графика

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

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

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

Уровень детализации сетевого графика зависит от сложности строящихся объектов, группировки и количества используемых ресурсов, объемов работ и периода строительства.

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

Сетевые модели могут быть детальными и укрупненными, в которых ряд работ заменяется одной укрупненной работой. Кроме того, они делятся на сводные, объединяющие комплексные сетевые графики зданий и сооружений данного объекта: комплексные, охватывающие все работы по возведению данного здания или сооружения и обеспечению ресурсами; частные, объединяющие часть работ, выполняемых на строительстве здания конкретной организацией; первичные – по работам, производимым отдельными исполнителями, например одним из участков строительного управления (первичная сеть является частью соответствующей частной сети).

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

Сетевой график представляет собой сетевую модель с рассчитанными временными параметрами. В основе построения сети лежат понятия «работа» и «событие».

Работа – это производственный процесс, требующий затрат времени и материальных ресурсов и приводящий к достижению определенных результатов. Работу на сетевом графике изображают одной сплошной стрелкой, длина которой не связана с продолжительностью работы. Под стрелкой указывают наименование работы, а над стрелкой – продолжительность работы в рабочих днях и при необходимости количество рабочих в день или смену. Под стрелкой можно показать также сметную стоимость СМР, физический объем работ, исполнители работ и т.д. В зависимости от назначения графика содержание приводимых параметров работы может меняться, но продолжительность и наименование работ указывают всегда.

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

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

События ограничивают рассматриваемую работу и по отношению к ней могут быть начальными и конечными.

Начальное событие определяет начало данной работы и является конечным для предшествующих работ.

Конечное событие определяет окончание данной работы и является начальным для последующих работ.

Исходное событие – событие, которое не имеет предшествующих работ в рамках рассматриваемого сетевого графика.

Завершающее событие – событие, которое не имеет последующих работ в рамках рассматриваемого сетевого графика.

Сложное событие – событие, в которое входят или из которого выходят две или более работы.

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

Критическим путем называют полный путь, имеющий наибольшую длину (продолжительность) из всех полных путей. Его длина определяет срок выполнения работ по сетевому графику. Работы, лежащие на критическом пути, называют критическими. Увеличение продолжительности критических работ увеличивает общую продолжительность работ по сетевому графику.

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

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

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

Основные правила построения сетевого графика

При этом учитывают:

  1. работы, которые должны быть завершены прежде, чем начнется планируемая работа;
  2. работы, которые могут быть начаты после нее, т.е. после данной планируемой работы;
  3. работы, осуществляемые одновременно с плановой работой.

При этом учитывают технологическую и логическую последовательность выполнения работ.

Сетевые графики строят по следующим правилам.

  1. Направление стрелок в сетевом графике следует принимать слева направо.
  2. Форма графика должна быть простой, без лишних пересечений, большинство работ следует изображать горизонтальными линиями.
  3. Если те или иные работы начинаются после частичного выполнения предшествующей, то эту работу следует разбить на части
  4. При изображении поточных работ особое внимание уделяется правильной разбивке работ на захватки и выявлению взаимосвязи смежных работ.
  5. Укрупнение сетей производится с соблюдением следующих правил:
    1. группа работ на сетевом графике может изображаться как одна работа, если в этой группе имеется одно начальное и одно конечное событие;
    2. укрупнять в одну работу следует только такие работы, которые закреплены за одним исполнителем (бригадой, участком и т.д.);
    3. в укрупненную сеть нельзя вводить новые события, которых не было на более детальном графике до укрупнения;
    4. наименование работ в укрупненном графике должно быть увязано с наименованием укрупняемых работ;
    5. коды событий, которые сохраняются в укрупненном графике, должны быть такими же, как и в детальном графике.
  6. При выполнении параллельных работ, т.е. если одно событие служит началом двух работ или более, заканчивающихся другим событием, вводится зависимость и дополнительное событие, иначе разные работы будут иметь одинаковый код. Между двумя событиями может быть только одна работа, т.е. нельзя допускать различных работ с одинаковыми кодами — работ с общим начальным и конечным событиями. В подобных случаях при необходимости выполнения двух и более параллельных работ вводят фиктивные работы и дополнительные события. Значит, при выполнении параллельных работ, т.е. когда одно событие служит началом 2-го и больше работ, заканчивающихся также одним событием, вводят зависимость.
  7. Если после окончания двух работ А и Б можно начать работу В, а начало работы, Г зависит только от окончания работы А и начало работы Д – от окончания работы Б, то на сетевом графике это изображается с помощью зависимостей.
  8. При построении сетевого графика могут быть следующие ошибки. В сетевом графике не должно быть «тупиков», «хвостов» и «циклов». «Тупик» — событие (кроме завершающего), из которого не выходит ни одна работа, «хвост» — событие (кроме исходного), в которое не входит ни одна работа, «цикл» — замкнутый контур, в котором работы возвращаются к тому событию, из которого они вышли.
  9. В сети не должно быть замкнутых контуров (циклов). Это значит, что ни одна из работ а, Ь, с не может быть выполнена, так как любая из них является и условием и следствием выполнения других работ.
  10. В сети не должно быть «тупиков», т.е. событий, из которых не выходит ни одной работы, если это (событие № 4) не конечное событие. Это говорит либо об ошибке в сети, либо о том, что результат работы, предшествующий событию № 4, никому из исполнителей не нужен.
  11. В сети не должно быть событий, за исключением исходного, в которые не входит ни одной (№ 6) работы. Это говорит о том, что результат, необходимый одному из исполнителей как доходное условие начала его работы, никому не поручен. Значит, событие не может наступить, так как не выполнены предшествующие ему работы.
  12. Ни одна работа не может начаться, пока не наступило событие, предшествующее ей. Ни одно событие не может считаться свершившимся до выполнения всех работ, ведущих к нему.
  13. Изображение поставок и других внешних работ осуществляется следующим образом. Работы, которые предшествуют выполнению тех или иных работ сетевого графика, но организационно решаются на другом уровне, называются внешними работами. К внешним работам можно отнести поступления технической документации, поставку материалов или оборудования, завоз строительных машин и т.д. Обычно такие работы графически выделяются, например, утолщенной стрелкой с двойным кружком.
  14. Нумерация (кодирование) событий должна соответствовать последовательности работ во времени, т.е. предшествующим событиям присваиваются меньшие номера. Нумерацию событий рекомендуется производить только после окончательного построения сети и вести от исходного события, которому присваивается нулевой или первый номер. Последующее событие нельзя нумеровать, если не пронумеровано предшествующее ему событие. Кодирование можно вести горизонтальным или вертикальным методом. При горизонтальном методе события кодируют слева направо по прямым до первого пересечения работ. При вертикальном способе нумерацию начинают сверху вниз и снизу вверх с учетом условия: последующее событие получает номер после предыдущего.

Перевод книги Интерком о продакт менеджменте

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

Эту книгу сотрудники Интерком создали на основе статей из их блога. Книга получилась практичной и полезной как для начинающих так и опытных продактов или тех кто работает в этой роли. Книга настолько понравилась, что решил перевести ее на русский язык.

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

Перевод книги на русский язык «Интерком о продакт менеджменте».

Оригинал книги «Intercom on Product Management» на английском.

Исходный текст перевода взят у хабрапользователя Алексея Горобчука @harabchuk

Принципы web-разработки через bitbucket

Несколько человек пишут код (php,js,mysql,html). Коммитят это. Push-ают. Код отправляется на сервер Bitbucket.

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

  1. Под каждую отдельную задачу создаётся отдельная ветка разработки.
  2. Разработчик по ходу работы никогда не должен пушить коммиты в ветку master. Он пушит их в свою ветку разработки.
  3. Когда задача доведена до некоторого итога, создаётся запрос на слияние (merge request, pull request). Либо в какой-то иной форме (хоть устно) обозначается готовность ветки к слиянию. Подробнее: Зачем нужен pull request, если есть push?
  4. Предложенная ветка проходит код-ревью, тестирование и какие угодно другие проверки.
  5. В каждом конкретном случае должен быть один ответственный человек, принимающий решение о слиянии. Это может быть тимлид, тестировщик, ещё кто-то — как договоритесь.

Далее вся комманда Pull-ами синхронизирует код у себя на машинах;

Команда git pull фактически включает в себя две: git fetch + git merge. С первой обычно не бывает проблем, вторая может застопориться на конфликтах. Я обычно обновляю master, а потом делаю rebase текущей ветки на него

git fetch
# посмотрим, что к нам пришло
git log --oneline --graph --decorate --all

# обновим master
git checkout master
git merge origin/master # или просто git pull

# переставим текущую ветку на новый master. 
# при наличии конфликтов лучше разрешить их сейчас, чем потом при слиянии в master
git checkout myfeature
git rebase master

Как вы будете развертывать приложение — совершенно отдельный вопрос. Если это интерпретируемый код вроде php или js — удобно использовать rsync. Есть более популярный, но гораздо менее надёжный способ развертывания через репозиторий на production-сервере и git-hook. Если доступен только FTP, придётся через FTP.

Стремитесь к тому, чтобы у вас было абсолютно идентичное окружение на всех этапах процесса: разработка, тестирование, staging (если есть), production.

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

Так вы страхуете свою команду:

  • от (части) багов, которые просачиваются на прод;
  • от феномена «works on my machine»;
  • от серверов-произведений искусства, которые были настроены год назад человеком, который потом уволился, а теперь никто не может сделать то же самое, поэтому в случае поломки заменить их будет нечем

U-образные ячейки

Расположение оборудования в форме латинской буквы «U». В U-образной ячейке станки расставлены подковообразно, согласно последовательности операций. При таком расположении оборудования последняя стадия обработки проходит в непосредственной близости от начальной стадии, поэтому оператору не нужно далеко ходить, чтобы начать выполнение следующего производственного цикла.

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

https://worksection.com/blog/u-shaped-conveyor-cells.html

Визуализация

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

Наиболее часто используемые методы визуализации:

  • Оконтуривание
  • Цветовая маркировка
  • Метод дорожных знаков
  • Маркировка краской
  • «Было»-«стало»
  • Графические рабочие инструкции

Система JIT

Just-In-Time — точно вовремя. Cистема управления материалами в производстве, при которой компоненты с предыдущей операции (или от внешнего поставщика) доставляются именно в тот момент, когда они требуются, но не раньше. Данная система ведет к резкому сокращению объема незавершенного производства, материалов и готовой продукции на складах.

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

Особенности системы JIT. При функционировании системы JIT ничего не производится и запас на производственном участке не пополняется пока конечный продукт не будет реализован или отгружен. Когда конечный продукт «вытянут», для восполнения изъятого «вытягиваются» изделия из предыдущей стадии производства или от поставщиков. Таким образом, система JIT предполагает обеспечение производственного участка всем ассортиментом материалов и комплектующих, в количестве необходимом для производства сборки (изготовления) такого количества производимых изделий на данном участке, которое его покинуло.

Таким образом, отправной точкой для пополнения запаса на производственном участке при реализации системы KANBAN является сигнал, выдаваемый в виде карточки или пустого контейнера по мере его окончания, но при этом на производственном участке есть полностью заполненный контейнер в объеме запаса, достаточного для работы на период пополнения + 10 – 30% (страховой запас). В системе JIT отправной точкой служит отгрузка готового изделия с производственного участка, после которой осуществляется пополнение запаса в объеме, необходимом для производства следующего аналогичного изделия.

Система TPM (Total Productive Maintenance)

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

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

В бережливом производстве TPM система борется против шести видов больших потерь, связанных с оборудованием:

  • поломки
  • установка и наладка
  • холостой ход и малые остановки
  • потери скорости
  • брак и переделка
  • пусковые потери

Если рассматривать управление техническим обслуживанием оборудования шире, то эффект от него в масштабах предприятия следующий:

  • повышает эффективность работы станков
  • повышает производительность цеха
  • снижает себестоимость производства
  • повышает качество продукции

В основе Total Productive Maintenance лежит восемь принципов, или столпов.

В основе Total Productive Maintenance лежит восемь принципов, или столпов

По материалам https://worksection.com/blog/total-productive-maintenance.html

Быстрая переналадка (SMED — Single Minute Exchange of Die)

Концепция была разработана японским автором Сигео Синго и произвела революцию в подходах к переналадке и переоснастке. В результате внедрения системы SMED смена любого инструмента и переналадка могут быть произведены всего за несколько минут или даже секунд, «в одно касание» (концепция «OTED»— «One Touch Exchange of Dies»).

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

  • подготовка материалов, штампов, приспособлений и т.п. — 30%;
  • закрепление и снятие штампов и инструментов — 5%;
  • центрирование и размещение инструмента — 15%;
  • пробная обработка и регулировка — 50%

В результате были сформулированы следующие принципы, позволяющие сокращать время переналадки в десятки и даже сотни раз:

  • разделение внутренних и внешних операций наладки,
  • преобразование внутренних действий во внешние,
  • применение функциональных зажимов или полное устранение крепежа,
  • использование дополнительных приспособлений.
Пример SMED