Почему заказчики IT-компаний переплачивают, и не считают нужным это менять

Сегодня, 13:08
120

Заказ IT-проекта похож на покупку дома на стадии строительства. Все договоренности соблюдаются на бумаге, установлены сроки и объемы работ, оплата производится вовремя, но что это гарантирует заказчику? Как показывает практика, немногое. Как ни странно, разработчику не всегда выгодно завершить проект в срок и распрощаться с довольным клиентом, даже если его работа была оплачена в полной мере. Некоторые IT-компании, пользуясь доверием клиента к своему профессиональному авторитету, держат клиента «в заложниках», ставя в зависимость от своих услуг и оставляя последнее слово за собой. По сути, разработчики заставляют заказчика платить больше, чем реально стоит его проект, и намного дольше, чем ведется работа над ним.

Заказ IT-проекта похож на покупку дома на стадии строительства. Все договоренности соблюдаются на бумаге, установлены сроки и объемы работ, оплата производится вовремя, но что это гарантирует заказчику?

Как показывает практика, немногое. Как ни странно, разработчику не всегда выгодно завершить проект в срок и распрощаться с довольным клиентом, даже если его работа была оплачена в полной мере. Некоторые IT-компании, пользуясь доверием клиента к своему профессиональному авторитету, держат клиента «в заложниках», ставя в зависимость от своих услуг и оставляя последнее слово за собой. По сути, разработчики заставляют заказчика платить больше, чем реально стоит его проект, и намного дольше, чем ведется работа над ним.

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

Кейс из практики MBP

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

A впечатлить заказчика, не имеющего опыта работы с IT-проектами, несложно. Достаточно иметь визуально приятное портфолио с большим количеством наименований сайтов и приложений. Наработать такое портфолио может любой начинающий разработчик, и его наличие не означает, что именно ваш проект ему по зубам.

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

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

Компания-разработчик согласилась, что заявленная неисправность существует. Но отказалась признавать ее неисправностью и назвала новым функционалом, требующим доработки! Заказчик, конечно, ни о каком новом функционале не слышал и не рассчитывал, что «готовое» приложение придется дорабатывать, причем за дополнительную плату.

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

Так или иначе, заказчику нужен был конечный продукт, и ему пришлось искать другой способ его получить.

Доверяй, но проверяй

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

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

В истории выше можно выделить основные причины, которые привели проект к сложившейся ситуации:

Плохая коммуникация. 

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

Отсутствие доверенного лица.

Чаще всего деятельность компании не завязана на IT-проекте, который они заказывают у IT-специалистов. Это какой-то вспомогательный инструмент, система, продукт, но не основа их деятельности. Следовательно, заказчик в лице начальства или рядовых сотрудников не может держать руку на пульсе 24/7 и посвящать все свое время участию в разработке проекта, так как занимается своей основной работой. В этом случае, компании необходимы «свободные руки», то есть человек, чьей основной задачей будет ведение проекта и той самой вышеупомянутой коммуникации. В метафоре со строительством эту роль исполняет прораб, человек, который знает все о вашей стройке, стройматериалах и рабочих, который не будет беспокоить вас по пустякам, но всегда позвонит, когда ситуация будет требовать вашего вмешательства. Он организовывает и контролирует весь процесс за вас.
Таким образом, вы закладываете фундамент вашего успешного проекта еще до его начала.

Что делать, если вы заказчик?

Убедиться, что вы назначаете менеджером проекта компетентного человека. 

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

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

Главным образом, это касается технической составляющей проекта — кода. Все права на обладание и использование программного обеспечения должны принадлежать вам, то есть заказчику. Во-первых, это гарантирует, что разработчики не смогут использовать «ваш» код в своей дальнейшей работе, передать его третьим лицам и продать повторно. Во-вторых, имея код вашего программного обеспечения, вы сможете использовать его как угодно и изменить при необходимости. Вы не будете ограничены одной компанией-разработчиком в случае, если вам потребуется какая-либо доработка или изменение существующего функционала.

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

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

Вместо вывода

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

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

Автор

Мироненко Максим Владимирович

image

Профиль
Изменить информацию о себе
Компании
Изменить информацию о компаниях и спецпредложениях
Подарки партнеров
Скидки на сервисы для бизнеса
Москва
Алтайский край
Амурская обл
Архангельская обл
Астраханская обл
Белгородская обл
Брянская обл
Владимирская обл
Волгоградская обл
Вологодская обл
Воронежская обл
Еврейская АО
Забайкальский край
Ивановская обл
Иркутская обл
Кабардино-Балкарская респ
Калининградская обл
Калужская обл
Камчатский край
Карачаево-Черкесская респ
Кемеровская обл
Кировская обл
Костромская обл
Краснодарский край
Красноярский край
Курганская обл
Курская обл
Ленинградская обл
Липецкая обл
Московская обл
Мурманская обл
Нижегородская обл
Новгородская обл
Новосибирская обл
Омская обл
Оренбургская обл
Орловская обл
Пензенская обл
Пермский край
Приморский край
Псковская обл
Респ Адыгея
Респ Алтай
Респ Башкортостан
Респ Бурятия
Респ Дагестан
Респ Карелия
Респ Коми
Респ Марий Эл
Респ Мордовия
Респ Саха
Респ Северная Осетия - Алания
Респ Татарстан
Респ Тыва (Тува)
Респ Хакасия
Ростовская обл
Рязанская обл
Самарская обл
Саратовская обл
Сахалинская обл
Свердловская обл
Смоленская обл
Ставропольский край
Тамбовская обл
Тверская обл
Томская обл
Тульская обл
Тюменская обл
Удмуртская Респ
Ульяновская обл
Хабаровский край
Ханты-Мансийский АО
Челябинская обл
Чеченская респ
Чувашская респ
Ямало-Ненецкий АО
Ярославская обл
Ваш город Москва?
Да