vit_r: default (vit_r)
[personal profile] vit_r
А нужно обязательно дорогостоящего, или подойдет просто хороший?
[livejournal.com profile] pvn123 тут



Думаю, все уже прочитали эпический пост про программиста, пославшего нафиг подрядчиков с менеджерами и решившего всё запрограммировать самостоятельно, а также дискуссию по этому поводу у [livejournal.com profile] metaclass и в вечернем противогазе

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

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

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

Да, в индустрии говорят о занятой памяти, скорости доступа, молятся на букву «O», особо продвинутые знают страшные слова вроде «цикломатическая сложность» и, даже, могут постараться и выдать число. Но всё это пустое. Единственная интересная метрика из популярных - function points. Правда для того, чтобы из цифр что-то полезное извлечь, нужно иметь базу по многим годам и многим проектам для тех же задач, тех же методик и того же персонала.

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

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

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

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

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

Date: 2013-11-22 09:56 am (UTC)
From: [identity profile] raydac.livejournal.com
там же диагноз и их директору и всей управляющей верхушке и написавшему сделан
"Но нужно, чтобы программист продолжал работы с этим подрядчиком."
это говнофирма

Date: 2013-11-22 10:03 am (UTC)
From: [identity profile] vit-r.livejournal.com
Это "обычная фирма" и "современный стандарт индустрии". Кстати, не только в ИТ.
Edited Date: 2013-11-22 10:03 am (UTC)

Date: 2013-11-22 10:06 am (UTC)
From: [identity profile] raydac.livejournal.com
программист поступает абсолютно правильно, это не его проблема что он погружен в говнопроцессы говнофирмочки, работой с подрядчиком должен заниматься менеджер проекта или координатор проекта, но никак не программист, которого менеджер может привлекать для консультаций, но как видим в тексте, в этом овощном ИТ-ларьке, есть походу программист и директор с замом, программист совмещает в себе все возможные роли и понятно что всё идет к жопе

Date: 2013-11-22 10:15 am (UTC)
From: [identity profile] vit-r.livejournal.com
Я бы на его месте не пытался спасти неспасаемое, а просто нашёл бы другое место до того, как всё развалится. Понятно, что даже если он что-то может, сделать это ему не дадут. И пусть они сто раз повторяют "да, надо уволить, но после того, как используем до конца"

Date: 2013-11-22 10:18 am (UTC)
From: [identity profile] raydac.livejournal.com
сейчас пошел какой то безумный тренд когда программист это не программист, а
- программист
- системный архитектор
- системный администратор
- технический писатель
- менеджер проекта
- тестировщик
и всё это желательно за те же самые деньги
неудивительно что проекты скатываются в полный булшит

Date: 2013-11-22 10:23 am (UTC)
From: [identity profile] retiredwizard.livejournal.com
Зато менеджер проекта по рашковански - это активная девочка, с невысокой зарплатой.

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

Date: 2013-11-22 10:25 am (UTC)
From: [identity profile] raydac.livejournal.com
ну слово "менеджер" в рф изначально означает - планктон бегающий с сумкой по офисам и впаривающий булшит

Date: 2013-11-22 10:26 am (UTC)
From: [identity profile] vit-r.livejournal.com
Это тренд мировой. В Германии всё то же самое плюс практически полная невозможность уволить за профнепригодность.

Date: 2013-11-22 10:27 am (UTC)
From: [identity profile] raydac.livejournal.com
да и не только в Германии,невГермании тоже, но невГермании легко уольняют
Edited Date: 2013-11-22 10:27 am (UTC)

Date: 2013-11-22 10:30 am (UTC)
From: [identity profile] vit-r.livejournal.com
В Германии тоже относительно легко увольняют. Но не тех, кто нифига не может, а тех, кто путается под ногами, пока коллектив дружным строем идёт в направлении топи.

Date: 2013-11-22 10:26 am (UTC)
From: [identity profile] raydac.livejournal.com
девочек таких, увы, распложилось слишком много и имхо им лучше рычагов вообще не давать, из того что видел, ответственности они всеравно никакой не несут, декоративные

Date: 2013-11-22 11:57 am (UTC)
From: [identity profile] retiredwizard.livejournal.com
так именно потому и стервозные девочки, что нормальному человеку там - делать нечего.
Я за последний года из двух таких конторок уволился, сам. Сейчас спокойно устраиваюсь джава-девелопером.

А ебанарики-хозяйчики пусть остаются со своими милыми бесправными девочками, и с них требуют "реультата". Я теперь отвечаю только в рамках своих полномочий - только за себя.

Date: 2013-11-22 12:02 pm (UTC)
From: [identity profile] raydac.livejournal.com
что о не уверен что тебе удастся в РФ найти конторку где тебе дадут отвечать "в рамках полномочий", там не любят "итальянских забастовок" )))

Date: 2013-11-22 12:12 pm (UTC)
From: [identity profile] retiredwizard.livejournal.com
ну вот посмотрим. пока мне кажется что бесправнее рашкованского матричного "менеджерка" никого нет.
пойду освежу в памяти, что там на другой стороне баррикадок.

Date: 2013-11-22 10:28 am (UTC)
From: [identity profile] raydac.livejournal.com
да, в основном вместо помощи это название закрывает дыры в стенах

Date: 2013-11-22 10:31 am (UTC)
From: [identity profile] orleanz.livejournal.com
а кстати, в том проекте, о котором идет речь (где строптивый программист) - аджайл который ты так не любишь бы помог

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

они же там по страринке решили сделать не итеративно, и теперь огребают

Date: 2013-11-22 10:35 am (UTC)
From: [identity profile] vit-r.livejournal.com
Практика показывает, что изменение процессов и названий не способно заменить бортовой компьютер между ушами.

Date: 2013-11-22 10:41 am (UTC)
From: [identity profile] orleanz.livejournal.com
название - не способно, а процесс при котором уже на ранней стадии разработки можно заметить серьезные косяки - очень полезная штука

Date: 2013-11-22 11:02 am (UTC)
From: [identity profile] vit-r.livejournal.com
Невозможно в agile первого уровня заметить серьёзнче косяки, как невозможно разглядеть впереди обрыв или болото, если идти, смотря только себе под ноги.

Date: 2013-11-24 11:07 am (UTC)
From: [identity profile] orleanz.livejournal.com
если делать реалистичный прототип, то можно

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

Date: 2013-11-24 11:36 am (UTC)
From: [identity profile] vit-r.livejournal.com
Прототип - это уже не первый уровень. И ни одна контора, исповедующая эту религию, подобного богохульства не позволит.

Это раз. И за два идёт то, что скриптами имитируется представление программистов, а не поведение пользователей.

Date: 2013-11-23 09:45 pm (UTC)
From: [identity profile] sergey lysak (from livejournal.com)
в аджайле все косяки массово выплывают в конце.

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

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

Date: 2013-11-24 11:04 am (UTC)
From: [identity profile] orleanz.livejournal.com
" в аджайле все косяки массово выплывают в конце.

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

Date: 2013-11-24 11:38 am (UTC)
From: [identity profile] vit-r.livejournal.com
Увидеть бы проект, где это не так.

Найди презентацию microTOOL на какой-то из конференций. Они ввели этот бред, а через несколько лет оказалось, что вся работа идёт на то, чтобы затыкать дыры, и клиенты активно сбегают. (Хотя последнего может быть в презентации и нет)

Но это редкий случай. Обычно такие проекты измеряют только по скорости мельтешения программистов. А когда всё летит к чёрту, просто прибавляют газа.

Date: 2013-11-22 04:32 pm (UTC)
ext_646638: (Default)
From: [identity profile] rdia.livejournal.com
> Нужно просто понять, чем измерять неизмеримое напрямую.

Стандартная естественно-научная задача.

> Так создают статьи в биологии, психологии или экономике.

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

Date: 2013-11-22 04:59 pm (UTC)
From: [identity profile] vit-r.livejournal.com
Обычно в физике можно проверить модель на закрытой специально подобранной системе. В гуманитарных науках это или слишком сложно, или вообще невозможно.

Плюс в физике модели и математика слишком сложные для программистов.

Date: 2013-11-22 05:26 pm (UTC)
ext_646638: (Default)
From: [identity profile] rdia.livejournal.com
> Обычно в физике можно проверить модель на закрытой специально подобранной системе.

Да. Поэтому учить делать эксперимент нужно именно на ней. Где можно всё отсечь и показать, как влияет экспериментатор.

> Плюс в физике модели и математика слишком сложные для программистов.

Значит, в гуманитарных науках модели такие, что программистам вообще ПЦ.

Физику умные люди упрощают так, чтобы даже школьнику было понятно. Собственно, вы сами знаете, что со сложностью надо бороться, чтобы продвинуться дальше. Не важно, в синтезе или в анализе.

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

Profile

vit_r: default (Default)
vit_r

February 2026

S M T W T F S
12 34 567
8 9 1011121314
15161718192021
22232425262728

Most Popular Tags

Style Credit

Expand Cut Tags

No cut tags
Page generated Feb. 11th, 2026 04:20 am
Powered by Dreamwidth Studios