К встрече по новому проекту отдел разработки пришёл с почти готовой схемой. Архитектуру уже обсудили внутри, задачи предварительно оценили, основные технические риски разобрали. От соседних подразделений ждали уточнений и подтверждения сроков.
Аналитик обратил внимание на сценарий, которого не было в схеме. Специалист, отвечающий за сопровождение, спросил, как после запуска будут разбираться ошибки, если в системе не предусмотрена отдельная диагностика. Руководитель проекта напомнил, что заказчик требует заявленный функционал к согласованной дате и перенос части работ придётся отдельно объяснять.
На каждый вопрос был ответ. Аналитик не знает прежних договорённостей. Сопровождение снова пытается предусмотреть слишком редкие случаи. Руководитель проекта смотрит на срок и не видит техническую цену своих обещаний заказчику.
Все ответы могли быть обоснованными. Отдел действительно несколько лет вытаскивал сложные проекты, исправлял последствия поспешных решений и отвечал за ограничения, которые другие участники замечали слишком поздно. Сотрудники привыкли доверять друг другу и быстро находили слабые места в чужих предложениях.
Как появляется сильное "мы"
В описанной ситуации доверие могло укрепиться после нескольких сложных запусков, когда сотрудники действительно рассчитывали прежде всего друг на друга.
После такого опыта вера в своих имеет под собой основу. Люди быстрее договариваются, меньше страхуются формальными письмами, просят о помощи и охотнее берут сложные части работы. Общая история создаёт короткий язык. "Сделаем как в прошлый раз" заменяет длинное объяснение, потому что участники помнят и выбранный вариант, и его последствия.
Дэниел Бил, Робин Коэн, Майкл Бёрк и Кристи Маклендон объединили 64 публикации и 71 независимую оценку связи сплочённости с результативностью групп. В среднем связь была положительной. Она была заметнее в группах, где действия участников сильнее зависели друг от друга, и менялась в зависимости от способа измерения результата.
В разработке со сложными зависимостями общий контекст экономит время. Систему трудно сопровождать, если каждую развилку приходится заново объяснять собственным коллегам. Накопленное взаимопонимание помогает отделу не рассыпаться и в напряжённые периоды.
Уверенность могла вырасти из реальных результатов, а настороженность к внешним предложениям - из случаев, когда они действительно не учитывали технические ограничения.
Есть два связанных наблюдения. Во-первых, высокая сплочённость не гарантирует открытости: один из типов групп описан как очень сплочённый, но закрытый для внешних. Во-вторых, сплочённость можно укреплять через ощущение элитарности - убеждение, что команда сильнее остальных. Отдельно руководителю предлагается следить за "герметичностью" группы, то есть за тем, не замыкается ли она только на внутренних связях.
Это не научная классификация. Но наблюдение полезное: представление "мы умеем то, чего не умеют другие" хорошо связывает людей. Одновременно оно делает внешнее несогласие более подозрительным.
Когда своим дают больше права на ошибку
Отдел мог справедливо считать себя сильным в технических вопросах. На встречах эта уверенность постепенно распространялась и на бизнес-сценарии, сопровождение и проектные сроки.
Разработчики лучше понимают архитектуру. Аналитики видят процессы, которые не проявляются в коде. Сопровождение знает, какие решения трудно поддерживать после запуска. Руководитель проекта отвечает за обязательства по сроку и объёму.
Полной картины нет ни у одной роли. Но прошлые успехи отдела подталкивают к выводу: раз его специалисты чаще остальных находили технические ошибки, их оценки надёжнее и в остальных вопросах.
Джозефина Хеннесси и Майкл Уэст изучили 112 сотрудников из 17 рабочих групп одной медицинской организации. Чем сильнее сотрудники отождествляли себя со своей рабочей группой, а не со всей организацией, тем заметнее было предпочтение своих. При этом идентификация со своей группой не предсказывала дискриминацию других групп при распределении ресурсов.
В повседневной работе предпочтение своих можно увидеть в процессе работы. Резкую фразу внутреннего эксперта коллеги переводят на привычный язык и продолжают обсуждение. Такая же фраза от человека из другого подразделения вызывает недовольство.
Свой специалист может принести предварительную оценку без расчёта. Его попросят уточнить отдельные цифры. Если расчёта нет у аналитика, под сомнение попадает не только оценка, но и сам поднятый им риск.
Границу между своими и чужими хорошо видно по тому, кто может высказать неполную мысль и всё равно быть услышанным.
Встречи и их эффективность
Внешних коллег можно звать на все рабочие встречи и почти не использовать их знания. Так происходит, когда основная развилка уже пройдена, а обсуждению оставляют детали реализации.
Людей приглашают на встречу не слишком поздно по календарю, а слишком поздно по логике принятия решения.
Карстен де Дреу и Майкл Уэст провели два исследования - на самоуправляемых и кросс-функциональных командах. Отличающееся мнение было связано с большим количеством инноваций только там, где участники действительно влияли на принятие решений. Для описанной ситуации вывод такой: человека можно выслушать, но его знание не принесёт пользы, если основные варианты уже выбраны и обсуждению оставили только детали.
Аналитик или специалист сопровождения не должны выбирать архитектуру. Но принесённое им ограничение должно иметь шанс изменить состав работ, порядок запуска или вариант реализации, если оно влияет на общий результат.
Почему следующие возражения приходят поздно
После нескольких похожих проектов соседние подразделения меняют поведение. Они реже приносят ранние сомнения, потому что на этом этапе у них ещё нет полного расчёта, подтверждённого ущерба или готового альтернативного варианта.
Аналитик ждёт, пока риск станет частью согласованного бизнес-сценария. Сопровождение формулирует возражение после тестового запуска, когда уже видны конкретные последствия.
Со стороны отдела разработки это выглядит, что замечания снова появились после оценки задач, когда любое изменение уже затрагивает дату. Почему люди не принесли их раньше, отдельно не обсуждают.
Дебора Анкона и Дэвид Колдуэлл исследовали внешнюю активность продуктовых команд. Они провели интервью с 38 руководителями, наблюдали за двумя командами, а затем проверили выводы на отдельной выборке из 45 групп разработки новых продуктов. Команды взаимодействовали с окружением по-разному: искали информацию, получали обратную связь, координировали работу или добивались поддержки руководства. Исследование показывает: команда может много общаться с другими подразделениями и всё равно оставаться закрытой, если внешние контакты нужны ей только для продвижения и исполнения собственного решения.
Исследование проводилось в высокотехнологичных компаниях начала 1990-х и не описывало напрямую современные отделы разработки 1С. Для нашей ситуации важно не количество встреч само по себе, а то, допускают ли внешние контакты изменение решения или используются только для организации его исполнения.
Пять вопросов перед тем, как принять решение
Оценивать открытость всего отдела я бы не стал. Такой разговор может перейти в конфликты, особенности характеров и корпоративную культуру. Проще взять одно решение, которое затрагивает несколько подразделений.
- Какой существенный выбор ещё не сделан? Если к общей встрече закрыты архитектура, состав работ и порядок запуска, внешние участники смогут влиять только на детали.
- Чьей информации не хватает отделу? Это может быть пользовательский сценарий, обязательство перед заказчиком, порядок приёмки или будущая работа сопровождения.
- Как разбирают неточный внешний аргумент? Из него извлекают полезную часть или используют неточность как основание отложить весь вопрос?
- Какие факты заставят вернуться к выбранной схеме? Если любое новое ограничение объясняется ошибкой соседей, решение фактически уже нельзя пересмотреть.
- Как человек узнает, что произошло с его замечанием? Достаточно сообщить, что изменили, что решили сохранить и почему. После нескольких встреч без ответа люди перестают приносить ранние сомнения.
Так можно проверить, не потерялись ли ограничения и обозначенные риски, которые видели только аналитик, сопровождение или руководитель проекта. Одинаковые полномочия всем для этого не нужны.
После первой встречи пришлось вернуться к схеме
Аналитик, сопровождение и руководитель проекта независимо указали на разные ограничения. Одно касалось обязательного бизнес-сценария, второе - будущей диагностики, третье - срока, зафиксированного перед заказчиком. Руководитель отдела решил проверить не каждое замечание по отдельности, а порядок, в котором принималось решение.
До окончательного утверждения схемы назначили ещё одну встречу. На этот раз участникам не показывали готовый вариант. Каждый должен был назвать одно ограничение, исправление которого после запуска обойдётся заметно дороже.
Аналитик описал редкий, но обязательный сценарий согласования. Сопровождение показало, что при текущей схеме не сможет определить причину части ошибок без участия разработчиков. Руководитель проекта зафиксировал дату, к которой заказчик ждёт основной функционал, и отдельно назвал работы, перенос которых потребует нового согласования.
Все предложения не приняли. Основная архитектура сохранилась. В первый выпуск добавили диагностический идентификатор, для редкого сценария описали контролируемый ручной порядок, а часть функций перенесли на второй этап.
Компромисс никого полностью не устроил. Руководителю проекта пришлось объяснять заказчику, почему часть функций не попадёт в первый релиз. Аналитику пришлось отдельно согласовать ручной порядок с владельцем процесса.
В результате ещё до начала основной разработки появились три вещи, которых не было после первой встречи: согласованный состав первого релиза, временный порядок для редкого сценария и диагностические данные для сопровождения. Заказчик заранее увидел, что переносится на второй этап. Разработка не брала в релиз весь желаемый объём.
Это не гарантировало беспроблемного запуска. Но три будущих конфликта начали приходить к общему компромиссу и к наиболее оптимальному решению.
Когда широкое обсуждение не требуется
Не каждое решение нужно выносить на кросс-функциональную встречу. Если выбор локален, легко обратим и почти не меняет работу соседних ролей, широкий состав участников только увеличит время согласования.
Внешний специалист также может ошибаться. Он способен не знать технического ограничения, защищать показатель своего подразделения или пытаться добавить объём без пересмотра срока. Открытость отдела не определяется количеством принятых чужих предложений.
Проверка может быть полезна там, где есть потенциальные проблемы. В такой ситуации показателен вопрос: когда в последний раз мнение человека не из отдела заметно изменило решение до его утверждения?
На встрече из начала статьи разработчики могли быть правы по каждому отдельному возражению. Аналитика, сопровождение и руководителя проекта действительно пригласили. Но основная схема уже прошла внутреннее обсуждение, а возвращение к ней встречалось сопротивлением.
Доверие к своим здесь не нужно уменьшать. Важно, остаются ли другие подразделения источниками информации или подключаются только для согласования уже выбранного варианта.