В этой статье я расскажу о построении рабочих процессов в небольшом отделе, занимающемся веб-разработкой.
Отдел был сформирован с нуля и сразу начал работать автономно, поэтому нам пришлось самостоятельно выстраивать производственные процессы, наступать на всевозможные ошибки и делать из этого необходимые выводы.
В надежде, что это поможет кому-то сэкономить время, деньги и стресс, опишу проблемы, с которыми мы столкнулись, и наши варианты их решения.
Важно отметить, что это не какая-то универсальная методология, которую можно внедрить в любую команду разработчиков и все сразу станет отлично.
Это просто микс известных методик и практического опыта, который мы смогли эффективно адаптировать под особенности нашей разработки.
Единого простого решения этой проблемы не существует. Всегда нужно учитывать размер и опыт самой команды, особенности бизнеса, специфику проектов и т. д. Исходные данные нашего отдела: небольшая (5-10 человек), частично распределенная (часть сотрудников работает удаленно, часть в офисе) продуктовая команда с клиентами внутри самой компании.
Веб-проекты.
В составе отдела нет специалистов по системному администрированию, но в компании есть отделы, которые этим занимаются.
Командные коммуникации
Начнем с построения эффективных коммуникаций внутри отдела.
В любой команде важно выстраивать эффективные каналы и методы коммуникации, но когда команда становится распределенной, эта потребность возрастает. В нашей стране она достигла максимальной остроты, поскольку коллектив был рассредоточен лишь частично.
Нам пришлось научиться объединять миры офисных и удаленных работников.
Самой большой проблемой, с которой мы столкнулись, были устные дискуссии.
У офисных работников всегда возникает соблазн быстро собраться за чашечкой кофе и обсудить состояние дел по проекту.
Однако в этом случае удаленные работники не смогут участвовать в этом обсуждении, следовательно, они не смогут внести свои идеи и даже не будут знать, что что-то происходит. Как правило, это приводит к рассинхронизации действий команды, повторным обсуждениям из-за появления новых мыслей и предложений от распределенной части команды и просто неприятному осадку.
Стало понятно, что какие-то существенные общие вещи следует обсуждать письменно в общих чатах или на каких-то групповых звонках.
Это порождает еще одну очень распространенную проблему, которая возникает в командах, где много пишут: проблема культуры письма.
Вы больше не можете просто подойти к коллеге, потянуть его за рукав, нарисовать что-то на салфетке и завершить свой рассказ жестами.
С одной стороны, это усложняет работу, но с другой – у людей развивается навык излагать свои мысли письменно в понятной, структурированной форме.
В результате такого подхода документация стала лучше форматироваться, задачи стали более четко формулироваться, и каждый начал задумываться о том, как преподнести свою идею так, чтобы она была понятна другим с первого прочтения.
Все вышесказанное не означает, что мы полностью отказались от личного общения, голосовых и видеозвонков.
Однако мы взяли за правило, что результаты таких обсуждений должны фиксироваться письменно, как некий артефакт знаний, всегда доступный каждому.
Давайте кратко рассмотрим банальный список инструментов, с помощью которых мы решали наши коммуникативные проблемы внутри команды.
Для начала мы завели чат в Telegram. Но потом, в связи с ростом команды, мы поняли, что нам уже тесно в одном чате, и перешли в Slack. Там мы разделили общий поток на тематические каналы и установили четкие правила — по каким причинам в каком канале писать.
Это помогло избежать смешивания полезной информации и флуда.
Плюс переход на Slack дал нам хорошие возможности для автоматизации и интеграции с другими сервисами, такими как система управления репозиторием или трекер ошибок.
- Аудио- и видеозвонки — Skype для бизнеса.
- Управляем задачами в Jira.
- Мы храним базу знаний в Confluence.
Планирование, выполнение и контроль задач
Когда мы выстроили коммуникации, стала актуальной проблема постановки, контроля и выполнения задач внутри команды (о работе с заказчиком в этом плане я расскажу чуть позже).
У нас не было единого списка задач, их приоритетов, статусов готовности и т. д. Вместо четкого, прозрачного и отслеживаемого плана было спонтанное краткосрочное планирование и исполнение.
Чтобы бороться с этой ситуацией, мы начали использовать систему отслеживания ошибок (на самом деле мы попробовали пять из них).
Стали прорисовываться очертания общего направления проекта, возникло понимание состояния отдельных задач и общей картины в целом.
Однако мы столкнулись с проблемой недисциплинированности при использовании баг-трекера, что начало обесценивать многие наши начинания.
Не все задачи были внесены в баг-трекер, существующие не всегда обновлялись и т. д. Проще говоря, картина состояния проекта уже не актуальна и достоверна.
Для борьбы с этим мы разработали и внедрили собственную культуру управления задачами:
- Работу не следует выполнять до тех пор, пока не будет создана соответствующая задача.
Это помогает поддерживать историю развития проекта и работы команды всегда в актуальном состоянии.
- При работе с задачей необходимо своевременно менять ее статус.
В нашем случае достаточно четырех статусов: «Сделать» — начальное состояние задачи, «В работе» — задача, находящаяся в процессе выполнения, «В ожидании» — задача, начавшая выполняться, но работа приостановлена (ждём дополнительной информации), «Готово» — задача готова.
Готовность задачи должна быть так или иначе подтверждена заказчиком или менеджером внутри команды.
- Со временем количество задач и проектов сильно увеличилось, поэтому мы разделили общий список работ на отдельные подпроекты, и задача должна создаваться согласно этому списку подпроектов.
- Задаче должен быть присвоен приоритет. Это помогает понять, какие задачи и в каком порядке необходимо выполнить, чтобы принести проекту максимальную пользу.
- Периодически проводится пересмотр задач и их приоритетов.
Поскольку проекты живут и развиваются, а бизнес-планы иногда меняются, со временем некоторые задачи становятся менее или более актуальными или вообще требуют удаления.
- Некоторые ключевые обсуждения задач, будь то устные или письменные через чат, требуют, чтобы окончательное решение было записано в самой задаче, чтобы при ее выполнении мы всегда видели самую актуальную информацию о ней и ее истории.
Часто бывает, что первоначальная постановка задачи после ряда обсуждений трансформируется во что-то совершенно иное, и за этим нужно следить.
- Если внутри коллектива задача передается от одной группы специалистов к другой, то передающая группа обязана зафиксировать в ней все необходимые артефакты знаний, которые необходимо передать следующей группе.
Например, группа дизайна должна прикрепить макеты и всю необходимую для разработки документацию перед передачей задачи группе разработки.
Это позволяет избежать ненужных вопросов, отвлекающих факторов и переключений контекста.
- Прикрепление фиксирует проблемы.
Используя некоторые правила именования коммитов, мы автоматически присваиваем ссылкам на коммиты в GitLab задачам.
Это очень помогает в разработке понять, кто, что, как и когда выполнил это задание.
И в обратном направлении, используя правильно названные коммиты, всегда можно найти задачу, содержащую причину внесенных изменений.
Коммуникации с клиентом
Следующая категория сложностей, которую нам нужно было решить, — работа с клиентами.
Первое, что нам пришлось искоренить, — это постановку целей на словах.
Если мы установили культуру письма внутри отдела, то пришло время распространить ее и на внешние контакты.
Ни для кого не секрет, что некоторые менеджеры любят подойти к разработчику, на словах рассказать ему, что нужно сделать, для убедительности ткнуть пальцем в экран и уйти, надеясь, что все будет сделано хорошо и в срок.
В этой ситуации менеджера и разработчика может заменить владелец продукта и некий менеджер команды разработки, который управляет всеми этими задачами.
Результат не изменится.
При таком подходе есть несколько проблем:
- Сказанное словами и жестами забудется (хотя бы частично) примерно завтра, в лучшем случае послезавтра.
Дело не столько в каких-то мелочах, сколько в опасности совсем забыть о задании.
При этом невозможно никак подтвердить, что вы его кому-то установили или что кто-то обещал вам хоть что-то сделать.
- Обычно такая постановка задачи довольно хаотична и лишена каких-либо глубоких деталей.
В результате очень сложно уточнить недостающую информацию.
- Как обсуждалось ранее, постановка проблемы словами порождает пагубное нежелание учиться выражать свои мысли в письменной форме так, чтобы другие люди могли их понять.
В идеале мы хотели бы добавить всех клиентов в баг-трекер, где они могли бы ставить задачи, расставлять приоритеты, обсуждать детали и принимать работу.
Но это по-прежнему остается невыполнимой задачей.
Однако нам удалось найти компромисс, при котором задачи отправляются на корпоративную почту нашего отдела в строго письменном потоке, а с нашей стороны менеджер заносит и ведет их дальше в багтрекер по уже установленным у нас правилам.
Задачи больше не теряются, не забываются, не хранятся в головах конкретных людей, не обсуждаются неполной группой необходимых специалистов и т. д. Потом мы столкнулись с еще одной важной проблемой: заказчику было сложно сформулировать задачу.
Заказчик не всегда достаточно компетентен (вернее, почти всегда недостаточно компетентен) в формулировании технического задания для технической команды.
И это нормально.
Нельзя игнорировать человеческий фактор: заказчику может быть просто неловко и неудобно прийти с просьбой к команде, когда он сам еще не смог ее полностью сформулировать.
Одним из критериев зрелой профессиональной команды является способность помочь клиенту определить его проблемы, требования и решения.
Часто бывает, что заказчик вместо того, чтобы прийти с проблемой, приходит с просьбой реализовать уже придуманное им решение.
Чтобы не удивлять ни себя, ни заказчика результатами работы по техническому заданию, составленному «на салфетке», мы создали базовый чек-лист вопросов для заказчика.
Уже на основании этих ответов и заказчику легче понять, чего он на самом деле хочет, и команде разработчиков, что от него требуется.
А затем пришло время задать несколько наводящих вопросов, чтобы прояснить или определить требования.
Итак, перед первой встречей с заказчиком мы просим Вас сначала заполнить (по возможности) и прислать нам этот чек-лист, чтобы потом не тратить время на однотипные вопросы, а сразу приступить к работе.
плодотворный диалог.
Стоит отметить, что при взаимодействии с заказчиком важно не только уточнить ответы, которые он дал, но и, исходя из заявленной им проблемы, помочь ему выявить те требования, о которых он, возможно, не задумывался.
Список вопросов для клиента:
- Какова цель проекта? Какую проблему это решает? Какую ценность для бизнеса это приносит?
- Это единственное возможное решение данной проблемы? Если нет, то какие еще варианты есть?
- Существуют ли какие-либо общие требования для всего проекта? Например, если это интернет-магазин, то он должен полностью соответствовать законам, регулирующим интернет-торговлю.
- Есть ли функциональные требования? Что должен делать раздел (страница, проект)? Например, раздел должен предоставлять информацию о продукции компании и через форму на странице собирать желающих задать вопросы об этом товаре или приобрести его.
- Есть ли нефункциональные требования? Насколько хорошо он должен это делать? Например, время открытия страницы должно быть не более 5 секунд.
- Дополнительные требования.
Свободный формат, в котором можно излить душу.
Когда на разных проектах много заказчиков, каждый хочет уделить своей задаче наивысший приоритет. В общем идеальном случае эта задача, вероятно, не может быть решена на 100%.
Как нам с этим жить? С введением дисциплины в постановке и управлении задачами, а также некоторых элементов Agile-методологий наш пул задач стал более упорядоченным, прозрачным для внешнего наблюдателя, а главное, предсказуемым.
В нашей команде наведен порядок и планы, и нам остается только усилить обратную связь с клиентами.
Обсуждая приоритеты, сроки и планы, мы научились выстраивать аргументированный диалог, а не слепо торопиться с задачами и постоянно тушить полыхающие пожары (которые на самом деле не всегда актуальны и не всегда являются пожарами).
Также в рамках этого пункта мы постарались искоренить классический антипаттерн «чайка-менеджмент», когда пришел заказчик или менеджер, «наложил» задачи и улетел в полной уверенности, что раз он поставил задачу, то и результат безусловно, это будет отличный результат. Как показала практика, результат при таком подходе оказался не самым впечатляющим.
Как с этим справиться? Здесь тоже нет универсального совета, нет волшебной фразы, меняющей поведение людей.
Для этого необходимо говорить, воспитывать, объяснять, показывать, можно сказать воспитывать.
Только просветительская работа и либо очень наглядные, либо очень измеримые (а лучше и то, и другое) положительные и отрицательные примеры помогут в достаточной степени преодолеть «менеджмент чайки».
Разработчики против Ops
И наша последняя важная проблема — это проблема коммуникации между отделами разработки и эксплуатации.
Мы столкнулись с классической ситуацией, когда разработчики не совсем понимают, как работает сервер, а сторонняя админка не совсем понимает, как работает приложение.
Каждая трудность на пересечении этих двух сфер давалась нам с болью и большим количеством времени.
Трудно было даже диагностировать, с какой стороны проблема:
- Вы запрограммировали это там!
- Нет, что-то не так с вашим сервером!
Он смог поговорить с каждой группой на их языке и диагностировать каждую проблему с обеих сторон.
Нестыковки утихли, но мы остались привязаны к этому человеку.
Чтобы отвязать от себя все эти проблемы, он стал помогать администраторам понять, как работает приложение, а программистам — что происходит на сервере.
Добавим к объяснению голосом написание документации и мы не только улучшим знания всей команды, но и более слаженную работу отделов Dev и Ops. Да, в крупных подразделениях кровавого предприятия есть специальные команды и квалифицированные люди, которые все настроят так, что разработчики могут даже не знать, как и где работает их творчество на сервере.
Однако в небольших коллективах было бы неплохо развивать у людей этот уровень компетентности, а также иметь хотя бы одного сотрудника, который уже достаточно хорошо развит в этом плане.
Разработка
Параллельно со всем этим мы начали развивать культуру разработки.
Не буду заострять внимание на технической части, да и сейчас это уже стандарт де-факто и практически все понимают, насколько необходимо иметь систему контроля версий, CI/CD и другие инструменты разработки, сборки и развертывания.
Остановлюсь только на мягких моментах развития.
- Кодовый стиль .
Очень важно разработать и явно утвердить правила оформления кода.
Во-первых, эстетически приятнее видеть в проекте единый гармоничный образ, а не зоопарк разных стилей и стандартов.
Во-вторых, это повышает читаемость кода, а как мы знаем, большую часть времени программист пишет не свой код, а читает чужой.
- Именование коммитов .
Мы ввели определенные правила именования коммитов, чтобы по названию коммита было понятно, какие изменения были внесены, кем и в рамках какой задачи.
- Обзор кода .
Специфика наших проектов и команды такова, что у нас нет обязательного кода-ревью, без которого мы не сможем запустить наш код в производство.
Однако мы взяли за правило, чтобы хотя бы один человек смотрел код, который пушит коллега.
Это помогает не только заметить какие-то недостатки, внести альтернативные идеи, но и просто быть в курсе всех частей системы.
Проверка кода стала особенно актуальной с ростом количества и сложности проектов, из-за чего у каждого разработчика больше нет времени работать над всеми проектами настолько, чтобы разобраться во всех их деталях.
- Координация архитектуры внутри команды на ранних этапах .
Часто случается, что в стремлении быстро создать фичу фронтенд начинает делать что-то свое, бэкенд быстро начинает делать свое, а потом оказывается, что он интегрируется с большим трудом или не интегрируется вообще .
При разработке больших фич мы заранее совместно обсуждаем архитектуру, форматы обмена данными и т.д. В результате интеграция уже не является долгой и болезненной.
- Развитие на основе резюме .
Это проблема, при которой разработчики тянут в проект новые (свежие, модные, высокооплачиваемые) технологии не ради проекта, а ради галочки в своем резюме.
Мы открыты новым технологиям и стараемся развивать наши проекты технологично, но важно сохранять баланс, при котором будет как технологический прогресс, так и проекты успешно реализованы в разумные сроки.
В этой скользкой теме важны две вещи: чтобы заказчик не давил на сроки настолько, что разработчики не могут дышать, и чтобы команда разработчиков (или хотя бы компетентный тимлид или технический руководитель) заботилась не только о разработке их профиль в LinkedIn, но и о благополучии проекта в целом.
Рефакторинг, технический долг и принцип постоянного улучшения
Наш отдел начал формироваться вокруг уже существующего парка проектов, выполненных аутсорсерами.
Никакой документации там, естественно, не было, за актуальностью и качеством кода никто не следил.
Поскольку мы понимали, что нам придется долго с этим работать, поддерживать и развивать, было решено часть времени выделить на наведение порядка в проекте — рефакторинг, удаление ненужного кода и т. д. Поскольку проект был большим, уровень энтропии тоже был высоким.
Мы понимали, что за один присест физически все это не преодолеть, и морально отказывались от перспективы такой колоссальной работы.
Мы решили применить японский принцип постоянного совершенствования «кайдзен».
Мы разбивали технический долг на множество мелких частей и понемногу, но регулярно закрывали эти мелкие части, постоянно модифицируя и улучшая как проекты, так и работу самой команды.
Морально это не доставило никаких неудобств, но в то же время не оказало существенного влияния на разработку нового функционала и покрытие требований бизнеса.
Через полтора года мы обнаружили, что старый технический долг полностью погашен, и это открыло перед нами возможности для разработки функционала принципиально нового уровня сложности и важности.
Конечно, это не означает, что у нас сейчас нет технического долга.
По мере того, как проекты живут, развиваются, растут и развиваются, оно непременно накапливается.
Однако мы тщательно отслеживаем его, помещаем в специальный пул задач и регулярно выделяем некоторое время на его погашение.
Постоянная работа с техническим долгом позволяет нам найти баланс между разработкой нового функционала и качественной поддержкой старого.
В нашем случае мы, разработчики, смогли объяснить и показать бизнесу важность погашения технического долга.
Как мы это сделали? На практике мы продемонстрировали ситуации, в которых, если в текущий проект не будет проведен рефакторинг или какие-то другие структурные изменения, разработка нового функционала или изменение старого будет в принципе невозможно (или возможно, но гораздо медленнее).
Внедрение гибких методологий
Внедрение некоторых идей из Agile-методологий позволило нам повысить прозрачность нашей работы как внутри самой команды, так и для бизнеса, сделать разработку более предсказуемой и гибкой, а результат — более стабильным.
Первое, что мы сделали — организовали ежедневные стендапы внутри команды.
Поскольку команда распределена, в Slack для этого выделен отдельный канал, в котором каждое утро каждый сотрудник пишет три пункта: над какими задачами он работал вчера, над какими задачами планирует работать сегодня и есть ли проблемы, которые мешают с его работой.
Флудить на этом канале или обсуждать чьи-либо задачи или проблемы запрещено.
Этот канал предназначен исключительно для агрегирования информации о положении дел.
Остальные обсуждения должны проводиться в соответствующих тематических каналах.
Это позволило каждому человеку в команде понять, чем занимаются его коллеги, что происходит с проектом в целом и кому можно и нужно помочь.
Если без стендапов проблемы замалчивались, а через долгое время вдруг выяснилось, что задание еще не готово, то теперь четко видно, кому нужна помощь, что нужно сделать, чтобы работа команды была более эффективной.
Дальше мы решили вести разработку спринтами.
Каждую пятницу в конце дня мы проводим ретроспективу спринта, смотрим, какие задачи были в планах, что готово, что не готово, и если что-то не готово, то почему это произошло.
Мы думаем о том, какие проблемы у нас были и что мы могли бы сделать, чтобы избежать подобных трудностей в будущем.
Затем мы планируем спринт на следующую неделю, исходя из загруженности различных областей внутри команды и бизнес-приоритетов.
В результате в начале недели все разработчики знают, что и в какой последовательности делать, а бизнес знает, какие его потребности будут покрыты в ближайшее время, и уже может сформулировать свои «хотелки» на следующие спринты.
Стоит сказать, что мы не избавлены от неожиданных задач, которые могут нарушить наши планы спринта.
В этом случае нужно действовать исходя из конкретной специфики работы: как часто возникают подобные задачи? Сколько? Можно ли это предсказать? В нашем конкретном случае в разработке мы эмпирически подсчитали, сколько времени в среднем тратится на незапланированные задачи, и постарались включить этот резерв в спринт. Отдельно стоит отметить, что после начала работы по спринтам мы смогли конкретно узнать, какой объем работы нам сдан незапланированно, проанализировать и сократить это количество, тщательно обсудив с заказчиком приоритеты и наглядно показав, как сиюминутное желание получить не самую нужную сейчас функцию, влияет на общую продуктивность всей команды.
Мы также перешли от длинных выпусков к коротким.
Раньше мы получали техническое задание, тратили недели или месяцы на создание целого пакета функций и только потом показывали их заказчику.
В результате часто оказывалось, что заказчик либо передумал, либо ожидал чего-то не совсем того, чего он ожидал, и мы начинали переделывать все или часть того, что уже сделали.
А вносить изменения в уже готовый большой набор возможностей — сомнительное удовольствие.
Теперь мы демонстрируем каждую функцию как можно раньше, чтобы заказчик мог решить, действительно ли это то, что он хотел, или нужно что-то изменить.
Чем быстрее он ее либо одобрит, либо отправит на доработку, тем меньше труда мы вложим, следовательно, тем быстрее функция пойдет в производство.
В результате фичи стали быстрее поступать в производство, быстрее тестировались гипотезы и быстрее развивался проект.
Фактор автобуса
Поскольку команда у нас небольшая, мы сразу начали задумываться о проблемах, с которыми можем столкнуться при ротации кадров.
Конкретные люди стали единственными хранителями некоторых знаний, проекты разрослись по своим масштабам, и поэтому мы начали развивать культуру хранения и управления знаниями.
Искоренить эту проблему нам помогло накопление артефактов знаний, которые переместились из голов конкретных людей в физический письменный мир.
А именно:
- Все работы проводятся только при наличии задания в баг-трекере.
Это позволяет создать полную историю изменений в проекте.
- Если изменения задачи обсуждались где-то в чате или на встрече, мы обязательно отражаем результат этого обсуждения в самой задаче.
- Коммиты именуются с четким указанием внесенных изменений и ссылкой на задачу.
При этом в багтрекере интеграция настроена так, что в самом задании появляется ссылка на коммит в Gitlab. Это позволяет сохранять историю не только цели задачи и ее обсуждений, но и сохранять информацию о конкретных изменениях и их исполнителях.
- После разработки очередной фичи программист пишет документацию на Confluence, описывающую ее общую бизнес-логику и особенности реализации, если это необходимо.
- При возникновении каких-либо серьезных проблемных инцидентов проводится вскрытие в формате «что и когда произошло – что сделали – что на самом деле следовало сделать – как избежать подобной проблемы в будущем».
и ответьте ссылкой на него.
Таким образом, вам больше никогда не придется отвечать на этот вопрос или просить других людей его задать.
Этот метод хранения артефактов знаний неоднократно помогал нам находить информацию о частях проекта, которые в противном случае были бы обязательно потеряны.
Также это существенно снизило риски для проекта и команды при ротации персонала.
Последний пример: мы довольно легко и быстро восстановили информацию о бизнес-логике, принципе работы и способе развертывания инструмента, что сделал уволившийся два года назад сотрудник.
Если к этой методике применить работу со стойками и спринтом, то фактор шины снижается еще больше.
Не так давно мы провели эксперимент: один разработчик был в отпуске, а другой работал.
В тот момент, когда первый вернулся из отпуска, второй ушел в отпуск.
Суть эксперимента заключалась в том, чтобы не писать никаких объяснительных писем, сообщений, не передавать дела каким-либо образом и посмотреть, насколько сложно будет человеку после длительного отпуска понять, что произошло в его отсутствие, что изменилось, как именно и какие планы на будущее.
Как показала практика, просмотр баг-трекера, коммитов, документации, стендапов и спринтов позволял сотруднику довольно легко войти в курс дела и продолжить работу автономно.
Заключение
В заключение хотелось бы отметить, что ни одна из вышеперечисленных проблем не была решена сразу и безупречно.Организационные изменения – это всегда долгая и методичная работа.
Нельзя просто сказать «теперь мы делаем так» и надеяться, что теперь все будет по-другому.
Любые решения, которые вы принимаете, любые мероприятия, которые вы организуете, требуют контроля, обучения и воспитания людей, времени на адаптацию как команды к новым методикам, так и самих методик к конкретной ситуации.
Еще отмечу, что навязывание методологии людям – это очень трудоемкий и неэффективный процесс.
Люди будут сопротивляться, пренебрегать и, возможно, даже саботировать.
Чтобы в команде начались необходимые изменения, команда сама должна захотеть эти изменения.
Необходимо следить за тем, как с ней обстоят дела, выявлять проблемные места, осознавать эти проблемы, находить решения и только потом реализовывать их.
Конечно, не каждый член команды должен или хочет это делать, но если есть кто-то, кто увидел эти проблемы и придумал их решения, то он должен в первую очередь обучать команду.
Делитесь своими знаниями, наблюдениями, опытом, спорьте, показывайте и доказывайте, где сейчас находятся проблемы и какие шаги можно предпринять для их решения.
Это единственный способ провести серьезные организационные изменения максимально эффективно.
Даже если вы руководитель и хотите протолкнуть свою позицию и свое решение, постарайтесь сделать это максимально аргументировано и убедительно, тем самым сэкономив время на реализации и уберегая команду от нежелательного негатива.
Автор : Евгений Антонов, руководитель группы разработки Positive Technologies Теги: #Управление проектами #Управление продуктом #Менеджмент
-
Убиквитин
19 Oct, 24 -
Маршалл, Джордж Катлетт
19 Oct, 24 -
Как Создать Отдел С Нуля: Инструменты Для Hr
19 Oct, 24 -
Корпоративное Интервью
19 Oct, 24 -
Ботнеты На Базе Tor
19 Oct, 24 -
Тестирование Сериализаторов Для .Net
19 Oct, 24
