0 added
0 removed
Original
2026-01-01
Modified
2026-03-10
1
<ul><li><a>Девять проблем отдела разработки</a><ul><li><a>Решения</a></li>
1
<ul><li><a>Девять проблем отдела разработки</a><ul><li><a>Решения</a></li>
2
<li><a>Инструменты и практики</a></li>
2
<li><a>Инструменты и практики</a></li>
3
<li><a>План действий</a></li>
3
<li><a>План действий</a></li>
4
<li><a>Ожидаемый результат</a></li>
4
<li><a>Ожидаемый результат</a></li>
5
</ul></li>
5
</ul></li>
6
</ul><p><em>Предлагаем вашему вниманию проектную работу<strong>Романа Прудкогляда</strong>, выпускника курса "<a>Delivery Manager</a>".</em></p>
6
</ul><p><em>Предлагаем вашему вниманию проектную работу<strong>Романа Прудкогляда</strong>, выпускника курса "<a>Delivery Manager</a>".</em></p>
7
<ul><li><strong>LinkedIn</strong>:<a>linkedin.com/in/roman-prudkogliad-7526a44</a></li>
7
<ul><li><strong>LinkedIn</strong>:<a>linkedin.com/in/roman-prudkogliad-7526a44</a></li>
8
</ul><ul><li><strong>Telegram</strong>: @RomanPrudkogliad</li>
8
</ul><ul><li><strong>Telegram</strong>: @RomanPrudkogliad</li>
9
</ul><p>Устроившись в компанию N, я первым делом провожу аудит доверенного мне отдела разработки. Оказывается, что отдел находится в неработоспособном состоянии: процессов нет; что команды делают и как именно - никто не знает; тимлиды между собой никак не коммуницируют, а топ-менеджеры не понимают, что происходит в отделе. </p>
9
</ul><p>Устроившись в компанию N, я первым делом провожу аудит доверенного мне отдела разработки. Оказывается, что отдел находится в неработоспособном состоянии: процессов нет; что команды делают и как именно - никто не знает; тимлиды между собой никак не коммуницируют, а топ-менеджеры не понимают, что происходит в отделе. </p>
10
<p>Все эти проблемы мне предстоит решить. Здесь вы узнаете о том, как я это делаю.</p>
10
<p>Все эти проблемы мне предстоит решить. Здесь вы узнаете о том, как я это делаю.</p>
11
<h2><strong>Девять проблем отдела разработки</strong></h2>
11
<h2><strong>Девять проблем отдела разработки</strong></h2>
12
<p><strong>Нет процесса постановки и завершения задачи.</strong>Никто не знает, как и кому ставить задачу на разработку и что должно быть в описании задачи. Сроки выполнения и ход работы - тоже неясны. </p>
12
<p><strong>Нет процесса постановки и завершения задачи.</strong>Никто не знает, как и кому ставить задачу на разработку и что должно быть в описании задачи. Сроки выполнения и ход работы - тоже неясны. </p>
13
<p><strong>Отсутствуют горизонтальные связи в отделе.</strong>Тимлиды не понимают специфику работы других команд, не разбираются в их технологических стеках. Команды могут работать над одной задачей и не знать, что выполняют одинаковую работу. Также команды не обмениваются опытом и повторяют ошибки друг за другом. </p>
13
<p><strong>Отсутствуют горизонтальные связи в отделе.</strong>Тимлиды не понимают специфику работы других команд, не разбираются в их технологических стеках. Команды могут работать над одной задачей и не знать, что выполняют одинаковую работу. Также команды не обмениваются опытом и повторяют ошибки друг за другом. </p>
14
<p><strong>Отсутствует коммуникация с топ-менеджментом.</strong>Так как нет процессов и невозможно планировать работу отдела, топ-менеджмент не может планировать развитие компании. Это блокирует многие инвестиционные проекты и новые возможности.</p>
14
<p><strong>Отсутствует коммуникация с топ-менеджментом.</strong>Так как нет процессов и невозможно планировать работу отдела, топ-менеджмент не может планировать развитие компании. Это блокирует многие инвестиционные проекты и новые возможности.</p>
15
<p><strong>Частые кризисы в отделе разработки</strong>. Это сигнал о том, что продукт работает нестабильно, снижается NPS (индекс потребительской лояльности), падают доходы самой компании</p>
15
<p><strong>Частые кризисы в отделе разработки</strong>. Это сигнал о том, что продукт работает нестабильно, снижается NPS (индекс потребительской лояльности), падают доходы самой компании</p>
16
<p><strong>Бэкенд разрабатывается на Java 8, БД - на</strong><strong>PostgreSQL 9.2, Spring 4.3, Spring Boot 1.5.</strong>Многие из этих версий уже не поддерживаются, при серьёзных уязвимостях - будет сложно починить. При попытках создать микросервисы, получается распределенный монолит. Релиз новых версий монолита требует участия всех QA, попавших в этот деплой. Каждый деплой отнимает полдня. </p>
16
<p><strong>Бэкенд разрабатывается на Java 8, БД - на</strong><strong>PostgreSQL 9.2, Spring 4.3, Spring Boot 1.5.</strong>Многие из этих версий уже не поддерживаются, при серьёзных уязвимостях - будет сложно починить. При попытках создать микросервисы, получается распределенный монолит. Релиз новых версий монолита требует участия всех QA, попавших в этот деплой. Каждый деплой отнимает полдня. </p>
17
<p><strong>Фронтенд разрабатывается на Angular 11 и TypeScript 4.1.</strong>Эти версии библиотек необходимо обновить. В одном репозитории - огромное количество кода, на сборку уходит много времени. После каждого исправления разработчик ждёт сборки по 10-20 минут в зависимости от мощности компьютера. </p>
17
<p><strong>Фронтенд разрабатывается на Angular 11 и TypeScript 4.1.</strong>Эти версии библиотек необходимо обновить. В одном репозитории - огромное количество кода, на сборку уходит много времени. После каждого исправления разработчик ждёт сборки по 10-20 минут в зависимости от мощности компьютера. </p>
18
<p><strong>QA пишут автотесты на<a>Selenium</a>v3.141.5</strong>. Старая и медленная версия Selenium. Прогон тестов занимает от двух до четырёх часов. Много случайно "упавших" тестов<em>(flaky tests)</em>. Разработчики практически не пишут юнит-тестов, а если пишут, то такие тесты - низкого качества.</p>
18
<p><strong>QA пишут автотесты на<a>Selenium</a>v3.141.5</strong>. Старая и медленная версия Selenium. Прогон тестов занимает от двух до четырёх часов. Много случайно "упавших" тестов<em>(flaky tests)</em>. Разработчики практически не пишут юнит-тестов, а если пишут, то такие тесты - низкого качества.</p>
19
<p><strong>Система виртуализации - старая, "виртуалки" постоянно ломаются.</strong>Внедрены система контейнеризации Docker и система управления контейнерами Kubernetes, но разработчики не придерживаются требований к разработке сервисов для контейнеров. Поэтому возникает много проблем с поддержкой и обновлением. Тестовые среды постоянно ломаются, а их починкой не занимается никто. Проблемы с production-окружением часто игнорируются. Проблемы пользователей не доходят до отдела разработки. </p>
19
<p><strong>Система виртуализации - старая, "виртуалки" постоянно ломаются.</strong>Внедрены система контейнеризации Docker и система управления контейнерами Kubernetes, но разработчики не придерживаются требований к разработке сервисов для контейнеров. Поэтому возникает много проблем с поддержкой и обновлением. Тестовые среды постоянно ломаются, а их починкой не занимается никто. Проблемы с production-окружением часто игнорируются. Проблемы пользователей не доходят до отдела разработки. </p>
20
<p><strong>Следствие проблем</strong></p>
20
<p><strong>Следствие проблем</strong></p>
21
<p>Многие сотрудники выгорели, отдел теряет специалистов.</p>
21
<p>Многие сотрудники выгорели, отдел теряет специалистов.</p>
22
<h2><strong>Решения</strong></h2>
22
<h2><strong>Решения</strong></h2>
23
<p><strong>Проекты</strong></p>
23
<p><strong>Проекты</strong></p>
24
<ul><li>Я согласую зону ответственности и мои цели на квартал, полгода, год. </li>
24
<ul><li>Я согласую зону ответственности и мои цели на квартал, полгода, год. </li>
25
</ul><ul><li>Необходимо расписать устав проектов, согласовать устав, бюджеты, цели и ход проектов со стейкхолдерами. Также нужно собрать метрики по проектам: в зависимости от проекта выбираем:</li>
25
</ul><ul><li>Необходимо расписать устав проектов, согласовать устав, бюджеты, цели и ход проектов со стейкхолдерами. Также нужно собрать метрики по проектам: в зависимости от проекта выбираем:</li>
26
</ul><ul><li>метрики PMBOK</li>
26
</ul><ul><li>метрики PMBOK</li>
27
<li>набор других подходящих метрик для Scrum или Kanban</li>
27
<li>набор других подходящих метрик для Scrum или Kanban</li>
28
<li>метрики для waterfall-проектов.</li>
28
<li>метрики для waterfall-проектов.</li>
29
</ul><p><strong>Горизонтальные связи</strong></p>
29
</ul><p><strong>Горизонтальные связи</strong></p>
30
<p>Предлагаю сформировать:</p>
30
<p>Предлагаю сформировать:</p>
31
<ul><li>проектные команды разработки</li>
31
<ul><li>проектные команды разработки</li>
32
<li>сервисную команду с DevOps (у каждого члена сервисной команды - своя зона ответственности)</li>
32
<li>сервисную команду с DevOps (у каждого члена сервисной команды - своя зона ответственности)</li>
33
</ul><p>Состав команд разработки:</p>
33
</ul><p>Состав команд разработки:</p>
34
<ul><li>1 тимлид</li>
34
<ul><li>1 тимлид</li>
35
<li>6 разработчиков: три бэкенд- и три фронтенд-разработчика</li>
35
<li>6 разработчиков: три бэкенд- и три фронтенд-разработчика</li>
36
<li>2 QA</li>
36
<li>2 QA</li>
37
</ul><p><strong>Структура отдела</strong></p>
37
</ul><p><strong>Структура отдела</strong></p>
38
<a></a><p>Также считаю необходимым<strong>организовать работу сообществ бэкенд- и фронтенд-разработчиков, тестировщиков, DevOps.</strong></p>
38
<a></a><p>Также считаю необходимым<strong>организовать работу сообществ бэкенд- и фронтенд-разработчиков, тестировщиков, DevOps.</strong></p>
39
<p><strong>Функции и устройство сообществ</strong></p>
39
<p><strong>Функции и устройство сообществ</strong></p>
40
<p>Профессиональные сообщества отвечают за техническое развитие отделов и найм специалистов, составляют карты развития сотрудников. Так мы создаём горизонтальные связи между командами. </p>
40
<p>Профессиональные сообщества отвечают за техническое развитие отделов и найм специалистов, составляют карты развития сотрудников. Так мы создаём горизонтальные связи между командами. </p>
41
<ul><li>Раз в месяц сообщества рассказывают о реализованных технические инициативах, делятся дальнейшими планами. </li>
41
<ul><li>Раз в месяц сообщества рассказывают о реализованных технические инициативах, делятся дальнейшими планами. </li>
42
<li>Сообщества собираются раз в неделю и ведут бэклоги с инициативами и техническим долгом. </li>
42
<li>Сообщества собираются раз в неделю и ведут бэклоги с инициативами и техническим долгом. </li>
43
<li>У каждого сообщества есть лидер (председатель), который отвечает за сообщество и помогает формировать бэклог. </li>
43
<li>У каждого сообщества есть лидер (председатель), который отвечает за сообщество и помогает формировать бэклог. </li>
44
</ul><p><strong>Вертикальные связи</strong></p>
44
</ul><p><strong>Вертикальные связи</strong></p>
45
<p>Для каждой команды предлагаю сформировать бэклог, куда стейкхолдеры и председатель профессионального сообщества смогут добавлять задачи. Бэклог будут регулярно проверять и уточнять. Также предлагаю стейкхолдерам и инженерному отделу проверять работу сообществ ежемесячно. </p>
45
<p>Для каждой команды предлагаю сформировать бэклог, куда стейкхолдеры и председатель профессионального сообщества смогут добавлять задачи. Бэклог будут регулярно проверять и уточнять. Также предлагаю стейкхолдерам и инженерному отделу проверять работу сообществ ежемесячно. </p>
46
<p>Как я уже говорил, проблемы пользователей не доходят до отделов разработки, а ведь команды и стейкхолдеры должны получать информацию о дефектах. Поэтому необходимо создать "процесс эскалации".</p>
46
<p>Как я уже говорил, проблемы пользователей не доходят до отделов разработки, а ведь команды и стейкхолдеры должны получать информацию о дефектах. Поэтому необходимо создать "процесс эскалации".</p>
47
<h2><strong>Инструменты и практики</strong></h2>
47
<h2><strong>Инструменты и практики</strong></h2>
48
<ul><li>Три проектные команды будут работать над внутренним продуктом. Эти команды внедряют гибкие методологии разработки (Scrum).</li>
48
<ul><li>Три проектные команды будут работать над внутренним продуктом. Эти команды внедряют гибкие методологии разработки (Scrum).</li>
49
<li>Две другие проектные команды работают над проектами для заказчиков и работают<a>по методологии</a>Waterfall.</li>
49
<li>Две другие проектные команды работают над проектами для заказчиков и работают<a>по методологии</a>Waterfall.</li>
50
<li>Команда DevOps работает с входящим потоком запросов от проектных команд; внутри команды действует Kanban.</li>
50
<li>Команда DevOps работает с входящим потоком запросов от проектных команд; внутри команды действует Kanban.</li>
51
<li>Каждая команда сама должна решить, сколько времени выделять на технический долг или на технические инициативы. Я бы предложил выделять на это 15-20% от времени спринта или каждый пятый спринт целиком. </li>
51
<li>Каждая команда сама должна решить, сколько времени выделять на технический долг или на технические инициативы. Я бы предложил выделять на это 15-20% от времени спринта или каждый пятый спринт целиком. </li>
52
<li>Внедрить ревью кода и архитектурных решений на стадии дизайна и анализа будущих изменений. Костяк из лидеров, способных проводить такой анализ, будет формироваться в профессиональных сообществах.</li>
52
<li>Внедрить ревью кода и архитектурных решений на стадии дизайна и анализа будущих изменений. Костяк из лидеров, способных проводить такой анализ, будет формироваться в профессиональных сообществах.</li>
53
<li>Внедрить новую стадию проверки кода, статический анализатор кода и библиотек на уязвимости. </li>
53
<li>Внедрить новую стадию проверки кода, статический анализатор кода и библиотек на уязвимости. </li>
54
<li>Закрепить за каждым сервисом ответственную команду. </li>
54
<li>Закрепить за каждым сервисом ответственную команду. </li>
55
<li>Показывать технический долг, задачи и приоритет задач из саппорта на спринт-ревью команды</li>
55
<li>Показывать технический долг, задачи и приоритет задач из саппорта на спринт-ревью команды</li>
56
<li>Внедрить практику технических чтений: команды будут делиться новыми техническими решениями, решениями архитектурных задач, создавать записи архитектурных решений<em>(ADR, architectural decision records)</em></li>
56
<li>Внедрить практику технических чтений: команды будут делиться новыми техническими решениями, решениями архитектурных задач, создавать записи архитектурных решений<em>(ADR, architectural decision records)</em></li>
57
<li>Создать карту компетенций для каждой специализации: бэкенд, фронтенд, QA, DevOps: для каждого отдела создаётся матрица скилов и разрабатывается карьерный путь; расписываются уровни для каждого отдела: Intern, Junior, Middle, Senior, Lead. Лиды в командах и профсообществах отвечают за развитие сотрудников. </li>
57
<li>Создать карту компетенций для каждой специализации: бэкенд, фронтенд, QA, DevOps: для каждого отдела создаётся матрица скилов и разрабатывается карьерный путь; расписываются уровни для каждого отдела: Intern, Junior, Middle, Senior, Lead. Лиды в командах и профсообществах отвечают за развитие сотрудников. </li>
58
<li>Разработать и внедрить процесс эскалации. Также внедрить автоматические инструменты мониторинга и эскалации ошибок в ответственные команды. </li>
58
<li>Разработать и внедрить процесс эскалации. Также внедрить автоматические инструменты мониторинга и эскалации ошибок в ответственные команды. </li>
59
<li>Привлечь HRBP. Необходимо оценивать мотивацию сотрудников отдела разработки, слаживать команду; организовывать проверки для работников с низкой производительностью, и, если нужно, увольнять.</li>
59
<li>Привлечь HRBP. Необходимо оценивать мотивацию сотрудников отдела разработки, слаживать команду; организовывать проверки для работников с низкой производительностью, и, если нужно, увольнять.</li>
60
</ul><h2><strong>План действий</strong></h2>
60
</ul><h2><strong>План действий</strong></h2>
61
<ol><li>Встретиться с командами и руководителями команд. Обучить лидов и команды гибким методологиям. </li>
61
<ol><li>Встретиться с командами и руководителями команд. Обучить лидов и команды гибким методологиям. </li>
62
<li>Обучить лидов проводить встречи "один на один", составлять карьерные пути и ставить цели. </li>
62
<li>Обучить лидов проводить встречи "один на один", составлять карьерные пути и ставить цели. </li>
63
<li>Сформировать бэклог команд со стейкхолдерами и лидами, упорядочить бэклог по степени важности задач, спланировать спринты. Постепенно запустить гибкие методологии. Организовать регулярные встречи в командах: планирование, "daily", упорядочивание бэклога, организацию "демо" и "ретро" в командах. </li>
63
<li>Сформировать бэклог команд со стейкхолдерами и лидами, упорядочить бэклог по степени важности задач, спланировать спринты. Постепенно запустить гибкие методологии. Организовать регулярные встречи в командах: планирование, "daily", упорядочивание бэклога, организацию "демо" и "ретро" в командах. </li>
64
<li>Установить коммуникацию с стейкхолдерами. Организовать ежемесячные встречи, отчетчитываться о проекте в системе трекинга задач, чтобы стейкхолдеры всегда могли узнать состояние проекта и прогнозы.</li>
64
<li>Установить коммуникацию с стейкхолдерами. Организовать ежемесячные встречи, отчетчитываться о проекте в системе трекинга задач, чтобы стейкхолдеры всегда могли узнать состояние проекта и прогнозы.</li>
65
<li>Создать процесс, который поможет передать командам и стейкхолдерам сведения о дефектах из "продакшена". Распределить ответственность за сервисы между командами, закрепить границы ответственности. У каждой команды должен быть свой канал, куда пользователи и автоматические системы мониторинга смогут сообщать о проблемах с сервисом. Также каналы команд можно будет использовать и для ChatOps.</li>
65
<li>Создать процесс, который поможет передать командам и стейкхолдерам сведения о дефектах из "продакшена". Распределить ответственность за сервисы между командами, закрепить границы ответственности. У каждой команды должен быть свой канал, куда пользователи и автоматические системы мониторинга смогут сообщать о проблемах с сервисом. Также каналы команд можно будет использовать и для ChatOps.</li>
66
<li>Постепенно запустить профсообщества бэкенд- и фронтенд-разработчиков, тестировщиков, DevOps. </li>
66
<li>Постепенно запустить профсообщества бэкенд- и фронтенд-разработчиков, тестировщиков, DevOps. </li>
67
</ol><p><strong>Расчёт ROI для инженерных инициатив сообществ</strong></p>
67
</ol><p><strong>Расчёт ROI для инженерных инициатив сообществ</strong></p>
68
<p><strong>Пример расчета ROI 1:</strong> Обновление библиотек бэкенда. Риски: уязвимости в старых библиотеках могут вызвать отказ или утечку персональных данных клиентов. Затраты на обновление библиотек: один человеко-месяц на одну библиотеку. Потери в случае утечки данных: 10-20% годового дохода компании в качестве штрафа. ROI = (2 000 0000 - 5000) ÷ 5000 = 400%.</p>
68
<p><strong>Пример расчета ROI 1:</strong> Обновление библиотек бэкенда. Риски: уязвимости в старых библиотеках могут вызвать отказ или утечку персональных данных клиентов. Затраты на обновление библиотек: один человеко-месяц на одну библиотеку. Потери в случае утечки данных: 10-20% годового дохода компании в качестве штрафа. ROI = (2 000 0000 - 5000) ÷ 5000 = 400%.</p>
69
<p><strong>Пример расчета ROI 2:</strong>Обновление библиотек фронтенда для уменьшения времени сборки для каждого разработчика. Стоимость обновления: 0,5 человеко-месяца за библиотеку. Потери при сборке: </p>
69
<p><strong>Пример расчета ROI 2:</strong>Обновление библиотек фронтенда для уменьшения времени сборки для каждого разработчика. Стоимость обновления: 0,5 человеко-месяца за библиотеку. Потери при сборке: </p>
70
<p>15 человек производят 4-6 сборок в день.15 x 6 x 20(мин) = 1800 x 20 (рабочих дней) = 36000 мин/мес = 600 ч/мес = 3.75 человеко-месяца х 5000 = 18750＄. ROI = (18750 - 2500) ÷ 2500 = 6.5%</p>
70
<p>15 человек производят 4-6 сборок в день.15 x 6 x 20(мин) = 1800 x 20 (рабочих дней) = 36000 мин/мес = 600 ч/мес = 3.75 человеко-месяца х 5000 = 18750＄. ROI = (18750 - 2500) ÷ 2500 = 6.5%</p>
71
<p>Такие расчёты помогут встроить технические задачи в общий бэклог с продуктовыми задачами. </p>
71
<p>Такие расчёты помогут встроить технические задачи в общий бэклог с продуктовыми задачами. </p>
72
<ol><li>Улучшить релизный процесс по результатам аудита в командах, внедрить и улучшить метрики DORA (DevOps Research and Assessment), провести оценку релизного процесса по DORA.</li>
72
<ol><li>Улучшить релизный процесс по результатам аудита в командах, внедрить и улучшить метрики DORA (DevOps Research and Assessment), провести оценку релизного процесса по DORA.</li>
73
<li>Совместно со стейкхолдерами разработать систему метрик для оценки работы команд. В командах с лидами разработать KPI для участников команд, согласовать метрики и KPI со всем отделом, внедрить регулярные отчеты по KPI и метрикам команд: "capacity", "performance", "review iterations"</li>
73
<li>Совместно со стейкхолдерами разработать систему метрик для оценки работы команд. В командах с лидами разработать KPI для участников команд, согласовать метрики и KPI со всем отделом, внедрить регулярные отчеты по KPI и метрикам команд: "capacity", "performance", "review iterations"</li>
74
</ol><h2><strong>Ожидаемый результат</strong></h2>
74
</ol><h2><strong>Ожидаемый результат</strong></h2>
75
<p><em>Когда мера становится целью, она перестаёт быть хорошей мерой</em></p>
75
<p><em>Когда мера становится целью, она перестаёт быть хорошей мерой</em></p>
76
<p>Чарльз Гудхарт</p>
76
<p>Чарльз Гудхарт</p>
77
<ul><li>Команды обучены; работают, используя гибкие методологии. Каждая команда проводит встречи, чтобы поддерживать процесс разработки: daily, "груминг", планирование, спринт, демо, ретро. </li>
77
<ul><li>Команды обучены; работают, используя гибкие методологии. Каждая команда проводит встречи, чтобы поддерживать процесс разработки: daily, "груминг", планирование, спринт, демо, ретро. </li>
78
<li>Руководители регулярно проводят встречи один на один: раз в месяц или в квартал. Команды оперируют метриками для оценки собственной работы: метриками по дефектам (информация о дефектах поступает от пользователей) и метриками по объему технического долга. Метрики презентуются на каждом демо команд. Регулярные отчёты по метрикам позволяют быстро реагировать на изменения [в метриках] и принимать соответствующие решения.</li>
78
<li>Руководители регулярно проводят встречи один на один: раз в месяц или в квартал. Команды оперируют метриками для оценки собственной работы: метриками по дефектам (информация о дефектах поступает от пользователей) и метриками по объему технического долга. Метрики презентуются на каждом демо команд. Регулярные отчёты по метрикам позволяют быстро реагировать на изменения [в метриках] и принимать соответствующие решения.</li>
79
<li>Профсообщества проводят встречи раз в неделю, чтобы расставить приоритеты в работе над техническими задачами и организовать технические инициативы в командах.</li>
79
<li>Профсообщества проводят встречи раз в неделю, чтобы расставить приоритеты в работе над техническими задачами и организовать технические инициативы в командах.</li>
80
<li>Стейкхолдеры всегда в курсе деятельности и планов команд. Регулярные встречи со стейкхолдерами для расстановки приоритетов в бэклоге и для разбора задач позволяют установить двустороннюю коммуникацию. </li>
80
<li>Стейкхолдеры всегда в курсе деятельности и планов команд. Регулярные встречи со стейкхолдерами для расстановки приоритетов в бэклоге и для разбора задач позволяют установить двустороннюю коммуникацию. </li>
81
<li>Чёткие планы позволяют инвестировать в будущую разработку продуктов. Повышается NPS, компания увеличивает доход от своих продуктов, получает инвестиции для новых проектов. </li>
81
<li>Чёткие планы позволяют инвестировать в будущую разработку продуктов. Повышается NPS, компания увеличивает доход от своих продуктов, получает инвестиции для новых проектов. </li>
82
<li>Улучшается eNPS, уменьшается текучка кадров. Стабилизируется работа команд. Сотрудники учатся презентовать внутренние технические решения, выступать на встречах. Таким образом повышается публичный рейтинг компании внутри сообщества разработчиков.</li>
82
<li>Улучшается eNPS, уменьшается текучка кадров. Стабилизируется работа команд. Сотрудники учатся презентовать внутренние технические решения, выступать на встречах. Таким образом повышается публичный рейтинг компании внутри сообщества разработчиков.</li>
83
</ul><a></a><p><em>Новая структура отдела </em></p>
83
</ul><a></a><p><em>Новая структура отдела </em></p>
84
<p>Также, возможно, вам будет интересен<a>еще один проект</a>на аналогичную тему.</p>
84
<p>Также, возможно, вам будет интересен<a>еще один проект</a>на аналогичную тему.</p>
85
85