Надеюсь, что смог привлечь ваше внимание таким провокационным (и, признаться, утрированным) заголовком. Хорошо. Теперь позвольте его переформулировать в чуть более изящном и менее завлекающем виде:
В принципе, софт можно написать либо вовремя, либо хорошо, но не то и другое одновременно*
* за исключением считанных случаев в сложившихся высокопроизводительных командах
Вот уже несколько месяцев я размышлял о том, почему создание качественного софта плохо сочетается с оценочными сроками и планированием вообще. За свою карьеру я видел проекты, выстроенные по самым разным моделям (каскадная, подлинно гибкая, гибко-каскадная), и у всех них была одна общая черта: независимо от того, над каким проектом мы работаем, если он делался «по науке» (т.e., мы не позволяли себе грязных уловок, из-за которых нам бы потом снились кошмары), то мы всегда срывали сроки.
С другой стороны, всякий раз, когда проект сдавался «вовремя», это означало, что по ходу дела неизбежно пришлось сократить его объем, либо срезать столько углов, что во время реализации накапливались горы технического долга, практически гарантировавшие, что проект придется переписывать вскоре после запуска. Поэтому я стал задумываться: на самом ли деле можно считать, что проект сдан «в срок», если в результате мы имеем уродливый, неудобный в поддержке, нашпигованный багами и, прямо скажем, более неприглядный вариант кода по сравнению с тем, что мы исходно пытались сделать?
Переведено в Alconost
Мне доводилось работать и на проектах без жестких дедлайнов. Да, формально «дедлайны» там были, но далеко не железобетонные. Все понимали, что сроки у нас гибкие, и что качество важнее своевременной сдачи продукта. Именно на этих проектах у нас получался самый лучший софт, были самые довольные разработчики и, в целом, эти проекты оказывались в числе наиболее успешных среди всех, над которыми мне приходилось работать. Но все мы знаем, что такие проекты — большая редкость, иначе бы я всего этого не писал.
Итак, почему же так сложно спланировать работу и выдать хороший софт, имея жестко заданные сроки? Думаю, это во многом связано с креативностью, мастерством и непредсказуемостью.
Креативная сторона программирования
Я придерживаюсь мнения, что разработка ПО — по определению творческое занятие. Конечно же, есть разработчики, выполняющие однообразные тривиальные задачи, но у них работа есть лишь до тех пор, пока кто-нибудь не придумает, как их работу автоматизировать. Им не позавидуешь, да и тема этой статьи совершенно другая.
Для меня есть нечто особенное в акте создания чего-то нового и в поиске оригинальных решений в ответ на вызовы; поэтому я и ощущаю призвание к разработке ПО, и не думаю, что я один такой. На самом деле, считаю, что креативность — основная причина, по которой разработчики получают удовольствие от своего труда. Мой опыт подсказывает, что всякий раз, когда мне доводилось работать в условиях, где соблюдался строгий и неизменный «набор практик»(будь то технологический стек, процессы, регламентация, и т.д.)? — ?то eсть, чем меньше простора для творчества у меня было — тем меньше меня увлекала такая работа. «В конце концов, если они уже все для себя решили, то зачем им я?»? — думалось мне. С другой стороны, меня гораздо сильнее наполняла, воодушевляла такая работа (в которой я был и наиболее продуктивен), где было сравнительно немного директив сверху, оставался простор для творчества, и мне доверяли самому принимать технические решения.
Важно отметить, что дополнительная творческая свобода приводит к тому, что на пути к достижению решения неизбежно будет больше проб и ошибок ?—? и это нормально. Некоторым кажется, что можно просто знать идеальное решение априори (заранее), еще не написав ни единой строки кода. Я, напротив, настаиваю, что при творческом процессе путь к открытию решения поставленной задачи (это касается не только ПО) требует повозиться: невозможно заранее все знать наверняка; напротив, вы учитесь на практике, постепенно перебирая все новые варианты и придерживаясь тех, что работают, оттачивая свое решение (и, возможно, постепенно сдавая его заказчикам, если вы работаете по «гибкой» методологии) пока вы не будете им довольны.
Только подумайте, сколько раз доводилось кропотливо проектировать компонент на бумаге — лишь затем, чтобы полностью переделать дизайн, стоило только приступить к реализации. В этом деле всегда будут неизвестные неизвестные, и выявить их и справиться с ними можно только апостериори (по факту), за программированием вашего решения, а не тратя массу времени на теоретизирование и не притворяясь, что мы можем заранее обладать идеальной информацией. Такая импровизация плохо сочетается с оценочными сроками.
Кроме того, как и в случае с другими творческими занятиями, при программировании полезно практиковать стратегическую прокрастинацию ?—? этот термин впервые предложил Адам Грант, утверждающий, что часто не удается креативить по требованию, а, напротив, креативность приходит как «push-уведомление» от некого процесса, работающего в фоновом режиме у вас в голове:
«Регулярно прокрастинирующие сотрудники обычно уделяют больше времени дивергентному мышлению, и кураторы чаще оценивали их как более творческих по сравнению с коллегами. Прокрастинация не всегда подпитывает креативность: если сотрудник не обладает уверенной мотивацией решить крупную проблему, то из-за пробуксовки просто отстает. Однако, если человек достаточно увлечен делом и выдает новые идеи, то, отложив задачу, приходит к более творческим решениям».
— Грант, Адам. “Originals: How Non-Conformists Move the World”
Опять же, это не обрадует сторонников централизованного планирования, стремящихся предусмотреть и измерить каждую минуту в проектах по разработке ПО.
Млечный путь, Марс и метеор
Мастерство создания программ
Лучшие разработчики, которых я знаю — это искусные мастера. Мастерство — характерный признак хорошего ПО: вы создаете нечто работающее, причем, создаете наилучшим возможным способом —?относительно несложно создать нечто рабочее, но очень трудно — такое, что не только будет работать, но и выдержит проверку временем.
Поскольку вы — мастер, качество вашей работы говорит о вас. Для вас качество важнее количества, поскольку вы не хотите прослыть автором говнокода, даже если бы могли удовлетворить продакт-менеджера, придав вашей программе внешний лоск, а внутри нашпиговав ее кучей гнусных сюрпризов ?—?такой подход я называю Киндерсюрпризной Разработкой. Вы знаете, что уделить делу достаточно времени и написать хорошую программу — это правильно, поэтому противитесь прессингу «делай быстрее», так как знаешь, что чем больше костылей наставишь сейчас, тем недолговечнее получится твой код, и тем больше проблем с ним будет по ходу дела.
Глазки кровоточат
Мастерство связано с заботой: мы заботимся о том, чтобы сделать отличную работу, о тех, кому придется поддерживать наш код после нас, о наших клиентах, которым должно быть легко обращаться с нашей программой, о товарищах по команде и т.д. Вы так поступаете, поскольку вы не мудак и поскольку знаете, что именно так и следует поступать, если вы печетесь об успехе проекта.
Короче говоря, хорошему инженеру выпадает сложная задача: заботиться о качестве ?—? которое будет ощущаться в долгосрочной перспективе ?—? в мире, где все принято делать по-быстрому.
На практике это выражается в подобных вещах:
- Найти нужное сочетание между инкапсуляцией, расширяемостью, масштабируемостью и т.д.?—?опять же, потребуется итеративный подход методом проб и ошибок, ведь никому не удается сваять наилучшее решение с первой попытки.
- Уделить время рефакторингу, если наткнетесь на постыдно плохой фрагмент кода.
- Писать хорошие, полные тесты?—?может быть, даже заняться TDD
- Программировать в тандеме с коллегой
Стоит ли говорить, что невозможно все это спланировать заранее, поэтому подобный подход все равно не поможет вам уложиться в сроки.
Ваши прогнозы ошибочны
«Даже при наличии четких требований —?а таковых, по-видимому, никогда не бывает —? все равно практически невозможно просчитать, сколько времени уйдет на конкретную работу, поскольку мы никогда не решали данную задачу ранее. Если решали — то просто выдадим вам результат».
— Рон Джеффрис, Движение NoEstimates
Софтверные проекты — это Сложные Системы: они создаются людьми, а поэтому несут отпечаток межличностных отношений, мотивации, коммуникативных проблем и человеческой психологии в целом —? все это весьма сложно смоделировать и количественно выразить в таблице, если вас интересует мое мнение. Итак, софтверные проекты очень сложно моделировать (и, следовательно, прогнозировать). Лучше всего это объясняет Нассим Талеб в своей книге «Антихрупкость»:
«Сложные системы отличаются большой взаимозависимостью (которую трудно распознать) и нелинейными реакциями. «Нелинейный» означает, что когда вы удваиваете, например, дозу лекарства или количество работников на заводе, отдача будет не в два раза больше, а либо намного больше, либо намного меньше. Нельзя сказать, что два уик-энда в Филадельфии в два раза приятнее, чем один, – это я могу утверждать по своему опыту...».
— Нассим Николас Талеб, «Антихрупкость»
Хуже того, учитывая, что время не может быть отрицательной величиной, любые незапланированные «сюрпризы» скорее всего отдалят завершение проекта, а не приблизят его, поскольку существует асимметрия результатов:
«Время не бывает отрицательной величиной, а значит, трехмесячный проект не может быть реализован за нулевой или отрицательный временной промежуток. Поэтому на оси времени, которое движется слева направо, ошибки скапливаются справа, а не слева. Будь неопределенность линейной, мы бы видели, что некоторые проекты завершаются существенно раньше срока (как мы иногда прилетаем на место намного раньше, а иногда намного позже). Но в реальности все не так».
— Нассим Николас Талеб, «Антихрупкость»
Это плохая новость, так как неопределенность гарантирована, и даже небольшие ошибки при оценке отдельных задач будут накапливаться экспоненциально в масштабах проекта. Причем, здесь мы рассматриваем наилучший случай, когда дедлайны устанавливаются самими разработчиками после тщательной оценки сроков. Однако, реальность куда абсурднее: в большинстве случаев «бизнес» ставит сроки как ему угодно, и лишь потом за дело берутся инженеры, планирующие, как бы удовлетворить все требования за этот произвольно заданный период; случай столь же вопиющий, как начинать строительство дома с крыши, а не с фундамента, либо ставить телегу впереди лошади.
Хороший вопрос
Вот несколько примеров, демонстрирующих нелинейность разработки ПО и возникающие при этом циклы обратной связи:
- Как-то раз вы предположили, что API, с которым требуется связываться, принимает
accountId, но на самом деле он принимает лишьmemberId. Добавляем к ориентировочному сроку 4 дня, нужные на рефакторинг кода API —?после чего, в свою очередь, потребуется отдельное ревью, на которое мы добавим еще 2 дня.
- Задача, которую мы рассчитывали решить за 2 дня, растягивается на неделю, поскольку в процессе ревью один из коллег принуждает вас (и правильно делает) рефакторить и оптимизировать отвратительный фрагмент кода, давно ждавший своего часа.
- Вспомните ту задачу-одноходовку, когда требовалось реализовать всего одну новую возможность. Но оказалось, что для этого нужно обновить зависимость, на что ушло 4 дня, а эта операция спровоцировала цепную реакцию с обновлением других зависимостей и целый ворох зависимостей при сборке.
Мы облажались?
Мы просто по инерции продолжаем играть в эту игру с оценками и планированием, просто чтобы уверить себя: якобы мы контролируем ситуации. Но на самом деле ничего мы не контролируем; опыт показывает, что софтверные проекты непредсказуемы. Поэтому я думаю, что лучше сосредоточиться на деле, а не на планировании ?—?#NoEstimates, кто со мной? Однако, конечно же, во многих организациях это не прокатит: «Нельзя просто так взять и позволить инженерам заправлять балом, чтобы никто их не контролировал. Должна быть отчетность!». Я понял.
Вы так не говорите?
Что же тогда делать? Думаю, это сводится к сокращению разрыва между миром таблиц и миром IDE так, чтобы обеспечить инженерам максимум креативности, гибкости и свободу проявлять мастерство, однако, в то же время, ответственно придерживаться обещанного и оправдывать ожидания стейкхолдеров проекта. Технический менеджер (Engineering Manager) — лучший специалист по наведению таких мостов, который также может амортизировать разрыв между двумя мирами. Это работа непростая, но необходимая. Вот как хорошо о ней рассказывает в своей статье Аарон Лонгуэлл:
«Поскольку технические менеджеры обитают на границе между бизнесом и технарями, именно им приходится улаживать противоречия между ожиданиями и реальностью. Они словно рычажная подвеска, которую тянут в разные стороны: защелкнуться может с обеих сторон. Если побеждает бизнес, то разработчиков загоняют до смерти. Если инженерные доводы перевесят деловые, то прощайте бюджет и дедлайны. В любом случае — провал. Успешный менеджер софтверных проектов находит способы действовать гибко; уступать, не ломаясь, и постепенно разруливать трения. Подход «лидерство как служение» может помочь вам обрести такую гибкость».
— Аарон Лонгуэлл, Why Software Development Requires Servant Leaders
Также очень важно наладить прочные доверительные отношения между Производством и Инженерами. Если доверие есть, то вы сможете честно и добросовестно обговорить сроки. Если ранее вы уже доказали, что ваша команда делает хороший софт, то у вас должна быть достаточно хорошая репутация, и стейкхолдеры должны вам доверять, понимая: если уж вы выбились из графика, то по веским причинам и ради общего блага.
Еще один «трюк», которым лично я пользовался на посту менеджера — не называть конкретных дат, поскольку они неизбежно превращаются в жесткие дедлайны. Лучше давать нечеткие сроки, например, «три-пять недель». В таком случае при приближении такого зыбкого дедлайна вы добавляете: «в апреле или в мае», что легко трактуется как «Между 15-м апреля и 3-м мая» в начале апреля, около 10-го апреля может превратиться в «К 20-му апреля» и т.д. В таком случае вы не лукавите, общаясь с коллегами, а команде обеспечиваете гибкость сроков, которая понадобится для разрешения неизбежных непредвиденных проблем, которые возникнут.
Наконец, помните, что именно разработчик должен отвечать за техническое качество выдаваемого продукта, а не другие заинтересованные лица. Совершенно естественно, что будут возникать трения между организациями, которые, на первый взгляд, руководствуются разными стимулами. В данном случае важнее всего отметить, что все вы (предположительно) объединены общей целью: выдавать заказчику качественный софт в максимально сжатые сроки. По-видимому, ?только хорошие разработчики способны мыслить в таком духе и понимать, что важно избегать обманчивого подхода «раз, два — и готово!», который в долгосрочной перспективе оказывается самым медленным.
В заключение скажу, что это решаемая, пусть и сложная (и распространенная) проблема. Я бы сказал, что если на ваш взгляд ваш менеджер или ваша организация не настроены писать хороший софт, то нужно высказаться об этом и попытаться это изменить; если же это не удастся — найти другую работу.
О переводчике
Перевод статьи выполнен в Alconost.
Alconost занимается локализацией игр, приложений и сайтов на 70 языков. Переводчики-носители языка, лингвистическое тестирование, облачная платформа с API, непрерывная локализация, менеджеры проектов 24/7, любые форматы строковых ресурсов.
Мы также делаем рекламные и обучающие видеоролики — для сайтов, продающие, имиджевые, рекламные, обучающие, тизеры, эксплейнеры, трейлеры для Google Play и App Store.
Подробнее
Комментарии (26)
lxsmkv
27.09.2018 21:34Я все время задаюсь вопросом, почему строительство зданий обычно проходит успешно, а с разработкой такие трудности. Архитектор, курирующий строительный проект, смотрит, чтобы все было для того, чтобы работу можно было выполнить по плану. Да проблемы могут возникнуть, но любая проблема решается просто добавлением денег, могут даже на воде построить только плати. Юридические проблемы тоже решаются деньгами. Что-то придумывать как правило не нужно. В большинстве случаев есть типовое решение.
Да с качеством тоже бывают косяки — рушащиеся мосты, разваливающиеся фундаменты и пр.
А в программировани каждый раз как в первый раз. Почему так?
Странно если бы один строитель контролировал качество работы другого. Этим занимается архитектор, и прораб. В разработке один программист ревьюит код другого и это считается нормой. Чем занимается программный архитектор?
Представьте себе конференции по строительству на тему «войлочные валики — добро или зло?» или что нибудь в таком духе. Смешно, да? Почему в программировании создается впечатление, что вообще нет стандартных способов.
У меня только одно обьяснение, что строительством человек занимается с начала времен, а программированием «всего» каких-то жалких 80 лет. Индустрия еще в зачаточной стадии.boblenin
27.09.2018 22:31+1> Я все время задаюсь вопросом, почему строительство зданий обычно проходит успешно, а с
> разработкой такие трудности.
У вас есть какие-то статистические данные на эту тему? Из моего, не реперезентативного, личного опыта — вы слишком идеализируете строительство.lxsmkv
27.09.2018 22:51Вы правы, это систематическая ошибка выжившего. Мы обращаем внимание только на те строительные проекты которые получились. О тех которые провалились мы никогда ничего не узнаем. А их конечно тоже должно быть не мало.
boblenin
27.09.2018 23:16+1Почему же? Например в Washington DC есть монумент Вашингтона. Сроки срывались неоднократно. Так же было с собором Святой Софии. Да те же пирамиды случалось строились с опазданием к ключевому событию. Если более современное — то посмотрите ролики о строительстве в Китае городов-призраков. Особенно на тему балконов обваливающихся через полгода после постройки дома. Да банально… насколько часто граждане довольны ремонтом?!
lxsmkv
27.09.2018 23:40Решил поинтересоваться , а что в строительстве является ключевыми факторами успеха:
На первых трех местах: организация проекта, компетентнось менеджера, и управление рисками.
И только четвертым идет компетентность исполняющей команды.
А характеристики проекта на последнем месте.
Это полностью соответствует тому, что можно выделить в IT в качестве ключевых факторов успеха.
Общий вывод: не важно какой тип проекта ты делаешь — без нормальной организации и управления ты завалишь его скорее чем по какой-то другой причине.
В области управления требованиями на первом месте по важности определение границ требований. Все как у нас.
Вообще запрос «critical success factors construction industry» оказалось выдает огромный пласт информации, т.е «они тоже ищут серебрянную пулю».boblenin
28.09.2018 04:39Все-таки в строительстве есть специфика. Там планирование значительно дешевле собственно изготовления. В разработке ПО не так — планирование сравнимо по стоимости с разработкой.
Closius
27.09.2018 23:34Современное строительство зданий (именно строительство, а не проектирование. современное строительство) — это процесс по уже проверенным и подготовленным документациям вплоть до разблюдовки сроков кто и когда будет что поставлять. То есть все точно знают что надо делать. А если например кто-то что-то не поставил во время — это просто передвижение сроков дальше.
А программирование это творческий процесс. Там в принципе невозможно сказать можно это сделать или нельзя. Например в API модет найтись баг в самом неожиданном месте и все. И чтоб его обойти надо писать дикие костыли так как апи наприемр закрытое.
Есть конечно простые случаи где все понятно, но боле менее сложные задачи это всегда очень рискованно.Daddy_Cool
28.09.2018 02:01Подумал о том же! Впрочем в строительстве тоже бывают внезапные баги.
Пример из жизни — ремонт частном в доме. После трудового дня бригада рабочих культурно отдыхает в одном крыле здания. В этот же момент, в другом крыле здания разрывает шланг подводки воды (конструктивный дефект стандартного изделия). Утром обнаруживается, что крыло залито водой, и количество требуемых работ внезапно выросло с соответствующими сдвигами сроков и стоимости.
А вот тут великие незавершенные стройки.
pastuh83.livejournal.com/230836.html
JediPhilosopher
28.09.2018 19:37Не так все просто со стройкой, и не всегда чертежами готовыми обойдешься. Тут на хабре можно много про это почитать в топиках про BIM.
Наприме в ходе постройки внезапно пришлось срочно поменять поставщика блоков для внутренних стен. А у нового поставщика блоки оказались чуть шире. Из-за этого дверной проем сузился на несколько сантиметров. А в этом помещении должно было располагаться какое-то серьезное оборудование. А в более узкий проем его уже не протащить. А выяснили это только когда уже все построили, отделали и начали затаскивать. Пришлось потом частично все разбирать-перебирать.
Ну а уж рядовые мелочи, типа несогласованности чертежей различных инженерных сетей, когда на чертеже электросети тут распределительный шкаф, а на чертеже вентиляции в этом же месте по плану должен быть вентиляционный короб — это вообще сплошь и рядом.
nsinreal
28.09.2018 01:05Почему в программировании создается впечатление, что вообще нет стандартных способов.
Стандартные способы уже вынесены в ос, фреймворки, библиотеки. Если нет явного NIH (а он на самом деле не так част, как кажется), то любая задача разработки явно содержит элемент нестандартности.
В разработке один программист ревьюит код другого и это считается нормой
У код-ревью больше одной цели. В некоторых конторах ревью используется также в целях гарантии ознакомления хотя-бы одного другого разработчика с этим кодом.
а программированием «всего» каких-то жалких 80 лет. Индустрия еще в зачаточной стадии.
Когда будет решена последняя нестандартная задача — программирование исчезнет как вид деятельности. Вы же не называете программированием использование grep или использование (без написания кода) "визуальных" конструкторов сайтов?
Int_13h
28.09.2018 05:37Программирование — это не что-то сверхособенное до богоподобности и специфическое.
Любая проектная деятельность, любая разработка сталкивается с проблемами, затронутыми в статье. Не важно, разрабатываете вы ПО для социалочки с котиками, офисные небоскребы или АСУ ТП атомной станции, в любом случае будет проблема определения времени, необходимого на разработку, миллионы переделок и срыв заранее заданных сроков.
В любой проектной деятельности будет и элемент творчества, и использованиеранее написанного кодатиповых решений, и сотни итераций с полным переписыванием кода с нуля :), и отладка, и тестирование. И с помощью вливания дополнительных ассигнований не всегда удастся заставить родить 9 женщин ребенка-проект за 1 месяц.
С ПО даже проще, ну будут баги, но сдадим в срок, потом может быть подправим, выкатим через пару лет сервиспак, а пользователи потерпят. А вот после багов проектировщика-строителя людям потом жить в забагованном здании, и надеяться, чтосервердомик не рухнет, если сильно хлопнуть дверью. Финансовые потери на переписывание кода и на снос здания несравнимы.
Типичная проблема времени при проектировании — заказчик говорит, вот такой проект нужен, вот такие объемы, срок? Заказчику говоришь — от полугода до года, основываясь на объемах. Заказчик в ответ — полугода нет, есть только месяц. И заказчик вынужден выбирать, получить халтурно сделанный проект, но быстро, или качественный поект, но со срывом сроков.
Еще одна проблема — оптимизация. С обычным ПО опять же просто — не работает, значит добавьте оперативки, пару ядер или вобще вычислительный кластер. Ибо рабочее время программиста дороже железа. Проектировщика, заявившего, что его рабочее время дороже десятка бетономешалок — просто выставят за дверь. Если необычный программист АСУ ТП неправильно выберет мощность контроллера на этпе подбора оборудования, а потом заявит начальству, что код немного разросся, давайте заказанное оборудование на складе похороним, а закажем вот такую штуку еще за пару миллионов $, у него даже с зарплаты не высчитаешь.
roscomtheend
28.09.2018 10:24Есть большой проект автоматизации, клиент сам не знает до конца как оно должно быть. Есть этапы, на разных этапах происходят уточнение. Потому как есть софт более нижнего уровня, который так велик что даже разработчик (крупная международная корпорация ваяющая его более 20 лет) не знает точно можно ли сделать конкретную хотелку.
Строительство зданий, кстати, тоже происходит не совсем успешно. Затягивают сроки, раздувают бюджеты, недоделки, брак, несоответствие требованиям. Даже с типовыми решениями. А ещё они могут содержать дефекты by design и даже падать от этого. Оно для несталкивающихся выглядит идеально.
> Чем занимается программный архитектор?
Своим отсутствием? Даже в крупных проектах его может не быть (и это боль, и костыли, и боль от вставленных костылей).
> Индустрия еще в зачаточной стадии
Плюс все хотят быстро и дёшево. Вот и получается типо дачных домиков, построенных гостями из более солнечных стран — оно, конечно, похоже на дом, но зачастую только издалека (и чем ниже цена — тем более издалека).
nsinreal
28.09.2018 00:47Есть замечательная альтернатива концепциям "жесткие дедлайны" и "отсутствие эстимейтов": на основе эстимейтов и несоответствия реальности планам нужно убирать низкоприоритетные фичи тз бэклога.
Nubus
28.09.2018 08:07Если бы строили по заданию как у программистов, то после того как построили лифт, то он должен был бы ходить еще и горизонтально, это-же круто! Двери бы для каждой квартиры были-бы разными, а потом вообще этажи должны были-бы меняться местами.
Femistoklov
28.09.2018 08:33И даже не только это. Дом построили, так он так и будет стоять. Никому не придёт в голову его наращивать каждый месяц по этажу. Если на его месте понадобится небоскрёб, то старый дом просто снесут, и заново будут строить.
VadimKolo
28.09.2018 19:40Готов поспорить. У меня дочь учится в школе. И там явно здание изначально было меньше раза в 3. Потом как минимум две пристройки было сделано, которые по площади больше изначального здания.
Также в историческом центре города полно многоквартирных домов 18 века, которые изначально имели печное отопление. Сейчас там газ, центральное отопление и все остальные ништяки цивилизации.
Частные дома вообще принято достраивать. Легко можно надстроить второй этаж, легко несколько пристроек.
sebres
28.09.2018 10:22В принципе, софт можно написать либо вовремя, либо хорошо, но не то и другое одновременно
Вообще-то можно и одновременно… ибо есть еще и третий фактор (в этом треугольнике) — цена вопроса.
Конечно если сроки возможны в принципе (т.е. если вдевятером не нужно будет "родить" за месяц ©).
Revertis
28.09.2018 12:33Эй, Алконостовцы, признавайтесь, что у вас есть некие инопланетные существа, которые пишут такие качественные переводы! Судя по рунету, человеки на такое не способны!
Dr_Faksov
29.09.2018 14:05Есть у меня знакомый, совсем недавно работавший в одной из ведущих американских компаний-производителей мобильных процессоров. Потом надоело, ушел в одну из ведущих компаний по производству видеокарт.
Так вот он говорил мне: Никогда не покупай топовых телефонов в момент их выхода на рынок! Если бы ты видел как мы пишем код к процесору… По принципу — лишь бы явно не глючило.
Потому что живой процессор всегда появляется позже установленных сроков и всегда отличается от эмулятора. А срок выхода топового телефона сдвинуть невозможно.
evocatus
А что значит вовремя? Когда какой-то лунатик, ничего не понимающий в разработке, выдумал из головы срок, а команда профессионалов не успела реализовать выдуманную тем же лунатиком функциональность, кто виноват?
Если я пойду к Маску и потребую отвезти меня на Марс к началу октября за 500 рублей, он меня на *** пошлёт и будет прав.
P.S. Читайте Роберта Мартина («Идеальный программист» — это действительно хорошая книга и там даже есть формула по которой сроки оценивать — PERT) и учитесь говорить «нет», «это невозможно» и никогда, никогда не говорите «я постараюсь» — это подразумевает, что обычно вы не стараетесь.
CactusKnight
Если «команда профессионалов» добровольно согласилась на сроки, выдвинутые «лунатиком, ничего не понимающий в разработке», то какие-то они хреновые профессионалы
Closius
Я какраз таки говорю всегда «я потораюсь» или «я это никогда не делал, но постораюсь». Но никогда не говорю, что я это сделаю точно. А вот нет говорю только в точно местах, в которых я уверен. Даже не «нет» а «на сколько я знаю нет» или «по моему опыту это не возможно»
Но тут стоит сказать — я работаю в европейской международной компании
roscomtheend
Лунатику нужен результат к сроку или лунатику нужно закупить оборудование и начать окупать вложения в разработку. Купит оборудование раньше завершения — потеря денег, завершится раньше — начнут окупаться позже. Программы ради программ нужны только программистам в вакууме.
JediPhilosopher
Тут скорее думаю речь о типичном случае, когда менеджеру очень хочется урвать контракт (выслужиться, премию получить или даже из благих соображений — добыть денег для компании) и он пытается это сделать любой ценой — в частности демпингуя по срокам и цене, совершенно не думая о том, как команда потом будет это расхлебывать и реализовывать