Порой лучшая разработка — та, которой не было (ч.1)
Заказчик приходит к разработчику, потому что хочет что-то разработать. Разработчик зарабатывает на разработке, что логично. Поэтому самый очевидный сценарий — внимательно выслушать заказчика, оценить объём работ и прислать смету. А далее все по накатанной: договор, счета, акты всякие, сама разработка, и по пути бы еще не обосраться обеим сторонам. Пока выглядит здраво, верно?
Да, но нет.
Проблема в том, что большинство заказчиков приходят к разработчику уже с принятым в голове решением, мол, «Нам нужен пи*датый конверсионный сайт», или «Нам нужен удобный кастомный ЛК для клиентов, и чтоб с блэкджеком и шлюхами интеграциями всякими, или хотят какую-нибудь систему типа ERP, CRM, CMS, SMS, ПМС, МЧС, ЦК КПСС, ГИБДД, и тд и тп.
Короче, суть понятна, с чем бы ни пришел заказчик, он чаще всего изначально приходит с запросом именно что-то разработать, а не решить конкретные бизнес-задачи.
По моему опыту среднестатистический заказчик — это представитель малого или среднего бизнеса, но только крупный бизнес может позволить себе покупать «руки», а не бизнес-решения. И то, в исключительных случаях, при наличии inhouse-спецов на своей стороне, а также наличия Царя в голове компетенций у руководства, и с учетом кучи прочих вводных.
В результате часто получается корпоративный сюр ситуация в которой разработчик пилит проект по заданию заказчика, до конца не понимая как все должно работать, а заказчик, в свою очередь, ожидает крутого результата на выходе, потому что в его голове всё должно хорошо сложиться как-то само собой.
На выходе имеем сомнительного качества разработку, которая жрет ресурсы на ее поддержание, и недовольного заказчика, потому что увы, «магии не случилось».
Причем де-юре все чисто.
Обязательства по договору выполнены, все строго по ТЗ, да вот только заказчик приуныл и бизнес-задача осталась не решена. Все дружно построили телегу, которая в итоге не едет, и коня нужно постоянно кормить, а то сдохнет. А строить, как оказалось, нужно было вообще условный самолет или корабль. Вот такая херня, собачка.
Результаты:
— Заказчик получил то, за чем изначально и пришел;
— Разработчик заработал бабла;
— Истинные бизнес-задачи не решены, цели не достигнуты.
Это как в анекдоте про “х” в “ж” с Петькой и Василием Ивановичем. «Вроде как все хорошо, но есть нюанс…»
Разработка — это не цель! Именно в этой точке чаще всего и происходит подмена понятий. Бизнесу редко нужен конкретные инструменты или разработка сами по себе.
Ему нужно не терять заявки. Быстрее обрабатывать заказы. Контролировать сотрудников. Сократить ручную работу. Увеличить продажи. В конце концов — больше зарабатывать и меньше тратить!
И вот здесь для меня проходит граница между подрядчиком по разработке и технологическим партнёром.
Подрядчик отвечает на вопрос: «Сколько будет стоить это разработать?» А технологический партнёр сначала задает контр-вопрос: «Что у вас сейчас не работает и какой результат вы хотите получить?», а потом отвечает на «Как эту бизнес-задачу лучше решить?»
Иногда хороший проект — это проект, который мы не написали.
