Сервис для обмена шифрованными сообщениями на базе PrivateBin — сделал отдельный экземпляр.
Ваш бизнес — это не просто компания, это история, которую вы хотите рассказать миру. Наши Телеграм-боты помогут вам сделать это, усиливая ваши коммуникации с клиентами! 🤖📩
1. Уникальное внимание: Подарите своим клиентам чувство важности, отправляя им персонализированные новости и акции, которые соответствуют их интересам.
2. Эффективное взаимодействие: Наши боты позволяют вам связываться с вашими подписчиками немедленно, обеспечивая оперативную реакцию на актуальные события.
3. Увеличение продаж: Удивите клиентов эксклюзивными предложениями и скидками, что может существенно увеличить конверсию и выручку.
4. Аналитика в реальном времени: Следите за реакцией клиентов и получайте полезные данные о взаимодействии, помогая вам совершенствовать свои стратегии.
5. Продвигайте свой бизнес: Не упустите шанс оставаться на связи с клиентами и продвигать свой бренд с помощью наших Телеграм-ботов. Обратитесь к нам, и давайте сделаем ваш бизнес еще успешнее! 📰💼 #ТелеграмБоты #Маркетинг #Рассылки
Превратите свой опыт обслуживания клиентов в нечто уникальное с помощью телеграм-ботов! 🚀📱
1. Быстрые ответы на вопросы: Наши боты оснащены базой знаний, позволяя моментально отвечать на часто задаваемые вопросы клиентов и устранять недоразумения.
2. Проведение опросов: Мы можем создавать опросы и анкеты, помогая собирать мнения клиентов и анализировать их, чтобы улучшить ваш продукт или услугу.
3. Обратная связь: Давайте клиентам возможность выразить свое мнение и предложения через ботов, что поможет строить долгосрочные отношения и усилить лояльность.
4. Эффективное время ожидания: Клиенты больше не должны ждать в очередях. Боты обрабатывают запросы моментально, сэкономив время и нервы.
5. Улучшенный анализ данных: Мы предоставляем вам аналитические отчеты, основанные на взаимодействии с ботами, помогая выявить тренды и улучшить качество обслуживания.
Инновации ждут вас! Подключите телеграм-ботов для более эффективной коммуникации с вашими клиентами. 🤖💬 #КлиентскаяСлужба #ТелеграмБоты #КоммуникацияСКлиентами
Ваш бизнес готов встретить будущее? 🚀 Телеграм-боты могут сделать процесс приема и обработки заказов проще и более эффективным, чем когда-либо! 📱💼
Присоединитесь к цифровой революции! Интегрируйте телеграм-ботов в свой бизнес и упростите заказы для ваших клиентов. 💼🤖 #ЦифроваяТрансформация #ТелеграмБоты #БизнесВЭпохуТехнологий
Управление изменениями (Change Management) — это процесс планирования, внедрения и управления изменениями в организации с целью достижения успешных результатов и минимизации негативных воздействий на сотрудников, бизнес-процессы и организационную структуру. Оно связано с управлением переходом от текущего состояния к желаемому состоянию, включая изменения в стратегии, процессах, технологиях, структуре и культуре организации.
Процесс управления изменениями включает в себя следующие ключевые аспекты:
Управление изменениями важно для успешной реализации стратегических целей, внедрения новых технологий, оптимизации бизнес-процессов и обеспечения эффективной работы компании в условиях постоянно меняющейся среды. Оно также направлено на уменьшение сопротивления со стороны сотрудников и создание позитивного опыта в процессе изменений.
Управление изменениями играет ключевую роль в развитии бизнеса, обеспечивая успешную адаптацию к новым условиям и повышение эффективности. Вот как оно способствует развитию бизнеса:
Современный бизнес требует гибкости и способности адаптироваться к постоянно меняющейся среде. Управление изменениями позволяет бизнесу более эффективно внедрять и адаптироваться к изменениям, что является неотъемлемой частью его успешного развития.
Вот пошаговый план внедрения управления изменениями в организации:
Шаг 1: Анализ и Подготовка
Определение необходимости изменений: Выявите, почему необходимо внести изменения, и какие аспекты бизнеса требуют адаптации.
Создание команды управления изменениями: Сформируйте команду, которая будет отвечать за планирование и внедрение процессов изменений.
Шаг 2: Анализ Заинтересованных Сторон
Идентификация заинтересованных сторон: Определите, какие группы сотрудников и другие заинтересованные стороны будут затронуты изменениями.
Оценка потребностей заинтересованных сторон: Понимание ожиданий и опасений заинтересованных сторон поможет разработать более эффективные стратегии управления изменениями.
Шаг 3: Планирование Изменений
Разработка стратегии управления изменениями: Определите цели, методы, ресурсы и расписание внедрения изменений.
Создание плана коммуникации: Разработайте стратегию коммуникации, включая сообщения для различных групп сотрудников и других заинтересованных сторон.
Подготовка обучения: Разработайте программы обучения для перехода к новым процессам, инструментам и навыкам.
Шаг 4: Внедрение Изменений
Обучение и поддержка сотрудников: Проведите обучение сотрудников по новым процессам и предоставьте им поддержку во время внедрения изменений.
Постепенное внедрение: Внедряйте изменения постепенно, чтобы минимизировать сопротивление и улучшить адаптацию.
Шаг 5: Обратная Связь и Коррекция
Сбор обратной связи: Соберите мнения и впечатления сотрудников и других заинтересованных сторон о внедренных изменениях.
Анализ обратной связи: Проанализируйте собранную обратную связь, выявьте проблемы и успешные аспекты.
Шаг 6: Оценка Результатов
Измерение результатов: Оцените, насколько успешно прошло внедрение изменений, используя ключевые показатели производительности и удовлетворенности.
Сравнение с планом: Сравните фактические результаты с планом внедрения и определите разницу.
Шаг 7: Поддержание Изменений
Интеграция в культуру компании: Убедитесь, что изменения интегрированы в культуру организации и стали частью повседневной практики.
Обучение новых сотрудников: При необходимости предоставьте обучение новым сотрудникам, чтобы они тоже могли адаптироваться к изменениям.
Шаг 8: Непрерывное Улучшение
Постоянный мониторинг: Продолжайте отслеживать результаты и собирать обратную связь, чтобы внести дополнительные улучшения.
Адаптация к новым изменениям: Будьте готовы к новым изменениям и динамично адаптируйте бизнес к меняющимся условиям.
Управление изменениями — это непрерывный процесс, который требует постоянного внимания и участия. Его целью является создание гибкой и адаптивной организации, способной успешно развиваться и преодолевать вызовы перемен.
Уважаемые предприниматели и руководители компаний, хотите увеличить лояльность клиентов, повысить доходы и создать успешный бизнес, ориентированный на потребности вашей аудитории?
https://t.me/grisenko
Любой API следует так называемому ресурсно-ориентированному дизайну и состоит из трех ключевых концепций
Если вы хотите получить список заказов.
Плохо:
/systemOrders или /system_ordersХорошо:
/system-ordersПрименяйте, если хотите получить товары из определенного магазина.
Плохо:
/system-orders/{order_id} или /system-orders/{OrderId}Хорошо:
/system-orders/{orderId}Если необходимо получить всех пользователей системы.
Плохо:
GET /user или GET /UserХорошо:
GET /usersЕсли хотите сохранить концепцию единой и последовательной.
Плохо:
GET /shops/:shopId/category/:categoryId/priceЭто плохо, потому что здесь описано свойство, а не ресурс.
Хорошо:
GET /shops/:shopId/ или GET /category/:categoryIdНе используйте глаголы в URL для выражения действий. Вместо этого примените описанные ниже методы.
Плохо:
POST /updateuser/{userId} или GET /getusersХорошо:
PUT /user/{userId}У вас есть код, не возвращающий ничего кроме операции. В этом случае можно использовать глаголы. Например, для повторной отправки предупреждения пользователю.
Хорошо:
POST /alerts/245743/resendЕсли у вас есть тело запроса или ответ в JSON, имена свойств должны быть в camelCase.
Плохо:
{
user_name: «Programmer's library»
user_id: «1»
}Хорошо:
{
userName: «Programmer's library»
userId: «1»
}Службы HTTP RESTful должны реализовывать конечные точки API /health, /version и /metrics, предоставляющие следующую информацию:
/health – отвечает на запросы с кодом состояния 200 OK;
/version – отвечает на запрос номером версии;
/metrics – эта конечная точка будет предоставлять различные показатели, например, среднее время отклика.
Настоятельно рекомендуем использовать конечные точки /debug и /status.
Не используйте имя таблицы в качестве имени ресурса. В долгосрочной перспективе такая лень может привести к проблемам.
Плохо:
product_orderХорошо:
product-ordersСуществует много хороших инструментов проектирования API:
Наличие хорошей и подробной документации обеспечивает отличный клиентский опыт для пользователей API.
Всегда указывайте номер версии для API. Номер версии должен быть v1, v2 и т. д.
Хорошо:
http://api.domain.com/v1/shops/3/productsЕсли API используется внешними сущностями, изменение конечной точки может нарушить их функциональность, поэтому использование версий обязательно.
Если API возвращает список объектов, всегда включайте общее количество ресурсов в ответ.
Плохо:
{
пользователи: [ ... ]
}Хорошо:
{
пользователи: [ ... ],
всего: 34
}Всегда принимайте параметры ограничения и смещения в операциях GET.
Хорошо:
GET /shops?offset=5&limit=5Это необходимо для пагинации на фронтенде.
Следует учитывать объем возвращаемых данных. Добавьте параметр fields, чтобы предоставить только необходимые поля из вашего API.
Пример:
Вернуть только название, адрес и контакты магазинов.
GET /shops?fields=id,name,address,contactВ некоторых случаях это поможет уменьшить размер ответа.
Это очень плохая практика, потому что URL часто регистрируются и, следовательно, маркер аутентификации также будет регистрироваться без необходимости.
Плохо:
GET /shops/123?token=some_kind_of_authenticaiton_tokenХорошо:
Вместо этого передайте их в заголовке:
Authorization: Bearer xxxxxx, Extra yyyyyСервер не должен принимать content-type. Например, если вы принимаете application/x-www-form-urlencoded, злоумышленник может создать форму и запустить простой запрос POST.
Всегда валидируйте тип контента, а если хотите использовать content-type по умолчанию, используйте application/json.
Следующие методы служат для описания CRUD-функций:
Вот некоторые практические примеры:
Поддерживайте заголовки CORS (Cross-Origin Resource Sharing) для всех общедоступных API. Рассмотрите возможность поддержки разрешенного CORS-источника « * » и принудительной авторизации с помощью OAuth-токенов. Избегайте объединения учетных данных пользователя с валидацией происхождения.
Применяйте протокол HTTPS (зашифрованный TLS) ко всем конечным точкам, ресурсам и службам. HTTPS должен быть у всех колбеков, эндпоинтов, push-уведомлений и веб-хуков.
Ошибки возникают, когда клиент делает неправильный запрос к службе или передает службе неправильные данные, а та отклоняет запрос. Популярные проблемы: неверные учетные данные, неправильные параметры, неизвестные идентификаторы версий и т. д. При отклонении запроса клиента по причине ошибок службы возвращают коды HTTP – 4xx.
Перевод статьи 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 календарных дней.
Совокупность всех критических и подкритических работ называют критической зоной. Работы, лежащие на этих путях, требуют к себе внимания, так же как и работы критического пути.
Направление построения сети, ее развертывание может носить различный характер. Обычно сетевой график строят от исходного к завершающему или, наоборот, от завершающего к исходному. Но график можно также строить от любого события в двух направлениях: к исходному и к завершающему событиям.
При этом учитывают:
При этом учитывают технологическую и логическую последовательность выполнения работ.
Продакт менеджер — роль, в которой есть элементы инженерии, маркетинга, исследований и управления проектами, и такая роль является ключевой в создании выдающихся продуктов. Она требует непрерывного внимания к целостности продукта, объединяя под единым видением то как продукт проектируется, создается, называется, брендируется и продвигается на рынке.
Эту книгу сотрудники Интерком создали на основе статей из их блога. Книга получилась практичной и полезной как для начинающих так и опытных продактов или тех кто работает в этой роли. Книга настолько понравилась, что решил перевести ее на русский язык.
Мы начнем с оценки текущего состояния вашего продукта. Посмотрим какие части используются и какие требуют улучшения. Во второй главе вы узнаете о трудном выборе, который возникает при добавлении нового функционала, и почему «нет» — это самое важное слово в словаре продакт менеджера. Третья глава содержит чек лист, который должен пройти каждая новая функция; в этой же главе обсудим, как выпускать новый функционал. В завершение вы узнаете, как помочь пользователям начать использовать новые функции. Потому что конечная цель выпуска нового кода, чтобы он использовался и был полезным.
Перевод книги на русский язык «Интерком о продакт менеджменте».
Оригинал книги «Intercom on Product Management» на английском.
Исходный текст перевода взят у хабрапользователя Алексея Горобчука @harabchuk