Любой API следует так называемому ресурсно-ориентированному дизайну и состоит из трех ключевых концепций
ресурс: часть данных, например, User;
коллекция: группа ресурсов, например, List of users;
URL: местоположение ресурса или коллекции, например, /user.
1. Kebab-case для URL-адресов
Если вы хотите получить список заказов.
Плохо:
/systemOrders или /system_orders
Хорошо:
/system-orders
2. CamelCase для параметров
Применяйте, если хотите получить товары из определенного магазина.
Плохо:
/system-orders/{order_id} или /system-orders/{OrderId}
Хорошо:
/system-orders/{orderId}
3. Множественное число, указывающее на коллекцию
Если необходимо получить всех пользователей системы.
Плохо:
GET /user или GET /User
Хорошо:
GET /users
4. URL начинается с коллекции и заканчивается идентификатором
Если хотите сохранить концепцию единой и последовательной.
Плохо:
GET /shops/:shopId/category/:categoryId/price
Это плохо, потому что здесь описано свойство, а не ресурс.
Хорошо:
GET /shops/:shopId/ или GET /category/:categoryId
5. Не используйте глаголы в URL ресурса
Не используйте глаголы в URL для выражения действий. Вместо этого примените описанные ниже методы.
Плохо:
POST /updateuser/{userId} или GET /getusers
Хорошо:
PUT /user/{userId}
6. Используйте глаголы в URL для Non-Resource
У вас есть код, не возвращающий ничего кроме операции. В этом случае можно использовать глаголы. Например, для повторной отправки предупреждения пользователю.
Хорошо:
POST /alerts/245743/resend
7. Используйте camelCase для свойства JSON
Если у вас есть тело запроса или ответ в JSON, имена свойств должны быть в camelCase.
Службы HTTP RESTful должны реализовывать конечные точки API /health, /version и /metrics, предоставляющие следующую информацию:
/health – отвечает на запросы с кодом состояния 200 OK; /version – отвечает на запрос номером версии; /metrics – эта конечная точка будет предоставлять различные показатели, например, среднее время отклика. Настоятельно рекомендуем использовать конечные точки /debug и /status.
9. Не используйте table_name для имени ресурса
Не используйте имя таблицы в качестве имени ресурса. В долгосрочной перспективе такая лень может привести к проблемам.
Плохо:
product_order
Хорошо:
product-orders
10. Применяйте инструменты проектирования
Существует много хороших инструментов проектирования API:
Если API используется внешними сущностями, изменение конечной точки может нарушить их функциональность, поэтому использование версий обязательно.
12. Выводите в ответе общее количество ресурсов
Если API возвращает список объектов, всегда включайте общее количество ресурсов в ответ.
Плохо:
{ пользователи: [ ... ] }
Хорошо:
{ пользователи: [ ... ], всего: 34 }
13. Принимайте параметры ограничения и смещения
Всегда принимайте параметры ограничения и смещения в операциях GET.
Хорошо:
GET /shops?offset=5&limit=5
Это необходимо для пагинации на фронтенде.
14. Получаем поля параметров запроса
Следует учитывать объем возвращаемых данных. Добавьте параметр fields, чтобы предоставить только необходимые поля из вашего API.
Пример:
Вернуть только название, адрес и контакты магазинов.
GET /shops?fields=id,name,address,contact
В некоторых случаях это поможет уменьшить размер ответа.
15. Не передавайте в URL токены аутентификации
Это очень плохая практика, потому что URL часто регистрируются и, следовательно, маркер аутентификации также будет регистрироваться без необходимости.
Плохо:
GET /shops/123?token=some_kind_of_authenticaiton_token
Хорошо:
Вместо этого передайте их в заголовке:
Authorization: Bearer xxxxxx, Extra yyyyy
16. Проверка Content-Type
Сервер не должен принимать content-type. Например, если вы принимаете application/x-www-form-urlencoded, злоумышленник может создать форму и запустить простой запрос POST.
Всегда валидируйте тип контента, а если хотите использовать content-type по умолчанию, используйте application/json.
17. Использование методов HTTP для функций CRUD
Следующие методы служат для описания CRUD-функций:
GET: получение представления ресурса.
POST: создание новых ресурсов и подресурсов.
PUT: обновление существующих ресурсов.
PATCH: обновление существующих ресурсов, но только тех полей, которые были описаны (остальные остаются без изменений).
DELETE: удаление существующих ресурсов.
18. Применение отношений в URL для вложенных ресурсов
Вот некоторые практические примеры:
GET /shops/2/products: получить список всех продуктов из магазина 2.
GET /shops/2/products/31: получить подробную информацию о продукте 31, из магазина 2.
DELETE /shops/2/products/31: удалить продукт 31 из магазина 2.
PUT /shops/2/products/31: обновить информацию о продукте 31 (использовать только URL ресурса, а не коллекцию).
POST /shops: создать новый магазин и вернуть сведения о нем.
19. CORS
Поддерживайте заголовки CORS (Cross-Origin Resource Sharing) для всех общедоступных API. Рассмотрите возможность поддержки разрешенного CORS-источника « * » и принудительной авторизации с помощью OAuth-токенов. Избегайте объединения учетных данных пользователя с валидацией происхождения.
20. Безопасность
Применяйте протокол HTTPS (зашифрованный TLS) ко всем конечным точкам, ресурсам и службам. HTTPS должен быть у всех колбеков, эндпоинтов, push-уведомлений и веб-хуков.
21. Ошибки
Ошибки возникают, когда клиент делает неправильный запрос к службе или передает службе неправильные данные, а та отклоняет запрос. Популярные проблемы: неверные учетные данные, неправильные параметры, неизвестные идентификаторы версий и т. д. При отклонении запроса клиента по причине ошибок службы возвращают коды HTTP – 4xx.
Для кого: Владельцы продуктов / менеджеры проектов
Что: Использование 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 Таблиц, мы можем визуально отображать значения, представленные в некоторых из наших столбцов, позволяя читателю сканировать страницу в поисках ценных историй. Или, наоборот, он может визуально выделить те истории, в которых риск плюс затраты перевешивают ценность для бизнеса, которую они создадут.
В шаблоне вы можете увидеть, где каждый столбец использует свой собственный базовый цвет, а затем использует различные оттенки этого цвета для обозначения интенсивности. Например, чем выше значение, тем темнее фон в столбце «Значение» для истории.
Вы можете настроить условное форматирование, выбрав столбец или ячейки и перейдя в меню «Формат» к «Условное форматирование…»
Использование элементов списка проверки данных
Чтобы провести какой-либо анализ ваших историй, по крайней мере, некоторые поля должны быть заблокированы, чтобы разрешить выбор только из предустановленного списка опций. Как правило, не следует рассчитывать на получение согласованных и сопоставимых данных в любом поле, в которое можно ввести информацию от руки. Чтобы бороться с этим, мы можем настроить правила проверки и предоставить пользователю предустановленные списки опций для выбора. Параметры списка можно легко изменить в соответствии с контекстом текущего проекта, но важно то, что список существует и что введенные данные соответствуют ему. Это войдет в игру позже, когда мы начнем настраивать диаграммы в листе анализа.
Чтобы настроить правила проверки, выберите диапазон ячеек и в меню «Данные» перейдите к «Проверка…».
Заставляем лист работать на вас
Все, о чем мы говорили до сих пор, представляет собой несколько надежных советов по созданию электронной таблицы пользовательских историй, но мало что сделано, кроме основ создания таблицы и данных цветового кодирования. Давайте начнем поднимать шкалу сложности и заставим этот лист работать за нас.
Матрица стоимости / риска
Одним из примеров является автоматическая оценка таблицы, в какой квадрант матрицы ценности / риска попадает каждая история. Выбирая варианты стоимости и риска для каждой истории, лист может применить формулу, чтобы определить, подпадает ли история под стратегические (высокая ценность и высокий риск), с кредитным плечом (высокая ценность и низкий риск), целенаправленная (низкая ценность и высокий риск). ) или рутинный (низкая стоимость и низкий риск).
//В качестве альтернативы вы можете выполнить поиск в таблице вместо этого сложного вложения условных выражений
Используемые здесь методы не являются точной наукой и, конечно же, не приведут к построению графика матрицы. На этом этапе проекта это высокоуровневое разделение относительного падения сюжета может быть использовано в качестве еще одной точки данных при оценке приоритета сюжета и примерно того, где должны присутствовать функции при планировании выпуска.
Примеры случаев использования: если вы используете представление с фильтрами только для историй, которые должны быть включены в выпуск MVP, и обнаруживаете, что формируется непропорционально большое количество историй, попадающих в стратегическую и целенаправленную классификации, то, возможно, стоит оценить, как возможно, в одном выпуске будет рассказано так много историй о высоком риске.
И наоборот, что, если релиз будет состоять почти исключительно из рутинных историй. Сможет ли команда хоть как-то поддержать боевой дух, выполняя такой тусклый релиз, лишенный видения и волнения?
Возможно, стоит пересмотреть некоторые решения, чтобы сбалансировать план выпуска и повысить вероятность успешного выпуска.
Расширенные столбцы
Это «секретный соус» этого листа. В шаблоне, если вы посмотрите полностью вправо от заголовка столбца, вы заметите стрелочные индикаторы, обозначающие скрытые столбцы. Если вы развернете эти столбцы, вы найдете несколько столбцов с расчетными данными, в которых используются формулы для преобразования данных из видимых столбцов для использования в наших сводных таблицах и диаграммах анализа.
В шаблоне вы можете видеть, что первые три скрытых поля представляют собой просто целочисленные представления значений, выбранных в столбцах «Приоритет», «Значение» и «Риск». Хотя метки High, Med, Low делают видимые столбцы более удобными для человека, они не подходят для агрегирования и анализа. Создав эту целочисленную копию данных, мы теперь можем легко использовать эту информацию в наших графиках, сводя к минимуму путаницу для любых заинтересованных сторон, просматривающих основные столбцы таблицы.
Следующие три столбца аналогичны последним трем, но с инвертированными значениями. Хотя мы обнаружили, что наличие приоритета «1» хорошо соотносится с нашей системой управления проектами, меньшее значение не всегда означает более высокий приоритет при создании сводных таблиц и диаграмм. Имея этот столбец INV (инвертированное значение), теперь мы можем иметь наши диаграммы, точно отражающие «высокое значение» как более высокое значение относительно оси графика.
Помимо этого, то, какие скрытые вычисляемые / агрегированные столбцы вам понадобятся, зависит от вас и от контекста вашей ситуации.
В шаблоне вы можете увидеть поддержку разделения, если вы представляете более одной категоризации истории в первом столбце, например тему и функцию. Также есть столбец, который помогает с намеченным порядком сортировки выпусков. И, наконец, столбец, который просто обеспечивает доступ к автоматически сгенерированному номеру строки листа пользовательской истории.
Создание представлений фильтров для выпусков
Использование представлений фильтров может дать вам возможность быстро переключаться между историями и функциями, которые вы выбрали для выпусков, и оценивать, соответствует ли каждый выпуск реалистичному и выполнимому пути. Ваша точка зрения при просмотре данных может иметь большое значение, поэтому настройте несколько видов, чтобы вы могли видеть лист под разными углами.
Использование сводных таблиц
Еще одна перспектива, которую вы можете себе представить, заключается в использовании сводных таблиц. В шаблоне показан пример, оценивающий ценность, которую каждая функция получит в каждом выпуске. В качестве дополнительного бонуса вы также получаете общую сумму баллов, назначенных для каждой версии и функции.
Приступая к упражнению по пользовательской истории, нередко у нас есть некоторые предвзятые представления о том, на какие функции и решения будет направлена наша работа. После того, как мы собрали наши данные, изменение угла обзора может преподнести некоторые сюрпризы. Возможно, одна функция, которая, как мы ожидали, будет иметь относительно низкий приоритет, на самом деле заслуживает особого внимания. Или, возможно, эта функция, которую ИТ-директор считает краеугольным камнем всего продукта, демонстрирует признаки того, что ей потребуется меньше внимания по сравнению с другими функциями.
Это не точная наука. Многие переменные и факторы будут влиять на результаты каждой сводной таблицы. Например, на изображении выше одна функция может показаться менее ценной, чем другая, хотя на самом деле это просто вопрос чрезвычайно ценной функции, имеющей долю от количества пользовательских историй в качестве еще одной более стандартной, но необходимой функции. Вы можете расширить эту концепцию и ввести более сложные средства взвешивания баллов, присваиваемых историям.
Важно то, что когда вы просматриваете эту таблицу, вы спрашиваете себя: «проходит ли то, что я вижу, мою интуицию?» Когда вы просматриваете диаграмму, видите ли вы выбросы, которых не ожидали? Если это так, то, возможно, вы видите подсказки, которые заслуживают дальнейшего изучения.
При желании вы можете реплицировать этот же тип сводной таблицы, чтобы определить выбросы по приоритету, риску или любому другому столбцу, для которого вы измеряете согласованные значения.
Графики аналитики
Многим людям нравятся визуальные эффекты. В частности, менеджменту нравится видеть информацию с первого взгляда в легко усваиваемом формате. Инструменты построения графиков 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.
а — первоначальный вариант; б — промежуточный вариант; в — окончательный вариант
При построении СГ степень детализации работ зависит от сложности объектов, количества ресурсов, объемов работ и периода строительства.
При составлении первичных СГ учитывают следующие рекомендации:
— технология работ должна быть выражена с исчерпывающей полнотой;
— каждая стрелка должна соответствовать отдельной работе, выполняемой бригадой в определенных пространственных границах;
— детализация работ должна обеспечивать планирование и управление деятельностью самостоятельных ресурсов (бригад, машин, механизмов и т.п.), позволять рассчитывать сроки и объемы поставок материалов, конструкций и изделий и контролировать ход этих поставок.
Необходимо, чтобы продолжительность работ не превышала продолжительности двух интервалов представления оперативной информации.
Например, если информация предоставляется каждые сутки, работы следует выполнять не более двух дней, при недельном планировании — 14 дней, при месячном — 60 дней.
Сетевой график строят на основе детально разработанного перечня всего комплекса работ, необходимых для достижения конечной цели. Сетевая модель изображается в виде графика, состоящего из стрелок и кружков. Сеть с математической точки зрения представляет собой ориентированный, связный, конечный граф без контуров отражающие отношения предшествования между работами комплекса.
Первоначально сетевой график строят без учета продолжительности составляющих ее работ, и поэтому длина стрелок зависит только от необходимости обеспечить простую и ясную структуру сети и систематизирование расположить показатели и записать наименование по каждой работе. На первой стадии построение сети осуществляют на технологической взаимосвязи работ и определяющих ограничениях по ведущим ресурсам, таким, как монтажные краны, комплексные бригады и т.п. В процессе построения первоначального варианта сети ее внешнему виду не уделяют особого внимания.
После того как составлен первый вариант сети, проверяют правильность построения, просматривая ее от исходного события к завершающему и обратно, и устанавливают, имеются ли все предшествующие работы, необходимые для начала последующих работ. Проводится также графическое упорядочение сети, чтобы уменьшить количество взаимопересекающихся работ и зависимостей и расположить работы во временной последовательности.
Уровень детализации сетевого графика зависит от сложности строящихся объектов, группировки и количества используемых ресурсов, объемов работ и периода строительства.
При составлении первичных сетевых графиков, имеющих наибольшую детализацию, учитывают следующие требования к детализации работ: технология работ должна быть выражена с исчерпывающей полнотой; каждая стрелка должна выявлять отдельно работу, выполняемую бригадой определенной специальности в определенных пространственных границах; детализация работ должна обеспечивать планирование и управление деятельностью самостоятельных ресурсов (бригад, машин, механизмов и т. п.), позволять рассчитывать сроки и объемы поставок материалов, конструкций и изделий и контролировать ход этих поставок.
Сетевые модели могут быть детальными и укрупненными, в которых ряд работ заменяется одной укрупненной работой. Кроме того, они делятся на сводные, объединяющие комплексные сетевые графики зданий и сооружений данного объекта: комплексные, охватывающие все работы по возведению данного здания или сооружения и обеспечению ресурсами; частные, объединяющие часть работ, выполняемых на строительстве здания конкретной организацией; первичные – по работам, производимым отдельными исполнителями, например одним из участков строительного управления (первичная сеть является частью соответствующей частной сети).
С целью сокращения затрат труда на составление сетевых моделей и повышения их качества в последнее время получают распространение типовые сетевые модели и номенклатура работ, которые наиболее эффективно применяются для типовых объектов.
Сетевой график представляет собой сетевую модель с рассчитанными временными параметрами. В основе построения сети лежат понятия «работа» и «событие».
Работа – это производственный процесс, требующий затрат времени и материальных ресурсов и приводящий к достижению определенных результатов. Работу на сетевом графике изображают одной сплошной стрелкой, длина которой не связана с продолжительностью работы. Под стрелкой указывают наименование работы, а над стрелкой – продолжительность работы в рабочих днях и при необходимости количество рабочих в день или смену. Под стрелкой можно показать также сметную стоимость СМР, физический объем работ, исполнители работ и т.д. В зависимости от назначения графика содержание приводимых параметров работы может меняться, но продолжительность и наименование работ указывают всегда.
Ожидание – процесс, требующий только затрат времени и не потребляющий никаких материальных ресурсов. Ожидание является технологическим и организационным перерывом между работами, непосредственно выполняемыми друг за другом.
Событие – это факт окончания одной или нескольких работ, необходимый и достаточный для начала следующих работ. В любой сетевой модели события устанавливают технологическую и организационную последовательность работ. События изображаются кружками или другими геометрическими фигурами, внутри которых указывается определенный номер – код события.
События ограничивают рассматриваемую работу и по отношению к ней могут быть начальными и конечными.
Начальное событие определяет начало данной работы и является конечным для предшествующих работ.
Конечное событие определяет окончание данной работы и является начальным для последующих работ.
Исходное событие – событие, которое не имеет предшествующих работ в рамках рассматриваемого сетевого графика.
Завершающее событие – событие, которое не имеет последующих работ в рамках рассматриваемого сетевого графика.
Сложное событие – событие, в которое входят или из которого выходят две или более работы.
Путь – непрерывная последовательность работ в сетевом графике. Его длину определяют суммой продолжительности составляющих его работ. Путь от исходного до завершающего события сетевого графика называют полным путем. Путь может быть также предшествующим – это участок полного пути от исходного события графика до данного, а также последующим – от данного события до любого последующего. Путь описывается последовательностью работ или событий.
Критическим путем называют полный путь, имеющий наибольшую длину (продолжительность) из всех полных путей. Его длина определяет срок выполнения работ по сетевому графику. Работы, лежащие на критическом пути, называют критическими. Увеличение продолжительности критических работ увеличивает общую продолжительность работ по сетевому графику.
Пути продолжительность которых несколько меньше продолжительности критического пути на заданную величину, называют подкритическими. Такой величиной может быть период контроля. При недельно-суточном оперативном планировании период контроля составляет 7 календарных дней.
Совокупность всех критических и подкритических работ называют критической зоной. Работы, лежащие на этих путях, требуют к себе внимания, так же как и работы критического пути.
Направление построения сети, ее развертывание может носить различный характер. Обычно сетевой график строят от исходного к завершающему или, наоборот, от завершающего к исходному. Но график можно также строить от любого события в двух направлениях: к исходному и к завершающему событиям.
Основные правила построения сетевого графика
При этом учитывают:
работы, которые должны быть завершены прежде, чем начнется планируемая работа;
работы, которые могут быть начаты после нее, т.е. после данной планируемой работы;
работы, осуществляемые одновременно с плановой работой.
При этом учитывают технологическую и логическую последовательность выполнения работ.
Сетевые графики строят по следующим правилам.
Направление стрелок в сетевом графике следует принимать слева направо.
Форма графика должна быть простой, без лишних пересечений, большинство работ следует изображать горизонтальными линиями.
Если те или иные работы начинаются после частичного выполнения предшествующей, то эту работу следует разбить на части
При изображении поточных работ особое внимание уделяется правильной разбивке работ на захватки и выявлению взаимосвязи смежных работ.
Укрупнение сетей производится с соблюдением следующих правил:
группа работ на сетевом графике может изображаться как одна работа, если в этой группе имеется одно начальное и одно конечное событие;
укрупнять в одну работу следует только такие работы, которые закреплены за одним исполнителем (бригадой, участком и т.д.);
в укрупненную сеть нельзя вводить новые события, которых не было на более детальном графике до укрупнения;
наименование работ в укрупненном графике должно быть увязано с наименованием укрупняемых работ;
коды событий, которые сохраняются в укрупненном графике, должны быть такими же, как и в детальном графике.
При выполнении параллельных работ, т.е. если одно событие служит началом двух работ или более, заканчивающихся другим событием, вводится зависимость и дополнительное событие, иначе разные работы будут иметь одинаковый код. Между двумя событиями может быть только одна работа, т.е. нельзя допускать различных работ с одинаковыми кодами — работ с общим начальным и конечным событиями. В подобных случаях при необходимости выполнения двух и более параллельных работ вводят фиктивные работы и дополнительные события. Значит, при выполнении параллельных работ, т.е. когда одно событие служит началом 2-го и больше работ, заканчивающихся также одним событием, вводят зависимость.
Если после окончания двух работ А и Б можно начать работу В, а начало работы, Г зависит только от окончания работы А и начало работы Д – от окончания работы Б, то на сетевом графике это изображается с помощью зависимостей.
При построении сетевого графика могут быть следующие ошибки. В сетевом графике не должно быть «тупиков», «хвостов» и «циклов». «Тупик» — событие (кроме завершающего), из которого не выходит ни одна работа, «хвост» — событие (кроме исходного), в которое не входит ни одна работа, «цикл» — замкнутый контур, в котором работы возвращаются к тому событию, из которого они вышли.
В сети не должно быть замкнутых контуров (циклов). Это значит, что ни одна из работ а, Ь, с не может быть выполнена, так как любая из них является и условием и следствием выполнения других работ.
В сети не должно быть «тупиков», т.е. событий, из которых не выходит ни одной работы, если это (событие № 4) не конечное событие. Это говорит либо об ошибке в сети, либо о том, что результат работы, предшествующий событию № 4, никому из исполнителей не нужен.
В сети не должно быть событий, за исключением исходного, в которые не входит ни одной (№ 6) работы. Это говорит о том, что результат, необходимый одному из исполнителей как доходное условие начала его работы, никому не поручен. Значит, событие не может наступить, так как не выполнены предшествующие ему работы.
Ни одна работа не может начаться, пока не наступило событие, предшествующее ей. Ни одно событие не может считаться свершившимся до выполнения всех работ, ведущих к нему.
Изображение поставок и других внешних работ осуществляется следующим образом. Работы, которые предшествуют выполнению тех или иных работ сетевого графика, но организационно решаются на другом уровне, называются внешними работами. К внешним работам можно отнести поступления технической документации, поставку материалов или оборудования, завоз строительных машин и т.д. Обычно такие работы графически выделяются, например, утолщенной стрелкой с двойным кружком.
Нумерация (кодирование) событий должна соответствовать последовательности работ во времени, т.е. предшествующим событиям присваиваются меньшие номера. Нумерацию событий рекомендуется производить только после окончательного построения сети и вести от исходного события, которому присваивается нулевой или первый номер. Последующее событие нельзя нумеровать, если не пронумеровано предшествующее ему событие. Кодирование можно вести горизонтальным или вертикальным методом. При горизонтальном методе события кодируют слева направо по прямым до первого пересечения работ. При вертикальном способе нумерацию начинают сверху вниз и снизу вверх с учетом условия: последующее событие получает номер после предыдущего.
Продакт менеджер — роль, в которой есть элементы инженерии, маркетинга, исследований и управления проектами, и такая роль является ключевой в создании выдающихся продуктов. Она требует непрерывного внимания к целостности продукта, объединяя под единым видением то как продукт проектируется, создается, называется, брендируется и продвигается на рынке.
Эту книгу сотрудники Интерком создали на основе статей из их блога. Книга получилась практичной и полезной как для начинающих так и опытных продактов или тех кто работает в этой роли. Книга настолько понравилась, что решил перевести ее на русский язык.
Мы начнем с оценки текущего состояния вашего продукта. Посмотрим какие части используются и какие требуют улучшения. Во второй главе вы узнаете о трудном выборе, который возникает при добавлении нового функционала, и почему «нет» — это самое важное слово в словаре продакт менеджера. Третья глава содержит чек лист, который должен пройти каждая новая функция; в этой же главе обсудим, как выпускать новый функционал. В завершение вы узнаете, как помочь пользователям начать использовать новые функции. Потому что конечная цель выпуска нового кода, чтобы он использовался и был полезным.
24 января 2020 года Москва, Radisson Collection Moscow
Вручал награды лучшим спикерам 2019 года в категории «Электронный документооборот и повышения эффективности бизнес-процессов» на Церемонии награждения лауреатов премии «Лучший спикер CFO Russia»
