Аутсорсинговая компания и клиент. Узкие места взаимодействия.

30 Окт 2014
by admin
Comments are closed
Огромное количество компаний передает задачи на разработку в аутсорсинговую компанию. Схема работы уже настолько привычна, что мало кто отступает от нее. В этой статье собраны советы по оптимизации взаимодействия заказчика и исполнителя.
В качестве начальных условий будем использовать следующие: – Рассматриваемый разработчик сможет выполнить заказ клиента; – Заказчик и исполнитель ранее не взаимодействовали; – Техническое задание уже подготовлено; – В ходе взаимодействия клиента и разработчика используются различные методологии разработки и системы управления проектами; – Если приложение должно быть наполнено контентом, это выполняется за счет средств клиента; – Способы и размеры оплаты указаны в договоре.
В целом схема взаимодействия выглядит следующим образом: При знакомстве с компанией, с которой планируется работать, необходимо познакомиться и непосредственно с командой, которая будет работать на проекте. Далее следует определить, как именно работает разработчик, и определить методы работы, удовлетворяющие и требованиями заказчика, и возможностям исполнителя, определить способ формирования стоимости работ и порядок оплаты и подписать договор.
На стадии реализации проекта придется приложить намного больше усилий и учесть огромное количество аспектов. Перед тем, как начать разработку, аутсорсер должен ознакомиться с техническим заданием и после ознакомления с ТЗ встретиться с заказчиком для обсуждения проекта. В рамках обсуждения приветствуется разделение проекта на этапе – это сделает работу над проектом удобнее и прозрачнее. Когда разбивка на этапы уже закончена, можно составить план реализации проекта и приступать к работе.
Чтобы работа над проектом не была секретом за семью замками, заказчик должен иметь возможность связаться с менеджером проекта и, желательно, получить доступ к системе управления проектами. Менеджер проекта является основным сотрудником, с которым взаимодействует клиент, а значит, именно с ним клиент будет обговаривать ход разработки, возникающие проблемы и оплату. В область ответственности разработчика всходит реализация проекта в установленный срок, ведение отчетности. Область ответственности клиента включает в себя контроль хода разработки, контроль отчетов для оплаты, подтверждение трудозатрат, а также ответы на возникающие вопросы.
После завершения разработки проект должен быть протестирован. Тестирование может быть выполнено на стороне исполнителя и на стороне заказчика. Если в ходе тестирования были выявлены какие-либо недочеты или баги, они исправляются разработчиком бесплатно.
Как только проект готов к запуску, его размещают на сервере заказчика, и он переходит на техподдержку разработчика. В это же время документация по проекту передается заказчику, а заказчик оплачивает работу исполнителя.
Если аутсорсер честен, и его квалификация действительно так высока, как он ее рекламирует, то и договор, скорей всего, будет составлен баз подводных камней. Однако клиенту всегда стоит обращать на договор особое внимание, ведь есть вещи, которые некоторые разработчики предпочтут убрать из договора некоторые аспекты, такие, как: 1. Соблюдение срока реализации проекта. Срыв сроков является одной из самых распространенных проблем в передаче проекта на аутсорсинг, и чаще всего сроки срываются по вине разработчика. Понятно, что рассчитать точный срок, в который разработчик уложится с вероятностью в 100%, очень сложно. Но предупредить заказчика о том, что работа не будет сдана вовремя, нужно заранее. Этот пункт должен быть прописан в договоре во избежание искусственного затягивания сроков. 2. Время гарантии на выполненные работы. Часто бывает так, что какие-то выявленные проблемы не были устранены до сдачи проекта, или же они появились в процессе работы. Такие баги должны быть исправлены разработчиком бесплатно в гарантийный срок (обычно это 3 месяца). Недобросовестные аутсорсеры стараются или не прописывать этот пункт в договоре, либо сильно приуменьшить гарантийный срок. 3. Пункт о правах на разработанное программное обеспечение. Естественно, что разработчику удобнее без подобного пункта в договоре. Тогда он спокойно сможет использовать свои разработки в других проектах. Однако клиента такое положение дел может привести к неудобной ситуации. 4. Корректное функционирование всей системы после доработок или добавления новых модулей. Разработать дополнительный модуль несложно. Гораздо сложнее разработать его так, чтобы он не навредил функционалу всей программы. Если подобный пункт не будет прописан в договоре, клиент рискует оплачивать все исправления из своего кармана. 5. Документация на разработанное ПО. Часто аутсорсеру бывает выгодно, чтобы клиент чувствовал себя привязанным именно к нему. Одним из способов достижения такой привязки может быть отсутствие технической документации к проекту. 6. Тестирование. В договоре должен быть прописан этот пункт, однако часто его не вписывают. Некоторые клиенты считают тестирование обязанностью разработчика, а некоторые желают протестировать разработку сами. Необходимо помнить, что с того момента, как разработчик сдал работу заказчику, все баги (если таковые найдутся) должны быть устранены разработчиком бесплатно. 7. Размещение разработки на стороне заказчика. Размещением проекта должен заниматься разработчик, а заказчик обязан выполнить все технические требования для площадки. 8. Привлечение сторонних разработчиков. Бывают обстоятельства, когда разработчик не может продолжать работу над проектом (заболел, ушел в отпуск, уволился), а сотрудников не хватает. Некоторые разработчики привлекают подряд. И с этого момента ответственность перед клиентом за разработанное подрядчиком ПО, утечку информации или какой либо иной ущерб должен нести разработчик, с которым составлен договор. Клиент должен быть застрахован. 9. Ответственность за сохранность проекта в период разработки. В договоре должен быть пункт об ответственности за сохранность проекта в случае сбоя. Сохранность проекта может обеспечиваться сохранением резервной копии хотя бы раз в сутки. 10. Использование наиболее распространенных технологий при разработке проекта. Не слишком честные программисты вполне могут в ходе разработки использовать собственные технологии, в связи с чем дальнейшая эксплуатация продукта, а также исправление багов, будет проблематичной.
Кроме особенностей составления договора следует обратить внимание и на способы завышения цена на аутсорсинг. Их огромное множество, но чаще других используются следующие:
1. Невозможность контроля выполнения задач по проекту или отсутствие отчетов о ходе выполнения проекта. 2. Разработка оценивается какой-либо фиксированной суммой, а любые доработки стоят денег. Понятие доработка понимается заказчиком и исполнителем по-разному. Такая ситуация может быть следствием недоработанного договора между сторонами. 3. Увеличение функционала или его усложнение. Разработчик реализует более сложный или более развернутый функционал, который выглядит интересно, но в дальнейшем использоваться не будет. За разработку этого функционала взимается дополнительная плата. 4. Фиксированная стоимость разработки. При фиксированной стоимости проекта в смету закладывается значительная сумма для страхования от больших рисков. 5. Приблизительная оценка стоимости выполнения проекта. Если проект оценивается целиком, без разбивки его на этапы, велика вероятность завышения стоимости разработки в 2-3 раза. 6. Отсутствие в составе команды разработчика нужных специалистов. Это увеличит время выполнения проекта, а значит и его стоимость. 7. Неверный выбор способа или технологии реализации функционала. Эта статья также может сильно увеличить стоимость всего проекта.
Главное в сотрудничестве клиента и аутсорсера – это взаимоуважение, доверие и правильно составленный и проработанный договор.
Senior Soft — Аутсорсинг 1С разработки © 2012 - 2017. Все права защищены.