Алексей Кулаков - Бизнес-фэнтези и другие истории

Мне кажется удобным к бизнесу применять игровые термины — сразу многое становится понятным. Я прямо так и думаю про свою компанию: придумываю правила игры, всем их объясняю, и потом мы по ним живем. Есть общие правила, есть правила, которые распространяются на какую-то отдельную профессию внутри компании. Вот пример такой мысли без перевода: «Менеджер выполняет в проекте роль танка — его задача, чтобы дерьмо не долетало до рейда.

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

Я знаю кучу организаций, в которых это выглядит строго наоборот: менеджер работает так, чтобы неприятности за ним разгребала команда, а директор втаптывает менеджера после неудачи, выпивая его ману. Понятно, что хилера не просто нет — в бизнес-сленге даже нет слова для его работы».

После каждой игры я нахожу новые вопросы, на которые мне интересно искать ответы. У нас в сленге есть даже такой термин —

«хороший вопрос». Хороший вопрос — это вопрос, на который ответить очень хочется, но не получается. Например, мой актуальный вопрос: «Почему мне неинтересно делать игры для моих детей?» Я их придумываю, но мне неинтересно. Как только ответ найдется, вопрос перестанет быть хорошим, но можно будет начинать реализовывать найденный ответ.

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

На прошлой неделе на DK.RU вышла колонка генерального директора «АРК Девелопмент» и сервиса по доставке правильного питания UNIKFOOD Никиты Попова, где он рассказал, с какими трудностями столкнулся, когда заказывал сайты для своих компаний. Еще раньше предприниматель Иван Зубарев поделился своей историей, как вложил 1,5 млн руб. в разработку сайта, но в итоге остался ни с чем.

Тема вызвала бурные обсуждения как со стороны предпринимателей, так и со стороны разработчиков. В редакцию DK.RU обратились несколько владельцев компаний по созданию сайтов, которые хотели бы ответить на претензии заказчиков. Приводим мнение двоих из них.

«В МОМЕНТ, КОГДА МЫ ВЗЯЛИ ЗАКАЗ — ОН СТАЛ НАШЕЙ ПРОБЛЕМОЙ»

Алексей Кулаков, генеральный директор JetStyle:

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

Обе позиции представляются мне ошибочными. Я не буду пытаться научить бизнес, как заказывать наши услуги. Это бесполезно. Я расскажу, как, по-моему, должен вести себя менеджер IT-проекта, чтобы у этого самого проекта был шанс состояться. Честно сказать, я думаю, что это не только про IT, а про любую достаточно сложную услугу, в которой есть существенный разрыв в компетенции у заказчика и исполнителя.

ОБЩАЯ ЦЕЛЬ И ОТВЕТСТВЕННОСТЬ

Первое, о чем надо договориться при работе над любым, в том числе IT проектом, — об общей для всех участников цели. Мысль простая: «Прежде чем придумывать ответ на вопрос: «Как будет устроен сайт», надо ответить на вопрос: «А какая от него должна быть польза?»

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

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

Главная ошибка в кейсе, который рассказал Никита Попов, в том, что общение шло про то, как выглядит сайт, а не про то, как он добивается цели. Это, в целом, значит, что менеджмент разработчика не справился со сложным клиентом.

Почти все клиенты, которые к нам приходят, на входе формулируют задание на сайт в терминах фич и хотелок. В этот момент менеджмент разработчика должен переформулировать фичи в цели. Если они не справляются, происходит потеря управления проектом. Отсюда следуют разговоры в терминах «нравится/не нравится», «объяснение профессионалам, как делать их работу» и дальше по списку.

В момент, когда мы взяли заказ — он стал нашей проблемой. Если мы взяли ответственность не в терминах цели, а в форме хотелок, то мы попали. Проект продан неправильно.

ВЗАИМНОЕ УВАЖЕНИЕ

Мы уважаем клиента за то, что он делает бизнес. Ровно такого же уважения мы должны требовать к себе: нам платят деньги за то, что у нас есть экстра-компетенция в управлении проектами, проектировании пользовательского опыта, разработке программного обеспечения.

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

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

И да, удержание рамок — это наша ответственность. Заказчик не обязан быть компетентным IT-менеджером. Но, если мы не можем сделать так, чтобы заказчик доверял нам принятие решений в нашей сфере компетенции, за проект браться нельзя.

Все это внутри JetStyle называется «Принцип мудака Шредингера»и значит следующее: только мы сами можем превратить клиента в мудака. Не бывает плохих клиентов, бывает потеря управления. Уважайте клиента, относитесь к нему по-человечески и вовремя говорите «Нет». Тогда и клиент будет нас уважать.