Так мы систему для кого разрабатываем? Конфликтующие требования вижу я :)
Для поиска альтернативных (не требующих разработки) решений — отлично «Impact mapping» подходит. В ментальной карте будет ветка целей («Уменьшить кражи»), под ней — две Персоны, которые помогут добиться этой цели («Фермер» и «Сторож»), под ними — будут действия Персон («Уведомление» для Фермера и «Ружье с солью» для Сторожа). На мозговом штурме — фермер решит, стоит ли идти по первой ветке или Петра Петровича с ружбайкой будет достаточно.
Формат Истории пользователя такой:
Как <Пользователь>, я хочу <Действие с системой>, что бы <Бизнес-ценность>.
Для описанного выше примера история может быть сформулирована так:
Как Владелец Фермы, я хочу получать уведомления о выезде тракторов за пределы фермы, что бы избегать не целевого использования своих активов трактористами.
Можно еще подумать над формулировкой и улучшить ее. Цель Истории — сделать понятным: кто и для чего будет использовать функциональность. Как только мы видим намек на техническое решение посередине <Действие с системой>, начинаем задавать больше вопросов о <Бизнес-ценности>.
Записываем такие бизнес-требования чуть наперед. А детали и способ реализации обсуждаем «точно вовремя» — когда Иван Иванович сказал что готов заплатить за эту функциональность. Хорошо работает в итеративных подходах с приоритезацией требований и доступом к «телу заказчика» для уточнения деталей.
В продуктах широкой аудитории к вариативному набору описанных выше техник добавляется следование принципам Lean StartUp, один из которых — измерение.
Как мы узнаем, что проблема над которой мы работаем — существует? Как мы узнаем, что решение, которые мы предлагаем — подходит? Как мы узнаем, что набор реализованной функциональности — удовлетворяет решению? Что меняется в поведении пользователей? Для получения ответов на эти вопросы, очевидно, потребуется дополнительная функциональность (аналитики гугл будет не достаточно).
Метрики имеют особое значение для стартапов, особенно, нацеленных на массовый рынок. Лучший материал на эту тему в 5-ти минутном ролике Dave McClure — Startup Metrics for Pirates. Можно нагуглить более полезный и обширный материал по запросу «AARRR», но в этом видео Дейв просто душечка.
А бизнес и не должен уметь формулировать хорошие требования
Именно это я хочу донести. Таких примеров с формами ввода и отчетами — масса. Использующийся в проекте формат описания требований часто провоцирует клиентов писать подобные спецификации. Чуть лучше дела обстоят в командах, в которых есть бизнес-аналитики. Однако, даже в этом случае есть риск формализации «решений глазами аналитика». Поэтому, освоение некоторых продуктовых техник и смена подходов работы с требованиями мне кажется важной в проектах заказной разработки.
«Истории Пользователя» хороши для высокоуровневого диалога о функциональности — они содержат контекст, действующее лицо и конечную ценность действия с системой. А для обсуждения вариантов реализации лучше подключать либо всю команду (в случае если это небольшие feature teams), либо разносторонне сбалансированную ее часть (интерактивных дизайнеров, экспертов предметной области и технологических возможностей).
«Гамбургер истории» — несмотря на несерьезное название позволяет избежать довольно серьезных разногласий в том, какой способ реализации минимален и достаточен с точки зрения бизнеса (инвестиций в его исполнение) и разработки (качества, рисков, стоимости поддержки). Такие открытые обсуждения помогают сторонам с часто полярными интересами понять мотивы друг друга, не разрабатывать откровенно слабых решений и не заниматься излишним их «золочением» (Over Processing в терминах Lean TPS)
Я предлагаю повысить удовольствие от работы, которое непосредственно зависит от наличия у нее цели и смысла. Все никак не пойму — где я написала про состояние стресса? Давление срочности и важности — это нечто другое. Попробую на примере.
Пример 3. Я девочка-гик, люблю программировать. А еще — жую иногда печеньки перед монитором, увлекаюсь. Мне в общем-то нравится быть здоровой и стройной. Но печеньки такие преченьки, мммм. И времени на пробежку вечно жалко — другие приоритеты. Как же быть? Я узнаю, что бывают такие мультиспортивные гонки — X-Крым. Там нужно делать много всего — бегать, плавать, дюльферить (простите, не знаю перевода) и лазить по скалам. Это классное, увлекательное приключение. Командное, притом. Но к нему нужно готовиться. И приходится себя вытряхивать на пробежку по утрам, и жевать изюм вместо печенек, и завязывать восьмерки. Цель важнее: хочу попасть на гонку и не сдохнуть там (простите), хочу этого опыта. Без давления срочности (это уже 5-го октября!) и важности (хочешь приключение? нужна подготовка!) мотивации заниматься здоровьем было бы сильно меньше.
В Примеры 1 и 2 были более релевантными софтверной разработке. Этот — более метафорический.
В этом пункте идет речь о высокоуровневом видении.
Пример питча.
Для разработчиков, освоивших базовые конструкции языка программирования, CheckiO — это обучающая социальная игра. Целью игры является создание и совершенствование программных решений, при помощи обратной связи и советов других игроков. У квеста есть легенда, персонажи и уровни с заданиями. Примером такого задания может служить написание программы, которая «играет» в тетрис. Программы «соревнуются» между собой и зарабатывают своим создателям очки в игре. Игроки видят код друг друга и могут совершенствовать свои программы.
Для рекрутеров и HR компаний, которые разрабатывают программные продукты, Чекио — это инструмент поиска кадров, оценки экспертизы разработчиков, проведения технических собеседований, организации «баталий» между девелоперами (с целью повышения культуры разработки, передачи опыта и знаний внутри компании).
Образно говоря, Checkio — это как Codeacademy + World of Warcraft. Это игровой образовательный портал с социальными механизмами, в котором наставничество — является частью игры. Таким образом, Чекио — это площадка для создания образовательной экосистемы нового типа.
Вы можете время от времени менять набор деталей и стиль подачи — в зависимости от того — кто перед вами: инвестор, юзер или кандидат в команду. Но цель одна: дать общее представление о проекте, заинтересовать, зажечь идеей, остаться в уме собеседника.
Простите, сомневалась как написать — «лифт питч» или «элеватор питч». Выбрала оригинальное название. На самом деле, это строго определенный тип презентации, который отличается весьма — и структурой и длительностью, и поэтому имеет отдельное непереводимое название.
Можно было бы написать «подача в лифте», но резало бы глаза тем, кто не знает формата, и смешило бы тех, кто его знает. Такие профессиональные техники зачастую не переводятся. По крайней мере, я не встречала достойного перевода.
Моя попытка научиться писать короткие статьи начинает попахивать фейлом — не хватает примеров и некоторого количества знаков, для объяснения деталей. Но продолжу учиться, а отстреливаться буду в коментах J.
Разумеется, ve1m прав. Регулярные овертаймы — это не здорово и не здорово. Я за поддерживаемый ритм разработки. Здесь я скорее говорю о балансе интересов продуктовой и технологической стороны. Если перегиб на стороне бизнеса, то мы успешно работаем над краткосрочными коммерческими целями, однако команда выжимается и страдает качество. Перегиб на стороне технологий характеризуется чистейшим кодом, экспериментами с новыми технологиями, 100% покрытием тестами и т.п., и при этом, несвоевременностью поставки продукта, потерей рынка либо несоответствию затрат и ценности.
Пример 1. Владелец продукта работает над игровым приложением. Проект длится почти год. За этот период «случилось» подобие внутреннего релиза, но процесс был слабо-итеративным. Команда технически очень сильная, зарплаты выше средних на рынке. Однако, потеря ощущения «срочности» сказывается на мотивации завершать начатое. Люди попросту привыкли не напрягаться, иметь достаточно времени и на фейсбучек и на неторопливую разработку.
Как разбудить вовлеченность в проект, в его результаты? «Придумайте» выставку, конференцию, встречу с инвесторами. Дисциплинируйте, прежде всего, себя. Покажите команде, как важна вам эта дата. Людям нравится решать сложные задачи. Нравится помогать и чувствовать полезность своей работы. В этом случае бессмысленно мотивировать деньгами, люди просто потеряли ощущение конечной цели. Дайте им почувствовать ее вкус, и они проснутся. И толковые спецы сами придумают какой процесс им построить, что бы «выручить» довольно (а может и слишком) лояльного к ним Владельца продукта.
Как видите, я сейчас не говорю о процессах. Статья — о Владельцах продуктов и для них же.
Пример 2. Владелец продукта разрабатывает конкурентное решение на рынке облачных хранилищ. Продукт строится на основе нескольких вау-фич, которые пока еще не реализованы ни в одном существующем сервисе. Проекту полгода. Владелец продукта уверен, что поставлять нужно «либо все, либо ничего». Точнее, «все и в лучшем виде». Команда таким же образом относится к внутренним техническим решениям. К предпринимательским веяниям в компании, разработчики относятся настороженно. Бытует мнение, что весь этот Lean StartUp — от лукавого, лишь сеет соблазны пасть до написания недостаточно великолепного кода.
Как мотивировать программистов на конечную цель? Цель в красивом коде, или в красивом продукте? Наведите порядок в своей голове, особенно если вы Владелец продукта с инженерным бекграундом. Цель — в проверке идеи и построении стабильного бизнеса. Почему важно поскорее проверить решение рынком? Что будет, если мы ошибались и вау-фичи окажутся невостребованными? Скольких пользователей охватили конкуренты за то время, пока мы пишем свое решение? Как часто они умеют поставлять версии? Как быстро они смогут скопировать наши фичи и сделать своим конкурентным преимуществом? Дайте большую картинку технологического бизнеса и люди поймут свою роль в нем. И сами поймут какое решение достаточно великолепно для этого времени и фазы жизни продукта.
Еще раз повторюсь — статья для Владельцев Продукта, о том, как сделать ваше видение — движущей мотивационной силой команды.
bromium, спасибо большое за комментарий, он много лучше статьи =) Вызвал несколько новых мыслей.
1. ИНДИВИДУАЛЬНЫЙ ПРОФЕССИОНАЛИЗМ
Соглашусь, безусловно важен. Чуть раньше писала о том, как собрать полнофункциональную команду и избежать автобусного фактора. В проектах, в отличие от стритбола, у нас есть время и выбор, важно ними воспользоваться.
Другое позитивное отличие проектов — время игры. За три-шесть месяцев, при наличии искры в глазах участников, можно подтянуть подающего надежды джуниора, научиться писать юнит-тесты, автоматизировать мануальное тестирование, начать деливерить в два-три раза чаще чем могли вначале… Поэтому, я бы обращала внимание не только и не столько на факт профессионализма, сколько на стремление к нему. Непрерывное стремление к профессионализму, в паре с желанием работать командно.
2. ИГРОВОЙ ИНТЕЛЛЕКТ
На игровом поле, даже при слабой технике или низком росте отдельных участников, команда может включить свой «баскетбольный интеллект» и буквально рассчитать как обыграть противника, используя слабости его игроков.
В проекте, когда мы осознаем ограничения своей продуктивности, недостаток навыков или инструментов, у нас может быть даже больше возможностей. В гибкой разработке есть специальный ритуал для этого — регулярная ретроспектива процесса, на которой команда генерирует идеи о том, как сыграть лучше в следующем «квартере». Независимо от того, какой процесс вы используете, регулярное осознание узких мест и культура непрерывного совершенствования сделают свое дело.
Что делать сильному игроку в слабой команде?
Типичные, на мой взгляд, модели — совмещенные: вариант 2+3 (альтернатива полному выходу — фриланс) либо вариант 1+4 (попытался — не вышло — потух). Опять-таки в проектах у нас больше времени и шансов. Как ними правильно воспользоваться?
3. СТАРШИНСТВО v.s. СТАРЕЙШИНСТВО
Мне очень нравится эта метафора в понимании типов лидерства. Старшина — тот, кто награжден полномочиями. Старейшина — тот, кто обогащен опытом. К старейшине сами идут за советом, поддержкой. Старшина может быть навязан кем-то, либо самим собой. Часто, мы, чувствуя себя старейшиной ведем себя как старшина. Не даем времени окружающим почувствовать наш профессионализм и захотеть нашего лидерства, совершаем другие социальные ошибки.
Это естественная трудность технических лидеров — на то они и технические, что посвящали себя инженерному профессионализму, а не психологии командного взаимодействия. Если есть желание «взять игру на себя», придется еще многому научиться.
4. HI-FIVE
Как и чему учиться — это огромный топик. Но кое-что мы можем вынести за полчаса с все той же баскетбольной площадки bromium:
… это поддержка своих партнеров по команде, подбадривание при неудачных действиях, подстраховка в сложных моментах в защите
Каждый член команды имеет на нее влияние, как элемент системы. Каждый участник может менять культуру своим примером.
Мои быстрые идеи:
— Три простые вещи: благодарить, хвалить, просить помощи. Регулярно.
— Отмечать успехи, и точно так же отмечать поражения (радоваться тому, чему мы научились).
— Завести командные ритуалы (очень нравится это движение — Hi-five Driven Development. )
— Завести забавные артефакты (вчера, были в гостях у команды с офигительный экспозицией напильников в офисе =))
Что-то я увлеклась =) Думаю, сказала достаточно. Спасибо кто дочитал.
SWOT как инструмент люблю и, в основном, использую его для выбора одного варианта из нескольких, а так же в роли «сам себе маркетолог». В отношении людей, признаться, не пробовала, поэтому пофантазирую: я бы его свела к чуть более формальному варианту sell/buy, целью которого было бы не знакомство, а именно анализ. Есть похожий айсбрейкер, с вопросами:
— Что я делать умею и люблю?
— Что я могу делать, при необходимости?
— Что я делать никогда не должен (и даже не просите)?
У последнего может быть причина как в неумении, так и в нежелании. Такая формулировка персональна и чуть более общая, чем в Weaknesses. Думаю, для того, что бы использовать SWOT в чистом виде, в команде должна быть открытая атмосфера и доверие. А в свеже-собранной команде их еще нет, есть только сильная потенциальная возможность их построить. Вот лично я бы ею не рисковала, и использовала чуть более «мягкие» к признанию своих недостатков инструменты.
Но мне интересен ваш опыт, я полагаю что все, как обычно, зависит от контекста. Как вы заполняете «внешние» блоки матрицы, Opportunities и Threats? По классике, они ведь включают внешние факторы (в данном случае, за пределами команды).
Спасибо за дополнение, совершенно согласна. Ничего так не разрушает доверие и мотивацию, как «мы поговорили, а толку?». Поэтому, важно на выходе каждой командной встречи иметь план следующих шагов и имена людей, которые проследят, что бы шаги были пройдены.
Так мы систему для кого разрабатываем? Конфликтующие требования вижу я :)
Для поиска альтернативных (не требующих разработки) решений — отлично «Impact mapping» подходит. В ментальной карте будет ветка целей («Уменьшить кражи»), под ней — две Персоны, которые помогут добиться этой цели («Фермер» и «Сторож»), под ними — будут действия Персон («Уведомление» для Фермера и «Ружье с солью» для Сторожа). На мозговом штурме — фермер решит, стоит ли идти по первой ветке или Петра Петровича с ружбайкой будет достаточно.
Как <Пользователь>, я хочу <Действие с системой>, что бы <Бизнес-ценность>.
Для описанного выше примера история может быть сформулирована так:
Как Владелец Фермы, я хочу получать уведомления о выезде тракторов за пределы фермы, что бы избегать не целевого использования своих активов трактористами.
Можно еще подумать над формулировкой и улучшить ее. Цель Истории — сделать понятным: кто и для чего будет использовать функциональность. Как только мы видим намек на техническое решение посередине <Действие с системой>, начинаем задавать больше вопросов о <Бизнес-ценности>.
Записываем такие бизнес-требования чуть наперед. А детали и способ реализации обсуждаем «точно вовремя» — когда Иван Иванович сказал что готов заплатить за эту функциональность. Хорошо работает в итеративных подходах с приоритезацией требований и доступом к «телу заказчика» для уточнения деталей.
Как мы узнаем, что проблема над которой мы работаем — существует? Как мы узнаем, что решение, которые мы предлагаем — подходит? Как мы узнаем, что набор реализованной функциональности — удовлетворяет решению? Что меняется в поведении пользователей? Для получения ответов на эти вопросы, очевидно, потребуется дополнительная функциональность (аналитики гугл будет не достаточно).
Метрики имеют особое значение для стартапов, особенно, нацеленных на массовый рынок. Лучший материал на эту тему в 5-ти минутном ролике Dave McClure — Startup Metrics for Pirates. Можно нагуглить более полезный и обширный материал по запросу «AARRR», но в этом видео Дейв просто душечка.
Именно это я хочу донести. Таких примеров с формами ввода и отчетами — масса. Использующийся в проекте формат описания требований часто провоцирует клиентов писать подобные спецификации. Чуть лучше дела обстоят в командах, в которых есть бизнес-аналитики. Однако, даже в этом случае есть риск формализации «решений глазами аналитика». Поэтому, освоение некоторых продуктовых техник и смена подходов работы с требованиями мне кажется важной в проектах заказной разработки.
«Истории Пользователя» хороши для высокоуровневого диалога о функциональности — они содержат контекст, действующее лицо и конечную ценность действия с системой. А для обсуждения вариантов реализации лучше подключать либо всю команду (в случае если это небольшие feature teams), либо разносторонне сбалансированную ее часть (интерактивных дизайнеров, экспертов предметной области и технологических возможностей).
«Гамбургер истории» — несмотря на несерьезное название позволяет избежать довольно серьезных разногласий в том, какой способ реализации минимален и достаточен с точки зрения бизнеса (инвестиций в его исполнение) и разработки (качества, рисков, стоимости поддержки). Такие открытые обсуждения помогают сторонам с часто полярными интересами понять мотивы друг друга, не разрабатывать откровенно слабых решений и не заниматься излишним их «золочением» (Over Processing в терминах Lean TPS)
Пример 3. Я девочка-гик, люблю программировать. А еще — жую иногда печеньки перед монитором, увлекаюсь. Мне в общем-то нравится быть здоровой и стройной. Но печеньки такие преченьки, мммм. И времени на пробежку вечно жалко — другие приоритеты. Как же быть? Я узнаю, что бывают такие мультиспортивные гонки — X-Крым. Там нужно делать много всего — бегать, плавать, дюльферить (простите, не знаю перевода) и лазить по скалам. Это классное, увлекательное приключение. Командное, притом. Но к нему нужно готовиться. И приходится себя вытряхивать на пробежку по утрам, и жевать изюм вместо печенек, и завязывать восьмерки. Цель важнее: хочу попасть на гонку и не сдохнуть там (простите), хочу этого опыта. Без давления срочности (это уже 5-го октября!) и важности (хочешь приключение? нужна подготовка!) мотивации заниматься здоровьем было бы сильно меньше.
В Примеры 1 и 2 были более релевантными софтверной разработке. Этот — более метафорический.
Пример питча.
Вы можете время от времени менять набор деталей и стиль подачи — в зависимости от того — кто перед вами: инвестор, юзер или кандидат в команду. Но цель одна: дать общее представление о проекте, заинтересовать, зажечь идеей, остаться в уме собеседника.
Можно было бы написать «подача в лифте», но резало бы глаза тем, кто не знает формата, и смешило бы тех, кто его знает. Такие профессиональные техники зачастую не переводятся. По крайней мере, я не встречала достойного перевода.
Разумеется, ve1m прав. Регулярные овертаймы — это не здорово и не здорово. Я за поддерживаемый ритм разработки. Здесь я скорее говорю о балансе интересов продуктовой и технологической стороны. Если перегиб на стороне бизнеса, то мы успешно работаем над краткосрочными коммерческими целями, однако команда выжимается и страдает качество. Перегиб на стороне технологий характеризуется чистейшим кодом, экспериментами с новыми технологиями, 100% покрытием тестами и т.п., и при этом, несвоевременностью поставки продукта, потерей рынка либо несоответствию затрат и ценности.
Пример 1. Владелец продукта работает над игровым приложением. Проект длится почти год. За этот период «случилось» подобие внутреннего релиза, но процесс был слабо-итеративным. Команда технически очень сильная, зарплаты выше средних на рынке. Однако, потеря ощущения «срочности» сказывается на мотивации завершать начатое. Люди попросту привыкли не напрягаться, иметь достаточно времени и на фейсбучек и на неторопливую разработку.
Как разбудить вовлеченность в проект, в его результаты? «Придумайте» выставку, конференцию, встречу с инвесторами. Дисциплинируйте, прежде всего, себя. Покажите команде, как важна вам эта дата. Людям нравится решать сложные задачи. Нравится помогать и чувствовать полезность своей работы. В этом случае бессмысленно мотивировать деньгами, люди просто потеряли ощущение конечной цели. Дайте им почувствовать ее вкус, и они проснутся. И толковые спецы сами придумают какой процесс им построить, что бы «выручить» довольно (а может и слишком) лояльного к ним Владельца продукта.
Как видите, я сейчас не говорю о процессах. Статья — о Владельцах продуктов и для них же.
Пример 2. Владелец продукта разрабатывает конкурентное решение на рынке облачных хранилищ. Продукт строится на основе нескольких вау-фич, которые пока еще не реализованы ни в одном существующем сервисе. Проекту полгода. Владелец продукта уверен, что поставлять нужно «либо все, либо ничего». Точнее, «все и в лучшем виде». Команда таким же образом относится к внутренним техническим решениям. К предпринимательским веяниям в компании, разработчики относятся настороженно. Бытует мнение, что весь этот Lean StartUp — от лукавого, лишь сеет соблазны пасть до написания недостаточно великолепного кода.
Как мотивировать программистов на конечную цель? Цель в красивом коде, или в красивом продукте? Наведите порядок в своей голове, особенно если вы Владелец продукта с инженерным бекграундом. Цель — в проверке идеи и построении стабильного бизнеса. Почему важно поскорее проверить решение рынком? Что будет, если мы ошибались и вау-фичи окажутся невостребованными? Скольких пользователей охватили конкуренты за то время, пока мы пишем свое решение? Как часто они умеют поставлять версии? Как быстро они смогут скопировать наши фичи и сделать своим конкурентным преимуществом? Дайте большую картинку технологического бизнеса и люди поймут свою роль в нем. И сами поймут какое решение достаточно великолепно для этого времени и фазы жизни продукта.
Еще раз повторюсь — статья для Владельцев Продукта, о том, как сделать ваше видение — движущей мотивационной силой команды.
1. ИНДИВИДУАЛЬНЫЙ ПРОФЕССИОНАЛИЗМ
Соглашусь, безусловно важен. Чуть раньше писала о том, как собрать полнофункциональную команду и избежать автобусного фактора. В проектах, в отличие от стритбола, у нас есть время и выбор, важно ними воспользоваться.
Другое позитивное отличие проектов — время игры. За три-шесть месяцев, при наличии искры в глазах участников, можно подтянуть подающего надежды джуниора, научиться писать юнит-тесты, автоматизировать мануальное тестирование, начать деливерить в два-три раза чаще чем могли вначале… Поэтому, я бы обращала внимание не только и не столько на факт профессионализма, сколько на стремление к нему. Непрерывное стремление к профессионализму, в паре с желанием работать командно.
2. ИГРОВОЙ ИНТЕЛЛЕКТ
На игровом поле, даже при слабой технике или низком росте отдельных участников, команда может включить свой «баскетбольный интеллект» и буквально рассчитать как обыграть противника, используя слабости его игроков.
В проекте, когда мы осознаем ограничения своей продуктивности, недостаток навыков или инструментов, у нас может быть даже больше возможностей. В гибкой разработке есть специальный ритуал для этого — регулярная ретроспектива процесса, на которой команда генерирует идеи о том, как сыграть лучше в следующем «квартере». Независимо от того, какой процесс вы используете, регулярное осознание узких мест и культура непрерывного совершенствования сделают свое дело.
Что делать сильному игроку в слабой команде?
Типичные, на мой взгляд, модели — совмещенные: вариант 2+3 (альтернатива полному выходу — фриланс) либо вариант 1+4 (попытался — не вышло — потух). Опять-таки в проектах у нас больше времени и шансов. Как ними правильно воспользоваться?
3. СТАРШИНСТВО v.s. СТАРЕЙШИНСТВО
Мне очень нравится эта метафора в понимании типов лидерства. Старшина — тот, кто награжден полномочиями. Старейшина — тот, кто обогащен опытом. К старейшине сами идут за советом, поддержкой. Старшина может быть навязан кем-то, либо самим собой. Часто, мы, чувствуя себя старейшиной ведем себя как старшина. Не даем времени окружающим почувствовать наш профессионализм и захотеть нашего лидерства, совершаем другие социальные ошибки.
Это естественная трудность технических лидеров — на то они и технические, что посвящали себя инженерному профессионализму, а не психологии командного взаимодействия. Если есть желание «взять игру на себя», придется еще многому научиться.
4. HI-FIVE
Как и чему учиться — это огромный топик. Но кое-что мы можем вынести за полчаса с все той же баскетбольной площадки bromium:
Каждый член команды имеет на нее влияние, как элемент системы. Каждый участник может менять культуру своим примером.
Мои быстрые идеи:
— Три простые вещи: благодарить, хвалить, просить помощи. Регулярно.
— Отмечать успехи, и точно так же отмечать поражения (радоваться тому, чему мы научились).
— Завести командные ритуалы (очень нравится это движение — Hi-five Driven Development. )
— Завести забавные артефакты (вчера, были в гостях у команды с офигительный экспозицией напильников в офисе =))
Что-то я увлеклась =) Думаю, сказала достаточно. Спасибо кто дочитал.
— Что я делать умею и люблю?
— Что я могу делать, при необходимости?
— Что я делать никогда не должен (и даже не просите)?
У последнего может быть причина как в неумении, так и в нежелании. Такая формулировка персональна и чуть более общая, чем в Weaknesses. Думаю, для того, что бы использовать SWOT в чистом виде, в команде должна быть открытая атмосфера и доверие. А в свеже-собранной команде их еще нет, есть только сильная потенциальная возможность их построить. Вот лично я бы ею не рисковала, и использовала чуть более «мягкие» к признанию своих недостатков инструменты.
Но мне интересен ваш опыт, я полагаю что все, как обычно, зависит от контекста. Как вы заполняете «внешние» блоки матрицы, Opportunities и Threats? По классике, они ведь включают внешние факторы (в данном случае, за пределами команды).