Взаимодействие клиента с аутсорсинговой компанией

Схема взаимодействия заказчик – разработчик программного обеспечения от первого знакомства до окончания взаимоотношений.

1. Разработчик ПО способен выполнить проект.
2. С разработчиком ПО до этого договор не подписывался и никаких проектов не было.
3. ТЗ уже готово.
4. Условия оплаты регулируются договором.
5. Системы управления проектами и методологии разработки ПО (XP, Scrum, Lean, Kanban, ScrumBut и т.д.) используются.
6. Наполнение контентом приложения (если это необходимо) делается средствами клиента.

1. Ответственность за соблюдение сроков лежит на стороне разработчика и в случае, если срыв сроков происходит в последний момент (т.е. разработчик заранее не уведомил о том, что не успевает до закрытия) должны накладываться штрафные санкции (здесь большой выбор вариантов).
   Причина: срыв сроков — одна из самых больших проблем и упоминать это в договоре не очень интересно, т.к. в большинстве своем срыв сроков лежит на стороне разработчика. Здесь нужно учитывать, что точно рассчитать сложно, но заранее предупредить о том, что разработчик не успевает выполнить этап разработки в определенный срок — обязан и это нужно прописывать в договоре.
   
2. Условия гарантий исправлений «багов» по вине разработчика, которые не были вовремя выявлены. Обычный срок гарантии 3 месяца.
   Причина: часто бывает, что некоторые “баги” не были устранены или появились уже в процессе работы, поэтому этот пункт часто пытаются не указывать или уменьшать время гарантии. Мое мнение, что меньше 3х месяцев мало.
3. Права на разработанное ПО, модули, блоки и т.д. принадлежат заказчику и не могут применяться для последующей перепродажи.
   Причина: разработчику выгодно обладать правами на интеллектуальную собственность или иметь возможность продавать/использовать наработки для других клиентов, что в свою очередь может поставить заказчика в неудобную ситуацию на рынке.
4. При разработка нового модуля в системе, который влияет на работу других модулей или всей системы, разработчик должен обеспечеить функционирование всей системы.
   Причина: часто разработка одного модуля может навредить работе другого модуля или вообще всей системе и дальнейшие доработки могут лечь на “плечи”(финансово) клиента. Разработчик обязан учитывать структуру всей системы и в случае “багов”, найденных клиентом, править бесплатно.
5. Техническая документация на разработку должна составляться с учетом требований заказчика.
   Причина: разработчикам выгодно полностью привязать себя к заказчику и часто бывает, что документация не ведется.
6. В случае разработки веб-сайта, исполнитель обязан учитывать SEO оптимизацию для сайта, а именно: описание изображений, страниц…
   Причина: экономия времени на “мелочи”, что в зависимости от условий договора может привести к финансовым потерям заказчика (разработчик ПО экономит время/финансы).
7. Тестирование системы должен обеспечивать разработчик системы.
   Приемка заказчиком готового модуля не должна превращаться в тестирование системы, т.е. разработчик обязан взять на себя устранение выявленных “багов” клиентом за свой счет. Это нужно для того, чтобы обеспечить качественное тестирование продукта со стороны разработчика. К моменту, когда разработчик говорит “сделано” и начинается тестирование на стороне клиента — “баги” правятся бесплатно.
8. Ответственность за размещение проекта на стороне заказчика берет на себя разработчик. При этом заказчик обязан обеспечить выполнение технических требований для площадки.
   Причина: размещение проекта на стороне заказчика иногда может вызвать определенные трудности, что может привести к “шапкозакидательству”, поэтому ответственность по размещению и настройке сервера должна быть на стороне разработчика ПО.
9. В случае если разработчик ПО вынужден прибегнуть к помощи специалистов вне своей команды он обязан взять на себя все сопутствующие риски за утечку, потерю данных или любой другой ущерб, который может нанести своим действием или бездействием сотрудник со стороны.
   Причина: бывает, что у разработчика может заболеть, уволиться и т.д. кто-нибудь из сотрудников. В этом случае заказчик должен быть застрахован.
10. Резервные копии проекта должны обеспечиваться на стороне разработчика не реже 1 раза в сутки. Любые проблемы с потерей данных по проекту должен брать на себя разработчик.
    Причина: здесь нужно обозначить кто несет ответственность за сохранность проекта в случае каких-либо сбоев.
11. Разработчик должен исходить из популярности использования применяемых им технологий при выборе.
    Причина: привязка к собственным технологиям, которые усложнят жизнь в случае перехода заказчика к другому разработчику.

• Поверхностная оценка стоимости разработки проекта целиком, без разбиения на этапы, что может привести к 2х-3х кратному превышению стоимости проекта.
• Не предоставление отчетов о проделанной работе в определенный по договору срок или не возможность контролировать ход разработки со стороны клиента
• Неправильный выбор технологии при реализации технической части, может значительно увеличить стоимость разработки.
• Отсутствие в команде разработчика нужных специалистов, что увеличивает время и стоимость разработки.
• Фиксированная установка стоимости разработки проекта или модуля и дальнейшее увеличение стоимости за каждую мелочь, которую обе стороны понимали по разному.
• Фиксированная установка стоимости разработки проекта — более высокий риск заставляет закладывать в стоимость проекта.
• При разработке дизайна не используется прототипирование, а разработка дизайна ведется на основе текстового ТЗ, что в итоге приводит к большому количеству доработок/исправлений и соответственно увеличению стоимости проекта.
• Добавление/усложнение функционала. Можно сделать проще — делают сложней.
• “Красивости” там где они не нужны (можно сказать про админ. часть сайта, если можно использовать css фреймворки для быстрой кастомизации админ. части — начинают разрабатывать с нуля).

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

1. Оплата работы исходя из почасовой оплаты работы сотрудников или усредненной стоимости работы специалиста всей команды разработчика. Оценку этапов разработки делать необходимо. Почему считаю эту форму расчета цены оптимальной:
   
   • Не требует очень щепетильного подхода в оценке проекта, которую сделать на 100% точной практически нереально. В случае если оценка сделана неверно и разработчик ПО это начинает понимать, то происходит “ущемление” функционала везде где только можно, что в итоге будет сказываться на удобстве использования.
   • Улучшает взаимопонимание между разработчиком ПО и клиентом, т.к. основная задача сводится к принципу — “сделай качественно и быстро”, а не “вложись в жесткий бюджет и как будет работать так и хорошо”.
   • Клиент, на основе ежедневных отчетов о затраченных часах, может видеть какое время тратят сотрудники на разные блоки при разработке, что дает понимание скорости и качества работы сотрудников разработчика ПО.
   • Взаимодействие между заказчиком и менеджером-проекта ведется максимально на прямую, т.е. при использовании skype, телефонов и т.д.
2. Только 2х недельные отчеты и планы должны пересылаться в обязательном порядке по почте (для контроля).
3. Клиент предоставляет прототип приложения или его разрабатывает команда разработчика ПО, если это необходимо:
   • Упрощает понимание основного функционала проекта.
   • Увеличивает общую скорость разработки проекта.
   • Понятные требования к функционалу как у заказчика так и у разработчика.
   • Ясное понимание куда будет двигаться проект.
4. Система управления проектами для ведения хода реализации проекта и возможности мониторинга процесса, времени разработки, потраченной на каждую задачу в отдельности. К сожалению, доступ редко предоставляют разработчики.
5. Желательно, чтобы весь проект делала одна команда, т.е. не должно быть такого, что один этап делает одна компания, другой — другая и т.д.
6. Контрольные точки (“забег”) каждые 2 недели- оптимальное время для контроля проекта.
7. В разработке предпочтение отдается известным фреймворкам, также для более простой адаптации в случае какой-либо ситуации, когда необходимо передать проект другим разработчикам.
8. Качественное тестирование на стороне разработчика — прямая обязанность. При передаче клиенту проекта или какой-то его части, всё должно быть проверено досконально.
9. Поддерживать разные браузеры — прямая задача разработчика