Я планировал написать эту статью еще два года назад, сразу после публикации “Продуктовые vs. Фиче-команды”. Тогда мне казалось, что мне следует развить центральную смысловую линию в статье про разницу между продуктовыми и проектными командами, но в действительности это была попытка выдать желаемое за действительное.
Я по-настоящему хотел верить, что больше нет необходимости продолжать приводить доводы в пользу того, что проектные команды неэффективны. Ровно так же, как когда верил, что никто не будет голосовать за откровенное мошенничество, или что люди будут опираться на научные данные в вопросах, касающихся их здоровья, или что Facebook будет всегда поступать правильно. К сожалению, самовнушение не способно изменить реальность.
Мой партнер по компании Silicon Valley Product Group (SVPG) и соавтор книги EMPOWERED: Ordinary People, Extraordinary Products Крис Джонс недавно поделился со мной, что он все еще сталкивается с проектными командами, но я не желаю верить, что это до сих пор распространенное явление. Дело совсем не в том, что я не писал о проблемах, возникающих в проектных командах, просто многие из тех статей написаны уже более десяти лет назад, и мне очень хотелось верить, что мы это все уже прошли.
Как создать эффективную команду в бизнесе? Евгений Черняк
Эта тема, конечно, связана с вопросом различий между продуктовыми и фиче-командами. Существенная разница между продуктовой и фиче-командой состоит в расширении прав и возможностей. Разница в том, чтобы с одной стороны, давать команде проблему, которую необходимо решить, и с другой стороны — фичи, которые нужно реализовать.
Однако по сути разница между продуктовой и проектной командой в ответственности. В одном случае команда берет ответственность за ключевые результаты для бизнеса (“outcome” — метрика бизнес-эффекта, дает возможность измерить полученную ценность для компании и клиентов); а в другом команда занимается поставкой проекта, фактических результатов (“output” — метрика результата фактических действий; числовые измерители результата задач, шагов или действий, предпринятых для создания ценности).
На жаргоне метода Lean Startup (“Бережливый стартап”), продуктовая команда долговечна, она живет долго (обычно минимум 1-2 года). Проектная команда, напротив, существует на протяжении жизни проекта. Поэтому проектные команды иногда связывают с понятием “pool model”: инженеры привлекаются к работе над проектом в течение, например, недели, месяца или двух, а после окончания работы над проектом возвращаются обратно в пул, откуда их переназначат в какую-то другую область. Самый большой миф о проектной команде заключается в убеждении об эффективности такого подхода, якобы потому что каждый инженер “полностью задействован” на наиболее важном проекте в данный момент.
Если вы работаете над чем-то тривиальным, например, созданием веб-сайтов, тогда да. Но я никогда не работал с компанией, создающей тривиальные вещи.
TV1 | Абрамов И. — Свистунов Д. | Чемпионат России 2023 «Свободная пирамида»
Продуктовые компании создают вещи какие угодно, но не тривиальные. На самом деле, нормой является для инженера потратить несколько месяцев на изучение необходимой технологии, лежащей в основе архитектуры, релевантной кодовой базы и самой области достаточно хорошо, чтобы суметь сыграть свою ключевую роль. Эта же кривая обучения относится к дизайнерам и продакт-менеджерам.
Идея, что любой инженер или продакт-менеджер может легко и немедленно переключаться между главными областями, и что от него ожидаются инновационные идеи, бросает вызов реальности и выходит далеко за рамки принятия желаемого за действительное.
И это мы только говорим о скорости (velocity). Всё становится еще сложнее, если пытаться рассуждать о создании чего-то действительно ценного, не говоря уже об инновациях в интересах вашего клиента. Не только то, что люди на проекте едва ли знакомы с кодовой базой, они даже едва ли знакомы со своими коллегами, из-за чего не возникает достаточного уровня доверия, необходимого для реального сотрудничества и решения проблем. И еще меньше они знают о реальных заказчиках. Остается только пожелать удачи в поисках миссионеров, которые будут согласны работать по такой модели.
В более общем смысле, много лет назад мы научились одной вещи: успех исходит скорее не из проектов, а от постоянной работы и итераций в определенной области до тех пор, пока не будут получены необходимые результаты.
Признаки проектных команд довольно просто заметить: команды контрактников, низкая скорость, малая часть или совсем отсутствие инноваций, раздувающийся технический долг, отсутствие права собственности на результаты, осиротевшие проекты и повсеместные обвинения. Возможно, вы будете способны вернуться к этому проекту в какой-то момент в будущем, но гарантий здесь нет никаких, и даже если последующий проект одобрен, кто знает, будут ли на него назначены те же люди?
Эти недостатки давно установлены и хорошо известны. Так почему же так много компаний до сих пор используют проектные команды? Главная тому причина заключается в том, что проектные команды это часть IT-культуры. Вспомните определяющую характеристику IT — технологию рассматривают как центр бюджетной ответственности.
IT-организации обычно финансируют что-либо через проекты. Построить бизнес-модель проекта, обеспечить финансирование проекта, собрать команду, запустить проект, и надеяться, что никто не будет проверять фактические результаты на соответствие с бизнес-моделью, и так по кругу.
Обычно в этих организациях корень проблемы — это CFO и CIO . CFO хочет верить, что несет финансовую ответственность (а это не так). CIO хочет верить, что служит бизнесу, поставляя ценность заинтересованным сторонам (и это не так). Они не пытаются намеренно навредить своей компании, однако, их действия часто ведут к значительным потерям, и что более важно, к такому состоянию компании, при котором она созревает для разрушения. В том числе и по этой причине важно осознавать, что переход от проектной команды (или фиче-команды) к наделенной полномочиями продуктовой команде выходит далеко за рамки продукта и технологий.
Стоит отметить, что с подобной проблемой сталкиваются не только крупные ИТ-компании, существующие на рынке давно. Я наблюдал ситуацию, при которой один стартап с отличными навыками работы с продуктом стремительно рос, но вместо того, чтобы масштабироваться за счет того, чтобы дать командам право много работать так, как стартап делал в свои первые годы, лидеры пытаются масштабироваться, набирая персонал и руководя проектными и фиче-командами, не осознавая при этом, что они теряют наиболее важный ингредиент своих прошлых лет.
Конечно, я не единственный, кто рассуждает на эту фундаментальную тему. Как я и сказал, это общепризнанная и широко известная проблема. Отличную статью об этом вопросе пару лет назад написала компания Thoughtworks.
Материал подготовлен в рамках курса «Системный аналитик. Advanced». Если вам интересно узнать подробнее о формате обучения и программе, познакомиться с преподавателем курса — приглашаем на день открытых дверей онлайн. Регистрация здесь.
- системный анализ
- управление продуктом
- продуктовые команды
- проектный команды
Источник: habr.com
Команда проекта — это. Понятие, этапы развития и управление
Команда проекта это группа людей, от которых зависит его успешность. Две основные задачи, решаемые при продумывании новой идеи: сбор команды, подготовка ее эффективной работы. Так как организация команды проекта является важным и ответственным мероприятием, остановимся на этом вопросе подробнее.
Суть термина
В непосредственной зависимости от специфики, типажа, масштаба рассматриваемой инициативы, участие в работе могут принимать как отдельные профессионалы, так и несколько разнообразных организаций. Все они – члены команды проекта в широком смысле данного термина. Среди представителей инициативной группы выделяют:
- инвесторов;
- непосредственных заказчиков;
- финансовые предприятия;
- проектировщиков;
- консультантов по бизнесу;
- поставщиков ресурсов и материалов;
- различных подрядчиков.
Каждый из них выполняет какие-то определенные функции, несет ответственность за конкретную часть работы. Из всех сотрудников выделяют микрогруппу, которая будет решать определенные вопросы на протяжении всей разработки и внедрения инновационной идеи.
Эффективная команда проекта – это специалисты, занимающиеся непосредственным осуществлением новой инициативы, подчиняющиеся проектному менеджеру. Ее создание является обязательным условием для успешной реализации задумки, способствующей созданию уникального продукта.
Важные моменты
Команда проекта — это коллектив, формирование которого осуществляется до начала внедрения инициативы « в жизнь». Он распускается сразу после того, как успешно справится с поставленной перед ним задачей.
Состав команды проекта подбирается профессионалами, является дорогостоящим и затратным по времени процессом. Необходимо установить между членами группы доброжелательные и работоспособные отношения, чтобы рассчитывать на получение желаемого результата. В некоторых случаях для экономии материальных ресурсов в компании создается рабочая группа. Целью ее работы является выполнение специфической задачи, актуальной на конкретный момент времени для организации.
Функционирование
Структура команды проекта и ее количество варьируется в зависимости от специфики реализуемой идеи.
Каждый участник отвечает за определенную часть проекта, преследуя при этом и личные интересы.
Создание команды проекта предполагает не только формирование группы, но и совместное обучение, общение. Подобный подход способствует получению на выходе желаемого результата. При благоприятном психологическом климате между участниками, решения принимаются мобильно и взвешенно. Единомышленниками учитываются внешние и внутренние факторы, поэтому ускоряется процесс внедрения идеи в жизнь.
Принцип создания
Как происходит формирование команды проекта? Данная группа имеет ряд существенных отличий от стабильного коллектива работников. Так как она выполняет определенные функции только на конкретном временном промежутке. Существуют определенные принципы ее формирования. Остановимся на этом вопросе подробнее.
Главные игроки идеи (подрядчик и заказчик) создают свои группы, руководят которыми профессиональные менеджеры. По обоюдной договоренности между сторонами, руководителем является менеджер от заказчика или от подрядчика.
Развитие команды проекта способствует достижению поставленной задачи в минимальные временные сроки. Управленческая функция руководителей заключается в выполнении следующих задач:
- в планировании реализации инициативы;
- обеспечение идеи нужным кадровым составом;
- систематический контроль деятельности;
- мотивация сотрудников на достижение определенного результата.
Специфика внедрения идеи
Управление командой проекта определяется с учетом специфики внедряемой инициативы. От этого напрямую зависит структура группы, количество нужных специалистов, требования к их умениям и навыкам.
Команда проекта это единый механизм, от слаженности которого зависят сроки выполнения необходимых работ. К примеру, если предполагается реализация замысла в области здравоохранения, для команды нужны будут дипломированные медицинские администраторы и врачи.
Строительная команда проекта — это проектировщики, архитекторы, строители, снабженцы, без которых сложно себе представить данную отрасль экономики.
Организационно-культурная среда
Внешние факторы оказывают существенное влияние на работу предприятия. Внутренние элементы включают следующие аспекты: сплоченность компаньонов, коллективные нормы работы, распределение функциональных обязанностей, коммуникативные навыки.
Грамотное управление командой проекта способствует минимизации подобных влияний. Существенным отличием команды от классического вида трудового коллектива является функционирование на основе профессионализма и деловых качеств, а не применение типичного иерархического принципа.
Способы формирования
Новые инициативы могут появляться и внутри одной организации (компании), и при сотрудничестве сразу нескольких небольших компаний. Именно поэтому разными способами осуществляется формирование проектной команды. Это важное условие.
В зависимости от цели команды проекта применяются определенные инструменты и подходы. Например, когда суть замысла связана с реструктуризацией, расширением, модернизацией внутри конкретного предприятия, проект представляет собой часть ежедневной работы руководителя и специалистов, выбранных для работы.
Классическая модель
Менеджер, назначенный руководителем компании, помимо своих основных функциональных обязанностей, также руководит идеей, реализует этот конкретный замысел.
У него есть полноценный доступ к требуемому персоналу, полномочия на координацию всех действий, планирование этапов работы. В общей организационной структуре компании при продумывании новой идеи выделяют отдельную структурную единицу.
Подобная модель является классической формой, используется она в основном на крупных предприятиях. Она предполагает приоритетность инновации над повседневной деятельностью, так как менеджер не касается типичной иерархии, установленной в компании. Менеджера и основных членов команды освобождают на время от выполнения своих непосредственных функциональных обязанностей. Куратором группы назначается сам руководитель фирмы либо его заместитель.
Смешанная форма
Она подходит для средних фирм. Суть создания проектной группы состоит в том, что инновацию возглавляет менеджер со стороны. Именно на него возлагается ответственность за успешность реализации идеи. Для выполнения задачи, поставленной перед ним, такой специалист может привлекать в проект сотрудников иных подразделений. Отличие состоит в том, что, помимо работы над инновацией, они продолжают выполнять основные обязанности.
Если идея реализуется сразу несколькими компаниями, в проектную группу включают представителей всех заинтересованных в успехе предприятий. Стандартной считают такую организацию процесса, при которой для каждой задумки создают отдельную группу исполнителей.
Основные походы к созданию команды
В настоящее время используют четыре базовых принципа:
- целеполагающий;
- межличностный;
- ролевой;
- проблемно – ориентационный.
Первый предполагает установку конечной цели в качестве ориентира работы проектной группы, предварительное продумывание путей ее достижения.
Межличностный принцип состоит в повышенном внимании к взаимоотношениям между членами команды, Успешность работы напрямую зависит от установления коммуникативных доверительных отношений, поэтому руководитель проекта часто прибегает к помощи профессионального психолога.
Ролевой принцип направлен на разделение между членами группы основных полномочий, наделение каждого человека собственными правами и обязанностями.
Последний принцип способствует решению в рамках совместных диспутов всех спорных вопросов, что существенно ускоряет реализацию замысла, повышает его эффективность.
Критерии отбора сотрудников
Отдельное внимание уделяется опыту и профессионализму людей, которые будут заниматься разработкой и внедрением новинки, важной для компании. Сотрудники, привлекаемые в проект, должны быть инициативными, готовыми брать ответственность за принимаемые ими решения. Приветствуется желание уделять максимальное количество времени работе, а также самостоятельность при планировании этапов деятельности.
Никаких особых требований к возрастному составу при создании команды проекта не выдвигается. С целью сплочения нового небольшого коллектива руководитель организует совместные мероприятия: праздники, туристические походы, корпоративные вечеринки.
Структура разрабатывается с учетом функций, выполняемых специалистами, а также взаимоотношений между ними. Среди групповых процессов, влияющих на оперативность достижения цели, отметим групповое давление, динамические показатели, продумывание совместных решений. Среди факторов, которые негативно отражаются на скорости реализации проекта, отметим отсутствие четко сформулировано цели, плана работы, постоянные внутренние конфликты, а также недостаточность ресурсов и незаинтересованность руководителя в продвижении проекта.
В реалиях нашей страны при привлечении в команду ценных специалистов из иных подразделений, появляются разнообразные конфликты между начальниками отделов и менеджерами. Максимальные сложности появляются у молодых и перспективных работников, получаемых от руководителя ответственное задание. Проблема в подобных ситуациях должна решаться с помощью конструктивных переговоров, а руководство обязано расставлять правильные акценты в команде.
Этапы становления и цикл «жизни»
После появления интересной идеи до момента ее успешного внедрения в реальность, проходит сразу несколько последовательных стадий. В это время происходит налаживание отношений между частниками, выстраивание доброжелательного и результативного сотрудничества. Менеджер наблюдает за процессами, происходящими внутри группы, пресекает конфликты и недопонимания, ориентирует участников на конечный результат.
На этапе ориентации осуществляется первичное поверхностное знакомство всех участников новой группы. Они находятся в состоянии неуверенности и неопределенности в своих силах и возможностях, поэтому руководителю важно создать на данном этапе правильный настрой.
Менеджер не только ориентирует своих единомышленников, но и отвечает на вопросы, формирует перечень правил, цель, методы ее достижения.
В процессе общения появляются конфликты и разногласия, касающиеся распределения функций в команде. Руководителю нужно снизить продолжительность данной фазы, в минимальные сроки распределить роли между членами группы.
От заинтересованности самого руководителя напрямую зависит увлеченность каждого сотрудника, его желание проявлять инициативность, самостоятельность и оригинальность при планировании основных этапов деятельности.
На этапе сотрудничества предполагается установление доверительных отношений, четкое распределение ролей, последовательная работа по обдумыванию плана работы.
Рабочий этап — это время непосредственное время внедрения всех задумок в реальную жизнь. Его продолжительность связана со спецификой рассматриваемой идеи, а также материальными возможностями компании, осуществляющей проект.
Завершающим этапом является оценка эффективности проекта, полноты достижения поставленной в начале работы цели.
Источник: fb.ru
Как руководителю проекта подружить проектную команду и бизнес
Когда я начинала свою карьеру в разработке, многие запросы пользователей, аналитиков и руководителей проектов казались мне непонятными и странными. За последующие годы я прошла несколько этапов карьерного пути: после разработчика была архитектором, аналитиком, руководителем проекта и аккаунт-менеджером. Это помогло мне взглянуть на потребности заказчиков с других ракурсов, и многие запросы бизнеса оказались понятными и обоснованными.
Я хочу поделиться опытом и рассказать, как руководителю правильно погрузить проектную команду в контекст заказчика, сделать потребности бизнеса или отдельных пользователей понятными, а проблемы — решаемыми. Под руководителями проекта я подразумеваю в том числе и тех руководителей, которые выстраивают коммуникацию между заказчиком и проектной командой — владельцев продукта, аккаунт-менеджеров.
Шаг 1. Оцениваем текущую ситуацию
Для начала необходимо понять, как команда видит цели и задачи проекта. И сразу плохая новость: если коллега сам пришёл с уточняющими вопросами, это может быть тревожным сигналом о том, что непонимание накопилось не только у него, но и у всей команды. Внимательно понаблюдайте за происходящим: что говорят о проекте? Задают ли вопросы вам? А вашим коллегам?
А друг другу? Часто люди до последнего стараются разобраться в проблеме самостоятельно, но при этом внутри них копится недовольство проектом, клиентом или руководством. Причин, почему вопросов не задают вовремя, может быть множество. Некоторые думают, что их посчитают глупыми или некомпетентными. Другие стесняются спросить, необщительны или считают, что коллеги должны им все рассказать или догадаться, что они чего-то не понимают.
Конечно, в компаниях, где корпоративная культура построена на взаимовыручке и доверии, сотрудники более расположены к обсуждению тем, которые их волнуют или вызывают непонимание. Но даже в этом случае руководителю проекта лучше работать на предупреждение деструктивных ситуаций. Его главная задача — соблюдать обязательства перед заказчиком и при этом поддерживать комфортную и продуктивную атмосферу в коллективе.
- Как он понимает цели и задачи проекта?
- Как он понимает свои собственные цели и задачи?
- Какие цели он считает приоритетными: свои, проектной команды, пользователей, заказчика или те, которые определяет его проектная роль?
- Кому он задает вопросы и отчитывается о результатах своей работы? Кого считает руководителем?
- Что он считает успешным результатом своего труда?
Ключевые слова здесь — «с каждым». Без индивидуального общения картина будет неполной. К встрече нужно подготовиться заранее, учитывая особенности и личные предпочтения человека.
На что стоит обратить внимание:
Место. Одному комфортнее обсуждать рабочие вопросы на обеде, другой чувствует себя спокойнее в тихой переговорной, а третьему удобнее перекинуться парой фраз за кофе на корпоративной кухне.
Время. Человек, с которым вы общаетесь, должен быть в рабочем состоянии. Так что не назначайте встречи жаворонкам на конец дня, а совам — на раннее утро.
Личный настрой. На встречу нужно идти с желанием узнать что-то новое о человеке и о проекте. Если вам не интересно чужое мнение и вы не готовы слушать, лучше не тратьте рабочее время. Если обсуждение проходит «для галочки», то люди интуитивно это понимают, поэтому с таким подходом открытого диалога не получится. Вам расскажут «правильную» или корпоративно одобряемую версию событий или вообще ничего толком не объяснят.
Проведение встречи. Больше слушайте, задавайте вопросы, интересуйтесь, старайтесь услышать, что вам хочет сказать человек. В процессе встречи можете делать записи, если боитесь что-то упустить, но постарайтесь не писать постоянно.
Подведение итогов. После встречи выделите время, чтобы зафиксировать цели проекта, которые озвучил вам коллега, и его личные стремления. Лучше сделать это сразу, пока свежи воспоминания. Я рекомендую фиксировать формулировки человека дословно, чтобы не потерять исходного смысла. Приведу примеры из личной практики.
Посмотрите, насколько различаются формулировки целей разных сотрудников, работающих в одном проекте: «сделать отчеты по ценным бумагам для трейдеров»; «сделать проект в срок и уложиться в бюджет»; «удовлетворить требованиям ТЗ»; «удовлетворить требованиям пользователей». Аналогично и с постановкой личных целей: «освоить новую технологию»; «научиться понимать аналитика»; «делать работу, и чтобы никто не трогал»; «найти много багов».
Шаг 2. Составляем «карту местности»
Все результаты встреч переносим на «карту местности»: рисуем организационную диаграмму, структуру коммуникаций, обозначаем функции и задачи каждого сотрудника и другие важные нюансы. Если схема организационной структуры выглядит понятной, то либо в проекте всё хорошо, либо вы что-то упустили. Чаще схема выглядит запутанной. Приведу пример из реальной практики.
На картинке изображены люди, цвета пиктограмм соответствуют разным функциям (аналитика, разработка, тестирование, владение продуктом). Стрелочки показывают, кто кому подчиняется, по мнению руководителей и самих сотрудников.
Шаг 3 (или 0). Описываем внешний контекст: задачи заказчика и продукт
Если вы руководите проектом с его старта, этот шаг должен быть первым. Но более распространенная ситуация — долгоживущий продукт с периодической сменой руководителей. В этом случае правильнее сначала изучить существующие материалы по продукту и затем сравнить их с задачами заказчика, выяснить, чего хотят конечные пользователи, с какими проблемами они сталкиваются, а также подумать над способами их решения.
Существует масса практик, которые помогают разрабатывать продукт: фиксировать информацию от пользователей, создавать описания продукта, проверять гипотезы. Приведу самые распространенные, расположив их сверху вниз по степени увеличения детализации создаваемых описаний продукта:
- Canvas Business Model,
- Глубинные/пользовательские интервью,
- Customer Journey Map,
- Customer Development,
- Service Design,
- Story Map,
- User Story,
- Jobs-To-Be-Done.
Все эти практики можно применять в продуктовой разработке, при этом три последние подходят для использования в заказной разработке.
В проекте, где уже есть прототипы или какие-то версии продукта, будут некоторые описания продукта. Если вы делаете продукт с нуля, то они должны сформироваться в ходе работы проектной команды.
Шаг 4. Определяем различия между желаемым и действительным
Вам нужно сопоставить желаемую и реальную ситуацию в проекте по двум направлениям:
- продукт,
- организационная структура внутри команды.
Продукт
Ожидания заказчика и сам продукт часто описываются при помощи разных методологий. Поэтому универсального способа для поиска несоответствий между такими описаниями нет. Для решения этой задачи вам придётся применить аналитический подход и сопоставить эти описания вручную. Итогом работы должен стать перечень различий. Он ляжет в основу плана конкретных изменений в проектируемом или уже созданном продукте.
Организационная структура
На данном этапе нужно создать схему желаемой организационной структуры, опираясь на схему, которая получилась после шага 2.
Отдельно для всех типов деятельности и каждой роли нужно описать функции, которые будет выполнять человек. После этого сравните вашу точку зрения с мнениями членов команды. Различия обязательно найдутся, поэтому на заключительном этапе работы с организационной структурой важно подумать о том, как объяснить сотрудникам необходимость преобразований и их новые функции.
Если тимлиды будут не в курсе вашей загруженности, то увеличат количество задач, а это приведёт к выгоранию. Возможно, вы захотите лично обратиться к кому-то из членов команды. Например, вы пожелаете, чтобы разработчик взял на себя функции тимлида.
Постарайтесь, чтобы человеку было приятно услышать ваше предложение. Не стоит формулировать его так: «Вася, к тебе все ходят с вопросами по технической части и уточняют, что делать. Давай ты будешь руководить ребятами?». Гораздо лучше сказать: «Василий, мы видим, что ты стал экспертом по продукту, умеешь принимать взвешенные технические решения и доносить их до команды.
Как ты относишься к тому, чтобы узаконить эти функции? При новом распределении нагрузки часть времени ты будешь тратить на координацию группы, а часть — на разработку». Так вы обозначите сильные стороны человека, покажете, что видите его заслуги и оцениваете их по достоинству, и при этом зададите все необходимые вопросы, не загнав человека в угол.
Сотрудник может отказаться от вашего предложения, это его право. В таком случае вам нужно будет вернуться к пересмотру организационной структуры.
Важный момент. Персональное предложение сначала нужно обсудить с человеком лично. Только после этого можно будет озвучить принятое решение всей команде. Сотруднику будет не очень приятно узнать, что его назначают тимлидом, на общей встрече.
Шаг 5. Доносим контекст до команды
Всю собранную информацию нужно не просто осмыслить, а передать в работу команде. И тут важно выбрать метод, подходящий именно вашим коллегам: общие статусы, индивидуальные встречи, презентации, воркшопы или что-то ещё. Здесь вам помогут данные, которые вы зафиксировали на этапах 1 и 2.
Чаще всего описания продукта по требованиям заказчика готовит только часть команды. Это могут быть: владелец продукта, аналитик, руководитель проекта, архитектор или ведущий разработчик, UX/UI-дизайнер. Поэтому тех, кто подключается к проекту уже после создания описаний, необходимо оперативно ознакомить с актуальной повесткой. И нет, это не значит прислать ссылку на хранилище тучи файлов.
Здесь все ситуативно. В моей практике наибольшую эффективность показали регулярные презентации о продукте для всей команды. В нашем случае это ежемесячная часовая встреча, на которой руководители рассказывают о том, в каком состоянии на данный момент находится продукт, что из прошлых планов удалось реализовать и какие наработки планируются в будущем.
Как и во всякой встрече, залог её успешного проведения — предварительная подготовка. О том, как подготовиться ко встречам, можно почитать в этой статье. После мероприятия важно собрать вопросы и оперативно дать на них ответы.
Как подготовить совещание, на которое захотят приходить
Однако для некоторых команд такие форматы оказываются совершенно нерабочими и приходится подбирать другие варианты. Мои коллеги, руководители проектов, иногда устраивают воркшопы для крупных команд, чтобы под руководством опытного тренера сформировать единое описание продукта. Здесь стоить отметить, что такие воркшопы могут проводиться как для создания описаний, так и в случае знакомства сотрудников с материалами, подготовленными частью команды проекта.
Вариант воркшопов особенно продуктивен, когда проект только стартует, а также если в команде больше таких людей, которым самостоятельное осмысление задачи и вариантов ее решения помогает убедиться в необходимости ее выполнения.
Очень рекомендую записывать общие встречи и воркшопы на видео, чтобы новые сотрудники могли ознакомиться с материалами. Это не отменит индивидуальных встреч, но поможет коллегам получить предварительную картину происходящего и сократит время на персональное погружение.
Существует множество других форматов передачи знаний. Чтобы выбрать правильный инструмент, можно обратиться к специалистам по внутренним коммуникациям вашей компании, если такие имеются.
Шаг 6. Контролируем все организованные процессы
Если вы успешно прошли предыдущие шаги, то вам удалось наладить работу над проектом. Каждый член вашей команды знает свои цели и задачи, понимает свой вклад в общее дело и то, какой результат нужно получить. На этом этапе руководителю важно не убирать руку с организационного пульса. Недопонимание внутри коллектива и при общении с заказчиком возникает постоянно, поэтому необходимо вовремя отслеживать разногласия и возвращать рабочий процесс в продуктивное русло.
Источник: tproger.ru
