Как сократить оценку на разработку через обследование кода

Привет, VC! На связи Антон, техдир Metalcode. У нашей команды 10-летний опыт разработки еком-проектов на php, битрикс. От типовых решений Аспро до сложной кастомной разработки с десятками интеграций.

В этой статье разбираю один из процессов разработки, который часто вызывает вопросы у заказчика.

Как сократить оценку на разработку через обследование кода

Кому будет полезно: маркетологам, менеджерам проектов, руководителям, ответственным за digital-направление в компании.

Ситуация: ставите подрядчику задачу по разработке, а он говорит, что нужно заложить время на обследование функционала.

Какое обследование? МРТ программисту хотите сделать за мой счет?

Тут все просто. В проекте много «темных зон». Они появляются по следующим причинам:

  • крайне редко весь проект собран одним разработчиком, чаще это команда или проект достался от предыдущего подрядчика;
  • для разработки используется фреймворк и библиотеки, они разработаны другими программистами;
  • интеграции со сторонними сервисами (в еком-проектах уровня энтерпрайз бывает собрано до 20-30 сервисов). Даже если у вас небольшой проект, несколько интеграций там наверняка найдется.

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

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

Он изучит функциональность, которая связана с задачей и проведет тесты, например:

  • нужно доработать функционал — обследует, что есть, куда писать код, как новое решение будет взаимодействовать со старой функциональностью;
  • нужно разработать новый функционал — уделит время проектированию, архитектуре, набросает скелет, проверит варианты реализации;
  • нужно перейти на новое API — обследует старые методы, изучит новые;
  • нужно что-то обновить на сервере или внутри проекта — проведет тесты на копиях для разработки, соберет нюансы и подводные камни;

Почему не можете оценить задачу сразу, без этих дополнительных действий?

Оценить можно, но поверхностно.

Запрос на обследование не предполагает учиться за счет заказчика. Он позволяет выбирать более качественное и эффективное решение, за счет перехода от теории к практике.

Пару часов никак не покачнут бюджет, но могут дать серьезную пользу. В том числе сэкономить бюджет.

Как понять, что подрядчик не злоупотребляет обследованиями?

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

Что будет на выходе? В чем польза?

Результатом будет документ в котором разобраны основные аспекты будущего решения.

Берем исходные бизнес-требования и превращаем их в детальное ТЗ, подсвечиваем нюансы.

А также финальная оценка, которая может быть меньше поверхностной, за счет отсечения рисков, которые исполнитель закладывает из-за сомнений в выбранном решении или неполной картинке зависимостей проекта.

Когда лучше обследовать?

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

И что, теперь каждая задача этого требует?

Однозначно нет. Задачи разные. Как правило обследовать нужно когда задача сложная и затрагивает много зависимостей.

Какая задача точно требует обследования?

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

При каком формате сотрудничества это подходит?

  • при работе по фиксу может спасти бюджет, срезав лишние риски;
  • при ТМ корректнее проставить приоритет на задачу.

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

Больше полезной информации про разработку еком-проектов в моем телеграм-канале.

66
4 комментария

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

1
Ответить

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

1
Ответить