|
|
 У каждого из нас есть друзья и знакомые и нередко бывает, когда один из ваших знакомых начинает искать работу, а у вас на работе есть соответствующая вакансия. Казалось бы, отличная возможность и знакомому помочь, и своему работодателю, но тут, как и везде, есть подводные камни. Эти подводные (некоторые даже из воды торчат) камни называются архипелаг ответственности за рекомендацию. Какую-то ответственность вы сами себе в голову вбиваете, какую-то вам навязывает будущий руководитель этого сотрудника. Да и наверняка многие из вас уже слышали фразы наподобие: “Ну и на хрена ты привел к нам этого долбоклюя?” Давайте по полочкам все разберем и выясним, какая же на самом деле ответственность за приведенного сотрудника.
- Ответственность за адекватность. Чаще всего эту ответственность вам навязывают, но в конце-то концов, вы же не один будете собеседовать кандидата, вот и предоставьте собеседующим самим решить, насколько он адекватен.
- Ответственность за профессиональные навыки. Эту ответственность вам тоже нередко навязывают, заодно и халтуря на собеседовании. Не поддавайтесь на провокации и предлагайте заинтересованным лицам самим выяснить. Вы же всего лишь принесли резюме.
- Ответственность за достоверность данных. Тут все несколько сложнее. Если вы видите в резюме явно недостоверные данные, подумайте, а стоит ли это резюме передавать дальше. Можете выяснить у своего знакомого, что подвигло его на такой шаг и постараться убедить писать о себе только правду и ничего кроме правды. В любом случае, эта ответственность только на вас. Другая часть ответственности уже на собеседующих и будущем руководителе, ведь вы можете и не знать, достоверен какой-либо факт в резюме или нет, но вот кадровая служба и/или будущий руководитель должны проверить все (если им это важно, конечно). И вы можете уверенно говорить, что не знали о том, что в резюме неправда.
- Ответственность за умение работать с кем либо кроме вас. Возлагая на вас эту ответственность, компания пытается контролировать риски возникновения клики, совместного увольнения и подобные им. Опять-таки, на самом деле эта ответственность в основном на собеседующих. И вам же на самом деле неинтересны все эти корпоративные интриги? 😉
- Ответственность за воспитание и приобщение к корпоративному духу и “казарменной” жизни. Это, пожалуй, единственная ответственность, которую стоит взять, да и то с ограничениями. Вашему знакомому будет гораздо приятнее узнать от вас про особенности пропускного режима, распорядок обеда, местоположение туалетов и прочие нюансы трудового быта. А вот уж должностные обязанности излагать новообращенному должен его непосредственный руководитель.
- Ответственность за неувольнение человека, в случае, если вы вдруг уволитесь. Опять-таки, эта ответственность целиком и полностью на работодателе. И ему очень удобно вместо создания комфортных условий для работы просто заставлять вас уговаривать вашего знакомого не увольняться.
Как видите, реально ответственности за приведенного сотрудника никакой на вас нет, кроме той, которую вы сами по каким-то причинам на себя захотели взять. В общем, не бойтесь рекомендовать друзей и знакомых на вакансии вашего же работодателя.
 О том, как проводить эффективные совещания, написана уже куча книг и интернетов, придуманы всякие методики типа шести шляп и прочих. Поэтому не буду писать про эффективность. Этот пост о том, как максимально развлечь себя на совещании.
Читать еще
 Мысль возникла после некоторых наблюдений за так называемыми ИТ-специалистами. Хорошо, что они не мои коллеги.
Суть идеи в том, что надо выдавать права на управление и эксплуатацию вычислительного средства прежде чем выдавать доступ к этому средству. И следить за соблюдением общих правил эксплуатации вычислительного средства.
Создать бы такой большой контролирующий орган на уровне государства, который бы следил за правилами эксплуатации вычислительных средств. Такой ГИИ (государственная инженерная инспекция). И штрафовать за нарушение правил, вплоть до лишения прав.
Технически бы сделать так: при заведении юзера обязательно указываешь айдишку прав, которая передается в государственный реестр прав вместе с типом устройства, на котором юзер заводится, и оттуда уже приходит липо аппрув, либо деклайн. И в случае каждого нарушения регламента работ (несделанный бэкап перед началом работ, явно неправильные действия и так далее) отправлять уведомление в контролирующий орган, которое бы содержало номер удостоверения и код нарушения.
 Нашел подборку фотографий мобилкой, еще с 2007 года из замечательной компании “Столица-Медикл”. На фотографиях мой тогдашний босс и коллега. Все описанное на картинках сплошной вымысел, на самом деле мужики очень профессиональные и дело свое знают лучше всех.
 Чем больше команда, тем больше времени надо на коммуникации. Тем дольше информация расползается по команде. Рассмотрим обычную ситуацию: компания из 2 000 сотрудников, 10 топ-менеджеров, под каждым топом 10 менеджеров среднего звена, под каждым менеджером среднего звена еще по 3 руководителя группы. Допустим, на совете топ-менеджеров приняли какое-то решение, которое касается деятельности каждого сотрудника. Решение непростое, большое, емейлом и не описать вот так. И тогда каждый топ-менеджер собирает своих сотрудников на совещание. То есть нужно провести еще 10 совещаний. Отчетные совещания проходят раз в две недели, да и если созывать внеплановое совещание, все равно раньше, чем через 2 недели, всех собрать толком и не получится. После этого каждый менеджер среднего звена на летучке отдела все сообщит, а это будет еще через неделю. В промежутках между совещаниями на разных уровнях идет активная переписка с уточнениями и вопросами касательно принятого решения.
И что же мы видим: более-менее объемная информация распространяется от руководства до младших сотрудников не менее чем за 3 недели. И это в относительно небольшой компании. Сокращение сотрудников компании до 200 человек (в 10 раз) уменьшит срок прохождения только на 1 неделю, то есть время доставки информации зависит от количества уровней иерархии. Что же делать?
Руководство никому не доверяет принятие решений
В этом случае нужно основную часть коммуникаций перенести в онлайн, например, в интранет-систему. Это позволит не отвечать на один и тот же вопрос дважды, да и не будет необходимости собирать кучу народа на совещания. Также это поможет избежать ошибок коммуникации (про которые я писал ранее). Подобным образом поступают, например, компании “большой четверки”.
Руководство свободно делегирует принятие решений
В этом случае нужно создавать небольшие автономные группы, которые должны быть максимально независимыми от деятельности остальных групп. И каждой группе выдавать свое направление для работы, предоставляя ей самой уже решать, как именно развивать это направление и выходить на нужные показатели. За счет небольшого размера группы ошибок коммуникации не будет. Таким образом действуют, например, компании Virgin и Gore.
Оба пути имеют право на существование, так что тут решать только вам, как поступить.
 Не бывает сложных проблем, задач, решений или систем. Но, “просто” не значит “легко”. Если вы проектируете сложную систему и сразу закладываете сложности, лучше бросайте это дело и займитесь чем-нибудь другим, все равно такая система обречена на провал. Все в нашем мире устроено просто и единственная сложность, которая есть, это многообразие вариантов и комбинаций простых вещей. Мастерство тем выше, чем меньше простых составляющих нужно для получения результата. Особенно это заметно в больших системах, где сходу нельзя определить минимальное необходимое и достаточное количество простых элементов. Касательно технологических проектов и стартапов это хорошо видно: те, которые начинали с гаража/одного сервера, сейчас имеют преимущество перед теми, которые начинали с какой-то сложной схемы.
При постепенном увеличении разнообразия “деталек” уровень сложности системы нарастает тоже постепенно, к тому же в системе отсутствует ненужная избыточность, а вместо нее имеется бОльшая гибкость. Но в какой-то момент количество “деталек” становится огромным и сложность системы зашкаливает. Очень важно поймать этот момент, остановиться, посмотреть назад и сделать рефакторинг, постараться опять уменьшить количество “деталек”, например, заменив несколько очень похожих на одну более универсальную, или же уменьшив количество связей между элементами. Или же заменив комбинацию нескольких элементов одним. Тут уже конкретные действия зависят от особенностей системы и вашей фантазии.
Сложность системы можно определять по временной шкале: сколько времени нужно инженеру, чтобы разобраться, как работает система. Если срок приближается к году или даже больше, что-то явно не так. Либо же вы разрабатываете военный/космический проект, начатый еще 25 лет назад. Выгода определения сложности в человекоднях очевидна: сразу видны издержки на привлечение нового специалиста в проект, а также виден коэффициент, понижающий стоимость проекта при продаже. Чем больше времени надо на освоение системы, тем выше и эксплуатационные риски, и кадровые.
Жизненных примеров полно, хотя бы та же электроника, которая собирается вся на одной элементной базе.
 Итак, в этой статье мы рассмотрим, как можно уменьшить количество ошибок в итоговом результате работы. Вообще, не стоит это все воспринимать как нечто догматическое, это просто мое субъективное мнение.
Разделим ошибки на категории:
1) ошибки коммуникации (например, разное понимание одного и того же термина приводят к искажению восприятия задачи).
2) Ошибки, допущенные непосредственным исполнителем в процессе реализации.
3) Ошибки, допущенные при проектировании и/или при постановке задачи. Или вообще на этапе придумывания идеи.
У каждой категории ошибок есть свои причины, влияющие на их количество и характер. Причем независимо от типа работы (проект или процесс) сами ошибки не меняются. Попробуем рассмотреть эти причины и способы влияния на них.
Ошибки коммуникации
Любое общение суть передача набора понятий от одного человека к другому человеку (или же от нескольких/к нескольким). Поскольку общение происходит посредством языка, а язык это набор абстрактных понятий, выраженных в словах. (Во, блин, как заумно завернул). Ну так вот, во время общения под одним и тем же словом каждый может понимать разные вещи. Чем больше актов общения происходит, тем больше вероятность ошибки. Более сложным случаем являются цепочки общения (например, заказчик высказывает пожелание менеджеру проектов, тот объясняет задачу дизайнеру, тот тимлидеру, а тимлидер разработчику). Как же уменьшить количество этих ошибок? Очень просто: нужно уменьшать количество актов непосредственно полезного общения, увеличивать качество общения, и после каждого акта составлять протокол, в котором каждый участник общения описывает своими словами договоренности, достигнутые в процессе общения, который затем проверяется каждым участником общения и каждый тезис либо подтверждается, либо опровергается. Таким образом, мы по сути увеличиваем количество актов общения как минимум вдвое. Но зато уменьшается количество ошибок, ведь каждый протокол скорее всего найдет хотя бы часть ошибок. С другой стороны протокол может вносить ошибки, поэтому каким-то образом нужно контролировать и протоколы. Например, на каждые N протоколов составлять большой сводный протокол, причем силами других людей, в котором бы излагались все тезисы из предыдущих протоколов. В целом, в большинстве компаний так и происходит, люди просто пишут друг другу письма со своим пониманием совещания.
С другой стороны, все эти согласования результатов общения сильно затягивают процесс и откладывают принятия решений и начала проектирования.
Ошибки исполнителя
Тут причины простые: люди иногда ошибаются и такова природа. Программист может где-то неправильно реализовать логику или не учесть какую-то ситуацию. Выход простой: тестировать перед тем, как использовать в жизни. В случае с кодом ситуация особенно показательна: на сам классы пишутся юнит-тесты, затем на сам код пишутся (или проводятся руками) функциональные тесты, затем на всю систему пишутся (ну или же опять-таки руками делаются) интеграционные тесты. Однако, если проект большой, то есть вероятность, что в тестах будет ошибка, которую пропустит ошибку в коде или в классе. А значит, все тесты надо покрывать тестами и так далее, такое рекурсивное тестирование.
А это уже сильно затягивает процесс разработки и откладывает момент внедрения и эксплуатации продукта.
Ошибки проектирования
И здесь тоже причины простые. Чаще такие ошибки являются комбинацией ошибок коммуникации и исполнения на начальном этапе. Суть в том, что поскольку люди это люди, на основании правильно понятых потребностей может быть составлено ошибочное задание для исполнителя. Для избежания таких ошибок нужно проверять технические задания другими экспертами, а также постоянно проводить аудит технического состояния системы, по результатам которого выявлять противоречивые и опасные (с технической точки зрения) моменты в техническом задании.
Все это тоже может очень сильно оттянуть момент начала работы.
Что делать?
Глядя на все описанное можно сделать вывод, что внесение даже сколь-нибудь малого изменения в большую систему, да еще и при условии, что разные изменения вносятся постоянно и параллельно, может затянуться на недели или даже месяцы. Выходов тут 3:
1) Радикальный экстремизм. Вообще минимизировать всякие проверки и быть готовым быстро-быстро править-чинить. По сути, выкладывать код, который банально запускается и не удаляет все данные. 😉
2) Радикальный консерватизм: следовать всем-всем процедурам проверки и выкладывать много раз проверенный код. Подход хорош, когда нет возможности быстренько починить или же когда цена ошибки очень высока.
3) Умеренный экстремизм. В общем-то, некая комбинация первого и второго вариантов. Нужно заранее спроектировать свою систему так, чтобы ни одно изменение не могло затронуть ее целиком. Тестировать на предмет соответствия требованиям и работоспособности кода, выкладывать так, чтобы сначала изменение затрагивало только часть системы и уже после опытной эксплуатации распространять изменения на всю систему.
Лично мне ближе 3-й вариант. Похожим образом действуют, например, Facebook, ВКонтакте, Бегун, Twitter и, наверняка, еще немало хороших организаций.
 Такой небольшой экспресс-пост. Для людей, далеких от жизни, поясню: кредит — деньги сейчас, потом долго платить небольшими частями и много переплачивать в итоге. Депозит — сразу отдаете деньги банку, а потом каждый месяц собираете проценты. Посмотрим, какое это имеет отношение к разработке. У любой задачи есть как минимум два решения. Первое решение быстрое, костыльное, с кучей возможных ограничений для будущего развития. Второе решение более трудоемкое, но лишено основных недостатков первого. Казалось бы, второе решение панацея от головной боли, но все не так просто.
В случае с кредитом результат получаете сейчас, потом долго разгребаете говно. А в случае с депозитом вкладываете много сил сейчас, потом получаете проценты в виде стабильно работающей системы. Дальше можно провести аналогию с рассуждениями о соотношении заемного и собственного капитала в структуре активов предприятия. А также вспомнить, что код это интеллектуальный актив, а значит политика костыльности кода должна соответствовать политике распределения долей собственных средств и заемного капитала.
 Как вам новые картинки? Старательно отобранные в интернете, чтобы радовать ваш глаз.
 Я про вас помню, уважаемые читатели. Разрываюсь между работой, продолжением статьи про бонусы и новой статьей про PR личности внутри крупной организации. Постараюсь не разочаровать вас новым материалом, он уже на подходе. 🙂
|
|
У каждого из нас есть друзья и знакомые и нередко бывает, когда один из ваших знакомых начинает искать работу, а у вас на работе есть соответствующая вакансия. Казалось бы, отличная возможность и знакомому помочь, и своему работодателю, но тут, как и везде, есть подводные камни. Эти подводные (некоторые даже из воды торчат) камни называются архипелаг ответственности за рекомендацию. Какую-то ответственность вы сами себе в голову вбиваете, какую-то вам навязывает будущий руководитель этого сотрудника. Да и наверняка многие из вас уже слышали фразы наподобие: “Ну и на хрена ты привел к нам этого долбоклюя?” Давайте по полочкам все разберем и выясним, какая же на самом деле ответственность за приведенного сотрудника.