Комментарии 30
Если я пойду к Маску и потребую отвезти меня на Марс к началу октября за 500 рублей, он меня на *** пошлёт и будет прав.
P.S. Читайте Роберта Мартина («Идеальный программист» — это действительно хорошая книга и там даже есть формула по которой сроки оценивать — PERT) и учитесь говорить «нет», «это невозможно» и никогда, никогда не говорите «я постараюсь» — это подразумевает, что обычно вы не стараетесь.
Но тут стоит сказать — я работаю в европейской международной компании
Если часто говорить нет, то найдутся с другой команды, которые скажут "я попробую", потом трижды перенесут срок, и в конце концов сделают (и будут в своем поведении абсолютно правы).
Да с качеством тоже бывают косяки — рушащиеся мосты, разваливающиеся фундаменты и пр.
А в программировани каждый раз как в первый раз. Почему так?
Странно если бы один строитель контролировал качество работы другого. Этим занимается архитектор, и прораб. В разработке один программист ревьюит код другого и это считается нормой. Чем занимается программный архитектор?
Представьте себе конференции по строительству на тему «войлочные валики — добро или зло?» или что нибудь в таком духе. Смешно, да? Почему в программировании создается впечатление, что вообще нет стандартных способов.
У меня только одно обьяснение, что строительством человек занимается с начала времен, а программированием «всего» каких-то жалких 80 лет. Индустрия еще в зачаточной стадии.
> разработкой такие трудности.
У вас есть какие-то статистические данные на эту тему? Из моего, не реперезентативного, личного опыта — вы слишком идеализируете строительство.
На первых трех местах: организация проекта, компетентнось менеджера, и управление рисками.
И только четвертым идет компетентность исполняющей команды.
А характеристики проекта на последнем месте.
Это полностью соответствует тому, что можно выделить в IT в качестве ключевых факторов успеха.
Общий вывод: не важно какой тип проекта ты делаешь — без нормальной организации и управления ты завалишь его скорее чем по какой-то другой причине.
В области управления требованиями на первом месте по важности определение границ требований. Все как у нас.
Вообще запрос «critical success factors construction industry» оказалось выдает огромный пласт информации, т.е «они тоже ищут серебрянную пулю».
А программирование это творческий процесс. Там в принципе невозможно сказать можно это сделать или нельзя. Например в API модет найтись баг в самом неожиданном месте и все. И чтоб его обойти надо писать дикие костыли так как апи наприемр закрытое.
Есть конечно простые случаи где все понятно, но боле менее сложные задачи это всегда очень рискованно.
Пример из жизни — ремонт частном в доме. После трудового дня бригада рабочих культурно отдыхает в одном крыле здания. В этот же момент, в другом крыле здания разрывает шланг подводки воды (конструктивный дефект стандартного изделия). Утром обнаруживается, что крыло залито водой, и количество требуемых работ внезапно выросло с соответствующими сдвигами сроков и стоимости.
А вот тут великие незавершенные стройки.
pastuh83.livejournal.com/230836.html
Наприме в ходе постройки внезапно пришлось срочно поменять поставщика блоков для внутренних стен. А у нового поставщика блоки оказались чуть шире. Из-за этого дверной проем сузился на несколько сантиметров. А в этом помещении должно было располагаться какое-то серьезное оборудование. А в более узкий проем его уже не протащить. А выяснили это только когда уже все построили, отделали и начали затаскивать. Пришлось потом частично все разбирать-перебирать.
Ну а уж рядовые мелочи, типа несогласованности чертежей различных инженерных сетей, когда на чертеже электросети тут распределительный шкаф, а на чертеже вентиляции в этом же месте по плану должен быть вентиляционный короб — это вообще сплошь и рядом.
Почему в программировании создается впечатление, что вообще нет стандартных способов.
Стандартные способы уже вынесены в ос, фреймворки, библиотеки. Если нет явного NIH (а он на самом деле не так част, как кажется), то любая задача разработки явно содержит элемент нестандартности.
В разработке один программист ревьюит код другого и это считается нормой
У код-ревью больше одной цели. В некоторых конторах ревью используется также в целях гарантии ознакомления хотя-бы одного другого разработчика с этим кодом.
а программированием «всего» каких-то жалких 80 лет. Индустрия еще в зачаточной стадии.
Когда будет решена последняя нестандартная задача — программирование исчезнет как вид деятельности. Вы же не называете программированием использование grep или использование (без написания кода) "визуальных" конструкторов сайтов?
Любая проектная деятельность, любая разработка сталкивается с проблемами, затронутыми в статье. Не важно, разрабатываете вы ПО для социалочки с котиками, офисные небоскребы или АСУ ТП атомной станции, в любом случае будет проблема определения времени, необходимого на разработку, миллионы переделок и срыв заранее заданных сроков.
В любой проектной деятельности будет и элемент творчества, и использование
С ПО даже проще, ну будут баги, но сдадим в срок, потом может быть подправим, выкатим через пару лет сервиспак, а пользователи потерпят. А вот после багов проектировщика-строителя людям потом жить в забагованном здании, и надеяться, что
Типичная проблема времени при проектировании — заказчик говорит, вот такой проект нужен, вот такие объемы, срок? Заказчику говоришь — от полугода до года, основываясь на объемах. Заказчик в ответ — полугода нет, есть только месяц. И заказчик вынужден выбирать, получить халтурно сделанный проект, но быстро, или качественный поект, но со срывом сроков.
Еще одна проблема — оптимизация. С обычным ПО опять же просто — не работает, значит добавьте оперативки, пару ядер или вобще вычислительный кластер. Ибо рабочее время программиста дороже железа. Проектировщика, заявившего, что его рабочее время дороже десятка бетономешалок — просто выставят за дверь. Если необычный программист АСУ ТП неправильно выберет мощность контроллера на этпе подбора оборудования, а потом заявит начальству, что код немного разросся, давайте заказанное оборудование на складе похороним, а закажем вот такую штуку еще за пару миллионов $, у него даже с зарплаты не высчитаешь.
Строительство зданий, кстати, тоже происходит не совсем успешно. Затягивают сроки, раздувают бюджеты, недоделки, брак, несоответствие требованиям. Даже с типовыми решениями. А ещё они могут содержать дефекты by design и даже падать от этого. Оно для несталкивающихся выглядит идеально.
> Чем занимается программный архитектор?
Своим отсутствием? Даже в крупных проектах его может не быть (и это боль, и костыли, и боль от вставленных костылей).
> Индустрия еще в зачаточной стадии
Плюс все хотят быстро и дёшево. Вот и получается типо дачных домиков, построенных гостями из более солнечных стран — оно, конечно, похоже на дом, но зачастую только издалека (и чем ниже цена — тем более издалека).
К примеру, строительство жилых многоэтажных домов в Украине почти никогда не завершается в срок...
Есть замечательная альтернатива концепциям "жесткие дедлайны" и "отсутствие эстимейтов": на основе эстимейтов и несоответствия реальности планам нужно убирать низкоприоритетные фичи тз бэклога.
Также в историческом центре города полно многоквартирных домов 18 века, которые изначально имели печное отопление. Сейчас там газ, центральное отопление и все остальные ништяки цивилизации.
Частные дома вообще принято достраивать. Легко можно надстроить второй этаж, легко несколько пристроек.
В данной ситуации лучше тогда было изначально делать с учётом того, что проект будет развиваться. Но и времени это займёт больше. Если он не будет развиваться, проиграем, если будет, выиграем.
В принципе, софт можно написать либо вовремя, либо хорошо, но не то и другое одновременно
Вообще-то можно и одновременно… ибо есть еще и третий фактор (в этом треугольнике) — цена вопроса.
Конечно если сроки возможны в принципе (т.е. если вдевятером не нужно будет "родить" за месяц ©).
Так вот он говорил мне: Никогда не покупай топовых телефонов в момент их выхода на рынок! Если бы ты видел как мы пишем код к процесору… По принципу — лишь бы явно не глючило.
Потому что живой процессор всегда появляется позже установленных сроков и всегда отличается от эмулятора. А срок выхода топового телефона сдвинуть невозможно.
Приходится выбирать, какой софт вам нужен: написанный вовремя или качественный