Автосервис VS Разработка ПО

Недавно, начав заниматься ремонтом автомобиля, я понял, что деятельность автосервиса очень похожа на разработку ПО в аутсорсинговой компании. И если проводить параллели, то можно много почерпнуть из сферы, которая существует уже более века.

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

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

Второй случай: клиент привозит автомобиль в сервис, утверждая, что у него что-то не работает, и он хочет что-то улучшить. Однако, это не просто рядовой Mercedes или Toyota, а неизвестный Oting, который по заверением клиента, тот же NIssan, только с другого завода. Механики имеют технологические карты на Nissan, но не могут быть уверены в полной аналогичности. Разработчики IT-компаний сталкиваются с аналогичной ситуацией, когда не обладают документацией на конкретное ПО и имеют лишь общую информацию о технологиях и решениях, использованных в нем. Анализ кода, выявление слабых мест и потенциальных рисков требует времени и усилий, которые должны быть оплачены. Разработчики не виноваты в отсутствии документации, поэтому им нужно время, чтобы понять, что они могут сделать.

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

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

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

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

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