Archive for the ‘Менеджмент’ Category

Деньги/мотивация/работа (продолжаем отвечать на вопросы телезрителей).

Понедельник, Март 22nd, 2010

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

А я сделаю все сам.

Среда, Март 10th, 2010

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

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

Вот что писал Young и Vitali.

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

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

Начну с несколько побочных вопросов, а дальше уже перейдем к делу. В той самой книге RTFM (которую я упоминал), был описан один забавный случай: Человек видит на обложке журнала фразу «Как стартовать свой бизнес без проблем?», купил журнал, открывает и видит большую надпись на весь разворот «НИКАК».

Так вот, относительно «который может работать без тебя».  Малый бизнес НЕ может работать без владельца. Максимально, на что можно надеяться, настроить его так, чтобы он мог проработать некоторое время (неделя, месяц, пол года). А все эти штучки-дрючку Киосакиевского разлива (а-ля создать себе пассивный источник дохода), можете выкинуть из головы прямо сейчас. (Кстати, вот мое мнение по поводу Киосаки).

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

Теперь возвращаясь к проблеме.

Думаю, очень многие думают примерно такие мысли «Я — эту задачу могу сделать быстрее, лучше чем любой кому я ее дам. Причем, если я кому-то ее  выдам, то мне придется за это еще заплатить, потом контролировать, чтобы все вышло как надо, объяснять как и что переделать, а зачастую по окончанию переделывать самом. Таким образом я больше времени потрачу на объяснения, контроль и переделки чем если сделаю это сам… Ура-ура… Я таки сам буду делать эту задачу.»

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

1. Я сделаю это задачу лучше чем другие (читай — выше качество и быстрее по времени, в целом эффективнее и дешевле)

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

3. Мне придется контролировать исполнение, давать задачи и просить отчеты ( выполнять нетипичную, плохо понятную и неприятную работу).

4.Я потрачу больше времени на объяснение, контроль и исправления чем сделать задачу самому (опять же — эффективнее).

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

1. Я сделаю это задачу лучше чем другие (читай — выше качество и быстрее по времени, в целом эффективнее)

Скажем у нас есть директор компании в 100 человек.  И он просто нереально крутой программист и может пофиксить баги быстрее всех.  Стоит ли ему НЕ ехать на подписание 10 миллионного контракта, а вместо этого очень эффективно пофиксить баги?

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

Слышу уже голос из зала «Но, блин, я же не директор компании на 100 человек и подписание контракта в 10M у меня сегодня нету. У меня нет стоимости потерянных возможностей». Так, вот, если все время фиксить баги и педалить код — стоимость ваших потерянных возможностей — это то, что вы никогда не найдете новых контрактов, не продадите ваш продукт, не станете директором этой самой компании из 100 человек. Вы же пишите код, а не разбираетесь в том, как продавать продукт/работаете с людьми, которые дадут отзывы на ваши услуги, ездите на встречи на которых может завязаться знакомство принесущее новый контракт. Вообще, усердное программирование один из самых потрясающих методов убить все потенциальные возможности.

Вообще, положа руку на область желудка, программирование в IT бизнесе имеет примерно такую же важность, как вождение грузовика в доставочном бизнесе. Да, без программистов (водителей) не обойдешься, но в результате sales и marketing рулят и бибикают.

Так что, может быть дать задачу человеку, который сделает ее чуть медленее, а в этот момент, доделать web site, написать документацию и попытаться найти покупателей, на ту байду, которая пишется?

4.Я потрачу больше времени на объяснение, контроль и исправления чем сделать задачу самому (опять же — эффективне).

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

Однако, тут важно остановится, положить руку на область желудка и признаться себе в двух вещах

— задачи с которыми знаком и которые нравятся обычно недооцениваются по времени

— задачи с которыми плохо знаком и которые не нравятся оцениваются слишком высоко.

Именно из этого и выходит, что-нибудь в виде: » … да я этот графический редактор я сам напишу за 2 дня, а вот если мне придется объяснять и контролировать, то у меня на это уйдет 2 недели».

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

3. Мне придется контролировать исполнение, давать задачи и просить отчеты ( выполнять нетипичную и неприятную работу).

Да — придется.  И к этому надо привыкнуть.

Бизнес — это не сладкая река в которой можно делать только то что хочется (педать сверхмощную архитектуру для никому не нужного проекта).

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

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

Такс… Много уже текста написал, а толком ничего не сказал.  Так, что перейду таки к пункту что делать.

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

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

Замечу, что фактически все руководители (включая меня) страдают тем, что один из этих пунктов выпадает.

Первая классическая ситуация (плохая подготовка задачи) — «Вася, пойди выкопай яму», потом обнаруживаем, что он выкопал ее не в том месте и не той глубины и не в те сроки.

Вторая классическая ситуация(плохой контроль в ключевых точках) — «Вася, яму надо выкопать метр, на метр, на метр, к следующему понедельнику (через неделю)».  Через неделю привозим цемент заливать в яму, а ямы-то и нету, так как Вася забухал. А мы не удосужились потратить 5 минут выглянуть из окна, как движется яма.

Третяя классическая ситуация: «Вася, яму надо выкопать метр, на метр, на метр, к следующему понедельнику (через неделю)». Пришли поглядели в четверг и в пятницу, что яма продвигается. В понедельник обо всем забыли, во вторник тоже и через где-то месяц навернувшись ночью в эту яму начали возмущаться… какого фига тут выкопана яма.

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

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

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

в) А как же вера в кадры?

Бытует такое мнение, что если ты держишь руку на пульсе — то значит не доверяешь. И типа, какого черта кого-то нанимать, если потом не доверять.

В общем, как говорится в пословице «доверяй, но проверяй».  Во первых, доверие должно вырастать из фактов, а не из желания верить. Только, если человек, сделал X раз все четко, качественно и выверено, то это значит, что в X+1 раз ему можно таки доверять. Все дипломы, регалии, хорошие отзывы и т.п. — вторичный признак и должны быть подтверждены фактами.

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

г) Делегирование больших задач

В какой-то момент от прямого делегирования а-ля «Вася — пойди выкопай яму», приходится переходить к «Петя — твоя задача организовать пяти Вась, чтобы они засадили двор яблонями».

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

По этому поводу несколько советов

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

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

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

— Четвертое, это то, что при делегирование больших задач, нужно проходить те же самые пункты, как при обычном делегировании.  Так как задача большая —  то важно поставить цели, объяснить, как эта  задача ложится в больший план (чтобы человек мог сам «доточить» задачу), разбить на этапы.  Дальше, поэтапно контролировать и в конце принять задачу.

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

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

С удовольствием отвечу на какие-то конкретные вопросы и приму замечания.

Корпоративное говно: дух времени

Понедельник, Февраль 22nd, 2010

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

В общем, преамбула совмещается с фабулой и будет многа букаф. Это скорее просто жалобы на тяжелую жизнь, но возможно тебе это знакомо. Короче говоря, у меня нас есть несколько тимов, каждый из которых пишет свой продукт и OEM тим, которые все эти продукты собирает, кастомизируют и раздают оем клиентам. Рулит этим тимом Configuration manager.

На прошлой неделе наш Configuration manager поднял плач Ярославны «как у нас все хуево с качеством, всем пиздец». Ну ок. В целом, я с ним согласен, но почему так получилось — вопрос интересный. Получилось так, что по целому ряду стратегических решений топ менеджмента, принятых год-полтора назад, стандартный подход — нахуй качество, надо рынок завоевывать, а остальное потом исправим. Ну, рынок завоевали, тока теперь на поддержание этой кучи говна в жизнеспособном состоянии тратятся огромные ресурсы, кастомизации под каждого клиента приходится приделывать болтами и сварочным аппаратом где-то сбоку.

Так вот, прошлонедельный плач был по поводу того, что тестеры из оем находят много багов, относящихся к самому продукту. И мы мол не знаем, что именно получает команда оем от команд продуктовых. Наш Configuration менеджер поднял дискуссию на высоком уровне и в итоге наш VP engineering’а произнес сакраментальную фразу: «А давайте померяем качество!»

Ну давайте. Встречный вопрос — а как мы будем мерять качество? Он грит, а хуй его знает. Вот пойдите, мои верные слуги, простите, менеджеры, и придумайте, как мы будем мерять качество. Мол, похоже QA хуево работают, но хер его знает. Мне изначально было все это похую, потому как я за qa не отвечаю и вообще это проблемы project manager’а.

В общем, как тут принято начинать работу над любым вопросом (хоть формы зеркала в сортире)? Правильно — соберем митинг. Пригласим всех ну или не всех. В общем, собрались мы митинговать — я, мой начальник, Configuration менеджер, директор инжениринг и прочая братия.

Project manager говорит — тебе нужно сказать, что ты как product manager хочешь сделать для измерения качества? Я говорю, охуенные заявочки. А ниче, шо инжениринг — это вы, а не я? Я вам как product manager могу тока сказать, что качество наверное хуевое, а как его мерять — это уже ваши дела. Померяйте и принесите. Они грят -а мы не знаем, как мерять качество. Вот если нам скажут, как мерять, мы померяем, и отчитаемся о проделанной работе.

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

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

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

Мне все это надоело, я пошел к моему боссу и говорю — вот такая хуйня. Я в жизни никогда qa не был, какие у них там метрики, методы и тд я понятия не имею. Он говорит, ладно, ну их всех нахуй. Раз никто нихера не знает, будем сами с тобой придумывать. Собрали очередной митинг. Вызвали все тех же танцоров.

Началось все уже привычно: А как нам померять качество? Я грю, ну самое простое, что приходит в голову — отсортировать тест кейсы по группам и собрать статистику по pass & fail. Все радостно закивали головами. Но тут вступил мой босс. Не, говорит, это все хорошо, но не люблю я эти тест кейс статистики. Вот когда я пишу acceptance criteria, я знаю, что это я написал и знаю, сколько они покрывают. а кто там писал ваши тест кейсы я не знаю, и как они написаны я тоже не знаю. Может они там покрывают 20% возможных use cases (надо заметить, у него есть основания так говорить). Давайте, говорит, лучше определим 10-20 основных функциональных областей (типа как epics), отдадим каждому члену команды на тестинг и послушаем выводы.

Тут вступает project manager: не, если программистов послушать, так у них все работает идеально, а если не работает, то это исключение и дурацкий юз кейс (что впрочем, тоже логично).

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

Я говорю, а как мы до этого релизили? На что следует ответ: ну так это же было неправильно! Мы же растем, мы должны знать, что мы релизим. Ок, отвечаю я, а как на счет того, чтобы мы сейчас неправильно отрелизили по старинке, не страдали хуйней, а по ходу следующих несколько недель я почитаю, подумаю, да и вообще что-то придумаем. Он на меня посмотрел так, как будто я лично признался в массовых убийствах христианских младенцев и сообщил: ТЫ ЧТО, ХОЧЕШЬ РЕЛИЗИТЬ, НЕ ЗНАЯ, ЧТО ТЫ РЕЛИЗИШЬ??? И ЭТО НЕ СГНАЛ ТРЕВОГИ ДЛЯ ТЕБЯ???

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

И теперь финишная прямая

Я написал письмо, отправил тимам с их инженерным менеджментом, а он — менеджмент тот — пришел ко мне и сказал: а мы че-то не поняли, в каком виде вы это хотите получить? @#$@#$@#$…. В виде процента по тест кейсам бля и личным соображениям бля. Хотя я думал, вы там что-то с QA придумаете. Ответ последовал ожидаемый: так а шо QA, они качество мерять не умеют. Как скажете, так и померяем.

Я устало махнул рукой, и сказал — ну вот пусть и меряют по своим тест кейсам.

Хороший или Гениальный программист.

Вторник, Январь 19th, 2010

Мысль из сегодня обсуждения… Плюс навеяно обсуждением книги Good to Great.

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

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

Слава богу, за свой опыт я не слишком часто с такими сталкивался 🙂

Так вот, о чем я задумался, это о том насколько они гениальны такие программисты, на самом деле.

Подведем простой математический расчет. Естественно все цифры взятые с потолка, если вам они не нравятся, подставьте свои.

а) Не ходить на работу и пользовать это время на программирование. (+10% дополнительного времени).

б) не писать документации (+5% дополнительного времени).

в) не обучать других программистов (+10% дополнительного времени)

г) не менеджить других программистов (+15% дополнительного времени)

д) отсутствие отчетности отчетности (+5% времени)

е) отсутствие необходимости согласовывать решения (+5% времени)

е) не присутствовать на всех митингах (+10% дополнительного времени)

д) отсутствие переключения между задачи (+30% эффективности).

е) отсутствие прерываний работы другими людьми (+30% эффективности)

Итого уже накапало 50% дополнительного времени и 60% увеличение эффективности. То бишь, продуктивность возросла в 2.4 раза. Думаю, если покопаться и выписать более полный список того, что НЕ делает гениальный программист, то вполне разность продуктивности может получаться и в 3-4 раза (отсюда и выходит, что хороший программист делает 3 месяца, а гениальный вадает за 4 недели).

А теперь на секунду остановитесь и задумайтесь. Хорошо ли для компании такое увеличение продуктивности в 4 раза? Если вы ответили «Да», то вам двойка в четверти по бизнесоведению 🙂

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

Есть такая штука «technical debt». Это когда написал код на скорую руку и решил, что потом его приведешь в божеский вид, но потом как-то не наступило и код продолжает пользоваться/изменяться/дополняться. С каждым днем его становится все сложнее поменять и все больше времени уходит на его поддержание. То есть мы сделали что-то быстрее взяв в долг, но долг не выплатили и него начали расти проценты.

Аналогично,  можно, ввести понятие «process debt», когда что-то делается без учета уже действующих правил (а-ля документирование, обучения людей и т.п.).  Взять такой долг на короткое время вполне можно, но постепенно он накапливается (остальные разработчики не знаю тех частей, которые написаны гениальным программистом, не возможно предсказать даты выпуска продукта, так как нету никакой отчетности, время поддержки кода растет из-за отсутствия документации, обсуждений по ходу разработки и т.п).

В целом, Гениальных программистов в Бабруйск, даешь хороших программистов.

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

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