Руководитель отдела аутсорсинга всегда в курсе всех поступающих запросов по веб-разработке. В его компетенцию входит постановка задач и руководство ключевыми специалистами, а также распределение и планирование ресурсов. Руководитель отдела аутсорсинга всегда держит руку на пульсе и координирует исполнение договорных обязательств по проекту. Поэтому мы решили обратиться к Виталию Горнику — руководителю отдела аутсорсинга компании ИксБи Софтваре с насущными для заказчиков вопросами.
— И сразу к делу. В чем конкурентное преимущество ИксБи Софтваре по сравнению с другими аутсорсинговыми компаниям?
— В первую очередь, в библиотеке JS компонентов Webix и некоторых других продуктов, потому что это основа всех разрабатываемых нами веб-приложений. Лучше нас эту библиотеку никто не знает и, соответственно, быстрее и дешевле нас приложение с использованием таких продуктов никто не разработает.
— То есть кастомизация наших продуктов — это самые популярные услуги по аутсорсингу, которые оказывает ИксБи Софтваре?
— Большинство наших проектов, так или иначе, базируются на наших продуктах. Хотя сейчас есть несколько крупных проектов, в которых они не используются, но благодаря нашим продуктам нас и нашли. В целом, если учитывать предыдущие проекты, то именно наши компоненты и определили выбор заказчика в нашу пользу.
— Многие ИТ-компании заявляют, что они применяют гибкие методологии разработки ПО, например, Scrum или Kanban. Как показывает практика, зачастую Agile остается лишь модным словом, а на на деле его либо выборочно применяют либо не применяют вовсе, особенно когда планируется срочный релиз. А как организована работа в ИксБи Софтваре?
— Agile — это общее название огромного множества гибких методологий. И когда люди говорят Agile — это то же самое, если бы мы говорили, что используем на фронтенде какой-то фреймворк, и не указывали какой. В первую очередь, Agile — это рекламный трюк, потому что любая методология либо фреймворк вносят ограничения. Да, мы бы хотели следовать чистому скраму, как написано в теории, но теория всегда состоит из определенной идеализации. И поскольку над проектом всегда идет совместная работа с заказчиком, не только мы должны следовать выбранному направлению, но и заказчик. Следует не забывать, что cкрам — это средство, а не цель. Поэтому, если скрам не работает в чистом виде, его подрезают. По этой причине существует такое большое количество гибких методологий. Утверждение, что компания работает по Agile — это всего лишь значит, что компания адаптируется под нужды заказчика в процессе работы гораздо лучше. В противовес Waterfall, где мы определились заранее, куда бежать, и побежали, Agile говорит: да мы определились, куда бежать, но мы будем постоянно оглядываться, туда ли мы бежим.
— Чем обычно обеспокоен клиент при аутсорсинге веб-разработки своего проекта?
— Как всегда, чтобы заплатить меньше денег и быстрее получить результат. Хочу сейчас и бесплатно, но это все клиенты, не только софтварные, даже я на рынке, когда покупаю какие-либо товары, хочу лучше и бесплатно.
— Какие, на твой взгляд, наиболее частые проблемы возникают с нашей стороны и со стороны заказчика на разных этапах работ над проектом?
— Давай по порядку рассмотрим все этапы проекта. Инициация проекта. Пришел заказчик и говорит: “Ребята, у меня есть идея, давайте ее реализуем!”. Первая проблема состоит в том, что зачастую клиент не описывает свою идею, а предлагает устроить скайп-колл и все обсудить. Дело в том, что когда клиент описывает свою идею в письменном виде, он свои мысли структурирует и смотрит на cвою идею как бы со стороны: на ее жизнеспособность, осуществимость и необходимость. Если описание всей его идеи умещается на страницу формата A4 и там только набор хаотичных мыслей, а он просит эстимейт, то сразу видно, что у клиента нет ясного видения, чего же он хочет, и с таким клиентом лучше не работать. Бывает, что клиенту и эстимейт не нужен. Тогда такой проект переходит в разряд стартапов, которые могут в любой момент рухнуть. У нас есть такие клиенты, которые ничего не могли вначале сказать, а потом по чуть-чуть что-то выкристаллизовывалось. Но мы всегда готовы к тому, что однажды он не получит дальнейшего финансирования своего стартапа и скажет нам: “Спасибо, до свидания”.
— А какие проблемы возникают на этапе планирования проекта?
— На этом этапе мы должны распределить, что мы делаем, какие инструменты и фреймворки используем, какие у нас этапы (майлстоуны) и какие дэдлайны. Независимо от того, разрабатывается проект по Waterfall или по Agile, необходимо прояснять, туда ли мы идем, чтобы понимать, когда мы придем. Если начать проект и не знать времени его окончания, то проект в конечном счете умрет из-за его ненадобности. Поэтому было бы здорово на этапе планирования четко понимать, что, например, профиль пользователя будет готов через неделю, синхронизация с Google должна работать через три недели, а весь проект должен быть завершен через 5 месяцев. Когда такие данные есть, всегда можно сориентироваться в будущем.
— Какие самые частые проблемы возникают на этапе выполнения проекта?
— Здесь проблема в том, чтобы клиент смотрел, что мы делаем. Нередко были случаи, когда клиент говорил, что все хорошо, платил деньги, а результат не смотрел. Клиент ожидает, что мы сделали так, как он когда-то в голове у себя построил. А разбежка может быть очень большая, потому что он переводит свою мысль через слова или текст и доносит до нас, а наш бизнес-аналитик берет их и строит у себя в голове какой-то образ, который он затем доносит исполнителю, который это реализует и показывает заказчику. Тот образ, который у заказчика был, когда он пытался перевести в слова или текст, и тот образ, который он получил, глядя на продукт, могут отличаться.
— Как сломанный телефон, пока дошло до разработчика, суть поменялась.
— Да, конечно. И проблема может быть на любом этапе. Как говорит Agile, постоянно показывайте заказчику достигнутый результат, чтобы он посмотрел внимательно и сказал: “Да, я получил то, что я хотел.” Еще важно не спешить реализовывать, потому что по факту реализация — это всего лишь треть или четверть времени, которое нужно потратить на проект, если делать все правильно и грамотно. Если взять стартап, то реализация занимает почти все время, поэтому и вероятность успеха стартапа один из десяти. Если клиент готов сразу проститься со своими деньгами, тогда стартап можно сразу реализовывать по той схеме, которая сложилась у него в голове. Но это его риски. А если у клиента есть понимание того, что он платит, чтобы получить отличный результат на выходе, то нужно вначале проговорить, что конкретно он хочет, нарисовать макеты страниц интерфейса, сделать дизайн и только в конце реализовывать. Ну и при реализации проекта важно, чтобы разработчики не спешили и хорошо понимали, как будет работать проект. Чтобы в итоге они построили хорошую архитектуру, которую не нужно будет дорабатывать новыми фичами, о которых заказчик не знал. Обычно фича, которая не была запланирована заранее, нарушает общую структуру проекта.
Пример:
Можно представить разработку как строительство какого-то дома. Приходит, к примеру, архитектор к прорабу и говорит: “Вот, посмотри, нам нужно построить такой дом.” И начали строить. А потом заказчик смотрит на этот дом и говорит: “А давайте комнаты вот так передвинем…здесь сделаем надстройку, в подвале спортзал, а на крыше пусть будет бассейн.” И в итоге получается, что вся эта конструкция как-то кособоко стоит. Так и с проектами по веб-разработке: накопленные изменения, внесенные в проект новые фичи вынуждают делать рефакторинг. В связи с тем, что установили на крыше бассейн, нужно усилить стены, несущие балки. Возможно, проще снести такой дом и построить новый.
— А бывало такое, чтобы проект надо было делать заново?
— Это дорого, такого не было. Заказчики все-таки надеются получить в итоге рабочий результат. Поэтому необходимо отслеживать, чтобы у исполнителя были навыки, необходимые для выполнения работы. Если, к примеру, используется новый фреймворк или мы для реализации новой фичи должны подключить то, с чем раньше не работали, то лучше предварительно потренироваться где-то на стороне, например, на внутренних проектах, а не на проектах заказчика. И на закрытии проекта важно, чтобы после того, как мы закончили итерацию и предоставили заказчику версию — мажорную, минорную или промежуточную — заказчик сказал: “Да, молодцы!”. Потому что он может не сказать этого, и мы пойдем дальше-дальше и не туда уйдем. На этом этапе важно, чтобы наш бизнес-аналитик и заказчик посмотрели на проект со стороны: “A то ли мы делаем? Приближаемся ли мы к нашей цели или нет?” То есть на этапе планирования зафиксировали временные рамки, когда что будет реализовано. А во время работы над проектом мы должны сверить наши результаты с прогнозом и посмотреть, как они соотносятся. И, соответственно, корректировать либо разработку, либо прогнозы. И еще, нужно обращать внимание заказчика на то, что он может увлечься добавлением фич, оторваться от жизни и забыть напрочь прогнозы и про то, что он когда-то хотел. Такое действительно бывало: начинаешь что-то разрабатывать в соответствии с оговоренным планом, а потом заказчик просил добавлять функциональность и ещё, и ещё, в результате получалось не совсем то, что ожидали.
