Я уже 11 лет работаю в IT и создаю веб-сервисы, помогаю делать стартапы, маркетплейсы и мобильные приложения.

И за эти 11 лет я не могу вспомнить случая, когда заказчик попросил бы оценку на большой проект (большой в моем понимании это больше 2000 часов) и программисты попали бы в эту оценку.

И, кстати, это не потому что программисты тупые или у них мало опыта. Причины абсолютно в другом. Их несколько.

Уровень

Я примерно месяц назад сам для себя написал совсем небольшой скрипт. У меня не было времени и нужно было как можно быстрее его написать. За час написал, все работает. Отлично.

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

Там не было документации, переменные и функции были названы как попало. Хаос полнейший. И я потом потратил еще кучу времени, чтобы переписать все нормально. Чтобы был чистый и красивый код. Я написал нормальную документацию к этому скрипту. Я его доработал, например, добавил поведение в случае ошибки.

Один и тот же код. Делает он тоже самое. Но на его написание можно потратить один час и пять часов. И вот представьте, что программист пишет вам такой скрипт.

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

А по факту окажется, что все наоборот. Просто одна из компаний не может допустить для себя делать проект "на отвали".

У меня еще была ситуация, когда я пользовался одним Open Source редактором. И я хотел добавить небольшие изменения в код. Я сделал изменения и решил послать их сообществу. Потратил я на это около часа.

Мои изменения не приняли и сказали, что мой код не соответствует стандартам. Дали ссылку на стандарты. Я потратил время на то, чтобы прочитать о стандартах, а потом еще на переписывание кода.

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

Понимаете? Я сделал что-то за час и оно работало. Но чтобы этим могли пользоваться и остальные люди, нужно потратить в 5 раз больше времени.

Вот такие вещи клиенты вообще не понимают.

Им нужны различные аналогии чтобы объяснить это.

Ну, например, ты приходишь к плотнику. И говоришь, что тебе нужна штука, на которую ты мог бы ставить кастрюлю.

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

А неопытный слышит только требования. Штука для того чтобы ставить на нее кастрюлю? Ну ладно, давайте возьмем, например, две стопки из 10 кирпичей, поставим их. А на них положим кусок фанеры. Все. Готово. Если мы поставим кирпичи и фанеру на них, то кастрюля сможет стоять. Все желания заказчика технически соблюдены.

И стоит это намного дешевле. Тысяча рублей, а не пять тысяч рублей.

И заказчик первоначально может посмотреть и сказать, что да. Кастрюля стоит. Как я и хотел.

Но потом вдруг выяснится, что если поставить сильно тяжелую кастрюлю, то фанера ломается. И нужна новая фанера. А если ногой задеть эту конструкцию, то она разрушается. И очень тяжело переносить ее с места на место.

Заказчик пишет другому программисту. И говорит: "Слушай, у меня тут есть проект. Мне нужно его немного доделать. Я вот часто переношу мой проект и мне нужно чтобы его было удобно переносить"

Программист отвечает: "Слушайте, да это же говно, а не проект. Вам просто нужен стол за пять тысяч"

Заказчик, естественно отвечает, что вроде все нормально и все работает и ему только надо сделать чтобы удобно было переносить.

Программист берет скотч и сматывает кирпичи вместе.

За это еще тысяча рублей.

Потом еще две тысячи за доску вместо фанеры. Так как она всегда ломается когда ставишь полную кастрюлю.

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

Еще раз. Цена на проект не коррелирует с уровнем программистов, которые давали цену. Они могу сделать все очень плохо.

Когда делаете проект у вас должны быть стандарты по которому пишется код. Все должны понимать эти стандарты. И должна быть база знаний и документация. И когда кто-то сталкивается с проблемой, она не должна просто решаться. Решение должно записываться в базу знаний.

Очень часто я вижу ситуации, когда у проекта/стартапа есть технический директор. И этот технический директор знает все про свой проект.

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

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

Короче говоря, чтобы закончить уже с первым пунктом. Условный проект можно сделать как за 200 часов так и за 1000 часов. Работать будет он одинаково. Только первый будет написал через одно место. Никто не поймет как оно работает, его невозможно будет масштабировать и не будет никакой документации.

А со вторым все будет отлично.

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

Заблуждение планирования

У Канемана есть очень популярная книга, которая называется на русском "Думай медленно, решай быстро" книга очень интересная, я советую прочитать.

Она есть на букмейте или на Озоне. Советую почитать.

И там он рассказывает о таком когнитивном искажении, которое называется "Заблуждение планирования". Когнитивное искажение это такая штука, когда наш мозг систематически ошибается и интерпретирует информацию неправильно. И вот несколько примеров из книги:

Аэропорт Денвера открылся на 16 месяцев позже запланированного, и эта задержка стоила $2 млрд.

Совместный оборонный проект нескольких европейских стран “Тайфун”, был закончен через 4.5 года после дедлайна, стоимость была $19 млрд вместо $7 млрд.

Сиднейский Оперный Театр изначально оценивался в $7 млн, а обошелся в $102 млн. И построился на 6 лет позже.

Здание парламента Шотландии оценивали в 40 млн фунтов, оценка эта менялась несколько раз, причем два раза даже законодатели устанавливали предел. Сначала 195 млн, а позже 241 млн. Но как оказалось, даже английские законы не спасают. В итоге затраты составили 431 млн. В 10 раз больше запланированных.

В 2002 еще проводили интересный опрос, в котором опрашивали людей, которые перепланировали свои кухни. Хозяева предполагали потратить на ремонт в среднем 18.658 долларов, а тратили в среднем 38.769.

Эта штука называется “заблуждение планирования”. Это такое когнитивное искажение, это значит, что люди всегда допускают эту ошибку, даже зная о ней.

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

Так что, если вы делаете проект, то просто знайте, что его в любом случае сделают позже, чем обещают.

Инструменты

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

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

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

А вот мобильных приложений еще каких-то 15 лет назад не было вообще.

И так вот со всем. Меняются фреймворки, меняются языки. Появляются все новые и новые штуковины. У меня такое ощущение, что айти сфера она развивается быстрее остальных.

Ну представьте, что если бы так же за 15 лет развивалась сфера строительства. Вот, бредовый пример но все же.

В 2001 году мы с вами живем в шалашах.

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

В 2008 уже никто не роет землю. Все строят деревянные избы. Мастера по дереву на вес золота, а землекопы никому не нужны. Нужно полностью переучиваться.

В 2012 уже никто не строит дома из дерева. Появился кирпич, появились другие технологии, другие стройматериалы.

В 2015 кирпич уже не рентабелен. Ведь с ним довольно толстые стены, да и вообще не построишь дома больше 10 этажей.

Вот, если бы в сфере строительства было бы настолько же экстенсивное развитие, то было бы похоже.

Вывод

Если вы агентство или программист

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

Вы даете такую оценку только потому что заказчик говорит: "Ну я был у компании Студия Василия Синичкина и мне сказали что они сделают это за пол миллиона". А у вас это сколько стоит?

И вы сидите, считаете, и даете оценку такую же или чуть ниже. И делаете проект на отвали.

Мне кажется, что рынок нужно менять. И объяснить людям что они получат. И почему это не стоит 500 тысяч.

Если вы хотите делать свой стартап

Если вы хотите сделать свой продукт, то знайте, что оценить его невозможно.

А если кто-то и дает вам точную оценку. То он врет. И он скорее всего знает, что он врет. Ну, а если он не знает, что он врет, то он неопытен.

Ищите компанию которая уже делала продукт, который по функционалу похож на ваш продукт. Компанию, у которой есть успешные продукты. Компанию, которая дорожит своей репутацией. Смотрите отзывы.

Смотрите на то, хочет ли компания работать с вами изо всех сил и на любых условиях. Если хочет, то, наверное, у компании проблемы. У нее мало клиентов. И подумайте, нужно ли вам работать с такой компанией.

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

Удачи вам с вашим стартапом.