Бизнес-задачи, менеджмент, быдлокодинг

Ещё раз, речь не о вылизывании и не о дедлайнах, а о том, что разработчик вынужден заниматься менеджментом, чтобы проект скатился в говно хотя бы через год, а не скоропостижно уже через месяц

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

Но все равно интересно - какой бы вы видели свою идеально-оптимальную работу? )

Билеты покупают простые люди, и их доллар решает всё в индустрии

А выбора нет ) Боинг, эйрбас и много мелких производителей, которые порой оказываются еще хуже боинга. Альтернативы нет, пешком не пойдешь.

их интересует только сам факт и название самолета/авиакомпании. Вон у малайзийцев два самолета пропало — авиакомпания разорилась.

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

Я хотел бы подчеркнуть, что здесь цена вопроса находится на порядке тысячи долларов. При миллиардных оборотах.

Похоже, ты не понимаешь что такое «оборот». Компания моет иметь миллиардные обороты и при этом быть в минусе.

И речь идет про HTML, на котором программирует куча школьников.

Что ее раз подтверждает твою неопытность.
Во-первых, проблему нужно сначала локализовать. А в случаях, когда библиотека на библиотеке и библиотекой погоняет это не всегда просто.
Во-вторых, важно продумать импакт и возможные регрессии. И пусть тебя не вводит в заблуждение, что возможно там нужно поправить две строки на HTML. Я сталкивался со случаем, когда девелопер 3 дня анализировал проблему, чтобы потом дописать 10 строк. И, предупреждая твой вопрос, у меня есть все основания говорить, что это время было обосновано.

Около половины стартапов умирает в течение 4 лет, 90% всех стартапов загнулось.

Именно. Из-за отсутствия маркетинга и желания отполировать свой код.

с чего вам беспокоиться о будущем его и его фирмы?

И я о том же. Но не всё так просто. В какой-то момент при таком подходе получится итальянская забастовка.

какой бы вы видели свою идеально-оптимальную работу?

Полёживание в гамаке за 300к в секунду. Или дегустатор грудей.

Я тебе про время-бюджет-качество, а ты опять в технику скатываешься. Ты вообще прочитал мой коммент?

Я заметил в моем сообщении потенциал для такого недопонимания, потому написал дополнительный ответ:
Бизнес-задачи, менеджмент, быдлокодинг (комментарий)

В данном случае времени-бюджета сильно больше, чем качества.

Баг состоит в том, что есть лишний скроллбар, который, да, немного мешает, но критично не влияет на работу. Нужно 2 пользователям, притом не коммерческим. Atlassian предоставило workaround с урезанным функционалом: подойдет не всем, но кому-то подойдет.

Пардон, это другой баг, тоже со скролами. Я имею в виду вот это, которое прямо у них на сайте повторяется: https://imgur.com/a/dE2nxJi

Если бы ты был держателем бюджета, ты бы тратил деньги на решение этого бага?

Тут очень много факторов «если б да кабы». Конкретно я списываю все проблемы на потребителя и инвестора, а не на производителя-исполнителя. Исполнитель (atlassian) зажат в некие рамки, которые, вполне возможно, могли бы и расшириться, если бы внезапно у них появился я. Сам факт наличия многочисленных альтернатив говорит, что далеко не всё у них гладко.

И я о том же. Но не всё так просто. В какой-то момент при таком подходе получится итальянская забастовка.

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

Полёживание в гамаке за 300к в секунду. Или дегустатор грудей.

А если оставить выбор только среди реально существующих программерских видов деятельности? )

А выбора нет ) Боинг, эйрбас и много мелких производителей, которые порой оказываются еще хуже боинга. Альтернативы нет, пешком не пойдешь

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

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

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

Похоже, ты не понимаешь что такое «оборот». Компания моет иметь миллиардные обороты и при этом быть в минусе

Может. Но не в этом случае:
https://investors.atlassian.com/financials-and-filings/news/news-details/2019...

Во-первых, проблему нужно сначала локализовать. А в случаях, когда библиотека на библиотеке и библиотекой погоняет это не всегда просто.
Во-вторых, важно продумать импакт и возможные регрессии. И пусть тебя не вводит в заблуждение, что возможно там нужно поправить две строки на HTML. Я сталкивался со случаем, когда девелопер 3 дня анализировал проблему, чтобы потом дописать 10 строк. И, предупреждая твой вопрос, у меня есть все основания говорить, что это время было обосновано

Ну, 3 дня работы плюс тестирование — это и есть тот самый уровень тысячи долларов. Что более важно — это что в Atlassian отсутствует организация для решения простейших технических вопросов, вместо этого они решаются по крайней необходимости.

Около половины стартапов умирает в течение 4 лет, 90% всех стартапов загнулось.

Именно. Из-за отсутствия маркетинга и желания отполировать свой код

Там в большинстве случаев люди вообще не разбираются в предметной области. Из самых ярких примеров я бы вспомнил MySQL и MongoDB, создатели которых не разбирались в проектировании СУБД. У них если в этом месяце не умер — и то праздник. Там такой угар, что коррупция и некомпетентность чиновников в СНГ может показаться детским садом.

Лишь бы не в организации галерного типа, а роль не так и важна.

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

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

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

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

Лишь бы не в организации галерного типа, а роль не так и важна.

То есть, если взглянуть спокойно, то красота и вылизанность кода не столь для вас и важна? )

Я не уловил стремительную как пегас мысль, видимо.

То есть, если взглянуть спокойно, то красота и вылизанность кода не столь для вас и важна?

Каким образом при прочих равных моя роль влияет на чистоту проекта?

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

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

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

Будучи обезьянкой, я могу просто херачить чёткий пацанский код.

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

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

б) за срок >>X, с получением той же суммы Y, (в пересчете на ЗП она пропорционально снизится) но продукт выйдет отлаженным, с красивым, оптимизированным кодом. Кроме вас и коллег это никто не оценит.

То есть вполне жизненная ситуация - вас никто не торопит, но когда сделаете, тогда и получите бабки. Как поступите?

Поддержка не требуется, головняк не грозит

Выбор слишком простой. Топик не об этом. Топик не о разовом проекте на выброс, а о продукте.

Выбор слишком простой.

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

Топик не об этом

Мне был интересен ваш выбор, но вы постарались уйти от ответа.

Топик не о разовом проекте на выброс, а о продукте.

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

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

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

У вас та же психологическая болячка, что и у большинства обитателей лора - генерализация частных случаев )

Впрочем, вы совершенно правильно заметили - «в идеале». Намеренно или ненамеренно вы упустили важную деталь - не бывает компаний, бесплатно и долго поддерживающих продукт. В кабалу на неопределенный срок никто не пойдет ) Это почти всегда некий гарантийный период, после которого идет платная поддержка. А иногда и сразу платная ) То есть компания продолжает получать ощутимые деньги, за которые в течение которых она будет не торопясь вылизывать свой продукт. Главное же уже сделано - продукт продан, договор на поддержку подписан. А теперь представьте - во главе компании сидит перфекционист, подобный вам, который не поставит продукт заказчику, пока не вылижет все ошибки :)

Вот об этом и был вопрос - в какой момент вы сочтете продукт готовым? )

внутренний продукт

Который экономит деньги компании.

Готовым может быть проект. А продукт может развиваться, либо нет. Условия стадия готовности — попадание в прод. Развитие от этого не останавливается. Может остановиться по какой-то другой причине.

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

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

У проекта есть конец — его реализация.

В какой момент вы сочтете продукт готовым для передачи/продажи заказчику?

Вопрос абстрактный или речь о конкретном вышеназванном продукте?

У проекта есть конец — его реализация.

Видимо вы никогда не видели как проекты меняются и по мере его реализации и после нее - в соотвествии с постоянно меняющимися потребностями заказчика ) Но ладно, это неважно

Вопрос абстрактный или речь о конкретном вышеназванном продукте?

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

Мало вводных.

Вполне достаточно. Это специально, чтобы вы не тонули в ненужных деталях и не искали способа увильнуть от прямого ответа :)

В зависимости от вводных ответ будет разным.

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

Так ответ и без того очевиден. Тем более, что я один раз уже ответил: Бизнес-задачи, менеджмент, быдлокодинг (комментарий)

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

Если проект разовый, всё зависит от того, сколько платят и какие требования. В общем случае это будет 90%-е решение. Всё равно немного допиливать придётся.

Так ответ и без того очевиден.

Мне не был очевиден. Тем более с преобладанием перфекционистов, идеалистов и максималистов в этом топике.

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

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

В общем случае это будет 90%-е решение. Всё равно немного допиливать придётся.

В общем случае понятно. Сойдет за то, что я хотел услышать )

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

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

а) за срок Х с получением суммы денег Y, но продукт выйдет сырым, говняньким, с ошибками, но вполне приемлемым для заказчика. Поддержка не требуется, головняк не грозит
б) за срок >>X, с получением той же суммы Y, (в пересчете на ЗП она пропорционально снизится) но продукт выйдет отлаженным, с красивым, оптимизированным кодом. Кроме вас и коллег это никто не оценит
То есть вполне жизненная ситуация - вас никто не торопит, но когда сделаете, тогда и получите бабки. Как поступите?

Я выбираю вариант «c»: выкатить сырющую промежуточную версию, получить деньги за промежуточный этап, отдать проект на доработку индусам с рейтом $2 в час, и резко исчезнуть. Причем, вполне возможно, что полученный продукт вполне устроит заказчика, если условие стоит «продукт выйдет сырым, говняньким, с ошибками, но вполне приемлемым для заказчика. Поддержка не требуется, головняк не грозит».

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

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

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

Есть огромное кол-во фирм, которые существуют десятками лет, у которых до сих пор системы на ES4, VBA, втором питоне, пятом пыхе. Они не светятся, мол, «набираем свежие таланты» — они просто работают. И им нужны ровно противоположные критерии разработки. Может быть это и менее массовый рынок, не спорю, но я бы заметил, что на массовом рынке доминируют бездарности с накручиванием рейтингов на фрилансовых площадках или чуть более серьезные фирмы, которые пытаются стать в каждой бочке затычкой, чтобы приходящие не разбирающиеся в отрасли клиенты сразу обращались к ним за порцией говна. Результат простой: когда приходит немногочисленный серьезный заказчик, который планирует заниматься долгосрочным бизнесом и хочет серьезную систему, получается кусок говна, долго мучивается, и переплачивает за систему, итоговый срок и стоимость разработки которой намного превышает тот самый вариант:

б) за срок >>X, с получением той же суммы Y, (в пересчете на ЗП она пропорционально снизится) но продукт выйдет отлаженным, с красивым, оптимизированным кодом. Кроме вас и коллег это никто не оценит

И получается именно потому, что априори заказчик не смог этого оценить. Конечно, в реальности эта фирма просто обратится в Oracle, где с нее снимут последние трусы, или в TopTal, где с него снимут последнюю рубашку, а трусы оставят.

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

Давай, расскажи мне про вопросы экономической эффективности во взаимоотношениях с женой и детьми. Ты лучше бы прямо и написал «как украсть у других и принести в семью» — при чем тут кодинг?

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

I know that feel bro. У меня лично есть такой проект. Я проработал в нем много лет, и у меня жопа горит с того, что мой код работает безупречно, но соседний модуль, к которому у меня нет доступа, глючит беспощадно, и в итоге клиент прибегает с криками «где мои товары? Где мои комментарии» — а я знаю, где твои товары и комментарии? Мой код отработал безупречно.

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

Было бы интересно понаблюдать за реакцией вашего руководства и коллег

У меня нет руководства с прошлого века. А коллеги в большинстве случаев вполне трезвомыслящие.

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

Просранность сроков почти никогда не является серьезной проблемой.
Заказчикам обычно важнее видеть, что деньги не исчезают зря, а проект движется. Требования же согласуются и уточняются в рабочем порядке. Вместе с проектом ) Хорошему заказчику всегда можно объяснить чего именно он хочет )

Я выбираю вариант «c»: выкатить сырющую промежуточную версию, получить деньги за промежуточный этап, отдать проект на доработку индусам с рейтом $2 в час, и резко исчезнуть. Причем, вполне возможно, что полученный продукт вполне устроит заказчика, если условие стоит «продукт выйдет сырым, говняньким, с ошибками, но вполне приемлемым для заказчика. Поддержка не требуется, головняк не грозит».

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

Давай, расскажи мне про вопросы экономической эффективности во взаимоотношениях с женой и детьми. Ты лучше бы прямо и написал «как украсть у других и принести в семью» — при чем тут кодинг?

Не как украсть, а как заработать. Будете вылизывать свой код слишком долго - заработаете меньше чем могли бы - получите соответствующее «фи» от жены. Тем более что ваше вылизывание как правило никому не нужно, ниже вы сами назвали почему:

Я проработал в нем много лет, и у меня жопа горит с того, что мой код работает безупречно, но соседний модуль, к которому у меня нет доступа, глючит беспощадно, и в итоге клиент прибегает с криками «где мои товары? Где мои комментарии» — а я знаю, где твои товары и комментарии? Мой код отработал безупречно.

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

В этом мире это почти норма. Нравится вам это или нет. Если забить болт для бизнеса выгоднее - он будет забиваться.

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

А можно не быть долбоклюями, собрать требования, зафиксировать ТЗ и заняться проектированием.

Хорошему заказчику всегда можно объяснить чего именно он хочет

Согласен только с этим. Но и это делается не с переобуванием в воздухе, а заранее.

лучше бы прямо и написал «как украсть у других и принести в семью» — при чем тут кодинг?

Жму обе руки.

А можно не быть долбоклюями, собрать требования, зафиксировать ТЗ и заняться проектированием.

Как хорошо все устроено в идеальном мире. Там и код пишут без ошибок, и тз фиксируется навсегда, и сроки соблюдаются )

Согласен только с этим. Но и это делается не с переобуванием в воздухе, а заранее.

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

тз фиксируется навсегда

и сроки соблюдаются

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

из-за новых веяний и на рынке и в политике

То у вас проекты и год не живут, то веяния успевают перемениться и политика, определитесь.

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

То у вас проекты и год не живут, то веяния успевают перемениться и политика, определитесь.

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

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

Хорошему заказчику всегда можно объяснить чего именно он хочет

Согласен только с этим. Но и это делается не с переобуванием в воздухе, а заранее.

Если бы он еще заранее знал. Заказчик ведь тоже не всеведущ. Обязательно выяснится на полдороге (после тыканья первой рабочей версии), что вот здесь и здесь он ошибался и недопонимал, а здесь практика показала, что этим пользоваться очень трудно — то есть если продолжить пилить по первоначальному плану, получится ненужно. И какая тогда разница, насколько качественно это ненужно реализовано?

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

Да не, аджайл какой-то. Лучше будем четко по плану пилить ненужно из говнокода без тестов и документации, все ведь так делают.

Прогибаться и лизать жопы, я понял.

Ты с кем-то другим общаешься, видимо. Ведь я выше написал то же самое.

четко по плану пилить ненужно из говнокода без тестов и документации

А это уже шиза.

Ну будьте же взрослее ) Неужели вам хлопать дверью кажется разумнее? Тогда до менеджмента вы пока малость недозрели

Ведь я выше написал то же самое.

Ты же вроде там мечтаешь о полностью собранных заранее требованиях и зафиксированном намертво ТЗ. Что как бы идет полностью вразрез с тем, что я написал.