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