9 параметров хорошего работника.

Январь 23rd, 2009

— Ум

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

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

—  Увлеченность

Я бы сказал, что этот параметр состоит из двух подпараметров, я специально не хочу их разделять на отдельные верхнеуровневые, так как они очень тесно связанны. Страстность для меня значит — заинтересованность и активность.

Заинтересованность побуждает человека учиться чему-то новому. А активность позволяет человеку активно делать то, что он уже знает.

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

— Мотивированность

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

Ну и мотивированность включает в себя увлеченность. Но увлеченность не обязательно включает в себя мотивированность.

— Честность

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

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

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

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

— Опыт

Это в целом гораздо легче определить, чем ум. Это как раз то, что пишут в резюме: где работал, сколько работал,  где учился и т.п.

Это фактически единственный из всех параметров, который изменяется по ходу жизни.

— Коммуникативность

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

—  Лидерство

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

Как точно замечено Yurich, высокое значение этого параметра нужно не всем хорошим работникам.

— Рискованность

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

Вот такие вот параметры… Что еще можно сюда добавить?

— Трудолюбие

Важный параметр, но с двумя подводными камнями.

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

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

Posted in Мысли вслух | 61 комментарий »

Программист vs QC

Январь 15th, 2009

В нескольких статья меня пнули ногой (и правильно), что я путаю QA и QC. Ну, слава богу, уже разобрался.

Хотя как показала практика, не один я такой. В Google ищем «QA engineer» — получаем 1M результатов, «QC engineer» — 200k. Судя по всему, большинство таки людей хотя сказать QC используют QA.

Но, я собственного говоря не об этом. Я совсем о другом.
Почему-то в последнее время повеяла такая мода программистам побольше QC задач подкидывать и пытаться размыть границу между программистами и QC engineer (я дальше буду писать тестировщиком, хотя это и не идеально выражает то, что делают QC engineer’ы).

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

Или например, в Scrum, есть попытка ввести понятие Team member, без разделения на программиста и тестировщика. И типа, что нужно то и делай для окончания задачи.

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

а) Разделение труда

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

б) Квалификация

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

Само по себе это ничего не значит, но влияет на следующий пункт.

в) Стоимость работы

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

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

г) Односторонняя взаимозаменяемость

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

В обратную сторону, тестировщик чаще всего либо не может программировать вообще, либо является очень слабым программистом.

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

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

Никаких супер привелегий у них нету, просто они делают работу которую тестировщик не умеет делать.

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

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

Дописал большой P.S.
Дисскусия в нескольких ветках упала в сторону, кто быстрее выучиться программист — тестировщиком или тестировщик программистом.

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

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

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

Возьмем двух человек
а) Хорошего программиста
б) Хорошего тестировщика

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

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

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

Таким образом, когда программиста нужно обучить тестированию, то по большему счету ему нужно углубить свои знания в
а) Стресс тестировании
б) Почитать несколько книг по планированию тестирования
в) Поменять мышление, для того, мыслить не с точки зрения «вот, что надо сделать, чтобы оно работало» а на «вот, что надо сделать, чтобы оно НЕ работало».
г) Изучить некоторое количество инструментов для тестирования
д) Потестировать, чтобы разобраться что правильно, а что неправильно

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

Теперь тестировщику нужно обучиться программированию.
И вот тут база оказывается достаточно большой
а) Изучить основы программирования
б) Изучить язык программирования
в) Изучить API операционной системы/browser/базы данных
г) Изучить инструменты для программирования
д) Изучить такие вещи как ООП
е) Пописать программы, чтобы понять, что правильно, а что неправильно

То есть база знаний больше. А знание основ этой базы у тестировщика меньше.

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

Уже через неделю программист может выполнять простые элементы тестирования на __РЕАЛЬНЫХ__ (это ключевое слово) проектах.

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

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

Posted in Инфраструктура | 94 комментария »

Корпоративная культура (часть вторая).

Январь 11th, 2009

Когда-то я писал статью уже о корпоративной культуре (КК). Пока, все еще, актуальна, хотя немножко мой взгляд уже изменился.

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

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

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

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

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

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

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

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

С другой стороны, находясь в стабильном состоянии, можно о ней не беспокоиться, а оставить ее и она вероятнее всего «отразит» нападки снаружи.

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

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

Posted in Менеджмент, Мысли вслух | 15 комментариев »

Вера в лидеров и бабки.

Январь 4th, 2009

И еще одна из незаконченных статей.

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

Так вот, по поводу этого, у меня пару «за» и пару «против».

Начну очень издалека.

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

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

Теперь прыгаем к примеру с продавшицой. Пусть есть магазин в котором объем продаж $5k-$10k и в нем сидит продавщица, которая «отрываясь» на клиентах отбивает их от магазина и приближает продажи ближе к $5, а не отрываясь она приближает их к $10k. У нее же самой ЗП, может быть вполне $200. Стоит ли ей платить больше (есть на рынки именно такие цены). Я бы сказал, стоит если она старается, если же она требует это пытаясь держать вас в заложниках того, что ваша прибыль упадет на $5k, то ее надо гнать в шею, как того работника который просил повысить ЗП, чтобы он не работал плохо.

Смотрим дальше, предположим из-за ново нанятой продавщины, просто отбоя в магазине нету, вероятнее всего ей можно и $500k и $1k поставить зарплату (гораздо выше средней по рынке), если продажи зашкалили за $15k.

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

А теперь, какое это к черту имеет все отношению к лидерам?

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

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

Еще дальше возвращаясь, к статье Макса. Так вот, с чем я НЕ согласен, что роль лидера преувеличена. Да, CEO не решает все в компании (как Макс писал, статистически 10% успехов компании может быть отнесены к действиям CEO). С другой стороны, если 10% успехов увеличивают в 10 раз прибыль, то можно и в раза два зарплату им выше держать.

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

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

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

Posted in Деньги, Менеджмент, Мысли вслух, О большом и малом | 25 комментариев »

« Older Entries
Newer Entries »