Первое неприятное обращение пришло через несколько недель после запуска интеграции. Документ в принимающей системе появился, но логов не было. Повторять отправку наугад не стали, так как существовал риск получить дубль.
Сопровождение попыталось разобраться самостоятельно, но в журнале не хватало нужных сведений. Нельзя было уверенно понять, на каком шаге остановился обмен и допустимо ли повторить операцию. В итоге к задаче вернули разработчика, хотя он уже занимался следующей доработкой.
Возможность такого сбоя обсуждали ещё до релиза. Заказчик ждал функциональность к согласованной дате: под неё готовили пользователей и переход к новому порядку работы. Основной функционал выполнялся. Разработка предлагала не задерживать выпуск из-за расширенной диагностики и автоматического восстановления редкой частичной ошибки.
Сопровождение возражало. После запуска именно ему предстояло принимать обращения, определять состояние документов и при возникновении проблем с обменом первыми разбирать их. Без подробного журнала нестандартные ситуации неизбежно возвращались бы к автору кода.
На совещании озвучивалась цель заказчика - выпустить работающую интеграцию в короткие сроки. Разработка считала работающим решение, которое выполняет основной сценарий и выходит к обозначенной дате. Сопровождение добавляло ещё одно условие: после ошибки состояние обмена должно быть очень развернуто и понятно без отдельного расследования.
Общая цель задаёт направление, но не сообщает, чем поступиться в конкретном релизе.
Почему общего результата оказалось недостаточно
Подобный спор легко списать на недостаток командности. Разработчики якобы хотят быстрее закрыть задачу, сопровождение перестраховывается, а руководители не могут договориться.
Разработка видит последствия своего предложения. Дата подтверждена заказчику, подготовка пользователей уже началась, основной сценарий работает. Если перед выпуском добавлять каждое полезное техническое улучшение, хотя они и реально нужные, к обозначенному сроку могут не успеть. Иногда выпуск рабочей основы с временным ручным порядком для редкой ошибки является адекватным решением с учетом обстоятельств.
Сопровождение тоже не требует идеального решения на все случаи жизни. Оно заранее представляет, с чем им предстоит столкнуться после релиза. Если без разработчика это сделать нельзя, завершённая задача будет продолжать расходовать время проектной группы.
Одна сторона защищает обязательство по сроку. Другая смотрит на то, что произойдёт после запуска. Под выражением "рабочая интеграция" они понимают немного разные наборы обязательных свойств.
Всем участникам проекта не нужно одинаково разбираться во всех деталях. Важнее, чтобы значимые зависимости не оставались внутри одной роли.
Лесли ДеЧерч и Джессика Месмер-Магнус объединили результаты 65 исследований командного познания. Они показали, что для результатов команды важнее не одинаковое знание всех участников, а связанная система экспертизы: каждый понимает свою область и знает, чьи сведения нужны для общего решения.
Для проектной работы отсюда следует вывод. Всем необязательно одинаково разбираться во всех деталях, но значимые зависимости не должны оставаться внутри одной роли. Разработчику не нужна полная статистика будущих обращений. Специалисту сопровождения не требуется погружаться во всю реализацию обмена.
Дебора Догерти изучила 18 проектов создания новых продуктов в пяти крупных компаниях и опросила 80 сотрудников разных функций. Успешными считались продукты, достигшие или превысившие ожидаемую прибыль, неудачными - выпущенные, но впоследствии закрытые. Разные профессиональные взгляды встречались в обеих группах. Отличался способ работы с ними. В неудачных проектах привычные процедуры сохраняли разделение между подразделениями: каждая функция оценивала продукт по собственным критериям, а ограничения других сторон почти не меняли решения. В успешных проектах специалисты отходили от обычного порядка, совместно уточняли и связывали технические возможности с условиями его реального использования. Для спора разработки и сопровождения важен именно этот вывод.
Последствия принятого решения
Вариант разработки позволяет сократить объём текущего релиза и успеть к обозначенному сроку. Последствия возникают позже. Частичный сбой сложнее диагностировать, восстановление занимает больше времени, сопровождение обращается к разработчику, а тот оставляет следующую задачу.
Цепочка выглядит так: диагностику сокращают → интеграция выходит вовремя → нестандартный сбой нельзя быстро разобрать → подключается разработчик → следующая работа задерживается.
Возможно, за год произойдёт один подобный случай, а перенос запуска затронул бы десятки пользователей и поэтому такая экономия может быть оправданной. Само решение выпустить функциональность с ограниченной диагностикой с учетом всех переменных ещё не значит, что это плохо.
Не хорошо, когда будущая работа сопровождения вообще не попадает в обсуждение. После релиза её воспринимают как неожиданность, хотя цена была заложена в решение с самого начала.
Требования сопровождения тоже не бесплатны. Расширенный журнал и автоматическое восстановление помогают при будущей ошибке, но увеличивают текущий объём. Заказчик позже получает функциональность, приходится менять подготовку пользователей, сдвигается следующий этап проекта.
Поэтому вопрос «кто прав?» вряд ли приведет к решению. Полезнее выяснить, какая будет цена каждого варианта и кто будет оплачивать её своим временем.
Решение кажется дешёвым тому, кто не получит его последствия.
Точную стоимость заранее обычно не посчитать. Для сравнения вариантов можно использовать более грубые признаки: сколько потребуется ручных действий, понадобится ли автор кода, можно ли безопасно повторить операцию, какое количество пользователей затронет ошибка и какое обязательство окажется под угрозой.
Будущую нагрузку сопровождения легко недооценить, пока она описана только словами "могут возникнуть проблемы". Задача руководителя - добиться сопоставимой конкретности с обеих сторон.
Почему ещё одно совещание может не помочь
Джессика Месмер-Магнус и Лесли ДеЧерч объединили результаты 72 исследований обмена информацией в командах. Наиболее заметной оказалась связь с качеством принятых решений. Причём значение имела не общая разговорчивость команды. Обмен сведениями, которыми обладал только один участник, был связан с результативностью сильнее, чем просто открытое обсуждение уже известных вопросов.
Для спора разработки и сопровождения третье совещание не поможет, если стороны ещё раз скажут, что срок важен, а диагностика нужна. Требуется обмен более конкретной информацией: без каких данных сопровождение не сможет восстановить обмен и какой объём работ действительно сдвинет запуск.
Полезной информация становится тогда, когда её связывают с последствиями конкретного варианта.
Вместо "нам нужна расширенная диагностика":
Без идентификатора документа, этапа обработки и результата внешнего вызова мы не определим, завершилась ли операция. Для каждого такого случая потребуется разработчик.
Вместо "релиз переносить нельзя":
Дополнительный объём сдвигает подготовленный запуск на такое то время. Пользователей придётся повторно информировать, а следующий этап начнётся позже.
После такого уточнения специалисты могут остаться при своём мнении, руководитель хотя бы увидит, между какими последствиями ему предстоит выбирать.
Разработка и сопровождение не всегда способны принять этот выбор самостоятельно. Они не вправе менять дату, сокращать согласованный объём, выделять дополнительный ресурс или принимать риск от имени заказчика.
Фраза "договоритесь между собой" в такой ситуации передаёт сотрудникам ответственность без необходимых полномочий.
Бывает и хуже: совещание заканчивается формулировкой, которую каждая сторона понимает по-своему.
Диагностику добавить по возможности, срок запуска постараться сохранить.
Для разработки здесь главным остаётся срок. Для сопровождения - формально согласованная диагностика. Протокол встречи появился, решение - нет.
Я бы считал выбор сделанным только тогда, когда из записи понятно, что именно команда обязуется выполнить, от чего сознательно отказывается и кто может изменить приоритет.
Пять вопросов к спорному решению
Такой разбор нужен в ситуациях, где два варианта нельзя реализовать одновременно, а последствия переходят от одной роли к другой.
- Какой профессиональный результат защищает каждая сторона?
Разработка защищает дату и границы релиза. Сопровождение - возможность определить состояние обмена и восстановить работу. - Какую выгоду даёт каждый вариант и когда она проявится?
Сокращение диагностики помогает сохранить дату. Её добавление уменьшает время разбора после ошибки. - Какую цену переносит каждый вариант?
Это может быть задержка, ручная работа, зависимость от разработчика, будущие обращения или ограничение функциональности. - Кто и когда получит эту цену?
Сопровождение - при первом сложном сбое. Разработка - когда её отвлекут от следующей задачи. Заказчик - если изменится дата. - Кто вправе решить, какую цену проект принимает?
Нужен человек, способный изменить срок, уменьшить объём, выделить ресурс или согласовать риск от имени заказчика.
Спор перестаёт выглядеть как столкновение правильной и неправильной позиции. Перед руководителем появляются два варианта с понятными последствиями.
Как выглядит решение, которое можно исполнить
В случае с интеграцией необязательно выбирать между полной диагностикой и её отсутствием. Можно сохранить дату, но до запуска добавить минимальный набор данных для критичного сценария.
Для частичной ошибки описывают временный порядок восстановления и заранее определяют разработчика, которого подключают при необходимости. Полную автоматизацию выносят в отдельную задачу. Главное - не оставлять её в неопределённом "доделаем потом".
Принятое решение. Дату запуска сохраняем. До релиза добавляем идентификатор документа, этап обработки и результат внешнего вызова. Риск ручного восстановления редких частичных ошибок принимаем. При таком сбое сопровождение собирает данные по установленному составу и подключает назначенного разработчика. К решению возвращаемся после первого частичного сбоя либо в контрольной точке после запуска.
При таком варианте ясно, ради чего сохранён срок, что команда не успевает сделать и кто будет работать с последствиями.
Если после запуска частичные ошибки повторяются, а разработчик регулярно отвлекается от текущих задач, автоматизация восстановления возвращается в приоритет. Если сбой оказался единичным и быстро устранимым, решение сохранить дату могло быть удачным.
Дэвид Хупс и Стивен Пострел два года изучали компанию, разрабатывавшую научное программное обеспечение. Они искали не обычные программные ошибки, а случаи, когда проект получил неудовлетворительный результат из-за ограничения, известного одной группе, но не учтённого другими. Такие случаи обнаружились в 20 из 79 проектов, где работали несколько групп. Связанные с этими случаями переделки, исправления и незапланированное сопровождение потребовали не менее 91 человеко-месяца работы - примерно столько времени восемь специалистов потратили бы за год. Это составило около 17% всех трудозатрат на проекты, в которых участвовали несколько групп.
Рупак Рауниар, Уильям Долл, Грег Равски и Пол Хонг изучили 191 проект автомобильной отрасли США. Под проблемами разработки они понимали случаи, когда результат не соответствовал требованиям заказчика, поставщика, производства или сборки. Чем лучше участники понимали общий процесс, зависимости между этапами и ключевые точки решений, тем меньше сообщали о таких несоответствиях. А проекты, где они возникали чаще, хуже оценивались по сроку, стоимости и удовлетворённости заказчика.
Для нашего примера важен сам механизм. Если разработка видит только готовность основного сценария, а требования сопровождения не влияют на решение до релиза, проблема обнаруживается уже на следующем этапе. Тогда проект заплатит за конкретное несоответствие результата требованиям роли, которая должна с ним работать дальше.
Руководителю также не требуется знать устройство каждого механизма интеграции. Специалисты объясняют последствия своих вариантов. Дальше решение переходит к человеку, который может ответить: разрешено ли менять дату, какой риск проект принимает и когда к этому вопросу нужно вернуться. Здесь уже действия руководителя влияют на общую эффективность.
Пять вопросов не нужны для каждого поля формы или текста сообщения. Такой разбор стоит проводить, когда решение затрагивает срок, объём или риск другой роли, а исправление после запуска будет заметно дороже.
Если руководитель утвердил минимальную диагностику, а специалист продолжает незаметно расширять объём, дело уже не в разных критериях. Если релиз разрешён только при наличии журнала критичных операций, а разработка выпускает решение без него, это тоже не профессиональный спор.
В исходной ситуации срок можно сохранить. Но только после того, как названы минимальный состав диагностики, временный порядок восстановления и момент, когда решение пересмотрят.
Именно этим управленческое решение отличается от призыва работать на общий результат. Команда понимает, что получает сейчас, какое последствие готова принять позже и кто будет с ним разбираться.