Pull to refresh

Comments 30

А что значит вовремя? Когда какой-то лунатик, ничего не понимающий в разработке, выдумал из головы срок, а команда профессионалов не успела реализовать выдуманную тем же лунатиком функциональность, кто виноват?
Если я пойду к Маску и потребую отвезти меня на Марс к началу октября за 500 рублей, он меня на *** пошлёт и будет прав.
P.S. Читайте Роберта Мартина («Идеальный программист» — это действительно хорошая книга и там даже есть формула по которой сроки оценивать — PERT) и учитесь говорить «нет», «это невозможно» и никогда, никогда не говорите «я постараюсь» — это подразумевает, что обычно вы не стараетесь.
Если «команда профессионалов» добровольно согласилась на сроки, выдвинутые «лунатиком, ничего не понимающий в разработке», то какие-то они хреновые профессионалы
Я какраз таки говорю всегда «я потораюсь» или «я это никогда не делал, но постораюсь». Но никогда не говорю, что я это сделаю точно. А вот нет говорю только в точно местах, в которых я уверен. Даже не «нет» а «на сколько я знаю нет» или «по моему опыту это не возможно»

Но тут стоит сказать — я работаю в европейской международной компании
Лунатику нужен результат к сроку или лунатику нужно закупить оборудование и начать окупать вложения в разработку. Купит оборудование раньше завершения — потеря денег, завершится раньше — начнут окупаться позже. Программы ради программ нужны только программистам в вакууме.
Тут скорее думаю речь о типичном случае, когда менеджеру очень хочется урвать контракт (выслужиться, премию получить или даже из благих соображений — добыть денег для компании) и он пытается это сделать любой ценой — в частности демпингуя по срокам и цене, совершенно не думая о том, как команда потом будет это расхлебывать и реализовывать

Если часто говорить нет, то найдутся с другой команды, которые скажут "я попробую", потом трижды перенесут срок, и в конце концов сделают (и будут в своем поведении абсолютно правы).

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

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

У меня только одно обьяснение, что строительством человек занимается с начала времен, а программированием «всего» каких-то жалких 80 лет. Индустрия еще в зачаточной стадии.
> Я все время задаюсь вопросом, почему строительство зданий обычно проходит успешно, а с
> разработкой такие трудности.

У вас есть какие-то статистические данные на эту тему? Из моего, не реперезентативного, личного опыта — вы слишком идеализируете строительство.
Вы правы, это систематическая ошибка выжившего. Мы обращаем внимание только на те строительные проекты которые получились. О тех которые провалились мы никогда ничего не узнаем. А их конечно тоже должно быть не мало.
Почему же? Например в Washington DC есть монумент Вашингтона. Сроки срывались неоднократно. Так же было с собором Святой Софии. Да те же пирамиды случалось строились с опазданием к ключевому событию. Если более современное — то посмотрите ролики о строительстве в Китае городов-призраков. Особенно на тему балконов обваливающихся через полгода после постройки дома. Да банально… насколько часто граждане довольны ремонтом?!
Решил поинтересоваться , а что в строительстве является ключевыми факторами успеха:
На первых трех местах: организация проекта, компетентнось менеджера, и управление рисками.
И только четвертым идет компетентность исполняющей команды.
А характеристики проекта на последнем месте.

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

В области управления требованиями на первом месте по важности определение границ требований. Все как у нас.

Вообще запрос «critical success factors construction industry» оказалось выдает огромный пласт информации, т.е «они тоже ищут серебрянную пулю».
Все-таки в строительстве есть специфика. Там планирование значительно дешевле собственно изготовления. В разработке ПО не так — планирование сравнимо по стоимости с разработкой.
Современное строительство зданий (именно строительство, а не проектирование. современное строительство) — это процесс по уже проверенным и подготовленным документациям вплоть до разблюдовки сроков кто и когда будет что поставлять. То есть все точно знают что надо делать. А если например кто-то что-то не поставил во время — это просто передвижение сроков дальше.

А программирование это творческий процесс. Там в принципе невозможно сказать можно это сделать или нельзя. Например в API модет найтись баг в самом неожиданном месте и все. И чтоб его обойти надо писать дикие костыли так как апи наприемр закрытое.
Есть конечно простые случаи где все понятно, но боле менее сложные задачи это всегда очень рискованно.
Подумал о том же! Впрочем в строительстве тоже бывают внезапные баги.
Пример из жизни — ремонт частном в доме. После трудового дня бригада рабочих культурно отдыхает в одном крыле здания. В этот же момент, в другом крыле здания разрывает шланг подводки воды (конструктивный дефект стандартного изделия). Утром обнаруживается, что крыло залито водой, и количество требуемых работ внезапно выросло с соответствующими сдвигами сроков и стоимости.
А вот тут великие незавершенные стройки.
pastuh83.livejournal.com/230836.html
Не так все просто со стройкой, и не всегда чертежами готовыми обойдешься. Тут на хабре можно много про это почитать в топиках про BIM.

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

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

Стандартные способы уже вынесены в ос, фреймворки, библиотеки. Если нет явного NIH (а он на самом деле не так част, как кажется), то любая задача разработки явно содержит элемент нестандартности.


В разработке один программист ревьюит код другого и это считается нормой

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


а программированием «всего» каких-то жалких 80 лет. Индустрия еще в зачаточной стадии.

Когда будет решена последняя нестандартная задача — программирование исчезнет как вид деятельности. Вы же не называете программированием использование grep или использование (без написания кода) "визуальных" конструкторов сайтов?

Программирование — это не что-то сверхособенное до богоподобности и специфическое.
Любая проектная деятельность, любая разработка сталкивается с проблемами, затронутыми в статье. Не важно, разрабатываете вы ПО для социалочки с котиками, офисные небоскребы или АСУ ТП атомной станции, в любом случае будет проблема определения времени, необходимого на разработку, миллионы переделок и срыв заранее заданных сроков.
В любой проектной деятельности будет и элемент творчества, и использование ранее написанного кода типовых решений, и сотни итераций с полным переписыванием кода с нуля :), и отладка, и тестирование. И с помощью вливания дополнительных ассигнований не всегда удастся заставить родить 9 женщин ребенка-проект за 1 месяц.
С ПО даже проще, ну будут баги, но сдадим в срок, потом может быть подправим, выкатим через пару лет сервиспак, а пользователи потерпят. А вот после багов проектировщика-строителя людям потом жить в забагованном здании, и надеяться, что сервер домик не рухнет, если сильно хлопнуть дверью. Финансовые потери на переписывание кода и на снос здания несравнимы.
Типичная проблема времени при проектировании — заказчик говорит, вот такой проект нужен, вот такие объемы, срок? Заказчику говоришь — от полугода до года, основываясь на объемах. Заказчик в ответ — полугода нет, есть только месяц. И заказчик вынужден выбирать, получить халтурно сделанный проект, но быстро, или качественный поект, но со срывом сроков.
Еще одна проблема — оптимизация. С обычным ПО опять же просто — не работает, значит добавьте оперативки, пару ядер или вобще вычислительный кластер. Ибо рабочее время программиста дороже железа. Проектировщика, заявившего, что его рабочее время дороже десятка бетономешалок — просто выставят за дверь. Если необычный программист АСУ ТП неправильно выберет мощность контроллера на этпе подбора оборудования, а потом заявит начальству, что код немного разросся, давайте заказанное оборудование на складе похороним, а закажем вот такую штуку еще за пару миллионов $, у него даже с зарплаты не высчитаешь.
Есть большой проект автоматизации, клиент сам не знает до конца как оно должно быть. Есть этапы, на разных этапах происходят уточнение. Потому как есть софт более нижнего уровня, который так велик что даже разработчик (крупная международная корпорация ваяющая его более 20 лет) не знает точно можно ли сделать конкретную хотелку.

Строительство зданий, кстати, тоже происходит не совсем успешно. Затягивают сроки, раздувают бюджеты, недоделки, брак, несоответствие требованиям. Даже с типовыми решениями. А ещё они могут содержать дефекты by design и даже падать от этого. Оно для несталкивающихся выглядит идеально.

> Чем занимается программный архитектор?

Своим отсутствием? Даже в крупных проектах его может не быть (и это боль, и костыли, и боль от вставленных костылей).

> Индустрия еще в зачаточной стадии

Плюс все хотят быстро и дёшево. Вот и получается типо дачных домиков, построенных гостями из более солнечных стран — оно, конечно, похоже на дом, но зачастую только издалека (и чем ниже цена — тем более издалека).
Потому что в программировании каждый раз и есть в первый раз. Ты всегда пишешь то, что ещё никогда не существовало. Это как если бы человечество строило первое в истории здание, и тут просят оценить сроки. Ну в принципе можно оценить, ведь с кирпичами ты уже работал — на первый кирпич нужна минута, на второй ещё минута, значит на все 100 понадобится 100 минут. Но нет, оказывается зданию потребовалось железное укрепление, вот и сроки сорваны. Вам может это и очевидно, но тут человечество вообще первый раз в жизни здание строит. Нельзя всё учесть. А потом, кстати, ещё оказывается, что кирпичи чуть отличаются от тех, с которыми ты работал, и на них нужна не минута :( Тяжело что-то делать в первый раз :(

К примеру, строительство жилых многоэтажных домов в Украине почти никогда не завершается в срок...

Есть замечательная альтернатива концепциям "жесткие дедлайны" и "отсутствие эстимейтов": на основе эстимейтов и несоответствия реальности планам нужно убирать низкоприоритетные фичи тз бэклога.

Если бы строили по заданию как у программистов, то после того как построили лифт, то он должен был бы ходить еще и горизонтально, это-же круто! Двери бы для каждой квартиры были-бы разными, а потом вообще этажи должны были-бы меняться местами.
И даже не только это. Дом построили, так он так и будет стоять. Никому не придёт в голову его наращивать каждый месяц по этажу. Если на его месте понадобится небоскрёб, то старый дом просто снесут, и заново будут строить.
Готов поспорить. У меня дочь учится в школе. И там явно здание изначально было меньше раза в 3. Потом как минимум две пристройки было сделано, которые по площади больше изначального здания.
Также в историческом центре города полно многоквартирных домов 18 века, которые изначально имели печное отопление. Сейчас там газ, центральное отопление и все остальные ништяки цивилизации.
Частные дома вообще принято достраивать. Легко можно надстроить второй этаж, легко несколько пристроек.
Так у вас то разрешили делать пристройки рядом. А если бы пристройки надо было бы делать наверху (а у вас черепичная крыша)? А если бы посередине? Изначально проект не предполагал, что он будет развиваться, и такие пристройки будет сделать проблематично. Можно конечно сделать, но выглядеть будет так себе…

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

Вообще-то можно и одновременно… ибо есть еще и третий фактор (в этом треугольнике) — цена вопроса.
Конечно если сроки возможны в принципе (т.е. если вдевятером не нужно будет "родить" за месяц ©).

Эй, Алконостовцы, признавайтесь, что у вас есть некие инопланетные существа, которые пишут такие качественные переводы! Судя по рунету, человеки на такое не способны!
Спасибо за перевод, отправил эту статью руководству. Может поможет…
Угу, из параметров Цена, Качество, Скорость выберите любые два!
Есть у меня знакомый, совсем недавно работавший в одной из ведущих американских компаний-производителей мобильных процессоров. Потом надоело, ушел в одну из ведущих компаний по производству видеокарт.
Так вот он говорил мне: Никогда не покупай топовых телефонов в момент их выхода на рынок! Если бы ты видел как мы пишем код к процесору… По принципу — лишь бы явно не глючило.
Потому что живой процессор всегда появляется позже установленных сроков и всегда отличается от эмулятора. А срок выхода топового телефона сдвинуть невозможно.
Sign up to leave a comment.