Мы продолжаем интервью с руководителем отдела аутсорсинга ИксБи Софтваре Виталием Горником. В второй части вы узнаете, как происходит мониторинг выполнения проектов, как строится общение с заказчиками, как работают наши программисты и какие планы у компании на будущее.
— Кто контролирует весь процесс работы над проектом? Бизнес-аналитики?
— Бизнес-аналитики вначале выясняют, что должно было получиться, а потом смотрят, получилось ли то, что хотели. Бизнес-аналитики не отслеживают прогнозы и временные рамки. Это функция менеджера. Аналитик же работает с содержанием проекта (scope). Т.е. он берет и разбивает его на части вместе с разработчиками, а потом добавляет задачи в очередь (string). Когда разработчик выполнил работу, бизнес-аналитик смотрит список фич, которые должны были появится, и сопоставляет его с исходными данными. Связывается с заказчиком и говорит: “Вот список фич, о которых мы договаривались — и вот они реализованы в продукте.» Прогнозы, риски, прокачивание команды — это не функция бизнес-аналитика.
— A ресурсов хватает? т.е. достаточно ли в ИксБи Софтваре бизнес-аналитиков и менеджеров проектов?
— У нас, как правило, эти роли совпадают, за исключением нескольких крупных проектов. Нужно разделение, если на проекте задействовано 8-10 человек и масштаб проекта настолько большой, что один человек не может отслеживать его целиком, делать спринты и еще думать, попадаем мы или нет в установленные временные рамки. И при этом он еще должен заботиться о ресурсах, об удовлетворенности команды и о том, хватает ли у них навыков. Eму также нужно поговорить с каждым членом команды, поднять его мотивацию. На такой проект одного аналитика не хватает, поэтому возникает разделение. Любой проект состоит из определенного количества процессов, независимо от масштаба проекта: будь это проект, где всего два лица — заказчик и исполнитель, либо это крупный проект, в который вовлечены и заказчик, и менеджер, и аналитик, и второй аналитик, и QA. Сами процессы всегда одинаковые, всегда есть какая-то инициализация, планирование графика, митинги. Другое дело, сколько процессов и ролей возлагается на конкретного человека. Чем больше проект, тем более узкая специализация у каждого участника.
— Как происходит общение с заказчиком во время проекта? Он контактирует с 1-2 участниками команды (например, с бизнес-аналитиком или менеджером проекта), или, быть может, организуются call-сессии со всеми участниками команды?
— Чем меньшее количество людей вовлечено в ежедневное общение с заказчиками, тем лучше для проекта. Должно быть как можно меньше точек входа в команду, потому что, если будет много точек входа, нужно будет организовывать мероприятие для синхронизации их знаний. Если заказчик одновременно общается по вопросам одного scope с несколькими членами команды, то эти члены команды должны постоянно приходить к общему знаменателю, чтобы у них было одинаковое представление, что же мы в итоге делаем.
Пример 1:
Заказчик одному исполнителю может сказать, что мы делаем профиль пользователя, в котором будут загружаться аватарки пользователя, а другому дает задачу подгружать аватарки из Google+. Причем он мог сказать это двум исполнителям в разное время: одному во время скайп-колла, другому написать через месяц по email. И могло получиться так, что эти задачи стали выполняться одновременно.
— В команде ведь все равно исполнители предварительно согласовывают, какую функциональность они будут создавать и каким образом?
— Да, происходит синхронизация информации, приведение к одному знаменателю. А если в команде 15 человек? С ними уже тяжелее провести standup-митинг, потому что представь, если 15 человек по 5 минут будут говорить, что они сделали, что они будут делать и какие у них есть проблемы, то это уже занимает 75 минут, т.е. 1 час 15 минут. Т.е. ежедневно умышленно теряется 15 человеко-часов рабочего времени или два человеко-дня на то, чтобы каждый член команды послушал, что делают другие. Многовато.
— А смотри, допустим, бизнес-аналитик общается с заказчиком, который рассказывает ему, как нужно сделать. Тот приходит к разработчикам, говорит, что будем делать такую-то фичу таким-то образом, а кто-то из разработчиков говорит: нет, так не годится, будем делать лучше так. Бывало ли такое, чтобы разработчик был категорически против и говорил, что нет, я не буду так делать, это неправильно.
— Да, конечно. Есть понятие реализуемости фичи, есть понятие стоимости реализации фичи, может, выгода от реализации фичи существенно ниже от стоимости ее реализации. Т.е. ценность фичи маленькая.
Пример 2:
Заказчику нужно разместить документы в базе, и ему порекомендовали использовать базу данных MongoDB из семейства NoSQL Mongo. Заказчик думает: “Я использую новую фишку, мой проект станет круче.” А исполнитель может посмотреть все требования для хранения этих документов и сказать, что Mongo использовать неудобно и это вызовет кучу проблем. Или наоборот, заказчик думает, что документы хорошо хранить в mySQL, а исполнитель говорит, что лучше использовать Mongo. Возможно, mySQL подходит по требованиям, но в Mongo будет быстрее работать. В таких случаях собирается колл или митинг, на котором обязательно присутствует аналитик, потому что синхронизация должна идти через него. Т.е. он то лицо, которое синхронизирует все запросы клиента, чтобы они не были противоречивы.
— Бывает ли такое, что в процессе работы над проектом кто-то из команды (например, менеджер) не может найти общий язык с заказчиком? Что происходит в этом случае?
— Ну есть же всякие индивидуальные особенности. Аллергия, например. В общении тоже есть индивидуальная непереносимость. В этом случае мы меняем менеджера проекта. Легче поменять менеджера, чем заказчика. Заказчик — он один.
— По каким причинам заказчики могут отказаться от услуг компании на этапе согласования работ? Что их обычно не устраивает?
— Заказчики, в любом случае, связываются с разными компаниями и потом выбирают компанию, наиболее соответствующую их требованиям. Они обращаются с определенным проектом, который должен содержать определенные функции. Здесь нужно грамотно подходить к заказчику, уметь себя продать. По сути, мы еще ничего не сделали, но мы должны вселить ему уверенность, что мы сделаем проект лучше остальных. Он выберет компанию, которая ему больше всех вселит уверенность.
— То есть дело в коммуникативных навыках менеджера, который общается с заказчиком?
— Да-да-да, но в целом, у клиента формируется отношение не только из общения. Он обращает внимание на то, как выглядит сайт, например. Как мы представляем информацию, все ли понятно при общении с нами. Насколько мы проактивны, насколько мы его предугадываем. Если представить, что мы всегда на шаг впереди с каким-то клиентом, то конечно, он от нас не уйдет, потому что мы предугадываем его желания, и его восторг постоянно растет.
— А окончательное решение по проекту, будем мы над ним работать или нет, принимаешь ты?
— Не могу сказать, что только я. Решение принимается совместно с отделом продаж.
— Встречались ли проекты, от которых пришлось отказаться? Например, бывало ли такое, что, получив от заказчика видение проекта, вы не брались за него сами, а советовали того, кто будет лучше отвечать интересам заказчика?
— Конечно, мы же не работаем по всем направлениям. Нам поступают заказы на проекты, которые, допустим, должны быть реализованы на фронтенде на JavaScript, а на бэкенде на Java. Их мы не берем, т.к. специализируемся на фронтенд-разработке. Поэтому предлагаем взять на себя только фронтенд часть.
— А планируется расширять спектр оказываемых услуг, например, разработку нативных мобильных приложений.
— Конечно, мы вообще планируем мир покорить. :)
— Это понятно, просто сейчас разработка мобильных приложений в тренде, а ИксБи Софтваре предлагает, в основном, разработку гибридных приложений, а на Android/iOS почему не делает?
— Мы делаем, в основном, бизнес-приложения и, исходя из нашего опыта, существующих возможностей гибридных приложений, сделанных, к примеру, на PhoneGap, вполне достаточно. Такое гибридное приложение отличается от нативного только по скорости работы. В целом, для большинства неигровых приложений разница в производительности не будет заметна. Кроме того, с PhoneGap нет никаких ограничений в использовании аппаратных возможностей устройств. Разрабатывая PhonGap-приложение, мы работали с камерой, брали снимки, посылали их на сервер, работали с NFC тегами и GPS датчиками. На нем можно сделать 8 из 10 приложений, и такое приложение будет гораздо дешевле в разработке, чем нативное. PhoneGap — не единственный, но он на слуху, у него большое комьюнити, и мы давно с ним работаем. Мы предлагаем разработку PhonGap-приложения и говорим, что оно будет работать, как нативное. Вы только знаете, что оно фонгаповское, а визуально разницу не ощутите, особенно если вы не разработчик. Одних заказчиков такой вариант устраивает, других нет.
Читайте также первую часть интервью.
Если у вас есть вопросы к руководителю отдела аутсорсинга компании ИксБи Софтваре, присылайте их нам через форму обратной связи либо оставляйте в комментариях, и мы постараемся на них ответить.
