Системное мышление и бизнес-анализ для руководителей и тех, кто ими хочет стать

И всё это нужно было делать по правилам, которые не учитывали гибкость.

История третья: как я скрещивал ГОСТ с гибкими методологиями

Я не мог отказаться от ГОСТа — тендер бы не прошёл. Но я не мог и просто копировать его — проект бы застрял. Нужно было найти баланс.

Тогда я начал адаптировать ГОСТ под гибкие методологии.

Где-то я добавлял текст, чтобы соответствовать требованиям закупщиков. Например, заполнял разделы про архитектурные решения и сценарии тестирования.

Где-то я убирал текст, чтобы сохранить гибкость. Например, сокращал объём документа до 5–10 страниц вместо 50. Убирал дублирующие разделы. Заменял сложные формулировки на простые.

Где-то я менял форму, сохраняя суть. Например, вместо 100-страничного ТЗ я делал 5-страничный документ с чёткими требованиями, а всё остальное — в приложениях.

Я не ломал ГОСТ, я его пересобирал под свои задачи. Сохранял структуру, но делал её живой. Добавлял разделы, которые были нужны команде. Убирал то, что не приносило ценности.

В итоге все были довольны:

Закупщики получили документ, который проходил тендеры.

Исполнители не утонули в бюрократии, и мы могли их контролировать для быстрого выпуска релизов.

Я получил рабочий инструмент, который не убивал гибкость.

Почему методологии не работают «из коробки»

У меня есть простое правило: методология — это каркас, а не стена. Она даёт тебе опору, но не диктует, куда идти.

Почему люди терпят неудачу?

Они копируют без адаптации. Прочитали книгу, посмотрели курс — и внедряют один в один. Но у них другой бизнес, другая команда, другие риски.

Они игнорируют культуру. Методологии создаются под определённые ценности. Если у вас культура «сделай быстро», а вы внедряете «сделай по документации» — будет конфликт.

Они забывают про людей. Команда не любит, когда ей навязывают процессы, в которых она не участвовала. Люди хотят понимать «зачем». Если они не видят смысла, они сопротивляются.

И ещё один важный момент: иногда методологию нужно не внедрять, а сознательно откладывать. Как я делал с ГОСТом до 2015 года. Это тоже выбор. И это тоже системное мышление.

Как я адаптирую методологии (практический алгоритм)

За годы работы я выработал систему. Она помогает мне не копировать, а адаптировать любую методологию под конкретный проект.

Шаг 1. Понять контекст

Я не беру методологию в руки, пока не отвечу на вопросы:

Что за бизнес? (стартап, корпорация, госкомпания)

Какая команда? (опыт, мотивация, состав)

Какие стратегические цели компании?

Какие SLA у компании перед клиентами?

Какие SLO между подразделениями?

В каком сегменте финансовой структуры компании я нахожусь (привет ЦФО)?

Какая техническая зрелость моего заказчика?

Без ответа на эти вопросы методология — просто набор букв.

Шаг 2. Взять из методологии только то, что даёт ценность

Я не внедряю методологию целиком. Я использую инструменты, которые решают реальные проблемы.

Если проблема — хаос в требованиях → беру из ГОСТа рекомендации по описанию требований.

Если проблема — медленная обратная связь → беру из Scrum ежедневные митинги.

Если проблема — непонимание архитектуры → беру из ArchiMate моделирование или более простую визуализацию.

Всё остальное — отбрасываю без сожаления.

Шаг 3. Адаптировать под свою скорость

В стартапе я не могу делать двухнедельные спринты и ежемесячные отчёты. Я делаю недельные спринты и отчёты по запросу. В госкорпорации и среднем бизнесе могут быть спринты 2–4 недельные, и это нормально для их скорости и бюрократии.

Скорость диктует формат. Не наоборот.

Шаг 4. Часто я принимаю решение единолично, но объясняю команде «зачем»

Я не провожу голосования. Я не собираю команду на совещание для обсуждения, какую методологию нам взять.

Я принимаю решение сам.

Потому что:

Я вижу общую картину, которую команда не всегда видит.

Я отвечаю за бюджет, сроки и результат.

У меня есть опыт, который команда не имеет.

Но есть одно условие: я всегда предварительно собираю информацию для взвешенного решения и в этом мне помогает команда и особенно эксперты и тимлиды. А затем объясняю команде, почему я принял именно это решение.

«Мы переходим на недельные спринты, потому что у нас нестабильная среда, и двухнедельный спринт — это слишком большой риск.»

«Мы будем использовать ГОСТ 34 только для архитектурных решений и требований. Всё остальное — упрощаем, чтобы не тормозить разработку.»

Шаг 5. Пересматривать процесс регулярно

Методология не статична. Я пересматриваю её эпизодически и в зависимости от размера компании, иногда раз в квартал, а иногда раз в год. Что работает — оставляем. Что нет — меняем.

Следует адаптировать методологии под ваш контекст. Не копировать, а брать лучшее и подстраивать под себя.

И последнее: почему это важно

Потому что мир не будет ждать, пока вы освоите идеальную методологию. Бизнес меняется, команды меняются, технологии меняются. Единственное, что остаётся неизменным — это ваше умение адаптироваться.

Методология — не догма. Это каркас, на котором вы строите свой дом. Дом должен быть удобным для вас, а не соответствовать картинке из журнала.

Иногда вы сознательно отказываетесь от методологии, потому что она мешает. Иногда вы адаптируете её под жёсткие требования заказчика. Иногда вы создаёте свой собственный подход из кусочков разных систем.

Главное — не быть формалистом. Относитесь к проекту как реалист и прагматик.

Глава 3. Ваш прошлый опыт — это не багаж, а фундамент

«То, что мы называем опытом, часто является просто памятью о наших ошибках» - Нассим Талеб

Одну фразу я слышу на каждой второй консультации: «У меня нет профильного образования, я ничего не умею».

Директор по производству, который 15 лет управлял заводом, думает, что его опыт не пригодится в IT. Руководитель отдела продаж, который строил команды и выводил продукты на рынок, считает, что его навыки не имеют отношения к управлению IT-проектами. Топ-менеджер из логистики уверен, что его знания о процессах перевозок бесполезны в IT.

Я всегда отвечаю одно и то же: давайте посмотрим на это с другого ракурса.

История первая: как директор по производству стал IT-руководителем

Сергей управлял заводом 15 лет. Он знал, как выстроить производственные процессы, как управлять людьми, как работать с бюджетом. Но когда его компания начала цифровую трансформацию, он почувствовал, что отстаёт.

— Я не знаю IT, — сказал он. — Я не понимаю, как управлять разработкой, как работать с Agile, как оценивать сроки.

— А что ты делал на заводе? — спросил я.

— Управлял производством. Отвечал за то, чтобы продукт был выпущен в срок, в нужном количестве и с нужным качеством. Управлял бригадами, складами, закупками.

— А IT-проект — это то же самое, — сказал я. — Только вместо станков — разработчики. Вместо складов — репозитории. Вместо закупок — бюджетирование. Суть та же: ты должен организовать процесс так, чтобы результат был достигнут с минимальными потерями.

Сергей задумался. А потом начал перекладывать свой опыт на новую область:

Его знание производственных процессов → понимание жизненного цикла разработки.

Его опыт управления бригадами → управление командами разработки.

Его понимание бюджетирования → управление IT-бюджетами.

Его навыки работы с поставщиками → управление внешними подрядчиками.

Через 6 месяцев он стал руководителем IT-направления в своей компании. Его заводской опыт оказался ценнее, чем он думал. Он знал, как организовать процесс, как управлять людьми, как работать с бюджетом. Оставалось только добавить инструменты.

История вторая: как продажник стал операционным директором

Анна работала в продажах 12 лет. Она строила команды, выводила продукты на рынок, управляла бюджетами. Когда ей предложили стать операционным директором в IT-компании, она испугалась.

— Я не понимаю, как управлять разработкой, — сказала она. — Я не знаю, что такое CI/CD, DevOps, микросервисы.

— А что ты умеешь? — спросил я.

— Строить команды, понимать клиентов, управлять деньгами, договариваться, видеть рыночные тренды.

— А операционный директор — это про то же самое, — сказал я. — Ты управляешь людьми, деньгами и процессами. Технологии — это просто инструмент, который помогает тебе делать твою работу быстрее и дешевле.

Сегодня Анна — успешный операционный директор. Она говорит:

«Мой опыт в продажах помогает мне каждый день. Я понимаю клиентов. Я понимаю команду. Я понимаю, как устроен бизнес. Технологии я учу по мере необходимости. Главное — я знаю, как управлять».

История третья: как начальник отдела логистики стал CIO

Михаил управлял логистикой в крупной компании. Он знал, как выстраивать цепочки поставок, как управлять рисками, как работать с подрядчиками. Когда компания решила создать IT-департамент, ему предложили его возглавить.

— Я не программист, — сказал он. — Я не могу быть CIO.

— А кто сказал, что CIO должен уметь программировать? — спросил я.

— Ну… я думал…

— CIO — это про управление IT-системами, — сказал я. — Ты умеешь управлять логистическими цепочками. Теперь будешь управлять IT-системами. Разница — в контексте. Но суть та же: ты видишь картину целиком, понимаешь, как связаны элементы, умеешь управлять рисками.

Михаил возглавил IT-департамент. Он не пишет код, но он выстроил процессы, которые позволяют компании работать с IT как с единой системой. И он делает это лучше, чем многие «технари», потому что он видит бизнес целиком.

Что такое домен и почему он важен для руководителя

Конец ознакомительного фрагмента.

Текст предоставлен ООО «Литрес».

Прочитайте эту книгу целиком, купив полную легальную версию на Литрес.

Безопасно оплатить книгу можно банковской картой Visa, MasterCard, Maestro, со счета мобильного телефона, с платежного терминала, в салоне МТС или Связной, через PayPal, WebMoney, Яндекс.Деньги, QIWI Кошелек, бонусными картами или другим удобным Вам способом.