Нужны ли компаниям талантливые программисты?
Для начала возьмем такую четкую, формализованную цепочку:
-
Программист, пишет код и ничего его больше не интересует.
-
Тестировщик берет код у программиста и тестирует его, в случае ошибок, возвращает код на исправление.
-
Менеджер по продажам берет у тестера готовый дистрибутив и продает его клиенту.
-
Клиент использует программу, и в случае проблем с программой обращается в службу технической поддержки.
-
Техническая поддержка работает только с клиентом, отвечает на его вопросы, и плевать им на остальные отделы. Пожелания отправляет программистам.
Пока так, без усложнений. Все занимаются своим основным делом, и не общаются друг с другом через отдел, например, менеджер по продажам с программистами не общается, а только с клиентами. Цепочка однонаправленная. Посчитаем, что получается. Пусть средний программист НЕ допускает ошибку с вероятностью 0,5. Обычный средний тестировщик найдет эту ошибку с вероятностью 0,5. Менеджер сможет продать клиенту программу с вероятностью 0,5 (хотя, наверное, это очень высокая вероятность). В итоге у клиента окажется на руках наша «глюкавая» программа с нашей искомой ошибкой с вероятностью 0,5*0,5*0,5=0,125. Клиент может НЕ наткнуться на ошибку в программе в среднем, ну пусть, тоже с вероятностью 0,5. И, соответственно, техническая поддержка поможет клиенту пофиксить ошибку с вероятностью 0,5. Тогда вопрос с первоначально возникшей ошибкой у первого звена (программиста) будет решен с вероятностью 0,125*0,5*0,5=0,03125. Не придирайтесь к цифрам- они нужны как начальная точка для рассуждений. Вот эта вероятность 0,03125- она является мерой того, насколько клиент будет раздражен нашей ошибкой. Здесь 0- клиент в бешенстве, 1- клиент абсолютно доволен. Соответственно, если клиент раздражен, он всем скажет, что программа плохая, никто ее не купит больше и т.д. В общем, 0,03125- это мера успешности компании. Т.е. это то, к чему мы стремимся- успешности компании через производство качественного, радующего покупателей программного продукта. Получается, что, если полученный коэффициент равен 1, то компания успешна, если 0- неуспешна.
Возьмем теперь две крайности. На работу взяли тупого программиста, который не допустит ошибки в программе с вероятностью 0,1. Получается, что вероятность успешности компании, при всех остальных неизменных параметрах равна 0,1*0,5*0,5*0,5*0,5=0,00625.
Другая крайность- талантливый программист с вероятностью недопускания ошибки 0,9. Получается 0,05625. Разница между тупым и талантливым- 11% составила. С одной стороны здорово, но с другой стороны максимум успешности равен 1. А мы за счет таланта программиста добавили в копилку успешности только (0,05625-0,00625)=0,05 единиц, т.е. 5%.
Вы уже сообразили, к чему я клоню? «Догнать» уровень успешности до значений, близких к максимумам, можно, улучшив работу тестировщиков, менеджеров по продажам, технической поддержки. И в совокупности, это позволит нам достичь 0,99 единиц успешности. 0,01- это клиенту «на погоны», ведь он тоже в цепочку включен. В данной формуле успешность определяется самым слабым звеном. Возьмите лучших тестеров, менеджеров, саппорт- по 1 единице вероятности им дайте. Но если будет тупой программист с его 0,1 единицами, то в итоге успешность компании не превысит 0,1.
Какие выводы можно сделать? Компания для повышения вероятности своей успешности должна набирать в штат не только талантливых программистов, но и остальной персонал должен блистать талантами. Только так.
Тривиальный вывод, правда? И как это может помочь нам, программистам, и вообще ITшникам? Первое, что напрашивается, и без этих расчетов- это при трудоустройстве оценивать как с вами кадровики общаются. Ведь в успешной компании все должно быть на высоком уровне. И если вам с порога хамит охранник, игнорирует кадровик, решая свои вопросы и т.д., то наверняка в компании что-то не так. Цепочка бизнес-процессов где-то дает слабину, а, значит, уменьшает вероятность того, что компания окажется успешной.
Однако жизнь куда как заковыристей, чем описанная выше формализованная модель. Программисты знают не один адрес сайта с черными списками работодателей. При этом предприятия из этих списков не разоряются, а очень неплохо себя чувствуют, хотя точно хороших программистов им к себе не заманить. Так как же выживают такие предприятия? Ведь, согласно представленной выше модели, звено «программист» на таком «черносписочном» предприятии получит коэффициент ближе к нулю, а значит и успешность предприятия будет низкая.
Данная модель будет описывать подобные случаи, если ввести коэффициенты значимости для каждого звена. Предлагаю такой вариант формулы: (x+k)/2, где x- вышеописываемые вероятности допускания соответствующими отделами ошибок, k- коэффициент значимости работы отдела для получения конечного результата, т.е. для повышения вероятности успешности компании. Пусть значимость отдела программистов оценивается в 0,5. Тогда, если брать тупых программистов (вероятность НЕ допускания ими ошибки равна 0,1), то значимость качественной работы программистов на конечный результат составит (0,1+0,5)/2=0,3. Соответственно, для талантливых программистов (0,9 вероятность) получаем (0,9+0,5)/2=0,7. Выводы: если работа отдела не сильно сказывается на конечном результате, то таланты не смогут внести существенного вклада в проект, и, соответственно, тупицы тоже особо ничего не испортят. Вот сравните: разница между тупыми и талантами составляет 0,9/0,1=9 раз, а на конечном результате разница видна всего в 0,7/0,3=2,3 раза. Такая ситуация реальна, и часто встречается в «карманных» конторах или предприятиях, стоящих у какой-либо крупной «кормушки». Для таких предприятий важнее не талант программиста, а хорошие менеджеры со связями. Часто внутри таких предприятий атмосфера стоит склочная, начальство прислушивается к менеджерами (ведь они кормильцы предприятия, получается), а те все свои ошибки визгливо валят на программистов, тех в очередной раз называют бездельниками и закручивают гайки (Интернет отбирают, контролируют опоздания и уходы с работы и т.п.).
Итоговая формула получается такая:
,
Где K- вероятность успешности предприятия; i- кол-во отделов, плюс заказчик; k- вероятность безошибочной работы соответствующего отдела; a- коэффициент значимости отдела для компании или, по-другому, насколько вероятно то, что ошибка, допущенная отделом, скажется на конечном результате. Если у нас 5 отделов (см. рисунок 1), то вместе с заказчиком у нас получается 10 переменных с формуле. И только одна переменная, вероятность НЕ допускания ошибки программистом, напрямую зависит от программиста, от его таланта. И чем крупнее предприятие, тем менее заметно влияние таланта программиста на конечный результат компании. Даже в такой простой вышеприведенной схеме талант программиста уже незначителен для конечного результата: предприятие может быть успешным с довольно высокой вероятностью и без талантов, опираясь на «середнячков». Ясно, что любой здравый руководитель предпочтет нанять середнячка и платить ему меньше, чем нанять дорогущего таланта и, практически, не видеть его вклада в конечный продукт (прирост вероятности успешности предприятия будет совсем небольшим, не оправдывающим денег, вложенных в талант).
Теперь можно делать более глобальные выводы, кроме того, что кадровики должны быть с вами обходительны:
-
Чем крупнее компания, тем меньшую значимость для компании будет иметь каждый талантливый программист в отдельности. Для компании, практически с тем же результатом, дешевле будет нанять середнячков, чем талантов. Любой талант в такой компании будет со временем «причесан» под общую гребенку- его способности не будут востребованы и он отупеет до общего уровня.
-
В маленьких компаниях отделов меньше, людей меньше, поэтому важность каждого человека высока. Компания заинтересована нанять таланта и удерживать его всевозможными бонусами.
-
«Карманные» и «прикормленные» компании равнодушны к талантам- там их труд практически не сказывается на конечном результате.
Итог: Идеальная компания для программиста- небольшая, с отличными специалистами во всех отделах (вплоть до уборщицы), дружелюбными, профессиональными.
Что же получается тогда? Какая бы ни была компания внешне дружественная к программистам, активно зазывающая к себе, создающая блага, но если компания большая, то предложенная формула приводит нас к печальному выводу: «Талантливому программисту там делать нечего». И, наоборот, внешне непривлекательная небольшая компания может стать настоящей отдушиной для таланта, где он может раскрыться по максимуму.
Остается упомянуть о еще нескольких моментах. Первое, умные большие компании, ощутив на себе «смертельное дыхание» данной формулы, формируют из предприятия холдинг, состоящий из маленьких предприятий, ведущих самостоятельную деятельность. Это неплохо, но часто из управляющей компании холдинга прямо таки веет тупизной, бюрократизмом и предприятия холдинга ощущают это на себе. Периодические набеги руководства холдинга не дают расслабиться, и талантам там все же несколько неуютно. И второй момент, я не учитывал в формуле наличие босса, через которого формируются более сложные связи между отделами.
Оценивая формулу, я вижу, что на ее основе можно развить методологию оценки эффективности деятельности предприятия, притом основанную на количественных показателях деятельности организации. Хммм, вплоть до того, что можно осуществить мечту любого начальника: на экране компьютера кривая, которая в реальном времени показывается эффективность предприятия.
Однако, пора уж закругляться, а то так и до планирования мировой экономики договориться можно!
Ярлыки: производство

Комментарии: 10:
C выводом хочется согласиться, а вот эвристика вызывает недоверие. Есть ещё один важный фактор, кроме не совершения ошибки - производительность. Можно не ошибаться, но при этом ничего не делать.
Судя по всему, вы очень любите считать, но все эти расчеты рассыпаются, когда вы говорите про программистов, рисуете свою модель и упоминаете предприятие.
ИТ-шники водятся в ИТ компаниях и в разных не ИТ компаниях, и это две очень очень большие разницы, которых для вас видимо нет.
В действующих сегодня успешных ИТ компаниях занимающихся производством программных продуктов подбор и взращивание квалифицированных кадров программистов это не тот вопрос которым пренебрегают, кроме этого существует иерархия роста программиста, от кодера до бизнес аналитика и менеджера проекта, в известных мне ИТ компаниях никто не доверяет управление дорогими ресурсами - разработчиками, некомпетентным людям самим не прошедшим эту лестницу, тем более выпускникам непонятных курсов и факультетов "по управлению всего и вся"
И совсем другая ситуация в компаниях, для которых ИТ - это только обслуживание, но и там ошибка или просчет ИТ-специалиста часто слишком дорого может обойтись , чтобы пренебрегать качеством нанимаемого сотрудника.
Не так все просто. По моим наблюдениям разница между хорошим и плохим программистом невероятно велика.В двух словах это разница не только в личной производительности, но и в инфраструктурной нагрузке - на тестреров "снизу" и на менеджера "сверху", которая отличается на десятичный порядок. Я могу сказать, что один _хороший_ программист заменяет целый отдел из десятка плохих вместе с менеджером который ими рулит. И почему таким людям традиционно платят в полтора раза, а не в четыре, больше - я понять не могу. На своей прошлой работе мы одного из таких людей потеряли - хотя я и говорил что не надо жалеть денег, чтобы его удержать. К счастью, я там тоже больше не работаю.
И это я еще оставил за кадром тот кошмар, который начинается при рефакторинге плохого кода или (о, ужас! ужас!) передаче этой части проекта другому программисту!
Любопытная модель. Только я бы в нес в нее поправку. То что вы называете мерой успешности компании, это, скорее, мера успешности проектной команды в рамках проекта. Маленькая компания отличается от большой тем, что в ней меньше проектов и успех каждого из них более критичен для компании. В принципе, вы так и сказали :).
Самое интересное начинается при определении "коэффициента важности отдела". Вы сочли, что каждый "отдел" (а, в реальности, мы говорим о ролях в проектных командах) вносит равный вклад в успех компании (проекта), а значит "в компании все должно быть прекрасно - и программист, и уборщица, и кадровик". Вот тут не согласен.
В каждой конкретной компании коэффициент значимости тех или иных ролей - существенно отличается. Вы правильно сказали, что талантливому программисту следует идти работать туда, где вклад "программистов" в общее дело наиболее существенен. Но это не означает маленькие компании. Размер тут не причем. Сейчас поясню примерами софтверных контор:).
Есть компания, которая пилит государственное бабло. Получает кучу денег за "якобы" автоматизацию и написание софта, но в реальности софт либо нигде не внедряется либо "успешно внедряется" но в реальности не работает. Тут вообще не важно какой уровень у программиста, важно - какой уровень у продавца - сумеет ли он "договорится" с чиновниками о распиле бабла.
Есть компания, которая развивает свое тиражное ПО для сегмента в которым есть конкуренция. Здесь очень важны маркетинг, контроль качества и техподдержка (чтобы люди были счастливы покупать этот софт у них, а не у конкурентов).
Есть компания, которая пишет заказное ПО, работая с заказчикам по fixed-price договорам. Тут важно сделать заявленные фичи в указанные сроки, а значит на первый план выходят разработчики и управленцы (project manager'ы).
Вот, имхо, как-то так.
Бывает что внутри софтверного монстра есть все эти направления. Бывает что в мелкой софтовой фирмочке разработчики не ценятся. IT depends. =)
Мысль о том, что искать лучше всего те места, где ваш личный вклад в общее дело будет максимальным - всячески поддерживаю.
Для начала соглашусь с выводами :)
Но не согласен с постулатами.
Во-первых в комментах правильно заметили на счет производительности и качества труда. (Тупой интерфейс это ошибка или нет?)
В-вторых: что-то я не уловил мысль с форумлой.
если программист пишет код с вероятностью не ошибки X, то после тестировщика эта вероятность не-ошибки будет Y. Причем Y будет больше или равна X (ошибка либо не найдена Y=X, либо найдена и предполагается исправленной, т.е. Y больше X) У вас же получается Y меньше X
т.е. если выкинуть группу тестировщиков, то после плохого программиста вероятность будет 0.1, а после хорошего 0.9
Да уж, методика расчетов действительно ужасна. Почему ни кто не замечает, что модель поставлена с ног на голову?
Вероятность того, что программист НЕ допустит ошибки, а тестировщик ее НАЙДЕТ... Что он найдет - то? Несуществующую ошибку?
Наоборот надо считать, программист ошибку ДОПУСТИТ, а тестер ее НЕ ОБНАРУЖИТ. Цифры в итоге получаются те же, вот только 0 при этом соответствуют идеальные условия, а 1 - бешенство.
А в таких условиях разница между 0.05625 и 0.00625 уже более чувствительна, т.к. во втором случае мера эффективности в 9 раз выше!
Ну и еще, если тестер найдет ошибку, то плохой программист при ее исправлении может и новых наделать, так что самого обнаружения недостаточно, нужно и вероятность ее корректного исправления программистом учесть, а тогда зависимость от качества программиста уже квадратичная получается:
0.1*0.5*0.1*0.5*0.5*0.5 = 0.000625
0.9*0.5*0.9*0.5*0.5*0.5 = 0.050625
Да, абсолютная разница по прежнему только в 5%, но относительная - в 81 раз!
Как вы думаете, если у каждого 20 клиента будут возникать проблемы, которые не может решить служба поддержки (кстати, каким образом она вообще исправляет ошибки программиста?), будут ли менеджеры и дальше продавать с вероятностью 0.5, или она будет стремиться к 0?
Спасибо за комментарии, поясню момент с вероятность НЕ допущения программистом ошибки. Я долго решал, как записать формулу- допущение или не допущения. Если брать допущение, то получается, что чем выше значение, тем хуже код. С другой стороны, у всех остальных отделов чем выше число, тем лучше (тестер вероятнее всего отловит ошибку и т.д.) конечный результат работы отдела. Т.е. оценка программиста получается по противоположной шкале, чем оценка всех остальных отделов. Чтобы получить однозначный показатель 0- плохо, 1- хорошо я инвертировал систему оценки программиста на НЕ допущение ошибки. При этом логика не меняется. Ведь то, что он с некоторой вероятностью не допускает ошибки, не означает, что их нет. Тестеру от программиста их достанется (1-x), где x- вероятность НЕ допущения ошибки программистом.
Про производительность. Несомненно, важный показатель, но мне неизвестно ни одной формулы для оценки производительности программиста. Неявно в статье предполагается равномерная нагрузка на программиста (т.е. как написано в статье, упрощенная формализованная модель).
С выводами в основном согласен.
С математикой, там что-то не так...
Честно говоря начал где-то к четвертому абзацу перепрыгивать ее глазами. Но мне кажется, что там перевернуты "НЕ" в каких-то местах (я видел, что вы об этом писали в комментариях).
Кстати, все время говорится о одной ошибки. Но плохой программист их сделает 1000, а хороший 10. Это пожалуй и даст результат больше чем 5% на выходе.
Но действительно в крупных компаниях (скажем 500+ программистов) , все равно программист толковый или нет, так как один программист на их объемах не играет никакой роли.
По-моему, система учета качества работы очень хромает.
Тут говорится о том, что плохой программист допускает ошибки, а хороший - нет. Но сам по себе ошибка - это дело 10, ее исправили и все, программа работает. А что будет, если разработчик, например, выберет неверную архитектуру, потом напишет целую кучу заплаток, потому что будет масса ошибок. Правильно, система просто развалится и даже при всем таланте тестировщиков им нечего будет тестировать, а менеджерам нечего будет показывать клиентам
Отправить комментарий
<< Главная страница