Случайны выбор дневника Раскрыть/свернуть полный список возможностей


Найдено 966 сообщений
Cообщения с меткой

управление персоналом - Самое интересное в блогах

Следующие 30  »
rss_rss_hh_new

Кейс SMM-приложения KUKU.io: путь от спринта в 4 месяца до разумного планирования

Пятница, 26 Августа 2016 г. 13:16 (ссылка)

Ребята из стартапа KUKU.io, популярного сервиса для SMM, прошли долгий путь от хаотичного планирования и спринтов, растянутых почти на полгода, до логичного управления задачами, автономной команды и, наконец, закрываемых в срок спринтов. Молодым проектам на заметку.



Менеджер проекта Павел поделился историей о том, как удалось безболезненно решить большиство проблем:












Мы разрабатываем SMM-приложение KUKU.io с мая прошлого года и только сейчас нам удалось настроить все процессы так, чтобы хаос в задачах был сведен к минимуму, а пользователи оставались довольными новыми функциональными особенностями, о которых просили нас, как можно чаще.



Когда мы начинали, KUKU.io умел публиковать контент в 4 социальные сети: Facebook, Вконтакте, Twitter и Linkedin. Однозначно, полноценным управлением социальными сетями это никак не назовешь, и приложение постепенно начало обрастать другими особенностями: пользователи хотели видеть разделение аккаунтов соцсетей в каналы или проекты, анализ социальных сетей стал ключевым фактором выбора (или не выбора) сервиса, UTM-метки, сокращение ссылок, много картинок в одном посте, новые соцсети (сейчас KUKU.io поддерживает 10) и др. — все это предстояло реализовать.



В первые дни, когда я пришел в проект, была ситуация, когда вроде все понятно, а на деле ничего не понятно. Что за проект я понял очень быстро, без деталей, так как продукт уже на продакшене, и можно потыкать посмотреть, что к чему. К тому же, команда сразу позаботилась о крутом UX/UI, разобраться за несколько минут сможет даже человек, далекий от социальных сетей.



Команда… Команда есть, отличные все ребята, профессионалы в своем деле: от нереальных разработчиков до маркетолога и сммщика. Кто что делает, не понятно. :) Есть какое-то управление проектами и системы: Jira и GanttPRO, в них что-то есть, но что это — тоже ни малейшего представления (сторей тасков, описаний к ним минимальных, логики, ничего нет).



Лезу в документы — есть в драйве море папок, в которых вроде по названиям что-то адекватное намечается: альфа версия, анализ конкурентов, бета версия, демо, спека версии 1.0 и тд. Открываешь — заголовок, какие-то наброски и все.



В результате имеем: рабочий продукт, без понимания, как и что в нем работает, кто над чем работает, кто product owner, кто за что отвечает, куда проект идет, какие цели в дальнейшем, какие рабочие правила. Планирование не определить какое было, так как видно, пытались прийти к какому-то фреймворку гибкому, но все забрасывали. В результате имелась куча релизов, спринтов незакрытых, гигантский спринт в 4 месяца. По рабочему процессу была такая схема: практически любой участник команды создавал себе issues в Jira, естественно без описаний.



Т.е. залазим в спринт или бэклог, а там какая-нибудь борода «Изменить существующий блок» или баг «Не работает login — консольная ошибка #».



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



Поэтому начали с простого:


  • Взяли за основу канбан (свой проект, поэтому нет привязки по срокам).

  • Определили, кто за что отвечает, кто принимает решения.

  • Выбрали актуальные задачи.

  • Расставили приоритеты.

  • Договорились с QA насчет метода описания багов в виде use cases с описанием среды.

  • Наконец, прогрумили бэклог (заняло очень много времени).

  • Начали описывать все через истории, чтобы уменьшить количество багов.





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



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



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



Ретроспективу мы не стали вводить, так как смысла особого не было. Планирование делали на месяц, так как быстрее вряд ли получалось бы, слишком динамичный проект, хотя и сейчас есть проблемы со сроками. Решили, что к story points мы придем позже и оставили все в тасках, но с описанием логики и use cases, что дало быстрый результат: условия приемки были понятны для всех, и уменьшилось количество багов.



Из XP взяли большую часть CI (Continuous Integration), что ускорило обновления и, опять же, позволило выпускать более качественные релизы, обратную связь с клиентом (users' feedback) взяли за основу при расставлении приоритетов; все решения принимали сами, на свой страх и риск.



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



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



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



Позже из Scrum взяли story и epics — идем к детальному планированию. Можно сказать, что мы приходим к более детальному планированию и коротким итерациям. Сейчас мы знаем, что у нас будет почти на месяц вперед на процентов 80-90. И легко можем вносить правки.



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



Что в нашем случае привело к автономности:

1) постоянно меняющийся и растущий продукт и отпуска — все понюхали пороху в роли других участников и имеют представление, что и как устроено в продукте.

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

3) планирование — мы знаем, что у нас сейчас и к чему мы идем.

4) сплоченость команды — походы в бар, корпоративы, живое общение, отсутвие давления.

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



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



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



Мы планируем примерно на месяц, потом фикс, регресс, деплой. Итого примерно раз в 5-6 недель релизим обновление с крупными особенностями, а обновления с багфиксом — по мере поступления сообщений от пользователей. Раньше вообще наши планы были космосом. Спринт на 3 недели мог затянуться на пару месяцев.



Яркие последние примеры: это Контент План для социальных сетей и Командный План для SMM и маркетинговых агенств и компаний, в которых не один человек занимается продвижением в социальных сетях. Последний мы думали сделать за месяц по первой прикидке вообще без понимания как это должно быть. После анализа, декомпозиции, написания небольшой «спеки» оценили скоуп задач в 2 месяца. По факту команда выкитила командный план, кучу обвесов к нему, smm и маркетинговых плюшек, годовые подписки, улучшили аналитику социальных сетей, оттестировали все это, сделали регресс и релизнули на продакшен за 3 месяца. Это с учетом того, что у нас — 3 разработчика, у двоих была сессия и выселение из общежития, параллельно создавался Контент План, они связаны между собой и должны мержится без конфликтов. И оно все работало, как было описано. Это реально успех!



Еще одно достижение огромное достижение — меньше конфликтов в команде.



Дальше хотелось бы прийти к более частым релизам и уведомлять пользователей о наших ближайших обновлениях. Весь road map, мне кажется, не так круто показывать — нет интереса, все на ладони, а так ждать будут. :)
Original source: habrahabr.ru (comments, light).

https://habrahabr.ru/post/308588/

Комментарии (0)КомментироватьВ цитатник или сообщество
rss_rss_hh_new

«Разработчик переднего конца» или кто я по профессии

Понедельник, 22 Августа 2016 г. 11:13 (ссылка)



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





Какофония профессий



«Веб-дизайнер», как понятие в русскоязычном пространстве совершенно не совпадает с аналогичным понятием в англоязычном пространстве. Русскоязычный веб-дизайнер занимается составлением коллажа и макетов будущих страниц. Продвинутые веб-дизайнеры, чтобы отличаться от тех, низкоквалифицированных дизайнеров, дополнительно вешают на себя ярлыки «UI/UX дизайнера» или «дизайнера интерфейсов», подразумевая, что они предварительно думают головой, прежде чем рисовать коллажи и макеты будущих страниц и приложений. А особо продвинутые называют себя «арт-директором» или еще как-то так. Тех, кто не успел повесить себе медаль «UI-эксперта», пренебрежительно дразнят операторами фотошопа. Операторы фотошопа же или вообще новички в отрасли целенаправленно пытаются получить гордый титул «UI/UX», подразумевая, что они тут не хухры-мухры, а ребята с серьезными намерениями.



И еще у нас есть отдельная, в последнее время вымирающая, профессия «веб-верстальщика», которая подразумевает перевод нарисованных дизайнером картинок в удобочитаемый и адекватный html+css и иногда с примесью javascript. Если веб-верстальщик знает больше, чем просто набор тегов и немного css, называться «веб-верстальщиком» ему почему-то становится стыдно, и он вешает на себя ярлык «фронтэнд-разработчика», подразумевая, что он делает полноценные приложения в браузере, а не просто режет картинку на дивы и таблички или берет css-бутстрап и просто переопределяет переменные для CSS. Еще более модное название той же самой профессии даже не хочется переводить с английского, потому как по-русски оно звучит не достаточно круто — «клиент-сайд девелопер». По-русски это бы был обычный «разработчик приложений в браузере», а одно время гуглотранслейт буквально это переводил, как «разработчик переднего конца», что звучит скорее оскорбительно. Интересно, что появилась такая профессия в далекие времена ie6, opera8 и ff2 и именно потому, что тем людям, у кого было воспитано чувство прекрасного, не хватало сил и терпения научиться создавать html-файлы, которые одинаково хорошо отображаются в этих самых ie6, opera8 и ff2.



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



Систематизируй это



Правильному веб-дизайнеру просто необходимо уметь на выходе выдавать не красивую psd-ai-sketch картинку, а набор html+css+js, полностью готовый к интеграции в существующее приложение. В итоге веб-дизайнер должен еще быть хорошим веб-верстальщиком. Само собой, голову ему тоже стоит использовать в своей работе, поэтому «дизайнер-интерфейсов» как понятие тоже должно отсутствовать. «Веб-дизайнер» и точка.



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



Правильного фронтенд-девелопера стоит переименовать в простого джаваскрипт-разработчика и не выделываться, потому как мириады инструментов, созданных для веба, принципиально не отличаются от той массы инструментов для какого-либо другого окружения, будь до java, ruby, PHP или еще что-нибудь. Руби-разработчик остается руби-разработчиком вне зависимости от количества гемов и инструментов, используемых в работе. И почему-то его отличают от эрланг-разработчика, несмотря на то, что и тот и другой является в общепринятом смысле «бекэнд-разработчиком». А вот фронтенд-девелопер внезапно должен уметь одинаково хорошо программировать на es6 и react-js и в это же время писать отличный код на TypeScript с AngularJS. Современные реалии должны отличать TypeScript-разработчика от elm-разработчика и знания клиентских фреймворков должны позиционироваться точно так же, как и знания фреймворков у любого разработчика. Джанго-разработчик и разработчик, умеющий писать плагины для ansible принципиально отличаются в базовых знаниях, несмотря на то, что и то и другое написано на питоне.



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



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




Original source: habrahabr.ru.

https://habrahabr.ru/post/308186/?utm_source=habrahabr&utm_medium=rss&utm_campaign=best

Метки:   Комментарии (0)КомментироватьВ цитатник или сообщество
rss_rss_hh_new

Взлом собеседования на Junior Developer

Пятница, 19 Августа 2016 г. 14:17 (ссылка)



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



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



Часть 1. Сколько стоит время “домохозяйки”?



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



Но существуют сценарии, когда ни один из этих вариантов не дает максимальной выгоды ни исполнителю, ни заказчику. Особенно это актуально, когда исполнитель оказывает консультационные услуги, параллельно с ещё каким-нибудь процессом, который, в свою очередь, не ограничен во времени. Самое любопытное, что с этим типом консалтинга меня познакомила девушка, оказывающая интимные услуги онлайн (ну, вы поняли). Забавно, но в её резюме было написано “домохозяйка”.



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



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



Вы видели фильм “Время” с Джастином Тимберлейком в главной роли? В сюжете время было и одним из измерений, и платежной единицей. Для обмена временем использовался некий функционал с индикатором, встроенным в руку. Думаю, это было бы оптимальным решением задачи, но к сожалению, в реальной жизни time-based billing сервисов не так уж и много. Большинство из них, это сайты, заточенные под конкретные задачи (юридические консультации, службы технической поддержки или те же интимные услуги онлайн). Минус этих сервисов в узкой специализации и огромных комиссионных (некоторые берут до 30%). Из более менее универсальных решений выделяются западные Transcepta, Replicon и Zuora. Из отечественных, разве что, StretchPay даёт функционал посекундного перевода средств между кошельками в Яндекс.Деньгах.



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



Часть 2. Строитель — идеальный кандидат на Junior программиста



Карьерная лестница программиста всегда чёткая и ясная. Она абсолютно логична, как и всё, что касается программирования. Я видела много схем, но все они напоминают военную иерархию. В начале ты рядовой (стажер), затем можешь стать ефрейтором (начнешь тестировать софт), если подучиться, то можно пойти в сержанты (стать старшим тестировщиком, или админом, или назовите как хотите), конечная остановка здесь — старшина (архитектор или менеджер). Затем идут офицерские звания (собственно, разработчики), изобилующие приставками Junior, Experienced, Senior и так далее.



В HR-сленге есть такое понятие — “эффект МакДональдз”. Суть его в том, что в солдаты может записаться любой человек от 18 до 50 лет, а вот офицером, в большинстве случаев, может стать только тот, кто либо прошел весь путь с самого начала, либо пришел уже в офицерском звании. Вот последний вариант самый популярный. Так в МакДональдз вы вряд ли увидите менеджера младше 26 и старше 35. Откуда же берутся все эти люди в белых рубашках, если средний возраст сотрудников, стоящих за кассой, около 20 лет? Что они делали почти 10 лет? Чем занимались?



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



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



Еще одним немаловажным фактором, почему ИТ-компании отстраняются от поиска некоторых вакансий, является нежелание “пачкать руки” (особенно это актуально для компании с иностранным капиталом). Всё дело в том, что главный критерий для отбора на младшие должности в крупных ИТ-фирмах — вовсе не знания, а психологический портрет кандидата (ППК). Нужно отметить, что HR-департаменты ИТ-компаний, как огня боятся самостоятельно работать с любыми психологическими штуками (потому, что это потенциальная тема для судебного иска), всячески маскируя их под забавные тесты, а-ля Google, или перекладывая на чужие плечи.



Для чего это делается? Дело в том, что каждый абстрактный сотрудник имеет вполне конкретный бюджет на развитие. Он об этом даже не догадывается, но работодатель рассматривает его, как инвестицию. У каждый инвестиции есть определенный цикл окупаемости. Для сотрудника без опыта, которого к тому же придется ещё обучать, такой цикл может составлять до 18 месяцев. Грубо говоря, работодатель должен быть уверен, что кандидат его кинет и многократно окупится.



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



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



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



Немного инсайд-информации, которая слегка приоткроет завесу логики ППК.




  • Повышенное стремление к карьерному росту — плохо. Как я уже сказала, вы должны окупаться минимум 18 месяцев. Если через полгода вы попросите повышение, то не выполните это требование. Так что если на вопрос “Кем вы видите себя через год в нашей компании?” ответить “Junior Developer” (при том, что вы идете на тестировщика), вас отсеют не задумываясь.

  • Неконфликтность — хорошо. Было несколько сценариев вывести кандидата из себя. Обычно я повышала голос и с упреком говорила: “Мы же просили (на самом деле не просили хе-хе) вас прислать резюме на электронную почту, а вы с собой принесли! Если вы не знаете, как пользоваться электронкой, почему вы хотите работать в ИТ?” Особенно “накрывало” самоуверенных выпускников престижных вузов. Некоторые разворачивались и уходили. Один парень даже заплакал, я не шучу.

  • К слову, о самоуверенных отличниках: требования к зарплате. Западные компании очень чутко относятся к цифре, которая бы вас устроила. Нам кажется: “А, скажу какую-нибудь тыщу баксов…” Эти люди оценивают зарплатный порог, исключительно исходя из рамок бюджета на вакансию. Бывает так, что на должности с одинаковым называнием, но в разные проекты, окно зарплаты может быть 500-700$ и 650-730$. Если от балды запросить 900$ из расчета на торг, то торговаться будет не с кем.

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

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

  • Семейное положение: вопросов по этой тематике несколько, но не на все можно получить ответы. Например, учитывается также и гражданский брак, и просто “встречаюсь”, и, как говорится, “всё сложно”. Вероятно, в этом разделе есть какая-то статистическая база, но для девушки формула “возраст 26 лет, не замужем, не была и не в гражданском браке” вызвала резкий рост балла. И да, мы пользовались социальными сетями, заполняя анкеты кандидатов.

  • Обучаемость. Не путайте с оценками в школе или университете, обучаемость — это другая история. Здесь проверяется не то, как быстро ты выучишь формулу, а то, что ты не будешь её оспаривать и при этом сможешь эффективно использовать в работе.

  • Внешний вид. Вот тут всё очень странно. В разделе внешний вид были обобщенные пункты, среди ответов на выбор: “аккуратный”, “модный”, “неряшливый”, “панк”. При этом был пункт “длина ногтей”, возможно, чтобы не раздражать окружающих, когда стучишь по клавишам...

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



Оплата услуг HR-фирмы, в которой я работала, была сдельной. Мы получали одну месячную ставку кандидата, прошедшего все собеседования заказчика. Моя зарплата была лишь небольшим процентом от этих денег. И однажды по пути домой меня осенило. Я поняла, как же меня это всё достало. Что я имела: съемная однушка на окраине города, кот, диван и ноутбук, со стёршимися клавишами. Я решила сорвать банк. И еще до того, как вставить ключ в замочную скважину квартиры, я совершенно точно знала, что буду делать дальше.



Часть 3. Может ли кухарка пройти собеседование?



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



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

— Эмм… Тип, это… Никогда… Какое ему собеседование? Ну, полгода, минимум. Интенсив по 3 занятия в неделю, плюс человек должен самостоятельно заниматься столько же.

— Саша, погоди, я говорю не о подготовке джуниора, а о прохождении собеседования на джуниора. Разницу улавливаешь?

— Ну ты же знаешь правила, человек должен будет пройти отборочное собеседование…

— Это я беру на себя!

— Ну тогда под конкретную компанию можно подготовить человека месяца за 3 или 4. Часть вопросов на собеседовании стандартные, но есть задания, которые часто меняются. Плюс финансовая сторона…

— А что с финансовой стороной?

— Ну, нафига мне его быстро готовить? У меня же предоплата: чем больше занятий, тем больше я зарабатываю…

Диалог привожу в качестве иллюстрации того факта, что многие курсы программирования искусственно раздуты. Работают они по схеме предоплаты, а банальные принципы психологии рынка подсказывают: “Чем больше товар, тем выше цена”. Зачем напрягаться, выжимаясь перед учениками, если можно неделями рассматривать одни и те же алгоритмы.



Как вы понимаете, я решила подсидеть своего работодателя и готовить кандидатов самостоятельно. Одна анкета могла дать до 700$ за тестировщика. Джуниоры приносили не менее до 1000$. В потоке из сотен анкет это не так уж и много, но в моём случае 5 верных кандидатов за 3 месяца могли бы обеспечить мне зарплату. А готовить кандидатов я собиралась самостоятельно.



Мы быстро нашли нескольких желающих поучиться: библиотекарь, домохозяйка, фармацевт, банковский служащий. Люди искали обычные онлайн-курсы, а мы предлагали интенсивную подготовку с высокой вероятностью приёма на работу. Обычно курсы этого не гарантируют, мы же добавляли эту опцию совершенно бесплатно.



Забегая вперед, скажу: в результате мы сократили время подготовки к собеседованию с полугода до 75 дней. Как это работает?



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



В чем секрет? Я заметила любопытный факт, в компаниях даже самые неквалифицированные сотрудники со временем обучались пользоваться весьма сложными инструментами (взять ту же 1С). Это говорит о том, что все эти мифы о умных от рождения “5% населения” — чушь собачья. В любом процессе главное — практика.



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



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



Секреты наших достижений спрятаны глубоко в мозгу. Если бы Майкл Фелпс лет в 15 понял, что он не самый лучший пловец в своём городе, он бы давным давно закончил университет и стал юристом. Именно осознание своих достижений заставляет людей достигать большего. А что делать если достижений нет? Ошибочка! Достижения есть всегда, нужно только открыть на них глаза. Чем я и занималась.



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

В-третьих, по наводке “домохозяйки” мы стали использовать StretchPay для повременной тарификации занятий. Это очень простая штука: нажимаешь “play” — деньги начинают капать на кошелёк тренеру, время пошло, если занятие заканчивается — выключаешь. При этом тренер видит оплату в реальном времени.



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



Таким образом, мы решили проблему с раздутым графиком обучения и рисками, которые возникают при предоплате. Иногда Саша так увлекательно рассказывал, что вместо двух часов занятий ученики оставались на 3 или даже 4. Подумайте, в случае предоплаты Саша работал бы сверхурочное время бесплатно (или просто прекращал бы занятие), но с посекундной тарификацией вопрос решался сам собой. Такой подход удобен и ученикам: можно консультироваться в неурочное время по 10-20 минут, и платить только за использованное время. Попробуйте на обычных курсах попросить преподавателя по скайпу помочь с домашкой, в нашем случае всё просто: звонок, включили таймер, быстро помог, выключили. Это очень справедливый и честный подход. Мы подсчитывали — посекундная тарификация занятий приносит преподавателю больше денег, чем предоплата, при этом ученики испытывают больше удовольствия от процесса обучения. По сути, это напоминает оплату наличными и при этом абсолютно безопасно для всех участников: никто не может друг друга кинуть на деньги. Согласитесь, очень простой лайф-хак, но совсем не очевидный.



Эпилог. Как кинуть ИТ-компанию и при этом остаться в живых



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



Стало понятно, что с таким подходом, лавочка скоро закроется, HR-отдел узнает, что их анкету ППК взломали и сменит формулу. Тогда я решила сделать то, к чему так долго шла — сорвать банк. Я связалась с ИТ-компанией и сказала, что договорилась с курсами — те будут отправлять всех своих выпускников напрямую к ним, но для этого нужно оптом выкупить базу уже существующих студентов и выпускников. По 100 долларов за студента, база на 100 человек. Согласитесь, это неплохая экономия для HR-отдела, который отдает по 700$ комиссионных за одного трудоустроенного кандидата.



Хочу заметить, всё получилось более-менее честно: они получили свой список студентов (правда, некоторые из них еще и недели не отучились), я получила свои деньги — ведь это действительно были мои курсы. То, что я дальше буду заниматься этим бизнесом — я не гарантировала (да никто и не просил). Так что если у уважаемой ИТ-компании, после этой статьи, появится желание каким-то образом свести со мной счеты, ну что же, прошу. Но чуть раньше я заменю в этой статье каждую фразу “ИТ-компания” настоящим названием. Так что тут есть над чем подумать.



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


Original source: habrahabr.ru (comments, light).

https://habrahabr.ru/post/308110/

Метки:   Комментарии (0)КомментироватьВ цитатник или сообщество
rss_rss_hh_new

Сказ о том, что фрилансеры слышат только себя, а не заказчика

Четверг, 18 Августа 2016 г. 16:54 (ссылка)





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

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



Я создал на бирже фрилансеров задание следующего содержания:

У нас существует сайт www.kickidler.com/ru/

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

Где-то возможно нужно переставить кнопки, поменять их цвет, добавить подложку и т.д.

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



В ответ начали падать совершенно типовые отклики:

Здравствуйте.

Прошу рассмотреть мою кандидатуру.

Большой опыт работы в веб-разработках.

skype:…

mob.…



Нет, думаю. Либо меня не поняли, либо не хотят понять.

Решил я уточнить задание:

P.S.

Дорогие дизайнеры. Прочел первые поступившие отклики и решил внести дополнения.

Нам не нужен редизайн нашего сайта, нам нужно облагородить текущий дизайн.

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

Еще раз – вначале нужен список текущих «косяков» с предложением по доработкам и только потом эскизы конкретных доработок.

Хочется понять стоимость и сроки.

Шаблонных ответов типа «занимаюсь дизайном 10 лет, вот моё портфолио, сделаю все в лучшем виде» пришло много, но они не подходят.




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



Готов выполнить ваш проект в самые кратчайшие сроки.

Непосредственно сам программист-разработчик, не посредник.

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

Возможна поэтапная оплата для заказчиков с рейтингом.


Программист? Мне дизайнер нужен, верстальщик у нас и свой есть.

А до личного общения про сроки и бюджет проекта сказать было трудно?

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



Здравствуйте.



Мои отзывы: www.fl.ru/users

Мое портфолио: www.fl.ru/users



Мой скайп:…



С уважением, Вадим


И что? Заказчик должен сам ознакомиться с портфолио и выбрать что из прошлых работ нравится? Нет, спасибо.



Здравствуйте.

Меня зовут Анатолий, я занимаюсь программированием уже более 5 лет.

Готов выполнить ваш проект за разумную цену

Мой скайп:…

Моя почта: ...


Хочется задать такому «исполнителю» только один вопрос: милый, ты описание задания вообще читал? Или откликаешься на всё подряд?



Здравствуйте!

Интересен Ваш проект

Давайте обсудим



ПОРТФОЛИО И ОТЗЫВЫ КЛИЕНТОВ





КОНТАКТЫ

Скайп:…

E-mail:…



Был бы интересен мой проект, написал бы что-то о нём, а не о себе.



Здравствуйте! Готова Приступить к работе. Дизайн: WEB, баннера, постера, логотипа, д.р. Верстка.



ДИЗАЙНА:

одна уникальная страница: 6000 руб,

дополнительная страница макета: 1200 руб/шт.



Срок проекта: 2 – 6 дней


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



Здравствуйте.

Я графический дизайнер с 11 летним опытом работы.

Специализируюсь на корпоративной айдентике, полиграфии, веб-дизайне.

Успешный опыт работы на фриленсе более 6 лет.

Разработка оригинальной продающей концепции, удобного функционала, качественного юзабилити.

Гарантия уникальности, стильного дизайна, комфортного пользования и для продавца, и для пользователей ресурса.

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

Примеры работ можно посмотреть в портфолио.

Обращайтесь.

С уважением Петр





И апогея бреда :)

Information Security & IT Security

(((( [Программист] [Кодер] Пишем софт на заказ )))

Программирование на Perl, C++ JavaScript, Python, PL/SQL, Ruby, C and Java

[ Реверсинг ПО, деобфускация и декодирование ]

Cracking (взлом) софта на заказ.

Распакую и «вылечу» от жадности ПО любой сложности.

Delphi, Java, C++, C#, Android приложения.

Отличные знания в области сетевых концепций и безопасности.


Тут даже комментариев не будет, не ждите.



Возможно мне писали по-настоящему крутые профессионалы. Возможно они могли заставить наш сайт заиграть новыми красками.

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

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



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

Разгадка была проста. Пока другие расхваливали товар, цвет, качество — он работал на покупателя.

-Ну, парень, в этих джинсах все девки в институте твои! Но чтобы усилить эффект рекомендую вот эту куртку…

-Красавица, в этом платье сразу мужа найдешь!

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



Этот продавец был молодец! Делайте все как тот продавец!
Original source: habrahabr.ru (comments, light).

https://habrahabr.ru/post/308016/

Метки:   Комментарии (0)КомментироватьВ цитатник или сообщество
rss_rss_hh_new

Отчет о результатах «Моего круга» за июль 2016, и самые популярные вакансии месяца

Пятница, 12 Августа 2016 г. 12:31 (ссылка)

Представляем наш ежемесячный отчёт о результативности «Моего круга». В июле у нас было размещено 660 вакансий, на каждую за месяц в среднем откликнулось 9-10 специалистов. Это наш очередной небольшой рекорд по откликам!



А теперь более подробно об откликах на вакансии в самых популярных сферах деятельности.












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

  • На вакансии верстальщиков в среднем откликается по 12-13 специалистов, они стабильно занимают второе место по откликам. В истекшем месяце поставлен рекорд с почти 14 откликами на вакансию.

  • На вакансии менеджеров и администраторов в среднем откликается по 10-11 специалистов, эти сферы деятельности постоянно борются между собой за третье место.

  • На вакансии программистов в среднем откликается по 7-8 человек.

  • На вакансии тестировщиков в среднем откликается по 6-7 человек. В этом месяце вакансии этой сферы деятельности вновь вернулись на свой прежний уровень после двухмесячного проседания.

  • На вакансии разработчиков приложений и программного обеcпечения в среднем откликается по 5-6 специалистов.






Далее традиционный топ самых популярных IT-вакансий месяца: по одной вакансии из каждой сферы деятельности. Популярность вакансии измеряется числом откликов на неё. Все эти вакансии открыты на момент публикации отчёта, на них можно откликнуться.
















































Администрирование

DevOps Engineer / Инженер отдела эксплуатации, 17 откликов



От 100 000 руб. Москва. Полный рабочий день. Можно удалённо. Компания Alytics — сильнейшая команда на рынке рекламных web-технологий. Мы разрабатываем и продаем платформу для эффективного управления контекстной рекламой, автоматизации рекламных процессов и управления конверсиями.



image


Аналитика

Аналитик, 14 откликов



Полный рабочий день. Можно удалённо. Компания VimWin — создание новых проектов в области онлайн коммерции.



image


Бэкенд

PHP программист, 69 откликов



От 49 000 до 150 000 руб. Иваново. Полный рабочий день. Можно удаленно. Компания CodeGeek — информационные технологии, системная интеграция, интернет.



image


Дизайн

Web-дизайнер, 44 отклика



От 70 000 до 100 000 руб. Москва. Полный рабочий день. Можно удаленно. Компания Technology Marketing Solutions — разработка и продвижение мобильных приложений, программные решения для носимых устройств.



image


Контент

Контент менеджер и копирайтер, 21 отклик



От 30 000 до 80 000 руб. Москва. Полный рабочий день. Можно удалённо. Компания ООО «Континент» — интернет-продажи.



image


Маркетинг

Интернет-маркетолог, 6 откликов



От 30 000 до 60 000 руб. Москва. Неполный рабочий день. Компания «Софт Культура» — образовательная площадка для освоения современных цифровых инструментов для архитекторов и дизайнеров.



image


Менеджмент

Team-lead отдела разработки, 11 откликов



От 800 до 1200 USD. Неполный рабочий день. Можно удалённо. Компания ГК «Курортный Отдых» — мы соединяем IT, продажи и санаторно-курортное лечение.



image


Приложения

Разработчик Android, 12 откликов



до 120 000 руб. Москва. Полный рабочий день. Можно удаленно. Компания «Связной» — розница, retail.



image


Разработка ПО

Python разработчик, 17 откликов



От 60 000 руб. Ижевск. Полный рабочий день. Можно удалённо. Компания СКАТ — разработка программного обеспечения для таксомоторных служб.





Тестирование

QA Automation Engineer, 18 откликов



От 900 до 1 800 USD. Полный рабочий день. Можно удаленно. Компания LEGEFIX — надёжный провайдер консультационных услуг между экспертами права и людьми, которым требуется консультация.



image


Фронтенд

Верстальщик, 156 откликов



Владимир. Неполный рабочий день. Можно удаленно. Компания SymbioWay — центр сертификации, аттестации, профориентации и трудоустройства IT-специалистов



image



Original source: habrahabr.ru.

https://habrahabr.ru/post/307624/?utm_source=habrahabr&utm_medium=rss&utm_campaign=best

Метки:   Комментарии (0)КомментироватьВ цитатник или сообщество
rss_rss_hh_new

Исследуем вопрос наказаний 2.0

Пятница, 12 Августа 2016 г. 10:27 (ссылка)

Этот материал будет полезен в первую очередь тем, кто много занимался программированием и вдруг внезапно стал вынужден заниматься управлением проектами и людьми. С год назад я рассказал про наказания на конференции, а солнышки из Битрикса сделали текстовую версию для #habr. К сожалению, потеряв в точности, четкости и правильности акцентов. За год материала добавилось. В конце — чеклист для ленивых :)



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

image





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



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



Это печально, но как требовать у человека наличие навыка, которому его нигде не обучали? Был себе программистом, стал менеджером, и тут — иди и наказывай? Неправильно же требовать от программиста виртуозных навыков рукопашного боя?



Но неаккуратно наказанный (а по факту — обиженный) сотрудник в такие тонкости вдаваться не станет. Разбираться придётся руководителям, менеджерам, директорам.



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



«Нести ответственность» в практическом плане



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



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



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



Как директор я понимаю, что в случае факапа огребу по полной программе. Поставлю на проект неправильных людей — провалюсь финансово, неподходящего сотрудника найму — появятся проблемы в коллективе. Вся ответственность компании лежит на мне. А какую ответственность несёт программист? Или дизайнер? Что это в практическом плане?

image



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



И лишь спустя годы я нащупал ответ на этот вопрос. И пришло понимание, что тот разработчик, который вовремя ушел домой, хоть и не закончил задачу, ни в чем не виноват. А я — да, я виноват и что-то сделал неправильно: криво построил рабочий процесс, распланировал время или неправильно сформировал ожидания заказчика. Однако молодые и готовые горы свернуть горе-руководители такой мысли не допускают. У них включается стереотип «Твоя работа не закончена вовремя, и это принесло мне проблемы. Ты виноват!»



Руководители тоже люди. И их порой несёт



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



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



Ок, кричать и срываться плохо. Есть ли альтернативы? Да сколько угодно!



Интроверты пишут



Технологии сегодня позволяют голосом вообще не разговаривать. Зачем, когда обо всём можно НАПИСАТЬ! Больше остальных этот вариант любят руководители-интроверты (а таких в IT, как правило, большинство).



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



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



Метод работает безотказно. В 100% случаев человек, прочитав сообщение, делает так:



image



Присмотритесь к нему. Видите, он бормочет? Знаете, что? А вот что: «Начальник — козёл. Контора — говно». Вам этого не слышно, а по рынку труда разносится далеко и ещё долго не замолкает.



Наказать или обидеть?



Настрочив злобное письмо подчинённому, вы его не наказали, а обидели.



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



Отсюда — два важных следствия. Для работников интеллектуального труда:




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

  2. Наказывать нужно так, чтобы человек сам осознал, что действительно виноват. А такое возможно, только когда были нарушены установленные и доведенные до него правила. За ошибки наказывать нельзя. Там, где нет четких правил, регламента или однозначных договоренностей, руководитель не имеет права наказывать. Да и не сможет — получится только обидеть.



Два поганых принципа регулярного менеджмента



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



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



Проблема в том, что если на проступки не реагировать, они станут повторяться чаще и чаще. Авторитет руководителя будет подорван. Сотрудники начнут игнорировать правила, регламенты и договоренности. Производительность уйдет в ноль. Компания разорится, все разойдутся по домам, the end. Шутка :)

image



Получается, что наказывать всё-таки нужно. Но как? — в этом вопросе западные книжки не помогают. Отечественные — тоже не особо. Что-то похожее на правду есть у А. Фридмана. Он разбирает разные типы операционных систем менеджмента:




  1. директивный менеджмент, или диктатура (выхватить можно за любое творчество);

  2. манипуляционный менеджмент (все всегда виноваты, но некоторым это прощается);

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

  4. регулярный менеджмент (работа по четким правилам).



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



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



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



Петя робко подходит к Кате, говорит: «Помоги мне — начальник просит». А у Кати в голове гуляет весенний ветер и полное «не хочу думать — хочу платьице». И она мягко посылает Петю уйти прочь, ибо ей некогда.



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



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

image



А Петя полез туда, куда не просили и нарушил договорённость с руководителем — вот за это и нужно наказать. Хотя в системе импровизационного менеджмента он, может, подвиг совершил и достоин медали (удовлетворил принцип «не важно, как, но в понедельник утром это должно лежать у меня на столе!»).



Второй поганый принцип регулярного менеджмента заключается в следующем:



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



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



Пример из жизни: наш сисадмин менял диски на внутреннем сервере. Процедура несложная, с чётким регламентом, проводим её каждые полгода. Но во время замены произошёл непонятный сбой и слетели все данные с жёсткого диска. Его можно было восстановить — что мы и сделали, но потеряли 4 часа работы 42 человек.



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



В регулярном менеджменте руководитель не обязан наказывать подчинённого сразу, как заметил косяк. Можно отреагировать через некоторое время. Два-три дня не изменят ситуацию, но помогут разобраться в вопросе и разработать план действий. На более длительный срок откладывать не стоит — сотрудник может забыть детали, а наказывать за то, чего человек не помнит, как-то не комильфо.



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



Прощение, амнистия, хансей и root cause-анализ



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



Не путайте амнистию с прощением.



Амнистия не бывает автоматической и основанной на принципе «ты мне, я тебе». Если в компании договорённость, что никто не опаздывает, но её нарушил и руководитель, и подчинённый — начальнику нельзя простить сотрудника, только потому, что у самого рыльце в пушку. Наказывать в этой ситуации всё равно нужно. Как руководитель накажет себя — отдельная тема, которая не касается подчинённого. Либо соответствуйте правилу, либо убирайте его.



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

https://habrahabr.ru/post/307594/?utm_source=habrahabr&utm_medium=rss&utm_campaign=best

Метки:   Комментарии (0)КомментироватьВ цитатник или сообщество
rss_rss_hh_new

Исследуем вопрос наказаний 2.0

Пятница, 12 Августа 2016 г. 10:27 (ссылка)

Этот материал будет полезен в первую очередь тем, кто много занимался программированием и вдруг внезапно стал вынужден заниматься управлением проектами и людьми. С год назад я рассказал про наказания на конференции, а солнышки из Битрикса сделали текстовую версию для #habr. К сожалению, потеряв в точности, четкости и правильности акцентов. За год материала добавилось. В конце — чеклист для ленивых :)



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

image





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



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



Это печально, но как требовать у человека наличие навыка, которому его нигде не обучали? Был себе программистом, стал менеджером, и тут — иди и наказывай? Неправильно же требовать от программиста виртуозных навыков рукопашного боя?



Но неаккуратно наказанный (а по факту — обиженный) сотрудник в такие тонкости вдаваться не станет. Разбираться придётся руководителям, менеджерам, директорам.



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



«Нести ответственность» в практическом плане



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



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



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



Как директор я понимаю, что в случае факапа огребу по полной программе. Поставлю на проект неправильных людей — провалюсь финансово, неподходящего сотрудника найму — появятся проблемы в коллективе. Вся ответственность компании лежит на мне. А какую ответственность несёт программист? Или дизайнер? Что это в практическом плане?

image



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



И лишь спустя годы я нащупал ответ на этот вопрос. И пришло понимание, что тот разработчик, который вовремя ушел домой, хоть и не закончил задачу, ни в чем не виноват. А я — да, я виноват и что-то сделал неправильно: криво построил рабочий процесс, распланировал время или неправильно сформировал ожидания заказчика. Однако молодые и готовые горы свернуть горе-руководители такой мысли не допускают. У них включается стереотип «Твоя работа не закончена вовремя, и это принесло мне проблемы. Ты виноват!»



Руководители тоже люди. И их порой несёт



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



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



Ок, кричать и срываться плохо. Есть ли альтернативы? Да сколько угодно!



Интроверты пишут



Технологии сегодня позволяют голосом вообще не разговаривать. Зачем, когда обо всём можно НАПИСАТЬ! Больше остальных этот вариант любят руководители-интроверты (а таких в IT, как правило, большинство).



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



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



Метод работает безотказно. В 100% случаев человек, прочитав сообщение, делает так:



image



Присмотритесь к нему. Видите, он бормочет? Знаете, что? А вот что: «Начальник — козёл. Контора — говно». Вам этого не слышно, а по рынку труда разносится далеко и ещё долго не замолкает.



Наказать или обидеть?



Настрочив злобное письмо подчинённому, вы его не наказали, а обидели.



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



Отсюда — два важных следствия. Для работников интеллектуального труда:




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

  2. Наказывать нужно так, чтобы человек сам осознал, что действительно виноват. А такое возможно, только когда были нарушены установленные и доведенные до него правила. За ошибки наказывать нельзя. Там, где нет четких правил, регламента или однозначных договоренностей, руководитель не имеет права наказывать. Да и не сможет — получится только обидеть.



Два поганых принципа регулярного менеджмента



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



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



Проблема в том, что если на проступки не реагировать, они станут повторяться чаще и чаще. Авторитет руководителя будет подорван. Сотрудники начнут игнорировать правила, регламенты и договоренности. Производительность уйдет в ноль. Компания разорится, все разойдутся по домам, the end. Шутка :)

image



Получается, что наказывать всё-таки нужно. Но как? — в этом вопросе западные книжки не помогают. Отечественные — тоже не особо. Что-то похожее на правду есть у А. Фридмана. Он разбирает разные типы операционных систем менеджмента:




  1. директивный менеджмент, или диктатура (выхватить можно за любое творчество);

  2. манипуляционный менеджмент (все всегда виноваты, но некоторым это прощается);

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

  4. регулярный менеджмент (работа по четким правилам).



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



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



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



Петя робко подходит к Кате, говорит: «Помоги мне — начальник просит». А у Кати в голове гуляет весенний ветер и полное «не хочу думать — хочу платьице». И она мягко посылает Петю уйти прочь, ибо ей некогда.



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



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

image



А Петя полез туда, куда не просили и нарушил договорённость с руководителем — вот за это и нужно наказать. Хотя в системе импровизационного менеджмента он, может, подвиг совершил и достоин медали (удовлетворил принцип «не важно, как, но в понедельник утром это должно лежать у меня на столе!»).



Второй поганый принцип регулярного менеджмента заключается в следующем:



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



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



Пример из жизни: наш сисадмин менял диски на внутреннем сервере. Процедура несложная, с чётким регламентом, проводим её каждые полгода. Но во время замены произошёл непонятный сбой и слетели все данные с жёсткого диска. Его можно было восстановить — что мы и сделали, но потеряли 4 часа работы 42 человек.



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



В регулярном менеджменте руководитель не обязан наказывать подчинённого сразу, как заметил косяк. Можно отреагировать через некоторое время. Два-три дня не изменят ситуацию, но помогут разобраться в вопросе и разработать план действий. На более длительный срок откладывать не стоит — сотрудник может забыть детали, а наказывать за то, чего человек не помнит, как-то не комильфо.



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



Прощение, амнистия, хансей и root cause-анализ



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



Не путайте амнистию с прощением.



Амнистия не бывает автоматической и основанной на принципе «ты мне, я тебе». Если в компании договорённость, что никто не опаздывает, но её нарушил и руководитель, и подчинённый — начальнику нельзя простить сотрудника, только потому, что у самого рыльце в пушку. Наказывать в этой ситуации всё равно нужно. Как руководитель накажет себя — отдельная тема, которая не касается подчинённого. Либо соответствуйте правилу, либо убирайте его.



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

https://habrahabr.ru/post/307594/

Метки:   Комментарии (0)КомментироватьВ цитатник или сообщество
rss_rss_hh_new

Ошибки HR'ов глазами разработчика

Среда, 10 Августа 2016 г. 16:31 (ссылка)

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



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



Ошибки HR'ов глазами разработчика



Ошибка №1. Автоответчик



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



Рекомендация

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



Ошибка №2. Спешка — плохой помощник



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



Рекомендация

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



Ошибка №3. Обратная сторона медали



Обратная сторона спешки — это чрезмерная пассивность на начальной стадии общения. Не возникает желания продолжать общение, когда в письме всего 2 строчки с просьбой показать примеры кода или ответы на вопросы тестового задания. И даже если соискатель отвечает на такое письмо, бывает, работодатель пропадает на пару дней, оставляя соискателя без ответа. Это сильно уменьшает ваши шансы на то, что данный специалист будет с вами в дальнейшем сотрудничать. Зачем работать с компанией, в которой задержки и перебои начинаются уже с первого контакта?



Рекомендация

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



Ошибка №4. Текст вместо слов



Некоторые специалисты по работе с персоналом вместо того, чтобы пообщаться с человеком персонально, просто отсылают некую общую статью или тестовое задание и просят дать ответы на вопросы («Это принципы нашей компании, прочтите и выскажите свое мнение»). Был случай, когда HR компании просто прислала мне ТЗ, перед этим указав, что разыскивают они PHP-специалиста. Результат общения не был многообещающим.



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



Рекомендация

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



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



Ошибка №5. Некомпетентность



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



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



Рекомендация

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



Ошибка №6. Отношение к критике и терпение



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



Рекомендация

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



Ошибка №7. Кто в доме хозяин



На собеседовании бывает момент, когда становится понятно, что программист по общим показателям подходит на предложенную должность. И вдруг менеджер решает показать кандидату «кто в доме хозяин». Чаще всего используются такие приёмы, как зацикливание на малозначимых проблемах: указание на орфографические ошибки, требование знания иностранного языка на высоком уровне, фокусирование на какой-то определенной узкой области, вместо того, чтобы выяснить степень понимания кандидатом основных задач. Поверьте, незначительные опечатки и ошибки в построении предложений не скажут вам ничего о степени профессиональной подготовки кандидата.



Рекомендация

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



Ошибка №8. Присутствие на собеседовании лишних людей



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



Рекомендация

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



Ошибка №9. Жадность — не порок



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



Рекомендация

Сейчас на рынке тяжело найти специалистов, с уровнем выше middle, но вполне реально. Просто будьте лояльны и учитесь вести диалог.
Original source: habrahabr.ru.

https://habrahabr.ru/post/307522/?utm_source=habrahabr&utm_medium=rss&utm_campaign=best

Метки:   Комментарии (0)КомментироватьВ цитатник или сообщество
rss_rss_hh_new

Программировать скучно, но…

Вторник, 09 Августа 2016 г. 10:52 (ссылка)

Мне не удавалось, как разработчику, задерживаться на одной работе больше двух лет.



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



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



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



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



В Enki нам повезло работать над трудной и интересной задачей. У нас есть много интересных штук для претворения их в код и множество занятных проблем, которые нужно решить. Поэтому, казалось бы, о какой скуке может идти речь? Но в начале её никогда и не бывает. Скука, как правило, нагнетается со временем, и поражает вас в самый неподходящий момент.



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





TLDR: Too Long; Didn’t Learn



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



Я испытал это лично на своей первой работе. Моя команда работала над подготовкой и обслуживанием финансовых данных через удобный API. Сначала всё было интересно из-за сложности и объёма данных. Я узнал об эффективных способах анализа данных и дизайне API. Но спустя год мы по-прежнему работали над тем же набором данных, с теми же технологиями. Я становился специалистом в какой-то узкой области. Я не узнавал ничего нового.



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



Как предотвратить подобное чувство?



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



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



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



Поддерживать старый код — скучно



Понять, что ваш проект в режиме поддержки — официально или нет — можно, когда разработчики тратят 90% своего времени на исправление багов вместо разработки новых компонентов.



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



И да и нет. Типичная проблема — это сложившиеся установки.



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



Как справляться с такой проблемой?



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



Большая, монолитная кодовая база со сложными зависимостями требует дополнительного технического обслуживания. Хорошо спроектированная инфраструктура микро-сервисов, напротив, немного податливей. Когда микро-сервис перестает работать, его можно заменить. Можно переписать его с нуля, используя другой язык или технологию. Таким образом вы узнаете что-то новое, вместо исправления унаследованного кода. А если ваша архитектура пока этого не позволяет, то вы можете предпринять какие-то шаги, чтобы её улучшить и получить навыки DevOps в процессе.



Стратегия микро-сервисов — это только один из возможных способов подойти к проблеме "скучного" технического обслуживания. Некоторые создают продвинутые инструменты, чтобы сделать поддержку более эффективной и увлекательной. Отличный пример это то, что Facebook сделал со своей массивной базой кода на PHP. Они построили свой собственный компилятор и написали собственный типизированный язык (Hack) поверх PHP, чтобы одновременно облегчить обслуживание и улучшить опыт разработчиков. Я подозреваю, что это не "решило" проблемы легаси-кода, но, безусловно, сделало работу более интересной.



Копипастить скучно



Есть программирование, и есть программирование.



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



Но это было не так. Почему?



Потому что 50% моего кода (специально преувеличиваю!) были прямым копированием из Stack Overflow. А другие 40% были копированием из других скриптов. Либо моих коллег, либо моих собственных. Работа стала однообразной. Креативности или приобретения знаний тут было мало.



Как мы пытаемся справиться с этим?



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





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



Внутренние инструменты обычно скучны



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



Почему?



Потому что вы не можете о нем поговорить с друзьями, похвастаться им, не можете прочитать о нём на Hacker News, использовать его во время хакатонов или в закрытом стороннем проекте.



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



Я видел это сам на предыдущей работе. Я был вынужден использовать внутренний DSL для масштабной интеграции данных. Всё, что я узнал нового — это ещё один подобный SQL жаргон (специально преувеличиваю). Лучше бы я пользовался и изучал открытую низкоуровневую технологию, вроде Spark. Я был бы в 10 раз сильнее вовлечён, и даже если бы мой код был бы в два раза более многословным, это всё ещё делало бы меня в 5 раз более продуктивным. (не совсем математически обосновано, но вы понимаете).



Какая культура и окружение может это предотвратить?



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



Иногда мы делаем ошибки. Например, некоторое время мы использовали библиотеку agenda.js чтобы планировать бэкенд задачи, потому что это казалось современным и заманчивым. Но оказалось, что это всё усложняет, поэтому мы переключились на старую, более надежную технологию (старый добрый cron!). Мы не жалеем, что экспериментировали, потому что это был ценный опыт.



Быть манки-кодером скучно



Еще один распространенная причина скуки — это непрофессиональное управление персоналом. Если говорить точнее: диктаторское управление разработчиками, по принципу "сверху вниз".



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



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



Но здесь есть некоторые скрытые издержки.



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



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



Как это предотвратить?



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



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



Рутина всегда становится скучной



Последнее, но не менее важное: рутина в замкнутой атмосфере — абсолютный убийца удовольствия.



И это касается не только разработчиков и индустрии IT. Это можно применить почти к любым сотрудникам, не работающими напрямую с клиентами. Каждый день та же комната, те же самые люди, та же атмосфера, та же должность… Даже в быстро растущем коллективе, и даже тогда, когда все эти вещи объективно "хороши", люди начинают принимать все хорошее как должное, а плохое их сильно расстраивает.



Как мы боремся с этим?



Ключевой ингредиент тут — разнообразие: нанимать людей с разным видом опыта и разного происхождения (например, наша команда состоит из 6 человек родом из Британии, Франции, России и Греции). Ежедневно встречаться с теми же людьми, безусловно, интереснее, если каждый из них может внести что-то особенное в культуру.



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



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





Мы также организуем сторонние вылазки для команды (например, Secret Cinema) и у нас есть еженедельный "еnkiтон" без четкой цели и плана. Во время него мы иногда пишем вместе бесполезные программы. Иногда обмозговываем новую идею. Иногда просто играем в League of Legends. Или идем в паб. Приятное тут в том, что мы не знаем, что будем делать до последней минуты, пока не решим вместе.



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


Original source: habrahabr.ru (comments, light).

https://habrahabr.ru/post/307406/

Метки:   Комментарии (0)КомментироватьВ цитатник или сообщество
rss_rss_hh_new

Как нанимают программистов. Интервью с Катериной Гавриловой из DigitalHR

Понедельник, 08 Августа 2016 г. 11:59 (ссылка)

Рекрутеров редко спрашивают про то, как устроена их работа: обычно на собеседованиях кандидатам интереснее узнавать про проекты, куда они будут выходить. Оно и правильно. Но в одну пятницу CEO DigitalHR Катя Гаврилова в интервью с Hexlet отвечала на поток вопросов от разработчиков: почему эйчары не перезванивают, как становятся рекрутерами и как они вообще ищут кандидатов. На некоторые темы так и не хватило времени, поэтому постараемся дать ответ здесь:



ОБРАЗОВАНИЕ



Если у кандидата есть высшее образование, но непрофильное?



Разработчики — счастливые люди. Хотя бы потому, что у работодателей нет строгих требований к образованию кандидатов. Важны: опыт коммерческой разработки, владение определенным фреймворком, знание конкретной базы данных. Мы редко получаем запросы от компаний, чтобы кандидат заканчивал МГТУ, МИФИ или МАИ, но если запрос на высшее технического образование есть, эти вузы будут обязательно названы. Этот вопрос важен, если вы в будущем будете рассматривать релокацию, и вас будут приглашать работать заграницу. В этом случае важно, чтобы образование было профильным.



ПРЕДЫДУЩИЙ РАБОТОДАТЕЛЬ



Насколько важны рекомендации от других компаний?



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



Как относятся к людям, которые прыгают по компаниям, например, работают по одному году?



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



Что лучше ответить на вопрос, почему ушел из компании N. Вернее не что ответить, а КАК лучше ответить, что ты вырос из этой компании.



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



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



ЗАРПЛАТА



Как должна расти зарплата с годами?



Зарплата должна расти не с годами, а с уровнем сложности задач, которые вы выполняете. Во многих компаниях есть практика, когда зарплата с каждым годом вырастает на 5-10%. Связано это прежде всего с удержанием специалиста и повышения его лояльности. Например, вы выходите на Junior Frontend Разработчика в Москве в молодую компанию. Зарплата у вас 50 тысяч. Но спустя 2 года опыта работы на рынке вы будете стоить 120 тысяч.



ПЕРЕЕЗД



Про трудоустройство с переездом, как к этом относятся hr и работодатели



Распространенный кейс: сначала удаленное сотрудничество, а потом — помощь с переездом. Так компании снижают собственные риски и снимают с себя ответственность за иногороднего работника. Идеальная ситуация — когда кандидат собирается переезжать в новый город вне зависимости от того, возьмёт ли его конкретная компания или нет; который сможет пройти несколько этапов собеседования по skype; и, если окажется проездом в Москве (например) — сможет заглянуть к будущему работодателю на личное интервью.



Про отношения к регионам vs столица



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



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



“Я очень грустный на счет вакансий в Москве) Мне нравится мой дождик и серое небо)

Но спасибо за приглашение”.



КАК РАБОТАЮТ РЕКРУТЕРЫ



Как рекрутеры отбирают кандидатов в различных областях, в которых они сами вообще ну никак не разбираются, на что ориентируются?



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



А ещё мы стараемся находиться на постоянной связи с нашими кандидатами. Поэтому на вопрос “Как дела” нам никогда не отвечают дежурной фразой:



“Анна, день добрый! Дела обстоят так себе, сломал ногу...”



Как происходит отбор, если резюме приходит очень-очень-очень много? Лотерея?



Когда вы ищите разработчика, вы избавлены от необходимости сортировать огромный поток входящих резюме. Но давайте рассмотрим ситуацию с входящими резюме на должность Junior… Кто-то из них во время учебы в ВУЗе изучал язык, кому-то помогли курсы, а кто-то выучился на дому. Но быть разработчиком значить заниматься самообразованием. Обычно в компании берут таких ребят. Должен быть интерес, должны быть свои проекты, код, выложенный на GitHub — вам проще, чем гуманитариям показать заинтересованность в работе!



Что значит мнение рекрутера? Если тимлид за кандидата, а HR против, то что решат в итоге?



Чтобы HR быть против кандидата, нужно иметь веские основания — пара или несколько плохих рекомендаций, необязательное поведение во время собеседования (систематические опоздания, просроченное выполнение тестового задания, пропуск интервью без предварительного звонка), и факты, что кандидат не впишется в корпоративную культуру (все за ЗОЖ, он курит). Но всё это Тимлид может поставить под вопрос, если разработчик его обаял и идеально подходит под задачи. В таком случае делают дополнительную встречу: знакомят разработчика с командой. Если у команды вопросов нет, разработчик приступит к делу.



ДРУГОЕ



Если у разработчика нет аккаунтов в соц. сетях-это плохо?



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



Ещё мы выходим на кандидатов в чатах Telegram и других мессенджерах. Разработчики за это нас хвалят и иногда дают неожиданные комментарии:



“Ты написала в телеграмме это огромный плюс + у тебя шеллака нет на фото походу) это тоже плюс”



Насколько подробно нужно описывать свой бекграунд в резюме, если профильный опыт ~10 лет



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


Original source: habrahabr.ru (comments, light).

https://habrahabr.ru/post/307330/

Метки:   Комментарии (0)КомментироватьВ цитатник или сообщество
аврора2012

Как " поставить на место" зарвавшегося босса

Суббота, 06 Августа 2016 г. 14:23 (ссылка)
psyfactor.org/plohoyboss.htm

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

В этом случае Вам поможет золотое правило подчиненного. Оно прекрасно известно всем опытным бюрократам. Во-первых, даже самые идиотские начинания начальства Вы должны встречать с видимым восторгом и демонстрировать неуемное рвение. Во-вторых, Вы должны систематически информировать начальство об успехах в деле. Самый сложный и ответственный третий этап: здесь нужно дождаться того момента, когда начальственный пыл немного поутихнет; и только тогда начинать микроскопические «инъекции правды». Высшее мастерство — это повернуть дело так, чтобы начальство само забыло о своих идиотских инициативах.
Метки:   Комментарии (0)КомментироватьВ цитатник или сообщество
аврора2012

Общение с трудными руководителями

Суббота, 06 Августа 2016 г. 13:18 (ссылка)
psyfactor.org/lib/plohoyboss2.htm

Типы начальников-самодуров и способы общения с ними
Запрещенные методы психологического нападения - буллинг, моббинг, боссинг и пр.
Метки:   Комментарии (0)КомментироватьВ цитатник или сообщество

Следующие 30  »

<управление персоналом - Самое интересное в блогах

Страницы: [1] 2 3 ..
.. 10

LiveInternet.Ru Ссылки: на главную|почта|знакомства|одноклассники|фото|открытки|тесты|чат
О проекте: помощь|контакты|разместить рекламу|версия для pda