Как говорится, по просьбе трудящихся.

Оригинал

https://foren.germany.ru/programmer/f/35085938.html?Cat=&page=0&view=collapsed&sb=5

Много там еще непоняток осталось, действительно ли всё так как здесь пишут?

Tamachi

Так, частника, а не фрилансера! Разницу понимаете?

Вообще то, кто такой "частник" в России, я не знаю вообще.

Думал, что это

https://ru.wikipedia.org/wiki/Фрил�%...

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

https://blog.newsru.com/article/27apr2019/progressors

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

поэтому в цене не командные игроки, а одиночки, способные как-то сваять работающую систему,

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

Ну вот есть проекты на 10 человеко-лет. Как это можно сваять одному за за пару лет?

Безусловно, лидер должен быть, но без слаженной команды будет тяжело.

Бывает и попадаются сваянные "рабочие системы" - тут как на минном поле, шаг в сторону и усё, приплыли.

Касательно "10 человеко-лет":

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

Вот, например, сравните python и c++.

Возьмите какой-нибудь, достаточно объемный продукт и прикиньте: сколько времени Вам потребуется, чтобы его реализовать на той или иной технологии.

Я вполне могу поверить в то, что один человек, программируя на c++ способен за полгода сделать проект, который команда из 22 человек, работая на python не сможет сделать за 22 года. Скорее всего эта команда распадётся уже в первые 4 месяца.

Вот, например, сравните python и c++.

Зачем? Каждый язык имеет свою нишу и область применения. Да и личные предпочтения играют не последнюю роль.

Вот я на плюсах просто больше не хочу программить, но это не говорит о том что плюсы стали хуже.

Вы бы лучше рассказали чем частник от фрилансера у Вас отличается.

Причем в 2-3 раза, а в десятки или даже сотни раз. При этом новые (убогие) технологии получают огромную рекламу, в то время как старые уже стираются в памяти нового поколения.

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

Но вы(ну не вы конкретно, ваши коллеги) зачем то начинаете пользоваться другими языками и настраивать другие среды программирования. Зачем? Есть проблемы? Если есть проблемы, их разумеется нужно решать. Но решать организовано.

Как объяснить работодателю, что потратил 120 рабочих дней, а показать ещё ничего не могу, поскольку повяз в рутине.

Для меня подобная ситуация просто немыслима. То есть кто-то ТРИ МЕСЯЦА чем-то занимается, а никто не знает чем? Ну ок, если чел уже написал пару похожих проектов и пишет очередной, как пирожки печет. Черт с ним. Но если чел начал делать то, что раньше не делал и его оставили на 3 месяца без присмотра? А потом в итоге начальство чего-то там хочет? Здесь большая организационная(не программистская) проблема. Чел получил задание, с которым не в состоянии справится, а его кинули одного. 3 месяца потеряно из за неправильной организации труда. А нужно было всего навсего ввести планерки. И все. Если шеф на ШЕСТИДЕСЯТОЙ планерке (2 месяца) слышит "настраиваю эклипс", то даже самый тупой шеф должен задуматься.

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

Это проблема. НО! Проблема лежит опять в организации. Не должен программист "писать проект". Он должен выполнять конкретные задания с конкретными сроками. То есть дать программисту задание "написать программу" - это в корне неправильно. Потому что в итоге он завалит проект и отмажется. Нужно весь проект разбить на истории и программист должен программировать их одну за другой. Тогда будет ясно, в какой стадии находится проект, ЧТО КОНКРЕТНО слишком сложно или непонятно и можно конкретно спрашивать "почему за 4 дня не заложены классы доступа к басе данных? В чем проблема?"

Конкретные ответы можно получить только на конкретные вопросы.

Я вполне могу поверить в то, что один человек, программируя на c++ способен за полгода сделать проект, который команда из 22 человек, работая на python не сможет сделать за 22 года. Скорее всего эта команда распадётся уже в первые 4 месяца.

Тут для меня тоже как то странно. Ну ок, я питона никогда вживую не видел. Возьмем для примера яву. Берем проект и разбиваем его на сотню историй.

Берем команду программистов. Как это она сама распадется? Это что, банда Махно? К черту агил, на крайняк раздаем задания прямо, учитывая способности. Ну и организуем планерки для отчетности. Иванов, каркас модуля заложил? Почему, что мешает? Нужна помощь? Или нехватает звездюлей в организме?

Каждый программист получает КОНКРЕТНОЕ задание с обозримыми сроками. И выполняет его или отдает обратно как несправившийся. Если несправляется регулярно, тогда это не программист, а ошибка Господа Бога и из команды его убирают.

Я просто не понимаю, как нормальная команда может завалить нормально запланированный проект...

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

Я ж уже говорил: ТЗ часто отсутствует или там в ТЗ написано что-нибудь типа "проект должен работать надлежащим образом". И, вот, менеджер проекта должен сам догадаться, что означает "надлежащим образом".

Или такой вариант: "программа должна отправлять пакету туда-то и читать их отткда-то", но формат входящих пакетов не указан. Понимай как хошь.

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

Ну, вот, например, я пишу свой код на c++, который должен на вход принимать данные. Но реальных данных нет. Значит нужен какой-нибудь эмулятор данных. Мне приносят какой-то эмулятор, написанный на питоне, который до меня писал другой программист под свою задачу. Я обычно отказываюсь от таких услуг и пишу сам себе свой эмулятор. А некоторые не отказываются, а начинают переделывать свой продукт под формат эмулятора. В результате появляется куча закладок, которые потом надо удалять... А заказчик потом БАБАААХ и выдвинет новое требование, противоречащее предыдущим.

Менеджер проекта не может всем программистам раздать корректные задачи, потому что он ещё и сам ТЗ в глаза не видел....

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

Вот тогда кто-нибудь из коллектива ставить вопрос ребром, принимает весь проект на себя и пишет его один

он не бросает проект после получения оплаты

странная какая то ситуация, никогда еще не сталкивался. Работает значит человек на фирме, как обычно, получает свою зарплату.

А потом раз, отойдите все в сторону, я буду делать ентот проект и еще ему за это доплачивают? А остальные что делают в это время?

проект должен работать надлежащим образом
программа должна отправлять пакету туда-то и читать их отткда-то, но формат входящих пакетов не указан.

Знакомая ситуация с заказчиком, но разруливается звонком/письмом. За подобное ТЗ проект менеджер получит большой втык в первый раз.

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

Тоже часто было. Но! Всегда вначале письменно оговаривается интерфейс.

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

А заказчик потом БАБАААХ и выдвинет новое требование, противоречащее предыдущим.

все бывает. Для этого всё вначале описывается и передается на подпись заказчику.

Новые требования анализируются на соответствие старым и возможности реализации.

Разговор примерно следующий:

-это мы сделаем через пару дней дней

-для этого нужно будет неделя.

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

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

С эмуляторами тоже самое, вначале описанный протокол, затем эмулятор. Иногда описание до 10 версий доходит.

я питона никогда вживую не видел

вот только что ссылка пришла

https://www.kaggle.com/learn/data-visualization-from-non-c...

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

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

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

На производственных предприятиях вообще часто даже такой должности как "менеджер проекта" не существует. Я уж не говорю об "аналитиках" и прочих спецах.

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

Это ведь ПРОИЗВОДСТВЕННОЕ предприятие, тут к программистом относятся как к обычным рабочим и никому не приходит в голову создавать какую-то должность для управления ими. Фразу "менеджер проекта" тут произносят с улыбкой на лице и издевательской интонацией в голосе.

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

от мы купили пять тыщ контроллеров, но они неинтегрируемы в нашу систему

Я могу сделать совершенно другой вывод - Какая фиговая система.

Не нужно делать никаких выводов!

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