«Этот сайт довольно прост. Всё, что вам нужно сделать, — это выполнить X, Y, Z. Похоже, вы очень хорошо разбираетесь в технике, так что, полагаю, вам не потребуется много времени, чтобы его создать.»
Я время от времени получаю такие письма. Почти все, кто их пишет, либо не имеют отношения к технологиям, либо работают над своим первым продуктом. Сначала, когда я слышал подобные высказывания, я всегда очень раздражался. Кто они такие, чтобы спорить о том, сколько времени занимает разработка программного обеспечения? Но позже я понял, что даже я сам теряюсь, когда пытаюсь предсказать, сколько времени займут мои собственные проекты. Если я сам не могу этого сделать, почему я должен раздражаться на тех людей?
Что меня действительно удручает, так это не ошибка в их оценках. Проблема в том, что они на самом деле верят, будто могут сделать правильную оценку. Как разработчики, мы часто обнаруживаем, что когда речь заходит о разработке программного обеспечения, посторонний естественным образом оценивает сложные вещи как очень простые.
Это не оправдание для нашего гнева. Но это поднимает другой интересный вопрос: почему наша врождённая способность предсказывать сложность даёт сбой, когда речь заходит о проблемах программирования?
Чтобы ответить на этот вопрос, давайте посмотрим, как наш мозг оценивает вещи. Некоторые вещи легко правильно оценить даже неопытному человеку, а другие — нет.
Давайте представим, что мы смотрим, как кто-то играет на гитаре. Даже если вы никогда не играли на гитаре, после просмотра исполнения на гитаре «У Мэри был ягнёнок» вы можете примерно понять, что оно простое и что для его исполнения человеку не нужны очень продвинутые навыки. Точно так же, посмотрев, как кто-то играет «Канон Пахельбеля в ре мажоре», вы легко поймёте, что это сложное произведение и для его исполнения требуется долгая практика.
Почему мы можем быстро и точно оценить сложность этих двух произведений? Это связано с методами, которые мы используем, чтобы судить, просто что-то или сложно. У нашего мозга есть готовые шаблоны для выполнения таких задач, и первый основан на скорости. В этом случае мозг определяет, сколько играется за секунду. Исходя из того, сколько играется за секунду, мы можем легко составить интуитивное суждение о сложности произведения. Поскольку исполнение песни на гитаре — это физический процесс, сенсорная деятельность, наш мозг может легко вывести из этого скорость, а затем преобразовать её в сложность.
У нас также есть другая врождённая основа для оценки: объём. Подумайте о сравнении палатки с многоквартирным домом. Даже если человек никогда не изучал архитектуру, он может сказать вам, что спроектировать и построить палатку обычно проще, чем спроектировать и построить многоквартирный дом. Почему? Потому что мы врождённо используем физический объём как показатель сложности вещи.
Конечно, эти два вида логического анализа не всегда эффективны на 100%. Но в большинстве случаев люди поступают именно так и добиваются большого успеха. В большинстве ситуаций, когда мы оцениваем физические процессы, наш мозг эффективно связывает их с физическими объектами, не нуждаясь в опоре на предыдущий опыт.
Теперь поговорим о программном обеспечении. Когда человек без технической подготовки пытается оценить время разработки программного обеспечения, ему помогают два очень базовых интуитивных показателя: сложность, измеряемая объёмом, и сложность, измеряемая скоростью. Но он не осознаёт, что программное обеспечение не такое, каким он его себе представляет. Программное обеспечение по сути не является осязаемой субстанцией. У него нет ни объёма, ни скорости. Его крошечные компоненты могут время от времени мелькать на экране компьютера. Из-за этого, когда речь заходит о разработке веб-приложения (или любого другого типа программного обеспечения), наши базовые интуитивные чувства отказывают.
Первый пункт — скорость — очевидно, совершенно невозможно использовать постороннему человеку для оценки программного обеспечения. Поэтому естественно, что для оценки он склонен использовать показатель объёма. Либо на основе количества страниц в документе со спецификацией, либо на основе количества вариантов использования или функций программного обеспечения.
Иногда этот метод оценки действительно работает! Когда речь идёт о статическом сайте без особых требований к дизайну, посторонний человек может легко оценить таким образом время разработки. Но обычно для разработки программного обеспечения объём не может по-настоящему и эффективно отражать сложность.
К сожалению, единственный эффективный способ оценить сложность программного обеспечения — основываться на опыте. И даже он не всегда хорошо работает. Как программист, я знаю, что, исходя из похожих функций, которые я разрабатывал раньше, я могу оценить, сколько времени займёт разработка каждой из текущих функций. Затем я складываю общее время, и это даёт мне приблизительную оценку того, сколько времени займёт весь проект. Однако в реальности каждый проект сталкивается с двумя-тремя узкими местами во время разработки. Эти узкие места могут безрассудно поглощать у программиста массу времени, и вы не можете предвидеть их, пока не столкнётесь с ними. Они могут затормозить весь проект, задержав его на недели или даже месяцы.
Это вещи, которые неопытные люди не поймут при оценке сложности. Они не понимают, почему методы, которые хорошо работают для других вещей, не работают при применении к разработке программного обеспечения. Поэтому в следующий раз, когда вы услышите, как кто-то говорит: «Я думаю, вы сможете разработать это за несколько дней», — неважно, кто это говорит, не раздражайтесь. Сделайте глубокий вдох, покажите им адрес этой статьи и возвращайтесь к тому, чем занимались.
[Оригинальный английский текст:Я уверен, что написание кода займёт у вас всего несколько дней ]