Построение процессов с нуля: от хаоса к порядку

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

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

Исходные данные нашего отдела: небольшая (5–10 человек), частично распределенная (некоторые сотрудники работают удаленно, некоторые в офисе) продуктовая команда с заказчиками внутри самой компании. Веб-проекты. Нет специалистов по системному администрированию внутри отдела, но есть занимающиеся этим отделы в компании.

Коммуникации в команде

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

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

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

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

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

Для начала мы завели чат в Telegram. Но потом, в связи с ростом команды, мы поняли, что в одном чате нам уже тесно, и перешли в Slack. Там мы разбили общий поток на тематические каналы и установили четкие правила — по каким поводам в какой канал писать. Это помогло избежать смешения полезной информации и флуда.

Плюс, переход на Slack дал нам некоторые приятные возможности для автоматизации и интеграции с другими сервисами, типа системы управления репозиториями или багтрекера.

• Аудио- и видеозвонки — Skype for Business.
• Задачи ведем в Jira.
• Базу знаний храним в Confluence.

Планирование, исполнение и контроль задач

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

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

Для борьбы с этим мы разработали и внедрили свою культуру ведения задач:

• Работа не должна выполняться, пока не заведена соответствующая задача. Это помогает держать всегда актуальной историю развития проекта и работы команды.
• При работе с задачей необходимо своевременно менять ей статусы. В нашем случае хватает четырех статусов: «To do» — стартовое состояние задачи, «In progress» — задача, которая находится в процессе выполнения, «On hold» — задача, которую начали выполнять, но работы приостановлены (ждем какой-то дополнительной информации), «Done» — задача готова. Готовность задачи должен так или иначе подтвердить заказчик или менеджер внутри команды.
• Со временем количество задач и проектов сильно увеличилось, так что общий список работ мы разбили на отдельные подпроекты, и задачу следует заводить согласно этому списку подпроектов.
• Задаче необходимо назначать приоритет. Это помогает понять, какие задачи в каком порядке требуется выполнять, чтобы причинить проекту максимальную пользу.
• Периодически проводится ревью задач и их приоритетов. Так как проекты живут и развиваются, а планы бизнеса иногда меняются, то со временем некоторые задачи становятся менее или более актуальными или вовсе требуют своего удаления.
• Некоторые ключевые обсуждения по задачам, которые производились устно или письменно в чате, требуют фиксации финального решения в самой задаче, чтобы при ее выполнении мы всегда видели самую актуальную информацию о ней и о ее истории. Нередко бывает, что изначальная постановка задачи после ряда обсуждений трансформируется в нечто совсем иное, и нам нужно следить за этим.
• Если внутри команды задача передается от одной группы специалистов к другой, то передающая группа обязана зафиксировать в ней все необходимые артефакты знаний, которые надо передать следующей группе. Например, группа дизайна перед передачей задачи в группу разработки должна прикрепить макеты и всю необходимую для разработки документацию. Это позволяет избежать лишних вопросов, отвлечений и переключений контекста.
• Прикрепление коммитов к задачам. С помощью некоторых правил именования коммитов у нас автоматически привязываются к задачам ссылки на коммиты в GitLab. Это сильно помогает в разработке понимать, кто, что, как и когда делал по данной задаче. И в обратную сторону, по правильно именованным коммитам всегда можно найти задачу, содержащую причину внесенных изменений.

Коммуникации с заказчиком

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

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

В таком подходе кроется сразу несколько проблем:

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

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

Далее мы столкнулись с еще одной важной проблемой: заказчику сложно сформулировать задачу. Заказчик не всегда достаточно компетентен (а вернее, практически всегда недостаточно компетентен) в формулировании ТЗ для технической команды. И это нормально. Нельзя игнорировать и человеческий фактор: заказчику может быть банально неловко и неудобно приходить с просьбой к команде, когда он сам еще не смог до конца ее сформулировать. Один из критериев зрелой профессиональной команды — это умение помочь заказчику в выявлении его проблем, требований и решений.

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

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

Список вопросов для заказчика:

• Какова цель проекта? Какую проблему это решает? Какое business value оно несет?
• Это единственное возможное решение данной проблемы? Если нет, то какие еще есть варианты?
• Есть ли какие-то общие требования, проходящие сквозь весь проект? Например, если это интернет-магазин, то он должен полностью соответствовать законодательству, регулирующему онлайн-торговлю.
• Есть ли функциональные требования? Что должен делать раздел (страница, проект)? Например, раздел должен предоставлять информацию о продуктах компании и через форму на странице собирать желающих задать по этому продукту вопросы или приобрести его.
• Есть ли нефункциональные требования? Как хорошо он должен это делать? Например, время открытия страницы должно быть не больше 5 секунд.
• Дополнительные требования. Свободный формат, в котором можно излить душу.

Очередная проблема, с которой нам довелось столкнуться: задачи, поступающие одновременно со всех сторон. Когда много заказчиков по разным проектам, то каждый хочет выставить своей задаче наивысший приоритет. В общем идеальном случае, наверное, такую проблему нельзя решить на 100%. Как живем с этим мы? С внедрением дисциплины в постановке и ведении задач, а также некоторых элементов Agile-методологий, наш пул задач стал более упорядоченным, прозрачным для внешнего наблюдателя, а главное — прогнозируемым. Мы наладили порядок и планы у себя внутри команды, и нам осталось только усилить обратную связь с заказчиками. В обсуждении приоритетов, сроков и планов мы научились строить аргументированный диалог, а не слепо кидаться на задачи и постоянно тушить разгорающиеся пожары (которые на самом деле не всегда актуальны и не всегда пожары).

Также в рамках этого пункта мы постарались искоренить классический антипаттерн «чайка-менеджмент», когда заказчик или менеджер прилетел, «наложил» задач — и улетел в полной уверенности, что раз он задачу поставил, то непременно на выходе получится отличный результат. Как показала практика, результат при таком подходе получался не самый впечатляющий. Как с этим бороться? Тут тоже нет какого-то универсального совета, какой-то волшебной фразы, изменяющей поведение людей. Для этого необходимо разговаривать, просвещать, объяснять, показывать, можно сказать воспитывать. Только просветительская работа и либо очень наглядные, либо очень измеримые (а желательно и то, и другое) позитивные и негативные примеры помогут в достаточной мере побороть «чайка-менеджмент».

Dev vs Ops

И последняя важная наша проблема — проблема в коммуникациях между отделами Dev и Ops.
Мы столкнулись с классической ситуацией, когда разработчики не очень хорошо понимают, как работает сервер, а сторонняя команда админов не очень представляет, как работает приложение. Каждое затруднение на стыке этих двух сфер давалось нам с болью и большими временными затратами. Трудно было даже диагностировать, на какой стороне проблема:

• Это вы там напрограммировали!
• Нет, это у вас там что-то с сервером!

В данном случае нам помогло то, что в команде появился разработчик, который неплохо разбирался в администрировании. Он смог с каждой группой поговорить на ее языке и каждую проблему диагностировать с обеих сторон. Нестыковки пошли на спад, но мы оставались завязаны на этом человеке. Чтобы отвязать все эти проблемы от себя, он начал помогать админам понять, как работает приложение, а программистам — что происходит на сервере. Добавим к объяснению голосом написание документации и получим не только прокачку знаний всей команды, но и более слаженную работу Dev- и Ops-отделов. Да, в крупных отделах кровавого энтерпрайза существуют специальные команды и квалифицированные люди, которые все настроят так, чтобы разработчики могли даже и не знать, как и где работает на сервере их творчество. Однако в небольших командах было бы неплохо развивать у людей этот уровень компетенций, а также иметь хотя бы одного сотрудника, который уже достаточно хорошо развит в этом плане.

Разработка

Параллельно со всем эти мы занялись развитием культуры разработки.
Не буду заострять внимание на технической части, да и сейчас это уже стандарт де-факто и практически всем хватает понимания того, как необходимо наличие системы контроля версий, CI/CD и прочих инструментов разработки, сборки и деплоя. Остановлюсь лишь на soft моментах разработки.

• Codestyle. Довольно важно выработать и явно утвердить правила оформления кода. Во-первых, эстетически приятнее видеть в проекте единый стройный вид, а не зоопарк разных стилей и стандартов. Во-вторых, это повышает читаемость кода, а как мы знаем, большинство времени программист не пишет свой код, а читает чужой.
• Именование коммитов. Мы ввели определенные правила именования коммитов, чтобы по имени коммита было понятно, какие изменения были внесены, кем и в рамках какой задачи.
• Код-ревью. Специфика наших проектов и команды такова, что некоего обязательного код-ревью, без которого не влить свой код в продакшен, у нас нет. Однако мы взяли за правило, что хотя бы один человек смотрит тот код, который пушит коллега. Это помогает как замечать какие-то недочеты, привносить альтернативные идеи, так и просто быть в курсе всех частей системы. Код-ревью стало особенно актуальным с ростом количества и сложности проектов, из-за чего каждый разработчик уже не успевает поработать на всех проектах достаточно, чтобы понять все их детали.
• Согласование архитектуры внутри команды на ранних этапах. Часто бывает, что в стремлении создать фичу побыстрее, фронтенд начинает делать что-то свое, бэкенд быстро начинает свое, а потом оказывается, что это интегрируется с большим трудом или не интегрируется вообще. В разработке крупных фич мы заранее совместно обсуждаем архитектуру, форматы обмена данными и т. п. В результате интеграция перестала быть долгой и болезненной.
• CV Driven Development. Это проблема, при которой разработчики тащат в проект новые (свежие, модные, высокооплачиваемые) технологии не ради проекта, а ради галочки в резюме. Мы открыты для новых технологий и стараемся технологически развивать наши проекты, однако тут важно соблюсти баланс, при котором будет и технологический прогресс, и успешно выполненные в разумные сроки проекты. В этой скользкой теме важны две вещи: чтобы заказчик не давил сроками так, что разработчикам не продохнуть, и чтобы команду разработки (ну или, по крайней мере, компетентного тимлида или техлида) заботило не только развитие своего профиля в LinkedIn, но и благополучие проекта в целом.

Рефакторинг, технический долг и принцип непрерывного улучшения

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

Так как проект был большой, уровень энтропии был в нем также высок. Мы поняли, что за один присест это все не одолеть физически, да и морально опускаются руки от перспективы такой колоссальной работы. Мы решили применить японский принцип непрерывного улучшения «кайдзен». Раздробили технический долг на много маленьких частей и понемногу, но регулярно закрывали эти маленькие части, непрерывно модифицируя и улучшая как проекты, так и работу самой команды. Морально это никак не приносило неудобств, но при этом не оказывало значительного влияния на разработку новой функциональности и покрытие требований бизнеса. Спустя год-полтора мы обнаружили, что старый технический долг был полностью погашен, и это открыло нам возможности для разработки функциональности принципиально нового уровня сложности и важности.

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

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

Внедрение Agile-методологий

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

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

Далее мы решили вести разработку по спринтам. Каждую пятницу в конце дня мы проводим ретроспективу спринта, смотрим, какие задачи были в планах, что готово, что не готово, и если что-то не готово, то почему так произошло. Думаем о том, какие у нас были проблемы и что мы могли бы сделать, чтобы избежать подобных трудностей в будущем. Затем планируем спринт на следующую неделю исходя из загруженности разных направлений внутри команды и бизнес-приоритетов. В результате в начале недели все разработчики знают, чем им заниматься и в какой последовательности, а бизнес знает, какие его потребности будут покрыты в ближайшее время, и может уже формировать свои «хотелки» на следующие спринты. Стоит сказать, что мы не избавлены от внезапных задач, которые могут нарушить наши планы на спринт. В этом случае нужно действовать исходя из конкретной специфики работы: как часто такие задачи возникают? Насколько много? Можно ли это спрогнозировать? В нашем конкретном случае в разработке мы опытным путем подсчитали, сколько времени в среднем приходится на незапланированные задачи и стараемся закладывать этот запас в спринт. Отдельно стоит отметить, что после начала работы по спринтам нам удалось конкретно выяснить, как много работы нам поставляется на вход внепланово, проанализировать и сократить это количество, тщательно обсуждая приоритеты с заказчиком и наглядно показывая, как сиюминутное желание получить не самую необходимую фичу прямо сейчас влияет на общую продуктивность всей команды.

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

Bus factor

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

В искоренении этой проблемы нам помогло накопление артефактов знаний, которые переехали из голов конкретных людей в физический письменный мир. А именно:

• Все работы проводятся только если есть задача в багтрекере. Это позволяет составить полную историю изменений в проекте.
• В случае если где-то в чате или на митинге обсудили изменения по задаче — обязательно в самой задаче отражаем итог этого обсуждения.
• Коммиты именуются с понятным указанием произведенных изменений и ссылкой на задачу. При этом в багтрекере интеграция настроена так, что в самой задаче появляется ссылка на коммит в Gitlab. Это позволяет сохранить историю не только самой цели задачи и ее обсуждений, но и сохранить информацию о конкретных изменениях и их исполнителях.
• После разработки очередной фичи программист пишет в Confluence документацию, описывающую ее общую бизнес-логику и особенности реализации, если это необходимо.
• При возникновении каких-то крупных проблемных инцидентов ведется postmortem в формате «что и когда случилось — что делали — что нужно было на самом деле делать — как избежать такой проблемы в будущем».

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

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

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

Заключение

В заключение хотелось бы отметить, что ни одна из вышеуказанных проблем не решалась сразу и безупречно. Организационные изменения — это всегда долгий и методичный труд. Нельзя просто сказать «теперь делаем так» и надеяться, что теперь все станет иначе. Любые решения, которые вы примете, любые мероприятия, которые вы организуете, требуют контроля, обучения и просвещения людей, времени на адаптацию как команды к новым методикам, так и самих методик к конкретной ситуации. Также замечу, что навязывание людям какой-то методологии является очень трудоемким и малоэффективным процессом. Люди будут упираться, заб(ы/и)вать, возможно даже саботировать.

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

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

Автор: Евгений Антонов, руководитель группы разработки Positive Technologies