Archive for the ‘Персонал’ Category

Программисты украли мой проект.

Среда, Ноябрь 11th, 2009

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

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

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

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

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

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

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

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

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

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

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

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

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

О том как работают местные(США) рекрутинговое агентство.

Четверг, Июнь 11th, 2009

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

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

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

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

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

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

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

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

Солянка сборная часть 3.

Четверг, Июнь 4th, 2009

Сегодня, у меня солянка сборная. На повестке дня три темы:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Если подчиненных больше N…

Среда, Февраль 11th, 2009

Когда-то я написал пост, про то, какой я вижу распределение должностей в компании.

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

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

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

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

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

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