Доработать напильником

Наверное, всем в детстве мама рассказывала сказку, как царь послал стрельца Туда-не-знаю-куда принести То-не-знаю-что. И многие, наверное, помнят, что стрелец пошёл в лес и принёс оттуда не то перепёлку, не то тётку, на которой сам потом и женился. Царь же в итоге заработал оргомный геморрой и лишился должности.

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

Давеча друг Kalpa прислал прелюбопытнейший образец техзадания из серии How Not To Do или, говоря русским языком, Хочу-то-не-знаю-что:

В общем идея такая. Нужен интерактивный каталог заказов. Чем-то похоже на Интернет-магазин, но не совсем. То есть работает так. Есть база клиентов с их данными, паспорт, адрес и т.п. К каждому клиенту привязан счет, на который он кладет деньги и с которого они списываются. С другой стороны, есть некий каталог товаров и услуг. Он подвязывается к сторонним фирмам, которые забивают туда свой ассортимент. Каталог содержит как краткую инфу, так и пояснения к товарам. Клиент ,в принципе, неважно как, но в результате по сокетам, отправляет запрос на услугу. Запрос поступает на контрольный монитор к оператору, тот фиксирует, списывает бабки со счета и отправляет клиенту курьера с заказом. Все довольны. То есть система подразумевает, во-первых рабочее место оператора, где у него <загорится лампочка> о запросе и он сможет просмотреть всю инфу и обработать - но это уже дело запросов, было бы откуда смотреть. Во-вторых, некий интерфейс для фирм - партнеров, позволяющий дать инфу о товарах. В-третьих, интерфейс для клиентов. Запросы в любой доступной сокетам форме, вроде xml. Картинки клиенту посылаются просто тупо жпегами. Такой нюанс из-за того, что заказ выполняется не с компа и браузера, а с интерактивных сенсорных панелей, там только сокеты, никакого html. Это самое приблизительное описание. Но сразу говорю, система непростая и должна работать без сбоев.

Итак, для начала давайте определимся, будем ли мы делать каталог заказов, не совсем интернет-магазин или ещё какую неведому зверушку. Помнится, мне как-то заказывали портал-визитку, и даже спустя несколько часов допроса с пристрастием (НКВД нервно курит в застенках) клиент так и не смог человеческим языком объяснить, что же ему нужно и как оно должно выглядеть хотя бы примерно. Ну да это не суть.

Мы имеем некую систему, содержащую в себе "базу клиентов с их данными", куда будут заноситься, помимо Ф. И. О. и адреса, ещё и паспортные данные. А также место работы, состав семьи, сведения о ежемесячном доходе и в качестве обязательного приложения слепок ключа от входной двери и подробный план квартиры с указанием тумбочки, где деньги лежат и времени, когда никого нет дома. Щас! Миль пардон, дорогие сэры, но если уж говорить о платёжных системах, то свои паспортные данные я доверю разве что какому-нибудь уважаемому банку. Так что же получается, мы пишем банк?

А вот и нет! Мы пишем некий загадочный каталог товаров и услуг, куда не менее загадочные сторонние фирмы будут из совершенно непостижимых соображений забивать свой ассортимент. Забивать – это, наверное, пинками заколачивать. А в нагрузку к каждому товару прилагать краткое описание и пояснение к товару – чем отличается одно от другого не совсем понятно, но заказчику видней. Прочие параметры товара, как то: название, артикул, цена, количество, размерность (ёмкость, габариты) и т.д. значения не имеют и, по-видимому, не нужны.

Наконец мы достигли самой увлекательной части марлезонского балета – процесса покупки. Клиент кладёт на свой счет некоторую сумму (ага, я же говорила, что это банк или, как минимум, платёжная система!). Затем, "неважно как, но в результате по сокетам" клиент совершает заказ. Интересно, представляет ли клиент, что такое сокет и как по нему делать заказ? Насколько я понимаю из ТЗ, заказчику это не важно, в данном случае сокеты – головная боль клиента и исполнителя.

После того, как клиент пропихнул заказ в сокет (вспотел, бедняга!), у оператора на контрольном мониторе загорается волшебная лампочка-алярма (alarm bulb). В свою очередь оператор фиксирует (фиксирует своё состояние? фиксирует протез? или, может, рефлексирует?), лезет в клиентский счёт, берёт оттуда немножко денег и оправляет клиенту голубиную почту... эээ, то есть я хотела сказать курьера с заказом на деревню дедушке, которого дома нет. Все довольны! Особенно оператор, который имеет беспрепятственный доступ к клиентским счетам! Главное, чтоб было откуда смотреть и обрабатывать клиента, для чего предусмотрено специальное рабочее место.

В результате всех манипуляций (money благополучно запульнули фиг знает куда) на другом конце соединения клиент получает тупо жпегом по тупой морде. Занавес!

Напоследок одна маленькая рекомендация заказчикам: когда вы составляете подобные техзадания, не спрашивайте в конце, сколько это будет стоить? Задайте исполнителю вопрос, понял ли он ваше ТЗ так, как поняли его вы. И только в случае однозначно положительного ответа начинайте говорить о цене. Иначе придётся долго, больно и дорого дорабатывать напильником.