Диагностика проблем в команде за четыре часа на примере живого стартапа

  • Tutorial
Самая частая из проблем, с которыми я встречаюсь в проектах, — что менять в первую очередь, на чём фокусироваться. «Как» все знают или считают что знают. У меня припасено несколько хаков, которые позволяют за полдня провести первичный анализ, выявляющий точки фокуса.

image

В этот раз я хочу поделиться одним из них, на примере работы с командой одного успешного стартапа на прошлой неделе. Конкретная сфера деятельности проекта не имеет принципиального значения. Упомяну лишь, что они используют Scrum и, по мнению руководителя, «некоторые проблемы он всё равно не выявляет». Я, кстати, искренне считаю, что не существует ни одной универсальной методики, охватывающей все уровни управления. Максимально эффективно знание и применение хотя бы двух-трёх разноплановых.
Существует видение проблем на уровне первого лица, среднего менеджмента и линейных исполнителей. Моё мнение — самые важные проблемы выясняются на нижнем уровне, но эффективно решаются только через анализ их влияния на весь проект. Это главная проблема общения программиста или дизайнера с CEO. Последний часто понимает в чём загвоздка, но воспринимает это как боль конкретного сотрудника, не считая что она глобально влияет на весь процесс.

Собственно метод.

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

Шаг 1.
Если вы хотите опробовать метод на себе, запишите эти проблемы сейчас, не читая дальнейших спойлеров.

Я буду приводить примеры такой диагностике на примере трёх членов реальной команды:
  1. Дизайнер
  2. Заместитель генерального.
  3. CEO/Founder проекта.

Проблемы с точки зрения дизайнера
Проблемы в проекте
1. Отсутствие коммуникации внутри команды, изолированность
2. Отсутствие визуализации плана куда движемся
3. Отсутствие сильного тимлидера у разработчиков
4. Мало свободы, быстрый темп, даже не свободы, а каких-то неформальных митингов, на которых мы могли бы обсудить каким бы продукт мог бы быть. По сути мы инструменты, а CEO нами пилит. Мы сами не участвуем головой в процессе пиления, максимум — можем придумать, как интенсивнее пилить

Проблемы с точки зрения заместителя
Проблемы в проекте
5. Не эффективно проходит планирование. Мне хорошо бы понимать, что планирует делать команда разработки, чтобы планировать финансы, знать что можно обещать командам и т.д.
Узнавать это на сессиях планирования кране неэффективно для меня, так как CEO начинает менеджить команду и всё происходит очень долго
6. Я подстраиваюсь в процессе коммуникации под CEO и ожидаю, что под меня тоже будут подстраиваться (выстраивать индивидуальный интерфейс), пока этого не происходит.
7. Процесс ради процесса Меня несколько напрягали ситуации написания апдейтов в активностях, в которых я принимаю только номинальное участие, сейчас эта ситуация поменялась в лучшую сторону.
8. Создание процесса ради процесса Создание описания бизнес-процесса может тратить больше сил, чем даёт ценности на выходе

Проблемы с точки зрения CEO
Проблемы в проекте
9. Необходимо запускать много исследовательских процессов
10. Очень много ручной работы по настройке, получению данных, ресерчу
11. Понятна только часть пользы, которую мы можем принести, нужен ресерч и кейсы, чтобы увидеть больше пользы
12. Деньги, которые хочется получать, пока больше пользы, которую мы видим что можем оказать.

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

Этап 2.
Собственно в этот момент и вступает в силу простенький фокус, который позволяет сбор жалоб перевести в создание конструктива.
Предложите сотруднику (или себе) переформулировать ту же проблему в формат «Я не». Нужно написать чего не хватает, чтобы желаемое получилось. Обычно сводится к вариантам «Я не имею», «Я не знаю», «Я не умею», «Я не обладаю полномочиями, чтобы», etc.
Критично в этот момент подсказывать возможные варианты максимально тактично. Так что выделяйте на эту процедуру хоть сколько-то вежливых людей, готовых сдерживать язвительность и чёрный юмор. Человеку и так тяжело признать, что от него зависит решение этой проблемы, а если предлагать ему формулировки «Я не умный», «Я не люблю работать» или «Я не там работаю» (это реальный случай), то он просто закроется и ничего полезного вы не узнаете.

Шаг 2.
Если на пункте «Шаг 1» вы записали проблемы своей команды, сейчас самое время попробовать перевести их в формат «Я не».

Неделю назад я получил такие варианты:

Дизайнер
Проблемы в проекте Я не
1. Отсутствие коммуникации внутри команды, изолированность 1а. Во время работы я не обсуждаю дизайн с разработчиками, часто изолируюсь и сам додумываю многие вещи, которые нужно было бы спросить
2. Отсутствие визуализации плана куда движемся 2а. Я не уточняю регулярно куда мы движемся, узнаю это по факту
3. Отсутствие сильного тимлидера у разработчиков 3а. Я не могу быть уверен в адекватном использовании моего дизайна, потому что из-за низкого уровня разработки не отработаны эффективные практики его реализации
4. Мало свободы, быстрый темп, даже не свободы, а каких-то неформальных митингов, на которых мы могли бы обсудить каким бы продукт мог бы быть. По сути мы инструменты, а CEO нами пилит. Мы сами не участвуем головой в процессе пиления, максимум — можем придумать, как интенсивнее пилить 4а. Я не добиваюсь неформального обсуждения по проекту, как это было когда я приезжал в Москву

Заместитель
Проблемы в проекте Я не
5. Не эффективно проходит планирование. Мне хорошо бы понимать, что планирует делать команда разработки, чтобы планировать финансы, знать что можно обещать командам и т.д.
Узнавать это на сессиях планирования кране неэффективно для меня, так как CEO начинает менеджить команду и всё происходит очень долго
5а. Я не могу организовать процесс эффективного информирования меня о планах разработки
6. Я подстраиваюсь в процессе коммуникации под CEO и ожидаю, что под меня тоже будут подстраиваться (выстраивать индивидуальный интерфейс), пока этого не происходит. 6а. Я не могу убедить CEO общаться со мной более эффективно. Слышать меня и понимать
7. Процесс ради процесса Меня несколько напрягали ситуации написания апдейтов в активностях, в которых я принимаю только номинальное участие, сейчас эта ситуация поменялась в лучшую сторону. 7а. Я не считаю необходимым описывать деятельность, которая не приносит ценности другим членам команды
8. Создание процесса ради процесса Создание описания бизнес-процесса может тратить больше сил, чем даёт ценности на выходе 8а. Я не эскалирую и не доношу свое недовольство и не предлагаю альтернативные варианты решения

CEO
Проблемы в проекте Я не
9. Необходимо запускать много исследовательских процессов 9а. Я пока не выстроил понятные процессы для всех 5-6 команд по ресерчу и анализу, как принести больше пользы
10. Очень много ручной работы по настройке, получению данных, ресерчу 10а. Я пока не написал или не придумал кому поставить задачу написать инструкции на все случаи жизни, по настройке, экономике, выводам
11. Понятна только часть пользы, которую мы можем принести, нужен ресерч и кейсы, чтобы увидеть больше пользы 11а. Я пока не додумал и не визуализировал для b2b команд много неочевидных выводов
12. Деньги, которые хочется получать, пока больше пользы, которую мы видим что можем оказать. 10а+11а

Я не буду здесь рассказывать, к каким выводам пришла команда, и что она теперь делает.
Примеры здесь приведены лишь для наглядности.

Что нужно знать вам:
  1. Если проблема в том или ином виде встречается более чем на одном уровне, ею обязательно нужно заниматься.
  2. Если проблема встречается более чем у двух линейных исполнителей, ею обязательно нужно заниматься.
  3. Чем выше уровень исполнителя, который решает проблему, тем быстрее она решится.
  4. Чем ниже уровень исполнителя, выбранного для решения проблемы, тем эффективней и самостоятельней станет сотрудник, которому вы решение проблемы делегируете.


И напоследок две проблемы, которые я встречаю чаще всего:
  1. Я не понимаю, куда сейчас движется наш проект, и как мои действия влияют на него.
  2. Я не могу добиться того, чтобы руководитель услышал мою проблему, а не свою интерпретацию моей проблемы. Меня не понимают, а я не могу объяснить.

Дальше следует анализ и устранение проблем, но об этом в другой раз.
Share post
AdBlock has stolen the banner, but banners are not teeth — they will be back

More
Ads

Comments 12

    0
    Спасибо.
    Люблю хабр за то, что всегда актуально. Как раз сейчас для меня актуально настолько, что актуальнее некуда )
      0
      Писал без иронии. Реально оказалось к месту и полезно.
      Было бы крайне интересно увидеть продолжение — про анализ и устранение проблем.
        0
        Там уж слишком много внутренних секретов будет. Вряд ли они согласятся.

        Можете опубликовать здесь свои «Проблема» — «Я не». Я прокомментирую.
        Ну или кинуть мне в личку ссылку на них, если не для широкого круга информация.
        Два-три кейса до воскресенья я смогу разобрать.
        Потом будет не до того.
      0
      Я не понимаю, куда сейчас движется наш проект, и как мои действия влияют на него

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

      Спасибо за статью.
        +2
        Чего ж приятного?:)

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

        СЕО из примера в статье впал в ступор минуты на две, увидев проблемы с точки зрения дизайнера и своего зама.
        Потом очнулся: «Я же объясняю это каждый вторник по утрам!»
        Штука в том, что «я объясняю» совершенно не равна «все поняли»
        0
        Как-то мало полезного, нет стратегии.
        Часть рассуждений неизбежно придет к «я не ищу новую работу, потому что боюсь потерять старую». Что мне это даст?
        Это про те проблемы, которые действительно не решаются с места (такие тоже бывают, далеко не всё упирается в локальных нехочух).
          0
          Это пока и не стратегическая диагностика.
          Скорее оперативное понимание расхождений во взглядах и целях.
          При некотором преобразовании и стыковке с рынком можно получить из этого что-то про стратегию.
          А можно не получить.

          Я больше скажу, всегда какие-то «Я не» на уровне их владельца не имеют решения.
          Но позволяют понять его видение и подход.

          На проблему «Маленькая зарплата» может быть
          «Я не могу убедить директора платить мне больше»,
          «Я иногда забываю комментировать код».
          «Я не иду на курсы, которые мне частично оплачивает компания»,
          «Я не буду подлизываться к начальству», etc.

          И это довольно много говорит как об авторе, так и о его восприятии компании.

          Диагностика не всегда несёт в себе решение. Иногда это просто сны диагностика.
            0
            Что-то тут не так. Конечно, «мне не повышают зарплату» можно превратить в «я не могу убедить платить мне больше», но это ни к чему не приведёт. И даже не поможет понять проблему, это просто переформулирование (причём далеко не всегда корректное).

            Само собой напрашивается замена этого «я не» на что-то типа «мне надо сделать X».
              0
              Само собой напрашивается замена этого «я не» на что-то типа «мне надо сделать X».

              Это одна из главных проблем, когда вместо диагностики сразу придумывают решение проблемы.
              Сильно мешает и отвлекает от докапывания до сути проблемы.

              Я описал именно хак. С помощью хака можно ускорить какой-то системный процесс, но не заменить его.
              Не ищите в этом методе особой глубины, тут её нет.
              Выигрывая в скорости, мы непременно теряем в точности и глубине.
              Кому-то он подходит, кому-то нет.
              Мне удобно таким образом диагностировать незнакомые команды, и первые шаги после этого получается вполне конструктивными.
              Но это не единственный метод диагностики даже в моём арсенале.
                0
                Тогда разграничьте сферы применения метода.
                Ведь это не диагностика, а игра словами.
                Я с рабочей практики сразу вспоминаю примеры, которые с подходом «я не» просто констатируют несовершенство окружающего мира.
                Получается имитация диагностики вместо нормального анализа и поиска решений.
                  0
                  Вы просто под диагностикой понимаете какую-то свою, глобальную и стратегическую.
                  А я то, что направит меня на верные первые шаги.

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

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