Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности
|
|
|
Бизнес-логика в БД посредством ХП. за и против
|
|||
|---|---|---|---|
|
#18+
Небольшая предистория: В нашу фирму поступил заказ по разработке скдского ПО. Клиент требовал FireBird. Прикинули ТЗ-ху, утвердили. Вроде было все тип-топ. Когда начали сдавать альфа-версию клиент уперся выдав чтото типа: клиентзачем вам столько хранимых процедур. Мы всегда (а у него есть еще и свои программеры) делали бизнес-логику в приложении. Зачем ее переносить в БД? У нас конечно все офигели... 3 недели разработок коту под хвост. т.к. все было ориентировано на ХП и все действия с базой данных были сведены до атомарного вызова той или иной процедуры. Вот шеф и поставил задачу: Подготовь мне списочек, как можно больше, ЗА то чтобы бизнес-логику держать в БД. Заказчик конечно забугорный и программеры у них там "умные" сидят... все гарварды всякие там позаканчивали и 3-х месячные курсы по дельфям, вот и советуют шнягу вякую. Народ, помогите придумать как можно больше "за" чтобы не переделывать все заново, а то нам пока не удается переубедить клиента :( ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.08.2005, 10:33 |
|
||
|
Бизнес-логика в БД посредством ХП. за и против
|
|||
|---|---|---|---|
|
#18+
Есть такое понятие "толстый сервер", вот от него и надо плясать... >>>делали бизнес-логику в приложении. При разработке приложений С\S, такие высказывания выглядят как предложение продать душу дьяволу... ибо все это от нечистого... >>>сведены до атомарного вызова той или иной процедуры Это стандартный проверенный механизм... Ну и надо доказать это остолопам.... что они лохи позорные.... С графиками загрущенности сервера и клиентских мест... С графиками надежности и безопасности... И побольше умных цифр .... )) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.08.2005, 10:43 |
|
||
|
Бизнес-логика в БД посредством ХП. за и против
|
|||
|---|---|---|---|
|
#18+
sidor36С графиками загрущенности сервера и клиентских мест... С графиками надежности и безопасности... да я бы с радостью... но не хотят они ставить это дело у секбя пока... а у нас то что? ну напихаю я тестовых данных в бд под завязку, а всеравно реальной картины: 200 клиентов из разных концов мира я не смогу им показать. А ведь оптимальность этого метода проявляется какраз когда какой-нить клиент с медленным коннектом выполняет процедурку которая возвращает 0 или 1, но для того чтобы найти этот 0 или 1 перелопачивает горы инфы в базе (образно) тоесть если для медленных коннектов мы минимизируем количество данных передаваемых между сервером и клилентом само собой мы выигрываем, только не ведутся они на это все... они умные... пофиг что вместо мегабайтов по сети 2-3 килобайта трафика ходит, им либо пример на реальных системах подать (что мы сейчас не в силах сделать), либо теоретически интелектом задавить, что в данном случае и требуется :) З.Ы.: самый тупой клиент, это клиент который считает что разбирается в сути вопроса :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.08.2005, 10:51 |
|
||
|
Бизнес-логика в БД посредством ХП. за и против
|
|||
|---|---|---|---|
|
#18+
Крик о помощи :)200 клиентов обшибся - 200 тысяч имелось ввиду :) З.Ы.: да и ваще фаерберд для такой системы был не лучшим решением ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.08.2005, 10:53 |
|
||
|
Бизнес-логика в БД посредством ХП. за и против
|
|||
|---|---|---|---|
|
#18+
а FireBird Classic ? или SS ? (судя по всему у Вас ошибка проектирования, а клиент прав) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.08.2005, 11:08 |
|
||
|
Бизнес-логика в БД посредством ХП. за и против
|
|||
|---|---|---|---|
|
#18+
не знаю, как для FB, а для ms есть такие аргументы 1. Минимизация траффика, особенно, когда действительно люди ведут обработку данных и расчеты на клиенте. на сервере всяк спокойнее 2. безопасность. надежнее дать права на процедуру и зашить в нее логику обработку данных, чем раздавать права на таблицы и затем пытаться реализовать сохранность данных на триггерах 3.кэширование планов запросов, особенно хорошо смотрится при большом числе пользователей - реальная экономия на парсинге и оптимизации запроса 4. возможность изменения логики работы системы в одном-единственном месте 5. современные сервера обеспечивают бОльшую надежность, чем современные клиенты, соответсвенно там зачастую проще реализовывать обработку ошибок и всё такое (проще в глобальном смысле) 6. независимость клиента от структуры данных. клиент может и не знать, что база изменилась до неузначаемости (опять-таки, п.4) -- ------------------------- There's no silver bullet! Posted via ActualForum NNTP Server 1.3 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.08.2005, 11:15 |
|
||
|
Бизнес-логика в БД посредством ХП. за и против
|
|||
|---|---|---|---|
|
#18+
1. Уменьшение сетевого траффика 2. Хранимые процедуры выполняются в адресном пространстве сервера - выше быстродействие (т.е. рядом с данными) - уменьшение времени реакции системы 3. ХП хранится как откомпиленый код с уже готовым планом выполнения запросов - уменьшение времени реакции системы 4. Изменение бизнес-логики не требует перекомпиляции и переустановки клиентского ПО (особенно критично на этапе опытной эксплуатации) - снижение совокупной стоимости владения. 5. Снижение требований к клиентским компам - опять же снижение совокупной стоимости владения. 6. Язык разработки ХП "заточен" для работы с данными, в отличие от васиков, С, дельфей и т.д... - повышается скорость разработки = снижение трудоемкости = снижение стоимости разработки И тд и тп... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.08.2005, 11:17 |
|
||
|
Бизнес-логика в БД посредством ХП. за и против
|
|||
|---|---|---|---|
|
#18+
Мы просто всем сомневающимся клиентам демонстрируем работу нашего ПО на низких каналах связи. Приезжаем с ноутбуком, на нем установлено клиентское приложение с 2 типами подключений - одно напрямую через хост нацелено на консолидированную БД в нашей конторе, другое на локальную СУБД, связанную с консолидированной через оффлайн-репликацию по FTP, опять же в нашей конторе. Втыкаем BlueTooh-Adapter, соединяем через GRPS, демонстрируем, как работает клиент с консолидированной БД через хранимки, проводим изменения сверху данных узла, принадлежащих ноутбуку. Конечно не быстро, но достаточно удовлетворительно. Дальше подрубаем того же клиента, но к локальной СУБД, так же проводим изменения, запускаем репликацию, показываем что в обоих версиях клиента что в консолидированной, что в удаленной изменения были проведены и отображены. Таким образом демонстрируем, что на низких и даже не постоянных каналах доступа можно спокойно организовывать работу удаленных точек, причем работа может вестись в смешанном режиме, например у удаленного узла все клиентские приложения работают напрямую с консолидированной, а локальная БД периодически реплицирует на себя изменения. В случае падения канала будет достаточно перевести клиентские приложения на локальную БД и работа не будет остановлена, только что появится задержка в обмене данных между центром и удаленным узлом, равная периоду проведения репликации. Дальше уже достаточно показать, как с помощью ХП и триггеров организована система доступа прав от самих обьектов БД до бизнес-логики, централизованное администрирование удаленных узлов, автоматическое обновление структуры БД через репликацию и легкость сопровождения клиентского приложения и вопросы отпадают сами собой. Дальше обычно клиенты начинают упираться в платформу клиентского приложения, настаивая на веб-интерфейсе, чтоб было круто, но это уже другая тема разговора :) Ну а к Locky я бы добавил: 7. Облегчение логики клиентского приложения, увеличивает легкость его сопровождения 8. Так как FB поддерживает SELECT FROM ХП(), то это позволяет скрывать от клиента сложную структуру БД, но не обрезать его в использовании SQL и плодить ХП 9. Возможность наращивать функциональность (логирование, репликация через вызовы ХП и т.д.) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.08.2005, 11:21 |
|
||
|
Бизнес-логика в БД посредством ХП. за и против
|
|||
|---|---|---|---|
|
#18+
ASCRUSМы просто всем сомневающимся клиентам демонстрируем работу нашего ПО на низких каналах связи. Приезжаем с ноутбуком, на нем установлено клиентское приложение с 2 типами подключений - одно напрямую через хост нацелено на консолидированную БД в нашей конторе, другое на локальную СУБД, связанную с консолидированной через оффлайн-репликацию по FTP, опять же в нашей конторе. Втыкаем BlueTooh-Adapter, соединяем через GRPS, демонстрируем, как работает клиент с консолидированной БД через хранимки, проводим изменения сверху данных узла, принадлежащих ноутбуку. Конечно не быстро, но достаточно удовлетворительно. Дальше подрубаем того же клиента, но к локальной СУБД, так же проводим изменения, запускаем репликацию, показываем что в обоих версиях клиента что в консолидированной, что в удаленной изменения были проведены и отображены. Таким образом демонстрируем, что на низких и даже не постоянных каналах доступа можно спокойно организовывать работу удаленных точек, причем работа может вестись в смешанном режиме, например у удаленного узла все клиентские приложения работают напрямую с консолидированной, а локальная БД периодически реплицирует на себя изменения. В случае падения канала будет достаточно перевести клиентские приложения на локальную БД и работа не будет остановлена, только что появится задержка в обмене данных между центром и удаленным узлом, равная периоду проведения репликации. Дальше уже достаточно показать, как с помощью ХП и триггеров организована система доступа прав от самих обьектов БД до бизнес-логики, централизованное администрирование удаленных узлов, автоматическое обновление структуры БД через репликацию и легкость сопровождения клиентского приложения и вопросы отпадают сами собой. Дальше обычно клиенты начинают упираться в платформу клиентского приложения, настаивая на веб-интерфейсе, чтоб было круто, но это уже другая тема разговора :) потом подключаете одновременно 10% от 200 тысяч пользователей и начинаете сильно удивляться :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.08.2005, 11:32 |
|
||
|
Бизнес-логика в БД посредством ХП. за и против
|
|||
|---|---|---|---|
|
#18+
авторпотом подключаете одновременно 10% от 200 тысяч пользователей и начинаете сильно удивляться :) Может быть сразу от миллиона пользователей ? Чего уж там мелочиться то с нашей широкой душой, а вдруг столько у клиента пользователей лет так через сто появится ? :) ЗЫ: Да и пожалуйста, 2 штуки коннектов ASA нормально выдерживает, если сервак и ОС правильные :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.08.2005, 11:36 |
|
||
|
Бизнес-логика в БД посредством ХП. за и против
|
|||
|---|---|---|---|
|
#18+
ASCRUS авторпотом подключаете одновременно 10% от 200 тысяч пользователей и начинаете сильно удивляться :) Может быть сразу от миллиона пользователей ? Чего уж там мелочиться то с нашей широкой душой, а вдруг столько у клиента пользователей лет так через сто появится ? :) ЗЫ: Да и пожалуйста, 2 штуки коннектов ASA нормально выдерживает, если сервак и ОС правильные :) а подняться вверх и почитать внимательно посты автора влом :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.08.2005, 11:39 |
|
||
|
Бизнес-логика в БД посредством ХП. за и против
|
|||
|---|---|---|---|
|
#18+
Мне кажется, что вопросы клиента вызваны опасением: "А как это все сопровождать?" Может, имеет смысл об этом поговорить (с клиентом), а не только о технологических преимуществах? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.08.2005, 12:03 |
|
||
|
Бизнес-логика в БД посредством ХП. за и против
|
|||
|---|---|---|---|
|
#18+
> Клиент требовал FireBird. Обычный тупой клиент. > Мы всегда (а у него есть еще и свои программеры) делали бизнес-логику > в приложении. Зачем ее переносить в БД? Обычный продвинутый тупой клиент. > Подготовь мне списочек Добавить к уже сказанному нечего. > все гарварды всякие там позаканчивали Это отличный повод взять с них денег за консалтинг. Эмулировать требуемую нагрузку с разными вариантами реализации, продемонстрировать, что: 1. FB для 200к клиентов... не очень подойдет, 2. единственно возможный вариант реализации бизнес-логики - на сервере, другие варианты - от лукавого. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.08.2005, 12:04 |
|
||
|
Бизнес-логика в БД посредством ХП. за и против
|
|||
|---|---|---|---|
|
#18+
Предлагаю автору спросить о проблеме на форуме Interbase/Fireird, раз уж сервер у него выбран Firebird. Возможно при 200 тыс. клиентов кто-нибуть расскажет про особенности. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.08.2005, 12:49 |
|
||
|
Бизнес-логика в БД посредством ХП. за и против
|
|||
|---|---|---|---|
|
#18+
далеко не всякий бизнес-процесс можно запихнуть в хп-обертку. Есть бп которые требуют промежуточных рассчетов, промежуточных состояний, бп которые оперируют бизнес-объектами в рамках какой-либо единицы работы, и эти бизнес-объекты должны быть сохранены только когда вся единица работы complite. Конечно потом результат этой единицы работы можно завернуть в одну хп и отправить на сервер одним вызовом, но то что до complete гораздо красивее ложиться в промежуточное звено и на нормальный ООП-язык, чем на трудно читаемую логику на TSQL с кучей временных таблиц и еще невесть чего. По поводу скорости разрботки, я все так и придерживаюсь такой позиции: все что можно сгенерировать на основе модели, а именно CRUD, - правильно в хп, если нет - стоит подумать в зависимости от ситуации. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.08.2005, 13:16 |
|
||
|
Бизнес-логика в БД посредством ХП. за и против
|
|||
|---|---|---|---|
|
#18+
авторУ нас конечно все офигели... 3 недели разработок коту под хвост. т.к. все было ориентировано на ХП и все действия с базой данных были сведены до атомарного вызова той или иной процедуры. Ну если в ТЗ ничего не было сказано про ХП или НЕ ХП, то пошлите клиента далеко и надолго - его проблемы, что сразу не оговорил. Но если с клиентом никакого договора нет - тады ой -- Tygra's -- ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.08.2005, 15:41 |
|
||
|
Бизнес-логика в БД посредством ХП. за и против
|
|||
|---|---|---|---|
|
#18+
да фигня это всё. Вопрос из другой плоскости. Договор был заключён, ТЗ подписано, клиент требует пересмотра ТЗ. Posted via ActualForum NNTP Server 1.3 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.08.2005, 15:41 |
|
||
|
Бизнес-логика в БД посредством ХП. за и против
|
|||
|---|---|---|---|
|
#18+
1024 да фигня это всё. Вопрос из другой плоскости. Договор был заключён, ТЗ подписано, клиент требует пересмотра ТЗ. Posted via ActualForum NNTP Server 1.3 Тогда нужно быть максимально конструктивными и пойти клиенту навстречу. Т.е. оговорить масштабы переделки и... сумму, в которую все это выльется для клиента ;0) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.08.2005, 18:07 |
|
||
|
Бизнес-логика в БД посредством ХП. за и против
|
|||
|---|---|---|---|
|
#18+
Если у клиента есть "очень умный" специалист, который считает себя проффессионалом, то никакие ссылки на аргументы солидных людей не дадут результата. Следующий пересмотр ТЗ будет произведен, когда логика будет решена на клиенте, но "не правильно организована структура модулей" или "использованы не удачные объекты". ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.08.2005, 18:10 |
|
||
|
Бизнес-логика в БД посредством ХП. за и против
|
|||
|---|---|---|---|
|
#18+
Все правильно. За отдельные деньги переделать все - вынести логику на клиента, а потом когда он заплачет и попросит все вернуть, продать другую версию. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.08.2005, 18:28 |
|
||
|
Бизнес-логика в БД посредством ХП. за и против
|
|||
|---|---|---|---|
|
#18+
Забугорные специ правы, никогда не делай бизнесс логику на сервере баз данных он для этого не предназначен. Можно сделать если есть корпаративный сервак процессоров на 8 XEON MP минимум. А если пользователей человек 200 будет.... НУЖНО логику делать на сервере приложений, но это уже не подьёная задача для средней организации. Для мелких кантор.... Крутиться на локальной машине твоя логика и берёт данные для работы из базы (хранилище данных) и ВСЁ !!!!!!!!!!!!!!!!!!!!!!!!!!! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.08.2005, 04:33 |
|
||
|
Бизнес-логика в БД посредством ХП. за и против
|
|||
|---|---|---|---|
|
#18+
RЗабугорные специ правы, никогда не делай бизнесс логику на сервере баз данных он для этого не предназначен. Можно сделать если есть корпаративный сервак процессоров на 8 XEON MP минимум. А если пользователей человек 200 будет.... НУЖНО логику делать на сервере приложений, но это уже не подьёная задача для средней организации. Для мелких кантор.... Крутиться на локальной машине твоя логика и берёт данные для работы из базы (хранилище данных) и ВСЁ !!!!!!!!!!!!!!!!!!!!!!!!!!! Можно подумать, что сервер приложений не ту же тучу запросов будет на тех же 200 пользователей слать на СУБД, что и ХП. Другое дело, если "спецы" окромя алгоритмического программирования, то есть ветвления, циклов и курсорчиков по другому никак бизнес-логику делать не умеют, тогда ДА - лучше пусть они ее в клиентских приложениях или 3-ем звене делают. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.08.2005, 07:01 |
|
||
|
Бизнес-логика в БД посредством ХП. за и против
|
|||
|---|---|---|---|
|
#18+
ASCRUS, R давайте не будем вгонять топик в старую идеалогическю войну. "никогда не говори никогда" (с). Все зависит от требований к конкретной системе, ну и опыт, навыки разработчиков не на последнем месте, конечно. Сервер же приложений может и одним батчем весь запрос закинуть, равно как и кучу запросов по сохранению можно обернуть в одну хп-обертку, это уже только логики касается, а никак не способов ее реализации. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.08.2005, 09:21 |
|
||
|
Бизнес-логика в БД посредством ХП. за и против
|
|||
|---|---|---|---|
|
#18+
2 R А если у меня 7 XEON MP - можно БЛ на сервере делать или уже нет? -- Tygra's -- ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.08.2005, 09:26 |
|
||
|
Бизнес-логика в БД посредством ХП. за и против
|
|||
|---|---|---|---|
|
#18+
> Все зависит от требований к конкретной системе Конечно. Если в числе требований максимальное количество геморроя, нулевая сопровождаемость, практическая невозможность апдейтов, невозможность масштабирования, невозможность балансирования нагрузки, тогда, конечно, т. н. бизнес-логику необходимо реализовывать на клиенте. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.08.2005, 09:39 |
|
||
|
Бизнес-логика в БД посредством ХП. за и против
|
|||
|---|---|---|---|
|
#18+
Есть еще один аргумент: обычно у клиента 1 (одна) бизнес-логика и МНОГО клиентов (ну не один) - следовательно лучше иметь 1 (одну) реализацию бизнес-логики в ОДНОМ месте (сервер), чем воспроизводить эту реализацию многократно и с возможными ошибками на нескольких клиентах (нескольких версиях клиента). Тут не следует смешивать бизнес-логику и обработку данных. Бизнес-логика = набор правил, при выполнении которых база остается в логически непротиворечивом (и, следовательно, работоспособном) состоянии. Естественно, требовать выполнение таких правил следует на сервере, ну а уж каким способом (триггера, процедуры или что еще) - дело десятое. Обработка данных = ввод, изменение, перерасчеты, расчет каких-то особых величин на основе данных базы и т.д. и т.п. могут выполняться и на клиенте - это уменьшает нагрузку на сервер. При этом клиент может проверять полностью или частично и бизнес-логику, что НИКОИМ ОБРАЗОМ НЕ ОТМЕНЯЕТ необходимость контроля этой самой логики на сервере. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.08.2005, 10:09 |
|
||
|
Бизнес-логика в БД посредством ХП. за и против
|
|||
|---|---|---|---|
|
#18+
guest_20040621 Конечно. Если в числе требований максимальное количество геморроя, нулевая сопровождаемость, практическая невозможность апдейтов, невозможность масштабирования, невозможность балансирования нагрузки, тогда, конечно, т. н. бизнес-логику необходимо реализовывать на клиенте. Все это весьма и весьма спорно. Рекомендую почитать Фаулера "Aрхитектура корпоративных программных приложений". http://www.books.ru/shop/books/156126 p.s. и не на клиенте, а в среднем звене. А для масштабирования... уж что что, а среднее звено гораздо проще этому подается. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.08.2005, 10:33 |
|
||
|
Бизнес-логика в БД посредством ХП. за и против
|
|||
|---|---|---|---|
|
#18+
> Все это весьма и весьма спорно. Что именно вызывает у Вас желание поспорить? > Рекомендую почитать Фаулера "Aрхитектура корпоративных программных > приложений". Если Вы мне расскажете, чем корпоративные программные продукты отличаются от некорпоративных, - обещаю: куплю и прочту. > а в среднем звене. А я о чем говорю? Вы же не думаете, что масштабировать нужно сервер бд? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.08.2005, 13:06 |
|
||
|
Бизнес-логика в БД посредством ХП. за и против
|
|||
|---|---|---|---|
|
#18+
>>guest_20040621 Будьте внимательны, что то я не видел тут серьезных предложений, ни от автора ни от участников в клиента все перенести. Никто об этом всерьез не говорил. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.08.2005, 13:35 |
|
||
|
Бизнес-логика в БД посредством ХП. за и против
|
|||
|---|---|---|---|
|
#18+
Крик о помощи :)У нас конечно все офигели... 3 недели разработок коту под хвост. т.к. все было ориентировано на ХП и все действия с базой данных были сведены до атомарного вызова той или иной процедуры. Вот шеф и поставил задачу: Подготовь мне списочек, как можно больше, ЗА то чтобы бизнес-логику держать в БД. Заказчик конечно забугорный и программеры у них там "умные" сидят... все гарварды всякие там позаканчивали и 3-х месячные курсы по дельфям, вот и советуют шнягу вякую. Народ, помогите придумать как можно больше "за" чтобы не переделывать все заново, а то нам пока не удается переубедить клиента :( А вот интересно, вы то сами чем руководствовались, когда решили все на процедурах сделать ? Ведь если о чем-то думали, то можете это описать. PS: IMO, 3 недели разработок - это практически ничто :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.08.2005, 17:42 |
|
||
|
Бизнес-логика в БД посредством ХП. за и против
|
|||
|---|---|---|---|
|
#18+
Один1PS: IMO, 3 недели разработок - это практически ничто :) Это, если грубо, $1000 зарплаты, помноженная на количество участников проекта, ну и еще увеличенная раза в полтора, если зарплата белая. Рад за Вас, если для Вас это "практически ничто" :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.09.2005, 09:32 |
|
||
|
Бизнес-логика в БД посредством ХП. за и против
|
|||
|---|---|---|---|
|
#18+
softwarerЭто, если грубо, $1000 зарплаты, помноженная на количество участников проекта, ну и еще увеличенная раза в полтора, если зарплата белая. Рад за Вас, если для Вас это "практически ничто" :) Вот любите вы softwarer все по себе мерять. Откуда вы взяли $1000 зарплаты ? Среднепотолочная московская цифра ? 3 недели - при разработке сколько либо крупного проекта (ну года на 1,5 - 2) это действительно практически ничто. Если проект месяцев на 3-5 тогда да. З.п. тут не при чем совершенно, имеет смысл говорить о трудозатратах за 3 недели в сравнении с трудозатратами на весь проект. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.09.2005, 12:05 |
|
||
|
Бизнес-логика в БД посредством ХП. за и против
|
|||
|---|---|---|---|
|
#18+
Один1Вот любите вы softwarer все по себе мерять. Я люблю мерять наиболее доступным из корректных мерил. Если хотите, расшифрую, почему оно в данном случае корректно. Один1 Откуда вы взяли $1000 зарплаты ? Среднепотолочная московская цифра ? Примерно так. Один13 недели - при разработке сколько либо крупного проекта (ну года на 1,5 - 2) это действительно практически ничто. Если проект месяцев на 3-5 тогда да. У Вас очень чуткий критерий; между "тогда да" и "практически ничего" разница всего-то в пять раз. Три недели - это примерно 3% от двухлетнего проекта. Кажется, немного :) Теперь вспомним про норму прибыли - возьмем ее снова с потолка в 25%. Получается, Ваше "почти ничего" - это выброшенные на ветер 12% прибыли с проекта. Вы лично готовы отдать 12% своей зарплаты за время проекта в качестве жеста доброй воли по отношению к заказчику? Если да - соглашусь, что для Вас это немного. Один1З.п. тут не при чем совершенно, имеет смысл говорить о трудозатратах за 3 недели в сравнении с трудозатратами на весь проект. Безусловно. Зарплата просто позволяет наглядно, ощутимо показать, что речь идет о солидных суммах, в то время как для большинства людей "время как таковое, в неделях" - эфемерный показатель, не имеющий реальной стоимости. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.09.2005, 12:21 |
|
||
|
Бизнес-логика в БД посредством ХП. за и против
|
|||
|---|---|---|---|
|
#18+
softwarer Три недели - это примерно 3% от двухлетнего проекта. Кажется, немного :) Теперь вспомним про норму прибыли - возьмем ее снова с потолка в 25%. Получается, Ваше "почти ничего" - это выброшенные на ветер 12% прибыли с проекта. Вы лично готовы отдать 12% своей зарплаты за время проекта в качестве жеста доброй воли по отношению к заказчику? Если да - соглашусь, что для Вас это немного. Весьма спорные утверждения. 1. При ROI проекта 25%, увеличение длительности проекта (грубо) на 3% снизит ROI (еще грубее) до 24.27%, т.е. потери 0.73%, а никак не 12% 2. Если исходить из того, что потери от снижения ROI вписывать исполнителям, то: а) исполнители должны участвовать и в распределнии доходов в той же пропорции б) тогда речь идет не о зарплате (окладе), которая является постоянной и зависит _только от рабочего времени_(!) а о бонусах (премии), которые зависят от результатов(!). По любому, я бы не отказался от участия в проекте на этих условиях ;0)) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.09.2005, 13:05 |
|
||
|
Бизнес-логика в БД посредством ХП. за и против
|
|||
|---|---|---|---|
|
#18+
Jimmy1. При ROI проекта 25%, увеличение длительности проекта (грубо) на 3% снизит ROI (еще грубее) до 24.27%, т.е. потери 0.73%, а никак не 12% Хм. ROI = 25% - для моего уха звучит бессмыслицей; я всегда полагал, что ROI считается во временных единицах. Более того, в данном случае ROI будет считать заказчик, но не очень понимаю, какой смысл в этом подсчете для исполнителя. Чтобы не забираться вглубь того, как Вы считаете, приведу простой пример: Допустим, есть проект за 125 рублей, из которых 100 - себестоимость, а 25 - прибыль. Увеличивая себестоимость на 3%, то есть до 103 рублей, мы теряем три рубля из прибыли, то есть 3/25=12%. Разумеется, в моем утверждении есть определенная натяжка - прямая связь между временными и финансовыми затратами. Но для софтовых проектов это предположение весьма близко к истине. Jimmy2. Если исходить из того, что потери от снижения ROI вписывать исполнителям, то: Насколько я видел топик, вопрос "заказчик компенсирует нам стоимость переделки" не ставится, следовательно исполнитель (организация) деньги потеряет. Jimmyа) исполнители должны участвовать и в распределнии доходов в той же пропорции Он и участвует :) Если Вы не поняли: пассаж про зарплату вызван исключительно тем, что люди очень легко распоряжаются деньгами в чужом кармане. "Рядовой исполнитель" довольно легко скажет "подумаешь, затратили лишних пару недель", но весьма вероятно обидится, если именно ему предложат оплатить эти затраты "в той же пропорции". Jimmyб) тогда речь идет не о зарплате (окладе), которая является постоянной и зависит _только от рабочего времени_(!) а о бонусах (премии), которые зависят от результатов(!). Ok, если так Вам понятнее. Вы готовы пожертвовать лично своими 12% премии по итогам проекта ради удовлетворения идиотского каприза заказчика? А если эта премия составляет 100% Вашего дохода с проекта (то есть зарплаты нет как таковой)? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.09.2005, 13:45 |
|
||
|
Бизнес-логика в БД посредством ХП. за и против
|
|||
|---|---|---|---|
|
#18+
softwarerХм. ROI = 25% - для моего уха звучит бессмыслицей; я всегда полагал, что ROI считается во временных единицах. Более того, в данном случае ROI будет считать заказчик, но не очень понимаю, какой смысл в этом подсчете для исполнителя. 1. Моя трактовка - ROI = прибыль/инвестиции (см. здесь ) 2. Проект по разработке П/О ничем не хуже проекта внедрения. Или для проектов разработки нет ни инвестиций ни прибыли? softwarer Чтобы не забираться вглубь того, как Вы считаете, приведу простой пример: Допустим, есть проект за 125 рублей, из которых 100 - себестоимость, а 25 - прибыль. Увеличивая себестоимость на 3%, то есть до 103 рублей, мы теряем три рубля из прибыли, то есть 3/25=12%. Т.е. имеется ввиду 12% от 25%? Без дополнительных разъяснений это было далеко не очевидно, ведь так? softwarer Насколько я видел топик, вопрос "заказчик компенсирует нам стоимость переделки" не ставится, следовательно исполнитель (организация) деньги потеряет. Jimmyа) исполнители должны участвовать и в распределнии доходов в той же пропорции Он и участвует :) Я имел ввиду непосредственных исполнителей-специалистов. Во всяком случае, применять термин "зарплата" вообще к Исполнителю (организации) - достаточно смелое решение. softwarer Если Вы не поняли: пассаж про зарплату вызван исключительно тем, что люди очень легко распоряжаются деньгами в чужом кармане. "Рядовой исполнитель" довольно легко скажет "подумаешь, затратили лишних пару недель", но весьма вероятно обидится, если именно ему предложат оплатить эти затраты "в той же пропорции". Я просто не понял, почему наказывают рублем рядового исполнителя, за ошибки проектного менеджмента. Или это - новый подход к мотивации? softwarer Jimmyб) тогда речь идет не о зарплате (окладе), которая является постоянной и зависит _только от рабочего времени_(!) а о бонусах (премии), которые зависят от результатов(!). Ok, если так Вам понятнее. Вы готовы пожертвовать лично своими 12% премии по итогам проекта ради удовлетворения идиотского каприза заказчика? А если эта премия составляет 100% Вашего дохода с проекта (то есть зарплаты нет как таковой)? 1. Если я, как менеджер проекта, допустил такие ошибки, что заказчик нас "сделал", то я готов пожертвовать всей своей премией 2. Нет, я бы потребовал прибавки ;0)) Серьезно: см. п. 1 - нужно выполнять взятые на себя обязательства, если они именно таковы. Однако, оба эти пункта по отношению к программисту, например, применить нельзя, т.к. он сделал свою работу. Единственно, на что он может "попасть" - лишиться премии. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.09.2005, 14:57 |
|
||
|
Бизнес-логика в БД посредством ХП. за и против
|
|||
|---|---|---|---|
|
#18+
Jimmy1. Моя трактовка - ROI = прибыль/инвестиции [(см. здесь ) Хм. Ключевая фраза в указанном: Во-первых, обратите внимание на сам термин: ROI — это возврат на инвестицию, а не «возврат инвестиций», как говаривали лет восемь назад, да и сейчас нет-нет да и оговорятся. Признаться, не в курсе, кто оговаривался лет восемь назад, поскольку не интересуюсь активно экономикой; тем не менее, в этом году в англоязычном источнике встречал употребление ROI и именно в первом смысле. Впрочем, это в любом случае попутный вопрос. Jimmy2. Проект по разработке П/О ничем не хуже проекта внедрения. Или для проектов разработки нет ни инвестиций ни прибыли? Для внешнего и внутреннего проектов они кардинально разнятся. Внешний исполнитель как правило требует аванс и/или поэтапную оплату, в результате чего его денежные инвестиции невелики на фоне стоимости проекта. Его инвестиции - это труд; он рассматривает, оптимально ли он вложил труд с точки зрения максимизации возможной прибыли. Внутренний исполнитель - если он не на хозрасчетных отношениях с другими подразделениями - об этом не думает, а даже если и на хозрасчетных, его возможности очень ограничены. JimmyТ.е. имеется ввиду 12% от 25%? Без дополнительных разъяснений это было далеко не очевидно, ведь так? Хм. Прочитал еще раз свою фразу: "Получается, Ваше "почти ничего" - это выброшенные на ветер 12% прибыли с проекта." Вы таки действительно уверены, что это далеко не очевидно? А если посмотреть на предыдущую фразу: "Теперь вспомним про норму прибыли - возьмем ее снова с потолка в 25%" - и попробовать прочитать их друг за другом? JimmyЯ имел ввиду непосредственных исполнителей-специалистов. Я это понимаю. И что дальше? JimmyЯ просто не понял, почему наказывают рублем рядового исполнителя, за ошибки проектного менеджмента. Или это - новый подход к мотивации? Я не вижу, где "наказывают рублем рядового исполнителя за ошибки проектного менеджмента". Мой оппонент выдвинул утверждение, что некие траты - копейки. Я подсчитал эти траты и постарался показать ему, что это "копейки" только до тех пор, пока они в чужом кармане, а если соответствующую относительную сумму предложить оплатить из своего, отношение к этим тратам резко изменится. Если Вы не готовы воспринять эту логику иначе чем сугубо буквально - полагаю, дальнейшие объяснения бессмысленны. Jimmy1. Если я, как менеджер проекта, допустил такие ошибки, что заказчик нас "сделал", то я готов пожертвовать всей своей премией А если заказчик настаивает на том, чтобы Вы как менеджер проекта допустили такую ошибку? JimmyСерьезно: см. п. 1 - нужно выполнять взятые на себя обязательства, если они именно таковы. Согласен. Однако по контексту обсуждения не вижу почвы для "именно таковы". В чем, возможно, заблуждаюсь. Насколько я понимаю, довольно типичная ситуация, когда заказчик на полдороге услышал "A - это круто" и заканючил "хочу A". ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.09.2005, 15:51 |
|
||
|
Бизнес-логика в БД посредством ХП. за и против
|
|||
|---|---|---|---|
|
#18+
Jimmy2. Проект по разработке П/О ничем не хуже проекта внедрения. Или для проектов разработки нет ни инвестиций ни прибыли? Для внешнего и внутреннего проектов они кардинально разнятся. Внешний исполнитель как правило требует аванс и/или поэтапную оплату, в результате чего его денежные инвестиции невелики на фоне стоимости проекта. Его инвестиции - это труд; он рассматривает, оптимально ли он вложил труд с точки зрения максимизации возможной прибыли. Внутренний исполнитель - если он не на хозрасчетных отношениях с другими подразделениями - об этом не думает, а даже если и на хозрасчетных, его возможности очень ограничены. Вы, как почитатель логики и утверждений, тем не менее меняете контекст моего утверждения. Вопрос ведь был простой (а не глупый ;0) Инвестировать приходится как во внешний проект, так и во внутренний, только подсчитать прибыль труднее. И это - не кардинальная разница. JimmyТ.е. имеется ввиду 12% от 25%? Без дополнительных разъяснений это было далеко не очевидно, ведь так? Хм. Прочитал еще раз свою фразу: "Получается, Ваше "почти ничего" - это выброшенные на ветер 12% прибыли с проекта." Вы таки действительно уверены, что это далеко не очевидно? А если посмотреть на предыдущую фразу: "Теперь вспомним про норму прибыли - возьмем ее снова с потолка в 25%" - и попробовать прочитать их друг за другом? Возможно, мое замечание было воспринято, как согласие с Вашим методом расчета. Это не так. Это - просто замечание о недостаточно четкой формулировке. JimmyЯ имел ввиду непосредственных исполнителей-специалистов. Я это понимаю. И что дальше? Дальше? Вернемся к Вашему посылу, о том, что "не готовы ли вы, уважемый, заплатить из свой зарплаты за промахи руководства проектом?" и оценим его правомочность :0)) JimmyЯ просто не понял, почему наказывают рублем рядового исполнителя, за ошибки проектного менеджмента. Или это - новый подход к мотивации? Я не вижу, где "наказывают рублем рядового исполнителя за ошибки проектного менеджмента". См. выше. Мой оппонент выдвинул утверждение, что некие траты - копейки. Я подсчитал эти траты и постарался показать ему, что это "копейки" только до тех пор, пока они в чужом кармане, а если соответствующую относительную сумму предложить оплатить из своего, отношение к этим тратам резко изменится. Если Вы не готовы воспринять эту логику иначе чем сугубо буквально - полагаю, дальнейшие объяснения бессмысленны. Ваш оппонент высказал несколько иное утверждение, а именно, что отклонение от сроков в 3 недели на проекте, протяженностью 2 года это - допустимое явление (правда, он употребил слово "копейки", но мы же не настолько примитивны, чтобы воспринимать это "сугубо буквально"...). Я, как человек, непосредственно занятый в таких проектах могу подтвердить это высказывание, т.к. есть такое понятие, как проектные риски, которые, как правило, учитывают и при планировании того самого пресловутого ROI. Jimmy1. Если я, как менеджер проекта, допустил такие ошибки, что заказчик нас "сделал", то я готов пожертвовать всей своей премией А если заказчик настаивает на том, чтобы Вы как менеджер проекта допустили такую ошибку? Т.е. ему, заказчику, мало моей премии и он жажадет крови? Что-ж, ему придется остаться голодным. JimmyСерьезно: см. п. 1 - нужно выполнять взятые на себя обязательства, если они именно таковы. Согласен. Однако по контексту обсуждения не вижу почвы для "именно таковы". В чем, возможно, заблуждаюсь. Насколько я понимаю, довольно типичная ситуация, когда заказчик на полдороге услышал "A - это круто" и заканючил "хочу A". [/quot] Если считать, что условия работы "только за премию" - достаточно распространены и не являются чем-то исключительным, то "именно таковы" здесь действительно лишние. 2 All Не напрягает наш флейм? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.09.2005, 16:20 |
|
||
|
Бизнес-логика в БД посредством ХП. за и против
|
|||
|---|---|---|---|
|
#18+
softwarer Мой оппонент выдвинул утверждение, что некие траты - копейки. Я подсчитал эти траты и постарался показать ему, что это "копейки" только до тех пор, пока они в чужом кармане, а если соответствующую относительную сумму предложить оплатить из своего, отношение к этим тратам резко изменится. Если речь обо мне, то я не утверждал, "что некие траты - копейки". Я написал "PS: IMO, 3 недели разработок - это практически ничто :)" Где речь про траты и про копейки ? JimmyВаш оппонент высказал несколько иное утверждение, а именно, что отклонение от сроков в 3 недели на проекте, протяженностью 2 года это - допустимое явление (правда, он употребил слово "копейки", но мы же не настолько примитивны, чтобы воспринимать это "сугубо буквально"...). Еще раз, (если речь обо мне) я не употреблял слово "копейки", это softwarer придумал. В целом согласен с Jimmy (расшифровка фразы 3 недели разработок - это практически ничто ): Jimmyотклонение от сроков в 3 недели на проекте, протяженностью 2 года это - допустимое явление <skipped> т.к. есть такое понятие, как проектные риски Добавлю, что иногда полезно исходить из того, что клиент не дурак. И если он требует чего-либо, то у него есть на это основания. Скажем, ему проще будет в дальнейшем дорабатывать новую систему, т.к. у него есть специалисты по разработке ПО с логикой на клиенте, а на сервере как раз и нет. А может у него стандарты такие. А может ему так проще интегрироваться с чем-либо. А может действия пользователей должны проверяться непосредственно при вводе с клавиатуры. Да мало ли что может быть. Но если я, как клиент, вижу что команда разработчиков делает что-то явно "не то", да еще и не может внятно обьяснить мне почему она так делает ( см. вопрос на форуме "мы использовали крутую технологию, помогите пожалуйста нам понять чем она так крута" ), то лучше я заторможу этот процесс в самом начале проекта и потребую внятных обьяснений. Возможно в этом случае клиент так и поступил. А может клиент не знал как лучше, а теперь посмотрел на предложеный вариант и понял, что так как сделали - так не хорошо. И заставляет переделать. Это тоже нормально. А может и действительно, как написал softwarer softwarerдовольно типичная ситуация, когда заказчик на полдороге услышал "A - это круто" и заканючил "хочу A"." Всяко бывает. Мы же даже не знаем что за проект, какие сроки, сколько стоит. Смысл обсуждать "сферический проект в вакууме" ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.09.2005, 17:56 |
|
||
|
Бизнес-логика в БД посредством ХП. за и против
|
|||
|---|---|---|---|
|
#18+
> иногда полезно исходить из того, что клиент не дурак. Пара примеров? > И если он требует чего-либо, то у него есть на это основания. То, что Вы перечислили, основаниями не являются. Это отмазки для бедных. Достоверная информация о заказчике, упоминаемом в первом сообщении: 200к клиентов. Если не вдаваться в детали, какие реально существующие программно-аппаратные решения приходят в голову в первую очередь? Есть среди них такие, логика которых - на клиенте? Еще вопросы? > Но если я, как клиент, вижу что команда разработчиков делает что-то явно > "не то" Ну если Вы такой продвинутый клиент, что можете решать за разработчиков, что и как им делать - на кой Вам эти разработчики? Пишите сами. У Вас абсолютно неправильно представление о функциональных обязанностях заказчика и исполнителя и собственно разработке. > А может клиент не знал как лучше, а теперь посмотрел на предложеный > вариант и понял, что так как сделали - так не хорошо. И заставляет > переделать. Это тоже нормально. Кому нормально? Клиенту? А разработчику? На самом деле автор описал пример абсолютно безграмотного подхода к разработке. > Мы же даже не знаем что за проект, какие сроки, сколько стоит. Достаточно трех упоминавшихся вещей: 1. 200k клиентов, 2. IB, 3. описание проблемы и метода борьбы с ней, чтобы сделать правильные выводы. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.09.2005, 18:13 |
|
||
|
Бизнес-логика в БД посредством ХП. за и против
|
|||
|---|---|---|---|
|
#18+
Один1 wrote: > softwarer > > Добавлю, что иногда полезно исходить из того, что клиент не дурак. И > А может клиент не знал как лучше, а теперь посмотрел на предложеный > вариант и понял, что так как сделали - так не хорошо. И заставляет > переделать. Это тоже нормально. Если заказчик не дурак, он должен был оговорить в ТЗ подробнейшим образом, какие инструменты и технологии должны быть использованы, если с чем-то это надо интегрировать - описать, с чем интегрировать, если есть какие-то насущные проблемы - изложить, так мол и так, должно решать такие-то проблемы. Потому как если это не оговорено, разработчик выбрал средство разработки и технологию, написал проект, заказчик посмотрел и говорит - не то, переделывайте... Ну, батенька, там можно до греческих календ переделывать.... -- ------------------------- There's no silver bullet! Posted via ActualForum NNTP Server 1.3 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.09.2005, 18:20 |
|
||
|
Бизнес-логика в БД посредством ХП. за и против
|
|||
|---|---|---|---|
|
#18+
JimmyВы, как почитатель логики и утверждений, тем не менее меняете контекст моего утверждения. Как почитатель логики прежде всего скажу, что у Вас не утверждение а вопрос :) Далее, я как почитатель последовательности не меняю контекст Вашего вопроса, но восстанавливаю - говорю в рамках того контекста, который существовал до Вашего письма, и от которого Вы перешли к неким "разработке" и "внедрению". JimmyИнвестировать приходится как во внешний проект, так и во внутренний, только подсчитать прибыль труднее. И это - не кардинальная разница. Давайте я для экономии времены выдвину категорическое утверждение. Код: plaintext Соответственно, подсчитывая окупаемость по-вашему он может потратить произвольное время в разнообразных попытках деления на ноль. JimmyВозможно, мое замечание было воспринято, как согласие с Вашим методом расчета. Это не так. Это - просто замечание о недостаточно четкой формулировке. Как несогласие с моим методом расчета было воспринято указание некоторого не очень понятно как полученного числа; по беглому взгляду было ощущение, что Вы взяли 3% от прибыли и отнормировали по стоимости проекта. Ваше последнее замечание было воспринято именно как замечание к формулировке. Если формулировка "12% прибыли при прибыли в 25% от себестоимости" недостаточно четко отражает "взять 12% от 25%" - что ж, эту информацию я готов учесть, но не готов сделать практические выводы. JimmyДальше? Вернемся к Вашему посылу, о том, что "не готовы ли вы, уважемый, заплатить из свой зарплаты за промахи руководства проектом?" и оценим его правомочность :0)) Выберите уж - то ли мы вернемся к моему посылу, то ли к Вашему, Вами же мне приписанному. JimmyСм. выше. Смотрю. В силу известной Вам склонности к логике и контекстам - не вижу. И в полном соответствии с цитируемым Вами документом прошу: если Вы хотите поменять контекст - опишите, пожалуйста, новую ситуацию (в полном отрыве от старой) которую Вы имеете в виду и которую хотите обсудить. Jimmy softwarer Мой оппонент выдвинул утверждение, что некие траты - копейки. Я подсчитал.... Ваш оппонент высказал несколько иное утверждение, а именно, что отклонение от сроков в 3 недели на проекте, протяженностью 2 года это - допустимое явление (правда, он употребил слово "копейки", но мы же не настолько примитивны, чтобы воспринимать это "сугубо буквально"...). Признаться, не готов поверить Вашему экспертному мнению о том, что имел в виду мой оппонент, говоря те или иные слова. Поэтому снова выдвину категоричное утверждение: Код: plaintext Истинность этого утверждения я готов обсудить с ним. С Вами - не раньше, чем Вы признаетесь, что на самом деле Вы его виртуал. Теперь о Вашей трактовке (обратите внимание, меняем контекст). "Допустимое явление" - совершенно не значит "желательное". Предположим, мы с Вами связаны отношениями работодатель - работник. Для меня вполне допустимо сказать: извини, дружок, но я обанкротился, вот постановление суда, ты получишь только 88% того, что я тебе задолжал по зарплате и всего тебе наилучшего. Но подозреваю, Вы сочтете такой вариант событий нежелательным. Затянуть проект на три недели - допустимо. Даже если это проект на неделю, а не на два года :) Но "нормальности" и "желательности" в этом - совершенно никакой нет. И если некто говорит "да все путем, чего дергаться, копейки" - это всего лишь значит "копейки в чужом кармане". Для того, кто дергается - для того, из чьего кармана эти копейки - ситуация выглядит совершенно иначе. Jimmy softwarer А если заказчик настаивает на том, чтобы Вы как менеджер проекта допустили такую ошибку? Т.е. ему, заказчику, мало моей премии и он жажадет крови? Что-ж, ему придется остаться голодным. Отметим - Вы не всегда согласны удовлетворять идиотские требования заказчика. Если так - непонятно, почему Вы поддержали осуждение тех, кто занял сходную позицию. Jimmy softwarer JimmyСерьезно: см. п. 1 - нужно выполнять взятые на себя обязательства, если они именно таковы. Согласен. Однако по контексту обсуждения не вижу почвы для "именно таковы". В чем, возможно, заблуждаюсь. Насколько я понимаю, довольно типичная ситуация, когда заказчик на полдороге услышал "A - это круто" и заканючил "хочу A". Если считать, что условия работы "только за премию" - достаточно распространены и не являются чем-то исключительным, то "именно таковы" здесь действительно лишние. Для информации: я, как и Вы, читал Чапека. JimmyНе напрягает наш флейм? Скучноват только, а так - терпимо. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.09.2005, 18:34 |
|
||
|
Бизнес-логика в БД посредством ХП. за и против
|
|||
|---|---|---|---|
|
#18+
Один1Я написал: "PS: IMO, 3 недели разработок - это практически ничто :)" Где речь про траты и про копейки ? Три дополнительных недели разработок - это траты для того, за чей счет они идут. Насчет копеек - если не считаете синонимом, нисколько не буду спорить. Итак, Ваше утверждение: "Три недели разработок" == "практически ничего" Мое утверждение: "Три недели разработок" == "12% прибыли с двухгодового проекта" Закон транзитивности: "практически ничего" == "12% прибыли с двухгодового проекта" Далее есть два варианта: либо Вы соглашаетесь с этим выводом, либо не соглашаетесь, что означает ложность хотя бы одной из предпосылок. Соответственно, если моя предпосылка выдерживает обсуждение - ложной придется считать Вашу. Таково мое доказательство либо разницы в нашем восприятии мира, либо ложности Вашей предпосылки. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.09.2005, 18:45 |
|
||
|
Бизнес-логика в БД посредством ХП. за и против
|
|||
|---|---|---|---|
|
#18+
автор"Три недели разработок" == "12% прибыли с двухгодового проекта" Ваше утверждение про 12% подразумевает что стоимость проекта прямо пропорциональна человеко/часам разработчиков и того что у проекта ожидается 25% прибыль при 100% эффективном использовании труда разработчиков, что можно поставить под сомнение (например несмотря на задержки/сокращение фичей лонгхорна я сомневаюсь что мелкософт окажется в минусе). Однако, как верно было отмечено смириться с потерей в чужом кармане легче чем в собственном. Три недели - срок сопоставимый с отпуском и мне кажется что восторг работодателя в связи с предоставлением всей конторе дополнительного оплачиваемого месяца сравним с восторгом работников по поводу лишения их отпуска положенного по кзоту. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.09.2005, 19:12 |
|
||
|
Бизнес-логика в БД посредством ХП. за и против
|
|||
|---|---|---|---|
|
#18+
NaugВаше утверждение про 12% подразумевает что стоимость проекта прямо пропорциональна человеко/часам разработчиков .... что можно поставить под сомнение Безусловно, можно. Но как я указал, для софтовых проектов это весьма правдоподобное упрощение модели. Naug(например несмотря на задержки/сокращение фичей лонгхорна я сомневаюсь что мелкософт окажется в минусе). Сомневаюсь, что мелкософт получит с него всего 25% прибыли :) Однако стоит обратить внимание именно на сокращение фичей - полагаю, мы согласимся, что это делается главным образом ради сроков завершения. Другой вопрос, что в этом случае следует говорить не столько о прямых затратах и потерях, сколько о косвенных, и подсчеты гораздо сложнее. Впрочем - если здесь присутствует хотя бы один билл гейтс, я уберу подальше все свои точки зрения и с большим интересом выслушаю то, что он расскажет о коммерчески выгодных проектах :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.09.2005, 19:51 |
|
||
|
Бизнес-логика в БД посредством ХП. за и против
|
|||
|---|---|---|---|
|
#18+
авторСомневаюсь, что мелкософт получит с него всего 25% прибыли Прошу вас проккоментировать Naug ожидается 25% прибыль при 100% эффективном использовании труда разработчиков Мои опыт в разработке конечно мал, но у меня сложилось впечаление что кпд от использования труда разработчиков сильно отличается от 100% и с учётом размера этого отклонения 3% времени потраченного на топтание на месте вполне может укладываться в рамки ожидаемых расходов. Конечно, если коллектив компании-разработчика позиционирует себя как супер(мегa/гипер/L337 нужное подчеркнуть)-спецов со 100% кпд (100%-е знание рабочей области, технологий, целеустремлённость, работоспособность, понимание заказчика, прогнозирование будущего) то такой косяк (со стороны составителей тз, или составителей договора не оговоривших кто оплачивает изменение требований или руководителей проекта незаметивших что разрабов не туда занесло) показывает что исполнители при найме ввели в заблуждение работодателя касательно своих навыков. Что не есть гут, но где взять таких идеальных спецов соответствующих пресловутому шару весом 1 килограмм? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.09.2005, 20:38 |
|
||
|
Бизнес-логика в БД посредством ХП. за и против
|
|||
|---|---|---|---|
|
#18+
2 softwarer 1. С Вами - не раньше, чем Вы признаетесь, что на самом деле Вы его виртуал. Я - виртуал Орлова Дмитрия Георгиевича, руководителя проектов Datagy, компании "Диасофт" и больше - ничей. 2. "Как почитатель логики прежде всего скажу, что у Вас не утверждение а вопрос :)" Хм, цитата: "Проект по разработке П/О ничем не хуже проекта внедрения." (с) Jimmy Усилено вопросом. 3. softwarer: Я употребляю это слово (копейки) в том же самом смысле, что и мой оппонент. Один1: Если речь обо мне, то я не утверждал, "что некие траты - копейки". Я написал "PS: IMO, 3 недели разработок - это практически ничто :)" Где речь про траты и про копейки ? Контекст, мой друг, контекст... 4. Как несогласие с моим методом расчета было воспринято указание некоторого не очень понятно как полученного числа; по беглому взгляду было ощущение, что Вы взяли 3% от прибыли и отнормировали по стоимости проекта. 100000 - плановые затраты 25000 - плановая прибыль ROI = 25% 103000 - фактические затраты 22000 - фактическая прибыль ROI = 21.4% Разница - 3.6% (не 12%, хотя и не 0.75%) Почему так? Потому что, сумма контракта наверняка зафиксирована и равняется 125000. Т.е. долевое перераспределение прибыль/затраты при фиксированной общей сумме выглядят именно так. 5. Выберите уж - то ли мы вернемся к моему посылу, то ли к Вашему, Вами же мне приписанному Хорошо, просто мы по разному трактуем ситуацию - не будем спорить. 6. Затянуть проект на три недели - допустимо. Даже если это проект на неделю, а не на два года :) Но "нормальности" и "желательности" в этом - совершенно никакой нет. И если некто говорит "да все путем, чего дергаться, копейки" - это всего лишь значит "копейки в чужом кармане". А кто-то говорил о "нормальности" и "желательности"? По моему, кроме Вас - никто. Очень похоже на отношения небезызвестного персонажа Д. Кихота с ветряными мельницами :0))) 7. Отметим - Вы не всегда согласны удовлетворять идиотские требования заказчика. Если так - непонятно, почему Вы поддержали осуждение тех, кто занял сходную позицию . Если Исполнитель спрашивает: "Как быть - злой Заказчик говорит нам , что мы ... Что делать?", это значит только одно - проект "организован" так, что Исполнителю нечего противопоставить Заказчику. Это значит - Заказчик прав, увы :0) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.09.2005, 11:40 |
|
||
|
Бизнес-логика в БД посредством ХП. за и против
|
|||
|---|---|---|---|
|
#18+
>Небольшая предистория: >В нашу фирму поступил заказ по разработке скдского ПО ... Посмотри здесь http://www.gotdotnet.ru/LearnDotNet/NETFramework/125377.aspx может что и пригодится. Считаю, что подобные разработки должны опираться на многоуровневую архитектуру и распределенные вычислительные среды. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.09.2005, 13:33 |
|
||
|
Бизнес-логика в БД посредством ХП. за и против
|
|||
|---|---|---|---|
|
#18+
NaugМои опыт в разработке конечно мал, но у меня сложилось впечаление что кпд от использования труда разработчиков сильно отличается от 100% и с учётом размера этого отклонения 3% времени потраченного на топтание на месте вполне может укладываться в рамки ожидаемых расходов. КПД разработчиков здесь на самом деле не при чем. Разумеется, могут и даже скорее всего будут укладываться - зависит от ширины этих рамок. Вопрос в том, что если я запланировал получить с вышеозначенного проекта 20-30 рублей прибыли - 25 рублей тем не менее будут существенно приятнее, нежели 22, а 29 - нежели 26. И уж точно 21 рубль будет приятнее, чем 18. Вы исходите из модели "были запланированы непроизводительные траты - и вот она, эта трата". Да, можно так считать. Собственно, добрые отношения с заказчиком запросто могут оказаться куда дороже этих самых трех недель работы. Но в то же время эти траты запланированы на "поняли, что пришли не туда". В ситуации "нам вдруг зачем-то сказали потратить время" - я бы начал с выяснения, а зачем его тратить. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.09.2005, 14:09 |
|
||
|
Бизнес-логика в БД посредством ХП. за и против
|
|||
|---|---|---|---|
|
#18+
softwarer Мое утверждение: "Три недели разработок" == "12% прибыли с двухгодового проекта" Если я правильно понял, ваше утверждение про 12% прибыли базируется на том, что увеличение продолжительности проекта на 3% = увеличение его себестоимости на 3%. Это спорно само по себе (см. риски), но тем не менее замечу, что затраты по проекту во времени распределены отнюдь не равномерно (даже если мы сейчас говорим только о затратах на з.п. разработчикам). В начале проекта они будут меньше, т.к. не много людей заняты собственно разработкой. Ближе к окончанию проекта - больше, т.к. вся команда "под парами". В любом случае, для (софтверного) проекта время и себестоимость находятся в отнюдь не линейной зависимости. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.09.2005, 14:23 |
|
||
|
Бизнес-логика в БД посредством ХП. за и против
|
|||
|---|---|---|---|
|
#18+
Один1 Если я правильно понял <...> базируется на том, что увеличение продолжительности проекта на 3% = увеличение его себестоимости на 3%. Замечание правильное, но допущения оговаривалось при расчете (см. слова "грубо") ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.09.2005, 14:32 |
|
||
|
Бизнес-логика в БД посредством ХП. за и против
|
|||
|---|---|---|---|
|
#18+
softwarer: Я употребляю это слово (копейки) в том же самом смысле, что и мой оппонент. Один1: Если речь обо мне, то я не утверждал, "что некие траты - копейки". Я написал "PS: IMO, 3 недели разработок - это практически ничто :)" Где речь про траты и про копейки ? Контекст, мой друг, контекст... Что ж, придется сформулировать более детально. "Я употребляю это слово (копейки) в том же самом смысле, что и мой оппонент, употребляя слова "почти ничего". Разница - 3.6% (не 12%, хотя и не 0.75%) Безусловно, относительно "инвестиций" выйдет так. Собственно, в этой модели будет близкая к единице зависимость между процентом изменения расходов и процентом изменения ROI. Вопрос - в каком случае уместно использование той или иной величины. ROI вполне уместен для анализа, сравнения проектов - мы можем сказать, что проекты в такой-то области более выгодны, либо что PM#1 уступает по результатам своему коллеге PM#2. В то же время если мы говорим о выплате сотрудникам премии по результатам проекта - она будет именно на 12% меньше. Если мы говорим о способности компании закупить новые компы, благоустроить офис и так далее - она будет именно на 12% меньше. Если мы говорим о возможности владельца прикупить фазенду на Гаваях - она будет именно на 12% меньше. А потому, с легкостью говоря "почти ничего" - стоит примерить на свой карман именно 12%. А кто-то говорил о "нормальности" и "желательности"? По моему, кроме Вас - никто. Очень похоже на отношения небезызвестного персонажа Д. Кихота с ветряными мельницами :0))) Логика, друг мой, логика. Я говорю - о ненормальности и нежелательности. Если Исполнитель спрашивает: "Как быть - злой Заказчик говорит нам , что мы ... Что делать?", это значит только одно - проект "организован" так, что Исполнителю нечего противопоставить Заказчику. Это значит - Заказчик прав, увы :0) Если исполнитель спрашивает..... это значит ровно одно - заказчик говорит. Еще это значит, что исполнитель не успел обзавестись адекватным собственным опытом разрешения таких ситуаций. Но я не вижу, почему это значит "исполнитель должен молчать в тряпочку". Ваш последний вывод необоснован - с тем же успехом это значит, что Исполнитель не уверен в правильности оценки ситуации и не хочет противопоставлять заказчику, прежде чем обретет такую уверенность. И если так - он абсолютно прав. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.09.2005, 14:56 |
|
||
|
Бизнес-логика в БД посредством ХП. за и против
|
|||
|---|---|---|---|
|
#18+
Jimmy Один1 Если я правильно понял <...> базируется на том, что увеличение продолжительности проекта на 3% = увеличение его себестоимости на 3%. Замечание правильное, но допущения оговаривалось при расчете (см. слова "грубо") Потом про слово "грубо" как то забыли. См. вышепреведенную цитату Softwarer-a (3 недели = 12%) Вся проблема в том, что обсуждать особо нечего не видя конкретной ситуации. Можно "перетирать" насколько "грубо" и т.п. Возможна ведь и ситуация, при которой увеличение продолжительности на 3% может привести и к увеличению себестоимости на больше чем 3 % И даже в начале проекта. Вот, скажем, реальный случай: заказчика убедили, что для реализации проекта сильно-сильно необходимо применить одну французскую штуковину (очень особый медицинский софт, со своим оборудованием, своей базой и т.п.). И для запуска и настройки этой штуковины надо из Франции выписать редкого специалиста и оплатить его услуги. Ориентировочно спец. должен был работать у нас 5 рабочих дней. Он работал месяц, а потом приехал еще один и они вместе трудились еще пару недель. Наладили. Как это сказалось на себестоимости в % отношении мне трудно сказать, но неожиданный всплеск затрат на з.п. в начале проекта налицо, хотя заказчику удалось добиться не полной оплаты услуг французов. Ситуация не типичная, но реальная. PS: кстати там логику сделали на клиенте (приветствуются крики "ацтой", уродство, как так можно, абсолютно неверный подход и т.п.) MSSQL 7.0, VB6. Система управления госпиталями, используется в штатах, 3 года назад было больше сотни внедрений, сколько сейчас - не знаю. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.09.2005, 14:58 |
|
||
|
Бизнес-логика в БД посредством ХП. за и против
|
|||
|---|---|---|---|
|
#18+
Один1Это спорно само по себе (см. риски), Признаться, не понял, при чем тут риски. Риски - это понятие времени планирования, а себестоимость в данном случае вполне себе фактическая. Можно только сказать, что фактическая себестоимость не выйдет за запланированные с учетом рисков рамки - это покажет правильность планирования, но денег в кармане не прибавит :) Один1В любом случае, для (софтверного) проекта время и себестоимость находятся в отнюдь не линейной зависимости. Если начинать считать точно, придется выйти за рамки имеющейся информации и возможного в рамках форума. Например, оценить влияние трехнедельной задержки на другой проект, куда должны были перейти специалисты. А для грубой оценки эта модель вполне подходит. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.09.2005, 15:10 |
|
||
|
Бизнес-логика в БД посредством ХП. за и против
|
|||
|---|---|---|---|
|
#18+
Один1Потом про слово "грубо" как то забыли. См. вышепреведенную цитату Softwarer-a (3 недели = 12%) Хм. В этом топике уже всплывало слово "контекст". Несмотря на то, что меня иногда заслуженно считают формалистом (а я себя заслуженно считаю занудой), я нахожу несколько... утомительным повторять в каждом новом сообщении все сказанное ранее. Было сказано, что модель грубая, идет ссылка на эту модель - зачем говорить это вновь, тем более тому же собеседнику? Один1Вся проблема в том, что обсуждать особо нечего не видя конкретной ситуации. Можно "перетирать" насколько "грубо" и т.п. Да в общем-то обсуждать и было особо нечего. Мне не понравилась конкретная мысль, некое махание шашкой - мол, почти ничего и думать нечего. Я подсчитал - грубо - что может быть и очень даже "чего". И как водится, обсуждение пошло сильно далеко, пряча первоначальную тему. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.09.2005, 15:17 |
|
||
|
Бизнес-логика в БД посредством ХП. за и против
|
|||
|---|---|---|---|
|
#18+
softwarerРиски - это понятие времени планирования, а себестоимость в данном случае вполне себе фактическая. Можно только сказать, что фактическая себестоимость не выйдет за запланированные с учетом рисков рамки - это покажет правильность планирования, но денег в кармане не прибавит :) Ну да, только вот запланированная "задержка" (в кавычках) и себестоимость на 3% не снизит. Т.е. сколько запланировали - столько и потратили. Сколько запланировали работать - столько и работали. Вывод - пресловутые 3 недели были учтены с самого начала заказчиком, соответственно говорить вообще не о чем, ни у кого никаких претензий. softwarerА для грубой оценки эта модель вполне подходит. Ну это с вашей т.з. С моей - нет, не подходит. softwarerна то, что меня иногда заслуженно считают формалистом (а я себя заслуженно считаю занудой), я нахожу несколько... утомительным повторять в каждом новом сообщении все сказанное ранее. А я не нахожу. Лучше я повторю, так меньше вероятность что мне не припишут (например те, кто считает себя формалистом) то, чего я не говорил. Т.е. не от хорошей жизни. softwarerМне не понравилась конкретная мысль, некое махание шашкой - мол, почти ничего и думать нечего. Я подсчитал - грубо - что может быть и очень даже "чего". А вам попытались показать, что если более пристально рассмотреть ваше "грубо", то оно с большой вероятностью превратится в мое "почти ничего" softwarerИ как водится, обсуждение пошло сильно далеко, пряча первоначальную тему. Ну куда же без этого :) Я там в предыдущем посте привел топичный пример, так просто - может кому интересно. PS: Сам я сторонник логики на сервере (при клиент-сервере). Но считаю, что утверждения о том, что это - однозначное "вундерваффе" не верны. Утверждения о том, что клиент не должен никак вмешиваться в процесс разработки, особенно в таких принципиальнейших вещах тоже считаю неверным. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.09.2005, 15:51 |
|
||
|
Бизнес-логика в БД посредством ХП. за и против
|
|||
|---|---|---|---|
|
#18+
Брошу последнюю "копейку" ;0)) Причем тут риски? При том, что бюджет проекта планируется с учетом рисков, т.е. несколько завышается. Завышается именно себестоимость. Это - "бюджет рисков". Таким образом, если сработали некие риски, потери от которых превысили свой бюджет, тогда можно говорить о снижении прибыли и, соответственно, о недополученных премиях и недокупленных бунгало на Гаваях. Если этого не произошло, то "бюджет рисков" = "бонус Исполнителя". Ладно, думаю, пора заканчивать. Было интересно. Удачи всем участникам и зрителям :0). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.09.2005, 15:56 |
|
||
|
Бизнес-логика в БД посредством ХП. за и против
|
|||
|---|---|---|---|
|
#18+
Мощное обсуждение получилось. Хочу сказать вот что. 1) 200 тыс клиентов и FireBird - вещи несовместимые. Кто не знает как работает interbase - RTFM (читать матчать). Он просто умрет при таком одновременном кол-во подключений на отражении транзакций да и все. 2) три недели разработки... альфа версию. Враки, что это за задание такое, что без движка настроить систему с нуля(т.е. написать ее) нереально в принципе, если это какая-то система конечно. Если это глупость, тогда просто запросить много денег и написать на клиенте, а потом объяснять, почему плохо работает и за реинжиниринг и переработку взять еще денег. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.09.2005, 16:10 |
|
||
|
Бизнес-логика в БД посредством ХП. за и против
|
|||
|---|---|---|---|
|
#18+
JimmyЕсли этого не произошло, то "бюджет рисков" = "бонус Исполнителя". Который, тем не менее, является тем же самым недокупленным домиком на гаваях. Можно спланировать бюджет хорошо либо плохо, но факт определяется только фактом и никак не шириной допуска при планировании. Возвращаясь к личному кошельку - я вполне могу планировать получить 800 баксов премии за проект. Но если могу получить тысячу - не откажусь. И "ладно, почти ничего, возьму 800" не скажу. Один1Ну да, только вот запланированная "задержка" (в кавычках) и себестоимость на 3% не снизит. Т.е. сколько запланировали - столько и потратили. Сколько запланировали работать - столько и работали. В данном случае она скорее незапланированная. Судя по вопросу, вмешательство заказчика было неожиданным :) Тут уместнее следующая модель: нужно выполнить W полезной работы, и прогнозируется W0 потерь (W0 - матожидание). Потеряли три недели, начали проект с начала. И снова имеем W0 как матожидание оставшихся потерь. Один1 softwarer А для грубой оценки эта модель вполне подходит. Ну это с вашей т.з. С моей - нет, не подходит. Ok. Жаль только, что Вы поздно об этом сказали. Предложите лучшую модель? Один1А вам попытались показать, что если более пристально рассмотреть ваше "грубо", то оно с большой вероятностью превратится в мое "почти ничего" Хм. Как минимум "большой вероятности" я не увидел. Для того, чтобы показать "большую вероятность", Вам нужно показать, что основная доля расходов по проекту либо не зависит от времени, либо сосредоточена в небольшом временном диапазоне (или нескольких таких диапазонах) и соответственно средние траты за все остальное время резко ниже. То есть, Вам нужно показать, например, что для большинства проектов существует 20% времени, на которые приходится 80% себестоимости - тогда с вероятностью 0,8 мои 12% превратятся в 2,4%. JimmyPS: Сам я сторонник логики на сервере (при клиент-сервере). Но считаю, что утверждения о том, что это - однозначное "вундерваффе" не верны. Безусловно, в каждом случае нужно принимать взвешенное решение. Если говорить о личных впечатлениях - мне выпало переводить большой проект с Delphi/Win на gcc/Linux только потому, что одному человеку кто-то брякнул, что C - это круто и линукс - это круто. Поэтому я не очень хорошо отношусь к решениям вида "а давайте все перекурочим потому что захотелось". JimmyУтверждения о том, что клиент не должен никак вмешиваться в процесс разработки, особенно в таких принципиальнейших вещах тоже считаю неверным. Вопрос в том, как вмешиваться. Если может сказать что-то умное и уместное - welcome. Ну а если путаться под ногами и мешать - лучше не вмешиваться. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.09.2005, 17:00 |
|
||
|
Бизнес-логика в БД посредством ХП. за и против
|
|||
|---|---|---|---|
|
#18+
softwarerOk. Жаль только, что Вы поздно об этом сказали. Предложите лучшую модель? Конечно предложу. Давайте возьмем конкретный проект с планом, с бюджетом и будем говорить. У меня буквально сегодня была точно такая же ситуация: банку нужно придумать механизм расчета процентов по некоторой группе кредитов. Один сотрудник предложил механизм - простой, удобный, наглядный. Но совершенно не подходящий к реальной жизни. Он тоже давал некие "средние" оценки, но их никак нельзя применить. Причем чем большее кол-во кредитов из выбранной группы пытались им обработать - тем больше "плыл" результат. Средняя температура по больнице - очень уместное здесь выражение. softwarerХм. Как минимум "большой вероятности" я не увидел. Для того, чтобы показать "большую вероятность", Вам нужно показать, что основная доля расходов по проекту либо не зависит от времени, либо сосредоточена в небольшом временном диапазоне (или нескольких таких диапазонах) и соответственно средние траты за все остальное время резко ниже. Вообще-то, это была ваша модель оценки, вы ее и защищайте. До тех пор, пока не покажите, что она верна, будет "большая вероятность" что она не верна. Но тем не менее, я уже сказал, что в начале проекта над ним работают (значительно) меньше людей, чем в конце. Мы же говорим вроде бы о начальном периоде и о том как задержка в нем отразится на себестоимости проекта ? Если честно, уже во первых скушновато, во вторых новых поворотов не придвидится, в третьих пятница. Я заканчиваю. Как сказал Jimmy JimmyБыло интересно. Удачи всем участникам и зрителям ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.09.2005, 18:09 |
|
||
|
Бизнес-логика в БД посредством ХП. за и против
|
|||
|---|---|---|---|
|
#18+
Один1Конечно предложу. Давайте возьмем конкретный проект с планом, с бюджетом и будем говорить. OK. Выспрашивайте у автора темы :) Один1Вообще-то, это была ваша модель оценки, вы ее и защищайте. Хм. От кого? Я согласен поменять ее на лучшую Один1 До тех пор, пока не покажите, что она верна, будет "большая вероятность" что она не верна. Для экономии времени - допустим. Вы делаете логический переход между этой "большой вероятностью" и "большой вероятностью" в предыдущей фразе. OK. Применяем Вашу логику и получаем: в силу неверности модели есть "большая вероятность" того, что все будет гораздо хуже, чем я предсказываю. Не согласны? Один1Но тем не менее, я уже сказал, что в начале проекта над ним работают (значительно) меньше людей, чем в конце. Причем те, кто работает над проектом в начале - (значительно) более высокооплачиваемые специалисты, нежели работающие в конце. Аналитики, архитекторы, ведущие итп - закладывают основу. После чего потихоньку переходят на следующий проект, посматривая иногда, чтобы на этом кодеры итп ничего не испортили. Один1Мы же говорим вроде бы о начальном периоде и о том как задержка в нем отразится на себестоимости проекта ? Мое мнение Вы знаете :) Удачи. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.09.2005, 18:57 |
|
||
|
Бизнес-логика в БД посредством ХП. за и против
|
|||
|---|---|---|---|
|
#18+
Мне осталось непонятным, почему заказчика интересуют применяемые при написании проекта технологии. Это будет некое ядро, которое заказчик будет самостоятельно сопровождать и самостоятельно наращивать на нем функционал? По окончании работы исполнитель передает заказчику исходные коды? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.09.2005, 09:44 |
|
||
|
Бизнес-логика в БД посредством ХП. за и против
|
|||
|---|---|---|---|
|
#18+
2 softwarer 1.Каждое истинное высказывание должно основываться на истинном высказывании или аксиоме. Не так ли? 2.Увы, но в данном случае я этого не вижу - 2 последние цитаты (см. пост 2 сент 17-00), не мои. 3.Если в процессе спора начинаются отклонения такого рода, то они позволяют усомниться и в прочих Ваших высказываниях (см. п.1). PS Теперь точно все. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.09.2005, 10:09 |
|
||
|
|

start [/forum/topic.php?all=1&fid=32&tid=1545690]: |
0ms |
get settings: |
7ms |
get forum list: |
22ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
47ms |
get topic data: |
13ms |
get forum data: |
3ms |
get page messages: |
225ms |
get tp. blocked users: |
1ms |
| others: | 236ms |
| total: | 560ms |

| 0 / 0 |
