iscrafmпонятно, т.е. ничего серьезного не делал, типа только внедрения 1С.

[youtube=

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

Вот давай без обид, ок? Это вообще не ответ на вопрос.

-- Как сделать живой партионный учет на 2000 доков в день?
-- Надо его... Сделать!
-- Вы приняты!

Ты, видимо просто не понимаешь проблемы.

Поэтому этот вопрос и задаётся 1С-нику, потому что предметная область там узкая, а стереотипы - устоявшиеся.

Понятно, что любой нормальный прог прощелкает это как семечки.

Но твой ответ - за гранью и вне контекста реальной проблемы.

Злой Бобр
авторКоличество документов не является показателем.
Ну как не является-то, мусье! На сотне документов всё летает, на 10 000 всё ложится. Что же это за показатель??

авторИ при больших объемах я вообще не стал бы вести партионный учет в том виде в котором он есть в типовых конфигурациях.

А никто и не говорит про типовые.

авторБольшие обемы по моим меркам 10к+ документов в день с количеством записей 100+ . И да, это на 7.7 и это не фантастика.

Ага. С применением сторонних компонент, после ряда которых поднимается вопрос - а зачем нам вообще 1С?

автор Более того для 1С не может быть понятия архитектор.
Ну вот, уже и архитектор не нужен. Кто ж у нас остается то?

iscrafmвроде у тебя были вопросы? я могу только постебаться с программера с завышенным ЧСВ, который по сути не понимает элементарных вещей


Но у тебя нет на них ответов.

Злой БобрМасштабируемость - это работа под разными ОС, разными устройствами и пр. Но опять же - к 1С это не относится.

Бобр, ты почитай что такое масштабируемость. Можешь вместе с Искрой, у него тоже какие-то проблемы.

Злой БобрДаже для 7.7 это мелкий объем. Поэтому не говорите что нельзя было сделать на 1С. Это даже не смешно, т.к. многие успешно это делали.



)))) Что делали-то???

Я говорю не про ввод данных (отсылка к пользователям), или снятие отчетов, а про обработку данных.
Которая в 1С (в то время) была совмещена вместе с вводом и от того - нещадно жрала ресурсы.

Это всё 1С-вские стереотипы, своего рода паттерн. Просто рядовой 1С-ник ничего другого не знает (и знать не хочет) - от того и проблемы.

iscrafmMonochromatiqueпропущено...


Но у тебя нет на них ответов.
18455302
просто ответы неудобны, судя по всему, вопрошающему.

Это не ответы - это треш.

Не знаю, как ты это продаешь.

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

-- Как убедиться, что архитектура отвечает потребностям решения?
-- Ну её же делал архитектор!

-- Как быстро восстановить партионный учет?
-- Надо его сделать быстрым!!

Ша-пи-то.

Злой Бобр Я будучи "студентом" тоже думал что 1С решает все. Но только со временем понял насколько 1С - зло.

Тебя ждет еще столько удивительных открытий....

iscrafmMonochromatiqueпропущено...


Это не ответы - это треш.

Не знаю, как ты это продаешь.
вопрос: каким образом получить исчерпывающие описание системы?
ответ: дать задание подготовить описание его автору.

Оказывается


MonochromatiqueЭто не ответы - это треш.


Да не - всё ровно.

Ты меня научил.

С аналитика - анализ.
С Архитектора - архитектура.
С HR - проги.
С ТимЛида - дисциплина.
С Кодеров - код.

Бабки - мне.

Вот это да.

sereginsereginMonochromatique,

Хватит выяснять отношения.
Парню выделили бюджет, дали возможность команду набрать, а он хочет командой командами управлять.
Щас у парня проект провалится, бабки заберут, и не факт, что остальным дадут доделывать....

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

И вообще, если Вы такой опытный, на х...р Вам 10 человек команда? Сделали бы все сами по старинке!

Извиняюсь, возможно покажется свысока - но хоть первый отзыв в тему!

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

Из ваших слов, я не пойму - кто (КТО) определяет, как должен выглядеть финальный продукт. Архитектор? То есть, если заказчик настаивает на нежизнеспособном говне, а архитектор именно это и делает, но получается некая подпись по неким дизайн-документом обеспечивает спокойный сон PM-а?

Иными словами, у PM-а главное - акт приема-передачи, а не качество решения?