Андраш Густи: Женя затронул очень хорошую тему. Я имею в виду вопрос сложности проектов. Мы здесь можем сравнивать, у кого какой продукт круче, а можем поговорить о наших насущных проблемах, которые у нас были в этом году либо предвидятся.

Давайте я начну. Что было сложного у нас? Как сказал Женя, была большая проблема с тем, что замораживались проекты, что-то происходило с генеральными директорами (от «уехал в отпуск» до чего-то, видимо, очень плохого)… Такие случаи были, и заканчивалось все разрывом договора или безумной рассрочкой по платежам, что, конечно же, очень сильно бьет по работе любой студии. Естественно, как и все, в тот момент мы активизировались на Запад (что всем и советую).

Буквально недавно мы с Димой обсуждали сложности работы с Западом, то есть не все то, что привычно здесь, работает там. У нас есть клиенты из США, которые привыкли мало платить, привыкли работать с дешевым сегментом разработки внутри Штатов, которые тоже дешевые. Там есть ребята, которые берут по 20-30 долларов за час и сильно портят жизнь таким разработчикам, как мы, потому что нам, разумеется, хотелось бы больше, но мы далеко, и поэтому не совсем понятно, зачем платить именно нам. То есть имеем перенасыщенный рынок США, и есть также Европа, в которую очень сложно пробиться, если ты уже не там, – если у тебя нет офиса, нет контактов. Это также проблема, но как-то мы с ней справляемся.

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

Евгений Круглов: Возможно, кто-то из вас помнит, что в начале года я выступил на посиделках в коворкинге #tceh. У меня был небольшой доклад по поводу того, что нас ждет в 2015 году. Я тогда сделал несколько прогнозов, и сейчас самое время посмотреть на них и сделать какие-то выводы. Прогнозы были очень простые. Я говорил, что у больших компаний все будет хорошо, и ничего серьезного у них не случится. Возможно, такие компании столкнутся с какими-то вопросами по оптимизации, но большая часть из них работает с крупными клиентами, которые не будут останавливать разработку. И поэтому переживать им не стоит, просто стоит быть аккуратными и бдительными.
Компании среднего звена, скорее всего, тоже переживут этот год более-менее хорошо. Возможно, у кого-то будут проблемы, у кого-то – нет (зависит от того, какого рода клиенты, и насколько долгосрочные контракты у них). Вопрос оптимизации для них будет стоять острее, потому что, скорее всего, уровень маржинальности у них ниже, чем у больших компаний, но каких-то существенных проблем удастся избежать, если они будут вести себя адекватно ситуации на рынке.

Основные же сложности будут у маленьких компаний. И MobiGear, на самом деле, маленькая компания, все те сложности, о которых я говорил, мы испытали на собственной шкуре. До конца 2014 года у нас не было проблем с получением крупных заказов, мы регулярно их выполняли, и вопроса типа «А сможете ли вы пережить кризис?» не возникало. А вот в конце того года и начале нынешнего этот вопрос нам задавали постоянно. Несколько тендеров, в которых мы участвовали, мы проиграли, хотя делали хорошие предложения с финансовой точки зрения – именно по той причине, что заказчик делал свой выбор в пользу дорогой компании. Он готов был переплачивать, но чувствовать себя спокойнее, потому что большая компания гарантированно доведет проект до конца. Тем не менее, это позволило получить пару хороших клиентов и проектов. В частности, мы сделали проект для компании Ernst & Young, которым мы можем по праву гордиться. Но несколько других проектов – не менее интересных, для не менее крупных компаний – к сожалению, не состоялись.

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

Андраш Густи: Я бы хотел отметить, что ситуации у клиентов бывают разные. И это очень сильно зависит от сферы, в которой клиент задействован, в которой он обычно работает, и от размера. Если компания мелкая или средняя – это, кстати, совсем не значит, что у них нет денег, – обычно решение принимает сам генеральный директор. Это он отправляет запрос, он обрабатывает аутсорсеров, он принимает решение и подписывает договор. Кстати, это довольно неплохой сценарий, когда директор пока не умеет делегировать задачи.

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

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

Соответственно, можно выделить трех людей – сам гендиректор, маркетолог и технический директор. Иногда еще бывает проект-менеджер – к нему обычно такие же требования, как к техническому директору, он должен иметь соответствующий опыт и техническое образование, тогда все, как правило, проходит хорошо. Я бы еще дал совет генеральным директорам – не отдавайте все в руки маркетологу. Если отдаете, то поставьте еще над ним контролирующего «технического» человека.

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

Андраш Густи: Кстати, что касается участия технической стороны. У нас был такой феноменальный случай. Большой бренд, сеть магазинов. Мы общались с маркетинговым отделом, и они рассказывали нам красивые истории о том, что нужно подумать о позиционировании, о том, как завлечь пользователей. Казалось бы, очень правильные вещи. Что сделать такого, чтобы увеличить ретеншн, что это нужно как-то заложить в концепцию. Таким образом, мы общались с ними несколько месяцев время от времени, они все думали, наши предложения им не нравились, они хотели что-то свое. В конечном итоге, по истечении нескольких месяцев они просто сказали: «А вы знаете, мы уже заключили договор с вами, только с другим отделом». Как же это произошло? Оказывается, наш IT-отдел поговорил с теми ребятами напрямую, они как-то друг друга поняли и, собственно, уже начали работу. Такой вот интересный момент. Да, привлекать техническую сторону – это очень полезно.

Дмитрий Желнин: Все зависит от проекта. Если это сложный проект, под него приходится разворачивать у себя полностью среду и тестировать в том числе и нагрузочное тестирование, и бек-энд делать, самого приложения нужно делать ревью, и ревью кода соответственно. А в 90% случаев этот код в принципе неподдерживаемый, дешевле и умнее переписывать все с начала. Это в 90% случаев.

Бывают совершенно исключительные случаи, когда к нам стучит маркетинг одной из компаний, которая производит бытовую технику, и говорит: «Ребята, помогите пожалуйста! Бюджета нет, айтишников нет, есть только я – менеджер по маркетингу. И есть приложение, которое сделала такая-то студия». Я говорю: «Все понял, дальше можете не продолжать». И приложение собирает негативные отзывы в количестве 100 штук в сутки. Приложение, которое работает с бытовой техникой, – в данном случае это была мультиварка. Мол, любой ценой дайте нам разработчика, переделайте, пожалуйста, потому что мы собираем негатив, маркетинг недоволен, нас за это живьем едят. После чего мы две недели пытаемся получить исходный код от предыдущего разработчика. Вот и такие истории бывают.

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

Если ситуация более-менее конструктивная, то разработчики могут договориться о том, что им нужно. Но по большому счету достаточно исходного кода и документации, если она была. Но просто часто бывает, что проект делался плохо, новичками-студентами, тогда, конечно, они никакой документации не писали, код не комментировали. И по нашему опыту, в большинстве случаев принимается решение переписывать такой проект с нуля. Просто потому, что переделывать код, который писали очень плохо и непрофессионально, нет никакого смысла. Быстрее, лучше и дешевле переписать его заново.