Базовые условия сотрудничества

Здравствуйте! Меня зовут Игорь, и я — руководитель компании SmartHead. Мы стоим за честность, открытость и прозрачность наших отношений с партнерами. Поэтому я считаю своим долгом рассказать вам о некоторых нюансах нашей работы, условиях и возможностях еще до начала проекта — так, чтобы мы как можно раньше устранили все несоответствия в ожиданиях друг от друга, и они не привели к проблемам на этапе реализации проекта.

Рабочий график

Мы работаем по производственному календарю РФ с понедельника по пятницу с 10 до 19 часов. В дни национальных праздников Республики Татарстан мы тоже работаем.

При создании календарного плана реализации проектов мы всегда используем только рабочее время наших сотрудников.

Условия сверхурочной работы

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

  • Все непосредственные исполнители задачи добровольно согласны на сверхурочную работу.
  • Работа оплачивается по двойной ставке.
  • График расходования сверхурочных часов согласовывается заблаговременно.
  • Оплачивается все зарезервированное время сверхурочной работы независимо от типа выполняемых работ, наличия или отсутствия необходимых для выполнения работ, информации или материалов, а так же самих задач на выполнение.

Политика в области качества

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

К сожалению, даже у нас иногда возникают сложности и ошибки. Ведь услуги, которые мы оказываем, являются результатом уникального интеллектуального труда. А люди, к сожалению, иногда ошибаются. Разумеется, мы всегда стараемся сделать так, чтобы неприятности подобного рода не возникали, но также надеемся на ваше понимание.

Если у вас возникли любые комментарии относительно процесса работы с нами или полученного результата — пожалуйста, напишите мне по адресу igor@smarthead.ru. Я обязательно отвечу и постараюсь сделать все возможное, чтобы удовлетворить ваши ожидания.

Процесс коммуникации

В качестве основного способа общения с наши​​ми партнерами мы используем электронную почту, а в случае коммуникации по проектным вопросам - Basecamp.

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

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

Скорость реакции

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

В тех случаях, когда это необходимо, мы готовы обсуждать условия SLA и, в случае его подписания, мы сможем предоставить гарантии требуемых сроков ответа.

Условия планирования и выделения ресурсов

В начале проекта мы договариваемся о том, каким образом мы будем выделять ресурсы для проекта. Чаще всего, если речь идет про проекты с фиксированным объемом работ и сроком, ресурсы (люди, выполняющие задачи по проекту) резервируются в соответствии с планом-графиком выполнения проекта. Есть ряд нюансов, о которых я хочу рассказать вам чтобы вы лучше понимали, на что стоит и не стоит рассчитывать при работе с нами.

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

Если вы хотите получить максимально возможную скорость реакции на изменения требований, возможность влиять на приоритеты и очередность выполнения задач, без сложных согласований иметь возможность менять объем работ, то ваш вариант — работа с нами по Agile-методологии. Однако, в этом случае потребуется резервирование команды проекта на 100% рабочего времени и соответственно, оплата всего этого времени на весь срок разработки проекта.

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

Изменение требований

Требования — это список ваших определенных ожиданий от реализуемого проекта, то, что вы ждете от него, что надеетесь получить в результате: что он должен делать, как он должен это делать, как он должен выглядеть, где он будет размещаться, как можно будет его обслуживать. Мы проектируем и реализуем проект на основании требований, полученных от вас, как от носителей основной бизнес идеи.

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

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

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

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

Учет рисков

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

Я хочу отметить особо такой момент: данный список рисков представляет собой наши совместные риски при работе над данным проектом, и, поэтому, должны учитываться как нами, так и вами. Список рисков — это признак открытости отношений между заказчиком и подрядчиком, показатель того, что мы не скрываем возможные подводные камни, способ увеличения вероятности успешного завершения проекта.

Что является ошибкой, а что нет

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

Ошибкой не является реализация какого-то поведения системы на усмотрение разработчика, если на это не было дополнительных требований. Ошибкой не является еще не реализованное требование, если его реализация запланирована в рамках проекта в одном из будущих этапов.

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

Ответственность за допущенные ошибки, гарантийные сроки

Мы всегда предлагаем делать небольшой временной зазор между завершением реализации проекта и запуском проекта в промышленную эксплуатацию. Это время стоит отвести на опытную эксплуатацию — для ограниченной группы пользователей — чтобы получить обратную связь и устранить все проблемы, не обнаруженные в процессе тестирования. Все ошибки, выявленные в процессе опытной эксплуатации, устраняются бесплатно и с высоким приоритетом.

По умолчанию, на законченный проект, мы даем гарантийный срок — 1 месяц. Это значит, что ошибки в реализации, найденные в течение этого срока будут устраняться нами бесплатно и в рамках приоритетных задач. Однако, мы готовы обсуждать этот срок в контексте каждого проекта. После истечения этого срока, мы не можем гарантировать быстрое и бесплатное устранение проблем (однако за все время нашей работы еще ни разу мы не брали деньги за устранение собственных ошибок).

Тестирование

В первую очередь при проведении тестирования мы стремимся выявить обеспечение реализацией требований, зафиксированных в Техническом задании и макетах. Исходя из этого строится политика тестирования. Тестовые сценарии разрабатываются на основе вариантов использования (пользовательских сценариев) и призваны выявить возможность корректного выполнения пользовательской задачи.

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

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