Как привлечь команду к процессу поиска идей и получить намного больше, чем идеи

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



    My Why


    Всем привет, меня зовут Аня, я продуктовый дизайнер в американской компании Scentbird NY, до этого занималась разработкой флагманских продуктов вместе с дизайн-командой Альфа-Банка.
    Мне по жизни очень везёт, и я почему-то всегда работаю с разработчиками, которые предлагают самые интересные решения по продукту. Причем даже лучшие, чем могли бы предложить многие менеджеры и владельцы продуктов. И я заметила вот какую штуку: чем раньше вы подключаете разработчиков к работе над задачей, тем лучше получается результат. Под катом я расскажу, как проводить брейнштормы с командой так, чтобы генерировать не самые очевидные, но зато эффективные решения. Которые при этом еще и весьма просты в реализации. И, что главное, как не потратить на это уйму времени и не погрязнуть в согласованиях.

    Процесс


    1. Выбор задачи


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

    В идеале — выбирать то, что можно реализовать в ближайшее время. И под ближайшим временем я тут имею в виду пару недель. От силы 3 недели.



    2. Подготовьте аналитику


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

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



    3. Two pizza team


    Не старайтесь пригласить на брейншторм всех, до кого дотянетесь — людей должно быть немного, но достаточно, чтобы съесть 2 целых пиццы (это примерно 5–7 человек). Конечно, это может быть один очень голодный разраб, да. В идеале — приглашайте самых заинтересованных участников команды.

    Ну и если вы решили действовать именно по такому принципу, то не забудьте и сами пиццы. Лучше с запасом.

    4. Time is money


    Разделите встречу на две части.

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

    Вторая половина — выбор 3-5 лучших идей и их обсуждение. Чтобы убедиться, что все друг друга правильно поняли, эти идеи можно попробовать сразу сценарно прорисовать.



    5. Визуализация


    Записывайте и зарисовывайте все идеи. Флипчарт, стикеры – и вперед.

    А что делать, если команда распределенная?

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


    Sococo — общее пространство и видеосвязь


    Miro, figma и другие интерактивные доски, можно клеить стикеры, писать списки и многое другое


    VR chat — лично я не пробовала, но выглядит многообещающе. У ребят даже кофе есть.

    6. После всего


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

    Большая польза, которую я замечаю в результате таких встреч:

    Вовлечённость и интерес

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

    Узнаю обо всех подводных камнях раньше обычного

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

    Сплочённая команда

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

    T2M снижается!

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

    Очень вероятно, что некоторым из приглашённых встреча покажется скучной и бессмысленной, всё-таки «разработчики хотят писать код». Поэтому всегда делайте брейнштормы добровольными. А если какой-то из предложенных пунктов не подходит именно вашей команде, то смело уберите его или замените на что-то другое. Чтобы сделать ваши процессы самыми классными, постоянно собирайте обратную связь от всех участников команды.

    Similar posts

    Ads
    AdBlock has stolen the banner, but banners are not teeth — they will be back

    More

    Comments 5

      +2
      Ну, блин!
      За пиццу и я готов классных идей нагенерить )

      ЗЫ: а вообще, стоит задуматься — почему разработчики создают идеи лучше чем те, кто должен это делать. =)
        0
        почему разработчики создают идеи лучше чем те, кто должен это делать
        Зависит от того, идеи чего брейнштормятся — продукта или реализации.

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

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

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

        И, немаловажно, среди каких разработчиков? Привлекать программистов для решения задач UI можно, например, из-за ограничений по бюджету, не всякая компания может себе позволить отдел UI дизайнеров, которые тоже вполне себе разработчики. Или, например, в качестве тимбилдинга, если компания увлеклась модой на вовлечение сотрудников в заботы о судьбах продукта.

        Лучше все же привлекать к изобретательству того, кто учился изобретать, а не всех сотрудников подряд в свободное от критических задач время. Программисты умеют мыслить системно и находить пути в сложных графах, но не всякий программист увлекался ТРИЗом и более современными наборами методов для поиска нестандартных решений.
          0

          Про пользователей 100%. Пользователю виднее, что бы он хотел видеть в программе нового, а программисту виднее каким способом эту хотелку реализовать. Вообще, конечно, молодёжные тусовочки — это хорошо, но лично я предпочитаю работать

            0
            Пользователю виднее, что бы он хотел видеть в программе нового
            Вот тут есть целых две проблемы.
            Во-первых, пользователь часто не замечает неудобств — смирился, привык, перестал обращать внимание, работает на автомате. Нужна помощь стороннего специалиста, обученного замечать чужие проблемы.
            Во-вторых, пользователь зачастую хочет решений, которые лечат симптомы (проблема XY, проблема молотка). Нужна помощь стороннего специалиста, обученного выкапывать основополагающую проблему.
            программисту виднее каким способом эту хотелку реализовать
            Программист обычно умеет хорошо реализовывать хотелки, а не раскапывать корни проблем. Не всякий программист умеет сказать — нет, вам нужно вовсе не то, что вы говорите. Мы можем сделать так, как вы просите, и вот еще способ, и вот так вот можно, но вам нужно не это, а вон то, потому что ваша основная задача в том-то, и предложенный вами костыль не поможет её решить, лишь добавит сложности.

            Выражение «понять боль пользователя» — это не про эмпатию. Это ряд навыков, которые относятся не к использованию и не к программированию. Поэтому я и написал выше, что поиск идей руками программистов допустим только в трех случаях:
            1. Поиском идеи называют выбор способа технической реализации уже поставленной задачи.
            2. Хотят поработать над элементом корпоративной культуры «все сотрудники вовлечены заботу о продукте».
            3. Экономят на UX специалистах.
              +1
              По поводу пользователя. Если брать корпоративного, то есть того, кого заставляют работать в программах, тогда да, поворчал, но работать надо. А вот если брать пользователя, который покупает программы — там люди уже гораздо более требовательные и хотят новых полезных фич, удобных логичных интерфейсов и тд

              По поводу программиста тоже не соглашусь. Есть программисты разные. Есть «мне сказали, я пишу» то есть аналоги корпоративных пользователей, а есть «думающие», кто анализирует, думает об оптимизации и пытается понять корень проблемы. Я лично первых вообще к программистам не отношу. Это просто кодеры

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

      Only users with full accounts can post comments. Log in, please.