Как сократить оценку на разработку через обследование кода
Привет, VC! На связи Антон, техдир Metalcode. У нашей команды 10-летний опыт разработки еком-проектов на php, битрикс. От типовых решений Аспро до сложной кастомной разработки с десятками интеграций.
В этой статье разбираю один из процессов разработки, который часто вызывает вопросы у заказчика.
Кому будет полезно: маркетологам, менеджерам проектов, руководителям, ответственным за digital-направление в компании.
Ситуация: ставите подрядчику задачу по разработке, а он говорит, что нужно заложить время на обследование функционала.
Какое обследование? МРТ программисту хотите сделать за мой счет?
Тут все просто. В проекте много «темных зон». Они появляются по следующим причинам:
- крайне редко весь проект собран одним разработчиком, чаще это команда или проект достался от предыдущего подрядчика;
- для разработки используется фреймворк и библиотеки, они разработаны другими программистами;
- интеграции со сторонними сервисами (в еком-проектах уровня энтерпрайз бывает собрано до 20-30 сервисов). Даже если у вас небольшой проект, несколько интеграций там наверняка найдется.
Поэтому у разработчика редко есть исчерпывающее знание проекта и зависимостей. Эффект усиливается отсутствием документации.
Хорошо, допустим мне понятно, почему разработчик не знает весь проект наизусть. Что он будет делать во время своего «обследования»?
Он изучит функциональность, которая связана с задачей и проведет тесты, например:
- нужно доработать функционал — обследует, что есть, куда писать код, как новое решение будет взаимодействовать со старой функциональностью;
- нужно разработать новый функционал — уделит время проектированию, архитектуре, набросает скелет, проверит варианты реализации;
- нужно перейти на новое API — обследует старые методы, изучит новые;
- нужно что-то обновить на сервере или внутри проекта — проведет тесты на копиях для разработки, соберет нюансы и подводные камни;
Почему не можете оценить задачу сразу, без этих дополнительных действий?
Оценить можно, но поверхностно.
Запрос на обследование не предполагает учиться за счет заказчика. Он позволяет выбирать более качественное и эффективное решение, за счет перехода от теории к практике.
Пару часов никак не покачнут бюджет, но могут дать серьезную пользу. В том числе сэкономить бюджет.
Как понять, что подрядчик не злоупотребляет обследованиями?
Всех недобросовестных исполнителей, которые пытаются отлынивать под видом обследования видно сразу. Потому что обследование — это работа, после которой должны быть результаты. Позитивные, негативные, прорывное или тупиковое решение, но должно быть.
Что будет на выходе? В чем польза?
Результатом будет документ в котором разобраны основные аспекты будущего решения.
Берем исходные бизнес-требования и превращаем их в детальное ТЗ, подсвечиваем нюансы.
А также финальная оценка, которая может быть меньше поверхностной, за счет отсечения рисков, которые исполнитель закладывает из-за сомнений в выбранном решении или неполной картинке зависимостей проекта.
Когда лучше обследовать?
Лучше всего обследовать на этапе оценки, прежде чем выдать финальную оценку.
И что, теперь каждая задача этого требует?
Однозначно нет. Задачи разные. Как правило обследовать нужно когда задача сложная и затрагивает много зависимостей.
Какая задача точно требует обследования?
Если оценка выходит за рамки типовой. Если ощущаются сомнения со стороны подрядчика, и кажется что он перекрывает риски лишними часами.
При каком формате сотрудничества это подходит?
- при работе по фиксу может спасти бюджет, срезав лишние риски;
- при ТМ корректнее проставить приоритет на задачу.
Обследование кода — это инструмент разработки, направленный на повышение эффективности и выбор лучшего решения задачи. Значит не стоит его бояться и даже наоборот, если ваш подрядчик закладывает излишние часы на задачу перекрывая риски — можно предложить ему взять ресурсы на обследование, часто это помогает сократить расходы.
Больше полезной информации про разработку еком-проектов в моем телеграм-канале.