Подумал-подумал — и решил сюда написать.

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

Так вот, собственно проблема. До какой степени оправданно (меня интересует мнение публики по опыту успешного внедрения своих проектов) идти навстречу заказчикам в такой ситуации? Вот два конкретных случая.

В одном заказчик говорит: "В той табличке, которую мы зашлем в вашу программу, будут не только корректные данные, но и некорректные. Если для какой-то из записей вы не найдете соответствующую ей запись в своей мастер-таблице, просто пропускайте ее." В таком случае, даже если у них самих в таблице полный ералаш, мы радостно скушаем все то, что не сможем точно определить как некорректные данные. Сначала я думал отменять все импортирование при обнаружении некорректности, сейчас предлагается делать вид, что ничего не было. Вариантом было бы потребовать от заказчика сливать нам не все подряд, а фильтровать на их стороне, но тогда они говорят "Мы хотим просто слать вам подряд все из нашей собственной таблички, и не напрягать мозги какой-то фильтрацией". И как же лучше поступить — пойти навстречу или стоять на своем?

Другой случай. У каждой организации, прописанной в БД, может быть несколько торговых точек. Но может быть и всего одна. В последнем случае заказчик не желает возиться с торговыми точками для данной организации, и говорит "сделайте так, чтобы, если у данной организации нет торговых точек, считается, что есть всего одна". То есть в каждой аналитической процедуре тогда придется рассматривать два варианта: если точки есть, то импортированные данные привязаны к точкам, в противном случае — прямо к организациям. Это притом, что на самом деле данные всегда определяются в точках, а вот если она всего одна, то вместо номера точки указывается NULL. Теряется логика кода, размывается структура БД, и все из-за того, что отделу программистов у заказчика лень написать маленькую формочку для одновременного редактирования данных об организации и ее торговых точках (ну, чтобы не заставлять оператора лазить по разным таблицам, что, собственно, его и раздражает, если точка всего одна). Опять же вопрос — требовать у них привести базу в логичное состояние или соглашаться на такой бред? Есть и еще один вариант, но в данной ситуации он недоступен. Можно было бы при импортировании их данных самостоятельно вводить недостающие точки и привязывать к ним "по умолчанию" данные без номера точки. Но если считать, что такое невозможно, то какую позицию лучше занять, имея альтернативу "или-или"?

Лучше — означает: чтобы и заказчик приобрел продукт, и не пришлось ради этого жертвовать надежностью или внутренней (а она обязательно влияет на внешнюю, видимую!) логичностью продукта.

Slicer

Здравствуйте, Slicer [Mirkwood], Вы писали:
SM>Так вот, собственно проблема. До какой степени оправданно (меня интересует мнение публики по опыту успешного внедрения своих проектов) идти навстречу заказчикам в такой ситуации? Вот два конкретных случая.
Ну, по идее это вообще замечательно! Чем больше фидбека, тем больше поводов построить адекватную модель, которая учитывает реальные абстракции, а не только свойственные ровно одной ситуации.
SM>В одном заказчик говорит: "В той табличке, которую мы зашлем в вашу программу, будут не только корректные данные, но и некорректные. Если для какой-то из записей вы не найдете соответствующую ей запись в своей мастер-таблице, просто пропускайте ее." В таком случае, даже если у них самих в таблице полный ералаш, мы радостно скушаем все то, что не сможем точно определить как некорректные данные. Сначала я думал отменять все импортирование при обнаружении некорректности, сейчас предлагается делать вид, что ничего не было. Вариантом было бы потребовать от заказчика сливать нам не все подряд, а фильтровать на их стороне, но тогда они говорят "Мы хотим просто слать вам подряд все из нашей собственной таблички, и не напрягать мозги какой-то фильтрацией". И как же лучше поступить — пойти навстречу или стоять на своем?
Я может чего-то непонимаю, но такие вещи, как интеграция, делаются одним из двух способов:
1. Есть некоторый внутренний АПИ, и для каждого конкретного случая пишется заказная заплатка-плугин, которая и занимается сращиванием данных. Ну и тут уже вопросов не возникает — внешний интерфейс к ней формулируется заказчиком и является частью ТЗ.
2. Есть некоторый стандартный интерфейс взаимодействия, доступный для понужания IT-отделом заказчика. В таком случае как правило пишется PDF страниц на шестьдесят, и на все вопросы типа "а можно мы вместо данных сюда какое-нть г-цо засунем?" отвечается "можно, но в соответствии с PDF". В самом крайнем случае можно позволить некоторую настройку этого интерфейса, типа реакция на неконсистентные данные — игнор/мэйл-ворнинг/роллбэк.

SM>Другой случай. У каждой организации, прописанной в БД, может быть несколько торговых точек. Но может быть и всего одна. В последнем случае заказчик не желает возиться с торговыми точками для данной организации, и говорит "сделайте так, чтобы, если у данной организации нет торговых точек, считается, что есть всего одна". То есть в каждой аналитической процедуре тогда придется рассматривать два варианта: если точки есть, то импортированные данные привязаны к точкам, в противном случае — прямо к организациям. Это притом, что на самом деле данные всегда определяются в точках, а вот если она всего одна, то вместо номера точки указывается NULL. Теряется логика кода, размывается структура БД, и все из-за того, что отделу программистов у заказчика лень написать маленькую формочку для одновременного редактирования данных об организации и ее торговых точках (ну, чтобы не заставлять оператора лазить по разным таблицам, что, собственно, его и раздражает, если точка всего одна). Опять же вопрос — требовать у них привести базу в логичное состояние или соглашаться на такой бред? Есть и еще один вариант, но в данной ситуации он недоступен. Можно было бы при импортировании их данных самостоятельно вводить недостающие точки и привязывать к ним "по умолчанию" данные без номера точки. Но если считать, что такое невозможно, то какую позицию лучше занять, имея альтернативу "или-или"?

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

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

===== редактируем организацию 1 =====        ===== Торговые точки для организации 1 =====   
Свойство организации 1:[       ]             |Точка 1    [редактировать >>] [удалить >>]|    
Свойство организации 2:[       ]             |Точка 2    [редактировать >>] [удалить >>]|
Свойство организации 3:[       ]             |[добавить точку >>]                       |
[Торговые точки >>]

который требует много лишних действий, сделать вот так:

===== редактируем организацию 1 =====        
Свойство организации 1:[       ]             
Свойство организации 2:[       ]             
Свойство организации 3:[       ]             
Свойство торговой точки 1:[       ]
Свойство торговой точки 2:[       ]
Свойство торговой точки 3:[       ]
[Торговые точки>>]

Пусть даже там показывается тот же диалог 2. Но, во-первых, требуется меньше нажатий на кнопки для ввода основной торговой точки, а во-вторых, теперь придется сделать поддержку "основной" торговой точки для организации, а это улучшит также работу пользователя в тех случаях, когда вторичные точки используются реже. То есть достаточно будет выбрать организацию, а торговая точка подставится сама.
SM>Лучше — означает: чтобы и заказчик приобрел продукт, и не пришлось ради этого жертвовать надежностью или внутренней (а она обязательно влияет на внешнюю, видимую!) логичностью продукта.
Нужно помнить, что логика модели не всегда совпадает с логикой пользователя.

Здравствуйте, Slicer [Mirkwood], Вы писали:

SM>Лучше — означает: чтобы и заказчик приобрел продукт, и не пришлось ради этого жертвовать надежностью или внутренней (а она обязательно влияет на внешнюю, видимую!) логичностью продукта.

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

Здравствуйте, Sinclair, Вы писали:

S>2. Есть некоторый стандартный интерфейс взаимодействия, доступный для понужания IT-отделом заказчика. В таком случае как правило пишется PDF страниц на шестьдесят, и на все вопросы типа "а можно мы вместо данных сюда какое-нть г-цо засунем?" отвечается "можно, но в соответствии с PDF". В самом крайнем случае можно позволить некоторую настройку этого интерфейса, типа реакция на неконсистентные данные — игнор/мэйл-ворнинг/роллбэк.
Если есть готовый продукт, и его продают всем подряд, тогда так и бывает. А если продукт еще только пишется, и feedback оказывает на него огромное влияние, то никакого жесткого прописанного в PDF стандарта нет. Если он все же есть, то это как раз и есть тот ответ на мой вопрос, когда мы говорим: "нет, ребята, так нельзя, а можно только вот так". Но тогда заказчик может начать проявлять недовольство.

S>Т.е. вместо набора диалогов
S>

...
S>

S>который требует много лишних действий, сделать вот так:
S>

...
S>

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

S>Нужно помнить, что логика модели не всегда совпадает с логикой пользователя.
Бога ради! Но здесь эффективность действий пользователя можно сохранить без ущерба для логичности модели. Однако заказчику лень идти на такие усилия, им хочется, чтобы их часть работы была очень мала и проста, а как это отразится на логике модели (которая попросту станет ни с того ни с сего более запутанной), им все равно.

Что скажете?

Slicer

Здравствуйте, Anatolix, Вы писали:

A>Внутренней архитректурой жертвовать нельзя и обычно не нужно, т.к. заказчика внутренняя архитектура не интересует его интересует внешнее поведение программы. В частности в первом случае он не хочет конвертор писать не потому что не считает его правильным а потому что он сам не хочет это делать, а вы именно это ему и предлагаете. Предложите ему компромисс — он согласится.

Очень разумно. Но проблема в том, что а) наш директор не я, б) у нас в команде нет программистов 1С, в) уговорить директора завести собственного 1Сника и платить ему деньги не так уж и просто, г) у заказчиков уже есть свои 1Сники, и по сути мы должны взяться бесплатно делать их работу (в дополнение к нашей части, за которую нам заплатят), что несколько бесит.

Slicer

Здравствуйте, Slicer [Mirkwood], Вы писали:

SM>Так вот, собственно проблема. До какой степени оправданно (меня интересует мнение публики по опыту успешного внедрения своих проектов) идти навстречу заказчикам в такой ситуации? Вот два конкретных случая.
SM>В одном заказчик говорит: ...
SM>Другой случай...

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

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

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

Стандарт — это хорошо. Но опять же вопрос: что именно будет написано в стандарте? Следует ли при его формировании потворствовать каждому желанию заказчика, или делать по-своему и правильно, или как-то еще? Заказчик хочет написать так: мы кидаем в вас подряд нужные и ненужные данные, а вы сами разгребайте; мы делаем минимум работы, а уж вы можете хоть наизнанку вывернуться, но должны сами разруливать тот бардак, что мы вам выгрузим.

Slicer

Здравствуйте, Slicer, Вы писали:

SM> Лучше — означает: чтобы и заказчик приобрел продукт, и не пришлось
SM> ради этого жертвовать надежностью или внутренней (а она обязательно
SM> влияет на внешнюю, видимую!) логичностью продукта.

Сразу отмечу, что не возьмусь предлагать «готовые» решения для поставленных вами конкретных проблем.

Если вы разрабатываете продукт (который, в отличие от проектного решения, не обладает свойством уникальности), вы должны чётко зафиксировать требования, предъявляемые к продукту и реализуемые в нём. Если этого нет, сделайте это сейчас. Лучше поздно, чем никогда, однако ещё лучше — рано. (Там, вообще-то, ещё много чего надо зафиксировать, но в контексте этого обсуждения это не так важно.)

Далее, определите принципы внедрения продукта (иными словами, ведения проектов по поставке решения конкретному заказчику). Если вы решите, что при внедрении продукт должен дорабатываться под требования каждого заказчика, то каждое требование, выставляемое заказчиком, следует проанализировать ещё и вот в каком аспекте: будет ли оно включено в «базовый пакет» — в продукт, который будет в дальнейшем поставляться всем заказчикам? (Я исхожу из того, что разработка базового пакте ведётся параллельно с проектом внедрения.) Если да, то ответ очевиден: это должно быть сделано. Если нет, определитесь, как эти требования влияют на базовую архитектуру.

Например, заказчик не хочет вычищать мусор из таблиц, которые подлежат импорту в вашу систему. Стало быть, вы (а) тратите дополнительные вычислительные ресурсы на отлов мусорных записей и (б) перегружаете свои таблицы мусорными данными, если обнаружить их при помощи стандартных процедур проверки корректности данных не удалось. Это может привести к нарушению нефункциональных требований, определяющих производительность и надёжность системы. Готов ли заказчик смириться с этим? Если нет, требуется доработка процедур импорта данных с целью их оптимизации. Готов ли заказчик оплатить эти работы? Если опять нет, то мы вернулись в исходную точку и можем смело говорить: либо вы вычищаете мусор сами, либо вы миритесь с нестабильностью системы. (Ещё есть вариант: отказываетесь от внедрения, это иногда довольно сильный, хотя и настолько же опасный аргумент.)

В общем и целом, отношение к заказчику должно базироваться на принципе WYGIWYP: What You Get Is What You Paid. Если заказчик готов оплатить работы по «разруливанию бардака», почему бы не поразруливать?

Здравствуйте, Slicer [Mirkwood], Вы писали:

SM>Если есть готовый продукт, и его продают всем подряд, тогда так и бывает. А если продукт еще только пишется, и feedback оказывает на него огромное влияние, то никакого жесткого прописанного в PDF стандарта нет. Если он все же есть, то это как раз и есть тот ответ на мой вопрос, когда мы говорим: "нет, ребята, так нельзя, а можно только вот так". Но тогда заказчик может начать проявлять недовольство.
Ну в таком случае как раз сделайте в настройках опцию, руководящую реакцией на ошибки импорта. Потому, что другой заказчик, весьма вероятно, захочет другого поведения.
SM>Собственно, так и имеет смысл сделать, но — на стороне заказчика, до импорта в нашу программу. Мы вообще по отношению к этому занимаемся только анализом, а удобное редактирование исходных данных должны писать программисты организации-заказчика, т.к. к этим базам данных у нас вообще нет доступа.
Тут, видишь, я не понимаю сути вашей софтины. Я-то полагал, что у вас есть свои собственные данные, и проблема именно в них. Если логика вашей программы не требует наличия торговых точек — пусть не требует, а если требует — то никакого осмысленного поведения в случае их отсутствия изобрести не удастся.
SM>Но вот что делать, если они говорят, что, дескать, не хотят писать логичный и при этом эргономичный интерфейс, а хотят писать простенький (читай — для написания) и по-прежнему эргономичный, хоть и не столь логичный.
Тут меня настораживает то, что каждый заказчик, получается, будет вынужден подстраивать под вас не только свои данные, но и UI. Это резко снижает привлекательность продукта, потому как увеличивает стоимость внедрения. Этого надо по возможности избегать.
SM>Что скажете?
Что надо смотреть в модель

Здравствуйте, Slicer [Mirkwood], Вы писали:

SM>Стандарт — это хорошо. Но опять же вопрос: что именно будет написано в стандарте? Следует ли при его формировании потворствовать каждому желанию заказчика, или делать по-своему и правильно, или как-то еще? ...

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

SM>Заказчик хочет написать так: мы кидаем в вас подряд нужные и ненужные данные, а вы сами разгребайте; мы делаем минимум работы, а уж вы можете хоть наизнанку вывернуться, но должны сами разруливать тот бардак, что мы вам выгрузим.

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

ЗЫ: может у заказчика нет своего программиста или есть, но крайне низкой квалификации (может, шеф подрабатывает? ). В данном случае заказчику легче и выгоднее заплатить Вам, чем нанимать кого-либо с необходимой квалификацией.

Здравствуйте, Slicer [Mirkwood], Вы писали:

SM>Здравствуйте, Anatolix, Вы писали:

A>>Внутренней архитректурой жертвовать нельзя и обычно не нужно, т.к. заказчика внутренняя архитектура не интересует его интересует внешнее поведение программы. В частности в первом случае он не хочет конвертор писать не потому что не считает его правильным а потому что он сам не хочет это делать, а вы именно это ему и предлагаете. Предложите ему компромисс — он согласится.

SM>Очень разумно. Но проблема в том, что а) наш директор не я, б) у нас в команде нет программистов 1С, в) уговорить директора завести собственного 1Сника и платить ему деньги не так уж и просто, г) у заказчиков уже есть свои 1Сники, и по сути мы должны взяться бесплатно делать их работу (в дополнение к нашей части, за которую нам заплатят), что несколько бесит.

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

Из дополнительных советов которые как ты понимаешь в нашей стране бесплатны:
а) С директором можно поговорить
б) Программисты 1С вам не нужны — никто не сказал что решение должно быть со стороны 1С — главное оно должно быть не в ядре вашей системы
в) Можно просто его уговорить взять человека из компании заказичка на субподряд, счет выставив самому же заказчику. Или попросить специалиста для "консультаций" на недельку
г) Если бесит что именно бесплатно — делайте не бесплатно — бабло побеждает зло.

Здравствуйте, Anatolix, Вы писали:

A>Ты знаешь анекдот про то как филин порекомендовал мышам стать ежиками? Вот и я так же могу тебе сказать: я дал стратегическое решение, а грамотное тактическое можно выработать только обладая гораздо более детальной информацией, которую в форуме изложить нельзя.
Да я, в общем-то, и не ожидал готового рецепта, но все же надеялся — вдруг кто-то даст, если был в похожей ситуации? Специфика в том, что нас пока никто не знает, и, как говорится, не они покупают продукт, а мы его продаем.
Ладно, и на том спасибо!

A>б) Программисты 1С вам не нужны — никто не сказал что решение должно быть со стороны 1С — главное оно должно быть не в ядре вашей системы
Ну, в нашем случае все же со стороны 1С

Slicer

Здравствуйте, Sinclair, Вы писали:

S>Ну в таком случае как раз сделайте в настройках опцию, руководящую реакцией на ошибки импорта. Потому, что другой заказчик, весьма вероятно, захочет другого поведения.
Ну то есть как минимум требуемое заказчиком поведение все равно придется реализовывать, несмотря на его бредовость. Ладно, здесь я точку зрения понял
S>Тут, видишь, я не понимаю сути вашей софтины. Я-то полагал, что у вас есть свои собственные данные, и проблема именно в них. Если логика вашей программы не требует наличия торговых точек — пусть не требует, а если требует — то никакого осмысленного поведения в случае их отсутствия изобрести не удастся.
Логика-то требует. Но оператору удобно мыслить категорией "точки по умолчанию" — т.е. если нет уточнений, списываем все на центральный офис. А вот описать такую "точку по умолчанию" как сущность, как одну из точек, их ломает. И это можно понять, но этого нежелания не было бы, будь в их системе нормальный интерфейс редактирования. Чтобы не надо было вручную скакать по таблицам и вбивать данные туда-сюда.
S>Тут меня настораживает то, что каждый заказчик, получается, будет вынужден подстраивать под вас не только свои данные, но и UI. Это резко снижает привлекательность продукта, потому как увеличивает стоимость внедрения. Этого надо по возможности избегать.
Видите ли, в нормальной ситуации мы бы сказали: мы предоставляем фичи, а вот вам совет, как сделать более удобным их использование; и мы выдвигаем ряд требований (диктуемых логикой сферы применения), и вот вам совет, как проще обеспечить их удовлетворение. Но в сложившейся ситуации шеф занял такую позицию: они нам очень нужны, поэтому никаких требований, а делать все просто так, как они скажут. Такие пироги. Вот я и думаю, возможен ли компромисс — и клиента не злить, и модель не рушить. Похоже, придется вызваться и самому поговорить с клиентом о том, от каких своих требований он мог бы отказаться... Опыта такого рода у меня покуда не было, почему и не хотелось идти на это, но, видимо, единственная альтернатива этому — делать все как скажут.

Slicer

Здравствуйте, Slicer [Mirkwood], Вы писали:
SM>Так вот, собственно проблема. До какой степени оправданно (меня интересует мнение публики по опыту успешного внедрения своих проектов) идти навстречу заказчикам в такой ситуации?

Абстрактный общий совет — обобщать, не теряя частности. На каждое требование каждого частного заказчика пытайся понять насколько оно на самом деле частное, можно ли из него сделать ценную фичу и сколько еще потенциальных заказчиков заплатят за эту фичу в общем или частном виде. В зависимости от принятого решения и реализовывай — либо внешней залепухой, конвертером, хаком системы заказчика и т.д, главное — не трогая свой код, либо оформляй это требование как настоящий change request, находи место в архитектуре, внедряй туда общую часть, реализуй частную, расскажи VP of Marketing что вы теперь leading provider of XXXXX, bringing NN years of XXXX experience to the market, etc (дальше он сам подхватит и допоет).
Ни в коем случае не приноси в жертву архитектуру системы, если ты не видишь перспективы для реализации этого требования. Даже если заказчик платит "нереальное бобло"(тм). Бобло побеждает всё, ты останешься с боблом, но без продавабельной системы. Заказчик быстро поймет что он является для тебя единственным рынком и это будет последнее "нереальное бобло"(тм) которое ты от него увидишь.

SM>Вот два конкретных случая.
//skip
SM>И как же лучше поступить — пойти навстречу или стоять на своем?

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

У нас, например, есть такая тусовка независимых консалтеров и наше поведение скажем в нашем же публичном мейллисте где тусуются юзеры жестко регламентировано нами же — при любом раскладе мы всегда должны дать возможность интегратору придти на помощь юзеру (и развести его потом на бабки, если получится). Мы сами отвечаем только если никто из интеграторов не справился, или это серьезная проблема, которую интегратор решить просто не в состоянии.

SM>Другой случай.
//skip
SM> Но если считать, что такое невозможно, то какую позицию лучше занять, имея альтернативу "или-или"?

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

SM>Лучше — означает: чтобы и заказчик приобрел продукт, и не пришлось ради этого жертвовать надежностью или внутренней (а она обязательно влияет на внешнюю, видимую!) логичностью продукта.

Внутренняя логичность продукта — это ваша игрушка. Вам за нее никто не заплатит.

Здравствуйте, Slicer [Mirkwood], Вы писали:

SM>Подумал-подумал — и решил сюда написать.

SM>Наверняка многие (а не только наш) проекты, которые изначально расчитываются для продажи различным заказчикам, на стадии разработки и начала внедрения оттачиваются на паре-тройке заказчиков. Соответственно, раз приходится убеждать каждого из них в выигрыше от покупки продукта (ведь пока продукт никому не известен), и каждый из них всевозможными способами выеживается, выдвигая свои специфические требования к продукту.

SM>Так вот, собственно проблема. До какой степени оправданно (меня интересует мнение публики по опыту успешного внедрения своих проектов) идти навстречу заказчикам в такой ситуации? Вот два конкретных случая.

Поделюсь опытом. Наш проект фактически разрабатывался по заказам. Покупателей в мире мало — слишком специфичный продукт. Изначально были взяты несколько потенциальных заказчиков, и из них было выжато ВСЕ что можно в плане информации. Это сэкономило масштабные маркетинговые исследования. Потом, когда продукт уже можно было показывать, с ним ездили на презентации/выставки, где скрупулезно собирались и фильтровались высказывания ВСЕХ интересующихся нашим продуктом. Очень многое было добавлено. Проводился также обзор конкурирующих продуктов, давший, опять-таки немало идей. Когда продукт приближался к стадии завершения, с заказчиками была проведена работа и подписан документ, регламентирующий, при каких условиях продукт быдет куплен. Там по пунктам перечислялись необходимые доделки. А вот все что шло ЗА пределами документа(масса полезных фич была добавлена после), подлежало лицензированию и поставлялось за отдельную плату.

Здравствуйте, Slicer [Mirkwood], Вы писали:

SM>Подумал-подумал — и решил сюда написать.

SM>Наверняка многие (а не только наш) проекты, которые изначально расчитываются для продажи различным заказчикам, на стадии разработки и начала внедрения оттачиваются на паре-тройке заказчиков. Соответственно, раз приходится убеждать каждого из них в выигрыше от покупки продукта (ведь пока продукт никому не известен), и каждый из них всевозможными способами выеживается, выдвигая свои специфические требования к продукту.

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

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

SM>Так вот, собственно проблема. До какой степени оправданно (меня интересует мнение публики по опыту успешного внедрения своих проектов) идти навстречу заказчикам в такой ситуации? Вот два конкретных случая.

SM> Вариантом было бы потребовать от заказчика сливать нам не все подряд, а фильтровать на их стороне, но тогда они говорят "Мы хотим просто слать вам подряд все из нашей собственной таблички, и не напрягать мозги какой-то фильтрацией". И как же лучше поступить — пойти навстречу или стоять на своем?

Короче, вы определитесь, с главным — вам деньги нужны? Если нужны, то хорошенько подумайте, кто вам их платит, и, главное, за что. И вы волшебным образом сами ответите на свои вопросы. Я подскажу. Деньги вам платит заказчик, за то, что вы удовлетворяете его потребности, которые вы назвали "выеживаниями". В вашем представлении его выеживания это видимо что-то вроде детского каприза. Так вот, этот "каприз", возможно, единственная причина, по которой он обратился именно к вам. И ваш отказ в той или иной форме выполнить этот "каприз" вполне может стать поводом для дазвиданья. Это вообще, о выеживаниях.

Как поступать в данной конкретной ситуации? Я расскажу, как поступал я, и один из возможных сценариев развития ситуации. Когда клиент выдвигает очередное причудливое требование, я радуюсь. И, за его деньги, выполняю это требование. Заказчик видит, что любая его просьба в том или ином виде выполняется, и тут он вдруг понимает, что он может изменить в системе все! Любой каприз! Аппетит приходит во время еды, короче. Начинают они с действительно важного функционала, а потом когда все готово, начинают заказывать изменение цвета шрифтов.

Доволен ли клиент? Да он лопается от счастья, и их директор рекомендует нашу компанию своему другану, директору другой компании... Почему же там все так довольны? А из-за этого самого внимания к их проблемам, которого он не получит в другой фирме. Люди ценят это гораздо выше, чем стройность вашей архитектуры. Зачем же они потом тратили деньги на глупости типа изменения шрифтов? Послушайте другую историю, от моего друга (он директор маленькой фирмы, торгующей компами) — о капризах клиентов.

- ...понял, то есть ты завышаешь цены на дешевые товары, чтобы не гонять курьера со всякой мелочью.
— Да, прибильность получается маленькая, этим заниматься невыгодно... хотя... есть у меня один клиент, который звонит иногда, и просит привести ему один пиратский диск с софтом, например. И знаешь что? Я всегда отправляю к нему курьера, хот мне это практически в минус. И всегда вежливо треплюсь с их директором по поводу всякой фигни.
— Интересно, зачем?
— А затем, что их директор например, позвонил мне на прошлой неделе, и вдруг, между делом, говорит. "А что Серега, обороты тебе что-ли, поднять?" — "Отчего же не поднять!" — "А что у вас вообще есть?"
— Ха-ха! И что ты ему сказал?
— Я сразу понял, чего он хочет. "Плазменные панели", — говорю, — "по пять тыщ баксов". "А что", — говорит, — "поставлю себе в менеджерскую! Выставляй счет!" Вот поэтому, старичок, я всегда отправляю к нему курьера...

Короче, мораль. Пока клиент готов платить деньги — никаких компромиссов. В противном случае, ему, я бы сказал, придется идти на компромисс. Второй момент — если вам лично с этих денег ничего не перепадает (ни кнутов ни пряников) — то поступайте как знаете, потому что совершенно все равно как постапать.

> Короче, вы определитесь, с главным — вам деньги нужны? Если нужны, то хорошенько подумайте, кто вам их платит, и, главное, за что. И вы волшебным образом сами ответите на свои вопросы. Я подскажу. Деньги вам платит заказчик, за то, что вы удовлетворяете его потребности, которые вы назвали "выеживаниями". В вашем представлении его выеживания это видимо что-то вроде детского каприза. Так вот, этот "каприз", возможно, единственная причина, по которой он обратился именно к вам. И ваш отказ в той или иной форме выполнить этот "каприз" вполне может стать поводом для дазвиданья. Это вообще, о выеживаниях.
>
> Как поступать в данной конкретной ситуации? Я расскажу, как поступал я, и один из возможных сценариев развития ситуации. Когда клиент выдвигает очередное причудливое требование, я радуюсь. И, за его деньги, выполняю это требование. Заказчик видит, что любая его просьба в том или ином виде выполняется, и тут он вдруг понимает, что он может изменить в системе все! Любой каприз! Аппетит приходит во время еды, короче. Начинают они с действительно важного функционала, а потом когда все готово, начинают заказывать изменение цвета шрифтов.
>
> Доволен ли клиент? Да он лопается от счастья, и их директор рекомендует нашу компанию своему другану, директору другой компании... Почему же там все так довольны? А из-за этого самого внимания к их проблемам, которого он не получит в другой фирме. Люди ценят это гораздо выше, чем стройность вашей архитектуры. Зачем же они потом тратили деньги на глупости типа изменения шрифтов? Послушайте другую историю, от моего друга (он директор маленькой фирмы, торгующей компами) — о капризах клиентов.


Хи-хи-хи. А мы как раз специализируемся на восстановлении учета и этой самой стройной архитектуры, после таких дельцов Что самое интересное, и дельцы хорошо живут и мы не в угаре, восстановление оно по расценкам подороже будет. Правда таких клиентов потом на постоянном обслуживании приходится терпеть, в отношении к программам они обычно малоадекватные. Справедливости ради отмечу, часть из них вырастает до нормальных пользователей.

Здравствуйте, grosborn, Вы писали:

G>Хи-хи-хи. А мы как раз специализируемся на восстановлении учета и этой самой стройной архитектуры, после таких дельцов Что самое интересное, и дельцы хорошо живут и мы не в угаре, восстановление оно по расценкам подороже будет.

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

G>Правда таких клиентов потом на постоянном обслуживании приходится терпеть, в отношении к программам они обычно малоадекватные. Справедливости ради отмечу, часть из них вырастает до нормальных пользователей.
Не могу не посочувствовать. Терпеть малоадекватных к своим программам клиентов действительно тяжело. Я готов вам с этой проблемой помочь — я заберу ваших клиентов, если вы заплатите мне по 100 долларов за каждого.

ЗЫ:

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

Если во главу угла ставить именно "удовлетворение потребностей заказчика" без компромиссов (см.тему), то учет идёт лесом, поскольку заказчик не методист, не может сам оценить последствия своих требований.
Здесь он попросил надпись сделать синим цветом, а там субсчет добавить, потому что не заметил что такой уже есть, а вы ему с песнями и плясками всё сделали, он рад, его прет. Через год приходят аудиторы и бухгалтер отправляется работать на панель, даже если он м, а не ж. Множественные примеры из жизни. Абсолютно точно так же и с другими видами учета, только там всё незаметнее. Такая позиция исполнителей распространена, поскольку позволяет значительно повысить отдачу от клиента и поставить его в зависимость от себя. По вашему посту я понял что вы придерживатесь именно такой позициии и другим советуете. Правильно?

> G>Правда таких клиентов потом на постоянном обслуживании приходится терпеть, в отношении к программам они обычно малоадекватные. Справедливости ради отмечу, часть из них вырастает до нормальных пользователей.
> Не могу не посочувствовать. Терпеть малоадекватных к своим программам клиентов действительно тяжело. Я готов вам с этой проблемой помочь — я заберу ваших клиентов, если вы заплатите мне по 100 долларов за каждого.

Это нормально, в начале своей жизни считать всех потенциально лохами, так держать.

Здравствуйте, grosborn, Вы писали:
G>Это нормально, в начале своей жизни считать всех потенциально лохами, так держать.
Вот это вы очень правильно написали, мы к этому еще вернемся.

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

G>Если во главу угла ставить именно "удовлетворение потребностей заказчика" без компромиссов (см.тему), то учет идёт лесом, поскольку заказчик не методист, не может сам оценить последствия своих требований.
Интересный вы человек. Тему смотрим, да? Так смотрите. Вопрос был об отношению к требованиям заказчика, а не о технологии разработки и внедрения, так? Я и ответил по этому вопросу, так? И повторюсь, во главу угла я ставлю "удовлетворение потребностей заказчика".

Только мне что-то непонятно, это что, автоматически означает, что я при этом не провожу обследование, не строю модель бизнес-процессов заказчика (применяя связку ER + DFD, например), чтобы потом аккуратно отобразить на нее его пожелания? Отметив при этом конфликты с его же моделью бизнес-процессов, и посоветовав решения?

G>Здесь он попросил надпись сделать синим цветом, а там субсчет добавить, потому что не заметил что такой уже есть, а вы ему с песнями и плясками всё сделали, он рад, его прет.
G> Через год приходят аудиторы и бухгалтер отправляется работать на панель, даже если он м, а не ж. Множественные примеры из жизни.
К сведению восстановителям учета — несколько простых фактов. Не то чтобы поспорить — хочу показать вам, как выглядят ваши слова.
1) План счетов утверждается в начале года, его нельзя менять в середине, вот так от балды как вы пишете.
2) Разрабатывает план счетов главный бухгалтер заказчика, под свою ответственность, и никто другой. И уж по крайней мере программеру, аналитику, и специалисту по внедрению платят не за это, у них много своей работы.
3) Если главный бухгалтер компании полный кретин (а это тот самый случай, когда он "не помнит" свой план счетов), то он рано или поздно отправится работать на панель независимо от того, откажесь вы добавлять ему субсчет или нет.
4) Сильно сомневаюсь в вашей способности поправлять главного бухгалтера. Но если таки хватит ума это сделать, то у вас есть шанс после отправления бухгалтера на панель заполучить паяльник в анус от владельца бизнеса. И он будет прав — каждый должен заниматься своим делом.
5) Касательно синего цвета — я не понимаю вашей проблемы за деньги сделать цвет синим. Только не говорите мне, что это плохо повлияет на стройную архитектуру.

G>Абсолютно точно так же и с другими видами учета, только там всё незаметнее.
Так же это как же?

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