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

Но, я собственно не о том. Меня смешат три вещи в их письмах

а) Письма не по теме.

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

б) Письма о том, что должность находится за тридевять земель.

Условно говоря, когда предлагают позицию скажем Team Lead на Аляске. Это конечно прекрасно, но опять же в резюме четко написано, что переезжать я не собираюсь.

в) Письма без указания ценового диапазона.

Это пожалуй уже скорее бесит, чем смешит. Приходит, список требований длинной в страницу с кучей пунктов где нужен опыт 10+ лет и т.п.

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

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

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

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

Дошли руки разгрести рсс и вот, хочу сказать спасибо за интересные темы (дальнобойщики и делегирование) и тоже хочу задать пару вопросов-тем.
1. Слабомотивированные сотрудники, за которыми нужен постоянный контроль: смириться или избавляться от таких? Или может есть способ мотивировать?
2. Часто слышу в последнее время от айтишников в украинском аутсорсе: “Мне уже полгода (год/полтора) года не повышали зарплату (или повышали всего на 50 баксов). Что за дела?! Кризис-то уже закончился!”. И чуть-что такие люди валят в другую контору, где дали немногим больше.
А какая ситуация с зп в америке, так ли просто люди меняют работу при небольшой разнице? И так ли часто происходит пересмотр зп сотрудников?

Пройдется по пунктам.

а) Что делать с слабомотивированными сотрудниками.

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

У меня есть две методики в запасе, как решать эту проблему. Зависит от типа руководства.

Если метод руководства диктаторский, то все делается в три шага
Шаг 1: замечание (Вася, что-то ты в последнее время много пинаешь, а может пора поработать)
Шаг 2: предупреждение (Вася, я уже с тобой говорил, а ты все продолжаешь пинать. У тебя осталось X недель, чтобы это перестать делать.
Шаг 3: увольнение (Спасибо Вася, хорошо поработали, можешь на работу больше не приходить).

Если метод руководства добрый и ласковый, то тоже делаем в три шага
Шаг 1: пытаемся понять (Вася, у тебя все ok? Может что-то произошло? Я могу чем-то помочь)
Шаг 2: пытаемся разворушить (Вася, какими задачами ты хотел бы заняться? Вот тебе новые, интересные задачи)
Шаг 3: увольнение (Спасибо Вася, ты бесценный сотрудник, но мы вынуждены прекратить сотрудничество).

Естественно, в идеальном случае, мы смешиваем эти две методики. То есть пытаемся понять человека (может есть внешние __временные__ обстоятельства). Слово временные – ключевое, так как если они постоянные, то пожалуй можно таки перейти на шаг 3. Заодно, пытаясь разобраться вы даете человеку знак, что что-то идет не так.

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

В целом, если таки сотрудника не удается мотивировать, то в большинстве случаев его лучше уволить.

2) По поводу повышения зарплат и прыгания по конторам

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

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

В США рынок более сложившийся. Например в Вирджинии минимальная ЗП программиста будет $60K (только что из универа), максимальная $140k (когда пальцы уже просто веером нереально). Получается разброс всего в 2.3 раза. И покрывается большая часть этого зазора в буквально несколько переходов с работы на работу.

В exUSSR вполне можно стартовать с $300 и добраться до $2.4k. То есть разница в 8 раз и прыжков нужно гораздо больше.

Пересмотр зарплаты в обычной ситуации в штатах происходит раз в год. Чаще всего (для обычных работников), повышение идет на буквально несколько процентов 3-5%.

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

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

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

В целом есть три направления, в которых надо двигаться.

а) Контракт с заказчиком

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

б) Нормальные отношения с своими подчиненными.

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

в) Компания (как посредник) должна быть полезна для заказчика.

Вот этот пункт достаточно сложны. Чаще всего все IT компании, которые делают проекты фактически предоставляют услуги, которые составляют 100% их пользы. Чаще всего нету особо дорогого оборудования, которые отделившиеся программисты не смогли бы себе позволить.

Одна из хороших идей, лицензирование им (даже за бесплатно) какие-то из своих библиотек. Эта та самая Intellectual Property, которая будет являться дополнительной пользой.

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

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

Ну, по ходу,  мне стало интересно, как они работают. Кое что у них поспрашивал – выяснилась следующая картина.

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

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

- В третьих, самое ключевое, за счет чего они работают – это объемы. Сидят 5-6 молодых людей и девушек весь день на телефоне, обзванивают заказчиков и программистов и сводят воедино. Каждый делает скажем 15 звонков в день, и где-то 10% из них ведут к заинтересованности. Дальше проводят собеседования, пытаются подобрать кандидатуры.

В целом, никакой магии, просто работа с большим количеством народа.

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

Кстати, понравилась статейка по поводу работу в крупных конторах.

- организация совещаний

- соотношение менеджеров и исполнителей

- американский миф о команде

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

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

А теперь быстренько по пунктам, что нужно для толкового совещания:

а) Длительность митинга должна быть обозначена заранее.

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

Кстати, оба этих пункта озвучиваются и до митинга и повторяются в самом начале митинга.

в)Должен быть координатор совещания.

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

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

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

Усе… Этого достаточно, чтобы совещания не были местом спячки и разгребания накопившейся непрочитанной почты, а местом где собираются, чтобы делать что-то полезное.

Слава богу, что в IT на территории exUSSR пока не сильно прижился этот американский стандарт.

Второе, что я хотел сказать – это соотношение менеджмента и  исполнителей. Кстати, оказалось я об этом уже говорил тут. Хотя со мной и не согласились, но я считаю, что у чистого менеджера не должно быть больше чем 7 прямых подчиненных, но и меньше чем 4-5 тоже не должно быть. Как только вы обнаруживаете, что у вас 4 программиста, 3 тестировщика, 1 project manager и 2 product manager, 1 director, 1 CEO, 1 CFO, 1 CTO и т.п., то значит в королевстве датском, не все в порядка, так как общее соотношение по фирме выходит один исполнитель к одному менеджеру. Чаще всего этим болеют молодые компании, которым ну оооочень хочется, выглядеть большими и серьезными. Но, чаще всего, это проходит, как только становится видно что деньги утекают с какой-то сумасшедшей скоростью.

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

Так вот, там я в куче мест указал, что подчиненных у каждого должно быть от 1 до N. И нигде не указал, сколько же должно быть это N.

Так вот количество подчиненных для фирмы больше 10 человек должно выглядеть так
а) Ноль, для тех кто делает конечную работу и Developer, QA, Sales сидящий на телефоне
б) От одного до трех, для того, кто все еще делает конечную работу, но еще и должен руководить
кем-то (из-за того, что он более опытный). Например Dev Team Lead или QA Test Lead
в) От четырех до семи, для тех кто не делает конечной работы и только управляют (например Project manager, director).

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

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

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

Особенно меня радует, когда в разумно небольшой фирме образуется целая пачка людей а-ля – product manager’ов, VP чего-то там, маркетологов. Как то обычно, они множатся очень быстро, а уходят из фирмы очень медленно. (Для ясности – эти позиции нужны, но вероятнее всего в гораздо меньших количествах).

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

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

И вот, собственно, смирившись с невозможность победить в 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%).

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

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

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

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

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

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

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

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

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

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

Хороший программист – тот кто решает проблему и заодно предвидит/предотвращает будущие возможные проблемы.

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

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

Что вы скажете человеку, который будет вскапывать огород размером в 500 гектар с помощью лопаты?

Давайте угадаю с трех раз… Вы скажете, что это…м…. не лучшая идея.

И что нужно:

а) Добавить новые и более мощные инструменты

б) Добавить новые и более мощные знания как управляться с инструментами

в) Добавить людей на тех задачах с которыми тяжко справиться самому

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

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

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

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

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

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

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

Так, что я за то, чтобы устанавливать разумные правило (особенно с ростом компании), я за то, чтобы пересматривать правила, если они не работают и я против того, когда говорят… Да не, мы лучше по старинке, дедовскими методами, лопатой и субъективным мнением будем менеджить компанию.

P.S. Кстати, небольшая рекламная пауза, про которую я забыл. Эти два сайта публикуют мои статьи, за что им большое человеческое спасибо.

Загляните на сайт KakRabota.com.ua. Он посвящен в первую очередь отзывам сотрудников и соискателей о различных компаниях Украины и России, сбору статистики зарплат в разрезе отделов. В разделе форума есть опубликованные вакансии и резюме с возможностью комментировать их или задавать вопросы а так же просто обсудить темы связанные с работой. А также на сайте есть блог разработчиков, на котором вы можете регулярно читать интересные статьи опять же на околорабочую тематику.

А второй сайт – это, сайт www.webdiktor.ru. Это забавный бесплатный сервис по озвучиванию статей. Они меня тоже посчитали и озвучили уже несколько статей вот тут. Так, что если есть люди, которые любят слушать статьи в стиле podcast’ов – заглядывайте туда почаще. Хотя, стиль начитывания статей слегка своеобразен.