Сейчас, после где-то 9 месяцев (с перерывами) с начала разработки продукта, уже таки набил достаточно шишек, чтобы более взвешено взглянуть на выпуск продукта.

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

Просто напишу пункты из той статьи, к которым комментарий относится

>6) Идея должна быть размеров, которые можно потянуть
>2) У идеи должен быть рынок.
>1) Идея должна решать реальную проблему.
>5) Идею нужно иметь возможность сделать лучше чем конкуренты.

Охохонюшки…. Я с своим продуктом конкретно влип по всем статьям.

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

Даже супер идея и супер реализация не доведенная до конца вероятнее всего будут стоить ровно круглый нолик.

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

Так вот “деньги и время” должны стать коэффициентом, на который вы должны домножить абсолютно все. Есть идея, которая должна покорить рынок в 5 миллиардов баксов? А теперь домножьте на свои накопления в $123 и по полчаса в день по вечерам, которые вы собираетесь вложить. Умножили? Так вот, результат равен нулю.

Этот самый коэффициент точно также относится относится и к тому, что идея должна решать реальную проблему. Может ваша идея и решает
проблему, но вот реализация = идея*(деньги+время). И если второй множитель маленький, прощай решение проблемы.

Аналогично и с конкурентоспособностью.

Так, что повторяю еще раз – деньги и время.

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

Кстати,  именно он подкинул мне идею (был ее автором) самой моей любимой серии статей про программистский синхрофазатрон.

И вот, собственно, смирившись с невозможность победить в online споре, я решил перейти в offline режим, где смогу детализировано рассмотреть проблему.

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

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

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

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

Итак начнемс…

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

С точки зрения хорошего программиста Пети. Работа выглядит так
- Васе дали задачу, которую Петя мог сделать за 5 часа
- Вася поморочил Пети голову 2.5 часа, чтобы понять как ее сделать
- Вася проработал над задачей 20 часов пока не сделал
- Пете еще 2.5 потом пытается привести в порядок, то что натворил Вася

- Качество результата вышло хуже, чем если бы Петя делал сам.

Из этого следует, что если мы Васю уволим, то Петя потратит на эту задачу 5 часов и сделает (вместо объяснения, как ее делать), а фирма в результате потратит меньше денег. Вывод, Вася плохой программист и имеет отрицательную эффективность (только вытягивает на себя деньги).

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

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

Менеджер мыслит примерно так (естественно не с такими детальными выкладками)

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

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

Кстати, входные деньги – это не только деньги на зарплату программисту, но и на например покупку книг, или оплату другому программисту время консультаций и т.п.

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

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

Ну и просто, для того, чтобы показать, что значит в 50 раз менее эффективны. Это значит, что хороший программист задачу сделает за 1 неделю, плохой программист за 1 год.

Небольшое замечание по измерению оценки. Программист оценивает других программистах в терминах “на” – Вася сделает туже задачу _на_ X долларов дороже чем я, поэтому Вася не нужен. Менеджер измеряет в терминах “в”. Вася сделает туже задачу _в_ Y раза дороже.

Теперь следующий шаг в оценках менеджера. Пусть мы знаем, что задача которая подается программистам на вход должна принести скажем $10k. Самый эффективный программист на ее решение тратит $1k. Из этого следует, что все кто эффективны менее чем в 10 раз, будут тратить больше $10k и значит, что они приносят фирме уже только убыль. И чем больше они работают, тем большую убыль приносят. Так, что их таки можно увольнять.

Возвращаясь к Васе. Пусть Вася по этой формуле оказался в 4 раза менее эффективным. Тем не менее, с решенной задачи мы все еще имеем $10k – $4k = $6k прибыли.
Хотя безусловно, если Васю уволить, то получится $9k прибыли.

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

То есть, если у него эффективность жуткая (в 7 раз хуже, чем у Пети), но работает он автономно и Петю не трогает вообще, то тогда, получается, что они вдвоем могут приносить $10k-$1k (Петя) + $10k-$7k (Вася) = $12k. А если Васю уволить, то прибыль падает до $9k.

Ну и теперь с точки зрения предпринимателя.

Базируем ее на точки зрения точке зрения менеджера. Только введем некоторые дополнительные параметры.

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

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

Заметьте, как мыслит программист

а) Берется факт о случившейся ситуации где эффективность другого программиста была низкая

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

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

На самом же деле расход и доход динамичен. Он происходит в разные моменты времени.

Вернемся к примеру, который привел программист. Если плохой программист тратит в одной точки времени 5 часов хорошего, 20 часов своих и после этого в какой-то момент получается прибыль $10k, то действительно второй программист паразитирует в прямом смысле слова.

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

Для того, чтобы все стало на свои места, возьмем фирму из 30 плохих и 3 хороших программистов. Если мы слушаем 3 хороших, то мы увольняем всех плохих и ждем пока хорошие сделают всю работу которые делали бы плохие. Проблема заключается в том, что плохие хоть и были менее эффективны, но делали ее параллельно. Хорошие более эффективны, но делают ее последовательно. Итого, вместо выпуска через месяц и получения дохода, выпуск происходит через два месяца.

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

Естественно, наиболее хороший и логичный ответ, что в фирму из 3 хороших программистов нужно нанять еще 3 и они по быстродействию (даже последовательному)  станут быстрее, чем 30 плохих программистов.

Тут кроется одна проблема, это хорошо масштабируется от 1 до 5 хороших программистов, плохо от 5 до 50 и не масштабируется фактически вообще от 50 до 500 программистов. Поэтому для увеличения прибыли и сокращения сроков, компании проще нанимать 50 хороших программистов и 500 плохих, чем 100 хороших.

И последняя особенность.  В формуле прибыль = доход – расход, и доход и расход на самом деле являются не константами, а функциями.

Во первых, если фирма имеет большие продажи, то тогда доход от одной и той же функциональности может быть разный. И вот возникает интересный эффект. Если доход $10k, при расходах $1k и $7k – то отличие хороших и плохих программистов очень чувствительно (так как это изменяет прибыли от 90% дохода до 30% дохода). А вот если доход составит $100k, то разница между хороших и плохим программистов фактически не чувствуется (99% или 93%).

Важное замечание, которые мне написали: Это естественно более актуально для продуктов, где прибыль зависит от объема продаж. Для попроектной работы, прибыль заранее фиксирован. Более того, чаще всего они сильно прижат конкуренцией за исполнение проекта.

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

Фух… Подводя к итогам всю эту фигню, которую я написал.

а) Идеальная ситуация – много хороших программистов, нету плохих. Ситуация идеальная, но недостижима из-за плохого масштабирования найма хороших программистов.

б) Из-за пункта а) и больших штрафов при более позднем выпуске продуктов, компаниям выгодно распараллеливать работу нанимая средних и плохих программистов.

в) Да, плохие программисты менее эффективны, но благодаря увеличению продаж и улучшению процессов, они могут приносить прибыль, причем при определенных условия прибыль не многим меньше, чем хорошие программисты.

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

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

Есть два широко распространенных мнения:

- Лучшие лидеры решают все

То бишь, то что компанию “тянут” на себе эти самые лидеры. Остальные же, в лучшем случае не мешают.

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

Внутри этой идеи фактически к нулю сводиться наличие мозга у остальных в компании.

-  Одна голова хорошо, а две лучше

Это другой край той же палки.

Внутри этой  мысли бытует мнение, что даже самый умный человек не может быть умнее чем скажем десяток людей.

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

Чтобы не переливать воду из пустого в порожнее сразу прыгну к выводам.

Я считаю, что

а) Мнение большого количества людей хорошо в консультативном/обсудительном ключе. Как только мнение большинства начинает использоваться для управления, то получается анархия.

б)  Мнение большого количества людей полезно, но всегда надо полезность делить на количество потраченного времени этими людьми. Так, что если один человек подумав делает полезность на $100, и при этом за это время ему нужно заплатить $50 – это нормально. Если привлечь всю фирму к обдумыванию и они выдадут полезности в десять раз больше ($1000), но им надо заплатить за это $5000, то ну его на фиг такое мнение большинства, когда общая эффективность упала в 10 раз.

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

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

P.S. Я не пытаюсь противопоставить лидерство и мудрость толпы. Я пытаюсь очертить их границы. Естественно они должны взаимодополнять друг друга, а не бороться. И в общих чертах, граница проходит как раз по описанным пунтам – толпа может консультировать, но не управлять, использование толпы должны быть экономически оправдано, лидер используется там, где знание/умения/интуиция одного человека может превосходить коллектив.

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

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

Таким забавным образом получается, что программист именно из-за своего профессионализма тормозит свое развитие вширь (причем достаточно серьезно).

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

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

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

P.S. Из обсуждения с СОТОНА: Чем меньше компания, тем чаще профи затыкает все дыры.
Когда компания растет, то профи очень усердно начинают применять именно для одного направления.

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

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

А что вы предпочитаете делать в такие дни?

По этому поводу провожу глубокую заморозку блога на пару недель и писать новые статьи не буду (заодно может интересные мысли поднакопятся).

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

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

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

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

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

Я писал уже о том, что огромная проблема, что большей части населения вообще все пофиг.

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

Пробовал нанять Virtual Assistant. Так и получилось, первый блин – комом. Думаю, теперь, что делать. Платить больше денег – как-то жабно, так что придется перебором до нахождения кого-нибудь пристойного.

И вот пару дней назад у меня была битва в теннис с выдумщиком этой идей. Но, в отличии от того, что я писал в блоге (где я выступал за идею), в момент обсуждения с ним  я был адвокатам дьявола и пытался запинать идею ногами. И вот результаты пинания идеи выкладывают тут.

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

Итак начну из далека.

Пусть есть электрик Вася, сидящий на зарплате, и пьющий водку в рабочее время. И вдруг к этому Васе приходит белочка и он  думает , а чего это я водку все пью, лучше бабла подзашибу. Но блин, даже если я начну вкалывать, то дай бог мне подымут зарплату на 20%, лучше я пойду к своему начальнику и скажу, мол давай работать сдельно. Так Вася и делает. Приходит к начальнику и говорит, так мол и так, с водкой завяжу, сдельно работать будем и тебе лучше (я в пять раз больше сделаю и качественней делать буду) и мне лишняя денюжка в кармане. Начальник чешет голову и говорит, ладно Вася – починка розетки – 5 рублей, починка короткого замыкания – 10 рублей, полная проводка квартиры – 100 рублей. Если у заказчика все после этого через неделю сгорело – то с тебя вычет в двойном объеме. Проходит год, Вася шустрит, иногда правда клиенты ругаются, но суммарно все довольны – Вася при деньгам, начальник троих других электриков уволил, так как Вася за троих справляется, клиенты – счастливы не нюхать перегар Васи.

История вторая – есть Петя строитель. Так же самая картина маслом, но пьет он не водку, а пиво. И договаривается за 1000 положенных кирпичей. Начальнику тоже по душе, чтобы Петя работал и компания на нем деньги делала. Да, и теперь кладет кирпич в три раза быстрее, и при этом теперь больше его построек соответствует ГОСТу 1274-32-12б по укладке кирпича.
История номер три – есть Коля, модный массажист, делающий все виды массажа начиная от Боливийского и заканчивая массажем под названием “Рессора Белаза”. Коля, правда пьет уже не водку и пиво, а коньяк (не меньше 3 звездочек), но это мало что меняет. И вот он приходит к начальнику и говорит, а давайте я буду работать сдельно и буду делать все массажи в 5 лучше и в 5 раз быстрее. И вот тут начальник, выпучив глаза, говорит Коле…. Коля, а с коньячком-то видно пора таки завязывать, ты что с дуба упал в 5 раз быстрее массаж делать? Да и как мы будет проверять, что ты в 5 раз качественнее массаж сделал? У тебя что же есть массажеметр? Так, что пойди ка ты Коля, отдохни немножко и с свежими мозгами назад на зарплате работать возвращайся.
Ну, теперь более серьезно. Какова разница между вариантом Васей, Петей и Колей? А разница то, что в первых двух вариантах есть достаточно простое количественное измерение (связанной с доходом) сделанной работы и определенный (разумно измеримый) качественный уровень. В третьем же варианте, хотя количественное измерение есть, но оно не связанно с доходом и качественного измерения нету.

И теперь мы наконец возвращаемся к нашим горе-программистам.

С одной стороны, программисты (включая меня) очень хотят чисто сдельную оплату. Причем не просто сдельную оплату (такую как имеют freelancer’ы), а сдельную оплату внутри фирмы, когда дополнительной работы по поиску клиентов, ведению бухгалтерии у них нет, а вот денег можно зашибить дофига, если ты достаточно эффективен.
Кстати, коротенькое замечание сдельная = fixed cost за задачу, а не почасовка. Почасовка – это фактическа зарплата, просто в зависимости от того, сколько отсидишь на работе. Концептуально почасовка не меняет отношения к тому на сколько быстро хочется решить задачу. Я бы даже сказал, почасовка наоборот двигает человека в направлении растягивания задач.
Так вот, возвращаясь к тому, что программисты хотят сдельную оплату. Есть исследования, которые показывают, что отличный программист может быть эффективнее среднего в 10 раз. Соответственно, перед глазами мелькают цифры с 5-6 нулями за год
И вроде все было бы хорошо, если бы не
- Отсутсвие типовых задач
Фактически сама по себе – это не проблема, но я покажу, во что оно выливается ниже.
Тот же электрик или строитель, да и даже массажист имеет вполне ограниченный набор типовых задач. Их может быть скажем сотня, но все таки сотня разных задач – это вполне разумное число. И эти задачи можно записать.
- Отсутсвие количественной оценки задачи
Вот это проблема, которая вытекает из первой. Так как типовых задач нет, то все задачи не типовые. Для типовых задач, даже если их нельзя оценить впрямую, то можно оценить чисто статистически, сколько они занимают и какую прибыль они приносят. В случае, если же задачи не типовые, то начинается проблемы с их оценкой. И дай бог, если задачу можно оценить каким-то разумным методом. В программировании же, оценка чаще всего очень эмпирическая и +/- 30% даже на небольших задачах считается вполне неплохой точностью.  В добавление к этим проблемам, еще зачастую единственный человек который может дать оценку – является тот самым программист, работающий на проекте. И начальник никак не может проверить, дал ли он настоящую оценку или завысил ее в три раза.

Соответственно, начальник не может вывесить прейскуранта (как было сделано для Васи и Пети).

- Отсутствие измеряемого качества

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

И поэтому в ушах начальника это звучит так “Давайте я увеличу мое субъективное вложение в 5 раз, а вы мне увеличите объективную зарплату в 5 раз”. Так в жизни не бывает, что субъективное оценивается равным объективному. И кстати, именно поэтому хорошие программисты получают зарплату в 2-3 раза больше средних, а не в 10. Так как они только субъективно в 10 раз эффективнее, и то непонятно по чьим измерениям, когда же субъективное конвертируется, то на выходе получает большая в 2-3 объективных раза зарплата.
Фух… Что-то я начал запутываться, но думаю вы меня поняли. Вся проблема именно в отсутствии объективных оценок. Поэтому думаю к такому виду сотрудничества как я писал в первых частях – IT бизнес таки не придет.

Воооот… Ну и очень хотелось бы услышать ваши мнения, комментарии и идеи.

Дополнение N1: Итак, давайте, оценку = estimate из понятия абстрактного (а-ля сферический конь в вакууме) переведем на понятие реальное. Есть конечный человек которые делает оценку задачи.

Ситуация 1. Оценку делает менеджер, которые с кодом не работает. Я не верю, что человек не работающий с проектом может дать насколько нибудь разумную оценку.

Ситуация 2. Оценку делает каждый для себя. В таком случае, люди могут завышать оценку, тем самым выбивая деньги из фирмы.

Ситуация 3. Оценку делает team lead или другой опытный разработчик имеющий большой опыт на проекте. Это достаточно разумная практика, но в ней есть две проблемы. Даже team lead не дает точную оценку и очень обидно будет программистам, которые недополучат денег из-за ошибки team lead’а. Вторая проблема, что ситуация 3 вырождается в ситуацию 2 для самого team lead’а. То есть самый опытный человек делает оценку для самого себя и может ее завышать.

Учитывая, что весь этот сыр бор с программистским синхрофазотроном обсуждается именно для самых толковых программистов, то Ситуация 2+3, крайне важна. Непонятно, кто будет оценивать оценку team lead’а.

Дополнение 2. У многих возникает удивление. Типа, если программисты станут в 3 раза быстрее работать, какого фига они сейчас так не работают. Так что, эти заразы, работают не на полную мощность.

Так вот, как руководитель и программист в одном лице скажу,  да, программисты практически всегда работают не в полную силу. Кстати и не только программисты. Фактически в любой профессии если человек не дикий трудоголик то он в конечном итоге работает по возможному минимуму. И фактически все программисты – на работе читают блоги, смотрят YouTube, переписываются по ICQ с знакомыми. И это на самом деле выходит за рамки – передохуть подумать.

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

Просто, мне вспомнилась забавная история. Был большой и достаточно жуткий проект. Жуткий в том смысле, что писан был он большим количеством людей, без какой-либо толковой архитектуры и понимания, что делает каждая часть и как они должны взаимодействовать. Причем туча кода, писалась, хоть и толковыми парнями, но все же пока студентами, что опять же придавало проекту дух … э… ну, в общем студенческий дух. То есть код, вроде есть, вроде что-то делает, но скорее все это было похоже на переросшую (причем дико) лабораторную работу.

И вот один из продвинутых студентов (не я ) , начал выбивать рефакторинг, чтобы переварить всю эту кучу (хотел сказать говна, но решил сказать кода) в что-то более менее удобоваримое. Ну и начал он выбивать под это время. Естественно проект не маленький, поэтому время он пытался выбить тоже немало (уж очно не помню, но что-то типа 6-9 ч/м), на что в общем ему ответили, что иди мальчик – подыши свежим воздухом, столько бабок мы лучше в пофикс проекта вложим или скажем в новую функциональность.

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

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

Вернемся к тому продвинутому студенту. Товарищ поразмыслил и сказал, блин если вы такие жлобы, что не хотите давать 6 месяцев, то давайте хоть все начнем придерживаться единого стиля написания (название переменных, отступы и т.п. штучки).

И вот эту идею уже похерил я (не будучи даже главных разработчиком на проекте). И собственно я и сейчас готов отстаивать бессмысленность идеи. С одной стороны, вроде ясна логика студента, блин если нельзя сделать все красиво и качественно, то давайте делать, хоть что-то красиво и качественно. Но, тут есть одно «Но».

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

Вторая аналогия. У человека перелом ноги, малярия и чесотка. Нам нужно его вылечить. Имеет ли смысл человеку для лечения давать детскую дозу витаминку C?

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

Так вот, возвращаясь к коду. Если код плохой, то его нельзя вылечить витаминкой C (правильным именование переменных), его можно лечить только более серьезными лекарствами (например понемногу начать разгребать/рефактирить кусочки проекта).

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

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

P.S. Несколько вещей, которые были затронуты в комментариях. Отвечу сразу всем.

- Откуда вязалась неделя?

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

- Был ли это legacy проект?

Проект, содержал legacy части, но сам он не был legacy. Причем, его не собирались выкидывать

- Идея, не прогужения в гавно.

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

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

- Форматирование пробелов можно делать  автоматически

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

Остальное в комментариях.