У многих компаний два основателя

У многих компаний два основателя

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

Сейчас у Nimax целая команда руководителей, каждый из которых партнер в своем подразделении. Но долгое время мы с Максимом управляли компанией вдвоем. Более того, мы еще и учились в школе, а затем в институте вместе. А сейчас живем в одном доме и дружим семьями. В общем, мне есть что рассказать про взаимоотношения партнеров в проекте.

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

Еще у меня накопился целый список других проблем, которые мы когда-либо обсуждали с коллегами из других компаний:

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

Знакомо? Ну да, проблемы у всех одинаковые 🙁
Можем разобрать некоторые из этих ситуаций — напишите какие.

А пока я хочу обратить твоё внимание на парадокс

А пока я хочу обратить твоё внимание на парадокс

1. Ты часто делаешь работу не к сроку, я бы сказал систематически (ровно так же, как это делают 100% известных мне творческих специалистов).

2. Но всякий раз считаешь это случайностью и объясняешь внешними причинами.

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

Я читал об этом в книге Канемана.

Если коротко: «обычный» человек переоценивает потери и недооценивает выигрыш. Если «обычному человеку» предложить сыграть в игру с подбрасыванием монетки, где «орёл это получить 1200₽, а решка это отдать своих 1000₽», он не согласится, хотя математическое ожидание — положительное. Это «страх потери», который добавляет негативному сценарию дополнительный вес. У «обычного человека» равновесие достигается примерно в точке «выиграть 1500₽ или проиграть 1000₽».

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

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

Как же быть?

Понимать, с кем имеешь дело.

— Если имеешь дело с такими же предпринимателими, творцами и специалистами по неопределённости, то расслабиться, принять своё «несовершенство», делить с ними ответственность, давать больше обещаний про процесс и меньше про результат.

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

С вялым заказчиком каши не сваришь

Иногда пишу зарисовки из проектной деятельности. Вот и сегодня такая зарисовка.

Более-менее крупный проект может заглохнуть, если на стороне заказчика не будет команды. 

Если вам говорят: "С вами будет работать Ира, она в курсе всех процессов, а если надо – будет привлекать ещё кого-то!", то есть повод насторожиться. У заказчика должна быть команда, в которой Ира руководитель проекта, тогда норм.

Из жизни. На заре моего проектного менеджмента (в 2008-2009 году) у меня был проект внедрения системы автоматизации в транспортно-логистической компании. 

Большой проект, большое ТЗ. И один человек на стороне заказчика, который "активно" занимается проектом.

Этот один человек всегда загружен (работу же работать надо), поэтому обратная связь по релизам/вопросам идёт с задержками.

Нас, как исполнителя, никто не "трясёт" – сами тянут. В итоге проект скатывается в вялотекущий: у исполнителя нет тонуса, представитель заказчика не успевает, срок сдачи сдвигается и никого это не пугает (обоснованно же).

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

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

Заказчика в тонусе держать надо, а то на шею сядете и соскользнёте с неё очень быстро.

Про изучение пользователей

230 млн лет назад (230! млн. лет назад) по Земле ходили Герреразавры — картинка внизу поста.
Это были относительно легкие двуногие хищные динозавры. У них был длинный хвост и довольно маленькая голова. Длина тела примерно 6 метров, а весили порядка 650 кг.

Строение их тела говорит о том, что они довольно быстро бегали. Стопа герреразавров имела пять пальцев, однако полностью развиты были только три средних (II, III и IV). Два остальных (I и V) не несли на себе нагрузку от тела — они были сбоку и имели только коготь. Хвост был укреплен отростками позвонков и играл роль балансира при ходьбе и беге. На первых трёх пальцах передних лап были крупные загнутые когти ими герреразавры хватали и удерживали добычу. Догнал, схватил и съел.

О зверюге, которая жила на Земле 230 миллионов лет назад (аж в голове не укладывается цифра), известно больше, чем многим известно о пользователях, для которых создаётся продукт. Если вы не знаете досконально проблемы или мотивации пользователя, то создать классный продукт меньше шансов. Зачастую команда фокусируется на дизайне и функциях, которые в дальнейшем оказываются абсолютно бесполезными.
Если делать продукты для физлиц, то там вероятность "попасть" в потребность выше, так как команда ближе к проблемам физлиц — сами же люди.
Если делать продукты для бизнеса или государства — то лучшие продукты получаются, как правило, у тех, кто либо сам в этом же бизнесе поработал, либо много времени провёл внутри бизнеса, изучая процессы.

В 2015 году, работая в заказной разработке, я был в составе большой группы, которая делала продукт регионального уровня: муниципальные услуги, сервисы для жителей, мониторинг инвестиционных проектов.
И вот мы пошли на приём к мэру одного из региональных городов — приветливый и умный дядька.
Начали обсуждать сервисы для жителей. Один из сервисов был про активных горожан — отметил место на карте, приложил фотку и отписал, что не так. Все видят, голосуют за самые острые дела, а власть расторопно всё исправляет. У жителей, вероятно спрос был бы, если бы власть реагировала на запросы. Но на деле схема оказалась неработоспособной для небогатых городов (а это почти все). Приветливый и умный дядька нам сказал: "Мы уже знаем о таком количестве проблем, на которые не хватает городского бюджета. Зачем же мы будем давать людям ложную надежду и собирать их ещё больше — мы можем реагировать только на самые острые проблемы". Сервис не зашёл.

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

Идеальный процесс

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

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

Женя Бондарев рассказал нам о типичной структуре разработки цифрового продукта:

Погружение
Сбор информации, поиск вдохновения, анализ и инсайты.
Женя дал очень хорошее определение того, что такое инсайт:
Инсайт — это глубинная потребность человека в чем-либо. Обязательные элементы инсайта — мотив и барьер: я хочу делать то и то — мотив; но не делаю это потому что — барьер.
Наша задача, как дизайнера, в том, чтобы узнать конкретную причину этого барьера.

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

Usability test
Тестирование всего продукта и финальные изменения — Женя советует писать гипотезы в гугл-доке на протяжении всего исследования, чтобы во время тестирования не упустить что-то важное.
По итогу тестирования выявляются критичные и не очень ошибки, после чего нужно решить, с чем можно выходить на рынок, а что требует обязательной доработки. На этом шаге может всплыть много неожиданностей, на эту тему как-то писал Костя Горский — t.me/desprod/239

Финализация
Финальное утверждение, подготовка к разработке, подготовка к публикации (кейс в медиа, либо конкурс и т.д.), авторский надзор.
Круто выпускать MVP как можно раньше, чтобы начать получать реальный фидбэк.

После лекции Женя попросил нас расписать подобный план для своих проектов, где мы должны были указать основные чек-поинты, время, роли и артефакты.
Я немного упростил наш план, так как в оригинале он выглядел ещё больше:

1. Погружение

1. Связаться с заказчиком
Сделать:
- интервью с заказчиком
- запросить метрики
Итог:
- утвержденное направление работу
- утвержденные с заказчиком сроки
Срок: 4.03

2. Поиск референсов/конкурентов
Срок: 04.03

3. Интервью с пользователями
Сделать:
-подготовить вопросы
-найти респондентов
На выходе:
- уточненный портрет
- проблемы пользователей
Срок: 13.03

4. Попробовать
Сделать:
- Сделать заказ (понять процесс, опросить мастера)
- Зарегаться как мастер (понят, процесс, взять заказ)
На выходе:
- проблемы
- полное понимание бизнес-процесса
Срок: 11.03

Анализ полученных инсайтов
Артефакты: понять на каких проблемах фокусируемся, список инсайтов, фичерлист
Показываем заказчику — 12.03
— Ретро —


2. UX — проектирование

1. Информационная архитектура — 20.03
2. Структура — 20.03
3. Карта экранов — 31.03
4. Сценарии
5. Прототип
6. Тестирование прототипа (проверка гипотез) - 7.04

Анализ полученных решений
Артефакты: протестированный прототип, карта экранов, структура, информационная архитектура
Показываем заказчику — 9.04

— Ретро —


3. UI — визуальный язык

1. Существующие гайды продукта
2. Мудборд
3. Дизайн концепт 3-5 экранов — 14.04
4. Масштабирование
5. Анимация

Анализ полученных решений
Артефакты: финальный дизайн продукта, анимация
Показываем заказчику — 30.04

— Ретро —


4. Передача в разработку
5 занятий 10.05-19.05

5. Подготовка портфолио
9 занятий 22.05-09.06

6. Презентация
3 занятия

7. Защита
23 июня


По сути, этот план также может являться оглавлением моего дальнейшего повествования.
Как вы могли заметить, на сегодняшний момент мы заканчиваем стадию «2. UX — проектирование» и переходим к поиску визуальной концепции.
Уже сейчас можно сделать какие-то выводы о том, как мы двигаемся по этому плану: что-то из написанного в плане мы так и не сделали до сих пор, что-то наоборот — сделали с опережением. Так, мы до сих пор не утвердили окончательный набор фич, но, с другой стороны, у нас уже готовы все необходимые артефакты — можно начинать готовить мудборды