[Из песочницы] Взаимодействие клиента с аутсорсинговой компанией
Всем доброго времени суток! Сегодня хотел бы поговорить о путях взаимодействия клиента c аутсорсинговой компании, а также получить от Вас комментарии того, как Вы взаимодействуете со своими клиентами/разработчиками ПО. Данная статья написана на основании опыта работы и, по большей части, предназначена для заказчиков ПО. Целью является найти «узкие» места в вопросах отношений между заказчиком и компанией, которая предлагает услуги по разработке ПО.
Об авторе. Разрешите представиться: Я – Корхов Юрий и эта статья у меня на хабре первая. Закончил Белорусский Национальный Технический Университет (инженер по безопасности), Белорусский Государственный Университет (инвестиционный менеджер). Стаж работы — более 6 лет в IT на практически всех должностях: webmaster, верстальщик, web-дизайнер, программист, менеджер-проекта и по совместительству разработчик UI, руководитель отдела… В общей сложности, за это время, реализовано более 80 проектов: от маленьких сайтов, игр для мобильных телефонов до крупных интернет-порталов… Основной профиль — управление ходом разработки проектов в IT сфере. Работал как на стороне заказчика так и на стороне разработчика, как на Российский рынок так и на зарубежный.
Предыстория создания поста или Спасибо Wargaming. Обойти историю создания данного поста было бы не хорошо, т.к. хабр я читаю уже очень давно, а вот написать статью руки никак не доходили, а здесь дело “случая” и вот статья готова.Уже пару месяцев я отдыхаю от работы, потому что устал от аутсорсинга, решил найти смысл жизни и неторопливо подготовить к запуску свой проект, и в один прекрасный день раздался звонок. Рекрутер Wargaming (основатели “танчиков” и, по-моему мнению, одной из лучших фирм в Минске) позвонил мне с предложением пройти собеседование на вакансию Vendor Manager (здесь следует сказать, что работу я не искал, и, судя по их вакансии, я не очень подходил им). “Это же интересно!” — подумал я и решил выполнить тестовое задание, тем более, что оно было достаточно интересным для меня. Рекрутер сообщил, что у них созданы все условия для приятной, здоровой (фитнес, страховка и т.д) и высокооплачиваемой работы а также, что не маловажно, для выполнения тестового задания мне потребовалось бы около 3х часов. Я сомневаюсь, что у кого-то получилось бы сделать все тестовое задание в течение указанного срока, что касается меня – в общей сложности ушло около 6 часов.
К моему сожалению, feedback от компании был в телефонном разговоре и выражался сухой фразой “всё хорошо, всем понравилось” (дословно не помню, но суть такая) и без какой-то конкретики. Я сомневаюсь, что мне удалось указать все основные «узкие» места, а т.к. не хорошо пропадать труду, решил разместить ответы на тестовое задание (с небольшими изменениями, для удобства) на суд общественности и буду признателен аудитории habra за дополнения и здоровые комментарии к статье.
Схема взаимодействия заказчик – разработчик программного обеспечения от первого знакомства до окончания взаимоотношений.
При разработке схемы я подразумеваю:
Разработчик ПО способен выполнить проект.
С разработчиком ПО до этого договор не подписывался и никаких проектов не было.
ТЗ уже готово.
Условия оплаты регулируются договором.
Системы управления проектами и методологии разработки ПО (XP, Scrum, Lean, Kanban, ScrumBut и т.д.) используются.
Наполнение контентом приложения (если это необходимо) делается средствами клиента.
Аспекты контракта между software development вендором и заказчиком вендору выгодно избежать (упростить, вообще убрать из контракта).
Ответственность за соблюдение сроков лежит на стороне разработчика и в случае, если срыв сроков происходит в последний момент (т.е. разработчик заранее не уведомил о том, что не успевает до закрытия) должны накладываться штрафные санкции (здесь большой выбор вариантов).Причина: срыв сроков — одна из самых больших проблем и упоминать это в договоре не очень интересно, т.к. в большинстве своем срыв сроков лежит на стороне разработчика. Здесь нужно учитывать, что точно рассчитать сложно, но заранее предупредить о том, что разработчик не успевает выполнить этап разработки в определенный срок — обязан и это нужно прописывать в договоре. Условия гарантий исправлений «багов» по вине разработчика, которые не были вовремя выявлены. Обычный срок гарантии 3 месяца.Причина: часто бывает, что некоторые “баги” не были устранены или появились уже в процессе работы, поэтому этот пункт часто пытаются не указывать или уменьшать время гарантии. Мое мнение, что меньше 3х месяцев мало. Права на разработанное ПО, модули, блоки и т.д. принадлежат заказчику и не могут применяться для последующей перепродажи.Причина: разработчику выгодно обладать правами на интеллектуальную собственность или иметь возможность продавать/использовать наработки для других клиентов, что в свою очередь может поставить заказчика в неудобную ситуацию на рынке. При разработка нового модуля в системе, который влияет на работу других модулей или всей системы, разработчик должен обеспечеить функционирование всей системы.Причина: часто разработка одного модуля может навредить работе другого модуля или вообще всей системе и дальнейшие доработки могут лечь на “плечи”(финансово) клиента. Разработчик обязан учитывать структуру всей системы и в случае “багов”, найденных клиентом, править бесплатно. Техническая документация на разработку должна составляться с учетом требований заказчика.Причина: разработчикам выгодно полностью привязать себя к заказчику и часто бывает, что документация не ведется. В случае разработки веб-сайта, исполнитель обязан учитывать SEO оптимизацию для сайта, а именно: описание изображений, страниц…Причина: экономия времени на “мелочи”, что в зависимости от условий договора может привести к финансовым потерям заказчика (разработчик ПО экономит время/финансы). Тестирование системы должен обеспечивать разработчик системы.Приемка заказчиком готового модуля не должна превращаться в тестирование системы, т.е. разработчик обязан взять на себя устранение выявленных “багов” клиентом за свой счет. Это нужно для того, чтобы обеспечить качественное тестирование продукта со стороны разработчика. К моменту, когда разработчик говорит “сделано” и начинается тестирование на стороне клиента — “баги” правятся бесплатно. Ответственность за размещение проекта на стороне заказчика берет на себя разработчик. При этом заказчик обязан обеспечить выполнение технических требований для площадки.Причина: размещение проекта на стороне заказчика иногда может вызвать определенные трудности, что может привести к “шапкозакидательству”, поэтому ответственность по размещению и настройке сервера должна быть на стороне разработчика ПО. В случае если разработчик ПО вынужден прибегнуть к помощи специалистов вне своей команды он обязан взять на себя все сопутствующие риски за утечку, потерю данных или любой другой ущерб, который может нанести своим действием или бездействием сотрудник со стороны.Причина: бывает, что у разработчика может заболеть, уволиться и т.д. кто-нибудь из сотрудников. В этом случае заказчик должен быть застрахован. Резервные копии проекта должны обеспечиваться на стороне разработчика не реже 1 раза в сутки. Любые проблемы с потерей данных по проекту должен брать на себя разработчик.Причина: здесь нужно обозначить кто несет ответственность за сохранность проекта в случае каких-либо сбоев. Разработчик должен исходить из популярности использования применяемых им технологий при выборе.Причина: привязка к собственным технологиям, которые усложнят жизнь в случае перехода заказчика к другому разработчику. Известные способы завышения стоимости аутсорсинговых работ относительно реальности.Полагаю их больше.
Поверхностная оценка стоимости разработки проекта целиком, без разбиения на этапы, что может привести к 2х-3х кратному превышению стоимости проекта. Не предоставление отчетов о проделанной работе в определенный по договору срок или не возможность контролировать ход разработки со стороны клиента Неправильный выбор технологии при реализации технической части, может значительно увеличить стоимость разработки. Отсутствие в команде разработчика нужных специалистов, что увеличивает время и стоимость разработки. Фиксированная установка стоимости разработки проекта или модуля и дальнейшее увеличение стоимости за каждую мелочь, которую обе стороны понимали по разному. Фиксированная установка стоимости разработки проекта — более высокий риск заставляет закладывать в стоимость проекта. При разработке дизайна не используется прототипирование, а разработка дизайна ведется на основе текстового ТЗ, что в итоге приводит к большому количеству доработок/исправлений и соответственно увеличению стоимости проекта. Добавление/усложнение функционала. Можно сделать проще — делают сложней. “Красивости” там где они не нужны (можно сказать про админ. часть сайта, если можно использовать css фреймворки для быстрой кастомизации админ. части — начинают разрабатывать с нуля). Шаблон взаимоотношений ‘заказчик — software development vendor’, который, как мне кажется, наиболее близок к практическому использованию.
Многие аутсорсинговые компании предпочитает не предоставлять доступ к своим системам управления проектами, не предоставляя подробную информацию, лично считаю, что доступ должен предоставляться по желанию заказчика. Клиент является ответственным за реализацию проекта и видеть ход разработки в реальном времени — важно!Также, считаю, что разрабатывать ПО с учетом расчета полной стоимости проекта — трата средств и нерв, такая разработка обычно приводит к конфликтным ситуациям.
Основные моменты при взаимодействии разработчика ПО и клиента, которые считаю оптимальными:Оплата работы исходя из почасовой оплаты работы сотрудников или усредненной стоимости работы специалиста всей команды разработчика. Оценку этапов разработки делать необходимо. Почему считаю эту форму расчета цены оптимальной:Не требует очень щепетильного подхода в оценке проекта, которую сделать на 100% точной практически нереально. В случае если оценка сделана неверно и разработчик ПО это начинает понимать, то происходит “ущемление” функционала везде где только можно, что в итоге будет сказываться на удобстве использования.
Улучшает взаимопонимание между разработчиком ПО и клиентом, т.к. основная задача сводится к принципу — “сделай качественно и быстро”, а не “вложись в жесткий бюджет и как будет работать так и хорошо”.
Клиент, на основе ежедневных отчетов о затраченных часах, может видеть какое время тратят сотрудники на разные блоки при разработке, что дает понимание скорости и качества работы сотрудников разработчика ПО.
Взаимодействие между заказчиком и менеджером-проекта ведется максимально на прямую, т.е. при использовании skype, телефонов и т.д.
Только 2х недельные отчеты и планы должны пересылаться в обязательном порядке по почте (для контроля).
Клиент предоставляет прототип приложения или его разрабатывает команда разработчика ПО, если это необходимо:
Упрощает понимание основного функционала проекта.
Увеличивает общую скорость разработки проекта.
Понятные требования к функционалу как у заказчика так и у разработчика.
Ясное понимание куда будет двигаться проект.
Система управления проектами для ведения хода реализации проекта и возможности мониторинга процесса, времени разработки, потраченной на каждую задачу в отдельности. К сожалению, доступ редко предоставляют разработчики.
Желательно, чтобы весь проект делала одна команда, т.е. не должно быть такого, что один этап делает одна компания, другой — другая и т.д.
Контрольные точки (“забег”) каждые 2 недели- оптимальное время для контроля проекта.
В разработке предпочтение отдается известным фреймворкам, также для более простой адаптации в случае какой-либо ситуации, когда необходимо передать проект другим разработчикам.
Качественное тестирование на стороне разработчика — прямая обязанность. При передаче клиенту проекта или какой-то его части, всё должно быть проверено досконально.
Поддерживать разные браузеры — прямая задача разработчика
Вывод: главное придерживаться партнерских/взаимовыгодных и доверительных отношений с пониманием того, что разработчики такие же люди и усложняя им жизнь усложняешь жизнь и себе! Каждый должен отвечать за свою часть работы, клиент-за предоставление внятного ТЗ и отвечать оперативно на возникающие вопросы, не забывая оплачивать работу, а разработчик — за качество, сроки, скорость. Идеал, конечно, не достигнут, но мы на верном пути.
