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

Зацениваем программиста.

Понедельник, Май 26th, 2008

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

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

— Наличие мозга

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

— Понимание архитектуры и хорошего vs. плохого кода

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

— Знание платформы

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

— Знание языка программирования

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

Это был технический список, а вот личностный

— Мотивированный

В общем-то мне все равно чем человек мотивирован. То ли ему интересно, то ли ему хочется заработать на мерседес, то ли он трудоголик. Главное, чтобы человек приходил на работу и хотел что-то делать.

— Умение работать самому

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

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

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

— Умение работать в команде

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

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

Есть желание чего-нибудь добавить либо отнять от этого списка?

P.S. Кстати, сейчас у меня три метода доставки блога есть — RSS, email и livejournal. Есть еще какие-нибудь методы, которые упростили бы вам жизнь (в смысле получение блога)?

Застрявшие мозги

Пятница, Май 23rd, 2008

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

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

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

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

Мдя… Так вот. Будучи в бизнесе или даже просто в менеджменте, перед тем как оценивать человека, стоит учесть не только весь период знакомства, но умножить на три, последний год. Ясно, что плохие привычки остаются, но все таки, люди меняются и, как по мне, очень легко ошибиться путая Васю из вчера и Васю из сегодня.

Двойной стандарт.

Среда, Май 21st, 2008

Что меня очень напрягает — это двойные стандарты.

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

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

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

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

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

Кстати, ссылки на пару моих старых статей, которые мне нравятся и которые
публиковал тогда, когда людей в блоге было меньше:

Закон всемирного тяготения.

Кому хорошо живется от плохих estimat’ов

Нафига козлу баян

Что важнее для компанни, деньги или драйв.

P.S. Мне ОЧЕНЬ понравилась статья про инфляцию IT в блоге СОТОНА. И вообще блог очень-очень достойный. Почитайте.

И еще раз о амнезии (часть вторая). Буква закона vs. Дух закона.

Воскресенье, Май 11th, 2008

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

В этой статье не буду писать никаких решений, а только буду бить по больным местам… э… пожалуй, только по больным местам этой темы.

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

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

б) Запись знаний, чаще всего низкий приоритет в системе ценностей человека. И поэтому, когда встает выбор – разгребать текущие проблемы или создавать «нетленку» 🙂, то чаще всего начинают разгребать именно текущее дела.

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

в) Нужно ли заставлять подчиненного писать свои знания или делать остальную часть работы. Опять же возникает конфликт приоритетов.

Потребитель знаний:

г) Почему собственно нужно читать чьи-то ошибки, сделанные непонятно когда и кем и пытаться понять какие-то решения, принятые людьми, которые уже не работают в фирме?

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

Ну, и с точки зрения компания, проблемы следующие

е) Что делать с людьми, которые не хотят сохранять знания, особенно если они ими обладают. Должно ли стать это требованиям к работе. Что делать с теми, кто не хочет изучать знания?

ж) Какова приоритетность записи и изучения знаний? Это нужно для того, чтобы менеджеры могли выставлять приоритеты рабочим

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

Д) Самое главное, как сделать весь этот проект прибыльным?

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

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

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

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

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

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

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

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

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

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

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