Осторожно, очень много букв 🙂
Есть у меня один очень умный друг, которого абсолютно не возможно переспорить 🙂 Причем не из-за того, что он применяет какие-то нечестные метода спора, а просто потому, что количество знаний в его голове помноженные на его умение ими оперировать оставляют меня далеко позади 🙂
Кстати, именно он подкинул мне идею (был ее автором) самой моей любимой серии статей про программистский синхрофазатрон.
И вот, собственно, смирившись с невозможность победить в 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%).
Важное замечание, которые мне написали: Это естественно более актуально для продуктов, где прибыль зависит от объема продаж. Для попроектной работы, прибыль заранее фиксирован. Более того, чаще всего они сильно прижат конкуренцией за исполнение проекта.
И вторая функция — это расход. Как я уже писал, если плохой программист Вася не сильно теребит Петю, то для фирмы он становится гораздо более выгодный. Так вот, в маленьких фирмах Вася мучает Петю достаточно много, так как нету никаких процессов. В большой же фирме (в правильно построенной большой фирме) есть достаточно большое количество процессов по сбору, обработке требования, тестированию, разработке архитектуры. Все это процессы с одной стороны затратны, с другой стороны, позволяют Васе работать над гораздо более определенной задачей (с готовыми требованиями, архитектурой и т.п.), что уменьшает его необходимость в Пете.
Фух… Подводя к итогам всю эту фигню, которую я написал.
а) Идеальная ситуация — много хороших программистов, нету плохих. Ситуация идеальная, но недостижима из-за плохого масштабирования найма хороших программистов.
б) Из-за пункта а) и больших штрафов при более позднем выпуске продуктов, компаниям выгодно распараллеливать работу нанимая средних и плохих программистов.
в) Да, плохие программисты менее эффективны, но благодаря увеличению продаж и улучшению процессов, они могут приносить прибыль, причем при определенных условия прибыль не многим меньше, чем хорошие программисты.
г) Выгода использование плохих программистов растет с ростом соотношения прибыль/размер задачи и с улучшением процессов. Мне кажется, что это актуально для больших фирм и менее актуально для маленьких
в) Плохие программисты могут применять, когда диапазон требований к качеству достаточно большой и нижний порог достато низкий. При необходимости выпуска супер качественного продукта это не будет работать.
Виктор, что насчёт стоимости изменений? Мне кажется, она здесь не учтена.
Плохой код плохого прогграммиста увеличивает стоимость поддержки, что в оследствии сделает выпуск следующей версии более дорогостоящим, и увеличит время разработки.
Тоесть, изначально дешёвый плохой программист косвенно увеличивает ресурсоёмкость выпуска след. версий, тоесть приносит убытки компании.
P.S. Capthca у вас реализована откровенно плохо, при ошибке текст комментария безвовратно теряется.
Я чуть ниже писал. Для малых компаний действительно ухудшения качества — это проблема. При присутствии процессов контроля качества, оно падать не будет.
То есть, когда архитектура, user case, test case продумываются толковыми и ими контролируется, а реализация и unit-test’ы делаются менее толковыми, то проект можно вполне держать на разумном уровне.
Написал длинный ответ и потерял его, потому что openid опять глючит. Повторять уже не буду 🙁
Извиняюсь. Честно говоря openid + captcha меня убивают.
Captch’у снес, openid вроде без нее работает получше.
странный у тебя друг, раз вообще спорит об этом.
ведь существует просто огромная куча фирм с населением больше 50 человек (что автоматически обозначает присутсвие там «плохих» програмистов), которые генерируют доход, что опять же доказывает, что фирме иметь их выгодно.
ну, естественно, если не брать определение плохого как такого, который не генерирует прибыли 🙂
и вообще согласно закону Старжона 90% всего — гавно, но 10% вполне хватает 🙂
генерируют доход = генерируют доход больший, чем доход, который способны генерировать населяющие фирму только «хорошие» програмисты
кстати, а чё я не линк на свой сайт? (удали камент потом)
Черт его знает, что-то captcha совсем взбесилась. Я ее нафиг вырубил. Надеюсь, теперь станет получше.
>ведь существует просто огромная куча фирм с населением больше 50 человек (что >автоматически обозначает присутсвие там “плохих” програмистов), которые генерируют >доход, что опять же доказывает, что фирме иметь их выгодно.
Если бы все было так просто, я бы не писал статью :))
Если все сводить к логике, что раз оно есть, значит оно выгодно, то получиться —
Вы простудились, у вас теперь есть вирус. Значит вам выгодно иметь вируса.
Скорее, тут нужно обсуждать закон Парето, что 20% людей производят 80% результата. И заказывака состоит в том, можно ли или нельзя уволить часть из остальных 80% людей, не уменьшая (или увеличев результат).
ну, на самом деле, всё действительно так просто. просто не надо притягивать невалидные аналогии, а рассматривать саму проблему — она не настолько сложна, чтоб «упрощать» её с помощью аналогий, тем более неверных.
почему «раз есть, значит выгодно» — потому что руководство фирм совершенно свободно может набирать себе любых программистов. у них нет никаких внешних ограничений (за редкими исключениями типа ужасного реноме фирмы), которые бы мешали брать одних только звёзд. но почему-то не берут. если отбросить инсинуации про повальную тупость руководителей, остаётся только одно — прибыль.
а всё потому что бизнесу не надо «хорошо». бизнесу надо «удовлетворительно» (just good enough)
вот например макдональдс вообще не берёт звёзд (по крайней мере на звёздную зарплату) и ничего…
Собственно говоря я как раз пытаюсь доказать, что это выгодно. Совсем уж математического доказательства у меня увы нету. Думаю, что оно вполне может быть, но на нем легко можно уже PhD по экономике защищать 🙂
>если отбросить инсинуации про повальную тупость руководителей, остаётся только >одно — прибыль.
Боюсь, что этот аргумент постоянно всплывает и его достаточно тяжело опровергнуть.
Он основан на трех умозаключениях
а) Действительно есть большое количество не слишком умных и маломотивированных руководителей
б) Раз в некоторое время большие компании умирают. И вот тогда в них тыкают и говорят, это все дурные руководители (что верхнего, что среднего звена) довели.
в) На фразу, что остальные то компании приносят прибыль, идет ответ, что если бы руководители были умные, то прибыль была бы еще больше.
Увы, математического обоснования, что в среднем руководители умные, я тем более привести не могу.
хм. а как по мне те, кто его приводят просто не думают. так что про «умозаключения» ты загнул…
объясняю — приводить аргументов и примеров можно бесконечно много, но факт остаётся фактом: если прибыль падает ниже 0, то фирмы просто разоряются, но фирмы с населением больше 50 человек (т.е. с плохими програмистами) цветут и пахнут. это уже говорит о том, что это для владельца а) выгодно, б) выгоднее, чем фирма из 5ти хороших програмистов.
кстати, очень много фирм, основанных программистами, заканчивают крахом… аж до тех пор, пока «глупый бизнесмен» в основателе не победит «умного программиста» 🙂
>объясняю — приводить аргументов и примеров можно бесконечно много
Тут я не совсем согласен. Научный метод исследования требования построения теории.Причем если факты вписываются в одну теорию, это не значит, что она еще верна.
Я строю теорию, что плохие программисты приносят прибыль. Внутрь этой теории хорошо вписывается — большие фирмы с плохими программистами, которые цветут и пахнут.
Но с другой стороны, в теорию о том, что фирмы с плохими программистами получают прибыль из-за например монополии. А плохие программисты там находятся потому, что есть также много плохих менеджеров, вполне тоже работает на этих фактах.
Чтобы решить какая из теорий верна, нужны либо аргументы, либо факты которые подрывают чужую теорию.
эээ… вот только не надо всё смешивать.
я ж нигде не говорил, что «только тупые програмисты приносят прибыль». нет сами они не приносят — они _могут_ её приносить при поддержке «хороших».
есть же достаточные, а есть необходимые условия. так вот, имхо, достаточным условием для прибыльности является наличие «хороших» програмистов на фирме. необходимым условием масштабируемости (но недостаточным) является умение фирмы работать с «тупыми».
что касается фактов, подрывающих теорию о том, что тупые програмисты всегда работают в минус, то вот он: нет ни одной фирмы 50+ человек без тупых програмистов.
оффтоп:
кстати если взять команду из 10ти «хороших» програмистов, то как они распределятся внутри «хорошести» и как много из них будут считать, что среди этих 10ти есть хотя бы 1 «тупой»?
Кстати, спасибо за этот комментарий. Честно говоря я надеялся, что эта ветка обсуждения таки всплывет 🙂
вы забыли о модели time and matrial — когда клиент платит за часы. тогда не важно какого качества программист — он выгоден
Важно-важно.
а) Если программист очень хорошего качества, но требует уровень оплаты, который привышает стоимость часа в time & material — он может быть не выгоден.
б) Если программист очень плохого качества и не может сделать проект на уровне требуемом заказчиком — то он тоже может быть не выгоден (в случае если количество проектов ограниченно).
Хотя безусловно, в попроектной работе, качество программистов играет абсолютно другую роль.
Так как доход зависит не от результат и продаж, а от количество часов.
Тут есть один момент, который в статье не освещен. Многие фирмы фокусируются только на одном рынке, на рынке тех услуг, которые они предоставляют. На самом деле любая фирма находится минимум на двух рынках. Второй рынок — это рынок труда.
Кто про него забывает, обычно жалуется на то, как тяжело найти хороших программистов 🙂
Вторая типичная ошибка — это полагать, что когда я стал сотрудником фирмы, я ушел с рынка труда. Нифига не так, и вовсе даже наоборот: внутри фирмы информация течет более открыто и проявляются многие важные детали. Поэтому сотрудники имеют более опасную с точки зрения фирмы позицию на рынке труда, чем посторонние специалисты.
Любое мало-мальское бизнес решение отсматривается на предмет того, как оно повлияет на позиции фирмы на ее основном рынке. По хорошему оно также должно отсматриваться на предмет того, как оно повлияет на позиции фирмы на рынке труда.
Если система Пети и Васи принесет в среднем на 30% больше прибыли, улучшит масштабируемость фирмы, но приведет к тому, что «пети» больше в эту фирму не придут (а то и начнут из нее уходить), то ответ на этот вопрос перестает быть таким очевидным.
… так я к чему все это. Обычно Пети жалуются на наличие Вась не потому, что они принципиально ненавидят работать с новичками (а Васи, они ведь обычно плохие не потому, что тупые, а потому, что еще студенты). Так вот, сама по себе работа с новичками часто не является проблемой — в конце концов, мы все были новичками, работали вместе со старшими товарищами, помним как это было, и можем проявить эмпатию.
Проблема обычно лежит в области мотивации и/или управления. Например, Петя и Вася оба имеют одинаковое название должности в сигнатуре письма. Или какой-нибудь менеджер проекта при подсчете ресурсов не делает различия в производительности. Или Петя не имеет возможности выбрать того Васю из множества, с кем он бы хотел работать. И т.д.
Я бы сказал, что рынок труда, штука конечно хорошая, но на нем такое количество игроков, что решения фирмы очень мало влияют на то, кто к ней пойдет завтра работать, а кто нет.
Что я видел своими глазами, то, что даже фирма не слишкам лояльная к работникам и с большой текучкой вполне умела находить новых хороших работников.
Так, что Пети в эту фирму прийдут. Ну может Петям надо будет посулить дополнительные 10-15% поверх рыночной цены. Получается мы имеем 30% больше прибыли по всей фирмы и дополнительные 10-15% расходов на 10-15% программистах, что эквивалентно будет эдак повышению общих расходов на 1%.
Да, плохие программисты могут написать хоть какой-то код, но потом это все выливается в масштабные рефакторинги, поиски скрытых багов (месяцами) и утечек памяти. При этом, плохие программисты часто не используют тесты, доказательства алгоритмов и т.п. Что в итоге ведет к плохому продукту и репутационным потерям комании
Абсолютно согласен, на примере
а) Небольшой компании
б) Отсутствие процессов
Поэтому я и говорил, что плохие программисты для маленьких компаний работают плохо.
В компании с нормально поставленными процессами. Например такими
а) Коля собирает требования и приводит их к разумному виду, пишет user cas’ы и отдает Оле
б) Оля берет user case и создает test case и отдает это Пете
а) Петя разрабатывает архитектуру
б) Петя работает над критическими частями
в) Вася получает уже четкое описание интерфейса модуля который он должен писать
г) Вася должен написать тесты и показать из Пети
д) После этого Вася пишет свою модуль
е) На код Васи напускается утилита анализа кода и до тех пор пока кол-во ошибок не будет меньше чем X на Y линий, код не принимается.
В таком случае, проблемы в проекте хоть и будут накапливать, но не с такой скоростью, как они накапливаются если процессов нету.
Да, я как раз поб этом и говорил. Плюс к тому оверхед, создаваемый плохими программистами на руководителя проекта/рабочей группы наверх и на тестеров вниз на очень большой процент является принципиально неуничтожимым, убрать его по желанию просто невозможно. И повторное использование написанного плохими программистами кода крайне затруднено.
А проблема еще вот в чем: хотя казалось бы, очевидно, что эффективность хорошего программиста с учетом косвенных затрат, как минимум, на десятичный порядок выше, чем плохого, если не персонально ты распределяешь бюджет, объяснить административному руководству, что платить хорошему программисту нужно хотя бы в пять раз больше, а не в полтора-два, что за него нужно держаться и что метод «да мы лучше на эти деньги десять студентов наймем» — не работает — почти нереально в большинстве случаев. Большинство менеджеров пребывает в нелепейших заблуждениях о том, из чего складывается эффективность разработки.
Оверхед действительно есть.
То, что я ответил чуть выше.
Проблема в маленькой фирме, что она не может позволить себе оверхеда, так как ей надо быть очень мобильной.
В большой фирме оверхед, даже без плохих программистов гораздо выше. И туда легко встроить оверхед для того, чтобы заставить плохих программистов маршировать в ногу.
Вот, что меня удивляет, это противопоставление. Они — административное руководство, мы — менеджеры младшего звена или программисты.
Замечу, что
а) Есть множество директоров фирм, которые были программистами
б) Если множество топ менеджеров, которые были программистами
Почему же, они не понимают такой простой истины?
Мне кажется тут дело, именно в том, что финансово невозможно сделать разрыв в 5 раз, особенно в развитых странах.
Возьмем США. Условно говоря зарплата хорошего программиста $8k/месяц, плохого $4k/месяц. Мы не может поставить зарплату плохому $2k/месяц (достигнув разрыв 4) потом, что пойдет в другую фирму или если это будет повсеместно уйдет в другую специальность, чтобы не умереть с голоду. Но мы и не может повысить программисту зарплату с $8k до 16k, потому что тогда прибыль очень серьезно упадет (программисты одна из основных расходных статей).
В странах развивающихся большей разрыв держится только из-за того, что прибыль составляет больший процент и поэтому можно позволить платить больше программистам.
А почему, собственно, мы не можем платить $12-16K тому, кто работает в десять раз эффективнее получающего $4K? Если нам это выгодно? При том, что мы при том, не моргнув глазом, нанимаем несколько человек на те же деньги при необходимости? Не является ли это нелепым и опасным предрассудком? Опасным, потому что демотивирующим: никто не хочет корячиться за десятерых, чтобы получать вдвое больше, и уж точно нет никакого стимула делать это именно здесь, а не у соседа. Это просто несправедливо и нерационально.
Я в следующей статье пару графиков нарисую.
В целом, увы… не можем платить $12-16k. Если мы сейчас потянем зарплаты хороших программистов вверх, то это в притянут в индустрию множество новых людей. Увеличенная конкуренция понизит зарплаты слабых программистов и им будет выгоднее уйти из индустрии.
Дальше у нас возникнут две проблемы
а) Расходы в фирме вырастут
б) Образуется та же самая проблема с проблемным соотношением результативность/зарплата, только уже между хорошими и средними программистами.
Плохие программисты — конечно, зло, но хороших-то на всех не хватит. Есть некоторый уровень, ниже которого брать на работу нельзя вообще. Уровни повыше требуют контроля и некоторого обучения принятым (и общепринятым) стандартам. Еще выше — обходятся самоконтролем и чувством рабочей гордости 🙂
Но почему вы пишете только о «программистах», да еще так много? Давайте уж о всем бизнес-процессе, об утряске требований и их изменении, об обеспечении последующих переделок приложений, о кодерах, тимлидерах, тестировщиках и проектировании 🙂
P.S. Я — сторонник неформального похода к разработке 🙂
Ну, я пишу о программистах, так как ближе к телу. Но в целом эту статью можно достаточно легко «натянуть» на другие близкие должности.
>Есть некоторый уровень, ниже которого брать на работу нельзя вообще.
М… Против это я и спорю, что этот уровень слишком сильно зависит от того, как работает фирма, чтобы его провести.
Вот я как раз и пытался объяснить, что «плохой программист» плохо не столько сам по себе, а потому, что он в процессы вписывается плохо. И при неформальном подходе, кстати, все еще хуже. Формальные подходы затем и придуманы, чтобы из некачественных деталей можно было все равно собрать работающий механизм.
Как раз плохой программист вписывается в процессы гораздо лучше.
В McDonald схему хорошо вписываются студенты без знания кулинарии и плохо вписываются титулованные французские повара.
Хороших поваров сложнее найти, они требует гораздо более тщательного отношения к ним, они хотят «творить», а не действовать по указке.
А вот студентов, очень легко загнать «в процесс» где от них требуются минимальные умения. А если им не нравиться, то их увольняют и берут новых.
имхо,
1. плохому программисту можно поручать какие-то задания не очень сложные, на которые использовать дорого программиста будет не эффективно. такие задачи всегда есть.
2. если хороший программист в свое время не поленился хорошо документировать свой код, а так же менеджер не поленился с составлением инструкций по работе над задачами(т.е. поставлен процесс), то слабый программист не будет отбирать время у хорошего вообще.
3. слабые программисты, особенно если они еще молодые и неопытные, имеют тенденцию обучаться (так уж мы люди устроены). Так что имея штат из 1 супер-программиста, 5 хороших и 15 слабых программистов, через пару лет можем получить 2-3 супер и 10 хороших. Что так же можно оценивать с точки зрения хороших инвестиций (правда этих людей еще нужно удержать в фирме, но это другой вопрос, вопрос ресурс менеджемента). А если не иметь плохих программистов, то прийдется постоянно искать на рынке свободных супер-программистов ,которые смогут в сжатые сроки подхватывать и исполнять таски. И как мне кажется, но направлять усилия ресур-менеджемнта на удержание кадров ,все же более эффективно, чем на постоянные поиски свободных на рынке.
В защиту же можно сказать вот что:
чтобы содержать 6 программистов, им хватит одного менджера, 3-4 тестера + 1 бухгалтер, 1 офис менеджер, 1 уборщица и все (ну может че еще забыл.). Если держать 3 программиста хороших и 15 плохих, то сопутствующий штат выростает офигеть как быстро, и уже у вас штат программистов такой же по эффективности, но делает задачи в полтора раза быстрее чем 6 хороших, а общий штат сотрудников выростает с 15 человек, до 60-70, выростает необходимость в построении отточеного механизма, т.к. сами лично вы уже такую прорву людей контролировать не сможете. Выростают риски. Так что получается, что вся ваша выгода от того что вы с 18 программистами выпустите такой же функционал в полтора раза быстрее чем с 6-ю будет сожрана этими повышенными затратами. Плюс к этому качество продукта упадет, а в условиях конкуренции на рынке потеряв немного репутацию вы рискуете оказаться без заказов на пару месяцев. И что происходит в таком случае? 6 программистов, даже высокооплачиваемых, можно прокормить пару месяцев за счет фирмы (к тому же им всегда можно найти короткосрочную халтуру, в которую они быстро въедут и отработают часть денег по своему содержанию), а 70 человек содержать пару месяцев потянет далеко не каждая контора, не у всех есть такой запас прочности на счету в банке. А это в свою очередь влечет проблемы с климатом внутри конторы и еще куча проблем.
Так что смысл в найме слабых программистов конечно может быть, но прежде чем нанимать штат слабых программистов, нужно:
1. Заранее написать инструкции по работае в коллективе 60-70 человек. (тоже самое при повышении мастшатоб до 500 и 1000).
2. Запастись деньгами, чтобы вы могли пережить трудные времена за счет этого стабилизационного фонда, когда фирма оказывается без заказов или без оплат в течении какого-то периода времени.
Насчет первых трех пунктов полностью согласен. Единственное, учатся программисты, только в том, случае если они не опытные, если программист опытный и плохой, то вероятнее всего учиться уже поздно.
Насчет остального. В основном при росте программистской массы, за ними только тестеры и менджеры серьезно по количеству гоняться.
Количество необходимых тестеров решается
а) автоматизированным тестирование
б) uniTest’ами
Особенно если мы говорим, что функциональность одинаковых размеров делается.
Менеджеры действительно нужны дополнительные. Скажем 1 менеджер на 7 человек, офис менеджеры вполне может быть 1 менеджер на 30 человек, бухгалтер — 1 на 50 человек.
Итого, на каждые дополнительные 50 человек, мы будем иметь что-то типа человек 10 overhead’а. Причем, вероятно это 10 человек будут не слишком дорого оплачиваемых.
Что действительно, что вырастают риски. Прибыль конечно растет, но за ней растет и расход. Если прибыль не стабильна, то это действительно приводит к проблемам.
Имхо твоя вера в юнит-тесты и автоматизированное тестирование слишком сильна 🙂 программист делает ошибки не только в коде, а и в юнит-тестах. Тестировщик просто неохбодим. Автоматизация безусловно помогает, но найти такого классного тестировщика, еще сложнее чем классного программиста 🙂
так что раздутие штата при росте количества программистов очень велико. в нормальной конторе , которая занимается всесторонней поддержкой и разработкой продукта количество программистов не должно быть больше 20% от общего штата сотрудников. Иначе это серьезные косяки в организации производства или у вас специфические заказчики ,которые полностью берут на себя все задачи кроме кодинга. И если вы умеете работать только с программистами, и не понимаете для чего нужны тестировщики, дизайнеры, маркетологи, верстальщики, теч-райтеры, уборщицы, офис-менеджеры, менеджеры, инспекторы, курьеры, ассистенты менеджеров, юристы, бухгалтеры и прочая… вы никогда не сможете простроить прибыльную компанию крупнее чем 10-15 человек.
>Имхо твоя вера в юнит-тесты и автоматизированное тестирование слишком сильна 🙂
Ну я же не говорю, что оно решает ВСЕ проблемы. Оно просто изменяет соотношение тестировщиков к программистам.
>которая занимается всесторонней поддержкой и разработкой продукта количество >программистов не должно быть больше 20%
Эээ… Секундочку. Не надо тут путать.
Это выглядит не так: «если у нас 200 программистов, нам нужно нанять 800 кого-то еще для их поддержки’, а вот так «у нас есть большой продукт, который мы может круто продавать, так что у нас есть 400 sales, нам нужен HR отдел для нанятия sales и программистов, у нас нужно 30 человек в маркетинговом отделе, 20 в product manager и да… для того, чтобы поддерживать этот продукт нам нужно 200 программистов».
Это в небольших конторах танцуют от количества программистов. В больших конторах танцуют от объемов продаж.
И скажем если вместо 200 программистов (20 хороших, 50 средних и 130 плохих) мы как-то магически наймем 50 хороших, от этого мы не уволим всех sales, HR, product manager’ов и т.п.
Вывод: надо брать на работу или только сотрудников макдональдса или только бакалавров из MIT.
Продолжая идею если есть 1 супер-программист, 5 хороших и 15 слабых (кстати как определяются супер-, хороший и хреновый программисты? Программист либо есть либо нет. Нет — это «тупой программист»).
Так вот через год супер-програмист видит, что он умнее всех и ищет себе работу по лучше. И того уже есть 5 хороших и 15 слабых.
Через еще год контора начнет заказывать разработку библиотек на стороне и сбегут, предположим, еще 3 человека (из 5 хороших, слабым то чего, они за место будут держаться).
И так у нас есть 2 хороших программиста и 15 слабых.
Почему не было роста? Да потому, что для компании главное код педалить, а не учить тех самых 15… Да еще и супер-программист сбежал год назад.
Но это все касается «бесконечного ПО» (ПО которое выпускается версия за версией), а вот там, где главное один раз сделать и свалить все подругому.
Там тупые программисты в самый раз. Сделал один раз тупо и свалил. Так обычно сайты пишут, да и при принятой схеме «код нужен к дате Х» в конце концов как будет выглядеть код сайта уже не волнует. Я еще ниразу не видел ни одного сайта, который бы требовал поддержки (не считая случая когда находится уязвимость в шаблонном движке).
О применении идиотов в остальных типах ПО (внутреннее и какие там еще есть) ничего
приличногоне напишу (устану матюгаться).А где капча?
дык это полемика уже о том, кого называть тупым программистом. вы не находите, что когда мы только начинали учиться программировать мы все были тупыми программистами? просто кто-то учиться быстрее, а кто-то медленнее. кроме того если бы все учили одно и тоже, а то ведь учителей много и все они говорят разное. пойди разберись, что нужно учить, а что нет. далеко не всякий выбирает правильный путь. вы просто видимо сторонник того, что талант либо есть, либо его нет. Я же сторонник того, что талант — это лишь 10% от успеха, которые дают преимущество на старте, когда все еще ничего не знают. А остальные 90% — это трудолюбие и усердие (а тут главный вопрос в мотивации, в воспитании людей). Отсюда и мое нежелание называть программистов «тупыми», а использовать характеристику «слабый».
Тогда получается, что «слабый», «средний» и «супер» всего лишь оценка уровня знаний и она никак не связана с понятием «тупой». Да «тупой программист» на 99% это именно «слабый», но слабый он не «еще», а «уже [долгое время]».
Если так дело пошло то могу предложить следующую классификацию людей:
1) Могут сами решить поставленную задачу;
2) Могут решить задачу если им показать направление;
3) Не решат задачу.
Так вот «слабый», но «не тупой» будет в группе 1 или 2, а «тупой» всегда в 3. Так что термин «тупой» здесь более уместен. А если рассматривать с заделом на будующее то «тупой» == «не способный к обучению и делающий все по инструкции».
допустим я согласен с Вашим определением тупого. Но судя по цифрам из заметки Вити соотношение хороших к тупым 1 к десяти. Т.е. 9 из 10 программистов — это тупые программисты. Так вот мне с такими цифрами не позволяет согласиться ни мой опыт, ни моя вера в человечество. Я считаю, что на 10 человек не способных обучаться (не в силу своего физического развития, а в силу духовного, психологического развития (воспитание и мотивация)) всего лишь 2 из 10, остальные 6, которых вы причисляете к тупым — это люди готовые и желающие обучаться, если вы будете к ним относиться с уважением и пониманием. Оставшиеся 1-2 из 10, которые стали классными в силу либо благоприятствующего окружения, либо в силу своего природного протестующего духа, когда наперекор обстоятельствам они доказывали себе и окружающим, что они могут быть лучшими. Большинство же люде
…й не способно бороться против обстоятельств.
Да, может я слегка конечно загнул насчет соотношения 1 к 10 :)) тупых по количеству гораздо меньше 🙂 Хотя безусловно их очень не мало.
Хотя, слово «тупой» я на самом деле подкинул в заголовке, просто чтобы раззадорить.
Лучше таки использовать «плохой» — это может быть как глупый (который уже не научитсья), так и неопытный.
На словах конечно звучит хорошо — научится и станет лучше, но на самом деле длительность обучения для переходы из одной категории в другую — обычно превышает срок работы в одной компании.
Кстати, изначально в статье, я в основном имел в виду именно тупых программистов. Те которые слабые программисты, но которые уже не научаться лучше, в следствии низкого IQ, отсуствия мотивации и т.п. вещей.
Платить нормально — так не сбежит, а еще других приведет 😉
«все кто эффективны менее чем в 10 раз, будут тратить больше $10k и значит, что они приносят фирме уже только убыль»
🙂 Чтобы не сбежал хороший надо повысить планку для плохого. Так что снова перед разбитым корытом.
Кстати, эту мысль я как раз собираюсь в следующей статье описать, насчет зарплатообразования.
Давай-те лучше умножим все на 10, 10 отличных, 50 хороших, 150 слабых. В тот момент когда 3 отличных сбегают — то идут и нанимают других 3 отличных.
Как по вашему в IBM, Google, Microsoft, Apple и т.п. все-все отличные программисты? Да ничего подобного, куча средних, слабых. Да, сильные могут сбежать, но на их место нанимаются другие сильные.
Тут уже больше простора к размышлению.
Когда 3 сбегут не убегут ли остальные?
Какая тройка придет им на замену? И придет ли вообще.
и т.д.
IBM, Google, Microsoft? Они могут позволить себе нанять отличных программистов. Даже выбор будет. Конечно их можно сравнить с вымышленной компанией численностью 210 программистов, о которой никто не слышал. Да же экперимент (опрос?) провести, куда кто пойдет. Получится что вероятность попадания «тупого» к ним стремится к нулю. А набирать слабых и средних с обученим им вполне по карману (а может даже и дешевле).
>Тут уже больше простора к размышлению.
>Когда 3 сбегут не убегут ли остальные?
>Какая тройка придет им на замену? И придет ли вообще.
>и т.д.
Смотря какая ситуация. Если конечно, хороших программистов пытают и загоняют иголки под ногти — то может и сбегут.
А так, у 10 хороших программистов будет разная мотивация. Например кто-то купил квартиру только что и не хочет особо рисковать. А кому-то все пофиг, просто хочет сидеть и в свое удовольствие что-то делать и т.п.
>IBM, Google, Microsoft? Они могут позволить себе нанять отличных программистов.
Легко. Но нанимают они разных (особенно IBM и Microsoft), Google долго славился наемом хороших программистов, думаю скоро это будет меняться.
Не только нанимают, но и скупают. Но это уже другая история. Но это никак не значит, что им выгодно брать наимее способных. И если будет выбор между хороший и плохой они возьмут хорошего.
Но вернемся к вопросу. Вопрос, как я понимаю, именно в том «Хорошо ли брать плохих». И для неизвестных компании у него есть хвост «за неимением хороших».
Для известных ответ «нет» (с экономической точки 10 хороших выгоднее 10 плохих).
Для неизвестных — «иногда» (им во век 10 не набрать, а деньги делать надо).
Осталось примешать число требуемых программистов и число соискателей.
Думаю, деление на известный и неизвестный не совсем корректный.
а) В основном вопрос не известности, а возможности нахождения хороших. Опять же IBM, будет очень тяжко при всей своей известности находить столько хороших программистов, сколько нужно.
б) Для больших компаний с хорошо поставленными становится гораздо выгоднее брать плохих (работать по схеме McDonald’s).
a) Про деление я как раз и написал «Осталось примешать число требуемых программистов и число соискателей.» Известность лишь увеличивает число соискателей. (У IBM появилось сообщество;) )
б) Только в случае если выпускается много небольших проектов. А для коробочных проектов это будет смерть через пару выпусков (лирическое отступление: Можно конечно закрывать на это глаза, и считать что «в каждой программе обязаны быть ошибки» и «программа не тормозит, это компьютер слабый». И доверить таким писать ПО для кардиостимуляторов…).
Так что дискусию предлагаю остановить следующими утревждениями:
1) Выгоднее брать хороших программистов, чем плохих.
2) Выгоднее брать плохих программистов, чем не брать никаких.
Полностью соглашусь с последним абзацем 🙂
Искал в яндексе что-нибудь интересное и наткнулся на ваш сайт. 🙂
Тупые, тупые мы кодеры — не вовремя написать, не в задаче распутаться, а только запутаться, и работу подыскать не могем. Только смолётом можно долететь 🙂 😉 В).
…
А вон по факту — шас у нас тут , ну 3е -4е старших по возрасту, ой пять — 2 начальника, и три женщины — камералит, земельный участок и на бетоне на выходном.
А остальные — учёбки.
Хотя, да там ажно два инжнера, если не вру.
Но почему-то их в чистое плавание не то что не отпускают, просто и они не шибко-то и рвуться.
Хотя шас бабло подсекли, на дальнейшее только слухи, что ввего лишь 1и3 миллиарда на обводной дали до лета, короче ситуация как раз позволяет проявить самостоятельность «хороших программистов» 🙂 😉 В).
Если честно я толком ничего не понял. После двух прочтений я понял, что у вас 5 человек — два старшие по возрасту, два начальника и женщины.
Что такое камералит — я не знаю.
1и3 миллиарда на обводной — тоже не совсем понятная фраза.
хорошего програмиста следует искать из плохих.. со временем он научиться и выполнять будет все гораздо быстрее и рассудительнее!!!!
Естетсвенно, в него нужно вложить много-много денег, а потом он уйдет к конкурентам :))
Обучение хороших программистов занятие длительное и чаще всего риски превышают прибыли.
Я что-то не совсем понял, каким образом вы связываете роль человека (программиста или еще кого-то) с прибылью? Как вы оцениваете вклад в денежном эквиваленте?
Что касается «плохих» программистов. Если программист может часть работ взять на себя и гарантировать их выполнение (в любой срок), то он уже оказывается полезным — им можно управлять.
Обычно программистов делят на Junior/Middle/Senior. На мой взгляд они отличаются только степенью ответственности, которую готовы на себя взять (из расчета, что они отдают себе отчет в последствиях).
Что касается необходимости держать программистов разного уровня в штате — я думаю что без этого никак. Причина в том, что в процессе разработки очень много рутинной работы, которую нужно кому-то делать. Делать такую работу высококвалифицированными кадрами можно, но это как из пушки по воробьям.
По моему опыту один «хороший» программист может найти работу 2-3 программистам уровня ниже и организовать такой процесс эффективно, выполняя ее параллельно.
p.s.
OpenID все же глючит — стирает комментарий после попытки логина, которая, кстати, постоянно проваливается, если пытаться выполнить вход, написав URL в форме комментария.
На рутину людей найти не такая уж большая проблема. Есть люди, которые звезд с неба не хватают и знают об этом, и спокойно могут делать одно и то же до пенсии. Но им нужны приличные зарплаты и здоровый коллектив (ну и некоторые другие мелочи), если это есть, то все Ок.
А кто поспособнее, на тех обычно завязана судьба проектов, как бы это не высокопарно звучало, и отношения с ними совершенно другие, и мотивация другая.
Насчет OpenID знаю — у меня он на повестке дня. Вчера captch’у поборол, которая тоже глючила, надеюсь новая будет глючить меньше.
>Я что-то не совсем понял, каким образом вы связываете роль человека (программиста или >еще кого-то) с прибылью? Как вы оцениваете вклад в денежном эквиваленте?
Естественно формулы нету. Но в целом, если захотеть, то систему можно разделить на какие-то подчасти и назначить им % от цены всей системы.
Кстати, если вдуматься, точная конечная цифра стоимости того, что человек делает не так важна в каждом из расчетов, которое я привел.
Единственное, где она серьезна актуальна, это нижний уровень эффективности, который можно позволить, чтобы не выходить в минуса.
>Что касается необходимости держать программистов разного уровня в штате — я думаю что >без этого никак. Причина в том, что в процессе разработки очень много рутинной работы, >которую нужно кому-то делать. Делать такую работу высококвалифицированными >кадрами можно, но это как из пушки по воробьям.
Согласен с вами.
Но опять же с точки зрения хорошего программиста, даже когда мы выдаем простую рутинную работу, плохой программист делает ее очень долго и не качественно.
То есть с одной стороны, им самим скучно ее делать, с другой стороны, когда делает плохой им потом приходится ее доделывать/исправлять.
А плохой значит будет молча работать с тем что есть? Рабством попахивает.
Теперь уже начинает проследиваться связь с постом до этого. Есть человек которому абсолютно по хрену на проект главное делать нечто за что деньги платят.
В итоге действительно получается нечто, что теоретически можно использовать, но. Много но.
Такое проект можно впарить (именно впарить) только если:
1) Он позарез нужен и аналогов нет (кто-нибудь видел такое?);
2) Нужен не сам проект, а факт наличия онного (как это выглядить: НПО Х покупает проект Y и выдает его за реультат собственной научной работы).
Если есть что переделывать нужно, то это нужно было на предыдущем этапе в виде спецификации оформить и субпроект не принимать до тех пор пока он спецификации соответствовать не будет.
>А плохой значит будет молча работать с тем что есть?
Не совсем понял к какой их моих фраз это относилось.
>Есть человек которому абсолютно по хрену на проект главное делать нечто за что >деньги платят.
Между прочит таких людей достаточно много. И ничего
а) рабают
б) продукты в которых они участвуют — тоже продаются (причем не обязательно из-а отсутствия аналогов).
Еще раз возвращаясь:
>А плохой значит будет молча работать с тем что есть? Рабством попахивает.
Если это был вопрос насчет того, что хорошим программистам — скучно, а плохие — должны молча работать. То, в целом так и получается. К рабству это не имеет никакого отношения — это обычные вопросы спроса и предложения.
На хороших программистов спрос выше, а предложение меньше — они могут больше условий выбивать хороших. На плохих программистов — спрос меньше, предложение больше, вывод работодатель может выбивать условие интересные для него, а не для плохого программиста.
Да ладно вам , плохой, так всё писец.
Может потрётся с хорошими — глядишь чёт и выйдет.
А так-то с точки зрения давателя — только первый сорт, чё недоделок на созревание выбирать.
А вообще, если не забыл начало , смысл в том, что всё же и плохие программеры на чё-то годны, просто грамотный манагер замутит как их приготовить :))).
Ну я в нескольких комментариях писал, что в основном о плохих программистах мы говорим в том смысле, что у них уже было время научиться, но они таки не научились.
Подозреваю, что действительно хорошие программисты за зарплату не РАБотают, ни за 4к ни за 16к, а один раз программируют структуру фирмы под максимизацию прибыли, нанимают хороших манагеров и не очень хороших программистов, а затем пьют пиво и пишут в свое удовольствие патчи для KDE под FreeBSD:)
А если серьезно, то все зависит от специфики работы, если программистов требуется достаточно много, загрузка постоянная, а времени мало (аутсорсинг какой-нибудь или бухалтерская рутина), то хочешь-не хочешь наберешь «плохих» и будешь от них плясать; а вот если это небольшой экспериментальный стартап, то «хороший» программист может оказаться и среди основателей.
Насчет первого абзаца 😉 Один раз «запрограммировать» фирму не возможно. А те, кто умеют масимизировать прибыль — обычно называются бизнесмены 🙂
Насчет второго абзаца — согласен. Собственно говоря, это то, что я писал — в маленьких фирмах еще можно обойтись без плохих программистов. В больших — уже никак.
Никогда не понимал бизнеса исключительно с целью поднять бабла. Неинтересно это. Надо делать качественный продукт, чтобы получать удовлетворение от результата деятельности в целом, а не только от финансовой его составляющей…
Отлично 🙂 Но продукт можно и опенсорс делать, и даже качественный.
А единственной, основной и важнейшей целью бизнеса есть ПОДНЯТЬ БАБЛА. Это первой строкой в уставе любого ООО пишут 🙂
> Отлично Но продукт можно и опенсорс делать, и даже качественный.
Если ты имел в виду разработку на общественных началах (опенсорс тоже коммерческий бывает, если что), то мы опять приходим к тому, что надо где-то зарабатывать деньги. Я считаю, что лучше совмещать это с производством качественного продукта. Пусть деньги будут меньшие, зато общая отдача гораздо больше.
Опять таки, можно бизнес-процесс построить таким образом, чтобы делать качественный продукт было выгодно (но это я уже чисто теоретизирую).
Я с подозрением отношусь к free software с закрытыми исходниками, использую его только по необходимости.
Обратное же, «коммерческий opensource», происходит, насколько я могу видеть, от неумения сделать мало-мальски защищенный софт 🙂 Продавать то, что можно собрать самому — не абсурдно ли? Не говорите про заработок на поддержке и внедрении, это другое.
«Лучше совмещать с производством качественного продукта…» Скажите это дяде Биллу.
Надо зарабатывать деньги. Они так и зарабатываются. На продуктах с качеством, достаточным для использования в качестве товара, и не более того — ибо нерентабельно. Ну а в свободное время, конечно, можно что-то свободное же и ваять. Если желание есть.
На 99% поддерживаю Автоматизатора.
Ключевая цель бизнеса — это поднять бабла. Остальные цели — приятное дополнение к ним, но не более того.
Если программист просто хочет интересный проект — то можно спокойно найти какую-нибудь готовую фирму в которую наняться и работать и не морочить себе голову бизнес проблемами.
Оно так. Однако, по нынешним временам, фирмы имеют свойство терять источники финансирования, и я даже при небольшом круге знакомых вижу это не в единичном случае.
А не морочить себе голову бизнес-проблемами реально только на зарплате, чисто как шабашник — поработал над интересным проектом, свалил на другой… Такое имеет место быть. Хорошо или нет — черт его знает.
Ну и наконец, в полной мере насладиться интересным проектом можно, только будучи его единственным автором… или архитектором 🙂 Для самолюбия многих Программистов будет ударом то, что они на это не способны.
>Однако, по нынешним временам, фирмы имеют свойство терять источники >финансирования,
Это фактически всегда так. Да, когда все на подъеме деньги найти и получить легче, но все равно что-то типа 80% фирму умирают в течении 1 года и 80% из оставшихся в течении следующих 4 лет.
Ключевой пункт — нехватка денег.
Как всегда приятно почитать, респект автору за отличный пост))
»
Подозреваю, что действительно хорошие программисты за зарплату не РАБотают, ни за 4к ни за 16к, а один раз программируют структуру фирмы под максимизацию прибыли, нанимают хороших манагеров и не очень хороших программистов, а затем пьют пиво и пишут в свое удовольствие патчи для KDE под FreeBSD:)
»
Очень даже импонирует, а то большинство процессов тех. цепочки — «ручные».
А есть примеры в реальности, которые почти около , что в цитате?
То есть разработал — внедрил- а далее только поддержка. Ну и рестракт , от него никто не изолирован. Но всё же, чтобы доделка не приводила к созданию с нул.
…А, да , моно обозвать мою тех. цепочку — «Геодезическое обеспечение стоительства» 🙂 😉 В)
\\
…Я не пью и не курю, просто прёт, так прёт. От 3х до 5ти килограмм словесно-печатного поноса.
Зато таааа-ак играю в комтуперные игры , хе-хекс.
Еще о программистах и заказчиках
http://blognot.name/archives/106