К счастью, вся современная экономика становится экономикой групп а не иерархии. Специализация размывается, важно то в какой группе и над каким результатом ты работаешь, а не специализация - ведь она сменится.
Плоская структура - это там где команда принимает решение. Agile, сильная матричная структура и далее перенос компетенций на всю команду, так как hard skills быстро меняются. В разработке, например, быстро меняются технологии - сегодня можно писать на JS, а завтра на golang.
Иерархия - это где кто-то принимает решения (конвейер), или функциональная/линейная структура. Она всегда характеризуется меньшей вовлеченностью в принятие решений (как ты можешь принимать решения, если бизнес-аналитик тебе описал задачу, а системный - как её делать? Ответственность сильно сокращается.
Цель статьи - познакомить с понятием спиральной динамики и тем, что одни и те же события на разных уровнях воспринимаются по-разному. Если вдруг я вас чем-то обидел - извините.
Вообще, PCM определяет, что каждая личность, не смотря на то что имеет базу и фазу, может общаться на каждом уровне (например логик может выйти в позицию мечтателя или коммуникатора), но это будет отнимать у него энергию.
Очевидно, что психика человека столь многогранна, что попытки уложить её в любую модель (DISC, PCM, Спиральная динамика, MBTI, соционика - что угодно) могут лишь помочь нам посмотреть на личность под каким-то углом.
В реальности, каждый человек в разных деятельностях может быть на разных уровнях (от культурных и ментальных позиций). Всё сложно, и будет только сложнее. Цель статьи не предоставить всесторонний анализ, а познакомить с самим понятием динамики личности по Грейвзу.
У опенспейсов (как и у кабинетов) есть свои минусы. У медали всегда две стороны. Я просто пытался чуть более доходчиво объяснить отношение к колоборативным пространствам. С тем же успехом можно было привести пример кабинетов. Это просто пример.
Это да. На маленьких цифрах (маленький трафик, малое количество заказов, маленькая история измерения) сложно делать выводы на причины.
Несколько соображений конкретно по интернет-магазинам:
Воронка нижних уровней как правило не подвержена очень сильным колебаниям на протяжении месяца: если в чекауте до заполнения всех полей доходило от исходного числа 15%, то так и доходят. Даже сезоны со скидками вроде черной пятницы не приводят к сильным колебаниям конверсии там, так что можно попробовать так наблюдать. Так что я бы посоветовал посмотреть туда.
По поводу конверсии лендингов - да, тут зона маркетингового отдела (у нас он и отвечает за такие истории, меняя рекламу и посыл). Однако, тут как с градусником - если мы уже понмаем цель и задачу (и умеем получать быструю обратную связь), для проектной команды это супер позитивно.
Не станем говорить про A/A/B тесты потому что у маленьких проектов нет денег на поддержание сложной инфраструктуры с тремя версиями проекта (мы же говорим про целеполагание в разработке, с маркетингом можно обойтись только GTM+Google Experiments)
Хорошо, что врачи не работают по методам, которые вы предлагаете.
Иначе бы это было примерно так: - Доктор, у меня зуб болит, что делать? - На методы лечения вы сами налегайте, а я могу дырку просверлить. Говорите какую, где.
Погрешности бывают, но те данные, которые можно получить с помощью настройки Гугл.Аналитики, достаточны для принятия большинства управленческих решений.
Если мы говорим про e-commerce, то: весь сайт разделяется на этапы воронки (страница - этап, сложные страницы - много этапов. Например, оформление заказа можно разбить с детализацией по каждому заполненному полю, но для старта подойдет и просто понимание конверсии в чекауте)
Определяем конверсию по разным сегментам. Интересуют два: C1, CN (первый покупатель, последующие покупки).
Всё, данные настроены. Мы часто сталкиваемся с запросами о том, что клиентам нужна аналитика более серьёзная. Иногда это оправдано, часто - нет, потому что слабая аналитическая культура при любом, самом продвинутом инструменте (AA, OWOX, etc) всегда остаётся слабой культурой. Так что если сейчас никакие данные не используются, начните с самых простых инструментов и далее можно усложнять.
Очень частая ошибка в измерениях C1/CN. Это легко исправляется)
Более 142 млрд евро ЕС за 2004 год потратил денег на разработку, которая не привела ни к каким целям. Как видите, это не только в России происходит. Почитайте Сазерленда - он начинает с неудачного кейса в ФБР, которые десять лет разрабатывали софт. Миллиарды долларов потрачены. Цели расписаны не то чтобы на 2 листа - тома бумаги исписаны. А результата не было. В запутанных средах конвейер не работает.
Убежден, что практики IM/UE можно и вовсе без денег внедрять. Если есть желание - всё будет. Ни деньги, ни количество разработки само по себе к результату ведь не ведет.
Не удалось мне в статье донести мысль о том, что "интернет-магазин на Magento" - это не столько разработка, сколько целеполагание. Будем стараться больше.
Если оно у вас не работает, значит вы не в том культурном пласте находитесь, или нарушаете техники. Чаще - всё вместе.
Во что выливается например Scrum? Недели начинают называть спринтами, а поток задач теперь - "бэклог". Вот и весь "эйджаил". не удивительно, что это не работает.
И культурный аспект - штука сложная. Практики, работающие в красном уровне (см. спиральную динамику), не работают уже в синей компании. Agile, TQM/TOC - это всё аспекты верхних уровней осознанности, и если вы строите конвейер, то гибкость там строить иногда просто негде без осознанного движения (вот Тойоте удалось упаковать конвейер в гибкость, очень рекомендую посмотреть на их опыт).
Заказ в запутанной среде (разработка ПО) и упорядоченной (простой, типа производства гамбургера, или сложной, типа производства моста), требуют разной квалификации.
Поэтому когда мы обсуждаем заказ, мы начинаем ориентироваться на важные цели клиента, составляя Impact Mapping (иногда мы его составляем, но клиент с этим не работает - часто встречается с крупными компаниями). Я считаю, что все-равно успех проекта должен обеспечиваться разработчиками. Иначе через год разработчики отползают от проекта: "мы просто делали ваши задачи. Откуда же нам было знать, что вы не зарабатывали на этих решениях". Вы же к врачу не приходите со списком: "прооперируйте мне тут и вот тут, и еще промывание желудка сделайте"? Вы приходите с задачей, а он обеспечивает решение. Так же должно быть и с инженерами, если они не хотят носить звание "кодер".
Чтобы посчитать юнит-экономику, не нужно быть ни математическим гением, ни ярдовой компанией.
Речь как раз в том, что стоимость разработки всегда высока. И важно делать более рентабельные вещи в первую очередь, и менее рентабельные - потом.
Для этого есть огромное количество практик для этого (тактические: юнит-экономика, Матрица Эйзенхауэра, Scrum Planning Poker, стратегические: Impact Mapping, юнит-экономика).
Часто клиенты убеждены, что разработка сама по себе без нормального целеполагания даст экономический эффект (вот эти вот все "Лишь бы сделать правильную архитектуру", "Сделать UX дизайн", "Реализовать фич больше чем у конкурента"). Не удивительно, что этого не происходит. И чтобы решить эту проблему, клиенты начинают использовать методики упорядоченных систем (техническое задание например).
Методы, которые применяются в упорядоченных системах, не обеспечивают достижения целей бизнеса в запутанной среде (любая разработка выше совсем элементарной).
вопрос не только и не столько в пушах. Сами пуш-нотификации довольно спорны - ведь, как вы знаете, сейчас вообще каждый сайт считает своим долгом запросить у тебя разрешения на пуши. Безусловно, здесь должны устояться отраслевые стандарты (в каких случаях это норм, в каких - вредно). Apple пошла по пути "на сайте - нет, но если ты опубликовал апп - пушь". APNS (спасибо, коллегам). Workaround напрашивается сам собой, которые немного увеличивают косты конкретно для пушей. Это некоторые минусы, поддерживаю.
Мой посыл был в том, что на сегодня в JS можно и машинное обучение (и даже обучать на устройствах - tensorflow.js), внедряется Generic Sensor API и так дальше - получается, что сбылась мечта Стива Джобса и вот-вот вообще не нужны будут нейтивы. Я уже не говорю про скорость рендера CSS (60FPS и более) и революциями в CSS которые менее громкие, но происходят на наших глазах. Получается, что PWA при всех минусах на сегодня имеет такое количество плюсов!
Не ответил на вопрос про деньги - сам не задумывался об этом применительно к нашей компании)) . Начал тут считать - получается примерно 0,6 млн деньгами и примерно 1,5 на сотрудников которые именно за BPM часть отвечали (разработчики и те кто тратил время на конструирование и внедрение БП). В среднем, каждую неделю мы внедряем по одному новому процессу (без разработки, в конструкторе бизнес-процессов) и раз в месяц по одному существенному изменению в процессах с помощью дополнительной автоматизации.
Мы выбрали Битрикс-24 (потому что сами её внедряем). Бюджет - ну, мы постоянно выделили одного разработчика на добавления и исправления (это новые активити, это сложные всякие печатные формы и реализация workflow). Разработчик закреплен на проекте всегда. Бюджет внедрения нужно смотреть по году, для клиентов это в лайтовом режиме около 200 тыс в месяц на маленькое подразделения или на департамент крупного (потому что разработки меньше чем реального внедрения в бизнес и всего что сопровождает бизнес-процессы: регламенты, обучение, продажа этих изменений внутри компании - это медленно и очень сложно). И через полгода возникнет еще плечо техподдержки. Но давайте честно: бизнес-процесс можно накидать и без денег (мы так и делали в целом), просто при усложнении бизнес-процессов возникают такие потребности, как упрощение процессов на схеме (упрощение поддержки), более сложные действия и т.п. Так что про бюджет мне очень сложно сказать абстрактно.
Кстати, мы изначально пытались использовать JIRA. Ведь она тоже может использоваться в качестве BPM: конструктор workflow и триггеры имеются, но сложность поддержки и отсутствие CRM в том (продвинутом) виде делают систему сложно интегрируемой именно в бизнес-процессы. Т.е. они нарисованы и работают в одной системе, а большая часть жизни компании в другой и это порождает проблемы. В этом смысле, возможность добавлять активити в схемы в Б24 (как и в Biztalk, Salesforce и т.п.) очень выручает.
По практике общения со стартапами, они могут так уж и быть поддерживать бизнес-процессы которые для них сделаны головным подразделением. Опять же, стартап стартапу рознь. Есть стартапы, которые в поиске своего продукта. Это компактные группы, которым пока быстрее обсудить все на бумажках/канбан-доске или ее аналогах в максимально простых трекерах задач (там Трелло какой-нибудь). Есть стартапы в смысле новые предприятия, которые свой продукт нашли и все дело в его поставке. Т.е. строго говоря это не стартапы в общепринятом понимании, а просто молодые маленькие предприятия. Там, полностью согласен, имеет смысл накидывать бизнес-процессы сразу (если у маленьких предприятий на это есть деньги и ресурсы ;)
Да, возможно и такое! В теории. Но на практике, всегда есть показатели, которые твой технический долг олицетворяют. Количество ошибок в статанализе не подходит? Ок, давайте смотреть на ошибки на аппах. Там всё чисто, а проект "в жопе"? Ок, давайте посмотрим на общения первой линии поддержки и второй. Если ошибок нет, операторы КЦ молчат, условно, количество отмененных заказов небольшое - то или проект не так плох, или трафика нет. Задача менеджера не жаловаться, а такие параметры искать. Парадигма Disciplined Agile Delivery как раз и говорит, что у тебя должна быть цифра, которая свидетельствует как-то о техническом долге. Если человек не в состоянии такую цифру подобрать, то возможно он не должен быть менеджером проекта.
Это разное. Есть гигиена, есть лечение. Ритмичность релизов, количество ошибок на app-ах, pagespeed ранки и прочее - это именно параметры дисциплины. Есть такое понятие, как DAD (disciplined Agile delivery).
Например, у нас Magento. Для неё есть статический анализ, для неё есть встроенный репорт об ошибках. Менеджеру важно знать одно: что там в цифрах. Если сегодня ошибок 10 а завтра 20 - плохо. Если сегодня 20 а завтра после релиза стало 10 - хорошо. Подробности не нужны.
Аналогично, если у вас app сервер рапортует о 5000 ошибках в сутки, а потом стало 4000 - молодцы, скорее всего стало лучше (или трафик снизился, но это детали).
Да, вы скажете, что всё это уже есть в New Relic, есть Zabbix, есть масса штук. Только всё это не используется в ритмичных улучшениях (когда мы понимаем что технический долг большой, и нужно его маленькими итерациями улучшать).
Количество сообщений в чате между первой линией поддержки и второй и связь подтвержденных и не подтвержденных обращений очень важна по той же причине для менеджера: если у тебя на проекте 50 сообщений и подтвержденных 2 - значит, первой линии не хватает знаний (документация, тренинги). Если 50 сообщений и 40 подтвержденных - значит, ситуация с багами именно такая, и тут нужно смотреть глубже (менеджер должен классифицировать эти обращения и вынести на обсуждение команды что сделать чтобы эти и эти типы обращений уменьшить). Часто это бывают проблемы в интерфейсе (нелогично), а не только баги. Но это так или иначе технический долг. Если ты его не оцифруешь, то ты с ним и не работаешь.
К счастью, вся современная экономика становится экономикой групп а не иерархии. Специализация размывается, важно то в какой группе и над каким результатом ты работаешь, а не специализация - ведь она сменится.
Плоская структура - это там где команда принимает решение. Agile, сильная матричная структура и далее перенос компетенций на всю команду, так как hard skills быстро меняются. В разработке, например, быстро меняются технологии - сегодня можно писать на JS, а завтра на golang.
Иерархия - это где кто-то принимает решения (конвейер), или функциональная/линейная структура. Она всегда характеризуется меньшей вовлеченностью в принятие решений (как ты можешь принимать решения, если бизнес-аналитик тебе описал задачу, а системный - как её делать? Ответственность сильно сокращается.
Настоящая. И что? При чем тут фамилия то вообще..)
нет-нет, тут не про цели. Цели и целеполагание - совсем другая история.
Честно говоря, я не понял вашего комментария.
Цель статьи - познакомить с понятием спиральной динамики и тем, что одни и те же события на разных уровнях воспринимаются по-разному. Если вдруг я вас чем-то обидел - извините.
Нужно рассматривать детально.
Вообще, PCM определяет, что каждая личность, не смотря на то что имеет базу и фазу, может общаться на каждом уровне (например логик может выйти в позицию мечтателя или коммуникатора), но это будет отнимать у него энергию.
Очевидно, что психика человека столь многогранна, что попытки уложить её в любую модель (DISC, PCM, Спиральная динамика, MBTI, соционика - что угодно) могут лишь помочь нам посмотреть на личность под каким-то углом.
В реальности, каждый человек в разных деятельностях может быть на разных уровнях (от культурных и ментальных позиций). Всё сложно, и будет только сложнее. Цель статьи не предоставить всесторонний анализ, а познакомить с самим понятием динамики личности по Грейвзу.
Друзья, это один из примеров.
У опенспейсов (как и у кабинетов) есть свои минусы. У медали всегда две стороны.
Я просто пытался чуть более доходчиво объяснить отношение к колоборативным пространствам. С тем же успехом можно было привести пример кабинетов. Это просто пример.
Это да. На маленьких цифрах (маленький трафик, малое количество заказов, маленькая история измерения) сложно делать выводы на причины.
Несколько соображений конкретно по интернет-магазинам:
Воронка нижних уровней как правило не подвержена очень сильным колебаниям на протяжении месяца: если в чекауте до заполнения всех полей доходило от исходного числа 15%, то так и доходят. Даже сезоны со скидками вроде черной пятницы не приводят к сильным колебаниям конверсии там, так что можно попробовать так наблюдать. Так что я бы посоветовал посмотреть туда.
По поводу конверсии лендингов - да, тут зона маркетингового отдела (у нас он и отвечает за такие истории, меняя рекламу и посыл). Однако, тут как с градусником - если мы уже понмаем цель и задачу (и умеем получать быструю обратную связь), для проектной команды это супер позитивно.
Не станем говорить про A/A/B тесты потому что у маленьких проектов нет денег на поддержание сложной инфраструктуры с тремя версиями проекта (мы же говорим про целеполагание в разработке, с маркетингом можно обойтись только GTM+Google Experiments)
Хорошо, что врачи не работают по методам, которые вы предлагаете.
Иначе бы это было примерно так:
- Доктор, у меня зуб болит, что делать?
- На методы лечения вы сами налегайте, а я могу дырку просверлить. Говорите какую, где.
Цветовая градация придумана не нами, а мистером Грейвзом.
Есть в вики, оттуда взял эту ссылку https://romankalugin.com/teoriya-spiralnoj-dinamki-razvitiya-lichnosti-i-chelovechestva-ot-klera-grejvza/
Погрешности бывают, но те данные, которые можно получить с помощью настройки Гугл.Аналитики, достаточны для принятия большинства управленческих решений.
Если мы говорим про e-commerce, то:
весь сайт разделяется на этапы воронки (страница - этап, сложные страницы - много этапов. Например, оформление заказа можно разбить с детализацией по каждому заполненному полю, но для старта подойдет и просто понимание конверсии в чекауте)
Определяем конверсию по разным сегментам. Интересуют два: C1, CN (первый покупатель, последующие покупки).
Всё, данные настроены.
Мы часто сталкиваемся с запросами о том, что клиентам нужна аналитика более серьёзная. Иногда это оправдано, часто - нет, потому что слабая аналитическая культура при любом, самом продвинутом инструменте (AA, OWOX, etc) всегда остаётся слабой культурой. Так что если сейчас никакие данные не используются, начните с самых простых инструментов и далее можно усложнять.
Очень частая ошибка в измерениях C1/CN. Это легко исправляется)
ну вот. Я про PDCA и запутанные среды, а вы опять про Путина! ;)
Более 142 млрд евро ЕС за 2004 год потратил денег на разработку, которая не привела ни к каким целям. Как видите, это не только в России происходит. Почитайте Сазерленда - он начинает с неудачного кейса в ФБР, которые десять лет разрабатывали софт. Миллиарды долларов потрачены. Цели расписаны не то чтобы на 2 листа - тома бумаги исписаны. А результата не было. В запутанных средах конвейер не работает.
Это не беда, деньги - вторичны.
Убежден, что практики IM/UE можно и вовсе без денег внедрять. Если есть желание - всё будет. Ни деньги, ни количество разработки само по себе к результату ведь не ведет.
Не помню чтобы мы с вами работали..
Не удалось мне в статье донести мысль о том, что "интернет-магазин на Magento" - это не столько разработка, сколько целеполагание. Будем стараться больше.
Если оно у вас не работает, значит вы не в том культурном пласте находитесь, или нарушаете техники. Чаще - всё вместе.
Во что выливается например Scrum? Недели начинают называть спринтами, а поток задач теперь - "бэклог". Вот и весь "эйджаил". не удивительно, что это не работает.
И культурный аспект - штука сложная.
Практики, работающие в красном уровне (см. спиральную динамику), не работают уже в синей компании. Agile, TQM/TOC - это всё аспекты верхних уровней осознанности, и если вы строите конвейер, то гибкость там строить иногда просто негде без осознанного движения (вот Тойоте удалось упаковать конвейер в гибкость, очень рекомендую посмотреть на их опыт).
Не совсем так ))
Заказ в запутанной среде (разработка ПО) и упорядоченной (простой, типа производства гамбургера, или сложной, типа производства моста), требуют разной квалификации.
Поэтому когда мы обсуждаем заказ, мы начинаем ориентироваться на важные цели клиента, составляя Impact Mapping (иногда мы его составляем, но клиент с этим не работает - часто встречается с крупными компаниями). Я считаю, что все-равно успех проекта должен обеспечиваться разработчиками. Иначе через год разработчики отползают от проекта: "мы просто делали ваши задачи. Откуда же нам было знать, что вы не зарабатывали на этих решениях". Вы же к врачу не приходите со списком: "прооперируйте мне тут и вот тут, и еще промывание желудка сделайте"? Вы приходите с задачей, а он обеспечивает решение. Так же должно быть и с инженерами, если они не хотят носить звание "кодер".
Чтобы посчитать юнит-экономику, не нужно быть ни математическим гением, ни ярдовой компанией.
Речь как раз в том, что стоимость разработки всегда высока. И важно делать более рентабельные вещи в первую очередь, и менее рентабельные - потом.
Для этого есть огромное количество практик для этого (тактические: юнит-экономика, Матрица Эйзенхауэра, Scrum Planning Poker, стратегические: Impact Mapping, юнит-экономика).
Часто клиенты убеждены, что разработка сама по себе без нормального целеполагания даст экономический эффект (вот эти вот все "Лишь бы сделать правильную архитектуру", "Сделать UX дизайн", "Реализовать фич больше чем у конкурента"). Не удивительно, что этого не происходит. И чтобы решить эту проблему, клиенты начинают использовать методики упорядоченных систем (техническое задание например).
Методы, которые применяются в упорядоченных системах, не обеспечивают достижения целей бизнеса в запутанной среде (любая разработка выше совсем элементарной).
вопрос не только и не столько в пушах. Сами пуш-нотификации довольно спорны - ведь, как вы знаете, сейчас вообще каждый сайт считает своим долгом запросить у тебя разрешения на пуши. Безусловно, здесь должны устояться отраслевые стандарты (в каких случаях это норм, в каких - вредно). Apple пошла по пути "на сайте - нет, но если ты опубликовал апп - пушь". APNS (спасибо, коллегам).
Workaround напрашивается сам собой, которые немного увеличивают косты конкретно для пушей. Это некоторые минусы, поддерживаю.
Мой посыл был в том, что на сегодня в JS можно и машинное обучение (и даже обучать на устройствах - tensorflow.js), внедряется Generic Sensor API и так дальше - получается, что сбылась мечта Стива Джобса и вот-вот вообще не нужны будут нейтивы. Я уже не говорю про скорость рендера CSS (60FPS и более) и революциями в CSS которые менее громкие, но происходят на наших глазах. Получается, что PWA при всех минусах на сегодня имеет такое количество плюсов!
Не ответил на вопрос про деньги - сам не задумывался об этом применительно к нашей компании)) . Начал тут считать - получается примерно 0,6 млн деньгами и примерно 1,5 на сотрудников которые именно за BPM часть отвечали (разработчики и те кто тратил время на конструирование и внедрение БП).
В среднем, каждую неделю мы внедряем по одному новому процессу (без разработки, в конструкторе бизнес-процессов) и раз в месяц по одному существенному изменению в процессах с помощью дополнительной автоматизации.
Мы выбрали Битрикс-24 (потому что сами её внедряем). Бюджет - ну, мы постоянно выделили одного разработчика на добавления и исправления (это новые активити, это сложные всякие печатные формы и реализация workflow). Разработчик закреплен на проекте всегда.
Бюджет внедрения нужно смотреть по году, для клиентов это в лайтовом режиме около 200 тыс в месяц на маленькое подразделения или на департамент крупного (потому что разработки меньше чем реального внедрения в бизнес и всего что сопровождает бизнес-процессы: регламенты, обучение, продажа этих изменений внутри компании - это медленно и очень сложно). И через полгода возникнет еще плечо техподдержки. Но давайте честно: бизнес-процесс можно накидать и без денег (мы так и делали в целом), просто при усложнении бизнес-процессов возникают такие потребности, как упрощение процессов на схеме (упрощение поддержки), более сложные действия и т.п. Так что про бюджет мне очень сложно сказать абстрактно.
Кстати, мы изначально пытались использовать JIRA. Ведь она тоже может использоваться в качестве BPM: конструктор workflow и триггеры имеются, но сложность поддержки и отсутствие CRM в том (продвинутом) виде делают систему сложно интегрируемой именно в бизнес-процессы. Т.е. они нарисованы и работают в одной системе, а большая часть жизни компании в другой и это порождает проблемы. В этом смысле, возможность добавлять активити в схемы в Б24 (как и в Biztalk, Salesforce и т.п.) очень выручает.
У нас - Битрикс-24 в качестве BPM. Клиентам внедряем ещё и Salesforce.
По практике общения со стартапами, они могут так уж и быть поддерживать бизнес-процессы которые для них сделаны головным подразделением. Опять же, стартап стартапу рознь. Есть стартапы, которые в поиске своего продукта. Это компактные группы, которым пока быстрее обсудить все на бумажках/канбан-доске или ее аналогах в максимально простых трекерах задач (там Трелло какой-нибудь). Есть стартапы в смысле новые предприятия, которые свой продукт нашли и все дело в его поставке. Т.е. строго говоря это не стартапы в общепринятом понимании, а просто молодые маленькие предприятия. Там, полностью согласен, имеет смысл накидывать бизнес-процессы сразу (если у маленьких предприятий на это есть деньги и ресурсы ;)
Да, возможно и такое! В теории.
Но на практике, всегда есть показатели, которые твой технический долг олицетворяют.
Количество ошибок в статанализе не подходит? Ок, давайте смотреть на ошибки на аппах.
Там всё чисто, а проект "в жопе"? Ок, давайте посмотрим на общения первой линии поддержки и второй.
Если ошибок нет, операторы КЦ молчат, условно, количество отмененных заказов небольшое - то или проект не так плох, или трафика нет.
Задача менеджера не жаловаться, а такие параметры искать. Парадигма Disciplined Agile Delivery
как раз и говорит, что у тебя должна быть цифра, которая свидетельствует как-то о техническом долге. Если человек не в состоянии такую цифру подобрать, то возможно он не должен быть менеджером проекта.
Это разное.
Есть гигиена, есть лечение.
Ритмичность релизов, количество ошибок на app-ах, pagespeed ранки и прочее - это именно параметры дисциплины. Есть такое понятие, как DAD (disciplined Agile delivery).
Например, у нас Magento. Для неё есть статический анализ, для неё есть встроенный репорт об ошибках. Менеджеру важно знать одно: что там в цифрах.
Если сегодня ошибок 10 а завтра 20 - плохо. Если сегодня 20 а завтра после релиза стало 10 - хорошо. Подробности не нужны.
Аналогично, если у вас app сервер рапортует о 5000 ошибках в сутки, а потом стало 4000 - молодцы, скорее всего стало лучше (или трафик снизился, но это детали).
Да, вы скажете, что всё это уже есть в New Relic, есть Zabbix, есть масса штук. Только всё это не используется в ритмичных улучшениях (когда мы понимаем что технический долг большой, и нужно его маленькими итерациями улучшать).
Количество сообщений в чате между первой линией поддержки и второй и связь подтвержденных и не подтвержденных обращений очень важна по той же причине для менеджера:
если у тебя на проекте 50 сообщений и подтвержденных 2 - значит, первой линии не хватает знаний (документация, тренинги).
Если 50 сообщений и 40 подтвержденных - значит, ситуация с багами именно такая, и тут нужно смотреть глубже (менеджер должен классифицировать эти обращения и вынести на обсуждение команды что сделать чтобы эти и эти типы обращений уменьшить). Часто это бывают проблемы в интерфейсе (нелогично), а не только баги. Но это так или иначе технический долг. Если ты его не оцифруешь, то ты с ним и не работаешь.