Завязка
Хочу поднять тему, актуальную для разработчиков и для заказчиков: разработка в удовольствие. Что это, миф или реальность? Существуют ли компании, в которых процесс разработки поставлен так, что приносит удовольствие обеим сторонам: разработчику и заказчику. Ведь в конечном итоге цель у обеих сторон одна — удовлетворенность конечным продуктом.
Оговорюсь, что дальнейшие рассуждения пойдут о веб-разработке относительно сложных и протяженных по времени продуктов.
Рассмотрим стандартный процесс. Есть компания — заказчик, ей нужен продукт. Есть компания разработчиков, им нужно этот продукт воплотить в жизнь. Казалось бы все просто, нет конфликта интересов, цель одна. Но тут естественно появляется но: заказчику продукт нужен в минимально короткие сроки, это требование рынка. Опять же время компании-разработчика стоит недешево. В общем, заказчику нужно быстро, дешево и качественно.
У заказчика часто за спиной уже есть какой-то опыт общения с разработчиками. И довольно часто он, к сожалению, негативный. Продукт сделали некачественно, не в срок, либо вообще не сделали.
Почему так произошло? Опять же, возвращаясь к стандартному процессу, как происходит первый этап взаимодействия заказчика с разработчиком? Заказчик излагает, довольно абстрактно, свою идею. Разработчик дает довольно абстрактную оценку времени выполнения. Вот тут происходит первая и самая главная ошибка — еще практически ничего не зная о продукте, об условиях, нагрузках и многом другом, оценивается время. Хотя довольно логично предположить, что можно оценить только то, о чем знаешь. Но разработчики и заказчики уже попались в первый капкан — оценку нужно сделать как можно быстрее. Ведь нужно утвердить бизнес-планы, графики и еще кучу бумаг, к разработчикам не имеющую никакого отношения.
Кульминация
Приведу аналогию из мира строительства: заказчик просит построить четырехэтажный дом с определенным количеством окон и двумя входами. «Что ж», — думает строитель, «это довольно просто и мы уже строили 8 ми и 9ти этажные дома. Значит этот построим в половину времени от 8ми этажного». Заказчик тоже доволен вынесенными сроками и советует высечь их на арке двери будущего дома. «Стоп, какой арке?», — спрашивает строитель. «Как какой», — еще по-доброму удивлен заказчик. «В районе, где мы строим дом, все дома должны быть с арками». И понеслось…
Это пример одного из вариантов оценок проекта в условиях недостаточности данных о нем — экспертная оценка, оценка на основе уже сделанных проектов. Но, к сожалению, если рассматривать достаточно сложные проекты, она часто близка к попаданию пальцем в небо, поскольку вся “похожесть” есть только в голове оценщика, а на самом деле проект может настолько отличаться от уже готовых, что такие оценки ему не подойдут. И как же это понять, подходит проект под понятие “похож” на этапе “абстрактного описания”? Да никак!
Развязка
В итоге после таких оценок получаем продукт, который не нравится ни разработчику «мы делали его в такие сроки, что стыдно вспомнить, что там внутри». Ни заказчику: «я хотел совсем другого, но они постоянно переносили сроки и в итоге пришлось соглашаться на то, что было, так как нанимать других уже поздно».
И что?
Проблема есть, наверно в этом никто не сомневается. Но где же решение? К сожалению, серебряной пули нет. Нельзя совсем не оценивать сроки, это понятно, но нельзя и оценивать их «сходу» до плотного, по душам, общения с заказчиком. Выясняйте все детали, есть ли субподрядчики, планируется ли дальнейшее «уточнение» задачи. Ведь часто уточнение для заказчика бывает сменой архитектуры для разработчика, что не может не отражаться на сроках. Очень важным моментом является общение с заказчиком уже во время выполнения заказа, и не только для уточнения деталей. Объясняйте, почему вы принимаете те или иные решения, это положительно скажется на взаимном доверии.
