Как мы принимаем проекты на техподдержку

Переход проектов на техподдержку от одного разработчика к другому

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

Возникает резонный вопрос: Что заставляет заказчика менять команду разработчиков на новую, отказавшись от прежней, которая разработала этот проект с нуля и досконально его знает?

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

Почему же такое происходит? Очень часто новые проекты со стороны заказчика курируют совсем «зеленые» менеджеры, которые ранее не были никоим образом вовлечены в процесс разработки, все для них новое в области веб-разработки. И выбор компании-разработчика для таких людей естественно осложнен. Приходится полагаться больше не на выявление профессиональных возможностей потенциальных исполнителей, а на свою интуицию. А если в качестве куратора проекта выступает сам владелец, то не в последнюю очередь на выбор влияет озвученная потенциальными подрядчиками стоимость разработки. Естественно владелец проекта будет смотреть в сторону более низкой стоимости, не беря в расчет все возможные риски, связанные с этим.

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

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

Запрос доступов к проекту

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

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

Возвращаясь к вопросу о доступах, стоит отметить, что нам важно проанализировать именно код проекта, неважно его физическое размещение. Это может быть:

• доступ к репозиторию исходного кода (git, svn, mercurial),
• доступ к боевому проекту (SSH- или FTP-доступы к серверу/проекту),
• доступ к тестовой версии проекта (SSH- или FTP-доступы к копии на тестовом хосте),
• бекап-архив проекта (в этом случае мы разворачиваем сайт на своем сервере),
• доступ (логин/пароль) в админку сайта с возможностью просмотра исходников кода (этот вариант нежелателен, но, в крайнем случае, используется).

Компания Максимастер дорожит своей репутацией, поэтому можем гарантировать любому потенциальному клиенту, который предоставит нам доступы к своим серверам/проектам, что эти доступы не попадут третьим лицам и не будут использованы нами в целях, отличных от согласованных с клиентом. При необходимости перед выдачей доступов подписываем NDA (соглашение о неразглашении коммерческой тайны).

Порядок работы с новыми проектами

Все обращения к нам новых клиентов за услугой технической поддержки можно разделить условно на два типа (подход к обработке которых несколько разнится):

А. Клиент интересуется конкретными доработками/исправлениями по проекту и/или разработкой нового функционала.

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

Бывают случаи, когда клиенты просто просятся на техподдержку, при этом на первом этапе никаких задач не ставят. Но это скорее исключение из правил. И как уже было сказано выше, проекты без веской причины не переходят от одного подрядчика к другому. В любом случае таких заказчиков мы просим озвучить несколько задач, которые они планируют в перспективе реализовать.

А. Клиента интересуют конкретные доработки/исправления

Работа с такими обращениями ведется по следующему алгоритму:

1. Запрашиваем доступы к проекту
2. Подписываем NDA (при необходимости)
3. Получаем доступы от клиента и сообщаем о сроках подготовки оценки (это может быть как 1-2 дня, так и 1-2 недели, в зависимости от объема и сложности задач, однозначности и понятности их постановки)
4. Изучаем задачи, анализируем код проекта в целом и в особенности ту его часть, что связана с задачами. Формируем оценку по трудоемкости и стоимости доработок. Для крупных задач делаем подробную детализацию, в которой оценка дана по каждому пункту. При необходимости даем комментарии по отдельным пунктам (обосновываем трудоемкость, предлагаем несколько вариантов решения с перечислением достоинств и недостатков каждого варианта и т.д.)
5. Сообщаем клиенту получившуюся оценку и согласовываем ее. Если клиент одобряет ее, то переходим к следующему шагу. Если нет, то ищем компромиссные решения, упрощаем задачи, выбираем другой подход к их решениям и делаем новую оценку (для крупных задач может быть несколько таких итераций).
6. Заключаем договор на техподдержку.
7. Начинаем работать по задачам.

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

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

Б. Клиент жалуется на плохую работу сайта в целом

Работа с такими обращениями ведется по следующему алгоритму:

1. Запрашиваем доступы к проекту, для таких обращений рекомендуется предоставить SSH-доступы к серверу
2. Подписываем NDA (при необходимости)
3. Получаем доступы от клиента и проводим первичный (бесплатный) аудит кода проекта. (Иногда для решения проблем заказчика необходимо привлечение системного администратора. Взаимодействие по вопросам системного администрирование описано в другой статье «Поддержка веб-проектов по услугам системного администрирования». Здесь же будем говорить именно об аудите кода проекта)
4. Сообщаем клиенту о результатах первичного аудита кода проекта.
   В зависимости от обнаруженных разработчиками недочетов проекта может быть предложено проведение полного аудита по одному или нескольким направлениям:
   — аудит качества кода (соответствие стандартам и принципам)
   — аудит производительности
   — аудит безопасности кода
   и озвучивается трудоемкость/стоимость таких аудитов.
5. Если клиент одобрил оценку трудоемкости по выбранным направлениям полного аудита проекта, то заключается договор на проведение этого аудита.
6. Проводится полный аудит кода проекта и формируется отчет с итогами. В зависимости от выбранных направлений в отчет может входить:
   — общая характеристика качества кода с приведением примеров некорректного кода и последствий к чему этот код может привести;
   — описание всех найденных узких мест в порядке их влияния на общую производительность проекта (перечень файлов с неоптимальными участками кода, неоптимальными запросами в БД и т.д.);
   — потенциально опасные файлы и участки кода, которые могут снизить безопасность проекта.
   Также сразу дается оценка трудоемкости/стоимости рефакторинга всех проблемных мест.
7. Согласовывается оценка, по необходимости корректируется фронт работ (формируется техническое задание).
8. Если оценка согласована, то заключается договор на техническую поддержку сайта.
9. Проводятся работы по рефакторингу кода.
10. Продолжаем сотрудничество с клиентами, развиваем проект.

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

И заказчику необходимо будет принять решение:

• либо оптимизировать/исправлять то, что есть сейчас, 
• либо начать с нуля строить проект с правильной архитектурой.

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

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

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

Ознакомиться с проектами, которые мы поддерживаем, и конкретными реализованными нами задачами по этим проектам можно в нашем Портфолио.

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