Диагностика проблем в команде за четыре часа на примере живого стартапа
Самая частая из проблем, с которыми я встречаюсь в проектах, — что менять в первую очередь, на чём фокусироваться. «Как» все знают или считают что знают. У меня припасено несколько хаков, которые позволяют за полдня провести первичный анализ, выявляющий точки фокуса.
В этот раз я хочу поделиться одним из них, на примере работы с командой одного успешного стартапа на прошлой неделе. Конкретная сфера деятельности проекта не имеет принципиального значения. Упомяну лишь, что они используют Scrum и, по мнению руководителя, «некоторые проблемы он всё равно не выявляет». Я, кстати, искренне считаю, что не существует ни одной универсальной методики, охватывающей все уровни управления. Максимально эффективно знание и применение хотя бы двух-трёх разноплановых.Существует видение проблем на уровне первого лица, среднего менеджмента и линейных исполнителей. Моё мнение — самые важные проблемы выясняются на нижнем уровне, но эффективно решаются только через анализ их влияния на весь проект. Это главная проблема общения программиста или дизайнера с CEO. Последний часто понимает в чём загвоздка, но воспринимает это как боль конкретного сотрудника, не считая что она глобально влияет на весь процесс.
Собственно метод.Этап 1. Запишите восемь проблем в проекте, которые мешают вашей работе и сильнее всего цепляют вас эмоционально. Не ищите самое глобальное, не думайте за других, напишите о том, что раздражает именно вас. Единственное ограничение — проблема должна повторяться хотя бы несколько раз.Шаг 1. Если вы хотите опробовать метод на себе, запишите эти проблемы сейчас, не читая дальнейших спойлеров.Я буду приводить примеры такой диагностике на примере трёх членов реальной команды:
Дизайнер Заместитель генерального. 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а Я не буду здесь рассказывать, к каким выводам пришла команда, и что она теперь делает.Примеры здесь приведены лишь для наглядности.Что нужно знать вам:
Если проблема в том или ином виде встречается более чем на одном уровне, ею обязательно нужно заниматься. Если проблема встречается более чем у двух линейных исполнителей, ею обязательно нужно заниматься. Чем выше уровень исполнителя, который решает проблему, тем быстрее она решится. Чем ниже уровень исполнителя, выбранного для решения проблемы, тем эффективней и самостоятельней станет сотрудник, которому вы решение проблемы делегируете. И напоследок две проблемы, которые я встречаю чаще всего:
Я не понимаю, куда сейчас движется наш проект, и как мои действия влияют на него. Я не могу добиться того, чтобы руководитель услышал мою проблему, а не свою интерпретацию моей проблемы. Меня не понимают, а я не могу объяснить. Дальше следует анализ и устранение проблем, но об этом в другой раз.
