{
    "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": "18",
            "url": "https:\/\/loshenov.ru\/all\/pro-supersposobnosti\/",
            "title": "Про суперспособности",
            "content_html": "<p>У всех есть сильные стороны — набор личностных качеств в особенных пропорциях, благодаря которым что-то дается нам проще, чем остальным. Чем раньше получается их сформулировать, тем легче жить: выбирать работу, задачи, роли и среду.<\/p>\n<p>Чтобы обнаружить эти способности, часто советуют проанализировать навыки, опыт и хобби. Мне этот совет никогда не помогал. В момент такого анализа кажется, что ничего особенного ты как раз не делаешь: просто работаешь, просто разбираешься, просто доводишь до результата.<\/p>\n<p>В Школе Бюро мы с командой «Суккулентоводства» (Полина и Катя, привет!) столкнулись с интересным искажением: каждому казалось, что остальные ребята в команде сильные специалисты и вносят много пользы в проект, а ты не делаешь ничего особенного. Но когда обменялись обратной связью, стало понятно: мы не видели ценности в том, что давалось нам легко, а другие видели, потому что для них это огромный труд.<\/p>\n<p>Другими словами:<\/p>\n<ol start=\"1\">\n<li>Количество усилий, потраченных на достижение результата, не равно ценности результата. То, что вам очень тяжело, не означает, что вы на пути к чему-то полезному.<\/li>\n<li>Люди измеряют ценность результата количеством усилий, которые им самим пришлось бы потратить, чтобы получить то же самое. То, что вы делаете на автомате, для других может быть большой экономией времени, сил и нервов.<\/li>\n<\/ol>\n<p>Ищите свои сильные стороны в повторяющихся просьбах других людей: там, где вас снова и снова зовут помочь; там, где после вашего участия становится понятнее, спокойнее или надежнее; там, где вы делаете без надрыва, а другим это заметно помогает.<\/p>\n<p>А еще поиск суперспособностей помогает в управлении людьми. Если внимательно смотреть на команду, видно тех, у кого получается «само»: без насилия над собой, без лишнего контроля, с интересом и энергией. Часто это значит, что человек на своем месте.<\/p>\n<p>Потратьте пять минут, скажите человеку рядом о его суперсиле. Возможно, сам он ее пока не видит.<\/p>\n",
            "date_published": "2026-07-09T15:12:20+04:00",
            "date_modified": "2026-07-09T15:12:02+04:00",
            "tags": [
                "карьера",
                "управление"
            ],
            "_date_published_rfc2822": "Thu, 09 Jul 2026 15:12:20 +0400",
            "_rss_guid_is_permalink": "false",
            "_rss_guid": "18",
            "_rss_enclosures": [],
            "_e2_data": {
                "is_favourite": true,
                "links_required": [],
                "og_images": []
            }
        },
        {
            "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)"
}