Наверх ▲

Особенности рисков веб-проектов

Михаил Зоненашвили Михаил Зоненашвили Владелец компании «613», экс-CEO Top4Top.ru.

Михаил Зоненашвили: Меня зовут Михаил Зоненашвили. Начиная с окончания процесса под названием "Создание TVC на отечественной элементной базе", я занимался менеджментом. Это было в "сильно лохматые" годы. Чем только я, по большому счету, в своей жизни ни занимался. Кинопроизводством. Умудрялся в один строго назначенный день, который перенести нельзя, собрать порядка двухсот компаний, людей и всего остального в одно место, в один час. Вы знаете, получалось иногда. Занимался телепроизводством, телевидением, всем чем угодно и так далее. Радио, газетами, журналами. В итоге где-то аж в 2007-м году все-таки, так получилось, я занялся интернетом.

Предыдущий опыт менеджмента меня все время учил одной простой вещи. Что было связано с кино, телевидением, газетами, журналами, со всеми остальными. Если есть "deadline", то все равно все произойдет и случится. Телепрограмма выйдет, съемочный день пройдет. Его перенести нельзя, и поэтому все будут работать на этом. Эта установка, учитывая, что она была многолетняя, как-то закрепилась в моем мозгу.

В 2007-м году я понял, что это абсолютно не так. Все, что связано с интернет-проектами, в этом ключе не работает вообще. У вас могут быть замечательные сроки, "deadline", который не откладывается ни по каким условиям. Но ничего не произойдет. Я считаю, что это один из самых сложных рисков, который когда-либо существовал в любом бизнесе оффлайновом.

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

История следующая. Был проект в свое время, который вы, наверное, много раз слышали. Это был замечательный проект под названием "Top4Top", который надо было сделать, по телевизионной модели, за три месяца. "Deadline" был. Хочешь, не хочешь, оно должно случиться. Оно случилось. Не будем говорить, почему оно не случилось как проект. Это уже отдельная история и отдельная лекция. Здесь уже не в этом вопрос.

В реальности те риски, которые действительно возникли, именно особенности, которые есть у веб-проектов, я испытал на собственной шкуре первый раз. Придя причем в веб-проекты как опытный человек, уже с большим "background", знанием управления людьми, создания команд. Всю жизнь занимался стартапами, но не в веб-проектах. Любое кинопроизводство, съемки рекламного ролика – по большому счету, это стартап. Но там есть один плюс – четко отлаженные технологии. Здесь, казалось бы, они тоже есть, но, увы, не так.

С чем я столкнулся. Самая главная проблема, которая есть у любого веб-проекта – это люди. Это самый страшный риск. В любом бизнесе, который существовал, всегда есть некое сочетание "пряников" и "кнута". Как любит говорить Герман Клименко, розги и православие спасут. В данном случае здесь это сочетание, к сожалению, не работает. Работают только "пряники".

При создании сложного веб-проекта… Я не говорю о проектах, где есть клон, повторение, переписывание или адаптация уже существующего CMS-движка. Я говорю именно об оригинальном продукте, абсолютно уникальном, который никогда не существовал, и клонировать его неоткуда.

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

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

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

(Демонстрация слайда).

Точно также можно: люди у вас работают, что-то сделали. Не получилось в сроки, не успеваете вы к "deadline"– надо взять других, вот и все. Все, казалось бы, проще. Вся оффлайновая экономика работает, кстати, по этому принципу. Нет в этом никакой проблемы. Но здесь нет такого решения, как метро. Проблема в этом.

У вас оригинальный продукт. Заменив тех людей, кто с вами работает, вы будете вынуждены все делать заново. Вы откатитесь в точку начала старта вашего проекта. Это неизбежная вещь. Главное, что решения у этой задачи практически нет. Вам всегда будут рассказывать о том, что оно есть. Что мы сделали такой код, что любой человек будет каждый раз продолжать адаптироваться, и все будет хорошо. В реальности никогда этому не верьте. С опытом вы поймете, что это не случится.

Кстати, я не задал вопрос. С залом хотел бы познакомиться. Можно узнать, кто разработчики, а кто именно носители продукта? Кто разработчики, поднимите руки. А кто – с продуктом? Это будет славная охота. (Смеется).

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

Люди у вас могут быть мотивированы… Кроме денег, конечно. Про деньги мы не забываем. Про это вам не дадут забыть сами участники процесса. У вас есть интерес к идее, проекту, чему-то еще. Честно скажу. Месяца через три он в любом случае ослабевает. Хорошая кормежка в офисе…

Условно говоря, как сейчас в "Facebook". Я недавно комментировал. Мне задавали из "Голоса России" вопрос: "Как вы относитесь к тому, что часть сотрудников "Facebook" решили себе сделать не сидячие, а стоячие столы?". Может быть, это тоже некая мотивация сотрудников. Но – хрен его знает. Оно, может быть, и хорошо. Но не универсальное решение. Кому-то – да, кому-то – нет.

Все жертвоприношения, которые вы приносите – вы понимаете, что оно может случиться, может, нет. Может, дождь пойдет, может, нет. Вы можете приносить эти жертвоприношения, можете не приносить. Тогда, если вы не приносите этого, что у вас варианта нет.

Здесь вспоминается хорошая старая история про молодую девушку (старый-старый "бородатый" анекдот), пришедшую к раввину с вопросом, в чем ей все-таки предстать в первую брачную ночь. Раввин ей довольно просто ответил с вопросом, что, в общем, неважно, в чем вы будете. Дальше я продолжать эту историю не буду. Многие, наверное, знают этот анекдот.

 (Демонстрация слайда).

Фактически здесь происходит следующая вещь. Чтобы мы ни хотели, если у вас есть оригинальный продукт, то шансов у вас практически никаких. На "грабли" вы уже наступили. Проблема, которую вам придется решать, будет решаться долго, упорно, мучительно, каждый раз по-новому. Готового заранее решения нет и быть не может. Пятачок так спешил, так спешил, что иногда даже просто…

Последние несколько лет у меня ритм жизни абсолютно ночной, как у совы или кошки. Мои разработчики находятся по ту сторону океана. Общение с ними по "Skype" и переписка начинается ориентировочно с двух и заканчивается в пять утра. Поэтому для меня появление где-либо на людях раньше часа-двух дня – это вещь практически невозможная. Эта миссия практически невыполнима.

Вы всегда имеете проблему с наступлением на "грабли". Каждый раз, приступая к новому продукту, вы понимаете, что надежда у вас есть – а вдруг получится что-нибудь иначе. Нет. Всегда будет одно и то же. Проблема – в следующем. Вы можете "выращивать" команду, которая у вас будет переходить от проекта к проекту. Можете ее мотивировать. Она может быть вам предана достаточно.

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

В реальности, как у любого управленца, встает простейший вопрос – что делать. Надо свою команду иметь и самому ею управлять, или отдать на аутсорсинг какой-нибудь замечательной компании на рынке. Когда у вас возникают проблемы с продуктом, к вам обязательно придут и скажут: "Хм, старик. Что ж ты ерундой-то занимаешься. Пришел бы к нам в компанию. Мы бы тебе все за раз сделали".

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

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

 (Демонстрация слайда).

Я нарисовал так пафосно, с этой пирамидой. Мои рассуждения и разговоры относятся исключительно к тому случаю, когда вы создаете оригинальный продукт. Если вы берете некий клон какого-то известного ресурса и пытаетесь его повторить – эти схемы не работают. Они тут не нужны. Они даже вредны. Там совершенно другая логика. Здесь происходит создание именно продукта.

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

В результате ваши интересы с вашей же командой расходятся. Там можно много говорить, что команды общее видение, результаты, KPI. Ребята, "bullshit", вот что я вам скажу. Когда доходит до дела, за продукт отвечаете вы как руководитель продукта. Когда доходит до разработки, то каждый перекладывает маленький кусочек: "Вот я свою долянку хорошо сделал".

У Кеннеди была замечательная фраза: "У победы, как минимум, тысяча отцов. А поражение – практически сирота" (боюсь за дословность).

История следующая. У вас возникает этот простейший конфликт. Вам надо провести. Что вам надо сделать. Системы демократии в этой истории не работает. Система деспотизма и тирании не работает совсем, потому что вы имеете дело с мозговой деятельностью. Прекрасно работает система тирании на заводе. Прекрасно работать с гастарбайтерами по строительству загородного дома: отнял паспорт, и все – будут работать как миленькие. Главное – денег не платить. Потом, как заплатил деньги – сразу в вагоны, и обратно, на родину.

Не работает. Что делать? Единственное, что работает – это некая селективным образом созданная команда по правильному принципу с теми конфликтами, которые есть. С попыткой справиться с этим конфликтом (но об этом я чуть попозже поговорю).

 (Демонстрация слайда).

Итак, у вас есть продукт. Что вам надо сделать. Вопрос компании, которая может решить эту задачу за вас, уже не стоит. Я прошел этот путь тоже, честно вам скажу. Большинство из того, что я вам говорю – это не умозрительно, а на собственной шкуре испытано.

Вы приходите к замечательной компании, у которой есть гениальный гуру, которого все нежно любят, уважают, ценят. Вы ему говорите: "Гуру. Мне надо решить вот эту задачу". Гуру говорит: "Да не вопрос. Мы тебе сейчас ее решим. Значит, так. Ты пишешь техническое задание для этого, этого". Ты пишешь, месяца два вы с ним согласовываете видение проекта, что, как должно быть (что, кстати, очень полезно для вас, носителя продукта – вы хотя бы структурируете все мысли, которые у вас накопились). После этого вы приносите это гуру. Гуру смотрит на это, говорит: "Да, этого достаточно".

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

Дальше у вас происходит такая вещь. Этот человек вам всегда будет продавать готовое решение, которое есть у этой компании. Им невыгодно создавать новое решение, потому что это дополнительные людские затраты. А, извините, эта компания – не "Красный Крест" и даже не "полумесяц". Она создана для извлечения денег и прибыли. Поэтому они вам будут "впаривать" замечательнейшие решения.

Совсем недавно, буквально месяц назад, одна достаточно известная компания одному очень известному медийному лицу у меня на глазах "впаривала" так медийный сайт. Сайт был где-то на уровне разработки года, наверное, 2001-го. Медийное лицо было в восторге, подпрыгивало и вырывало волосы у себя на голове абсолютно от счастья, что, наконец, это счастье случилось. Я с ужасом смотрел на то, что это, на самом деле, не соответствует сегодня ничему. Ребята продали. Они сделали хорошую сделку.

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

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

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

Тогда у вас возникает вопрос – штатная команда. Ее далеко не каждый может позволить. Возникает другая проблема. Сегодня у вас есть задача для этой штатной команды, а завтра ее нет. У людей, которые сидят и "прокисают" без дела, никаких особо больших интересов и мотивации после этого не вырастает.

Поэтому приходится выбирать худшее решение из двух плохих. Третьего нет. Штатная команда может быть персонал полностью у вас работающий. Она может быть фрилансеры, которые с вами работают, и так далее. Может быть.

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

(Демонстрация слайда).

Вы выбираете фрилансеров, штатников. Сложно подсказать в процессе девелопмента продукта, что именно лучше. Шансы – 50 на 50. Чет – нечет. Нет ни одного аргумента против.

Есть единственный аргумент, который бы работал за штатную команду, только в одном случае – если продукт у вас уже готов, и вам надо его поддерживать. Если у вас идет процесс поддержки продукта, то тогда 100% однозначно штатная команда. Других вариантов нет, потому что вам не нужен дополнительный риск. У вас и так есть риски, когда у вас есть пользователь на другом конце, у вас происходит "diploy", и может быть, ночью сегодня там не произошло "обвала", а, может быть, произошло. С фрилансерами это будет значительно сложнее делать.

 (Демонстрация слайда).

Теперь давайте посмотрим на следующую вещь (о которой я говорил) – это конфликт, который вы создаете. Конфликт создается изначально одной очень простой вещью.

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

(Демонстрация слайда).

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

Ведь самое страшное еще что. Когда вы делаете продукт, вы же не можете позволить себе, что "хвост рулит собакой". Вы понимаете, что этот путь был ошибочным. Вам, на самом деле, надо людям сказать: "Ребята. То, что вы сделали, нам придется сейчас выкинуть в корзину". Это один из страшных конфликтов, мимо которого, естественным образом, вы не пройдете. Если вы проходите мимо этого конфликта – либо вы гений, который умеет просчитывать на 30 ходов вперед (что практически редко дается живым людям, значит, вы не живой, вы – робот), либо вы "забили" на продукт и "слили" его.

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

Проблема – в следующем. Обычно бывает так, что первые проблемы возникают на втором-третьем месяце совместной работы. Если люди уже работали достаточно долго, это может произойти после какого-то очередного "update" или переделки, которая, по вашему мнению, необходима. Если вы начнете людям говорить замечательные вещи: "Как вы думаете?", "Хорошо было бы…", "А, может быть…", "Вы не согласились бы пойти в атаку?".

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

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

Процесс бюрократии – это процесс ингибиции. Это ингибиторы. Если мы вернемся к математике и теории игр, и, соответственно, конфликтологии как одного из подразделов этой науки, то она утверждает, что, первое, конфликтом управлять нельзя. Вторая вещь, которая очень важна – конфликт исчерпывается только в тот момент, когда один из субъектов конфликта исчезает с "доски". Все остальные варианты являются промежуточными.

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

Единственное решение, которое для этого я на сегодняшний день нашел – это человек, который в реальности является "прокладкой" между носителем продукта и исполнителями. В реальности этого человека чаще всего называют и берут в качестве CTO. Он прекрасно коммуницирует с командой. Он не пишет код за команду, надо это прекрасно понимать. Он занимается именно этой функцией. Она самая главная для него, и та, которую вы возлагаете.

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

(Демонстрация слайда).

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

Победить – это означает сделать продукт, не "слить" его. Пойдете на пути у команды – вы "сольете" продукт. Он потом уже никому не будет нужен. Это самая важная вещь и составляющая.

Здесь, наверное, я закончу. Если есть вопросы, я готов отвечать вам практически на все.

 

Вопросы и ответы

Реплика из зала: (Неразборчиво) внешняя команда и собственная команда…

Михаил Зоненашвили: Которому?

Реплика из зала: То, что касается разработки – все понятно.

Михаил Зоненашвили: Вот эта?

Реплика из зала: Да. (Неразборчиво, 30:25) за вами и зависит от самого продукта. Что же касается (неразборчиво, 30:30) команд – UI или тестирования?

Михаил Зоненашвили: Тестирование – это было бы хорошо.

Реплика из зала: (Неразборчиво, тихо, 30:39). UI самое интересное.

Михаил Зоненашвили: Я с вами согласен. Если у вас действительно сложный продукт, то эти вещи вам лучше, конечно, в аутсорс, 100%. Это проверка вашего продукта. Если она будет внутри вас – это хорошо до момента старта. Можно там ловить какие-то баги, ошибки и все остальное.

А если вы начинаете со сложным продуктом выходить, держать внутри себя достаточно большое количество этих тестировщиков (а их нужно довольно много)… В том числе очень часто бывают нужны даже в жизни хакеры для того, чтобы проверить уязвимые участки вашего проекта. Что, вы будете держать у себя в штате хакеров? Это, конечно, лучше переводит в аутсорс. Но это вспомогательные функции. Я имею в виду – действительно только разработка. Вы здесь абсолютно правы. Здесь не стоит ходить в эту сторону.

Реплика из зала: Я правильно понимаю, что вы предлагаете вводить посредника, "прокладку", которую вы поменяете в следующем продукте?

Михаил Зоненашвили: Необязательно.

Реплика из зала: Если конфликта не будет, не поменяете?

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

Реплика из зала: Чтобы не получить риск потери команды?

Михаил Зоненашвили: Да. У вас в голове продукт. У вас есть интересы продукта. Для вас как руководителя они первичны. Для них интересы первичные, на самом деле, немножечко иные. Вам все скажут: "Замечательно. Мы – за Советскую власть. Мы тоже за продукт". В реальности – другие.

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

Я не говорю о том, что java-скриптер или верстальщик должен быть дилетантом. Это ужасно. Это лучше сразу застрелиться. Но дизайнер и интерфейщик могут быть во многом дилетантами. Доля дилетантизма у них должна быть достаточно высока. Иначе стереотипы мышления и готовые решения, которые они готовы сейчас выложить и сделать ("а вот это мы сделаем вот так"), вы получите опять очередной П-44 дом, строение и так далее. Пожалуй, наверное, так.

Реплика из зала: Какое количество человек в команде должно быть, чтобы вводить этого человека?

Михаил Зоненашвили: Это как раз самая большая проблема. Если у вас продукт не такой масштабный, и вам нужно в реальности один "back-end", один человек на "back-end", один – на "front-end", java-скриптер плюс верстальщик. Здесь еще вводить четвертую сущность реально "жаба душит", реально.

Реплика из зала: Это вообще оправданно?

Михаил Зоненашвили: Экономически – нет. С точки зрения, если вы с командой проработали достаточно давно и не хотите ее потерять из-за конфликта этого проекта – то да. Это не оправдано в краткосрочной перспективе. Это оправдано в долгосрочной перспективе, если вам с этой командой дальше нужно работать.

Реплика из зала: (Неразборчиво, 34:37) какая?

Михаил Зоненашвили: Он должен быть привязан к успеху проекта четко. Он обслуживает обе стороны. Его интересы и экспертиза, все его "skillz" находятся на уровне команды. Но, с другой стороны, он должен быть на вашей стороне с точки зрения мотивации от продукта. Результат продукта хороший, значит, у тебя… Только так. К сожалению, другого варианта…

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

Я не зря рассказывал эту притчу про чудовище и жертвоприношение. Если вы задумаетесь, то любое решение, что "ты нам не сделал вовремя код, мы тебя сейчас уволим" – не работает. Вы сами себе "злобный Буратино" в этой истории. Вы отодвинули сами же сроки. Это означает, что вы довели ситуацию до определенного конфликта.

Да, у него могли быть мотивации совершенно… Он не написал коды или скрипты, потому что его девушка бросила, еще что-то случилось, и вообще у него настроения не было код писать. Но если вы будете непосредственно как лидер продукта с ним коммуницировать на эту тему, единственное, до чего вы доведете – это расставание. Расставание означает переписывание его кода заново.

Реплика из зала: Почему он тогда не станет в ваш лагерь? Если я – держатель продукта, у меня одни интересы, у них – другие. Если я его мотивирую на результат, он, в принципе, становится (неразборчиво, 36:39).

Михаил Зоненашвили: Да ничего подобного. Здесь проблема – в сроках. На первые три месяца это работает. Это не работает потом, потому что вы как носитель продукта мысленно согласны, что у вас результат в лучшем случае – через год-полтора. Вы с этим идете на эту задачу. Большинство людей, с которыми вы работаете, любят получать краткосрочные. У него краткосрочные перспективы. Ничего с этим не поделать. Это еще один очень важный конфликт, который порождается именно временем.

Вы можете как угодно людям говорить, что это счастливое будущее будет впереди за горизонтом. Оно все замечательно. Ребята. Полгода – максимум, что вы можете сделать, так держать команду. Когда успех у продукта случится – все придут, поверьте. Это неизбежно. Все вспомнят и скажут, что все замечательно. Начнется новый проект – у вас будут те же самые проблемы.

Реплика из зала: (Неразборчиво, 37:51) CTO растить или нанимать?

Михаил Зоненашвили: (Смеется). Подбирать, я бы так сказать. Здесь эволюционная история. Здесь нельзя сказать, что вот этот человек "пойдет". Скажите, как – жену надо себе растить или просто найти в метро? Вы же не знаете ответ на этот вопрос.

Реплика из зала: Растить, конечно.

Михаил Зоненашвили: Ты знаешь. Но я не знаю.

Реплика из зала: Вырастил, значит.

Михаил Зоненашвили: Думает, что вырастил. (Смех).

Реплика из зала: (Неразборчиво, тихо, 38:28).

Михаил Зоненашвили: Ребята. Нет ответа на этот вопрос однозначного. Сказать, что так и никак иначе.

Реплика из зала: В вашем опыте как было?

Михаил Зоненашвили: В моем опыте это случайная встреча, которая переросла в некое состояние биохимии между мной и им. Мы понимаем друг друга с полуслова. Он может объяснить людям и прекрасным образом самортизировать происходящее. Я честно вам скажу. Сегодня у меня была такая идея. Я говорю, что надо сделать вот так. Проходит месяц, я понимаю, что тупик. Если я приду к команде и скажу: "Ребята, надо" – они меня, знаете, куда пошлют.

Реплика из зала: Знаю.

Михаил Зоненашвили: Скажите, пожалуйста. Я могу слить продукт? Я не могу себе этого позволить. Это моя компетенция, профессиональный "skillz". Это мое основное. Я должен продукт довести, сделать так, как я считаю его нужным, потому что за него отвечаю. В этом-то и проблема.

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

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

Если вы начнете ставить всюду "Google Translate", то у вас будут проблемы. Это неизбежно. Вы будете думать, что вам не так сказали, там будут думать, что вы не так сказали, и так далее. Это бесконечная история. Идеального нет. Может быть, растить. Может быть, найти. Но этот человек должен быть вместе с вами. Это ваша "правая рука". Ничего больше сказать не могу. Нет универсального решения. Спасибо.

(Аплодисменты).

Комментарии

Нет ни одного комментария

Только пользователи могут оставлять комментарии

Возможно, вам будет интересно:

Станислав Лагун

Станислав Лагун

Senior Software Developer, Mirantis Inc.

Евгений Кирпичев и Станислав Лагун (Mirantis) делятся опытом построения высоконагруженного кластера с использованием RabbitMQ.

Алексей Полковников

Алексей Полковников

Президент ассоциации управления проектами СОВНЕТ (представитель России в IPMA), генеральный директор и управляющий партнер ГК «Проектная ПРАКТИКА»

Рассказ, в первую очередь, о существующей сертификации в области профессионального проектного менеджмента.

Ярослав Сергеев

Ярослав Сергеев

Исполнительный директор компании Wamba, ранее - php-разработчик, архитектор, тимлид, IT-директор и, наконец, CEO. Знает Wamba, как никто другой (речь идёт как о технической стороне проекта, так и о команде сотрудников).

Рассказ о проекте Mamba и "граблях", на которые наступала команда по мере его роста.