Почему мы и дальше будем срывать сроки

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


        Литературы по управлению проектами написано много, но правильного ответа для того, самого животрепещущего, вопроса там нет. И скорее всего не будет. Я попытаюсь посвятить этот пост тому, чтобы максимально занудно описать причины печального положения людей, ищущих опоры и поддержки в своих попытках ответить на один из главнейших вопросов разработки ПО: сколько времени это займет?





    Постановка задачи

        Все в нашей цивилизации делается с какой-то целью, во всяком случае так принято считать, и уж во всяком случае любому, даже самому неразумному проекту, можно, постаравшись приписать какую-то цель. Все так и с программированием. Если вы занимаетесь программированием не только для себя, а также не пребываете в уютной вселенной опенсорса, то наверняка замечали вокруг себя людей, которые всеми правдами и неправдами пытаются получить от вас ответ, когда же наконец вы закончите. Кто-то говорит, что эти люди — заказчики, кто-то — тимлиды, некоторые даже говорят что это проект-менеджер. Говоря же прямо, кто этот человек и когда он задаст свой неудобный вопрос — не знает никто.
        Достоверно известно лишь одно — чем больше раз человек задает этот вопрос, тем большим негодованием преисполнен его голос, и тем большее давление он будет пытаться на вас оказать. Задача, казалось бы ясна, но специфика вопроса не дает на него ответить. Тут причины разнятся — и зависят от опыта отвечающего. Менее опытный склонен считать, что не знает ответа на этот вопрос. Человек же более опытный часто оказывается терзаем подозрениями, что не сможет дать такой ответ, который бы понравился вопрошающему, и поэтому в его душе происходит битва между ангелом искренности и демоном тактичности(впрочем, теологические роли могут различаться в зависимости от ситуации и целей отвечающего).
        Статистика показывает, что какой бы ответ не был дан, он оказывается либо неправильным, либо неприемлемым.



    Взгляд со стороны

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



    Два процесса

        В каждом производстве условно есть два этапа: разработка продукции и ее производство. Что такое разработка? Это затраты времени, в которые входит разработка дизайна, подбор сырья, элементной базы, создание производственных линий. Производство — это тот промежуток времени, отводимый на превращение чертежей и сырья в конечный продукт. Да простят меня диванные и дипломированные экономисты.
        Такая упрощенная модель в каком-то роде справедлива и для создания материальных продуктов и для написания программ. В идеальном мире. В реальном мире есть свои особенности. Оглянитесь вокруг — почти все предметы, окружающие вас — это продукт массового производства. Для компьютеров, холодильников, квартир, кошачьих лотков и велосипедов характерно многократное использование результатов этапа разработки. Т.е. по одному чертежу и налаженному тех-процессу выпускается огромное количество изделий, срок выпуска каждого из которых прописан и обоснован на этапе разработки. Вытачивание детали — детерминированный по времени процесс, сборка узла — тоже, и т.д. Суммируя все эти сроки можно получить точный срок выпуска конечного продукта(в рамках погрешностей). Достаточно просто не так ли? Простоты добавляет то, что люди понимают что, они выбирают из имеющихся моделей на рынке, и что если они хотят получить что-то отличное от стандартного изделия, то им необходимо найти специалиста, который мог бы изделие модифицировать или изготовить требуемое с нуля. С соответствующими затратами на проектирование и их работу.
        Культура потребления здесь присутствует, и все люди понимают разницу между массовым товаром и товаром сделанным на заказ. В том числе разницу в сроках поставки того и другого. И вообще, у людей складывается впечатление, что задачи нужно решать имеющимися средствами. И они их так и решают. Идиллия — не иначе.
        В случае программирования все переворачивается с ног на голову. Во-первых, фаза проектирования по сути никогда не заканчивается — как бы близко не был конец проекта, все равно нужно будет искать решения, что есть процесс творческий, а значит детерминизмом по времени тут и не пахнет. Выстроить предельно точную модель даже интернет-магазина и держать ее в голове ни одному человеку не под силу. Приходится постоянно додумывать детали. И никакие спецификации тут не подспорье — они лишь говорят что нужно сделать, но — не как. На вопрос «как» может дать ответ чертеж, но, по иронии, в случае ПО он — и есть готовая программа.
        Во-вторых, необходимость постоянного принятия решений складывается из-за того, что клиент в большинстве случаев подразумевает разработку на заказ, т.е. даже имея готовые модули и наработки не всегда возможно просто взять и собрать их воедино — изменения почти неизбежны. А где есть изменения, почти всегда есть регрессии, что означает опять таки потерю времени.
        В-третьих, обычно программы не могут(на момент января 2013) разрабатываться конвейерным способом — программисты не могут быть так же незаметно заменены, как рабочие на заводе. Нет, правда не могут! В небольшой команде потеря времени от смены или ухода разработчика будет очевидна. В огромной компании, где программистов десятки и сотни, может возникнуть иллюзия того, что сотрудника можно незаметно заменить. Внешне незаметно — можно, но потеря времени неизбежна, поскольку любой новый программист не сможет сразу въехать в процесс разработки и должен будет исследовать уже имеющийся код предшественника, что снова приводит нас к потерям времени. Изменения же в командном составе программистов есть явление закономерное.
        Копирование программы — аналог стадии производства в материальном мире на практике абсолютно не значимо для получения продукта. Все силы уходят в стадию разработки, гораздо более трудоемкую, а главное — плохо предсказуемую.


    Спекуляция временем

        Практически все заказчики не хотят работать с не детерминированной моделью поставок, и у них нет понимания того, что программный продукт, который они хотят получить не производится, а придумывается на ходу. А мыслительный процесс нормируется плохо. Но гарантий и определенности хочется все равно. Плохо также то, что большинство заказчиков не могут и не хотят понять этого. И объяснить это тяжело — вы бы сами поверили доводам одного человека о том, что ответа нет, когда рядом стоит еще 10 человек, которые этот ответ готовы дать?
        Спекуляция на угадывании срока уже давно и прочно закрепилась как инструмент конкуренции, а сам срок уже перестал что-то значить. Какой смысл определять то, что в принципе невозможно определить? Какой смысл говорить правду человеку, который ее не хочет слышать? Масла в огонь подливает еще и то, что для некоторых проектов, срок определить все же реально, в результате чего клиент, глядя на то, как ему быстро и четко настроили 1С или сделали промо-сайт, начинает думать, что подобный механизм оценки сроков будет работать и для других проектов…


    Триумф пунктуальности

        Дойдя до этого места, определенный круг читателей возможно станет подозревать автора в низкой компетенции, которую он пытается оправдать путем выставления задачи определения сроков проекта в нерешаемом свете. Вовсе нет! Я никоим образом не отрицаю того, что определить срок сдачи проекта возможно. Но давайте будем честны с собой.
        Много ли программирования в создании однотипных сайтов-визиток/интернет-магазинов/андройд-клиентов? В случае отлаженного тех-процесса, где различия между проектами минимальны, сроки будут точны. При этом упускается из внимания то, что вся фаза проектирования уже фактически выполнена. Даже некоторые программисты ведутся на эту ситуацию, оставляя у себя в голове твердую уверенность в том, что во всех программных проектах оценка сроков — вещь реальная.
        Занимает ли ваш проект больше месяца-двух? Обычно на таких сроках ошибка не очень велика, проект небольшой и погрешности при измерениях времени такие же. Однако они есть — если вы закончили проект за полтора месяца вместо месяца или двух, то вы серьезно ошиблись. Ваш прогнозируемый срок не совпал с реальным — а что будет если экстраполировать его на проекты больше длительности?
        Если вы все же считаете, что определение точное сроков возможно, то либо вы гений, либо вам следует в порядке эксперимента сменить предметную область программирования, чтобы проверить, будут ли ваши прогнозы сбываться с той же точностью как и на текущем поле деятельности.


    Что делать?

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

    Similar posts

    Ads
    AdBlock has stolen the banner, but banners are not teeth — they will be back

    More

    Comments 45

      +6
      Как то уж у вас совсем все печально получается. Оценку затрат времени на проект вполне можно сделать с достаточной точностью, для этого нужен Опыт и затраты времени на оценку затрат времени :-) Причем чем больше вы потратите времени на оценку тем точнее она будет. В особо тяжелых случаях затраты времени на оценку и будут затратами времени на сам проект :-) Но это бывает редко.
      А если серьезно, то я где-то уже писал, что например у меня за много лет опытным путем выработалась зависимость 1 к 6. Т.е. чтобы дать точную оценку мне надо потратить на нее примерно1/6 часть времени от самой работы. Только тогда я могу достаточно точно представить и расписать что будет делаться в процессе работы и возможно навести необходимые справки и получить консультации. Таким образом, если я трачу на оценку например три рабочих дня, то сама работа займет примерно 6*3 = 18 дней. Если же кто-то подумав пару минут говорит мне что что-то займет у него два дня — я ему не верю, ну нельзя за две минуты представить чем ты будешь заниматься следующие 16 часов.
      И еще я никогда не стесняюсь спросить заказчика о его лимитах по времени/средствам, вменяемый человек всегда дает такую информацию. Таким образом я еще на этапе проектирования опираясь на свою формулу могу увидеть что я не вписываюсь в бюджет/сроки, например если говорят что все надо сделать за 30 рабочих дней, а в конце пятого дня еще не продумал все, то скорее всего эту работу мне сделать за такой срок не удастся и уже в этот момент надо либо отказываться от нее либо уточнять сроки.
      Многие скажут что это неэффективно — тратить столько времени на оценку/подготовку. Более того я скажу что зачастую это время даже не оплачивается. Но я беру за свою работу достаточную для меня плату чтобы скомпенсировать эти потери. А вот доход от экономии нервов/здоровья на авралах или от репутации отвечающего за свои слова человека я вообще не берусь считать.
        0
        Если Ваш проект будет рассчитан на несколько лет, Вы будете пол года определять сроки?
          +2
          Я работал в компании, которая продавала заказчикам здоровенную систему (несколько миллионов строк кода), а затем регулярно делала новые версии, внося изменения по требованиям заказчика. Цикл сбор требований — их обсуждение — проектирование изменений — собственно из программирование — тестирование занимал год и при этом сроки чётко соблюдались. Да, waterfall. И, в пику рассуждениям автора, программисты там могли быть заменены почти безболезненно, потери времени минимальные благодаря чётко поставленному процессу и наличию большого количества программистов, работающих на соседнем похожем проекте.

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


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

            С другой стороны, если бы вы могли объяснить как именно четко поставленный процесс может спасти от того факта, что новому, даже самому хорошему программисту, требуется «въехать» в код, то я бы и изменил свою точку зрения. При этом сразу должен заметить, что вики, документация, наличие рядом гуру — это не панацея, это лишь способ уменьшить неизбежные траты времени.
              0
              Вам неправильно кажется. В крупных интеграторах такое нередко бывает. Или в компаниях, которые продают крупный, но не совсем коробочный продукт типа CRM. На нижнем звене программисты заменяются легко благодаря чёткому ТЗ, мощной платформы, методологии и детально описанных документов с дизайном изменений.

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

              Да, программирование в таких конторах — это скорее ремесло, чем искусство.
                +1
                Понимаю, но ваши примеры — это совершенно не то, что описывалось в статье. Естественно, если задача состоит лишь в выпуске апдейтов и смене дизайнов, то вопрос об оценке сроков не стоит. Можете подробнее описать что за интеграторы и что за продукты? И в чем реально заключалась работа легкозаменяемых программистов?
                  0
                  Вы, видимо, не поняли, что я имел в виду. Смысл статьи, каким увидел его я: «мы не можем поставлять готовый продукт в срок, потому что не знаем точно, что именно надо заказчику, и не знаем, как мы это будем делать, и не умеем делать из разработки конвеер». Я привёл пример компании, где конвеер успешно сделали )

                  Выпуск новой версии = несколько десятков человекомесяцев разработки. И не «смена дизайнов», дизайн изменений — это такой документ, где написано, где и какие именно изменения надо вносить для того, чтобы реализовать новый функционал, который хочет заказчик. На каждый более-менее независимый кусок изменений, запланированный на разрабатываемую версию, делается отдельный такой дизайн. Работа программистов, как это ни странно, заключалась в программировании :) Они внимательно читали дизайны изменений и эти самые изменения вносили.
                    0
                    На готовом проекте это вполне реально, согласен.
                    Чем старше проект, тем точнее можно прогнозировать временные затраты.
                    Однако на старте этого, как правило, нельзя сделать, т.к. нет базиса, на основании которого можно давать оценки. Более-менее точные оценки могут появиться после детальной проработки use case'ов (особенно UI) и архитектуры приложения в целом. А могут и не появиться — вопрос, реально ли это нужно, т.к. оценка задачи масштаба проекта занимает существенное время.
            0
            В той сфере вебдева где я работаю таких проектов не бывает. Ну или точнее так — проект может жить и несколько лет, но до его запуска обычно проходит не больше полугода.
            Но если бы мне предложили такой проект — то таки да, я потратил бы примерно столько времени на оценку и предварительное планирование, но с учетом длительности делал бы это конечно не бесплатно.
              0
              А вы можете представить заказчика который готов оплатить пол человеко/года только чтобы получить цифру (времени и дерег) за которые он получит продукт? Вы можете представить заказчика который будет ждать пол года чтобы получить эту цифру? Да даже если не пол года а месяц. Если же он не оплачивает и готов ждать, готовы ли вы потерять стоимоить этого месяца (вы или компания, без разницы) ради проекта который не факт что вы получите?

              Я обычно поступаю так для крупных проектов которые не факт что еще получу: первый этап — предварительная оценка, погрешность в районе 50%, чисто чтобы заказчик приблизительно оценил объем сумм и времени. Временные затраты 2-4 часа (для проектов в 3-6 человеко-месяцев), иногда до 8 часов (большая часть времени тратится на получение информации). Если предварительное согласие с оценкой получено, проект разбивается на задачи/этапы и дается уже детализированная оценка которая и есть реальная и пишется в договор. Оценить со 100% точностью конечно невозможно, но это и не нужно, 15-20% погрешности меня вполне устраивает и я готов отнести их к рискам, это лучше чем потратить то же время на более точную оценку (которая все равно не будет выше 90% если это не hello world). Если же его предварительная оценка не устраивает, то либо мы вместе думаем как ее уменьшить за счет упрощения функционала, либо этот проект получает кто-то другой. Итого потери максимум день, а заказчик в состоянии максимально быстро узнать подойдут ли мои услуги ему или нет.
                0
                Пффф, да сколько угодно. У того же Вымпелкома с несколько десятков систем, на обсуждение каждой новой версии которой они тратят сильно больше, чем пол человеко/года. Как и у практически любой крупной компании. И почему-то у их исполнителей очень часто получается соблюдать сроки. Вы сейчас мыслите в масштабах фрилансера-одиночки, мир вокруг сильно больше и разнообразнее.
                  0
                  на обсуждение или оценку? пол года на обсуждение не так уж много для уже существующего и развивающегося крупного проекта. а вот пол года на оценку по уже готовому тз (ну назовем так этот пакет документов), это мне сложно представить, что для фрилансера одиночки :-), что для крупной компании. неужто они согласны отсрочить начало работ на полгода чтобы потом попасть в сроки, вместо того чтобы заложить эти пол года в риски.
                    0
                    Допустим, компания делает для заказчика новую версию продукта каждые 6 месяцев. За 6 месяцев до начала разработки компания-заказчик начинает обсуждать с компанией-исполнителем, что они хотели бы видеть в новой версии, что именно исполнитель может успеть сделать в этой версии, как можно изменить требования для того, чтобы успели сделать законченную часть требований и т.д. Т.к. разговор в том числе и о деньгах — то в процессе этих переговоров регулярно оцениваются сроки для каждого из требований, суммарно набегает довольно большая цифра затраченного времени. Делается предварительная оценка — прикидываются деньги — изменяется изначальное требование, цикл повторяется иногда несколько раз, затем финализируется ТЗ и даётся окончательная оценка в деньгах = времени, т.к. оплата по человеко-месяцам.

                    Дать сразу готовый большой ТЗ и подождать пол года — это вариант с новым большим проектом, на который объявляют тендер. Там правда много человеко-лет на оценку будет потрачено :) Но для заказчика главное, чтобы потом не в сроки попали (хотя и это важно), а в деньги.
                      0
                      это все понятно, но за эти 6 месяцев даются предварительные оценки, очень грубые, и более детальные и уже точные для каждого блока функциональности. это нормальный процесс уточнения функционала и оценки. но эта ветка началась с того сто AlexTest рассказал про свой подход, по которому он тратит 1/6 часть времени на оценку, а если меньше то это не оценка. при этом, как я понял, ему нужно продумать все до мелочей, фактически иметь детальную архитектуру в мыслях или на бумаге и план выполнения. для этого нужно уже полностью готовое и зафиксированное описание функционала а уже потом оценка. если я неверно понял, AlexTest, поправьте пожалуйста. и я пытался объяснить, что такой подход не масштабируется на проекты в годы, или даже в пол года. большинство заказчиков хочет знать сколько это будет стоить, хотя бы приблизительно, заранее, с минимальными затратами на оценку, даже если это продолжающийся проект а не поиск исполнителя.

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

                      у оценки много задач, и успевание в срок, имхо, далеко не главная, срывы сроков обычно по другим причинам возникают.
                        0
                        В некоторых случаях срок также будут критичными.
                        Например, проект должен быть выпущен к какому-то событию.
                +1
                В случае проекта на несколько лет срок можно будет определить в лучшем случае за полгода до завершения проекта — когда станет понятно, что действительно всё уже предусмотрено, реализуемая архитектура удовлетворяет всем нужным требованиям, и главное, все необходимые алгоритмы и эвристики уже определены, разработаны и испытаны — осталось только состыковать всё вместе.
                  0
                  Не думаю, что процесс сможет масштабироваться таким образом, придется разбивать на более мелкие шаги. В любом случае, никто не застрахован от ситуаций вроде «уткнулись в ограничения существующей технологии и придется переписывать на другом языке/стеке/СУБД», опыт только снижает шансы такой ситуации, но не более того.
                    0
                    А может ли быть «опыт» для проекта длиной в несколько лет? Вряд ли найдётся много фирм, которые за время своего существования делают несколько таких похожих проектов. Тем более, что за каждые очередные несколько лет мир техники сильно меняется.
                      0
                      Я и говорю о невозможности масштабирования. В любом случае, изнутри любой большой проект состоит из множества маленьких, которыми зачастую занимаются разные люди, а то и отдаются подрядчикам.
                        0
                        А в какой момент подтверждается адекватность этого разбиения большого проекта на маленькие? И то, что стержневая архитектура (если она есть) способна поддержать все маленькие проекты?
                          0
                          Каким образом это относится к моим комментариям?
                            0
                            В них присутствует фраза «разбивать на более мелкие шаги». Я пытаюсь понять, возможно ли это. Потому что у меня очередное изменение понимания общего алгоритма проекта (обычно это деталь, которая вначале казалась несложной, но когда дело дошло до реализации — оказалась на уровне задач искусственного интеллекта), как правило, перетряхивает всю основную структуру разбиения (включая области ответственности отдельных частей).
                              0
                              Если над проектом работает более одного человека, его разбиение, очевидно, неизбежно.
                                0
                                Ваш случай очень похож на
                                никто не застрахован от ситуаций вроде «уткнулись в ограничения существующей технологии и придется переписывать на другом языке/стеке/СУБД», опыт только снижает шансы такой ситуации, но не более того.
                                из моего комментария выше. Ну и возможно, сказалось отсутствие определенного опыта, если уж гадать по фотографии.
                    +5
                    Оценку затрат времени на проект вполне можно сделать с достаточной точностью, для этого нужен Опыт и затраты времени на оценку затрат времени :-)


                    Я не автор статьи, но время тоже рассчитывать приходится. К сожалению, вынужден заметить что проект проекту рознь. Как и написал автор, все упирается в простейший критерий — «делали ли мы точно такую же работу или очень похожую до этого». Если вы сделали уже 20 тем для платформы «magento» и к вам приходит заказчик делать 21-ю, то вы в целом прекрасно знаете что займет сколько времени и можете относительно точно назвать срок. Если вчера вышла платформа blackberry 10 и к вам приходит заказчик портировать на нее angry birds — то сроки можно назвать в первом приближении. Потому как даже если вы досконально знаете исходники игры, а авторы BB10 клянутся что у них стандартный C++, :POSIX и OpenGL — никто не гарантирует, что это все не будет иметь багов или «особенностей» которые приведут к тому, что придется тратить сотни человекочасов на собственную реализацию жестов или менеджера памяти.

                    Плюс у нас в отрасли исторически очень много уровней абстракции, из-за чего велик фактор Нёх, которая может вылезти на пустом месте и просто так. Например, у заказчика последняя версия «magento» а там взяли и сменили шаблонизатор для тем. На новый, эксприментальный. У которого баги, не работает геометри менеджер а стандартная тема реализована через патчи кода. А заказчик не понимает, почему предыдущие темы делались за 5 дней, а на этой срыв сроков. И про шаблонизатор ему не объяснить, потому что для заказчика компьютер — это такой телевизор с одноклассниками :)
                    +3
                    Уже давно в литературе приводятся две отрасли человеческой деятельности, с которой сравнивается процесс разработки программного решения.

                    Заказчик строит аналогию с проектированием и строительством здания: шаг за шагом, котлован по чертежу, фундамент в котлован, камень за камнем и так до сдачи объекта комиссии — Классический WaterFall.

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

                    Известно, что в Советском Союзе назначение ответственным за сельское хозяйство было равносильно политической и управленческой смерти назначенца: было немыслимо, что в стране, где ВПК штампует ракеты как сосиски, могут не вызреть помидоры в Московской Области…

                    Но разве эти справедливые доводы отрицают успешность работы Североамериканских Фермеров? Они-то как-то работают. (Правда, может у них там есть субсидии от государства, я не знаю)
                      0
                      Зачем же так категорично? «Срывать сроки»!

                      Давайте по-другому научимся:

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

                        Объяснять ему, что вы сказали предлог «от» — значит портить отношения с заказчиком.
                          0
                          А для этого люди изобрели договора и электронную почту, где написано будет не ИКС, а «от ИКС».

                          Хотя это всё конечно сами знаете :)
                            0
                            Тыкать клиенту в формальности это последнее дело, к которому стоит прибегать. Меня бы это в бешенство привело, думаю 90% людей тоже.

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

                            Второй — метод прогрессивного джпега, но он применим далеко не ко всем проектам.
                              +2
                              Ээ… Если я в случае восклицания «Епа, а тыж говорил, что будет готово за ИКС времени!», возражу, что я не утверждал, а давал оценку — это формальность что ли?

                              Что значит просрочка — норма? Мож тогда сразу и говорить: «Мы думаем, что будет за ИКС времени, но ты не парься — все равно будет просрочка и это норма» :))

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

                                А если прийти к клиенту в день, когда нужно сдавать работу и сказать «дорогой, я оценивал месяц назад проект от X дней, то сейчас я начал кодить и на эту работу нужно 2*Х дней» это значит проявить себя некомпетентным. Нормальный клиент сразу на дверь в таком случае покажет или как минимум расскажет о вас много нового и задаст много интересных вопросов. И будет прав.
                                  –1
                                  Ж) вот это больше нравится — регулярно тык скыть быть вконтакте (с)
                                +1
                                Хм… а по-моему, договор это один из важных моментов. Почему, к примеру, я должен чувствовать себя виноватым, если я совершенно официально в договоре указал, что срок будет составлять 1-1,5 месяца, но заказчик чего-то там не дочитал, недопонял, недослышал и приходит через месяц требовать результат?

                                А если цена в договоре будет 10*X, а заказчик потом, не прочитав договор, будет говорить, что слышал X? Я думаю, тут уже «тыкать в формальности» вы не посчитаете за последнее дело. А время это такой же ваш ценный ресурс, как и деньги.
                                +2
                                А в графе «оплата» — «до Y денег» )
                                  0
                                  В графе оплата «почасовая оплата работы специалистов, стоимость одного нормочаса составляет 2000 рублей» или что-то подобное.
                                    +1
                                    Осталось найти идиота, который подпишет договор без ограничения стоимости.
                                      0
                                      Такая схема у нас работала для небольших клиентов(часов до 80-90). Подписывался рамочный договор в котором указывались необходимые услуги и стоимость часа работы. Необходимое время сообщалось приблизительно ± 20-30%. Закрывалось все поэтапно, через каждые несколько дней специалист расписывал лист учета рабочего времени с указанием выполненных работ и затраченного времени.
                                        0
                                        ± — это все-таки не «от...»
                                          0
                                          А вообще любопытно, почему тогда просто не указать общую стоимость (приблизительно часов) * стоимость часа * 130%? Так ли уж вашим клиентам важно, сколько на самом деле затрачено часов (которые они не контролируют)? Или им интересно сыграть в игру «мне (не)повезло и проект обошелся на 20%-30% дороже/дешевле»?
                                            0
                                            Частично это упрощало работу с клиентами у которых то, что они хотят и то, что говорят сильно различаются или у которых требования могут меняться на ходу.
                              0
                              >>Масла в огонь подливает еще и то, что для некоторых проектов, срок определить все же реально, в результате чего клиент, глядя на то, как ему быстро и четко настроили 1С или сделали промо-сайт, начинает думать, что подобный механизм оценки сроков будет работать и для других проектов…

                              Вы слишком хорошего мнения про 1С))

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

                                Как тут не вспомнить закон Брукса — гласящий, что добавление в программный проект новых людей еще больше оттягивает срок его реализации?
                                  0
                                  Добавление людей при приближении к концу разработки — да.
                                  А вот чем больше людей взять в начале пути… тут уже вопрос некого оптимального числа.
                                  По-моему оптимальное число будет тем что, что и минимальное количество цветов на закраску графа, чтобы никакие две соседние вершины не были закрашены одним и тем же цветом. Вершины — это части функционала, связи между ними — зависимости. Чем лучше продумана архитектура, тем точнее можно определить, какое число людей будет оптимальным.
                                    0
                                    P.S. Не совсем задача про раскраску, т.к. в реальной жизни есть еще фактор перераспределения ресурсов — сегодня три человека. завтра пять, в конце вообще один.

                                Only users with full accounts can post comments. Log in, please.