{
    "version": "https:\/\/jsonfeed.org\/version\/1.1",
    "title": "Управление",
    "_rss_description": "Блог про заказную разработку, запуск и развитие цифровых продуктов.",
    "_rss_language": "ru",
    "_itunes_email": "ivan@loshenov.ru",
    "_itunes_categories_xml": "",
    "_itunes_image": "https:\/\/loshenov.ru\/pictures\/userpic\/userpic-square@2x.jpg?1674468163",
    "_itunes_explicit": "no",
    "home_page_url": "https:\/\/loshenov.ru\/tags\/upravlenie\/",
    "feed_url": "https:\/\/loshenov.ru\/tags\/upravlenie\/json\/",
    "icon": "https:\/\/loshenov.ru\/pictures\/userpic\/userpic@2x.jpg?1674468163",
    "authors": [
        {
            "name": "Иван Лощёнов",
            "url": "https:\/\/loshenov.ru\/",
            "avatar": "https:\/\/loshenov.ru\/pictures\/userpic\/userpic@2x.jpg?1674468163"
        }
    ],
    "items": [
        {
            "id": "10",
            "url": "https:\/\/loshenov.ru\/all\/itogi-s-ural-digital-weekend-2023\/",
            "title": "Симулякр итогов с Ural Digital Weekend 2023",
            "content_html": "<p>С 3 по 5 августа провел с коллегами в Перми на Ural Digital Weekend 2023. Ничего не ждал и был удивлен уровнем организации, фестивальной атмосферой и кучей топов из заказной разработки.<\/p>\n<p>Чтобы не пропало, делюсь заметками с поездки:<\/p>\n<h2>Общее<\/h2>\n<ol start=\"1\">\n<li>Важность препати на профильных конференциях была мною сильно недооценена<\/li>\n<li>Критически важно выходить с уровня бизнес-заказчика на уровень топ-менеджеров и владельцев, чтобы не терять контакт с клиентом из-за смены менеджмента. И в дополнение — регулярно собирать обратную связь от топ-менеджеров и владельцев, чтобы реально оценивать ценность которую вы доносите до бизнеса клиента<\/li>\n<li>Отчеты для T&M-контрактов можно делать на BI — реалтайм-обновление и полная прозрачность<\/li>\n<li>Первый месяц можно продавать по постоплате, чтобы снизить риски клиента (интересная мысль, но не сталкивался с таким возражением на пресейле)<\/li>\n<li>Мало экспертизы на этапе продажи не бывает<\/li>\n<\/ol>\n<h2>Разработка своих продуктов<\/h2>\n<ol start=\"1\">\n<li>Значимые тренды рынка энтерпрайз-систем\n<ul>\n  <li>Освободилась существенная доля рынка из-за ухода зарубежных продуктов (нужны замены ушедших систем)<\/li>\n  <li>Технические тренды: микросервисы, lowcode\/nocode стек, RPA<\/li>\n  <li>Господдержка импортозамещения<\/li>\n  <li>Самописные внутренние разработки крупных игроков<\/li>\n  <li>Риски потери кадров (релокация, конкуренция за ИТ-кадры)<\/li>\n  <li>Новые продукты крупных российских интеграторов<\/li>\n  <li>Монетизация собственных решений<\/li>\n<\/ul>\n<\/li>\n<li>Не получится сделать продукт из готового решения, которое разрабатывалось под конкретного заказчика. Но для поиска «болей» рынка и формирования плана по развитию такого продукта можно использовать привычный Jobs To Be Done и мало известный  <a href=\"https:\/\/university.connectwise.com\/content\/documents\/cw_wp_painchain.pdf\">Pain Chain<\/a><\/li>\n<li>Почему здорово делать продукт с клиентом:\n<ul>\n  <li>Глубочаяшая отраслевая экспертиза<\/li>\n  <li>Выходы на всех ЛПР в отрасли<\/li>\n<\/ul>\n<\/li>\n<li>Почему клиенту здорово делать продукт с агентством:\n<ul>\n  <li>Экспертиза в разработке<\/li>\n  <li>Умение продавать ИТ-решения<\/li>\n  <li>Понимание того что такое клиентский сервис в ИТ (продукт может требовать внедрения)<\/li>\n  <li>Гибкость (агентство всегда меньше и быстрее)<\/li>\n<\/ul>\n<\/li>\n<li>Обратная сторона продуктовой разработки\n<ul>\n  <li>Очень сложно найти первых клиентов, свою кор-аудиторию<\/li>\n  <li>Высасывает ресурсы (деньги и людей)<\/li>\n  <li>Размывается фокус внимания<\/li>\n  <li>Расходы сложнее планировать<\/li>\n  <li>Расхолаживает команду, после клиентских проектов<\/li>\n  <li>Сложно контролировать команду, если делаешь продукт бенчем (так не надо делать)<\/li>\n<\/ul>\n<\/li>\n<li>Рекомендации по организации запуска продукта\n<ul>\n  <li>Жестко фиксировать этапы и бюджеты на свои продукты. Будьте готовы потерять эти деньги<\/li>\n  <li>Учитывайте все затраты на разработку, в том числе косвенные затраты и упущенную прбыль<\/li>\n  <li>Подумайте как будете использовать продукт, если он не взлетит<\/li>\n  <li>Выделенная команда и четкие роли в ней<\/li>\n  <li>Выделен ответственный за продукт (визионер) с четкими, прописанными KPI. Найдите человека, который будет думать о продукте всё время (не пол дня).<\/li>\n  <li>Ответственный за продукт — не просто продакт, это драйвер процесса. Зачастую это должен быть СЕО\\СОО\\партнер — очень замотивированный предстаитель отдельного бизнес-юнита. Поэтому начать стоит с драйвера, тогда будет все чуть проще.<\/li>\n  <li>Относитетсь к продукту как к заказчику своего агентства.<\/li>\n  <li>Четко поставлены цели: smart, harvest, mece<\/li>\n  <li>Продукт и основной бизнес не соперничают друг с другом<\/li>\n  <li>10 раз убедиться что за продуктом стоит реальная боль, а не фантазии (даже если это фантазии самых главных людей в компании). Убедитесь, что сфера продукта близка вашему агентству<\/li>\n  <li>Проработайте бизнес-модель, не смешивайте ее с агентской моделю<\/li>\n  <li>Рассказывайте о продукте и том, как его делаете<\/li>\n<\/ul>\n<\/li>\n<li>С какими клиентами будет сложно прийти к продуктовой разработке:\n<ul>\n  <li>Если нет процессов продуктовой разработки или текущее понимание больше на стороне заказчика<\/li>\n  <li>Работаем по спринтам, но не видим смысла в бизнес-аналитике или системном аналитике. Заказчик не подпускает подрядчика к внутренней кухне, работаем в режиме черного ящика (ВА, привет)<\/li>\n  <li>Продукт не совсем продукт, не приносит ценности бизнесу, обречен на правал<\/li>\n<\/ul>\n<\/li>\n<li>С какими клиентами возможно прийти к модели продуктовой разработки:\n<ul>\n  <li>Если у заказчика есть фреймворк продуктовой разработки и он внедрен хотя бы частично<\/li>\n  <li>Заказчик понимает ценность продукта и имеет план развития<\/li>\n  <li>Заказчик умеет пользоваться всеми инструментами аутсорса<\/li>\n<\/ul>\n<\/li>\n<li>Если продукт не развивается — не увеличивается бюджет на его развитие.<\/li>\n<li>Как устранить раскол между ИТ и бизнесом — путь к успеху агентства:\n<ul>\n  <li>Не пытаться занимать только одну из сторон (важно всё и сразу: делать важные для продукта задачи, по правильному процессу и быстро, чтобы бизнес возвращать инвестиции)<\/li>\n  <li>Объяснять бизнесу почему в долгосрочной перспективе нужно учиться слыть ИТ: архитекторов, лидов и СТО<\/li>\n  <li>Снабдить ИТ бизнесовой фактурой для продажи своих позиций, сделать ИТ-метрики управляемыми<\/li>\n  <li>Помочь ИТ лучше отвечать требованиям бизнеса, а бизнесу предоставить для ИТ требования в понятном виде<\/li>\n<\/ul>\n<\/li>\n<li>Фреймворк продуктовой разработки, который должен настраиваться и постоянно адаптироваться, чтобы минимизировать ТТМ:<\/li>\n<\/ol>\n<div class=\"e2-text-table\">\n<table cellpadding=\"0\" cellspacing=\"0\" border=\"0\">\n<tr>\n<td>Этап<\/td>\n<td>Бизнес-инициатива или гипотеза<\/td>\n<td>Оценка и приоритизация<\/td>\n<td>Бизнес-анализ<\/td>\n<td>Системный анализ<\/td>\n<td>Разработка<\/td>\n<\/tr>\n<tr>\n<td>Кто<\/td>\n<td>Кто угодно: стейкхолдеры, СЕО, владелец продукта<\/td>\n<td>Лид разработки, БА, Владелец продукта<\/td>\n<td>БА, Владелец продукта, РП, ITBP, стейкхолдеры<\/td>\n<td>Лид разработки, Владелец продукта, РП<\/td>\n<td>Лид разработки, РП<\/td>\n<\/tr>\n<tr>\n<td>С каким результатом<\/td>\n<td>Сделаем что-то что сделает продукт более ценным для потребителей с целью увеличения бизнеса<\/td>\n<td>Понимаем сложность и сроки в попугаях, понимаем профит, приоритизируем<\/td>\n<td>Декомпозированные бизнес-требования, CJM, EJM, описанный бизнес-процесс. Дизайн, UX, ограничения<\/td>\n<td>Техническое решение, декомпозиция задач, в том числе по системам, беклог готовых, оцененных и готовых к разработке задач<\/td>\n<td>Задачи в рамках изначальных БТ, готовые к релизам (или UAT\\AB\\E2E) во всех системах<\/td>\n<\/tr>\n<tr>\n<td>Пример<\/td>\n<td>Если мы автоматизируем процесс оформления заказа — улучшим SLA дял клиентов, сэкономим Х рублей на операционных затратах<\/td>\n<td>Клиенты смогут оформить заказ в любое время суток, бизнес сэкономит и высвободит операционного ресурса на 20 млн в год<\/td>\n<td>Осознание, что требуется доработка в 5 бэкенд-системах, юридические и финансовые аспекты улажены, готов дизайн, описан процесс, посчитан P&L<\/td>\n<td>Эпик или сторя, в который собраны все задачи с оценками. Осталось только положить в спринты по системам согласно приоритетам<\/td>\n<td>Команда разработки готова провести демо нового функционала бизнесу и готова к отгрузке на бой<\/td>\n<\/tr>\n<\/table>\n<\/div>\n<h2>Команда<\/h2>\n<ol start=\"1\">\n<li>Для создания эффективной команды нужны единая цель, где каждый преследует цель компании и взаимодействует друг с другом<\/li>\n<li>Почему командная работа решает на уровне задач Complex (об этом чуть ниже):\n<ul>\n  <li>Делает возможным решение задач, что не под силу одному человеку<\/li>\n  <li>Является гарантией, что будут учитываться интересы всех сторон<\/li>\n  <li>Понижается риск принятия ошибочных решений<\/li>\n  <li>Помогает бороться с производственной слепотой<\/li>\n<\/ul>\n<\/li>\n<li>Чтобы у команды появилась сопричастность к происходящему, сопереживание проблемам, поддержка и продвижение изменений, повышения доверия и генерация идей — она должна быть плотно интегрирована в то, что у компании происходит и наоборот. Для этого существует точки для сбора и передачи информации, дальше об этом<\/li>\n<li>Какие могут быть точки для сбора информации:\n<ul>\n  <li>1-2-1 RM<\/li>\n  <li>1-2-1 HR<\/li>\n  <li>360<\/li>\n  <li>Командные встречи<\/li>\n  <li>Чаты<\/li>\n  <li>Эскалации<\/li>\n  <li>Perfomance review<\/li>\n  <li>Проектные ретро<\/li>\n  <li>Неофициальные встречи<\/li>\n<\/ul>\n<\/li>\n<li>А какие системы передачи информации:\n<ul>\n  <li>Планерки топов (еженедельно)<\/li>\n  <li>Планерки менеджмента (каждые 2 недели)<\/li>\n  <li>Планерки отделов (каждые 2 недели)<\/li>\n  <li>Общая встреча компании (квартальные, годовая)<\/li>\n  <li>Мероприятия по изменениям<\/li>\n  <li>Личные встречи<\/li>\n  <li>Дополнительные: почтовые рассылки (nda\\not nda), телеграмм-канал, общий чат в телеге, сессии Q&A.<\/li>\n<\/ul>\n<\/li>\n<li>О чем компания может делиться с менеджментом:\n<ul>\n  <li>Всё и максимально открыто<\/li>\n  <li>Продавать прототипы изменений и собирать обратную связь<\/li>\n  <li>Просить задавать неудобные вопросы<\/li>\n  <li>Рассказывать о возможностях и искать лидеров<\/li>\n  <li>Показывать проблемы и искать совместные решения<\/li>\n<\/ul>\n<\/li>\n<li>О чем компании стоит делиться со всеми:\n<ul>\n  <li>Об изменениях (которые уже поддерживает менеджмент)<\/li>\n  <li>Проблемы — с решениями от менеджмента<\/li>\n  <li>Возможности — с запросом на участие<\/li>\n  <li>Выручку, прибыль — в процентах<\/li>\n<\/ul>\n<\/li>\n<\/ol>\n<h2>Проекты<\/h2>\n<ol start=\"1\">\n<li>Каскадная модель производства драматически снижает вероятность успеха проекта<\/li>\n<li>Cynefin framework <a href=\"https:\/\/ru.wikipedia.org\/wiki\/Cynefin_framework\">https:\/\/ru.wikipedia.org\/wiki\/Cynefin_framework<\/a> — как концептуальная основа для принятия решений:\n<ul>\n  <li>Obvious. Применяйте «Best Practice». Задачи ясны, решения очевидны, следуйте установленным процедурам.<\/li>\n  <li>Complicated. Применяйте «Good Practice» или экспертные мнения. Возможно несколько правильных решений<\/li>\n  <li>Complex. Проведите эксперименты и используйте «Emergent Practice». Тут нет очевидных решений, выясните правильный подход через пробу и ошибку.<\/li>\n  <li>Chaotic. Действуйте сразу для стабилизации ситуации, затем изучайте и отвечайте на изменения. Нужно немедленно действовать.<\/li>\n<\/ul>\n<\/li>\n<li>В разработке нетиповых решений часто приходится решать задачи уровня Complicated и Complex, поэтому взвешивайте решения. Complicated — это граница проектной деятельности, начиная с Complex — это задачи в зоне эмпирической деятельности, а значит мы не можем говорить о каскадной модели и вотерфоле для таких решений. Это всё Симулякр плана, как выразился Глеб Михеев :-)<\/li>\n<li>Иногда стоит принять, что ты не можешь определить точные требования и вместо требований определить цель и ключевые результаты (это, кстати, пересекается с тем что говорят ребята из Бюро про ФФФ). Это зона неопределенности, её невозможно спланировать. Это зона командной работы.<\/li>\n<li>Что пропагандирует аджайл:\n<ul>\n  <li>Люди и взаимодействие важнее процессов и инструментов<\/li>\n  <li>Работающий продукт важнее исчерпывающей документации<\/li>\n  <li>Сотрудничество с заказчиком важнее согласования условий контракта<\/li>\n  <li>Готовность к изменениям важнее следования первоначальному плану<\/li>\n<\/ul>\n<\/li>\n<li>В аджайле развитие. Аджайт создает продукт, ватерфолл его воспроизводит<\/li>\n<li>Немного о концепции Run-Change-Disrupt<\/li>\n<\/ol>\n<h2>На кого подписался после конфы<\/h2>\n<ol start=\"1\">\n<li><a href=\"https:\/\/t.me\/panfilovonline\">https:\/\/t.me\/panfilovonline<\/a> Пишет про запуск digital-проектов и IT-инструменты для бизнеса<\/li>\n<li><a href=\"https:\/\/t.me\/rukovozhu\">https:\/\/t.me\/rukovozhu<\/a> Виктор Рындин: CEO @Wemakefab & @Dprofileru<\/li>\n<li><a href=\"https:\/\/t.me\/tired_glebmikheev\">https:\/\/t.me\/tired_glebmikheev<\/a> Глеб Михеев, просто поток сознания на стыке менеджмента и ИТ, я влюбился<\/li>\n<li>@dpletnev. Дима Плетнев. Но он ничего в паблик почему-то не пишет, приходится писать в личку<\/li>\n<li><a href=\"https:\/\/t.me\/successfulproduct\">https:\/\/t.me\/successfulproduct<\/a> Сергей Пращенко, про продакт дискавери вообще и в энтерпрайзе в частности (самый недооцененный доклад, потому что было жутко интересно, но все выдохлись)<\/li>\n<\/ol>\n<p>Ну и посмотрите запись трансляции, очень много достойных лекций:<\/p>\n<div class=\"e2-text-video\">\n<iframe src=\"https:\/\/www.youtube.com\/embed\/6O78hNR2aes?enablejsapi=1\" allow=\"autoplay\" frameborder=\"0\" allowfullscreen><\/iframe>\n<\/div>\n",
            "date_published": "2023-08-14T18:29:50+04:00",
            "date_modified": "2023-08-15T04:32:14+04:00",
            "tags": [
                "Запуск продукта",
                "советы",
                "управление"
            ],
            "image": "https:\/\/loshenov.ru\/pictures\/remote\/youtube-6O78hNR2aes-cover.jpg",
            "_date_published_rfc2822": "Mon, 14 Aug 2023 18:29:50 +0400",
            "_rss_guid_is_permalink": "false",
            "_rss_guid": "10",
            "_rss_enclosures": [],
            "_e2_data": {
                "is_favourite": false,
                "links_required": [
                    "system\/library\/jquery\/jquery.js",
                    "system\/library\/media-seek\/media-seek.js"
                ],
                "og_images": [
                    "https:\/\/loshenov.ru\/pictures\/remote\/youtube-6O78hNR2aes-cover.jpg"
                ]
            }
        },
        {
            "id": "5",
            "url": "https:\/\/loshenov.ru\/all\/kak-igra-v-gluhie-telefony-chut-ne-stoila-nam-krupnogo-klienta\/",
            "title": "Как игра в «глухие телефоны» чуть не стоила нам крупного клиента",
            "content_html": "<div class=\"e2-text-picture\">\n<img src=\"https:\/\/loshenov.ru\/pictures\/nutnet-communicate.png\" width=\"700\" height=\"350\" alt=\"\" \/>\n<div class=\"e2-text-caption\">Сообщение от партнера, который узнал про ситуацию на проекте<\/div>\n<\/div>\n<p>В разработке первое, что должен понять исполнитель — цель клиента. Тогда есть шанс создать такой функционал, который ему действительно поможет.<\/p>\n<p>Обычно собственники и руководители компаний понимают, чего хотят от инвестиции в ИТ-проект. Они видят в нем ценность и хотят, чтобы вложения в него окупились. С ними легко говорить на языке бизнеса, они формулируют конкретные задачи — например, увеличить объем продаж в X раз.<\/p>\n<p>Иногда заказчику трудно сразу обозначить свои цели и четко сформулировать их. Тогда мы помогаем ему — задаем наводящие вопросы.<\/p>\n<p>Но чаще в качестве заказчика выступает не сам собственник бизнеса, а менеджеры с его стороны. От них намного сложнее добиться конкретики: они просят нас создать инструмент, но совершенно не понимают зачем.<\/p>\n<p>В таких случаях мы стараемся сэкономить ресурсы заказчика и время нашей команды: просим контакты собственников бизнеса и выясняем истинные цели проекта. Этот принцип мы выработали в процессе коммуникации с компанией «Витязь-Аэро».<\/p>\n<h2>Почему важна роль бизнес-заказчика в ИТ-проекте<\/h2>\n<p>«Витязь-Аэро» — это авиакомпания, которая выполняет пассажирские рейсы на вертолетах в отдаленные населенные пункты Камчатки. У них два ИТ-продукта: сайт и автоматизированная информационная система (АИС) для регистрации пассажиров, багажа, грузов. Первый — для клиентов, второй — для внутреннего пользования сотрудниками.<\/p>\n<p>В компании АИС ввели в 2017 году. Изначально ее создавал местный разработчик, сотрудники которого построили систему за полгода и далее осуществляли ее техподдержку. Позже количество человек в его команде сократилось, и работа по продукту замедлилась. АИС для аэропорта перестала стабильно работать и быстро адаптироваться под новые запросы пользователей.<\/p>\n<p>Кроме того, в системе изначально было много проблем в функционале: например, плохое изначальное проектирование и невыстроенная система тестирования и модификации кода. Со временем АИС перестала отвечать растущим потребностям компании.<\/p>\n<p>В конце 2019 года «Витязь-Аэро» захотели увеличить темпы разработки. Дополнительно нужно было развить функционал системы, ускорить трек поддержки и увеличить скорость реакции для исправления критичных дефектов. Чтобы закрыть эти потребности, в «Витязь-Аэро» решили сменить подрядчика и обратились к нам.<\/p>\n<h2>Проблемы в коммуникации с клиентом<\/h2>\n<div class=\"e2-text-picture\">\n<img src=\"https:\/\/loshenov.ru\/pictures\/ba-bylo.png\" width=\"1280\" height=\"720\" alt=\"\" \/>\n<div class=\"e2-text-caption\">Не надо так<\/div>\n<\/div>\n<p>Коммуникация с клиентом складывалась непросто: на разницу в местонахождении и часовом поясе (+8 часов) накладывались и другие сложности. Например, с начала сотрудничества у нас не было прямого контакта с бизнес-заказчиками — собственниками, которые хорошо представляют цели разработки и желаемый результат. Мы связывались с ними через руководителя проекта. Это был сотрудник компании, который не мог знать столько же, сколько бизнес-заказчики, несмотря на проактивную позицию в работе. Из-за этого в нашей коммуникации появилось несколько проблем:<\/p>\n<p>* <b>Менялись приоритеты, о чем мы поздно узнавали.<\/b> Например, нам приходила задача, которую надо было выполнить срочно. Мы тратили на нее время, а по готовности оказывалось, что она уже не нужна.<br \/>\n* <b>Возникали недопонимания при постановке задач.<\/b> Оказалось, что обсуждать задачу без прямого контакта с бизнес-заказчиком — сложно. Это было похоже на игру в «глухие телефоны»: собственник давал нам задание через руководителя проекта, а мы получали его искаженным или неполным. При этом не было возможности быстро уточнить, что значительно увеличивало сроки исполнения. В итоге при релизе демоверсии получалось, что с продуктом все не так — результат не совпадал с ожиданием бизнес-заказчика.<\/p>\n<h2>***<\/h2>\n<p>Например, нам ставили задачу — настроить онлайн-оплату для реализации электронных билетов на сайте.<\/p>\n<p>При выполнении мы обнаружили много тонкостей, которые не могли решить только с нашей стороны. Это не просто техническая задача, она касается всего продукта: надо было понять, какие бизнес-процессы есть в компании и какие изменения в них потребуются. Как на этой основе мы будем выстраивать работу нашего бэк-офиса. Все это приходилось уточнять через руководителя проекта, который тратил много времени для сбора нужных нам данных.<\/p>\n<blockquote>\n<p>В итоге работа усложнилась на всех звеньях коммуникации. С нашей стороны — мы выполняли часть работы и останавливались, потому что ждали ответов на запросы о бухгалтерской отчетности, онлайн-кассе, требованиях к авиабилетам. Со стороны руководителя проекта — не было представления о статусе и проблемах проекта, а также возможности повлиять на работу подразделений и топ-менеджмента. А со стороны бизнес-заказчиков все выглядело так, будто мы затянули выполнение задачи на 2 месяца.<\/p>\n<\/blockquote>\n<p>Момент оказался поворотным — мы решили организовать переговоры с непосредственными руководителями «Витязь-Аэро».<\/p>\n<h2>Переговоры и изменения в порядке работы<\/h2>\n<p>Из-за возникшей коллизии мы встретились с бизнес-заказчиками. В ходе переговоров мы:<\/p>\n<ol start=\"1\">\n<li>Воссоздали моменты нашей коммуникации с самого начала, чтобы проверить, кто какой информацией владеет.<\/li>\n<li>Обозначили проекты, которые мы ведем: поддержка и развитие АИС, поддержка существующего сайта «Витязь-Аэро» и разработка нового.<\/li>\n<li>Познакомили с нашей командой и рассказали об объеме задач у каждого сотрудника — чтобы клиент понимал, что в проекты вовлечено много человек.<\/li>\n<li>Презентовали результаты работы за последние 6 месяцев.<\/li>\n<li>Рассказали, на каких стадиях находятся поставленные задачи.<\/li>\n<li>Наметили будущие приоритеты и проблемы, из-за которых могут сдвинуться сроки.<\/li>\n<\/ol>\n<div class=\"e2-text-picture\">\n<img src=\"https:\/\/loshenov.ru\/pictures\/va-stalo.png\" width=\"1280\" height=\"720\" alt=\"\" \/>\n<div class=\"e2-text-caption\">Колесо проектного взаимопонимания<\/div>\n<\/div>\n<p>Также мы проанализировали коммуникацию с «Витязь-Аэро» и предложили варианты, как предотвратить проблемы в будущем. Самым важным было подключить бизнес-заказчика к ключевым процессам разработки. Договорились о следующем:<\/p>\n<ul>\n<li>Внедрили ежемесячные демо. Подключали руководителей и заинтересованных участников со стороны заказчика, чтобы совместно продемонстрировать и принять новый функционал в дев-окружении. Сбор обратной связи здесь и сейчас упрощал коммуникацию с двух сторон и позволил учитывать ожидания заказчика. Также это погрузило руководителей в процесс разработки и дало понимание, почему готовы или нет те или иные инструменты;<\/li>\n<li>Договорились о стратегических совещаниях раз в 3—6 месяцев. Это помогло увидеть горизонт работы и определить приоритетные задачи в следующие 6—12 месяцев. Выделили несколько направлений: развитие и поддержка продукта, а также фиксация проблем в автоматизированной системе.<\/li>\n<\/ul>\n<p>Выстроенная коммуникация позволила сохранить сотрудничество и быстрее выполнять задачи клиента. Объем работ многократно вырос, а time-to-market, время за которое идеи реализовывались и становились доступными для пользователей, сократилось в 2 раза.<\/p>\n<h2>Где участие бизнес-заказчика обязательно<\/h2>\n<p>Работа с «Витязь-Аэро» показала, что общаться только с руководителем проекта по поводу целей и результата сложно. При такой коммуникации мы упускали из виду приоритеты бизнес-заказчика, подолгу выясняли тонкости его работы и не получали адекватную обратную связь. В итоге понимание задач было неполным, они долго выполнялись — получалось, что бюджет компании тратился без видимого результата.<\/p>\n<div class=\"e2-text-picture\">\n<img src=\"https:\/\/loshenov.ru\/pictures\/va-etapy.png\" width=\"1288\" height=\"728\" alt=\"\" \/>\n<div class=\"e2-text-caption\">Это позволило синхронизировать бизнес и разработку<\/div>\n<\/div>\n<p>Теперь мы обязательно привлекаем к прямому обсуждению бизнес-заказчиков. Особенно на следующих итерациях проекта:<\/p>\n<ul>\n<li>Формирование бэклога — определяемся со списком задач с описанием, оценкой и приоритетами;<\/li>\n<li>Утверждение скоупа — согласовываем список задач, которые точно должны попасть в следующий релиз;<\/li>\n<li>Тестовая эксплуатация — демонстрируем результат работы клиенту.<\/li>\n<\/ul>\n<p>Если вам интересно, как эффективно выстроить работу с разработчиками — задавайте вопросы. Мы всегда готовы поделиться опытом или провести полноценный аудит вашего ИТ-продукта, чтобы по итогу вы получили обоснованные предложения по развитию и поддержке.<\/p>\n",
            "date_published": "2022-09-09T11:00:00+04:00",
            "date_modified": "2023-01-19T23:48:07+04:00",
            "tags": [
                "nutnet",
                "управление"
            ],
            "image": "https:\/\/loshenov.ru\/pictures\/nutnet-communicate.png",
            "_date_published_rfc2822": "Fri, 09 Sep 2022 11:00:00 +0400",
            "_rss_guid_is_permalink": "false",
            "_rss_guid": "5",
            "_rss_enclosures": [],
            "_e2_data": {
                "is_favourite": true,
                "links_required": [],
                "og_images": [
                    "https:\/\/loshenov.ru\/pictures\/nutnet-communicate.png",
                    "https:\/\/loshenov.ru\/pictures\/ba-bylo.png",
                    "https:\/\/loshenov.ru\/pictures\/va-stalo.png",
                    "https:\/\/loshenov.ru\/pictures\/va-etapy.png"
                ]
            }
        }
    ],
    "_e2_version": 4079,
    "_e2_ua_string": "Aegea 11.0 (v4079e)"
}