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

Don`t panic

Первым шагом предлагаю выполнить совет с обложки самоучителя «Автостопом по галактике». Худшее что можно сделать — начать паниковать и принимать кучу решений в попытке наверстать упущенное. Поспешные действия точно не помогут, зато легко могут все усугубить.

Команда

Я предпочитаю общаться с командой в формате один на один с каждым человеком. Важно, с одной стороны, не переходить на обсуждение конкретных текущих задач и, конечно, не переходить на обвинения. С другой стороны, не путать эту встречу с регулярными 1on1-ами, где центральной темой является личный рост и развитие.

Нужно получить список всех проектных проблем, которые видит каждый член команды. Если есть предложения по решениям, их нужно выслушать и задокументировать. Очень часто, члены вашей команды уже знают что нужно делать и сами подскажут все необходимые шаги. Столь же часто их взгляд может оказаться однобоким и решение улучшит что-то в одном месте, но сделает хуже в другом. Поэтому наша цель на этом этапе — собрать максимум информации. А принимать решение позже.

Проектные решения

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

Под такими решениями я понимаю, например, текущую архитектуру сервиса. Опору на внешние источники или зависимости. Договоренности о взаимодействии частей системы друг с другом, API, SOAP и т.д.

Конечно, я не предлагаю все переписать на новом молодежном фраемворке. Но часто описание проектных решений в едином документе помогает обнаружить проблему. Еще чаще проблемой является сам факт того, что решение нигде не описано.

Процессы

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

Задача

Когда составлен реестр проблем и неоптимальных решений. Когда выписаны все сложности в команде. И понятно, где застревают процессы. В этот момент стоит обратиться к изначальной задаче, которую решает проект. Понимание задачи может помочь посмотреть на свой список свежим взглядом. А еще напомнит нам ограничения, которые есть на самом фундаментальном уровне.

Риски

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

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

Итоги

“И это все?” спросит внимательный читатель. Конечно, нет. Все проекты разные. Но эти шесть шагов, на мой взгляд, самый минимальный набор действий, которые стоит совершить до того, как можно садиться за анализ и делать какие-то выводы. Если пропустить какой-то из них, то это почти гарантированный способ не починить процессы, а сломать все еще больше.

Если проект небольшой, например, не более 10 человек готовили проект около полугода. То такой анализ можно сделать в одиночку за одну-две недели. С минимальным отрывом текущей команды о работы. Ну а дальше уже принимать управленческие решения.