Коммуникация — это ключ: кейс спасения проекта

Когда-то очень давно один американец-клиент сказал мне: Communication is key. И я снова и снова убеждаюсь, что зачастую “просто правильно выстроенная” коммуникация выруливает сложные технические ситуации. Рапортую свежий кейс.

Ко мне обратился давний клиент с просьбой добавить в их мобильное приложение (далее “МП”) поддержку кастомного Bluetooth-девайса. Сей девайс является новым элементом в их программно-разрабатываемом комплексе, прослойкой между МП и датчиками, которые ранее подключались к смартфону с МП через USB. Этот девайс разрабатывается сторонней компанией. Таким образом, в этом спектакле участвуют 3 стороны: заказчик; мы, Zennex — как разработчик мобильного приложения; и третья компания — разработчик железа и онборд-софта для него.

Для полноты картины: четкого ТЗ не было и новый девайс изначально представлял из себя для нас черный ящик. На первом этапе мой Android-разработчик интегрировал в МП поддержку BLE (Bluetooth Low Emission) и начал пробовать получать данные. На этом этапе мы столкнулись с проблемами сбора получаемых данных из нескольких пакетов в один кусок и со скоростью их передачи. Я намеренно описываю технические детали очень общо, потому что:

• на другом проекте технические сложности могут быть другими, а организационные меры для их успешного преодоления будут аналогичными

• я, как управленец, не могу знать всех технических деталей и ищу решение, опираясь на общее понимание и знания других специалистов

Собственно на этом прелюдия окончена и я опишу, что было сделано в данной ситуации 🙂

Шаг 1

Организовал общий созвон, где:

• взял на себя активную роль, не будучи формально генподрядчиком

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

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

• попросил своего разработчика и разработчика железа нарисовать алгоритм работы всех компонент ПАК (программно-аппаратного комплекса)

• на выходе из созвона написал резюме с попунктным указанием договоренностей и плана действий (кто, что и когда делает)

Результат шага 1: началась командная работа с участием всех трех сторон.

Шаг 2

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

• накидал на бумажке примерно так, как я хочу это видеть, и нашел в интернете название этой нотации, скинул ребятам несколько примеров

• еще раз проговорили, в каком виде я хочу видеть алгоритм — с указанием взаимодействия трех компонент системы: МП, BLE-девайса, датчиков

• задал вопрос, понятно ли то, что я хочу, разработчикам (моему и третьей стороны) и смогут ли они сделать алгоритм в таком виде — получил от них подтверждение, что да

• на выходе снова написал резюме, включающее договоренности и план действий

• согласно плана разработчики созвонились тет-а-тет и спонтанно выработали иной, облегченный вариант алгоритма, который вроде бы решал текущую задачу

• затем они реализовали свой облегченный алгоритм в виде кода

Результат шага 2: здесь появились первые плоды командной работы в виде нарисованного алгоритма.

Шаг 3

Для анализа результатов софта, написанного на предыдущем шаге, организовал третий созвон:

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

• выяснилось, что заказчик так и не предоставил разработчику железа некую информацию, которая была запрошена очень давно, в самом начале работы над проектом — вот это поворот 🤯

• подробно еще раз разобрали алгоритм, ограничения, возможности всех компонент — по сути еще раз обсудили алгоритм в деталях, выяснили, что нужно кодить именно так, как было нарисовано на шаге 2

• снова резюме с планом действий

• на данный момент ожидаем реализации софта согласно алгоритму, после чего, надеюсь, выйдем на финишную прямую

Результат шага 3: наконец-то появилось ощущение, что все на одной странице и мы наконец-то дожмем проект, по поводу которого заказчик уже начал высказывать пессимистичные ожидания.

Чем закончится история — расскажу. Промежуточные выводы👇

📌 Ключевые действия, которые продвинули проект вперед:

✔ Активная позиция: сам взял и всех сорганизовал (кстати, за это клиент мне уже сказал “спасибо”)

✔ Организация командной работы через активное и конструктивное вовлечение всех сторон в мозгоштурм в реальном времени

✔ Использование стандартных процедур: планы действий по выходу из созвонов (кто что и когда делает), получение коммитментов от вовлеченных сторон

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

✔ Азарт: кайф от разруливания ситуации 🔥

А у вас бывало, что коммуникация буквально спасала проект?

• Кто в вашей практике берет на себя инициативу в неразруленных ситуациях?

• Сколько итераций вы считаете «нормой» для сложной команды?

• Сталкивались с ситуацией, когда заказчик сам был "узким горлышком"? Как решали?