Мы в Bimeister любим процессы.

А за что ж их не любить, в самом деле? Хорошо отлаженный процесс создает эффект «оно само»: каждый его участник в любой момент времени точно знает, что и в каком порядке ему нужно делать. За его ходом достаточно приглядывать и иногда нежно подталкивать, если кто-то забуксовал.

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

Привет тебе, читатель Хабра! Я Маша Демченко, системный аналитик компании Bimeister, и в своей первой статье я хочу рассказать о нашем опыте выявления и преодоления сложностей в процессе согласования требований к ПО.

Почему потребовались изменения процесса

Чтобы успешно преодолевать сложности, сначала их надо себе создать.

В нашем случае пересмотру процесса способствовал бурный рост компании. Меньше чем за два года компания Bimeister по численности выросла почти в 10 раз. Появились большие коммерческие контракты, а всякий приличный контракт имеет срок, к которому надо успевать. Причем в наращивании скорости важно не потерять качество.

Таким образом, то, что раньше хорошо работало, работать резко перестало.

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

«Узкое горлышко»

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

В широком смысле это некто, сильно перегруженный работой, который не успевает достаточно быстро обрабатывать поток входящих запросов. Явление может возникнуть внезапно, когда входящий поток резко вырос за короткий срок (наш случай).

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

Если делегирование по каким-то причинам невозможно (прямо сейчас или вообще), то есть ещё один вариант — договориться о пропуске проблемного этапа на временной или постоянной основе.

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

Затея рискованная и не всегда оправдывает себя, потому что универсального совета, какой этап можно пропустить без потери качества, а какой нет — не существует, нужно рассматривать каждый случай в отдельности. Но такая опция есть.

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

Много согласующих

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

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

Если количество участников процесса со временем разрослось, «выкинуть лишних» и минимизировать время обсуждения можно следующими способами:

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

• организовывать «очные» собрания (в условиях всеобщей удаленной работы едва ли получится физически собрать всех причастных в одной комнате. Но можно собрать общий звонок). Часто быстрее оффлайн решить интересующие вопросы, чем бесконечно переписываться;

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

Пересогласования при изменении требований

Леди не говорят об этом, и всё-таки оно существует. Требования меняются. Или «всплывают» не выявленные ранее — что поделать, бывает.

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

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

По сути это следование принципу «принимай решение в последний ответственный момент»: в условиях высокой неопределённости и скорости изменений вероятность, что описанное решение устареет ещё до окончания его согласования, высока. Принцип давно известный, но лично мне было сложно начать его применять — внутренний недобитый перфекционист все время пытается бежать впереди паровоза и сделать «быстро, четко, дорого». Помните, терпение — добродетель, которая вознаграждается отсутствием необходимости все переделывать в последний момент.

Тут же хочется сказать о выявлении и следовании приоритетам. Важно их расставить в самом начале и брать в работу задачи, которые требуется реализовать в ближайшее время. Потому что детально проработанные, но долго лежащие в бэклоге задачи имеют свойство «протухать» (как в техническом плане, так и с точки зрения бизнес-потребности), и при запуске в разработку подлежат обязательному пересмотру на предмет корректировок. Это двойная работа, которой можно избежать. Также опыт показывает, что если задача потеряла свой высокий приоритет, то лучше остановить работу по ней как можно раньше. Жаль затраченных усилий, но так «дешевле»: неизвестно, когда понадобится вернуться к проработке требований и насколько к тому моменту изменятся окружающие условия.

Все только начинается

На самом деле, рано подводить итоги и делать окончательные выводы. Наш рост ещё не завершен, впереди много новых контрактов и клиентов.

Глобально мы выбрали путь передачи компетенции и ответственности функциональным командам, специализированно занимающимся тем или иным «куском» системы, с минимальным вмешательством в работу профессионалов (пока сами не попросят пощады).

А к чему нас это приведет, я обязательно потом расскажу.

Увидимся в следующей серии!