Про отсталые индустрии

[vit_r]

Выношу из комментариев у nponeccop

«Коммерческий промышленный» означает выполнение проекта в ситуации нехватки бюджета, времени и специалистов, причём в коллективе, где не просто не знают, что делают некоторые работники того же проекта, но и не подозревают о их существовании.

Эти признаки важнее области, применяемых технологий, объёмов работ, размера бюджета и качества комманды. Потому что главный параметр проекта - это люди, главная проблема - это коммуникация между ними.

Причём, гораздо интереснее для рассмотрения проекты, где конечным результатом является не софт, а более сложная система, этот софт в себе заключающая или использующая. Потому что это накладывает очень жёсткие рамки на качество и на каналы коммуникации ИТ отдела.

Comments

а что тут причина и следствие?

[serge shikov (from livejournal.com)]

Коммерческий и промышленный - поэтому будет нехватка бюджета, или наоборот, нехватка бюджета делает проект коммерческим и промышленным? :)))

> Потому что главный параметр проекта - это люди
Браво! Нет, серьезно.

Re: а что тут причина и следствие?

[vit-r.livejournal.com]

Я предлагаю считать это просто эксперементально выявленной корреляцией.

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

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

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

Re: а что тут причина и следствие?

[serge shikov (from livejournal.com)]

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

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

Re: а что тут причина и следствие?

[vit-r.livejournal.com]

Пардон, не надо путать оптимизацию и минимизацию. Оптимальное решение ищет наиболее выгодный компромисс по многим параметрам.

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

Re: а что тут причина и следствие?

[serge shikov (from livejournal.com)]

Можете назвать это компромиссом, что изменится?

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

Это как бы очевидное явление - оптимальный бюджет это ноль затрат, оптимальные сроки - это вчера, оптимальное качество вчера и при нуле затрат недостижимо, просто потому, что нет самого продукта.

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

Ну так и об чем спор-то?

Re: а что тут причина и следствие?

[vit-r.livejournal.com]

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

Естественно, в реале идёт выбор компромиссов и ранжирование по значению и оценка рисков, но предсказывать будущее никто всё равно не умеет. Зачем говорить, что что-то фиксируют, если оно всё равно может уехать?

И не надо путать "оптимальное" и "идеальное". Ноль затрат - это идеальный предел. Оптимум - это выбор минимального бюджета из возможных реалистичных вариантов.

Профессиональная деформация

[livejournal.livejournal.com]

User metaclass referenced to your post from Профессиональная деформация (http://metaclass.livejournal.com/846701.html) saying: [...] Работа программистом, особенно в условиях промышленных [...]

[nponeccop.livejournal.com]

В таком виде более понятно. А имеет смысл выделить проекты, где коммуникация является определяющей проблемой, в отдельный класс?

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

[http://users.livejournal.com/_windwalker_/]

Мифическая OS 360 ?

а что в ней мифического?

[serge shikov (from livejournal.com)]

Если она была создана в 60-х, и до сих пор живет в виде своих потомков? Я даже не очень удивлюсь, если куски кода сохранились с тех пор.

P.S. Я не верю, что у них не было сроков и бюджета. Были. Даже при наличии альтернативы в виде DOS 360 (которая не факт что была в наличии) все равно машины-то надо было с чем-то продавать, это же не сегодня, когда можно продать теоретически ноутбук без ОС.

[vit-r.livejournal.com]

В любом проекте при росте группы или при разделении проекта на размещённые раздельно группы начинаются проблемы с коммуникацией.

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

Большие проекты с избытком по срокам и бюджету - это те случаи, когда процесс важнее результата. То есть, качество не фиксировано.

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

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